OSGi en bref - Eric

OSGi en bref de Eric Simon est mis à disposition selon les termes de la licence Creative Commons
Paternité 3.0 non transcrit.
ADELE/LIG
OSGi en bref
Version 1.0.2
Eric SIMON

2
1 But du document
Ce document a pour but d’expliquer brièvement les mécanismes dans OSGi qui permettent le
chargement et le déchargement dynamiques de modules ainsi que de la mise en place d’applications
dites dynamiques.
2 OSGi : Histoire et Motivation
Le succès d’OSGi ne cesse de croître. Cependant les buts actuels d’OSGi ne correspondent plus
au but initial.
JSR 008
A l’origine, le projet de la plate-forme OSGi est issu de la JSR 008 (décembre 1998) (cf. [1.]) qui
spécifie une passerelle de service appelée OSG pour Open Service Gateway. Cette passerelle est
destinée à fournir une capacité de pontage entre un réseau interne et un réseau externe, par
exemple entre un réseau SOHO
1
et internet ou encore entre un réseau domestique et internet (cf.
Figure 1).
Figure 1 Topologie ciblée par la JSR 008
Cette passerelle a deux buts :
 Servir de point d’accès à des partis tiers pour fournir des services ;
 Centraliser la gestion des différents équipements sur le réseau.
De plus les différents éléments sur cette passerelle doivent fournir des API pour pouvoir les lier
entre eux. Et d’autre part ils devraient suivre le principe de « zéro-administration ».
Un exemple de scénario parmi d’autres visés par la JSR 008
Pour bien comprendre l’intérêt, prenons un exemple concret :
EDF cherche à éviter la surcharge de la consommation nationale en fournissant un service de
facturation incitatif. C’est-à-dire que le prix du kW/h varie un jour sur l’autre dans une fourchette
préétablie. EDF s’engage à fournir la grille tarifaire 5 jours à l’avance au client. Par exemple un
dimanche au printemps ne nécessite pas de chauffage électrique ni de climatisation, pas
d’évènement particulier qui consomme de l’énergie au niveau national. Par conséquent le prix du
1
Small Office Home Office

3
kW/h sera faible ; les personnes devraient par conséquent faire leur lessive… Inversement imaginons
un lundi particulièrement froid en hiver, la consommation nationale en électricité est élevée :
chauffage, travail… Dans ce cas le prix du kW/h sera élevé, de cette manière les gens ne laisseront
pas le chauffage allumé alors qu’ils seront au travail, ils reporteront leur lessive et le sèche-linge à un
autre jour.
Pour définir un tel scénario il faut trois éléments :
 Des sondes sur le panneau électrique qui remontent la consommation journalière ;
 Une infrastructure de remontée de données des consommations ;
 L’envoi de la grille tarifaire des 5 prochains jours au client en fonction de leur abonnement et
de leur géolocalisation.
Dans ce scénario une passerelle OSG est parfaite car la passerelle récupère les données sur les
sondes et envoie périodiquement les données à EDF avec le numéro d’abonnement. Chaque jour EDF
envoie les grilles tarifaires aux passerelles. Les clients accèdent aux tarifs en se connectant sur
l’interface de la passerelle.
Par conséquent, la passerelle embarque un module de communication pour les sondes, un
module de communication pour la remontée de données vers EDF, un module d’interface pour les
abonnés et finalement un ou plusieurs composants métier.
Dans l’exemple ci-dessus, la passerelle sert de pont entre le compteur électrique et la remontée
de données d’EDF. Elle fournit un point d’accès à EDF pour déployer des composants qui vont lui
permettre de remonter des données ou de lui en envoyer. Et finalement, la passerelle permet de
centraliser l’ensemble des composants nécessaires à l’abonné.
Et OSGi dans tout ça ?
OSGi est un projet issu de la JSR 008. Le consortium OSGi Alliance (cf. [2.]) a été fondé en mars
1999. Il est chargé de spécifier et de standardiser les fonctionnalités et les services des plates-formes
d’exécution OSGi.
Bien que déjà décrit dans la JSR, OSGi met l’accent sur la modularité des éléments qui
constituent l’application aussi bien au niveau classe qu’au niveau objet, pour pouvoir reconfigurer
l’architecture en exécution sans avoir à arrêter la passerelle. La modularité et la reconfigurabilité
sont des propriétés recherchées dans des domaines autres que celui des passerelles : par exemple
pour les serveurs d’applications.
Conclusion
Nous nous intéresserons dans ce document aux aspects de modularité et de reconfigurabilité fournis
par OSGi.

4
3 La plate-forme OSGi
OSGi spécifie une plate-forme d’exécution Java qui supporte le déploiement d’applications
extensibles et téléchargeables nommées : bundle.
Les équipements compatibles OSGi peuvent télécharger et installer ces bundles et les
désinstaller lorsqu’ils n’en ont plus besoin.
Cette plate-forme repose principalement sur trois couches en interaction (cf. Figure 2) :
 La couche module définit un modèle de modularisation pour Java ;
 La couche cycle de vie est basée sur la couche module. Elle définit l’API d’administration des
