Vous avez tout à fait raison de penser qu'il y a des synergies ici, nous avons une application web modulaire où l'application elle-même est assemblée automatiquement à partir de composants indépendants (bundles OSGi) où chaque bundle contribue ses propres pages, ressources, css et éventuellement javascript.
Nous n'utilisons pas JSF (Spring MVC ici) donc je ne peux pas commenter sur la complexité supplémentaire de ce framework dans un contexte OSGi.
La plupart des frameworks ou approches là-bas continuent d'adhérer à l'ancienne façon de penser : un fichier WAR représentant votre application web puis de nombreux bundles et services OSGi mais presque aucun ne se préoccupe de la modularisation de l'interface utilisateur elle-même.
Prérequis pour une conception
Avec OSGi, la première question à résoudre est : 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 exécutable OSGi et utiliser son infrastructure pour tout. Alternativement, vous pouvez intégrer un exécutable OSGi dans un serveur d'application traditionnel et ensuite vous devrez réutiliser certaines infrastructures, en particulier vous voudrez utiliser le moteur de servlet de cet serveur d'application.
Notre conception est actuellement basée sur OSGi comme conteneur et nous utilisons le HTTPService offert par OSGi comme notre conteneur de servlet. Nous examinons la possibilité de fournir une sorte de pont transparent entre un conteneur de servlet externe et le HTTPService OSGi mais ce travail est en cours.
Esquisse architecturale d'une application web modulaire Spring MVC + OSGi
Le but n'est pas seulement de servir une application web sur OSGi mais aussi d'appliquer le modèle de composants d'OSGi à l'interface utilisateur web elle-même, pour la rendre composite, réutilisable, dynamique.
Voici les composants du système :
- 1 bundle central qui s'occupe de faire le lien entre Spring MVC et OSGi, il utilise spécifiquement le code de Bernd Kolb pour vous permettre d'enregistrer le DispatcherServlet de Spring avec OSGi en tant que servlet.
- 1 Mapper d'URL personnalisé qui est injecté dans le DispatcherServlet et qui fournit la correspondance des requêtes HTTP entrantes avec le contrôleur correct.
- 1 JSP décorateur basé sur Sitemesh qui définit la mise en page globale du site, ainsi que les bibliothèques CSS et Javascript centrales que nous voulons offrir par défaut.
-
Chaque bundle qui veut contribuer des pages à notre interface utilisateur web doit publier 1 ou plusieurs Contrôleurs en tant que Services OSGi et s'assurer d'enregistrer son propre servlet et ses propres ressources (CSS, JSP, images, etc) avec le HTTPService OSGi. L'enregistrement est fait avec le HTTPService et les méthodes clés sont :
httpService.registerResources() et httpService.registerServlet()
Lorsqu'un bundle contribuant à l'interface utilisateur web s'active et publie ses contrôleurs, ils sont automatiquement récupérés par notre bundle central d'interface utilisateur web et le Mapper d'URL personnalisé mentionné ci-dessus rassemble ces services de contrôleurs et garde une carte à jour des URL vers les instances de contrôleur.
Ensuite, lorsqu'une requête HTTP arrive pour une certaine URL, il trouve le contrôleur associé et envoie la requête là-bas.
Le contrôleur fait son travail puis renvoie toutes les données qui devraient être rendues et le nom de la vue (une JSP dans notre cas). Cette JSP est située dans le bundle du contrôleur et peut être accédée et rendue par le bundle central d'interface utilisateur web exactement parce que nous avons enregistré l'emplacement des ressources avec le HTTPService. Notre résolveur de vue central fusionne ensuite cette JSP avec notre décorateur central Sitemesh et renvoie le HTML résultant au client.
Je sais que c'est assez général mais sans fournir l'implémentation complète, il est difficile d'expliquer pleinement.
Notre principal point d'apprentissage pour cela était de regarder ce que Bernd Kolb a fait avec sa conversion de l'exemple JPetstore en OSGi et d'utiliser ces informations pour concevoir notre propre architecture.
À mon avis, il y a actuellement beaucoup trop de battage médiatique et de concentration pour intégrer OSGi d'une manière ou d'une autre dans des applications basées sur Java EE traditionnelles et très peu de réflexion est mise dans le fait de vraiment exploiter les idiomes d'OSGi et son excellent modèle de composants pour permettre la conception d'applications web à composants.
