تطبيقات الويب المعيارية

Question

لقد كنت أبحث في OSGi مؤخرًا وأعتقد أنها تبدو فكرة جيدة حقًا لتطبيقات Java المعيارية.

ومع ذلك، كنت أتساءل كيف سيعمل OSGi في تطبيق ويب، حيث لا يكون لديك تعليمات برمجية فقط تقلق بشأنها - وأيضًا HTML والصور وCSS وما إلى ذلك.

في العمل، نقوم ببناء تطبيق يحتوي على "علامات تبويب" متعددة، حيث تمثل كل علامة تبويب جزءًا من التطبيق.أعتقد أن هذا يمكن أن يستفيد حقًا من اتباع نهج OSGi - لكنني لست متأكدًا حقًا من أفضل طريقة للتعامل مع جميع موارد تطبيقات الويب المعتادة.

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

يحرر:وفق هذا الموضوع, ، يمكن تحميل ملفات faces-config.xml من ملفات JAR - لذلك من الممكن بالفعل تضمين ملفات faces-config.xml متعددة دون تعديل web.xml، بشرط تقسيمها إلى ملفات JAR.

فإن أي اقتراحات موضع تقدير كبير :-)

Answer 1

أنت على حق تمامًا في اعتقادك بوجود أوجه تآزر هنا، فلدينا تطبيق ويب معياري حيث يتم تجميع التطبيق نفسه تلقائيًا من مكونات مستقلة (حزم OSGi) حيث تساهم كل حزمة بصفحاتها ومواردها وCSS وجافا سكريبت اختياريًا.

نحن لا نستخدم JSF (Spring MVC هنا) لذا لا يمكنني التعليق على التعقيد الإضافي لهذا الإطار في سياق OSGi.

لا تزال معظم الأطر أو المناهج الموجودة ملتزمة بطريقة التفكير "القديمة":ملف WAR واحد يمثل تطبيق الويب الخاص بك ثم العديد من حزم وخدمات OSGi ولكن لا شيء تقريبًا يهتم بوحدة واجهة المستخدم الرسومية نفسها.

المتطلبات الأساسية للتصميم

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

يعتمد تصميمنا حاليًا على OSGi كحاوية ونستخدم خدمة HTTP التي تقدمها OSGi كحاوية servlet الخاصة بنا.نحن نتطلع إلى توفير نوع من الجسر الشفاف بين حاوية servlet خارجية وخدمة OSGi HTTPService ولكن هذا العمل مستمر.

رسم معماري لتطبيق الويب المعياري Spring MVC + OSGi

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

وهذه هي المكونات الموجودة في النظام:

• حزمة مركزية واحدة تهتم بربط Spring MVC مع OSGi، وتستخدمها على وجه التحديد كود بيرند كولب للسماح لك بتسجيل Spring DispatcherServlet مع OSGi باعتباره servlet.
• 1 مخطط URL مخصص يتم إدخاله في DispatcherServlet والذي يوفر تعيين طلبات HTTP الواردة إلى وحدة التحكم الصحيحة.
• 1 مصمم ديكور مركزي يعتمد على Sitemesh JSP يحدد التخطيط العام للموقع، بالإضافة إلى مكتبات CSS وJavascript المركزية التي نريد تقديمها كإعدادات افتراضية.

• يجب على كل حزمة ترغب في المساهمة بصفحات في واجهة مستخدم الويب الخاصة بنا أن تنشر وحدة تحكم واحدة أو أكثر كخدمات OSGi وتتأكد من ذلك تسجيل servlet الخاص به والموارد الخاصة به (CSS، JSP، الصور، إلخ) مع خدمة OSGi HTTPService.يتم التسجيل باستخدام HTTPService والطرق الرئيسية هي:

  httpservice.registerResources () و httpservice.registerservlet ()

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

ثم عندما يأتي طلب HTTP لعنوان URL معين، فإنه يجد وحدة التحكم المرتبطة ويرسل الطلب هناك.

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

في معرفة أن هذا مستوى عالٍ إلى حد ما، ولكن بدون توفير التنفيذ الكامل، يصعب شرحه بشكل كامل.

كانت نقطة التعلم الرئيسية لدينا لهذا هي النظر ما فعله بيرند كولب مع مثاله تحويل JPetstore إلى OSGi واستخدام تلك المعلومات لتصميم البنية الخاصة بنا.

يوجد حاليًا الكثير من الضجيج والتركيز على IMHO على جعل OSGi مضمنًا بطريقة ما في التطبيقات التقليدية المستندة إلى Java EE، ولم يتم وضع سوى القليل من التفكير في الاستخدام الفعلي لمصطلحات OSGi ونموذج مكوناته الممتاز للسماح حقًا بتصميم تطبيقات الويب المكونة.

Answer 2

الدفع خادم SpringSource DM - خادم تطبيقات تم تصميمه بالكامل من حيث OSGi ودعم تطبيقات الويب المعيارية.وهي متوفرة في إصدارات مجانية ومفتوحة المصدر وتجارية.

يمكنك البدء بنشر ملف WAR قياسي ثم تقسيم تطبيقك تدريجيًا إلى وحدات OSGi، أو "الحزم" في لغة OSGi.كما قد تتوقع من SpringSource، يتمتع الخادم بدعم ممتاز لإطار عمل Spring ومنتجات محفظة Spring ذات الصلة.

تنصل:أنا أعمل على هذا المنتج.

Answer 3

كن على علم بخادم Spring DM الترخيص.

Answer 4

لقد تم استخدام ريستليت مع OSGi لتحقيق تأثير جيد مع خدمة Http المضمنة (تحت الأغطية هي في الواقع Jetty، ولكن Tomcat متاح أيضًا).

لا تحتاج Restlet إلى الحد الأدنى من احتياجات تكوين XML، وأي تكوين نقوم به موجود في BundleActivator (تسجيل الخدمات الجديدة).

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

يوفر لنا REST عناوين URL لطيفة ونظيفة وذات معنى، وتمثيلات متعددة لنفس البيانات، ويبدو استعارة قابلة للتوسيع (أفعال قليلة، وأسماء كثيرة).

كانت الميزة الإضافية بالنسبة لنا هي الدعم الشامل للتخزين المؤقت، وتحديدًا ETag.

Answer 5

يبدو أن SpringSource يعمل على إطار ويب معياري مثير للاهتمام مبني على أعلى OSGi يسمى شرائح مصدر الربيع.يمكن العثور على مزيد من المعلومات في منشورات المدونة التالية:

• تطبيقات الويب المعيارية مع شرائح SpringSource
• تصميم قابل للتوصيل مع شرائح SpringSource
• شرائح شريط القائمة Screencast

Answer 6

إلقاء نظرة على الراب! http://www.Eclipse.org/rap/

Answer 7

نلقي نظرة على http://www.ztemplates.org وهو بسيط وسهل التعلم.يسمح لك هذا بوضع جميع القوالب ذات الصلة وجافا سكريبت وCSS في وعاء واحد واستخدامها بشفافية.يعني أنك لا تهتم بالإعلان عن جافا سكريبت المطلوبة في صفحتك عند استخدام مكون متوفر، حيث يقوم إطار العمل بذلك نيابةً عنك.

Answer 8

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