Problèmes de compréhension de l'ensemble du système Web OSGi

Question

Je suis un nouveau venu dans l'univers Java et OSGi et j'ai du mal à comprendre le système écologique d'une application Web OSGi.

Pour être plus précis, je suis en ce moment à essayer de comprendre comment toutes les parties du système écologique sont liés les uns aux autres:

• cadre OSGi (par exemple Apache Felix, Equinox, Knoplerfish)
• OSGi Runtime (par exemple Spring DM Server, Pax Runner, Apache Karaf)
• Web Extender (par exemple Pax Web Extender, Spring Web Extender)
• conteneur Web (par exemple Apache Tomcat, Jetty)

Pour vous donner une représentation visuelle de ma compréhension réelle de leur relation vérifier cette image:

alt text http://img253.imageshack.us/img253/1631/osgiwebenvironmentschem.png

Pour autant que je sais que le cadre OSGi est une implémentation de la spécification OSGi. Le runtime est une distribution qui ajoute des fonctionnalités supplémentaires à la spécification OSGi comme la journalisation par exemple. Comme il semble y avoir des différences dans le mécanisme de classpath d'OSGi et des conteneurs Web comme Tomcat, vous avez besoin d'un traducteur. Cette partie est gérée par le "Web Extender".

Pourriez-vous clarifier tout cela pour moi? Est-ce que je comprends tout correct?

Answer 1

OSGi est une norme en termes d'API et de conditionnement pour les modules logiciels en interaction. Ceci est similaire aux autres normes API telles que JPA ou Java EE.

Une exécution OSGi est un serveur qui suit la norme OSGi, il s'agit d'une implémentation de la norme. Vous mentionnez quelques uns communs: Knopflerfish, Eqinox. Ceux-ci vous permettent d'exécuter des bundles OSGi. Un conteneur Web fait généralement référence à une implémentation des parties Web-spécifiques de Java EE (servlets). La norme de servlet définit également une API et un packaging, tout comme OSGi, seulement différents.

Vous avez besoin d'un serveur pour exécuter vos applications Web Java EE. Vous empaquetez votre application en tant que Java Web Archive (WAR) et demandez à votre serveur d'applications de la démarrer. Comme vous l'avez mentionné, il existe plusieurs serveurs comme Tomcat, Jetty, mais aussi de plus gros serveurs qui couvrent des parties plus importantes de la norme Java EE, comme Glassfish et JBoss. Un extenseur Web tente d'unifier la norme de servlet avec OSGi. En ajoutant des données spécifiques à OSGi à votre fichier WAR déjà intégré, le fichier WAR sera automatiquement analysé et démarré par votre environnement d'exécution OSGi. Vos servlets WAR seront publiés sur le service http OSGi par l'extension Web. Avec un extendeur Web, vous pouvez exécuter les applications OSGi standard ainsi que les fichiers WAR en utilisant uniquement un environnement d'exécution OSGi, sans avoir besoin d'un serveur compatible Java EE tel que Tomcat.

Answer 2

Jens,

Comme je l'ai une certaine expérience avec OSGi, je voudrais vraiment pas vous suggère de commencer avec OSGi plaine.

Commencez par Eclipse RCP (Rich Client Platform) à la place.

Vous obtenez non seulement une exécution OSGi, mais un IDE intégré complet si vous download Eclipse IDE for RCP and RAP Developers edition here.

Heureusement pour nous tous, vous pouvez obtenir le livre Eclipse Rich Client Platform (2nd Edition) qui a été récemment publié il y a seulement quelques mois et contient les informations mises à jour/Guide sur Eclipse RCP. OSGi est les blocs de construction fondamentaux d'Eclipse RCP, mais OSGi à lui seul est confus et ennuyeux (au moins pour les démarreurs)

Se mettre au courant sur Eclipse RCP est beaucoup plus facile et agréable, vous pouvez construire une application "do-something" fonctionnelle en quelques heures. Avec OSGi, vous auriez déjà de la chance si vous pouviez vous débarrasser des exceptions ClassNotFound dans les premiers jours. Après un certain temps avec Eclipse RCP, "convertissez" votre application en Eclipse RAP pour l'exécuter en tant qu'application Web sur un conteneur de servlets Java. Voyez si vous l'aimez, même si vous n'avez pas ... à ce moment vous auriez déjà compris les concepts OSGi & pratiques que votre navigation vers "plaine OSGi" serait un peu plus lisse que si vous aviez commencé à partir de zéro.

Bonne chance Jens!

P.S. J'écris aussi sur ce sujet sur my Java EE blog, mais pas toujours spécifiquement sur OSGi.