EA2014 OSGi
Présentation
- Enseignants : Georges-Pierre Bonneau, Didier Donsez (EA2014)
- Sujet : OSGi
- Date : 17 octobre 2014
- Auteur : Arthur Clerc-Gherardi
Mots Clés
OSGi, SOA, Module, Bundle, Apache Karaf, Eclipse, Life Cycle
Synthèse
Introduction
Vous aimeriez pouvoir coder du JAVA et le déployer à chaud comme du JS ou du PhP car vous en avez marre de redéployer vos VM. Vous en avez assez des problèmes de versions de librairies non compatibles ? Vous souhaiteriez pouvoir utiliser plusieurs versions d'une même librairie pour une execution de programme ? Vous voudriez ne plus jamais avoir de "ClassNotFoundException" ? OSGi est alors le parfait framework pour vous.
OSGi est un framework orienté service permettant aux développeurs de créer des bundles (appelés aussi modules) qui seront indépendants les uns des autres. Ils peuvent s'utiliser entre eux, mais si l'un plante, ça ne fera pas planter tout le programme.
On peut donc dire que pour la mise en place d'une architecture SOA, OSGi peut être réellement intéressant.
Le fonctionnement
Comme on peut le voir grâce au schéma ci-dessus, les modules OSGi travaillent sur plusieurs couches :
- La couche Services met les services proposés à l'utilisateur en avant, sans leur montrer l'implémentation (une interface)
- La couche Cycle de vie va prendre en compte les états courants de chaque bundle
- La couche Module va mettre en place les différents bundle en les chargeant ainsi que leurs dépendances
- La couche Java Execution Environment est la couche que l'on utilise habituellement pour lancer nos programmes java
Les avantages que l'on peut déjà voir sont par exemples, l'isolation de chaque module ce qui va permettre à des bundles ayant besoin d'une même ressource mais de version différente de fonctionner. En effet côté JAVA, chaque bundle possède son propre classloader.
Le cycle de vie
Comme expliqué ci-dessus, chaque bundle va vivre selon un automate qui sera son cycle de vie. Chaque bundle va alors s'occuper de son propre cycle de vie. Le bundle peut soit être non-opérationnel, c'est à dire qu'il est présent mais n'a pas été déployé et n'est donc pas utilisable par les autres bundles. Il peut être au contraire opérationnel, et dans ce cas les autres bundles auront accès à ses services.
On peut diviser ces deux étapes en un automate un peu plus complet :
- Etat Installé : le composant vient d'être installé correctement mais n'est pas encore utilisable
- Etat Resolu : les dépendances liés à ce composant ont été résolues
- Etat Désinstallé : le composant vient d'être désinstallé
- Etat Démarrage : état transitoire où le bundle effectue les actions nécessaires (comme la souscription au registre) avant d'être utilisable par tous
- Etat Actif : le bundle est utilisable par les autres bundles
- Etat Arrêt : état transitoire où le bundle se désinscrit du registre
Structure du bundle OSGi
Chaque bundle peut être considéré comme un grosse boîte avec certaines propriétés :
- Les services apportés par le bundle
- Les services dont il a besoin pour fonctionner
- Les packages importés et exportés (par défaut 0)
- L'activateur qui va définir son cycle de vie
- Les ressources nécessaires au fonctionnement du bundle (image, xml...)
- Un fichier MANIFEST qui va contenir les informations du bundle
Pris, sur le site de IBM, un exemple de manifest :
