جاكرتا إنتربرايز بينز

الموسوعة الحرة

تُعدّ Jakarta Enterprise Beans ( EJB ؛ المعروفة سابقًا باسم Enterprise JavaBeans ) إحدى واجهات برمجة تطبيقات Java العديدة لبناء برمجيات المؤسسات بشكل معياري . EJB هو مُكوّن برمجي من جانب الخادم يُغلّف منطق الأعمال للتطبيق. يُوفّر حاوية EJB بيئة تشغيل لمُكوّنات البرمجيات المُتعلّقة بالويب، بما في ذلك أمن الحاسوب ، وإدارة دورة حياة Java servlet ، ومعالجة المعاملات ، وخدمات الويب الأخرى . تُمثّل مواصفات EJB جزءًا من مواصفات Jakarta EE . [ 1 ]

مواصفة

تم تطوير مواصفات EJB في الأصل في عام 1997 بواسطة IBM وتم اعتمادها لاحقًا بواسطة Sun Microsystems (EJB 1.0 و 1.1) في عام 1999 [ 2 ] وتم تحسينها في إطار عملية مجتمع جافا كـ JSR 19 (EJB 2.0) و JSR 153 (EJB 2.1) و JSR 220 (EJB 3.0) و JSR 318 (EJB 3.1) و JSR 345 (EJB 3.2).

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

المسؤوليات العامة

توضح مواصفات EJB بالتفصيل كيف يوفر خادم التطبيقات المسؤوليات التالية:

بالإضافة إلى ذلك، تحدد مواصفات Jakarta Enterprise Beans الأدوار التي يؤديها كل من حاوية EJB ووحدات EJB، فضلاً عن كيفية نشر وحدات EJB داخل الحاوية. تجدر الإشارة إلى أن مواصفات EJB لا تُفصّل كيفية توفير خادم التطبيقات لخدمات الثبات (وهي مهمة مُفوّضة إلى مواصفات JPA)، بل تُفصّل كيفية دمج منطق الأعمال بسهولة مع خدمات الثبات التي يُقدّمها خادم التطبيقات.

تاريخ

وجدت الشركات أن استخدام مكونات EJB لتغليف منطق الأعمال يؤدي إلى انخفاض في الأداء. ويعود ذلك إلى أن المواصفات الأصلية كانت تسمح فقط باستدعاء الدوال عن بُعد عبر بروتوكول CORBA (وبروتوكولات أخرى اختيارية)، على الرغم من أن الغالبية العظمى من تطبيقات الأعمال لا تتطلب فعليًا هذه الوظيفة للحوسبة الموزعة . وقد عالجت مواصفات EJB 2.0 هذا القلق بإضافة مفهوم الواجهات المحلية التي يمكن استدعاؤها مباشرةً دون أي تأثير سلبي على الأداء من قِبل التطبيقات غير الموزعة على خوادم متعددة. [ 3 ]

مثّلت مواصفات EJB 3.0 ( JSR 220) نقلةً نوعيةً عن سابقاتها، إذ تبنّت نموذجًا جديدًا خفيف الوزن. ويظهر تأثر EJB 3.0 بإطار عمل Spring في استخدامه لكائنات Java البسيطة، ودعمه لحقن التبعية لتبسيط تهيئة ودمج الأنظمة غير المتجانسة. ويمكن دمج EJB 3.0، إلى جانب الإصدارات الأخرى من EJB، مع MuleSoft v4 باستخدام موصل PlektonLabs EJB المعتمد من MuleSoft . وقد شارك غافين كينغ، مبتكر Hibernate ، في عملية تطوير EJB 3.0، وهو من أشدّ المتحمسين لهذه التقنية. وتم دمج العديد من الميزات التي كانت موجودةً في Hibernate في واجهة برمجة تطبيقات Java Persistence API ، التي حلّت محلّ Entity Beans في EJB 3.0. وتعتمد مواصفات EJB 3.0 بشكل كبير على استخدام التعليقات التوضيحية (وهي ميزة أُضيفت إلى لغة Java مع إصدارها 5.0) وعلى مبدأ "الاتفاقيات بدلًا من التهيئة" لتمكين أسلوب برمجة أقل إسهابًا. وبناءً على ذلك، من الناحية العملية، فإن EJB 3.0 أخف وزناً بكثير وهو واجهة برمجة تطبيقات جديدة تماماً تقريباً، ولا يشبه مواصفات EJB السابقة إلا قليلاً.

مثال

يوضح المثال التالي نموذجًا أساسيًا لما يبدو عليه مكون EJB في الكود:

@Stateless public class CustomerService {private EntityManager entityManager ; public void addCustomer ( Customer customer ) { entityManager.persist ( customer ) ; } }​

يُعرّف ما سبق فئة خدمة لحفظ كائن العميل (عبر ربط الكائنات العلائقية ). يتولى EJB إدارة سياق الحفظ، وتُعدّ دالة addCustomer() آمنة للاستخدام في بيئات متعددة الخيوط ومعاملاتية افتراضيًا. وكما هو موضح، يركز EJB فقط على منطق الأعمال والحفظ، ولا يعلم شيئًا عن أي عرض مُحدد.

يمكن استخدام مثل هذا المكون الأساسي (EJB) بواسطة فئة في طبقة الويب على سبيل المثال كما يلي:

