Thématiques principales

mercredi 30 janvier 2019

OSGI : les frameworks

Nous avons vu le fonctionnement de OSGI dans ses principes généraux et un peu plus dans le détails sur les mécanismes qu’il met en oeuvre pour l'exécution des bundles, des services et de leur interconnexion. Dans cet article, un peu plus court j'espère, nous allons un peu plus nous intéresser à ses implémentations [osgi-impl], leur fonctionnalité et contenu et leur intégration dans les outils JEE standard.

Implémentation

Les implémentations du framework OSGI ne sont pas légion, alors bien sur il existe une implémentation de référence fourni par l’OSGI Alliance mais il est bien précisé que celle ci n’est à utiliser qu’à titre d’exemple et ne pourrait être exploité en production car non optimisé. [OSGI-impl-ref]

Heureusement, grâce à son “grand âge”, OSGI a su intéresser des projets qui ont porté quelques implémentations associé à des versions plus ou moins divers d’OSGI. On peut ainsi en note 4 principales.

knoplerfish

Nous avons avec [knopflerfish] une implémentation mature associé à la version R6 de la norme OSGI (la R7 étant en cour de dev) .

Knoplerfish est une implémentation open source qui a la particularité d'être proposé avec un SDK. Cependant on notera que ce SDK est loin d’etre tres “intuitif” à l’utilisation sachant que les builds sont gérés ici par ant et non un maven ou un gradle.

Concierge

Nous ne nous attarderons pas beaucoup sur cette implémentation [concierge], [eclipse-concierge]. Ce qu’il faut savoir pour l’essentiel est qu’elle est orienté logiciel embarqué pour la domotique, la sécurité et l’internet des objets.

Cette implémentation est basé sur la version R5 de OSGI et se veut minimaliste et portable au maximum.

Equinox

Equinox [equinox] est le framework OSGI surement le plus utilisé. Il s’agit ici de l'implémentation fournir par la fondation eclipse et s’est intégré très tôt comme runtime dans le framework Eclipse. Assez peu évolué (il faut l'avouer puisque il n'implémente que la version RC4 de OSGI) Il a l'avantage d'être le seul framework (à ma connaissance) certifié par l'OSGI alliance.

Il n'est toutefois pas adapté pour une utilisation dans le domaine de l'électronique contrairement à concierge.

La fondation Eclipse fournit également un repository avec des bundles de tierce partie très intéressants. La compréhension d’equinox est à mon sens un incontournable pour comprendre intimement le fonctionnement de l’IDE eclipse et y développer ses propres outils.

À titre personnel, ayant implémenté un conteneur applicatif léger basé sur OSGI, je me suis appuyé sur cette implémentation, mais nous reviendrons sur ce point.

Felix (anciennement OSCAR)

Felix [felix] qui portait le nom d’OSCAR [oscar] est une implémentation presque historique de OSGI (réalisé par Object Web). Implémentant la version OSGi R7, son développement est supporté aujourd’hui par la fondation Apache.

Felix est aujourd’hui une implémentation majeur car c’est celle que l’on retrouve majoritairement dans les conteneurs d’applications comme Karaf.

On s'intéresse à félix pour explorer dans un article futur le fonctionnement du cycle de vie des bundles et la manière de construire un bundle selon les différentes approches élaborées au fil des évolutions de la spécifications (classe -> xml -> annotation [felix-tuto])

On notera aussi que la documentation de felix est parmis les framework implémentant OSGI, l’une des plus accessible [felix-pres-doc]

Frameworks et extensions

Par delà les implémentations de la norme, certains frameworks ont proposé des extensions xml afin de faciliter la construction des architectures modulaire à base OSGI et ainsi diminuer la charge de code à écrire.

L’approche se voulant assez proche que les systèmes d’injection de dépendances comme celle de Spring, on trouvera:

  • Virgo [VIRGO] (issu de SpringDM [SpringDM-1], [SpringDM-2], [SpringDM-3])
  • BluePrint [blue-print], [blue-print-2], [blue-print-3]

L'intérêt de l’approche est clairement de simplifier l’approche de construction des bundles et de faciliter leur mise en relation via les services. Cependant, avec cette approche, les objets produit par les bundles et les services seront alors de nouveau relié de façon statique et dépendant du démarrage du bundle.

