OSGi en bref ADELE/LIG. Version 1.0.2. Eric SIMON

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

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). Cette passerelle a deux buts : Figure 1 Topologie ciblée par la JSR 008 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 2

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. 3

Bundle Bundle 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. Enregistre, Désenregistre, Service Démarre, Arrête Cycle de vie Installe, Désinstalle Charge les classes Module 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). 4

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..class.class Rôle d unité de composition.dll,.so 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 MANIFEST.MF applications. Dans OSGi, cette composition peut se faire à deux niveaux : niveau classe et niveau objet. Dans cette section nous allons nous intéresser au Bundle niveau classe, le niveau objet sera quant à lui traité Figure 3 Module OSGi : Bundle 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. 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. 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. 5

Bundle-NativeCode : comme vu précédemment, un bundle OSGi peut embarquer du code natif. Cette propriété sert à la fois pour définir les chemins vers les librairies de code natif, ainsi que dans quels contextes d exécution (e.g. : système d exploitation, processeur ). Exemple : LibusbJava.dll;osname=WindowsXP;processor=x86. Nous aborderons à nouveau cette propriété dans la section 3.1.3. Bundle-RequiredExecutionEnvironnement : cette propriété indique le ou les environnements d exécution qui doivent être présents sur la machine. Exemple : Java SE 6. Export-Package : cette propriété désigne les packages appartenant au bundle qui seront exportés. Nous aborderons à nouveau cette propriété dans la section 3.1.2. Cycle de vie Import-Package : cette propriété désigne les packages requis par le bundle pour son utilisation. Nous aborderons à nouveau cette propriété dans la section 3.1.2. DynamicImport-Package : cette propriété désigne les packages qui seront chargés non pas à l installation du Bundle mais au moment de leur utilisation. Par conséquent il se peut qu il ait des dépendances de packages non résolues à l exécution. Il faut donc utiliser cette propriété en dernier recours. Bundle-Activator : cette propriété spécifie le nom de la classe utilisée pour l activation et la désactivation du bundle. Nous aborderons à nouveau cette propriété dans la section 3.2.1. Bundle-ActivationPolicy : cette propriété définit la politique d activation que doit suivre la plate-forme pour activer le bundle. Par défaut il existe deux politiques : o Par défaut eager : démarre le bundle et charge les classes lors de l activation. o Lazy : diffère l activation et le contexte d exécution du bundle jusqu à sa première utilisation (déclenchée par le chargement d une ou plusieurs classes spécifiées). Bundle-UpdateLocation : cette propriété permet de spécifier une URL, à partir de laquelle on devrait (SHOULD) pouvoir mettre à jour le bundle. Export-Service : cette propriété est dépréciée (deprecated). Elle permettait d indiquer les services que fournissait un bundle. Import-Service : cette propriété est dépréciée (deprecated). Elle permettait d indiquer les services que requérait un bundle. Provided-Capability (R4.3) : Cette propriété signifie que le bundle fournit un ensemble de «capacités». Require-Capability (R4.3) : Cette propriété signifie que le bundle requiert d autres bundles pour fourni une «capacité». Cette dépendance vers d autres bundles est définie via un filtre LDAP. Require-Bundle : cette propriété spécifie que tous les packages exportés par un bundle ciblé doivent être importés. Fragment-Host : cette propriété définit quels sont les bundles «hôtes» pour ce fragment. 6

3.1.2 Gestion des classes dans OSGi L un des principaux attraits d OSGi est la modularité qui permet l installation et la désinstallation de modules JAVA sans interruption de la plate-forme. Cette fonctionnalité est permise grâce à une gestion avancée des classes. Dans cette section nous allons nous intéresser à la gestion des class loaders (rappel : voir encadré ci-contre). OSGi base son mécanisme pour cacher et partager les packages sur deux points : un réseau de délégation de chargement de classes (cf. Figure 4) et des règles de visibilité de package. Réseau de délégation de class loader Chaque bundle a un unique class loader. Ce class loader peut charger des classes à partir de trois différentes sources de ressources : Boot class path : il contient les packages java.* et leurs implémentations ; Framework class path : la plate-forme OSGi a généralement un class loader séparé pour les classes d implémentation de la plate-forme ainsi que pour certaines interfaces de service clé ; Espace de Bundles : cet espace consiste en l ensemble des archives Java liées au bundle par une relation d import ou de fragment. Qu est-ce qu un class loader en Java? Rôle : La machine virtuelle Java (JVM) accède aux classes via les chargeurs de classe (class loader). Le but d un class loader est de charger les classes à partir d une source. De ce fait la machine virtuelle Java ignore la localisation des ressources : c est aux class loaders d aller les chercher dans les différentes ressources d un système. Pour cela, Java se base sur un arbre de délégation de class loader dont les règles sont les suivantes : Tout class loader a un parent (sauf le chargeur initial) ; Tout class loader va d abord chercher les classes à partir de son parent avant d aller les chercher dans le CLASSPATH. Par défaut, la machine virtuelle Java possède trois class loaders hiérarchiques : 1. Le class loader initial : charge les classes standards de la machine virtuelle (rt.jar, core.jar ) 2. Le class loader d extension : charge les classes du répertoire d extension : /jre/lib/ext ; 3. Le class loader applicatif : charge les classes à partir des archives Java définies dans le CLASSPATH. Il est possible d ajouter d autres class loader pour prendre en charge des aspects particuliers dans le système (e.g. : URLClassLoader) Règles : a. Une classe est liée à son class loader et ne peut en changer ; b. Une classe est identifiée par son nom et son class loader ; c. Il ne peut pas y avoir deux classes ou plus ayant le même nom dans un class loader ; d. Une même classe peut être chargée par plusieurs class loaders ; e. Une classe ne peut être déchargée que si son class loader n est plus référencé ; c est-à-dire qu il n existe plus d instance de cette classe. Bundle Class Loader Bundle Class Loader Framework Class Loader System Class Loader Bundle Class Loader Bundle Class Loader Import de Figure 4 Modèle de délégation de class loader 7