@Named @RequestScoped public class CustomerBacking { @EJB private CustomerService customerService ;public String addCustomer ( Customer customer ) { customerService . addCustomer ( customer ); context . addMessage (...); // اختصار للاختصار return "customer_overview" ; } }

يُعرّف ما سبق كائن JavaServer Faces (JSF) كعنصر داعم، حيث يتم حقن كائن EJB فيه باستخدام @EJBالتعليق التوضيحي. عادةً ما تكون دالة addCustomer الخاصة به مرتبطة بمكون واجهة مستخدم، مثل زر. على عكس كائن EJB، لا يحتوي الكائن الداعم على أي منطق أعمال أو كود تخزين، بل يُفوّض هذه المهام إلى كائن EJB. مع ذلك، يعرف الكائن الداعم عرضًا تقديميًا معينًا، لم يكن كائن EJB على دراية به.

أنواع برامج إدارة المشاريع

تحتوي حاوية EJB على نوعين رئيسيين من الفاصوليا:

  • تُعدّ Session Beans [ 4 ] كائناتٍ يمكن أن تكون "ذات حالة" أو "عديمة الحالة" أو "أحادية"، ويمكن الوصول إليها عبر واجهة محلية (على نفس JVM) أو واجهة بعيدة (على JVM مختلف)، أو مباشرةً بدون واجهة [ 5 ]، وفي هذه الحالة تُطبّق الدلالات المحلية. تدعم جميع كائنات Session Beans التنفيذ غير المتزامن [ 6 ] لجميع طرق العرض (المحلية/البعيدة/بدون واجهة).
  • مكونات الرسائل الموجهة (MDBs، والمعروفة أيضًا باسم مكونات الرسائل). تدعم مكونات الرسائل الموجهة التنفيذ غير المتزامن أيضًا، ولكن من خلال نموذج المراسلة.

مكونات الجلسة

Stateful Session Beans

تُعدّ Stateful Session Beans [ 7 ] كائنات أعمال تحتفظ بحالة : أي أنها تُسجّل العميل المُستدعي الذي تتعامل معه طوال الجلسة، بالإضافة إلى سجل طلباته، وبالتالي يقتصر الوصول إلى مثيل الكائن على عميل واحد فقط طوال فترة وجوده. [ 8 ] إذا تمت محاولة الوصول المتزامن إلى كائن واحد، يقوم الحاوية بتسلسل تلك الطلبات، ولكن باستخدام @AccessTimeoutالتعليق التوضيحي، يمكن للحاوية بدلاً من ذلك طرح استثناء. [ 9 ] يمكن للحاوية حفظ حالة Stateful Session Beans (تخميلها) تلقائيًا لتحرير الذاكرة بعد عدم وصول العميل إلى الكائن لفترة من الوقت. يدعم Stateful Session Beans سياق الثبات الموسّع لـ JPA بشكل صريح. [ 10 ]

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

حبوب جلسات عديمة الحالة

تُعدّ كائنات الجلسة عديمة الحالة [ 11 ] كائنات أعمال لا ترتبط بها أي حالة. ومع ذلك، يظل الوصول إلى نسخة واحدة من الكائن محدودًا بعميل واحد فقط في كل مرة، ويُحظر الوصول المتزامن إليه. [ 8 ] في حال محاولة الوصول المتزامن إلى كائن واحد، يقوم الحاوية ببساطة بتوجيه كل طلب إلى نسخة مختلفة. [ 12 ] هذا يجعل كائن الجلسة عديم الحالة آمنًا تلقائيًا للاستخدام المتزامن. يمكن استخدام متغيرات النسخة أثناء استدعاء دالة واحدة من العميل إلى الكائن، ولكن لا يُضمن الحفاظ على محتويات هذه المتغيرات عبر استدعاءات الدوال المختلفة من قِبل العميل . عادةً ما يتم تجميع نسخ كائنات الجلسة عديمة الحالة. إذا وصل عميل ثانٍ إلى كائن معين مباشرةً بعد انتهاء استدعاء دالة عليه من قِبل عميل أول، فقد يحصل على نفس النسخة. إن عدم وجود تكلفة إضافية للحفاظ على اتصال مع العميل المُستدعي يجعلها أقل استهلاكًا للموارد من الكائنات ذات الحالة.

أمثلة
  • قد تتم معالجة إرسال بريد إلكتروني إلى دعم العملاء بواسطة مكون برمجي عديم الحالة، لأن هذه عملية لمرة واحدة وليست جزءًا من عملية متعددة الخطوات.
  • قد يؤدي نقر مستخدم موقع ويب على مربع "أبقني على اطلاع بالتحديثات المستقبلية" إلى استدعاء طريقة غير متزامنة لـ session bean لإضافة المستخدم إلى قائمة في قاعدة بيانات الشركة (هذا الاستدعاء غير متزامن لأن المستخدم لا يحتاج إلى الانتظار ليتم إبلاغه بنجاحه أو فشله).
  • يمكن أيضًا معالجة جلب بيانات متعددة ومستقلة لموقع ويب، مثل قائمة المنتجات وسجل المستخدم الحالي، باستخدام طرق غير متزامنة في كائن جلسة (تُعتبر هذه الاستدعاءات غير متزامنة لأنها تُنفذ بالتوازي ، مما يُحسّن الأداء). في هذه الحالة، ستُعيد الطريقة غير المتزامنة كائنًا من نوع Future .

حبوب سينجلتون سيشن

تُعدّ كائنات Singleton Session Beans [ 13 ] [ 14 ] كائنات أعمال ذات حالة مشتركة عامة ضمن بيئة JVM. يُمكن التحكم في الوصول المتزامن إلى نسخة الكائن الوحيدة إما بواسطة الحاوية (التزامن المُدار بواسطة الحاوية، CMC) أو بواسطة الكائن نفسه (التزامن المُدار بواسطة الكائن، BMC). يُمكن ضبط CMC باستخدام @Lockالتعليق التوضيحي الذي يُحدد ما إذا كان سيتم استخدام قفل قراءة أو قفل كتابة لاستدعاء دالة. بالإضافة إلى ذلك، يُمكن لكائنات Singleton Session Beans طلب إنشاء مثيل لها صراحةً عند بدء تشغيل حاوية EJB، باستخدام @Startupالتعليق التوضيحي.

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

مكونات مدفوعة بالرسائل

تُعدّ كائنات Message Driven Beans [ 15 ] كائنات أعمال يتم تشغيلها بواسطة الرسائل بدلاً من استدعاءات الدوال. تُستخدم هذه الكائنات، من بين أمور أخرى، لتوفير تجريد عالي المستوى وسهل الاستخدام لمواصفات JMS ( خدمة رسائل جافا ) ذات المستوى الأدنى. يمكنها الاشتراك في قوائم انتظار رسائل JMS أو مواضيع الرسائل، ويتم ذلك عادةً عبر سمة activationConfig في @MessageDrivenالتعليق التوضيحي. أُضيفت هذه الكائنات في EJB للسماح بالمعالجة القائمة على الأحداث. على عكس كائنات الجلسة، لا تمتلك كائنات MDB واجهة عرض للعميل (محلية/بعيدة/بدون واجهة)، أي  لا يمكن للعملاء البحث عن مثيل MDB. تستمع كائنات MDB فقط لأي رسالة واردة، على سبيل المثال، في قائمة انتظار أو موضوع JMS، وتعالجها تلقائيًا. يتطلب معيار Java EE دعم JMS فقط [ 16 ]، ولكن يمكن لكائنات Message Driven Beans دعم بروتوكولات مراسلة أخرى [ 17 ] [ 18 ] . قد تكون هذه البروتوكولات غير متزامنة، ولكنها قد تكون متزامنة أيضًا. بما أن حزم الجلسات يمكن أن تكون متزامنة أو غير متزامنة، فإن الفرق الرئيسي بين حزم الجلسات وحزم الرسائل ليس التزامن، بل الفرق بين استدعاء الأساليب (الموجهة للكائنات) والمراسلة .

أمثلة
  • يمكن إرسال تحديث التكوين إلى عدة عقد عن طريق إرسال رسالة JMS إلى "موضوع الرسائل" ويمكن التعامل معها بواسطة Message Driven Bean الذي يستمع إلى هذا الموضوع (يتم استخدام نموذج الرسائل هنا لأن المرسل لا يحتاج إلى معرفة عدد المستهلكين أو موقعهم أو حتى نوعهم الدقيق).
  • يمكن إرسال مهمة إلى مجموعة عمل عن طريق إرسال رسالة JMS إلى "قائمة انتظار الرسائل"، ويمكن أيضًا معالجتها بواسطة Message Driven Bean، ولكن هذه المرة يتم الاستماع إلى قائمة انتظار (يتم استخدام نموذج الرسائل وقائمة الانتظار، حيث لا يتعين على المرسل الاهتمام بأي عامل يقوم بتنفيذ المهمة، ولكنه يحتاج إلى ضمان أن المهمة يتم تنفيذها مرة واحدة فقط).
  • يمكن معالجة أحداث التوقيت من مُجدول Quartz بواسطة Message Driven Bean؛ فعند تشغيل مُشغّل Quartz ، يتم استدعاء MDB تلقائيًا. ولأن Java EE لا تتعرف على Quartz افتراضيًا، فسيلزم وجود مُهايئ موارد JCA ، وسيتم إضافة تعليق توضيحي إلى MDB يُشير إليه. [ 19 ]

تنفيذ

يتم نشر مكونات EJB في حاوية EJB، عادةً ضمن خادم التطبيقات . يصف هذا المعيار كيفية تفاعل مكون EJB مع حاويته، وكيفية تفاعل كود العميل مع مزيج الحاوية ومكون EJB. تتضمن الحزمة فئات EJB التي تستخدمها التطبيقات javax.ejb. ( javax.ejb.spiالحزمة عبارة عن واجهة لمزود الخدمة تُستخدم فقط من قِبل تطبيقات حاوية EJB).

لا يقوم عملاء EJBs بإنشاء مثيلات لهذه المكونات مباشرةً باستخدام عامل التشغيل new في Java، بل عليهم الحصول على مرجع عبر حاوية EJB. عادةً لا يكون هذا المرجع مرجعًا إلى مكون التنفيذ نفسه، بل إلى وكيل (proxy ) يُنفذ ديناميكيًا إما واجهة الأعمال المحلية أو البعيدة التي طلبها العميل، أو نوعًا فرعيًا من المكون الفعلي. يمكن بعد ذلك تحويل الوكيل مباشرةً إلى الواجهة أو المكون، على التوالي. يُقال إن لدى العميل "عرضًا" على EJB، وتتوافق الواجهة المحلية والواجهة البعيدة ونوع المكون الفرعي نفسه، على التوالي، مع العرض المحلي والعرض البعيد وعرض بدون واجهة.

هذا الوسيط ضروري لتمكين حاوية EJB من تقديم خدمات شاملة ( شبيهة بـ AOP ) إلى وحدة برمجية (Bean) بشكل شفاف، مثل المعاملات والأمان والاعتراضات والحقن والتحكم عن بُعد. على سبيل المثال، يستدعي العميل دالةً على الوسيط، الذي يبدأ أولًا معاملةً بمساعدة حاوية EJB، ثم يستدعي دالة الوحدة البرمجية (Bean) الفعلية. عند انتهاء دالة الوحدة البرمجية، يُنهي الوسيط المعاملة (أي بتثبيتها أو التراجع عنها) ويعيد التحكم إلى العميل.

يُعدّ حاوية EJB مسؤولة عن ضمان حصول كود العميل على حقوق وصول كافية إلى EJB. [ 20 ] ويمكن تطبيق جوانب الأمان بشكل تصريحي على EJB عبر التعليقات التوضيحية. [ 21 ]

المعاملات

يجب أن تدعم حاويات EJB كلاً من معاملات ACID التي تديرها الحاويات والمعاملات التي تديرها المكونات. [ 22 ]

تُفعّل المعاملات المُدارة بواسطة الحاوية (CMT) افتراضيًا عند استدعاء مكونات الجلسة. أي أنه لا حاجة إلى أي تهيئة صريحة. يمكن ضبط هذا السلوك بشكل تصريحي بواسطة المكون عبر التعليقات التوضيحية، ويمكن تجاوز هذه التهيئة لاحقًا في واصف النشر عند الحاجة. تشمل الضبط إيقاف المعاملات للمكون بأكمله أو لأساليب محددة، أو طلب استراتيجيات بديلة لنشر المعاملات وبدء معاملة أو الانضمام إليها. تتعامل هذه الاستراتيجيات بشكل أساسي مع ما يجب فعله إذا كانت المعاملة قيد التنفيذ أو لا عند استدعاء المكون. يتم دعم الاختلافات التالية: [ 23 ] [ 24 ]

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

بدلاً من ذلك، يمكن للـ Bean أيضاً أن يُعلن عبر تعليق توضيحي أنه يرغب في معالجة المعاملات برمجياً عبر واجهة برمجة تطبيقات JTA . يُطلق على نمط التشغيل هذا اسم "المعاملات المُدارة بواسطة Bean" (BMT)، حيث يتولى Bean نفسه معالجة المعاملة بدلاً من الحاوية. [ 25 ]

الفعاليات

تُستخدم خدمة رسائل جافا (JMS ) لإرسال الرسائل من المكونات البرمجية (Beans) إلى العملاء، مما يسمح للعملاء باستقبال الرسائل غير المتزامنة من هذه المكونات. ويمكن استخدام وحدات إدارة الرسائل (MDBs) لاستقبال الرسائل من العملاء بشكل غير متزامن باستخدام إما قائمة انتظار JMS أو موضوع JMS.

خدمات التسمية والدليل

كبديلٍ لتقنية الحقن، يمكن لعملاء EJB الحصول على مرجعٍ لكائن وكيل جلسة العمل (EJB stub) باستخدام واجهة تسمية ودليل جافا (JNDI) . يُمكن استخدام هذا البديل في الحالات التي لا تتوفر فيها تقنية الحقن، كما هو الحال في التعليمات البرمجية غير المُدارة أو عملاء Java SE البعيدين المستقلين، أو عندما يكون من الضروري تحديد نوع كائن جلسة العمل المطلوب برمجيًا.

يتم تعيين أسماء JNDI لـ EJB session beans بواسطة حاوية EJB عبر المخطط التالي: [ 26 ] [ 27 ] [ 28 ]

أسماء JNDI
نِطَاقنمط الاسم
عالميjava:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interface-name>]
طلبjava:app/<module-name>/<bean-name>[!<fully-qualified-interface-name>]
وحدةjava:module/<bean-name>[!<fully-qualified-interface-name>]

(العناصر بين قوسين مربعين تشير إلى أجزاء اختيارية)

يمكن الحصول على عنصر واحد (bean) بأي اسم يطابق الأنماط المذكورة أعلاه، وذلك بحسب "موقع" العميل. يمكن للعملاء الموجودين في نفس الوحدة النمطية التي يوجد بها العنصر المطلوب استخدام نطاق الوحدة النمطية والنطاقات الأوسع، ويمكن للعملاء الموجودين في نفس التطبيق الذي يوجد به العنصر المطلوب استخدام نطاق التطبيق والنطاقات الأوسع، وهكذا.

يمكن لرمز Eg الذي يعمل في نفس الوحدة النمطية مثل عنصر CustomerService (كما هو موضح في المثال السابق في هذه المقالة) استخدام الرمز التالي للحصول على مرجع (محلي) إليه:

CustomerServiceLocal customerService = ( CustomerServiceLocal ) new InitialContext (). lookup ( "java:module/CustomerService" );

التنفيذ عن بعد/الموزع

للتواصل مع عميل مكتوب بلغة برمجة جافا، يمكن لـ session bean أن يعرض عرضًا عن بعد عبر واجهة مشروحة بـ @Remote. [ 29 ] وهذا يسمح باستدعاء هذه الـ beans من عملاء في JVMs أخرى قد تعمل على أنظمة أخرى (من وجهة نظر حاوية EJB، أي كود في JVM آخر هو عن بعد).

قد تُتيح مكونات جلسات Stateless و Singleton أيضًا "عرض عميل خدمة ويب" للتواصل عن بُعد عبر WSDL و SOAP أو XML عادي. [ 30 ] [ 31 ] [ 32 ] يتوافق هذا مع مواصفات JAX-RPC و JAX-WS . مع ذلك، يُقترح إزالة دعم JAX-RPC مستقبلًا. [ 33 ] لدعم JAX-WS، تُضاف تعليقات توضيحية إلى مكون الجلسة @WebService، وتُضاف تعليقات توضيحية إلى الطرق التي سيتم عرضها عن بُعد @WebMethod.

على الرغم من أن مواصفات EJB لا تُشير إلى إمكانية الوصول إليها كخدمات ويب RESTful بأي شكل من الأشكال، ولا تدعم هذا النوع من الاتصال صراحةً، فإن مواصفات JAX-RS تدعم EJB صراحةً. [ 34 ] وفقًا لمواصفات JAX-RS، يمكن تعريف مكونات جلسات Stateless وSingleton كموارد جذرية عبر @Pathالتعليق التوضيحي، ويمكن ربط أساليب أعمال EJB بأساليب الموارد عبر التعليقات التوضيحية @GET. مع ذلك @PUT، لا يُعد هذا "عرض عميل خدمة ويب"، والذي يُستخدم حصريًا مع JAX-WS وJAX-RPC.@POST@DELETE

يُعدّ التواصل عبر خدمات الويب شائعًا للعملاء غير المكتوبين بلغة برمجة جافا، ولكنه مناسب أيضًا لعملاء جافا الذين يواجهون صعوبة في الوصول إلى خادم EJB عبر جدار الحماية. إضافةً إلى ذلك، يمكن لعملاء جافا استخدام التواصل القائم على خدمات الويب لتجاوز المتطلبات المعقدة وغير المحددة لما يُسمى "مكتبات العميل"؛ وهي مجموعة من ملفات JAR التي يجب أن تكون موجودة في مسار فئة عميل جافا للتواصل مع خادم EJB البعيد. قد تتعارض مكتبات العميل هذه مع المكتبات الموجودة لدى العميل بالفعل (على سبيل المثال، إذا كان العميل نفسه خادم جافا EE كاملًا)، ويُعتبر حل هذا التعارض صعبًا للغاية أو مستحيلًا. [ 35 ]

إرث

واجهات المستخدم الرئيسية وواجهة الأعمال المطلوبة

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

وصف النشر المطلوب

في الإصدار 2.1 من EJB والإصدارات الأقدم، كان من الضروري وجود وصف نشر. كان هذا ضروريًا لتطبيق آلية تسمح بنشر مكونات EJB بطريقة متسقة بغض النظر عن منصة EJB المختارة. وكان يجب تحديد معلومات حول كيفية نشر المكون (مثل اسم الواجهة الرئيسية أو البعيدة، وما إذا كان سيتم تخزين المكون في قاعدة بيانات وكيفية ذلك، إلخ) في وصف النشر.

ملف وصف النشر هو مستند XML يحتوي على مدخل لكل مكون EJB يتم نشره. يحدد هذا المستند المعلومات التالية لكل مكون EJB:

