EA2014 OSGi

OSGi Alliance

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.

Nous allons donc voir un bref résumé d'OSGi pour au moins comprendre son intérêt et sa structure.

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 :

Expliquons brièvement à quoi sert chaque partie :

• Manifest-Version va nous donner la version du manifest car on peut en avoir plusieurs vu que les versions sont indépendantes les unes des autres
• Bundle-ManifestVersion va nous donner le numéro de révision du bundle
• Bundle-Name, le nom du bundle
• Bundle-SymbolicName, permet d'identifier un bundle dans un runtime
• Bundle-Version, la version du bundle
• Bundle-Activator, le lien qui servira d'Activator pour le bundle
• Import-package, les dépendances nécessaires au fonctionnement du bundle
• Export-package, les dépendances que l'on veut mettre à disposition
• Web-contentpath, présent dans le cas où le projet est une application web
• Export-EJB, présent dans le cas où l'on fait un projet JEE

Il faut savoir qu'il en existe beaucoup d'autres, je vous conseille donc de vous rendre sur la doc de OSGi.

Fonctionnement des services

Comme expliqué précédemment, les bundles fonctionnent avec un système de service. Ce système est appelé le registre de service. Ce registre va être accédé en permanence par les bundles dans le but de connaître les services actifs.

Les MAJ de ce registre se fait par les bundles eux-mêmes :

• Lorsqu'ils sont en démarrage, ils s'enregistrent en donnant les services qu'ils peuvent fournir et ce dont ils ont besoin.
• Lorsqu'ils s'arrêtent, ils se désinscrivent du registre.

Les fichiers qui sont transférés pour l'inscription et la désinscription sont de la forme : LDAP.

Côté utilisateur, seule une interface du service sera visible ainsi qu'un numéro de version.

Le petit plus du registre de services, est qu'il est doté d'un système de notifications : c'est à dire que dès qu'un service est disponible par exemple, ceux qui en avait besoin vont être notifié et vont donc pouvoir devenir actif.

Domaines d'applications

Voici des exemples concrets qui pourraient être utiles :

• Vous avez un système déjà présent en production et vous ne pouvez pas vous permettre d'arrêter la plateforme. Dans ce cas OSGi est un framework parfait, si vous avez pensé à l'implémenter avant la mise en production. Vous allez pouvoir mettre à jour des services et les déployer sans rien arrêter.
• Tout projet nécessitant un SOA léger

Sources

• Cours de Didier Donsez
• Tuto Apache Felix
• JavaDoc Osgi