Visibilité des packages Le deuxième mécanisme mis en place dans OSGi est un mécanisme de visibilité de package. En effet, comme vu dans la sous-section Gestion des classes de la section 3.1.1, OSGi définit des métadonnées pour la gestion des packages qui sont : Import Package ; Export Package ; Private Package ; Ces métadonnées définissent deux types de visibilité : Publique : les packages exportés ; Privée : les packages déclarés comme privés. privés publics Bundle A Espace de Classe de A publics Bundle B V1.0 publics privés privés Bundle C Les packages publics peuvent donc être importés et utilisés par d autres bundles. Par conséquent un bundle a accès à la fois aux classes de ses packages qu ils soient publics ou privés, mais aussi à toutes les classes des packages publics qu il importe. Prenons l exemple de la Figure 5, le bundle A accède à la fois à ses classes mais aussi aux classes des packages publics importés par A. Cet ensemble de classes auquel peut avoir accès le class loader du bundle A s appelle espace de classe. Versionnement Le fait d avoir un class loader par bundle permet d avoir à l exécution plusieurs versions d un même package dans l'environnement d'exécution. La seule contrainte est bien évidemment qu un bundle ne peut avoir accès qu à une seule version (règle C des class loader dans Java, encadré précédent). OSGi suppose que les bundles ont une compatibilité ascendante et cherchera donc par défaut à résoudre les dépendances de packages à l aide des dernières versions. Cependant il est possible de spécifier dans les métadonnées les versions que l on souhaite utiliser pour résoudre la dépendance de package : Import-Package : org.apache.felix.ipojo;version= 1.4.0 Espace de Classe de D Cela signifie que le bundle requiert le package org.apache.felix.ipojo ayant une version au moins égale à 1.4.0. Pour définir une version explicite il faut définir la propriété de la manière suivante : privés publics Bundle D publics Figure 5 Visibilité et espace de classe privés Bundle B V2.0 8

Import-Package : org.apache.felix.ipojo;version= [1.4.0, 1.4.0] Cela signifie que le package doit avoir une version supérieure ou égale à 1.4.0 et être inférieure ou égale à 1.4.0 : donc être égale à 1.4.0. De manière plus générale OSGi définit la politique de version de la manière suivante : [Min,Max] [Min,Max) (Min,Max) (Min,Max] Version Min <= x <= Max Min <=x< Max Min < x < Max Min < x <= Max Version <= x En conclusion, comme le montre la Figure 5, il est possible d avoir plusieurs versions d un même package dans OSGi : le bundle A utilise les packages du bundle B version 1 alors que le bundle D utilise la version 2. Cependant, les bundles A et B ne doivent pas s échanger des instances des classes venant respectivement des bundles B. Communication inter-bundle Rappelons une règle des class loaders : une classe est identifiée par son nom et son class loader. S il existe une même classe dans plusieurs class loaders alors ces mêmes versions de classe seront considérées comme étant distinctes. Par conséquent pour pouvoir communiquer, deux bundles doivent se partager une même classe. C est à ce moment que le mécanisme de réseau de délégation de class loader entre en jeu : un class loader va chercher dans son parent les classes à charger avant de les rechercher dans son classpath. Dans le cas d OSGi, un bundle va d abord chercher les classes à partir du class loader parent c est-à-dire le système Java et ses extensions, puis à partir des class loaders des différents bundles appartenant à son espace de bundles (relation d import/export de packages à l exécution). Grâce à ce mécanisme d import/export de package, les bundles peuvent s échanger des classes provenant d un unique class loader permettant ainsi la communication entre les bundles. Complétons l exemple de la Figure Class loader C 5 à l aide de la Figure 6: une instance de classe du bundle A envoie des messages à une instance de classe du bundle D. Par conséquent A et D doivent avoir le Class loader A même type de message et venir du même class loader. Dans le cas présent, les instances respectives de A et D vont loadclass(fr.imag.bob.getname()) charger la classe du message fr.imag.bob à partir de leur class loader respectif qui délèguera au class loader du bundle C. Dynamicité loadclass(fr.imag.bob.getname()) Class loader D loadclass(fr.imag.bob.getname()) Figure 6 Exemple de délégation de chargement dans OSGi Nous aurions pu avoir le cas, comme dans l exemple de la Figure 7, où les classes servant à la communication appartiennent à l un des deux bundles. Ce cas de figure est à éviter car nuit à la dynamicité de la plate-forme. 9