  • اسم واجهة المستخدم الرئيسية
  • فئة جافا للكائن (كائن الأعمال)
  • واجهة جافا للواجهة الرئيسية
  • واجهة جافا للكائن التجاري
  • مخزن دائم (خاص بـ Entity Beans فقط)
  • الأدوار والصلاحيات الأمنية
  • ذو حالة أو عديم الحالة (لـ Session Beans)

كانت حاويات EJB القديمة من العديد من الموردين تتطلب معلومات نشر أكثر مما هو مذكور في مواصفات EJB. وكانت تتطلب هذه المعلومات الإضافية كملفات XML منفصلة، ​​أو بتنسيق ملف تكوين آخر . وعادةً ما كان موردو منصات EJB يوفرون أدواتهم الخاصة التي تقرأ وصف النشر هذا، وربما تُنشئ مجموعة من الفئات التي تُنفذ واجهات Home وRemote التي أصبحت الآن مهملة.

منذ إصدار EJB 3.0 ( JSR 220 )، تم استبدال واصف XML بتعليقات Java المُحددة في تطبيق Enterprise Bean (على مستوى المصدر)، مع أنه لا يزال من الممكن استخدام واصف XML بدلاً من التعليقات (أو بالإضافة إليها). إذا تم تطبيق كل من واصف XML والتعليقات على نفس السمة داخل Enterprise Bean، فإن تعريف XML يُلغي التعليق المقابل على مستوى المصدر، مع العلم أن بعض عناصر XML يمكن أن تكون إضافية (على سبيل المثال، @ActivationConfigPropertyسيتم إضافة خاصية activation-config-property في XML باسم مختلف عن الاسم المُعرّف مسبقًا عبر تعليق، بدلاً من استبدال جميع الخصائص الموجودة).

تنوعات الحاويات

ابتداءً من EJB 3.1، تحدد مواصفات EJB نوعين من حاوية EJB؛ نسخة كاملة ونسخة محدودة. تلتزم النسخة المحدودة بمجموعة فرعية محددة من المواصفات تُسمى EJB 3.1 Lite [ 36 ] [ 37 ] ، وهي جزء من ملف تعريف الويب الخاص بـ Java EE 6 (والذي يُعد بدوره مجموعة فرعية من مواصفات Java EE 6 الكاملة).

يستثني EJB 3.1 Lite دعم الميزات التالية: [ 38 ]

