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

تطبيق سريع أعقبه نقد

وكانت هذه الرؤية قد قدمت بإقناع من قبل المدافعين عن وحدة جافا للأعمال مثل آي بي إم وصن مايكروسيستمز، وتم تبني وحدة جافا للأعمال سريعا من قبل عدد من الشركات الكبيرة. بأي حال فإن المشكلات سرعان ما طفت على السطح وبدأت سمعة وحدة جافا للأعمال في المعاناة نتيجة لذلك. وقد شعر بعض المطورين بأن واجهات برمجة التطبيق لمقياس وحدة جافا للأعمال كانت أكثر تعقيدا من تلك التي اعتاد على استخدامها المطورون. وكانت وفرة الاستثناءات المختبرة، والواجهات المطلوبة، وتطبيق فئة بين bean class كفئة مجردة أمرا غير معتاد ومناقضة للحدس بالنسبة للعديد من المبرمجين. ومما هو معروف فإن المشكلات التي كان مقياس وحدة جافا للأعمال يحاول تناولها، مثل كائن رسم الخرائط العلائقية والتكامل التبادلي، كانت معقدة. بأي حال فإن العديد من المبرمجين وجدوا واجهات برمجة التطبيقات على أنها صعبة بأقل تقدير، مما أدى إلى تصور واسع النطاق عن أن وحدة جافا للأعمال قد أدخلت تعقيدات دون تقديم مكاسب حقيقية.
إضافة إلى ذلك فقد وجدت الشركات أن استخدام وحدة جافا للأعمال لتغليف منطق الأعمال قد ألحق عقوبة بالأداء. وذلك نظرا لأن الخاصية الأصلية لا تكون متاحة إلا لإحلال طريقة بعيدة من خلال كوربا CORBA (وبروتوكولات أخرى اختيارية)، بالرغم من أن القدر الأكبر من تطبيقات الأعمال لا تتطلب فعليا وظيفية حوسبة التوزيع هذه. وتتناول خاصة وحدة جافا للأعمال هذه المسألة من خلال إضافة مفهوم الواجهات المحلية التي يمكن استدعاءها مباشرة دون أداء العقوبات من خلال التطبيقات التي لم يتم توزيعها على خوادم متعددة. وقد تم إدخالها بصورة أساسية لتناول مشكلات الأداء الموجودة في وحدة جافا للأعمال 1.0.
بأي حال فإن قضية التعقيد استمرت في إعاقة قبول وحدة جافا للأعمال. وبالرغم من أن أدوات المطور المتفوق قد سهلت من تكوين واستخدامات وحدة جافا للأعمال من خلال ميكنة المهام المتكررة، فإن هذه الأدوات لا تسهل بأي حال من الأحوال تعلم كيفية استخدام التكنولوجيا. علاوة على ذلك فإن الحركة المضادة قد نمت بقوة على مستوى القاعدة بين المبرمجين. وكانت المنتجات الرئيسية لهذه الحركة يطلق عليها التكنولوجيات "ذات الوزن الخفيف" (أي مقارنة بوحدة جافا للأعمال) لهايبرنيت Hibernate (للتوكيد وكائن رسم الخرائط العلائقية) وسبرنج فريموورك Spring Framework (والتي قدمت طريقة أقل إطنابا لتشفير منطق الأعمال). وبالرغم من الافتقاد لدعم الشركات الكبيرة، فإن هذه التكنولوجيات نمت جماهيريا وتم تبنيها بشكل أكبر من قبل الشركات التي كانت قد أصيبت بخيبة أمل إزاء وحدة جافا للأعمال.
وكان وحدة جافا للأعمال مدعوما من قبل البرنامج التجريبي جافا بلو برنتز الذي أصدرته جافا بيت ستور التابع لصن. إن استخدام وحدة جافا للأعمال كان مثار جدل وأن مبرمجين نافذين في جافا أي أي مثل رود جونسون قد تبنوا مواقف استجابة إلى جافا بيت ستور التي عملت على إضعاف التوكيد على وحدة جافا للأعمال. وقد أنتجت صن نفسها بديلا يسمى كائنات بيانات جافا. وفيما بعد فإن وحدات جافا للأعمال وأشكال بيانات جافا والعديد من الأفكار الكامنة في هايبرنيت اشتركت في تشكيل وحدة جافا للأعمال 3.0 التي تضمنت في واجهة برمجة تطبيق توكيد جافا وكائنات جافا القديمة المسطحة Plain Old Java Objects (POJOs). وكان وحدة جافا للأعمال 3.0 أقل وزنا مقارنة بوحدة جافا للأعمال 2.0 وقدم اختيارات أكبر للمطورين.

إعادة صياغة وحدة جافا للأعمال

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

مثال

يظهر ما يلي مثالا أساسيا لما يبدو عليه تشفير وحدة جافا للأعمال
@Localpublic interface CustomerServiceLocal {
   void addCustomer(Customer customer);}@Stateless 
public class CustomerService implements CustomerServiceLocal { 
  
