Le document présente l'Open Service Gateway Initiative (OSGi), qui permet le développement indépendant de composants logiciels appelés plugiciels pour les applications Java. OSGi facilite la gestion du cycle de vie des services, permettant des mises à jour dynamiques sans interrompre l'ensemble de l'application. Il décrit également l'architecture, le fonctionnement et les étapes pratiques de création et d'installation d'un plugiciel avec OSGi.

1. OSGi: Open Service Gateway Initiative Nasreddine ABBASSI

2. Plan Introduction Un exemple de plugiciel Eclipse Extensions OSGi Architecture Gestion du cycle de vie Service d’enregistrement Environnement d’exécution Gestion du cycle de vie Gestion de besoin Architecture Implantation Test Suivi des problèmes Gestion des versions

3. 1. Introduction Aujourd’hui (et demain), les programmes Sont de plus en plus complexes Doivent être livrés de plus en plus rapidement Doivent fonctionner avec un minimum d’arrêt

4. 1. Introduction Les programmes nécessitent donc Une plateforme de programmation favorisant l’indépendance des composants Un format de livraison « standardisé » Une plateforme d’exécution permettant le remplacement à chaud Les programmes doivent donc être formés de composants réutilisables et interchangeables en cours d’exécution

5. 2. Definition: plugiciel « Un [plugiciel] est un programme qui interagit avec un logiciel principal, appelé programme hôte, pour lui apporter de nouvelles fonctionnalités » [Wikipedia] ils ne peuvent fonctionner seuls car ils sont uniquement destinés à apporter une fonctionnalité à un ou plusieurs logiciels ; ils sont mis au point par des personnes n'ayant pas nécessairement de relation avec les auteurs du logiciel principal.

6. 2. Definition: plugiciel L’ojectif derriere l’implementation des plugiciels est de permettre: L’ajout des fonctionnalités sans avoir à tout reprogrammer Permettre aux utilisateurs d'ajouter leurs propres fonctionnalités de manière indépendante Cette indépendance inclut la possibilité pour le logiciel principal d'évoluer tout en restant compatible avec les plugiciels existants ; cette condition est cependant loin d'être toujours remplie.

7. 2. Chargement de plugiciel Dans les architectures statiques, la structure des plugiciel est définie avant le lancement du logiciel ( par exemple dans un fichier de configuration) Dans les architectures dynamique c’est l’application qui va elle même recenser les plugiciels présents, Très souvent par examen de fichiers présents dans un répertoire dédié aux plugiciels. Exemple Eclipse. L’ajout et la suppression d’éléments dans le répertoire permet d’activer ou de désactiver les plugiciels correspondants. Certaines applications permettent le démarrage et l’arrêt d’un plugiciel pendant son fonctionnement. On parle alors de configuration à chaud ou hot-plug Toutefois, ce type d’architecture devient vite complexe du fait des dépendances qui peuvent exister entre les plugiciels.

8. Un exemple de plugiciel Eclipse

9. Un exemple de plugiciel Extensions Points d’extension point d'ancrage dans plugins le “provide” des composants ressemble à la déclaration d'une interface, le plugiciel informe qu’il est ouvert à l’ajout de nouvelles fonctionnalités d’une certaine façon mais description en XML précisant la grammaire que les meta-data des extensions doivent suivre Extension greffon attaché à un point d'extension (déclaration de la nouvelle fonctionnalité d’extension) le “require” des composants ressemble à une liaison entre une interface et une implémentation (description XML suivant la grammaire spécifiée par le point d’extension)

10. Un exemple de plugiciel Extensions Registre des extensions ( Extension Registry ) Match des points d’extensions aux extensions Les plugiciel interrogent cette base pour connaître les extensions qui leurs sont proposées. Chargement à la demande http://www-master.ufr-info-p6.jussieu.fr/2006/Ajouts/Master_esj_2006_2007/IMG/pdf/Eclipse-plugins-slides.pdf

11. 3. OSGi Considérons une classe java faisant partie d’une application et implémentant une fonctionnalité. Cette classe doit donc faire partie des .jar de l’application. En cas de bug dans cette classe, l’application complète doit être arrêtée afin que celui-ci soit corrigé même s’il n’affecte qu’une sous-fonctionnalité très rarement utilisée. La technologie OSGi permet de développer les fonctionnalités de façon indépendantes et de les intégrées dans l’application sous forme de services. Ces services peuvent être reliées dynamiquement à l’application Un service particulier pouvant être arrêté et mis à jour sans que le reste de l’application ne soit affecté.

