Applications web modulaires

StackOverflow https://stackoverflow.com/questions/126073

Question

J'ai récemment consulté OSGi et je pense que cela semble être une très bonne idée pour applications Java modulaires.

Cependant, je me demandais comment OSGi fonctionnerait dans une application Web, où vous n'avez pas seulement à vous soucier du code, mais également du HTML, des images, des CSS, etc.

Au travail, nous construisons une application qui comporte plusieurs "onglets", chaque onglet constituant une partie de l'application. Je pense que l’approche OSGi pourrait nous être très bénéfique. Cependant, je ne sais vraiment pas quel serait le meilleur moyen de gérer toutes les ressources habituelles des applications Web.

Je ne suis pas sûr que cela fasse une différence, mais nous utilisons JSF et IceFaces (qui ajoute une autre couche de problèmes parce que vous avez des règles de navigation et que vous devez spécifier tous les fichiers de configuration de visages dans votre web.xml ... doh!)

Modifier: selon les fils , les fichiers faces-config.xml peuvent être chargé à partir de fichiers JAR - il est donc possible d'inclure plusieurs fichiers faces-config.xml sans modifier web.xml, à condition que vous vous sépariez en fichiers JAR.

Toute suggestion serait grandement appréciée: -)

Était-ce utile?

La solution

Vous avez vraiment raison de penser qu’il existe des synergies ici. Nous avons une application Web modulaire dans laquelle l’application elle-même est assemblée automatiquement à partir de composants indépendants (ensembles OSGi) où chaque ensemble contribue à ses propres pages, ressources, CSS et éventuellement à javascript.

Nous n'utilisons pas JSF (Spring MVC here), je ne peux donc pas commenter la complexité supplémentaire de ce cadre dans un contexte OSGi.

La plupart des cadres ou des approches existants adhèrent toujours à "l'ancien". façon de penser: un fichier WAR représentant votre application Web, puis de nombreux services et offres OSGi, mais presque aucun ne concerne la modularisation de l'interface graphique elle-même.

Conditions préalables pour une conception

Avec OSGi, la première question à résoudre est la suivante: quel est votre scénario de déploiement et qui est le conteneur principal? Ce que je veux dire, c'est que vous pouvez déployer votre application sur un environnement d'exécution OSGi et utiliser son infrastructure pour tout. Vous pouvez également intégrer un environnement d'exécution OSGi dans un serveur d'applications traditionnel. Vous devrez ensuite réutiliser certaines infrastructures, notamment le moteur de servlet d'AppServer.

Notre conception est actuellement basée sur OSGi en tant que conteneur et nous utilisons le service HTTPService proposé par OSGi en tant que conteneur de servlet. Nous envisageons de créer une sorte de pont transparent entre un conteneur de servlets externe et OSGi HTTPService, mais ce travail est en cours.

Esquisse architecturale d'une application Web modulaire Spring MVC + OSGi

L'objectif n'est donc pas uniquement de servir une application Web sur OSGi, mais également d'appliquer le modèle de composant d'OSGi à l'interface Web elle-même, afin de la rendre composable, réutilisable et dynamique.

Ce sont les composants du système:

  • 1 ensemble central chargé de relier Spring MVC avec OSGi, plus précisément, il utilise code Bernd Kolb pour vous permettre d’enregistrer le Spring DispatcherServlet avec OSGi en tant que servlet.
  • 1 mappeur d'URL personnalisé injecté dans DispatcherServlet et fournissant le mappage des demandes HTTP entrantes au contrôleur approprié.
  • 1 JSP de décorateur central basé sur Sitemesh qui définit la présentation globale du site, ainsi que les bibliothèques CSS et Javascript centrales que nous voulons offrir par défaut.

  • Chaque groupe souhaitant contribuer des pages à notre interface Web doit publier un ou plusieurs contrôleurs en tant que services OSGi et veiller à enregistrer son propre servlet et ses propres ressources (CSS, JSP, images, etc.). ) avec OSGi HTTPService. L’enregistrement s’effectue avec HTTPService et les méthodes principales sont:

    httpService.registerResources () et httpService.registerServlet ()

Lorsqu'un ensemble contributeur Web active et publie ses contrôleurs, ils sont automatiquement récupérés par notre ensemble interface utilisateur Web central et le mappeur d'URL personnalisé susmentionné rassemble ces services de contrôleur et conserve une carte à jour des URL des instances de contrôleur.

