وحدات EJB عديمة الحالة:إيجاد التوازن بين الأداء والأمن

Question

لدي عميل ويب JSF وعميل Java يستخدم كلاهما نفس طبقة EJB عديمة الحالة لمنطق التطبيق الخاص بهما.لست متأكدًا من كيفية الموازنة بين الحاجة إلى الأداء (الحد من كمية البيانات التي يتم نقلها بين طبقات العرض التقديمي والتطبيق) مع الأمان (بمعنى ضمان اتخاذ جميع القرارات بناءً على بيانات محدثة).

أفهم أن هذا موضوع شخصي، لذا ربما يمكنني جعله أكثر موضوعية بأمثلة ملموسة:

• هل أقوم فقط بإرسال اسم المستخدم إلى EJBs، ثم تحميل كيان المستخدم في كل استدعاء لـ EJB، أم أقوم بإرسال كيان المستخدم من طبقات العرض التقديمي؟
• إذا كنت بحاجة إلى معلومات أكثر من مجرد كيان المستخدم (لنفترض أنني بحاجة إلى تحميل كيان إضافي في كل استدعاء لـ EJB)، فهل أقوم بإرسال اسم المستخدم ومفتاح الكيان الآخر وتحميل كلا الكيانين في طبقة التطبيق، أم أرسل كلا entites من طبقات العرض؟
• ماذا لو كنت بحاجة إلى مزيد من المعلومات لبعض مكالمات EJB (>= 3 كيانات)؟

متى يكون من المنطقي إرسال الكيان الفعلي بدلاً من مفتاحه فقط، أم أن الإجابة لن يتم إعادة تحميلها أبدًا على جانب طبقة التطبيق؟هل يجب أن أقلق بشأن الأداء؟لقد سمعت أن Hibernate (الذي أستخدمه) يستخدم التخزين المؤقت الذكي مما يعني أنه ربما لن يتم إعادة تحميل كيان المستخدم من قاعدة البيانات في كل مرة؟ماذا لو كانت أساليب EJB الخاصة بي تحتوي على تفاصيل صغيرة جدًا وقد تتسبب إجراءات الواجهة الأمامية في بعض الأحيان في استدعاء 3 طرق أو أكثر من أساليب EJB، حيث يحتاج كل منها إلى تحميل كيان المستخدم؟

سؤال أخير ذو صلة:أنوي استخدام مبدأ JAAS لتخزين اسم المستخدم الذي يتم تحميله بواسطة EJBs.ماذا لو استدعت وحدات JB للواجهة البعيدة الخاصة بي مجموعة من وحدات EJB المحلية عديمة الحالة والتي تتطلب أيضًا معلومات المستخدم، فهل ما زلت أستخدم مبدأ JAAS وأقوم بتحميل كيان المستخدم في كل منها أيضًا أم أن هناك طريقة أفضل؟

Answer 1

يجب أن تفكر في وحدات EJBs ذات الحالة، حيث يبدو أن العملاء يحتاجون إلى حالة غير تافهة للرد على سلسلة من الطلبات المتعلقة بنفس الحالة من مستخدم واحد.ومع ذلك، فإن EJBs ذات الحالة هي نوع من التحمل للكتابة والتكوين بشكل صحيح.

من حيث التصميم، لن أطلب من العملاء إرسال معلومات المستخدم إلى طبقة منطق الأعمال.أولاً، إنه ينقل المشكلة إلى العميل، أليس كذلك؟لتحميل وتخزين وإرسال هذه المعلومات؟كما أنه يجعلني أشعر بالتوتر من منظور أمني، للسماح لطبقة العميل التي يُفترض أنها أقل أمانًا بتغذية بيانات المستخدم الحساسة إلى طبقة خلفية أكثر أمانًا والتي تثق بعد ذلك بهذه المعلومات وتستخدمها.

ولكن، في الحقيقة، أعتقد أنك ذكرت أفضل نهج بالفعل:التحميل البطيء للإسبات.كل ما عليك فعله هو التفاعل مع الكائن والسماح له بتحميل البيانات عند الطلب.للعمل بشكل جيد مع السبات في هذا الصدد، يجب أن يكون كائن المستخدم صغيرًا، بحيث يكون تحميله سريعًا إلى حد ما، ويدفع جميع المعلومات الكبيرة والثقيلة إلى الكائنات الفرعية أو الكيانات الأخرى.إذن لا يهم إذا كان عليك تحميل المستخدم كثيرًا؛إنه مجرد "مؤشر" لمعلومات أخرى.

لا أعتقد أنه سيغير الأمور إذا كنت تستخدم JAAS، لا.على الرغم من أنني قد أقول، بالنسبة لما أتخيله من أغراضك، فإن JAAS قد يكون أو لا يكون جديرًا بالاهتمام.في الوقت الذي يستغرقه التكامل، وكتابة الأذونات، واستخدام تلك الأذونات، والتعامل مع عواقب SecurityManager، وما إلى ذلك.ربما كان بإمكانك كتابة إطار عمل أذونات بسيط لنفسك على أية حال.

Answer 2

إذا قمت بإنشاء EJB واحد فقط، فقم بإجراء جلسة عديمة الحالة.شخصيا وجدت أنه واجهات فارغة هراء