12. 3. OSGi OSGi (Open Service Gateway Initiative) a é t é fond é par Ericson, IBM, Oracle et Sun Modèle à composants complet et dynamique Complémente la machine virtuelle Java Réduit la complexité : encapsulation, interface de programmation Réutilisation : composants depuis l’étagère Déploiement simplifié : gestion du cycle de vie Mises à jour dynamiques : voir ci-dessus Adaptation : les services peuvent aller et venir Transparence : composants indépendants [http://aneeshkumarkb.blogspot.com/]

13. OSGi Architecture Bundles = composants Services = publication, recherche et connexion dynamique d’objets Java Life Cycle = gestion du cycle de vie des objets (démarrage, arrêt, mises à jours, installation,…) Module = fonctions basiques de gestion (classloading, import, export,…) Security = gestion des aspects de sécurité Execution Environment = plateforme d’exécution [http://www.osgi.org]

14. OSGi La spécification de OSGi définit comment les bundles (composants) doivent être implémentés afin d’être intégrés à la plateforme OSGi. Elle se structure de la manière suivante: Un ensemble de services qu’un conteneur OSGi doit implémenter (Exple de conteneur: Equinox d’Eclipse) Un contrat entre le conteneur et les application

15. OSGi dans une application domotique

16. OSGi dans une application domotique

17. OSGi dans une application domotique

18. OSGi dans une application domotique

19. OSGi: Exemple Etape 1: Télécharger et sauvegarder un conteneur OSGi: Equinoxe par exemple dans C:/lab Etape 2: Créer la classe HelloOSGI.java suivante: package test.osgi.helloworld; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; public class Activator implements BundleActivator { public void start (BundleContext context) throws Exception { System.out.println("Hello World"); } public void stop (BundleContext context) throws Exception { System.out.println("Bye Bye"); } } Cette classe est comme une classe main usuelle, la méthode start() est le point de démarrage du bundle (composant)

20. OSGi: Exemple Etape 3 : Mettre à jour le path et compiler la classe # Set classpath=%classpath%;org.eclipse.osgi_3.4.0.v20080605-1900.jar # javac -d . HelloOSGi.java Etape 4 : Créer un fichier manifeste MANIFEST.MF contenant:

21. OSGi: Exemple MANIFEST.MF Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: HelloWorld OSGi Bundle-SymbolicName: test.osgi.HelloWorld Bundle-Version: 1.0.0 Bundle-Activator: test.osgi.helloworld.HelloOSGI Import-Package: org.osgi.framework

22. OSGi: Exemple Bundle-ManifestVersion: indique que le composant suit la spécification OSGi Bundle-Name: défini le nom du composant Bundle-SymbolicName: défini un nom de référencement pour le composant (ce nom sera utilisé par les autres composants) Bundle-Version: spécifie la version du composant Bundle-Activator: spécifie le nom de la classe listener à notifier des démarrages et arrêts du composant. Import-Package: définit les packages importés.

23. OSGi: Exemple Etape 5 : Créer ensuite le fichier bundle-jar # jar -cvmf MANIFEST.MF HelloOSGi.jar -C test/* Etape 6 : Démarrer le conteneur OSGi: #java -jar org.eclipse.osgi_3.4.0.v20080605-1900.jar -console Le prompt osgi> s’affichera. Etape 7 : Installer le bundle osgi> install file:/C:/lab/HelloOSGi.jar

24. OSGi: Exemple Etape 8 : Puis démarrer le bundle (composant) osgi> start file:/C:/lab/HelloOSGi.jar Vous verrez « Hello World » s’imprimer dans la console, votre composant est prêt! 

25. Cycle de vie d’un bundle OSGi

26. 4. Gestion du cycle de vie Gestion de besoin Architecture Implantation Test Suivi des problèmes Gestion des versions

27. Gestion du cycle de vie Problème de la traçabilité Besoins – conception Besoins – code Besoins – tests Besoins – bogues Besoins – versions Code – tests Code – bogues Code – versions