Ensuite, lorsqu'une requête HTTP arrive pour une URL donnée, il trouve le contrôleur associé et y envoie la requête.

Le contrôleur fait son travail, puis renvoie toutes les données qui doivent être rendues et sous le nom de la vue (un fichier JSP dans notre cas). Cette JSP est située dans le bundle du contrôleur et peut être consultée et rendue par le bundle de l'interface Web centrale exactement parce que nous avons enregistré l'emplacement de la ressource auprès de HTTPService. Notre résolveur de vues central fusionne ensuite ce fichier JSP avec notre décorateur central Sitemesh et envoie le code HTML résultant au client.

En fait, il s’agit d’un niveau plutôt élevé, mais il est difficile de donner une explication complète sans une mise en œuvre complète.

Nous avons surtout appris à regarder ce que Bernd Kolb a fait avec son exemple de conversion de JPetstore en OSGi et d’utiliser ces informations pour concevoir notre propre architecture.

À mon humble avis, il y a actuellement trop de battage médiatique et de focalisation sur l'intégration d'OSGi dans des applications traditionnelles basées sur Java EE et très peu de réflexion sur l'utilisation des idiomes OSGi et de son excellent modèle de composants pour réellement permettre la conception de sites Web applications.

Autres conseils

Découvrez le serveur SpringSource dm - un serveur d'applications entièrement construit en termes d'OSGi et prenant en charge le Web modulaire. applications. Il est disponible en versions gratuite, open source et commerciale.

Vous pouvez commencer par déployer un fichier WAR standard, puis diviser progressivement votre application en modules OSGi ou "ensembles" dans OSGi-speak. Comme on pouvait s'y attendre de SpringSource, le serveur offre une excellente prise en charge du framework Spring et des produits de portefeuille Spring associés.

Avertissement: je travaille sur ce produit.

Tenez compte du licence du serveur Spring DM.

Nous utilisons Restlet avec OSGi à bon escient avec un service HTTP intégré (sous les couvertures). c'est en fait Jetty, mais tomcat est aussi disponible).

Restlet a de zéro à un minimum de configuration XML, et toute configuration que nous faisons est dans BundleActivator (enregistrement de nouveaux services).

Lors de la création de la page, nous ne faisons que traiter les implémentations de services appropriées afin de générer le style de décorateur en sortie. Les nouveaux ensembles qui sont branchés ajouteront de nouvelles décorations de page / widgets lors de leur prochain rendu.

REST nous donne de jolies URL propres et significatives, de multiples représentations des mêmes données et semble être une métaphore extensible (quelques verbes, plusieurs noms).

Une fonctionnalité supplémentaire pour nous a été la prise en charge étendue de la mise en cache, en particulier de l’ETag.

SpringSource semble travailler sur une infrastructure Web modulaire intéressante construite sur OSGi, appelée tranches SpringSource . Plus d'informations peuvent être trouvées dans les articles de blog suivants:

Jetez un coup d’œil à http://www.ztemplates.org , qui est simple et facile à apprendre. Celui-ci vous permet de mettre tous les modèles associés, javascript et css dans un seul fichier jar et de les utiliser de manière transparente. Cela signifie que vous n'avez même pas à vous soucier de déclarer le javascript nécessaire dans votre page lorsque vous utilisez un composant fourni, comme le fait le framework pour vous.

Ensemble intéressant de messages. J'ai une application Web personnalisée pour chaque client. Chaque client reçoit un ensemble de composants de base et des composants supplémentaires en fonction de ce qu'il a souscrit. Pour chaque version, nous devons «assembler» le bon ensemble de services et appliquer la configuration de menu correcte (nous utilisons le menu struts) en fonction du client, ce qui est fastidieux pour le moins. Fondamentalement, c'est la même base de code, mais nous personnalisons simplement la navigation pour afficher ou masquer certaines pages. Ce n’est évidemment pas l’idéal et nous voudrions utiliser OSGi pour intégrer des services. Bien que je puisse voir comment cela est fait pour les API de service et comprendre en quelque sorte comment des ressources telles que CSS, les scripts java et les contrôleurs (nous utilisons Spring MVC) pourraient également être regroupées, comment feriez-vous pour traiter des problèmes "transversaux" tels que la navigation dans les pages et flux de travail général, en particulier dans le cas où vous souhaitez déployer de manière dynamique un nouveau service et que vous devez ajouter la navigation à ce service. Il peut également y avoir d'autres préoccupations «transversales», telles que des services qui couvrent d'autres services. Merci, Declan.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top