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 :