bundles ainsi que les différents états dans lesquels peut être un bundle;
 La couche service est basée sur la couche cycle de vie. Cette couche définit un modèle de
programmation ainsi que les mécanismes pour la conception, le développement et
l’exécution d’applications « dynamiques » basées sur l’approche orientée service.
Figure 2 Interactions entre les différentes couches
Nous résumerons dans cette section ces trois couches.
3.1 Couche Module : Bundle
La couche Module définit le concept de bundle à la fois comme unité de déploiement et comme
unité de composition dans la plate-forme d’exécution. Dans OSGi le concept de bundle et celui de
module sont similaires et sont donc interchangeables.
Un bundle est une archive Java (Jar) qui peut contenir, outre des classes Java, différentes
ressources. Ces ressources peuvent être diverses (cf. Figure 3) : GIF, PNG, fichier de propriétés ou
d’autres conteneurs comme des archives Java (Jar) ou des fichiers Zip. De plus un bundle peut
contenir aussi des librairies de code natif comme des dll ou des fichiers so… Il faut cependant
différencier les classes Java, les archives Java et les librairies de code natif des autres ressources car
celles-ci sont prises en charge par la plate-forme, alors que la gestion des autres ressources est à la
charge du développeur du bundle. Dernier point : un bundle contient un ensemble de métadonnées
utilisées par la plate-forme pour qu’elle puisse prendre en charge les différents aspects du bundle (cf.
section 3.1.1).
Bundle
Module
Bundle
Cycle de vie
Service
Enregistre,
Désenregistre,…
Démarre,
Arrête
Charge les
classes
Installe,
Désinstalle

5
Rôle d’unité de déploiement
Un point important est que le bundle est une unité
de déploiement, c’est-à-dire que c’est un élément
« tangible » qui d’une part va pouvoir être copié et
transféré ; mais qui d’autre part va servir à empaqueter
les classes qui pourront ainsi être partagées, chargées
et utilisées.
Rôle d’unité de composition
L’autre aspect d’un bundle est qu’il est utilisé
comme unité de composition. C’est-à-dire qu’il va être
utilisé avec d’autres pour définir une ou plusieurs
applications. Dans OSGi, cette composition peut se
faire à deux niveaux : niveau classe et niveau objet.
Dans cette section nous allons nous intéresser au
niveau classe, le niveau objet sera quant à lui traité
dans les autres couches. Au niveau classe le Bundle
permet de cloisonner les classes entre ce qui est propre (privé) à l’exécution du Bundle de ce qui sera
partagé dans la composition. Cet aspect est basé sur les métadonnées fournies par le Bundle.
Nous allons, dans un premier temps, aborder les métadonnées définies par OSGi, puis la prise en
charge des classes et des librairies de code natif.
3.1.1 Métadonnées d’un bundle
OSGi spécifie une spécialisation de l’archive Java pour son contexte d’exécution. De ce fait il
réutilise le fichier de métadonnées (Manifest) défini par Java (cf. encadré ci-contre) pour y inscrire
ses propres métadonnées.
OSGi définit un certain nombre de
métadonnées (cf. section 3.2.1 de
http://www.osgi.org/download/r4v43/r4.core.pdf).
Dans cette section nous n’allons pas décrire
l’ensemble des propriétés, mais seulement celles
qui sont liées au cycle de vie et à la gestion des
classes/code.
Gestion des classes/code
 Bundle-ClassPath : cette propriété est
utilisée pour indiquer les chemins (path) vers les
archives Java contenues dans le bundle. De cette
manière, les classes et les ressources de ces
archives embarquées pourront être utilisées. Par
exemple : /lib/jms.jar. Nous aborderons à
nouveau cette propriété dans la section 3.1.2.
Bundle
.class
.class
MANIFEST.MF
.dll, .so
Figure 3 Module OSGi : Bundle
Les Manifests dans Java
Les archives Java supportent de
nombreuses fonctionnalités, comme les
signatures électroniques, le contrôle de
version et bien d’autres aspects. Ces
fonctionnalités nécessitent des informations
incluses dans l’archive Java : c’est le rôle du
Manifest.
Le Manifest (fichier MANIFEST.MF) est un
fichier de métadonnées dans le répertoire
META-INF de l’archive Java. Ce fichier contient
au moins l’information de version du Manifest.
Par défaut Java définit un ensemble de
métadonnées : comme par exemple le nom du
vendeur ou la version de l’archive. La plupart
des métadonnées dépendent du contexte
d’exécution et de la nature de l’archive.
Pour plus d’information, référez-vous à
http://java.sun.com/developer/Books/javapro
gramming/JAR/basics/manifest.html.