  • واجهات عن بعد
  • قابلية التشغيل البيني بين RMI وIIOP
  • نقاط نهاية خدمة الويب JAX-WS
  • خدمة مؤقت EJB ( @Schedule, @Timeout)
  • استدعاءات جلسة غير متزامنة ( @Asynchronous)
  • حبوب مدفوعة بالرسائل

يستثني EJB 3.2 Lite عددًا أقل من الميزات. على وجه الخصوص، لم يعد يستثني @Asynchronousو @Schedule/ @Timeout، ولكنه @Scheduleلا يدعم خاصية "persistent" التي يدعمها EJB 3.2 الكامل. فيما يلي قائمة الميزات المستثناة الكاملة لـ EJB 3.2 Lite:

  • واجهات عن بعد
  • قابلية التشغيل البيني بين RMI وIIOP
  • نقاط نهاية خدمة الويب JAX-WS
  • المؤقتات المستمرة ("خاصية الاستمرارية" مُفعّلة @Schedule)
  • حبوب مدفوعة بالرسائل

سجل الإصدارات

EJB 4.0، الإصدار النهائي (22-05-2020)

كان Jakarta Enterprise Beans 4.0 ، كجزء من Jakarta EE 9، إصدارًا للأدوات نقل بشكل أساسي أسماء حزم واجهة برمجة التطبيقات من javax.ejbالحزمة ذات المستوى الأعلى إلى jakarta.ejbالحزمة ذات المستوى الأعلى. [ 39 ]

وشملت التغييرات الأخرى إزالة واجهات برمجة التطبيقات القديمة التي لم يعد من المجدي نقلها إلى الحزمة الرئيسية الجديدة، وإزالة الميزات التي تعتمد على ميزات تمت إزالتها من Java أو من أي مكان آخر في Jakarta EE 9. تمت إزالة واجهات برمجة التطبيقات التالية:

  • الطرق التي تعتمد على java.security.Identityوالتي تمت إزالتها من Java 14.
  • الأساليب التي تعتمد على Jakarta XML RPC لتعكس إزالة XML RPC من منصة Jakarta EE 9.
  • طريقة مهملة EJBContext.getEnvironment().
  • "دعم قابلية التشغيل البيني الموزع" ليعكس إزالة CORBA من Java 11 ومنصة Jakarta EE 9.

وتشمل التغييرات الطفيفة الأخرى وضع علامة على مجموعة واجهة برمجة تطبيقات Enterprise Beans 2.x على أنها "اختيارية" وجعل Scheduleالتعليق التوضيحي قابلاً للتكرار.

EJB 3.2.6، الإصدار النهائي (2019-08-23)

Jakarta Enterprise Beans 3.2 ، كجزء من Jakarta EE 8، وعلى الرغم من استمرار استخدام اختصار "EJB"، فقد تم تغيير اسم مجموعة واجهات برمجة التطبيقات هذه رسميًا إلى "Jakarta Enterprise Beans" بواسطة مؤسسة Eclipse حتى لا يتم التعدي على العلامة التجارية "Java" الخاصة بشركة Oracle.

EJB 3.2، الإصدار النهائي (2013-05-28)

JSR 345. كان إصدار Enterprise JavaBeans 3.2 إصدارًا ثانويًا نسبيًا، احتوى بشكل أساسي على توضيحات للمواصفات ورفع بعض القيود التي فرضتها، ولكنه مع مرور الوقت بدا بلا جدوى. كما طُلب تضمين بعض ميزات EJB الكاملة الموجودة في EJB 3 Lite، وتم بالفعل حذف بعض الوظائف التي كان من المقترح حذفها في EJB 3.1 (جعلها اختيارية). [ 40 ] [ 41 ]

تمت إضافة الميزات التالية:

  • يمكن تعطيل خاصية "الخمول" في جلسة ذات حالة عبر السمة الموجودة في @Statefulالتعليق التوضيحي (passivationCapable = false).
  • يمكن لـ TimerService استرداد جميع المؤقتات النشطة في نفس وحدة EJB (كان من الممكن سابقًا استرداد المؤقتات الخاصة بالـ bean الذي تم استدعاء TimerService فيه فقط).
  • يمكن أن تكون أساليب دورة الحياة (على سبيل المثال @PostConstruct) معاملاتية بالنسبة لحزم جلسات الحالة باستخدام @TransactionAttributeالتعليقات التوضيحية الموجودة
  • واجهة قابلة للإغلاق التلقائي يتم تنفيذها بواسطة حاوية قابلة للتضمين

EJB 3.1، الإصدار النهائي (10-12-2009)

JSR 318. الغرض من مواصفات Enterprise JavaBeans 3.1 هو زيادة تبسيط بنية EJB عن طريق تقليل تعقيدها من وجهة نظر المطور، مع إضافة وظائف جديدة استجابةً لاحتياجات المجتمع:

  • عرض محلي بدون واجهة (عرض بدون واجهة)
  • تغليف مكونات EJB بصيغة .war
  • EJB Lite: تعريف مجموعة فرعية من EJB
  • أسماء JNDI العالمية المحمولة لـ EJB
  • Singletons (Singleton Session Beans)
  • أحداث تهيئة التطبيق وإيقاف تشغيله
  • تحسينات خدمة مؤقت EJB
  • التزامن البسيط ( @Asynchronousلجلسات الحزم)

EJB 3.0، الإصدار النهائي (2006-05-11)

JSR 220 - تغييرات رئيسية : سهّل هذا الإصدار كتابة مكونات EJB بشكل كبير، باستخدام "التعليقات التوضيحية" بدلاً من "وصفات النشر" المعقدة المستخدمة في الإصدار 2.x. كما لم يعد استخدام واجهات المستخدم الرئيسية والبعيدة وملف ejb-jar.xml مطلوبًا في هذا الإصدار، حيث تم استبدالها بواجهة أعمال ووحدة برمجية (bean) تُنفذ هذه الواجهة.

EJB 2.1، الإصدار النهائي (24-11-2003)

JSR 153 - التغييرات الرئيسية :