Explication : une instance de A souhaite communiquer avec une loadclass(fr.imag.bob.getname()) instance de D, pour cela elle a chargé la Class loader A loadclass(fr.imag.bob.getname()) Class loader D loadclass(fr.imag.bob.getname()) classe Bob à partir de D. Maintenant on souhaite désinstaller D et installer un autre bundle qui fournit les mêmes fonctionnalités que D. il fournit aussi la classe Bob. Cependant le bundle A a Figure 7 Exemple de délégation à éviter déjà chargé la classe Bob et il n est possible de le décharger que si on relâche le class loader de A ce qui revient à redémarrer le bundle A. La communication avec les instances du nouveau bundle n est pas non plus possible car il utilisera sa classe Bob qui vient d un autre class loader et qui par conséquent est un autre objet. Par conséquent dans OSGi, on sépare l API pour la communication et son implémentation dans des bundles différents. 3.1.3 Gestion du code natif Java ne permet pas d accéder à tous les aspects d un système. Par conséquent OSGi spécifie la possibilité d embarquer du code natif dans un bundle. L idée sous-jacente est qu il est parfois nécessaire d utiliser des drivers natifs à un système. Cependant les programmes Java sont souvent portables entre les systèmes, ce qui n est pas le cas du code natif. Sélection des librairies OSGi spécifie un mécanisme de sélection de librairie de code natif en fonction du système. Cette sélection se base sur cinq propriétés : Le nom du système d exploitation (osname) : par exemple WindowsXP, Linux, Solaris ; La version du système d exploitation (osversion) : par exemple 5.1 ; Le processeur (processor) : par exemple x86, mips, sparc ; Le langage (language) : par exemple en, fr ; Un filtre de sélection. Prenons l exemple d un bundle qui fait le pont d USB 2 vers OSGi. Le manifest de ce bundle contient la métadonnée suivante : Bundle-NativeCode : lib/libusbjava.dll;osname=windowsxp;osname=windows vista;osname=windows 7;processor=x86, lib/libusbjava.so;osname=linux;processor=x86 La métadonnée suivante dit que la librairie LibusbJava.dll présente dans le répertoire lib du bundle sera chargée si le système d exploitation est un Windows soit XP, soit vista soit 7 et si c est un processeur x86. Si le système d exploitation est un Linux sur un processeur x86 alors la librairie libusbjava.so sera chargée. 2 http://websvn.ow2.org/filedetails.php?repname=chameleon&path=%2fsandboxes%2fmehdi%2fusb-bridge- Bundle%2Fpom.xml 10

