كيفية بناء نظام Java EE؟كيف يتم تعريف مصطلح التطبيق وبالتالي محتوى EAR؟

Question

أنا بصدد تصميم نظام بناء وهيكل دليل لنظام برمجي كبير تم تطويره باستخدام Java EE 5.سيتم تنفيذ نظام البناء باستخدام النمل.

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

لقد قرأت تعريفات وأمثلة عامة، لكنني ما زلت في حيرة من أمري بشأن مصطلحات Java EE:

• ما هو تطبيق Java EE؟وبالتالي، ما هو محتوى ملف EAR؟
• ما هو مشروع Java EE؟(يتم استخدام المصطلح بواسطة Netbeans وكذلك في اتفاقيات مشروع إرشادات Java Blueprints لتطبيقات المؤسسات)

هل يجب أن أضع كل ملفات EJB وWAR-module-package-files في EAR واحدة، بحيث تحتوي هذه EAR الفردية على نظامنا الكامل؟

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

أو هل أقوم بتجميع EAR منفصل لكل خدمة، على سبيل المثال.في أغلب الأحيان يحتوي فقط على ملف EJB jar واحد فقط وفي بعض الأحيان يحتوي على EJB وملف WAR؟

أم هل أرفض مفهوم التطبيقات وأقوم فقط بإنشاء ملفات EJB وWAR، بحيث يكون لدي ملف نشر واحد بالضبط لكل مجموعة خادم تطبيق؟

أعتقد أن سؤالي الرئيسي هو:ما هي مميزات تعبئة ملفات EAR؟

كما أرى في الوقت الحالي، هناك حاجة فقط إلى ملفات EAR-EJB وWAR بالإضافة إلى مفهوم المشروع الفرعي المتداخل في نظام بناء النمل وبنية الدليل لمصدرنا؟

يحرر:شكرا جزيلا للإجابات!يبدو لي أن التطبيق المعبأ في الأذن هو نظام فرعي ذري إلى حد ما.لذا أعتقد أنه سيكون لدي بنية مشروع فرعي متداخلة (منطقية فقط، ومرئية فقط لنظام البناء وفي بنية الدليل للمصدر) وكمية كبيرة إلى حد ما من EARs، كل واحدة منها تحتوي في الغالب على ejb-jar واحد فقط و/أو وحدة الحرب وتنفيذ خدمة واحدة (والتي يتم نشرها على مجموعة خادم تطبيق واحد).

Answer 1

أعتقد أن ما تقرر وضعه في كل EAR يخضع لقضايا تنظيمية وفنية.

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

لن تقوم عادةً بنشر وحدة برمجية أصغر من EAR.يمكن أن تكون كل EAR مكتفية ذاتيًا بشكل أو بآخر.عادةً ما أترك محتوى هذه العناصر يعكس ما تعتقده المنظمة المالكة كتطبيقات أو أنظمة فرعية.يمكنك عادةً تجميع نفس المكونات في وحدات EAR متعددة.

Answer 2

الكثير من الأسئلة هنا.

مشاريع Java EE هي إما عمليات نشر EAR أو WAR تستخدم تقنية Java EE.إذا كان لديك WAR مع وصول JSPs وJDBC إلى قاعدة بيانات علائقية، فهذا مشروع Java EE.كان القصد الأصلي هو أن ملفات EAR كانت "مؤسسية"، وهذا يعني وحدات JBs.يحتوي ملف EAR على EJBs وWARs وJARs والانتشيلادا بأكملها.

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

لذا فكر جيدًا في كيفية تقديم خدماتك.إنها ليست إجابة شاملة أو لا شيء، IMO.يجب أن تنظر إلى ما تفعله خدماتك وكيف يمكن استخدامها معًا لتقرر كيفية تعبئتها ونشرها.

Answer 3

تلعب الاعتبارات المنطقية والتنظيمية دورًا.ستحتوي كل EAR على جميع القطع المرتبطة بقدرة معينة.يمكننا دائمًا أن نفترض أن كل EAR ستكون محتواة ذاتيًا ويمكن نشرها على حاوية واحدة أو أكثر.النهج النموذجي الذي اتبعته دائمًا هو أن تحتوي كل EAR على واحد أو أكثر من الجرار والحروب.تحتوي كل حرب أو جرة على بعض المكونات الرئيسية أو مجموعة من المكونات ذات الصلة.يمثل EAR تطبيقًا مؤسسيًا يحتوي على المكونات وتطبيقات الويب الخاصة بالتطبيق.مثال على ذلك هو نظام معالجة الدفع الذي شاركت فيه.يحتوي EAR على كل ما هو مطلوب لتشغيل نظام معالجة الدفع.وشمل ذلك نصف دزينة من الجرار و3 حروب.تمثل كل جرة بعض الوظائف أو التجميع المنطقي للوظائف.تمثل كل حرب تطبيق ويب.مثال على تكوين الجرة:

• جرة للوظائف الأساسية
• جرة ل ejbs
• جرة لقطع الرياضيات المالية المتقدمة لدينا
• جرة لقطع الأمان لدينا الخ.تم تحديد وجود جرارات متعددة من خلال حقيقة أن الأشخاص المختلفين طوروا قطعًا مختلفة لذلك عملوا في مشاريع Eclipse مختلفة وقاموا بدمجها جميعًا حسب الحاجة.لا توجد قواعد صارمة وسريعة، فقط كل ما يناسب فريقك وموقفك.