  • دعم خدمة الويب (جديد): يمكن استدعاء مكونات الجلسة عديمة الحالة عبر بروتوكول SOAP / HTTP . كما يمكن لـ EJB الوصول بسهولة إلى خدمة الويب باستخدام مرجع الخدمة الجديد.
  • خدمة مؤقت EJB (جديد): آلية قائمة على الأحداث لاستدعاء EJBs في أوقات محددة.
  • تقبل مكونات البرمجيات الموجهة بالرسائل الرسائل من مصادر أخرى غير JMS .
  • تمت إضافة وجهات الرسائل (وهي نفس فكرة مراجع EJB، ومراجع الموارد، وما إلى ذلك).
  • إضافات لغة استعلام EJB (EJB-QL): ORDER BY، AVG، MIN، MAX، SUM، COUNT، وMOD.
  • يُستخدم مخطط XML لتحديد واصفات النشر، ويحل محل DTDs

EJB 2.0، الإصدار النهائي (22-08-2001)

JSR 19 - التغييرات الرئيسية : الأهداف العامة :

  • بنية المكونات القياسية لبناء تطبيقات الأعمال الموزعة الموجهة للكائنات في جافا .
  • اجعل من الممكن بناء تطبيقات موزعة من خلال الجمع بين المكونات المطورة باستخدام أدوات من موردين مختلفين .
  • اجعل كتابة تطبيقات (المؤسسات) سهلة: لن يضطر مطورو التطبيقات إلى فهم تفاصيل إدارة المعاملات والحالة على مستوى منخفض، والترابط المتعدد، وتجميع الاتصالات، وواجهات برمجة التطبيقات المعقدة الأخرى على مستوى منخفض.
  • سيتبع هذا النهج فلسفة " اكتب مرة واحدة، شغّل في أي مكان " الخاصة بلغة جافا . يمكن تطوير مكون المؤسسة مرة واحدة، ثم نشره على منصات متعددة دون إعادة تجميع أو تعديل شفرة المصدر.
  • تناول جوانب التطوير والنشر والتشغيل لدورة حياة تطبيق المؤسسة.
  • حدد العقود التي تُمكّن الأدوات من موردين متعددين من تطوير ونشر مكونات يمكنها العمل معًا في وقت التشغيل.
  • يجب أن يكون متوافقًا مع منصات الخوادم الحالية. سيتمكن الموردون من توسيع منتجاتهم الحالية لدعم مكونات EJB.
  • يجب أن يكون متوافقًا مع واجهات برمجة تطبيقات Java الأخرى .
  • توفير إمكانية التشغيل البيني بين مكونات Enterprise Beans ومكونات Java EE بالإضافة إلى تطبيقات لغات البرمجة غير Java.
  • يجب أن يكون متوافقًا مع بروتوكولات CORBA (RMI-IIOP).

EJB 1.1، الإصدار النهائي (17-12-1999)

تغييرات رئيسية :

  • واصفات نشر XML
  • سياقات JNDI الافتراضية
  • RMI أكثر من IIOP
  • الأمن - يعتمد على الأدوار، وليس على الأساليب
  • دعم Entity Bean - إلزامي وليس اختياريًا

أهداف الإصدار 1.1:

  • توفير دعم أفضل لتجميع التطبيقات ونشرها.
  • حدد بمزيد من التفصيل مسؤوليات أدوار EJB الفردية.

EJB 1.0 (1998-03-24)

تم الإعلان عنه في مؤتمر JavaOne 1998 ، [ 42 ] وهو المؤتمر الثالث لمطوري جافا الذي عقدته شركة صن (من 24 إلى 27 مارس). أهداف الإصدار 1.0:

  • تم تحديد "أدوار EJB" المميزة التي تضطلع بها بنية المكون.
  • تم تحديد وجهة نظر العميل لـ Enterprise Beans.
  • تم تحديد وجهة نظر مطوري Bean المؤسسية.
  • تم تحديد مسؤوليات موفر حاويات EJB وموفر الخادم؛ تشكل هذه معًا نظامًا يدعم نشر وتنفيذ مكونات المؤسسة (Enterprise Beans).

مراجع