Utilisation du code natif Grâce au mécanisme précédent il est possible d utiliser du code natif en fonction du système sous-jacent. Cependant ces librairies ne seront accessibles qu à partir de la plate-forme OSGi. En effet le but n est pas de déployer ou de mettre à jour des pilotes ou des fonctionnalités du système sous-jacent, mais d accéder et d exploiter des ressources du système qui nécessitent des pilotes en code natif. L exemple précédent en est une parfaite illustration : l accès aux équipements USB n est pas pris en charge par Java et nécessite des pilotes dépendants du système. Le but du bundle est de fournir un service d annuaire d équipements USB basé sur les pilotes USB pour Windows et Linux. Pour cela les deux librairies sont interfacées à l aide de JNI (voir encadré Java Native Interface). En fait, lorsque le code appelle le système pour rechercher la librairie, OSGi retourne la librairie comme si elle était installée dans le système. Il y a tout de même une limitation : seul un unique class loader, donc un bundle, doit charger la librairie native pour pouvoir préserver la séparation des espaces de nom. En effet si plusieurs class loaders chargent la librairie alors il y aura un recouvrement des espaces de noms et causera donc une erreur de liaison. Java Native Interface (JNI) (http://java.sun.com/docs/books/jni/download/jni.pdf) Le but de JNI est de pouvoir incorporer du code natif écrit en C ou en C++ dans du code JAVA. JNI est fournie par défaut dans le JDK de Sun. La machine virtuelle Java (JVM) fournit donc JNI pour interfacer du code natif et du Java. Cette interface est bidirectionnelle : elle permet à des applications Java d appeler du code natif et inversement. L interface bidirectionnelle JNI peut supporter deux types de code natif : les libraires et les applications. JNI peut être utilisée pour écrire des méthodes natives qui seront appelées par du code Java. Inversement, JNI peut être utilisée pour embarquer une application Java et la JVM dans une application native. Il faut toutefois remarquer que dans une application Java dépendante de librairie native, seule la partie purement Java est portable d un système à un autre. Il faudra donc interfacer pour chaque système les librairies natives correspondantes. Il faut donc bien circonscrire les librairies natives dans l architecture de l application et en limiter l utilisation. 3.1.4 Conclusion La couche module définit le concept de bundle. Ce concept est à la base de la modularité et de la dynamicité de la plate-forme d exécution OSGi. En effet chaque bundle a son class loader, ce qui fait que chaque bundle peut être vu comme étant une plate-forme ayant son espace de classe et son espace d exécution. Cependant, c est le mécanisme de délégation entre ces class loaders définis par OSGi qui permet le partage de classe et la communication entre ces espaces d exécutions. En d autres termes, OSGi se distingue des autres plates-formes d exécution (serveur JavaEE ) par son mécanisme de réseau de délégation de class loaders qui permet la modularité et une dynamicité des applications. 11

3.2 Couche cycle de vie La couche cycle de vie dans OSGi fournit les fonctionnalités de sécurité et les opérations d administration des bundles. Cette couche est basée sur celle de module. Dans cette section nous allons nous intéresser au cycle de vie d un bundle, c est-à-dire décrire les différents états par lesquels va passer un bundle de son installation à sa désinstallation, ainsi que les différentes opérations d administration qui permettent ces changements. Nous allons dans un premier temps aborder les états et les opérations d administration d un bundle avant de décrire un certain nombre de mécanismes qui interviennent durant le cycle de vie. 3.2.1 États et opérations d administration d un bundle La Figure 8 définit le cycle de vie d un bundle sous la forme d un diagramme d état. Désinstallé désinstalle installe Installé désinstalle / rafraichit / met à jour Résolu démarre En phase de démarrage Activé résout arrête rafraichit / met à jour En phase d arrêt Figure 8 Cycle de vie du Bundle (Diagramme d'état) Installé Si un bundle est dans l état installé c est que l installation a été effectuée avec succès. C est-àdire que le bundle est valide (cf. section 3.12 de la spécification d OSGi R4.3) et que la plate-forme lui a assigné un identifiant unique. Cette opération d installation est atomique et persistante. A la fin de cette opération, un objet bundle est créé dans la plate-forme et servira à administrer le bundle jusqu à sa désinstallation. Désinstallé Un bundle est désinstallé si sa représentation physique (persistance) a bien été supprimée et que ses différentes ressources logiques ont bien été déchargées de la plate-forme. Résolu Un bundle est résolu si toutes ses dépendances (package, capacité ) décrites dans le manifest ont été pourvues. 12

En phase de démarrage Durant la phase de démarrage d un bundle, celui-ci est initialisé (appel de la méthode start de l objet bundle). Une fois initialisé, le bundle sera automatiquement activé si la politique d activation est eager. Dans le cas où la politique d activation est lazy, alors l activation ne se fera pas immédiatement. Une fois l activation déclenchée, une notification est alors envoyée à la plate-forme OSGi. Dans le cas où une classe d activation est spécifiée par la propriété Bundle-Activator (cf. section 3.1.1), celle-ci est alors instanciée, déclenchant l instanciation du class loader du bundle. Activé Une fois l instance créée la plate-forme appelle la méthode start. Un bundle est activé au moment de l appel de la méthode start sur l instance de la classe d activation (définie par la propriété Bundle-Activator) si celle-ci existe. En phase d arrêt Un bundle actif peut être désactivé. Lorsque celui-ci est désactivé alors la méthode stop de la classe d activation est appelée et les contraintes suivantes doivent être respectées : tous les services et autres ressources (sauf les packages), qui étaient utilisés, doivent être relâchés par le bundle ; tous les threads du bundle devraient être immédiatement stoppés ; tous les services et listeners du bundle sont automatiquement désenregistrés de la plateforme OSGi. 3.2.2 Adaptation Depuis la version 4.3 de la spécification, un bundle peut être «adapté» en différent types. Cette fonctionnalité permet d obtenir une vue spécifique du bundle, comme par exemple les liens entre les capacités des bundles. Le nombre de vues différentes n est pas fixé par OSGi, cependant la spécification définit cinq vues : BundleRevision : cette vue permet d accéder aussi bien aux déclarations de capacités fournies et requises, ainsi qu au BundleWiring associé : c est-à-dire les liens entre les bundles à l exécution. Cette vue permet donc d obtenir le graphe de dépendance à l exécution en terme de capacité. Notez que d une part BundleRevision renvoie la révision courante et d autre part que cette vue n a pas de sens pour un bundle désinstallé (pas de révision courante). BundleStartLevel : cette vue permet d accéder et de modifier le niveau de démarrage du bundle. BundleWiring : cette vue permet d accéder aux liens de capacité d un bundle à l exécution. Notez qu un lien de capacité ne peut exister qu à partir de l état résolu (incluant donc les états : en phase de démarrage, en phase d arrêt et activé). 13

FrameworkStartLevel : cette vue permet d accéder et de modifier le niveau de démarrage du système. Notez qu il n est possible d adapter à cette vue que le bundle système. FrameworkWiring : cette vue permet d accéder aux dépendances des bundles. Elle permet notamment d obtenir la fermeture transitive des dépendances d un bundle donné en exécution. 3.2.3 Contexte du Bundle (Bundle Context) Comme vu dans la couche bundle (cf. section 3.1), un bundle possède son propre class loader, son espace de classe et d une certaine manière son propre environnement d exécution. Le BundleContext représente cet environnement d exécution et agit comme un proxy de la plate-forme OSGi. Le BundleContext permet donc : D installer de nouveaux bundles ; D accéder aux informations des autres bundles ; De rechercher un service (cf. section 3.3) ; D exposer un service (cf. section 3.3) ; De souscrire aux différentes sources d événements de la plate-forme OSGi. Le BundleContext est créé à l initialisation du bundle à la phase d activation. 3.2.4 Événement Le niveau cycle de vie de la plate-forme OSGi définit deux types de notifications : Les événements relatifs aux bundles (BundleEvent) : la plate-forme OSGi émet des notifications à chaque changement d état d un bundle. Les événements relatifs à la plate-forme (FrameworkEvent) : la plate-forme OSGi émet des notifications pour chaque changement d état du bundle système (la plate-forme elle-même), ainsi que pour chaque occurrence de logue (ERROR, INFO et WARNING) de la plate-forme. Comme dit précédemment les éléments d un bundle peuvent souscrire à ces deux sources d événements au travers du BundleContext. 3.2.5 Conclusion La couche cycle de vie définit les différentes opérations d administration que l on peut effectuer sur un bundle. Elle décrit les différents états par lesquels un bundle peut passer de son installation à sa désinstallation et des notifications associées. La version 4.3 de la spécification ajoute la notion de lien à l exécution. Une partie de ces liens est basée sur les capacités définies dans la couche module. Ce nouvel aspect est très intéressant car cela permet de tracer le graphe de dépendance entre les éléments du système à l exécution variant en fonction du cycle de vie des bundles. 14

3.4 Couche service Les deux couches précédentes : module et cycle de vie, permettent d avoir une gestion «dynamique» des bundles ; c est-à-dire qui ne nécessite pas le redémarrage de la plateforme. Cependant cette dynamicité des modules ne concerne que les classes. Ces deux couches ne sont pas suffisantes pour définir à elles seules des applications dynamiques ; en d autres termes une gestion dynamique des bundles n implique pas nécessairement une gestion dynamique des applications (niveau instance). Dans OSGi la couche service va permettre la définition d applications dites dynamiques. Pour cela un bundle va exposer ses fonctionnalités (niveau instance) à d autres bundles et inversement pouvoir utiliser celles des autres. Pour conserver la dynamicité il est nécessaire d avoir un couplage lâche dans les dépendances de fonctionnalités. L un des aspects les plus importants dans l approche orientée service (cf. encadré ci-dessous) est le contrat (description du service). Le fournisseur utilise ce contrat pour définir ses fonctionnalités Approche Orientée Service L approche orientée services [3.] est basée sur l idée qu une application peut être réalisée par composition des services logiciels mis à disposition par des fournisseurs divers ([4.] [5.] appellent ce modèle «service-based model of software»). Bien qu il n y ait pas de réel consensus sur la définition du concept de Service, les différentes définitions s accordent sur le patron d interaction. Il faut cependant remarquer que ce patron d interaction n est pas une réelle innovation en soi. En effet, il existait déjà, dans les applications distribuées, un niveau d indirection entre les clients et les serveurs, où les clients passent par le biais d un intermédiaire qui traduit le nom logique du serveur cible par l adresse physique (cf. DNS, les courtiers ODP [6.]). Cependant l approche orientée service pousse le raisonnement plus loin : on ne recherche plus un serveur/élément logiciel par rapport à son nom mais par rapport aux fonctionnalités qu il fournit. En d autres termes on recherche une fonctionnalité (un service) et non un fournisseur. Le patron d interaction du SOC est basé sur trois acteurs : Les fournisseurs de services qui offrent des services Les consommateurs de services qui requièrent et utilisent des services offerts par des fournisseurs Un registre de services permettant aux fournisseurs de publier leurs services et aux consommateurs de découvrir et de sélectionner les services qu ils veulent utiliser. Dans ce patron d interaction, le fournisseur de service publie sa spécification auprès d un courtier/registre de services. Lorsqu un Consommateur de service requiert un service, celui-ci recherche, auprès d un ou plusieurs registres de service, un service conforme à ses besoins ; une fois le service sélectionné, le consommateur interagit avec le fournisseur de ce dernier (cf. figure ci-dessous). Notons que seule la spécification du service est partagée entre les acteurs. 2. Découverte et sélection Client de service Registre de services Description de Service 3. Liaison 1. Publication Fournisseur de service 15

ainsi que les propriétés non-fonctionnelles associées. Les clients se basent sur les contrats pour sélectionner le ou les services qui conviennent à leurs besoins. Cet aspect de contrat de service permet de définir une frontière claire et propre entre les différents éléments logiciels de l application. Par conséquent, puisque la recherche et l utilisation d un service se fait via le contrat, il est possible de substituer l implémentation par une autre tant que ce dernier fournit au moins le contrat recherché. Par conséquent, OSGi utilise l approche orientée service pour définir les applications : car d une part cette approche fournit un couplage lâche entre le consommateur et le fournisseur de service, et d autre part le registre permet la re-sélection et donc l adaptation (substitution) à l exécution de l application. Dans cette section, nous aborderons le registre de services OSGi, puis les événements liés aux services, avant de nous intéresser à la définition d application dans OSGi. Finalement nous aborderons brièvement les mécanismes spécifiés pour les services distants avant de conclure. 3.4.1 Registre de services La couche module permet de partager les classes entre les différents bundles, alors que la couche service va permettre de partager les instances des fonctionnalités (service) entre bundles. Ce partage d instances est basé sur un registre de services partagé entre tous les bundle contexts. Un bundle peut être fournisseur et/ou consommateur de service. Nous allons dans la suite aborder les aspects fournisseur avant de voir les aspects consommateur Fournisseur de Service Pour enregistrer un service, un bundle doit fournir au registre les éléments suivants : La description des fonctionnalités : interface Java ; Le(s) point(s) d invocation des fonctionnalités : la référence de la classe d implémentation ; Les propriétés non-fonctionnelles : Tableau de propriétés Java (Properties.class). Lorsqu un élément d un bundle enregistre un service, celui-ci récupère une référence de l enregistrement (ServiceRegistration). Cette référence sert à administrer le service : modifier les propriétés non-fonctionnelles et désenregistrer un service. Soit l exemple de code suivant : Properties properties = new Properties(); //... ServiceRegistration serviceregistration = bundlecontext.registerservice(moninterfacedeservice.class.getname(), MonObjetDImplementationDuService, properties); Le développeur du bundle doit désenregistrer son ou ses services lorsqu il est désactivé. Noter que certaines implémentations de plate-forme OSGi automatisent ce désenregistrement. Consommateur de Service Pour utiliser un service, un consommateur doit le rechercher. Il est possible de rechercher un service selon deux modes : actif ou passif. 16

En mode actif, le consommateur fait un appel explicite au registre de services pour récupérer une ou plusieurs références de services présents au moment de l appel. Soit l exemple de code suivant : ServiceReference[] refs = context.getservicereferences(moninterfacedeservice.class.getname(), null); En mode passif, le consommateur souscrit aux événements de la plate-forme concernant l apparition, la disparition et la modification des services. De cette façon, le consommateur peut découvrir, sélectionner et utiliser un service au moment où il devient disponible ; ou sélectionner un nouveau service si le premier vient à ne plus être disponible. Soit l exemple de code suivant : context.addservicelistener(this); //... public void servicechanged(serviceevent event) { //... switch (event.gettype()) { case ServiceEvent.REGISTERED: ServiceReference serviceref = event.getservicereference(); //... break; //... Dans la pratique il est conseillé d utiliser les deux modes : à l activation du bundle, résoudre par une recherche active les différents services requis, et souscrire aux notifications des services pour, d une part, compléter les dépendances non résolues et d autre part, détecter le départ d un service. Lorsqu un service est désenregistré, il est impératif que les consommateurs de ce service le relâchent (cf. encadré stale reference). Par Stale Reference Une stale reference ou référence obsolète en français désigne dans OSGi une référence Java sur un objet qui soit appartient à un bundle stoppé, soit provient d un service désenregistré ; dans les deux cas cet objet doit être déréférencé. Cependant Java ne fournit pas de mécanisme générique pour nettoyer les références obsolètes. Le déréférencement de ces objets est à la charge du développeur du bundle. Les références obsolètes sont potentiellement dangereuses car elles peuvent bloquer le déchargement des class loaders. Elles entrainent aussi une augmentation de la mémoire ainsi que des problèmes de mise à jour. Pour éviter de tels problèmes, il est fortement recommandé d utiliser des intergiciels qui automatisent la dépendance des instances (cf. section 4). conséquent ils doivent écouter les notifications de la plate-forme pour relâcher les services qui souhaitent partir. Référence de service Dans les deux exemples précédents, la plateforme OSGi retourne une référence de service et non le service lui-même. En effet rechercher un service ne signifie pas nécessairement vouloir l utiliser, ce mécanisme permet donc d éviter des dépendances de service non nécessaires. Pour utiliser un service, le consommateur demande au registre, via le contexte du bundle, le service ciblé par la référence. Soit l exemple de code suivant : Objet service = bundlecontext.getservice(mareferencedeservice); 17

Une fois que le service n est ou ne doit plus être utilisé, le consommateur de service doit relâcher ce dernier. C est-à-dire notifier au contexte du bundle que le service ne sera plus utilisé et supprimer les références Java conservées. Soit l exemple de code suivant : bundlecontext.ungetservice(mareferencedeservice); this.service = null; Au final que ce soit pour la recherche ou l utilisation de service, il est recommandé, voir nécessaire, de souscrire aux notifications de la plate-forme : en effet la plate-forme OSGi permet la dynamicité des modules et des services. 3.4.2 Service Distant Jusqu à la version 4.3 de la spécification d OSGi, les services étaient considérés comme étant centralisés. Toutefois, certains mécanismes de distribution avaient été spécifiés dans le compendium (compilation des services standardisés pour OSGi). Cependant, la spécification de la plate-forme OSGi 4.3 définit des propriétés et des mécanismes que devraient implémenter les «fournisseurs de distribution» dans le cadre d une distribution des services. Un fournisseur de distribution implémente un ou plusieurs protocoles de communication (e.g. : RMI, CORBA, SOAP ). Ces fournisseurs permettent à la fois d exposer des services OSGi locaux sur le réseau, mais aussi de créer des proxies /représentations des services distants exposés par d autres plates-formes OSGi. Après, le principe est relativement simple : un service OSGi expose dans ses propriétés les protocoles par lesquels il souhaiterait être exporté. Par exemple le service Bob voudrait être exporté en RMI et en SOAP, par conséquent il expose la propriété suivante : service.exported.configs=net.rmi, net.soap Ces propriétés sont utilisées par les «fournisseurs de distribution» pour les exposer. Ces services exposés peuvent donc être finalement «importés» par les autres. Il est à noter cependant certains points : Il est possible d accéder à un service distant par plusieurs protocoles à la fois mais pas deux fois par le même. Par conséquent, soit les différents fournisseurs de distribution présents sur la même plate-forme implantent des protocoles distincts, soit il existe un mécanisme de gestion de conflits entre les fournisseurs de distribution. Le cycle de vie des services importés doit être synchronisé ou cohérent avec le cycle de vie du service correspondant. OSGi ne définit pas dans la spécification de la plate-forme les mécanismes de découverte des services distants, ni la liste des protocoles de communication autorisés et ni comment implémenter un fournisseur de distribution. En d autres termes, OSGi ne spécifie que les grandes lignes / les principes de la distribution des services. 3.4.3 Application OSGi Dans les sections précédentes nous avons vu que la modularisation était aussi bien en terme de classes qu en terme d instances. Cette modularisation est à la base de la dynamicité fournie par la plate-forme. Vient donc la question légitime : comment définir des applications et leur dynamicité (niveau instance) dans une plate-forme OSGi? 18

OSGi : modèle à composant? Une question, voire une affirmation, qui revient souvent est : OSGi est-il un modèle à composant? En effet bundle et composant partagent certaines similarités : ils modularisent le code, s auto-décrivent, explicitent leurs dépendances Cependant il faut bien voir qu un bundle et un composant ont des natures et des buts bien différents. Un bundle est au niveau classe : module, package, dépendance de classe alors qu un composant est du niveau instance : dépendance de fonctionnalité De plus : dans OSGi les dépendances de services sont implicites (les propriétés exported-package et imported-package ne sont pas en pratique utilisées) et d autre part le cycle de vie des services n est pas équivalent au cycle de vie de leur bundle. En simplifiant, au niveau service/instance, un bundle : n explicite pas ses dépendances ; ne fournit pas les interfaces de contrôle du cycle de vie des services ; n a pas nécessairement un cycle de vie équivalent à celui de ses services. En résume [7.], il faut penser qu un bundle traite de code statique et de dépendances à la compilation, alors qu un composant traite du niveau instance et de dépendances à l exécution. Une caractéristique importante d OSGi est qu il n y a pas de modèle d application. En effet, l utilisation d un modèle d application comme, par exemple, un ADL (architecture description language) se prête mal à l informatique pervasive et au cas d utilisation abordé à l origine par OSGi (cf. section 2 : OSGi : Histoire et Motivation). En effet, dans ces cas d utilisation, on cherche à réifier des services/équipements disponibles sur le réseau domestique ou d entreprise dans la plate-forme ; or un ADL définit statiquement et par extension l architecture de l application. Par conséquent si l on souhaite prendre en charge la disponibilité de ces équipements, cela implique la modification de l ADL. Or si c est le contexte d exécution qui définit le modèle de l application alors ce modèle ne définit pas l application qui doit s exécuter mais celle qui est en train de s exécuter : dans ce cas l ADL n est pas un ADL mais une modélisation de l architecture en exécution. De manière plus générale il est difficile de définir un modèle par extension d une application car cela va à l encontre d une passerelle à service ouverte (open service gateway). Par conséquent, la façon de définir une application suivant la philosophie d OSGi s apparente à une composition par contrat où le dynamisme des dépendances est géré de façon programmatique dans le bundle. Conséquemment, on peut définir la notion d application à deux niveaux : au niveau module et au niveau plate-forme. Si on raisonne au niveau module, alors chaque bundle définit une micro-application qui peut interagir avec d autres ; cette interaction est contractualisée et donc ne dépend pas d une autre micro-application en particulier mais d une fonctionnalité. De ce point de vue il y a autant d applications que de bundles. Si on raisonne au niveau plate-forme, alors l application peut être vue comme étant l ensemble des bundles et des équipements réifiés en cours d exécution. Selon ce point de vue, il n y a qu une et unique application sur la plate-forme. Nous pensons que la notion d application dans OSGi se situe entre ces deux extrêmes. Dans tous les cas, dans OSGi la modification dynamique des dépendances se fait au niveau module et non au niveau passerelle. 3.5 Conclusion En conclusion, OSGi spécifie une plate-forme d exécution pour des applications dynamiques. Cette plate-forme est basée sur trois couches (cf. Figure 9): 19

Bundle Bundle 1. La couche module définit le concept de bundle ainsi que les mécanismes nécessaires au partage des classes et des ressources. Cet aspect de module est à la base même du dynamisme dans OSGi. 2. La couche cycle de vie définit les différents états 3 par lesquels peux transiter OSGi 1 un bundle ainsi que les Figure 9 Les 3 mécanismes dans OSGi différentes opérations d administration sur ces derniers. 3. La couche service définit les mécanismes d interaction des instances entre les bundles. 2 Ces trois couches permettent le partage aussi bien des classes que des instances tout en maintenant un faible couplage entre les modules. Ces mécanismes permettent la modification de l architecture en cours d exécution. Les aspects de modularité et de dynamicité influent sur la définition d une application dans OSGi. Par conséquent dans OSGi, une application est une composition de modules dont les interactions sont définies contractuellement ; de cette façon il est possible de substituer une interaction par une autre. Par contre, autant le partage des classes par la couche module est géré par la plate-forme, autant le partage des fonctionnalités en terme de services est à la charge des développeurs de bundle. Or nous avons vu que la gestion des dépendances par le bundle est un aspect critique pour le dynamisme de l «application». Cette gestion manuelle des dépendances est donc une source d erreur : une erreur de gestion de dépendances d un bundle (e.g. : stale reference, ) peut nuire à la dynamicité de toute la plate-forme. Il est donc recommandé d utiliser des outils qui automatisent cette gestion. 20

4 Intergiciels Dans les sections précédentes nous avons abordé les mécanismes fournis par la plate-forme OSGi pour exécuter des applications «dynamiques». Nous avons observé trois choses : La gestion du partage d instance de service est manuelle et propre à chaque bundle. Cette gestion est un aspect critique du dynamisme de la plate-forme. Le cycle de vie des services n est pas nécessairement équivalent au cycle de vie du bundle. En d autres termes, un service peut apparaitre ou disparaitre alors que son bundle est toujours en état actif. Une application dans OSGi est une composition de bundle en interaction. Le problème soulevé par le premier point peut être résolu en automatisant la gestion des dépendances. Les deuxième et troisième points sont problématiques pour l adaptation de l environnement d exécution, car d une part il n est pas possible d agir sur un service en particulier (création, destruction ) et d autre part la composition en terme de bundle se prête mal à la modélisation du but d une application (e.g. : ADL). On aimerait pour cela avoir un modèle similaire au composant qui fournirait les opérations d administration et un accès au cycle de vie des implémentations de services. L approche à composant ne peut pas être réutilisée telle quelle car elle possède une limitation non négligeable dans le cas d OSGi qui est la staticité de l architecture de l application. Dans [8.], Humberto Cervantes explique le fait qu en général les implémentations de l approche à composant sont limitées vis à vis de la possibilité de supporter la disponibilité dynamique car : Les applications sont assemblées en phase de conception et non à l exécution. Dans les applications composées de façon déclaratives, le but de l application est défini par extension et n autorise donc pas les changements à l exécution. Dans le cas d une composition impérative, il est possible de reconfigurer l application (création et destruction d instance, établissement de connexion) mais seulement avec des classes de composants déjà disponibles durant la phase de conception. La disparition d une classe de composant à l exécution n est pas une hypothèse de l approche à composants. Pour combler cela, H. Cervantes propose d introduire l approche orientée service pour la communication entre les composants d un modèle à composant. Il nomme cette approche : composant orienté service (Service-Oriented Component) [8.][9.]. En résumé, nous avons vu que développer directement des applications dynamiques sur OSGi peut être compliqué. Il est donc recommandé d utiliser des intergiciels qui automatisent la gestion des dépendances. D autre part, mettre en place des mécanismes d adaptation est compliqué car l administration des services est limitée et l état courant de l architecture en terme d instances est incomplet. L utilisation de l approche composant orienté service permet de résoudre ces problèmes tout en préservant le dynamisme de la plate-forme. Dans cette section, nous allons brièvement expliquer l approche à composant orienté service. Puis décrire brièvement trois intergiciels utilisant cette approche : Declarative Services, Blueprint et ipojo. 21