  @PersistenceContext 
  private EntityManager entityManager; 
    
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}
ويحدد ما سبق واجهة محلية وتطبيق فئة الخدمة لتوكيد كائن العميل (من خلال كائن رسم الخرائط العلائقية). ويعتني وحدة جافا للأعمال بإدارة المحيط المؤكد، وتكون طريقة العميل المضاف تبادلية وآمنة التشعب من الأساس. وكما ظهر جليا، فإن وحدة جافا للأعمال لا يركز إلا على منطق الأعمال والتوكيد ولا يعرف شيئا عن أي تمثيل خاص.
ويمكن استخدام مثل وحدة جافا للأعمال من قبل فئة ما في شريحة الويب على سبيل المثال كما يلي:
@Named@RequestScopedpublic class CustomerBacking {

   @EJB 
   private CustomerServiceLocal customerService;

   public String addCustomer() {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }}
ويحدد ما سبق أوجه خادم جافا JavaServer Faces (JSF) التي تدعم بين والتي يتم ضخ وحدة جافا للأعمال فيها من خلال وسيلة شرح @EJB. إن طريقة العملاء المضافين addCostumer مرتبطة نمطيا ببعض مكونات واجهة المستخدم UI،مثل الأزرار. وعلى العكس من وحدة جافا للأعمال، فإن دعم بين لا يحتوي على أي منطق أعمال أو كود توكيد، لكنه يرسل مثل هذه الاهتمامات لوحدة جافا للأعمال. ويعرف دعم بين تمثيلا خاصا لا يكون لوحدة جافا للأعمال أية معرفة بها.

الوحدات الموروثة (قليلة الشأن)

كما استخدمت الإصدارات السابقة من وحدة جافا للأعمال نوعا من الوحدات معروف باسم وحدة الكيان Entity Bean. وكانت كائنات موزعة ذات حالة مستمرة. وهي الوحدات التي تكون في حاويتها مدارة لحالة الاستمرار Container-Managed Persistence (CMP)حيث تستخدم الحاوية المدارة باستمرار bean-Managed Persistence (BMP). وقد حلت وحدات الكيان بواجهة برمجة التطبيق لاستمرارية جافا في وحدة جافا للأعمال رقم 3.0، وكذلك في وحدة جافا للأعمال 3.1، إن أسلوب وحدات الكيان في CMP x2 لا تزال متاحة للتوافق بأثر رجعي. وتماما كما هو الحال في وحدة جافا للأعمال 3.1 فإن خاصية JPA كانت منفصلة تماما بخاصيتها نفسها وسوف لا  يركز وحدة جافا للأعمال إلا على "وحدة الجلسة الجوهرية ونماذج مكونات الوحدة القائمة على الرسائل وواجهات برمجة التطبيق لعملاءها").
وقد أقترحت أنواعا أخرى من وحدات الأعمال. على سبيل المثال وحدات أعمال الإعلام (JSR 86)  التي تتناول تكامل كائنات الوسائط الإعلامية في تطبيقات Java EE.

التنفيذ

تم نشر وحدات جافا للأعمال في حاوية وحدة جافا للأعمال داخل خادم التطبيق. وتصف هذه الخاصية كيف تتفاعل وحدة جافا للأعمال مع حاويتها وكيف يتفاعل كود العميل مع حاويتها/وحدة جافا للأعمال معا. إن فئات وحدة جافا للأعمال المستخدمة من قبل التطبيقات متضمنة في حزمة javax.ejb. (إن حزمة javax.ejb هي واجهة تقديم خدمة لا تستخدم إلا من قبل تطبيقات حاوية وحدة جافا للأعمال)
ولا يستعجل عملاء وحدات وحدة جافا للأعمال هذه الوحدات مباشرة من خلال مشغل جافا الجديد، لكنهم بدلا من ذلك عليهم الحصول على إحالة عبر حاوية وحدة جافا للأعمال لتطبيق الوحدة نفسها، ولكن إلى شبكات اتصال المخدم الفرعي الذي يطبق ديناميكيا واجهة أعمال منزلية أو بعيدة يطلبها العميل، أو يطبق ديناميكيا نوعا فرعيا من الوحدة الفعلية. ومن ثم يمكن لشبكات اتصال المخدم الفرعي أن تلقي مباشرة للواجهة أو الوحدة. ومن المعروف أن العميل يجب أن ياخذ "نظرة" على وحدة جافا للأعمال، والواجهة المحلية، والواجهة البعيدة ونوع الوحدة نفسه على التوالي فيما يتعلق بالعرض المحلي والعرض عن بعد والعرض بدون واجهة.
وتعتبر شبكات اتصال المخدم الفرعي هذه مطلوبة من أجل منح حاوية وحدة جافا للأعمال فرصة أن تقدم بشفافية خدمات متقاطعة (مثل AOP) لوحدة ما مثل التبادلات، الأمن، الإدخالات، التصورات المشتركة، والابتعاد، الخ.
على سبيل المثال فإنه يمكن لعميل أن يطرح طريقة ما عبر شبكات اتصال المخدم الفرعي، والتي سوف تبدأ فيما بعد تعاملا بمساعدة حاوية وحدة جافا للأعمال ثم يستدعي طريقة الوحدة الفعلية. وعندما تعود الوحدة الفعلية فإن شبكات اتصال المخدم الفرعي تنهي التبادل (أي من خلال إلزامها أو القيام برد) ويعيد السيطرة مرة أخرى إلى العميل.

الأحداث

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

الأمن

تعتبر حاوية وحدة جافا للأعمال مسئولة عن ضمان أن كود العميل له حقوق ولوج كافية لوحدة جافا للأعمال.

الإصدار النهائي لوحدة جافا للأعمال 3.0 (11 مايو 2006)

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