أوصى جافين كينج [1]، والد Hibernate، المطورين بالترقية إلى منصة Java EE 6، وأشار إلى أن الإحجام الحالي عن الترقية لا أساس له من الصحة.
بعد إصدار Java EE 6، رأيت الكثير من المقاومة للترقية إلى النظام الأساسي الجديد. يتم إثارة معظم هذه الاعتراضات من قبل مستخدمي Tomcat/Jetty وبعض الأطر مفتوحة المصدر (مثل Hibernate وSpring).
بالطبع، هناك العديد من الفوائد لاختيار التكنولوجيا غير القياسية ومفتوحة المصدر. بالإضافة إلى ذلك، في EE 6، يمكنك استخدام أطر العمل مفتوحة المصدر التي تهتم بها. يمكن لـ Servlet 3 وCDI دمج أطر عمل الطرف الثالث بسلاسة. لذلك ليس هناك سبب لعدم استخدام EE 6. ومع ذلك رأيت من يقول:
الترقية إلى خادم تطبيق EE أمر صعب
يبدو أن هذه مسألة سياسية بالنسبة لمنظمة معينة وليست مشكلة فنية فعلية. بالطبع، تعد ترقية خادم مثل GlassFish أو JBoss مهمة تافهة للغاية. (إن ترقية أطر عمل الطرف الثالث أكثر إيلامًا.) لدى بعض المؤسسات عملية ثقيلة جدًا لترقية الخوادم، ولكن ليس كثيرًا لترقية أطر العمل التي تعمل داخل الخوادم. لذلك، من الأسهل على فريق التطوير ترقية أطر عمل الطرف الثالث.
أعتقد أن تطوير عملية أكثر إقناعًا وأفضل هو الشيء الأكثر أهمية، بدلاً من التخلي عن Java EE. هناك العديد من المخاطر المرتبطة بتشغيل تطبيقك على منصة خادم قديمة، ويجب ألا تشجع العملية على مثل هذه الممارسات.
ولكن من الناحية العملية، يخطط الجميع تقريبًا للترقية إلى Servlet 3 في المستقبل القريب. سواء كنت تستخدم Tomcat أو Jetty أو JBoss أو GlassFish أو الراتنج أو WebLogic أو Oracle أو WebSphere، فهذا يعني ترقية الخادم. هذه فرصة رائعة للترقية إلى ملف تعريف الويب EE 6، الوقت الذهبي.
خادم تطبيق EE كبير جدًا
الاعتراض هو أن خادم EE يحتوي على العديد من الميزات غير المتوفرة (حاليًا). تتضمن حجج المعارضين عادةً مناقشة حجم حزمة الجرة ومساحة القرص التي يشغلها محرك Servlet + إطار عمل الطرف الثالث وخادم تطبيقات EE. والحقيقة أن هذه الحجة فيها إشكال:
يعد استخدام القرص ومساحة القرص التي تمت مناقشتها أمرًا تافهًا في الواقع عند قياسه بالدولار، وحزمة حرب التطبيقات أكثر أهمية بكثير من حجم حزمة تثبيت الخادم. يحتوي الخادم في الواقع على العديد من الوظائف لتقليل حجم الحرب.
بالإضافة إلى ذلك، أعتقد أن الشيء الأكثر إقناعًا هو أن ملف تعريف الويب Java EE 6 ليس ضخمًا على الإطلاق. بمجرد طرح خوادم ملفات تعريف الويب المعتمدة في السوق، يمكننا إيجاد توازن بين خوادم تطبيقات EE الكبيرة وحاويات Servlet الصغيرة.
J2EE وEJB2 سيئان!
مع عملية توحيد JCP، لم تعد هذه المشكلة موجودة فعليًا:
1. لقد مرت 8 سنوات منذ ظهور EJB2! هل لا يزال خيارك الأفضل؟
2. تم دمج المواصفات الجيدة من خلال التقييس المستمر لـ JCP، ويمكن استخدام بعضها بثقة كبيرة. ومع ذلك، فإن JCP ليس ناجحًا بنسبة 100% في التقييس.
3. كل من يعمل على منصة EE 6 يكره EJB2 وJ2EE. ولهذا السبب ينضم الأشخاص باستمرار إلى برنامج JCP للمساعدة في حل هذه المشكلات. على سبيل المثال، مؤسس Hibernate ومؤلف هذا المقال. هل تريد حقًا أن تعلمه درسًا حول EJB2؟ :-)
4. جميع الأشخاص الذين يعملون في Entity Beans تقريبًا متقاعدون الآن!
في الواقع، يعد ملف تعريف الويب Java EE 6 كافيًا. إذا لم تجرب Java EE 6 بنفسك، فلن تشعر حقًا بفوائد EE6 في التطوير.
تعد إمكانية نقل خادم التطبيقات أمرًا غامضًا!
حقًا؟ نرى العديد من الأشخاص يقومون بتقسيم تطبيقاتهم ونشرها على خوادم تطبيقات مختلفة؟ أوه، لقد رأيت أن هذا يعني تطبيقًا لا تشوبه شائبة بنسبة 100%، 0-تغيير النقل، وهو المثل الأفلاطوني لقابلية النقل. أنا أفهم الضعف بالنسبة للحقيقة المطلقة والمثل الأفلاطونية، ولكن دعونا ننظر إلى الأمثلة أولا.
إليك وجهة نظر نموذجية جدًا لمشكلة قابلية النقل:
9% من الكود، و85% من البيانات التعريفية الخارجية متوافقة تمامًا مع منصات الخوادم المختلفة، ويمكن تقسيم 1% و15% المتبقية بشكل مناسب
0% كود، 80% بيانات وصفية خارجية مرتبطة ببنية حاوية غير قياسية ذات بائع واحد
بينما كنت أقسم هذه النقاط، أردت فجأة تغيير موضوع هذا القسم من أن قابلية نقل خادم التطبيق غامضة جدًا لدرجة أنني لا أهتم على الإطلاق بإمكانية نقل الحاوية. تؤكد فكرة تغيير السمة أن مشكلة قابلية نقل الخادم حقيقية وأنها ستكون مفيدة جدًا للعديد من المؤسسات.
لقد أردت دائمًا رؤية مراجعات حقيقية لـ EE 6 من المشرفين الفنيين غير التابعين لـ EE 6. بعض الحجج المذكورة أعلاه لا تأتي من العالم الحقيقي، لذلك من الصعب إثارة المناقشات حول القضايا التقنية الفعلية لتطوير التطبيقات على منصة EE. يبدو أن الجولة الأخيرة من مواصفات برنامج خلق فرص العمل قد تركت المعسكر المناهض للكهرباء (مؤقتًا؟)، ولكنها تفتقر إلى الدعم الواقعي للنجاح.
ملاحظة المحرر:
[1] جافين كينغ: مؤسس Hibernate، عضو لجنة خبراء EJB3، أحد الأعضاء الأساسيين في JBoss، قائد إطار عمل Seam، قائد مواصفات JSR-299 (CDI)، ومؤلف كتاب "Hibernate in Action" .
المصدر: يجب عليك الترقية إلى Java EE 6