  1. ↑ "مواصفات جاكرتا إنتربرايز بينز" . jakarta.ee . تم الاطلاع عليه بتاريخ 2025-04-06 .
  2. ↑ تصميم وتطوير J2EE ، 2002 Wrox Press Ltd.، ص 5.
  3. ↑ تصميم وتطوير J2EE ، 2002، Wrox Press Ltd.، ص 19.
  4. ↑ JSR 318، 4.1، http://jcp.org/en/jsr/detail?id=318
  5. ↑ "واجهات الأعمال المحلية الاختيارية (مدونة كين ساكس)" . مؤرشف من الأصل في 19 نوفمبر 2015. تم الاطلاع عليه في 1 يونيو 2016 .
  6. ↑ JSR 318، 4.5، http://jcp.org/en/jsr/detail?id=318
  7. ↑ JSR 318، 4.6، http://jcp.org/en/jsr/detail?id=318
  8. 1 2 JSR 318، 4.10.3، http://jcp.org/en/jsr/detail?id=318
  9. ↑ JSR 318، 4.3.14، 21.4.2، http://jcp.org/en/jsr/detail?id=318
  10. ↑ "سياق الاستمرارية في الأنظمة ذات الحالة" . مؤرشف من الأصل في 16 مارس 2008. تم الاطلاع عليه في 1 يونيو 2016 .
  11. ↑ JSR 318، 4.7، http://jcp.org/en/jsr/detail?id=318
  12. ↑ JSR 318، 4.3.14، http://jcp.org/en/jsr/detail?id=318
  13. ↑ JSR 318، 4.8، http://jcp.org/en/jsr/detail?id=318
  14. ↑ "Singleton EJB" . Openejb.apache.org. مؤرشف من الأصل بتاريخ 24-05-2010 . تم الاطلاع عليه بتاريخ 17-06-2012 .
  15. ↑ JSR 318، 5.1، http://jcp.org/en/jsr/detail?id=318
  16. ↑ JSR 318، 5.7.2، http://jcp.org/en/jsr/detail?id=318
  17. ↑ JSR 318، 5.4.2، http://jcp.org/en/jsr/detail?id=318
  18. ↑ JSR 318، 5.6.2، http://jcp.org/en/jsr/detail?id=318
  19. ↑ تطوير Quartz MDB (29 أبريل 2009). "تطوير Quartz MDB" . Mastertheboss.com . تاريخ الاسترجاع: 17 يونيو 2012 .
  20. ↑ JSR 318، الفصل 17، http://jcp.org/en/jsr/detail?id=318
  21. ↑ "تعليقات الأمان" . Openejb.apache.org . تم الاطلاع عليه بتاريخ 17-06-2012 .
  22. ↑ JSR 318، الفصل 13، http://jcp.org/en/jsr/detail?id=318
  23. ↑ JSR 318، 13.6.2، http://jcp.org/en/jsr/detail?id=318
  24. ↑ "تعليقات المعاملات" . Openejb.apache.org . تم الاسترجاع في 17-06-2012 .
  25. ↑ JSR 318، 13.3.6، http://jcp.org/en/jsr/detail?id=318
  26. ↑ JSR 318، 4.4، http://jcp.org/en/jsr/detail?id=318
  27. ↑ "أسماء JNDI العالمية المحمولة (MaheshKannan)" . Blogs.oracle.com. مؤرشف من الأصل بتاريخ 20-06-2011 . تم الاطلاع عليه بتاريخ 17-06-2012 .
  28. ↑ "أسماء JNDI العالمية المحمولة (مدونة كين ساكس)" . Blogs.oracle.com. مؤرشف من الأصل بتاريخ 29-12-2011 . تم الاطلاع عليه بتاريخ 17-06-2012 .
  29. ↑ JSR 318، الفصل 15، http://jcp.org/en/jsr/detail?id=318
  30. ↑ JSR 318، 2.6، http://jcp.org/en/jsr/detail?id=318
  31. ↑ JSR 318، 3.2.4، http://jcp.org/en/jsr/detail?id=318
  32. ↑ JSR 318، 4.3.6، http://jcp.org/en/jsr/detail?id=318
  33. ↑ JSR 318، 2.7، http://jcp.org/en/jsr/detail?id=318
  34. ↑ JSR 311، الفصل 6.2، http://jcp.org/en/jsr/detail?id=311
  35. ↑ "التواصل بين JBoss AS 5 و JBoss AS 6 | JBoss AS | مجتمع JBoss" . Community.jboss.org . تاريخ الاسترجاع: 17-06-2012 .
  36. ↑ "ملف تعريف ويب Resin Java EE 6 - Resin 3.0" . Wiki.caucho.com. 12 فبراير 2010. مؤرشف من الأصل في 23 مارس 2012. تم الاطلاع عليه في 17 يونيو 2012 .
  37. ↑ JSR 318، 21.1 EJB 3.1 Lite، http://jcp.org/en/jsr/detail?id=318
  38. ↑ JSR 318، الجدول 27 - المحتويات المطلوبة لواجهة برمجة تطبيقات EJB 3.1 Lite وEJB 3.1 الكاملة، http://jcp.org/en/jsr/detail?id=318
  39. ↑ "ما الجديد في هذا الإصدار" . جاكرتا إنتربرايز بينز، الميزات الأساسية . جاكرتا إنتربرايز بينز 4.0. جاكرتا إي إي . 5 نوفمبر 2020. تم الاطلاع عليه بتاريخ 5 ديسمبر 2020 .
  40. ↑ "ما الجديد في EJB 3.2 ؟ - جافا EE 7 تتقدم بخطى ثابتة! (أرون غوبتا، ما زال الطريق طويلاً...)" . تم الاطلاع عليه في 1 يونيو 2016 . 
  41. ↑ "إذا لم تكن تعلم ما سيأتي في EJB 3.2... (مدونة مارينا فاتكينا)" . مؤرشف من الأصل في 4 مارس 2016. تم الاطلاع عليه في 1 يونيو 2016 .
  42. ↑ "تقرير رحلة مؤتمر JavaOne: تقنية Enterprise JavaBeans: تطوير ونشر تطبيقات الأعمال كمكونات" . Alephnaught.com . تاريخ الاسترجاع: 17-06-2012 .