De plus ces extension ont la particularité d’ajouter des registres spécifiques aux modèles d’injections, ajoutant au passage donc des mécanismes ralentissant les mécanismes de chargement des bundles et leur mise à jour. De plus on notera que la compatibilité entre les registres entre autre celui du framework OSGI et celui de l’extension ne communique pas toujours de façon optimal (ainsi, autant si la consommation de service OSGI du framework par le système d’extension pose assez peu de problèmes, l’inverse n’est pas forcément vrai et implique parfois des problèmes de synchronicité.

À noter que ce paragraphe précédent est issu de mon expérience avec SpringDM et demande à être confirmé pour les autres systèmes d’extension.

Enfin au delà de ce genre de problématique on notera que si nous n’avons pas encore parler de comment tester efficacement les services des bundles, l’utilisation de bundles de types Mock exploitant la technologie des extensions facilite grandement leur mise en oeuvre. Ainsi le mock portera une description xml des services dont il aura en le test et ces services seront injecté dans des contextes de test permettant de les évaluer.

Le prochain article sur OSGI dont l’objet est de présenter un exemple d’utilisation proposera une utilisation des extensions.

Serveurs d’applications


Un peu partout

Nous l’avons dit, OSGI est partout dans les IDE comme eclipse avec le framework Equinox [equinox] qui sert de base à la construction des applications eclipse RPC [eclipse-RPC] mais aussi dans les serveurs d’applications.

De manière non exhaustive, on notera par exemple que la plupart des serveurs d’application JEE classique intègre un moteur OSGI soit sur la base d’un implémentation interne où par l'intégration d’un framework standard.

Ainsi, par exemple nous avons

  • JBoss et son implémentation nommé bosgi en version 2.5 à priori intégrant une version OSGI en R5 mais ne semble plus maintenu [jbosgi]
  • Glassfish [glass-osgi] qui integre l'implémentation du framework OSGI felix en R4
  • Weblogic [weblo-osgi] qui étant très proche de glassfish integre lui aussi le framework OSGI felix.
  • Karaf qui comme nous allons le voir plus en détail dans le chapitre suivant est un server d’application reposant au choix sur felix où equinox et qui est exclusivement orienté bundle mais avec un packaging intégrant de nombreuses fonctionnalitées.

karaf

Comme nous venons de le dire, Karaf [karaf-latest] est un conteneur applicatif exclusivement orienté bundle.

La force de Karaf, issue directement des capacités de modularité de OSGI est d'être un conteneur applicatif hyper customisable et adaptable.

Du coup en toute logique, de nombreuse déclinaison direct et indirect de Karaf existe. on notera les 5 principales:

  • Karaf-container [karaf-latest], il s’agit de la base initiale de karaf avec l’essentiel pour faire tourner un serveur OSGI et le manipuler de manière standard.
  • Service Mix [service-mix], est un karaf customiser avec des composant supplémentaire permettant la mise en oeuvre de flux synchrone et asynchrone (JMS et WebServices) et les mécanisme de base à la constitution d’une couche base de données avec (JPA et JTA), tout ca pour les nostalgiques de JEE.
  • Karaf-Celar [karaf-celar] est un sous-projet Karaf dédié à la gestion d’un cluster de server karaf.
  • Karaf-Cave [karaf-cave] est aussi un sous-projet de gestion d’artifacts et de bundles en vue de simplifier la mise à disposition de bundle à des instances karaf
  • karaf-decanter [karaf-decanter] est enfin un autre sous projet karaf dédié à la gestion de l'agrégation d’information de monitoring de système et embarque une base elasticsearch.

Karaf est donc ce que l’on pourrait aujourd’hui considérer comme ce qui se fait de plus abouti en matière d’utilisation de la plateforme OSGI. Complète, polyvalente et adaptable, il sera toujours possible de la réduire à minima pour optimiser la consommation mémoire ou d'ajouter dynamiquement des bundles dédiés au debug afin de suivre plus finement son exécution et y corriger à chaud le fonctionnement.

Conclusion

Nous voilà au bout du tour d’horizon des implémentations et des conteneurs utilisant OSGI. En fait on en retiendra que OSGI est un peu partout, dans les IDE, dans l’Iot, dans les gros serveurs d’applications mais aussi dans des spécifiques où dans des entierement dédié au framework, il n’y a que l’embarra du choix!

Il est pourtant dommage que cette technologie soit si peu connu car elle apporte par sa modularité des possibilités que ne permettent pas les conteneurs courants comme le chargement où la mise à jour à chaud de composant applicatifs.

Ainsi avec l’utilisation de karaf, on à sous la main un conteneur applicatif simple et efficace sans excès de technologie qui se pose bien dans la logique de construction des applications conteneurisé avec docker que l’on trouve de plus en plus aujourd’hui.

Nous n’avons pas parlé du pourquoi je connais OSGI, mais en fait cela va faire presque 10 ans que je connais et utilise ce framework grâce à ma thèse qui m'a poussé à utiliser equinox et qui aujourd’hui est la base d’un framework que j’ai conçu moi-même…. mais nous y reviendrons.

Enfin promis le prochain article entrera plus dans le vif du sujet avec des exemples concrets d’utilisation, de constructions et de configuration.

Références

Publié par à
Libellés : , , , , , , , , , , , , , , , ,

Aucun commentaire:

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)