O S G I. Modèle de composants dynamiques A.U. 2010/2011. Ecole Supérieure de Technologie et d Informatique

Transcription

1 Ministère de l Enseignement Supérieur, de la Recherche Scientifique et de la Technologie Université du 7 Novembre à Carthage Ecole Supérieure de Technologie et d Informatique A.U. 2010/2011 O S G I Modèle de composants dynamiques Définit un conteneur de déploiement dynamique d applications Canevas d exécution de services Java avec un faible couplage Résolution des dépendances versionnées de code Multi-fournisseur, télé-administré Cible: set top box, passerelle résidentielle dédiée, contrôle industriel, téléphonie mobile Source principal: Didier Donsez Université Joseph Fourier (Grenoble 1) PolyTech Grenoble LIG/ADELE

2 Table des matières Table des matières Problématique Modèle à base de composants dynamiques La Technologie OSGI Standard Framework OSGI Environnement d exécution Modules Cycle de vie Annuaire de service Bundles Modèle de Services Services standrads Services framework Services systèmes Services protocolaires Autres services Concepts OSGI Application Java Le composant OSGI: Bundle Conclusion... 23

3 1. Problématique La complexité des logiciels ne cessent de s accroîtrent avec une vitesse gigantesque. Un grand part de cette complexité vient du fait que le cycle de vie de produit a été très réduit que se soit dans son développement, ou son déploiement. Le but étant de bien gérer les variations que ce soit du côté matériel que se soit du côté logiciel autour d un même produit. De ces jours nous observons que le développement de logiciel se concentre plus sur des efforts d adaptation de produits existants pour offrir de nouvelles fonctionnalités. Ces efforts d adaptation de briques existantes ont provoqué un problème de montée en complexité, du fait de la dépendance des briques les uns des autres et le besoin de répondre le plus rapidement possible à une exigence du marché. Bien sûr que le développement entier de logiciels restent le plus coûteux, par contre intégrer sans règles précises et sans standard nous mène à des échecs certains. La clé derrière tout ceci est la commutation totale vers la mise en place de normes et standard permettant l intégration intelligente et ordonnée de composants réutilisables, robustes et à bas prix que se soit dans l avant vente que se soit dans l après vente. 2. Modèle à base de composants dynamiques Les modèles à base de composants viennent naturellement pour répondre à la problématique ci-dessus dans le but d assurer un développement modulaire et une maintenance plus aisée des applications. Parmi les principaux modèles, on peut citer : - JavaBeans [Sun97], - EJB[Sun01], - CCM [OMG99]. Pour rappel, un composant est un module logiciel décrit par des contrats proposés, des contrats requis, des propriétés configurables et par des contraintes techniques. Les contrats sont définis par des interfaces et des événements. De ce fait, les applications sont obtenues par assemblage (ou tissage) de composants configurés. L assemblage consiste à connecter les composants entre eux par les contrats requis et fournis. L exécution de l application est démarrée lorsque ses composants sont déployés sur la plate-forme à composants (qui peut être distribuée sur plusieurs hôtes). Chaque composant est pris en charge par un conteneur dont le rôle consiste à isoler le composant de l environnement et de prendre en charge les contraintes techniques liées aux aspects non fonctionnels (distribution, persistance, fiabilité, sécurité, ). Traditionnellement, le cycle de vie de l application suit les phases strictement successives de développement, assemblage, configuration, déploiement et exécution. La maintenance de l application comporte généralement des opérations de reconfiguration et d adaptation de composants. La reconfiguration consiste à changer les valeurs des propriétés des composants. L adaptation consiste en général à remplacer un composant par un autre qui peut éventuellement fournir et requérir des contrats différents du composant initial. L adaptation revient à déconnecter le composant de l application, à transférer son état courant vers un nouveau composant et à connecter ce dernier à l application. Traditionnellement, l opération d adaptation requiert généralement l arrêt de l application et oblige à reprendre le cycle de vie à partir de la phase d assemblage. L adaptation peut être réalisée pour corriger le mauvais comportement d'un composant, pour répondre aux changements affectant

4 l'environnement d'exécution, pour étendre l'application avec de nouvelles fonctionnalités ou pour améliorer ses performances. L'adaptation est un événement de plus en plus fréquent dans le cycle de vie d'une application. L'opération d'adaptation doit répondre à plusieurs contraintes comme la sécurité, la complétude et la possibilité de retour en arrière au cas où l'adaptation ne peut se terminer avec succès. L adaptation dynamique consiste à introduire des modifications dans l application au cours de son exécution contrairement à l approche traditionnelle qui nécessite l arrêt total de l application. Le bénéfice essentiel est l amélioration de mis sur le marché de nouveau produit par la réduction du coût de développement parce que cette techno offre le moyen d intégration de briques compilés (prêtes à l emploi), testés et configurables. Cette technologie offre aussi bien l avantage de réduire le coût de déploiement et de maintenance avec des configurations différentes qui pourront satisfaire le marché et s adapter sur le plan coût et sur le plan fonctionnel répondnat aisni à un marché dynamique, exigeant et extrêmement concurrentiel 3. La Technologie OSGI Le standard OSGI implémente un modèle de composants dynamique et complet, comblant un manque dans les environnements Java/VM traditionnels. Les applications et composants (se trouvant sous la forme de bundles pour le déploiement) peuvent être installés, arrêtés, démarrés, mis à jour et désinstallés de manière distante sans nécessiter de redémarrage ; la gestion des classes/paquetages Java est spécifiée de manière très détaillée. La gestion du cycle de vie est effectuée à travers une API en appliquant une politique de gestion des téléchargements distants. Le référentiel (registry) de services permet aux bundles de détecter l addition de nouveaux services, ou la suppression de services et de s'y adapter. 1. Standard Open Services Gateway Initiative (OSGi) est une corporation indépendante qui a pour but de définir et de promouvoir des spécifications ouvertes pour la livraison de services administrables dans des réseaux résidentiels, véhiculaires et autres types d'environnements. OSGi définit la spécification d'une plate-forme de services qui inclut un modèle à composants minimal et un framework de petite taille pour administrer les composants. Les composants sont conditionnés dans un format spécifique. L'objectif original se focalisait sur les passerelles (gateways) de services mais sa mise en application s est avérée bien plus étendue. Les spécifications sont désormais utilisées dans plusieurs domaines allant de l informatique embarquée autour des applications des téléphones

5 portables à d autres domaines d'application incluant les automobiles, l automatisme industriel, la gestion de flottes et les serveurs d'applications. Les spécifications OSGi sont si largement applicables parce que la plate-forme permet à plusieurs composants Java basée à coopérer efficacement dans une seule machine virtuelle Java (JVM). Il offre un vaste modèle de sécurité de façon que les composants peuvent fonctionner dans un environnement sécurisé. Toutefois, avec les permissions adéquates, la réutilisation et la coopération entre les composants sont possibles, L adoption des spécifications OSGi peut donc réduire les coûts de développement de logiciels ainsi que de fournir de nouvelles occasions d'affaires Exemple d applications Une Imprimante Photocopie est installé en location chez un client (26% du Marché de Ricoh) : Le loueur (organisme financier) facture mensuellement à la consommation : Fixe mensuel + tarif par feuille Le Loueur gère les dispositions contractuelles à distance Le loueur soustraite la maintenance simple à une société spécialisée La société de maintenance réalise un diagnostic à distance avant d envoyer un agent L agent de maintenance interroge sur place le logiciel de diagnostic Le fabricant peut mettre à jour le logiciel embarqué

6 2. Framework OSGI Le Framework OSGI offre une plateforme standardisé pour des applications (bundles) pour s exécuter. Il est divisé en 4 couches : L0 : Env d exécution L1 : Modules L2 : Gestion de cycle de vie L3 : Service de registry 2.1 Environnement d exécution Cette couche est la couche d exécution correspondante à l environnement Java2: J2SE. La plateforme OSGI a aussi spécifié un environnement d excution minima allant avec les devices en carence de ressources mémoire et s daptant avec les ressources nécessaires par les bundles. 2.2 Modules Cette couche définit la les régles de chargement des classes. Le Framework repose essentiellement sur Java basé sur une unique classpath qui doit décrire toutes les endroits de ressources.le OSGI rajoute une couche supplémentaire au niveau de chaque module avec une classpath privée pour la recherche des classes en cours d exécution ou en cours de linkage. Cette couche déploie aussi une architecture sécurisée faisant abstraction aux différents domaines de constructeurs.

7 2.3 Cycle de vie Cette couche gère le cycle de vie des bundles dynamiquement:install, start,stop, update, uninstall. Les bundles seront chargés par la couche module mais rajoute une API standard pour une gestion dynamique. Un mécanisme de dépendance dynamqiue est mis en œuvre afin d assurer cette gestion et de préserver l intégrité et la sécurisation de l environnment. 2.4 Annuaire de service Cette couche rajoute un modèle de cooperation dynamique entre les bundles. Les bundles peuvent coopérer via le partage de classes clasique. Mais si nous rajoutant l aspect install/uninstall de code. Un certain nombre d évenment au sein de ce modèle est prévu pour gérer la montée et la disparition de services dans le système. Less ervices sont en fait des Objets serveurs comme le serveur http. 2.5 Bundles Un bundle est une unité physique de livraison ainsi qu'un concept logique employé par le framework pour organiser son état interne. Concrètement, un bundle est une archive Java qui contient un manifeste et un ensemble de classes, des bibliothèques de code natif et d autres ressources associées. Un bundle installé est identifiable de manière unique.

8 3. Modèle de Services Les services OSGi sont simplement des définitions d'interfaces Java avec une sémantique précise et tout objet qui implémente une interface de service est supposés obéir à son contrat. 3.1 Services standards L alliance OSGI a définit un certain nombre de services standards par le biais de Java Interface. Les Bundles peuvent implémenter ces interfaces et enregistre ensuite ce service dans la registry. Les clients peuvent rechercher ces services dans la registry ou reste en écoute quand au montée ou descente de ces services. Ceci est très similaire aux architectures SOA avec la différence que les SOA repose essentiellement sur les web services qui implémente une couche de transport pour véhiculer les données (SOAP/http). OSGI repose sur les mécanismes d invocation directes de tant plus que les composants OSGI réagit dynamiquement à l apparition et la disparition des services Dans ce qui suit un bref aperçu des services disponibles. A noter que chaque service est définit d une façon abstraite et peut être implémenté par différents constructeurs. 3.2 Services framework.les services Framework sont les suivants: Gestion des permissions: les permissions accordés au bundles existants et futures sont à gérer à ce niveau. Les permissions sont prises en compte immédiatement une fois définis

9 Administration des packages : Les Bundles partagent les packages avec les classes et ressources. Quand un bundle est mis à jour, il y a nécessité de recalculer ses dépendances. Ce service fournit les informations concernant l état des partages des packages et offre la possibilité de rafraîchir cet état. Niveau de lancement (Start Levels) Il s agit des bundles pré requis qui doivent être lances (ou initialisés) avant que d autres démarrent. Gestion des URL Ceci donnant la possibilité de faire collaborer plusieurs plateformes OSGI issus de plusieurs constructeurs. 3.3 Services systèmes Les services systèmes offrent des fonctionnalités horizontales nécessaires dans différents systèmes. Service de Journalisation Les informations de trace: warnings, debug, erreurs est gérés à ce niveau. Ce service reçoit les entrées du journal, puis envoie ces entrées à d'autres bundles qui ont souscrit à ce service. Service d Administration et de Configuration Ce service fournit un modèle dynamique, flexible afin de fixer et obtenir des informations de configuration. Device Access Service Device Access OSGi est le mécanisme pour trouver un pilote pour un nouvel appareil et de télécharger automatiquement un ensemble d'application de ce pilote. Il est utilisé pour Plug-and-Play scénarios. Service d administration des utilisateurs Ce service utilise une base de données avec les informations utilisateur (privé et public) pour fins d'authentification et d'autorisation. Service de para métrisation (préférences) Ce service donne accès à la base de données hiérarchique de propriétés, similaire à le Registre de Windows. Gestion de composants Le caractère dynamique des services (pouvant se charger/ décharger à tout moment) rend difficile l'écriture de logiciel. La spécification des

10 component Runtime permet de simplifier le traitement de ces aspects dynamiques en utilisant le formalisme XML pour décrire les dépendances. Administration des déploiements Le premier type de déploiement OSGi est le bundle, qui est un fichier JAR / ZIP. Ce service rajoute un nouveau format combinant le bundles avec des ressources propres en un seul livrable. Administration des événements De nombreux événements ont des interfaces spécifiques, ce qui rend difficile de recevoir et de filtrer les événements de manière générique. Ce service fournit un cadre générique et thématique, Administration des Applications Le bundle Osgi est différents des applications usuelles : desktop ou mobile. Ce service prévoit la gestion de telle application avec l allocation des ressources nécessaires 3.4 Services protocolaires The OSGi Alliance has defined a number of services that map an external protocol to an OSGi service. Service Http Ce service s exécute sous forme de servlet. Les bundles peuvent fournir des servlets qui pourront être accessible par le service http. Ce service fournit un serveur web très attractif avec toutes les possibilités d administration à distance pour charger / décharger de nouveaux servlets. Service UPnP Universal Plug and Play (UPnP) est un nouveau standard pour partager les ressources multimédia entre plusieurs équipements électronique. Ce service fournit une correspondance (passerelle) entre les les devices Upnp sur le réseau avec la registry. Et vice versa des services OSGI peuvent être exposé au réseau UpNP. 3.5 Autres services Wire Admin Service Normally bundles establish the rules to find services that they want to work with. However, in many cases this should be a deployment decision. The Wire Admin service therefore connects different services together as defined in a configuration file. The Wire Admin service uses the concept of a Consumer and Producer service that interchange objects over a wire. Service de parsing XML Ce service permet à un bundle de retrouver un parser avec les spécifités voulus. Service d accès aux applications distantes

11 4. Concepts OSGI 4.1 Application Java Un application java classique utilise un certains nombre de fichiers Jar placés statiquement sous $CLASSPATH ou $JRE_HOME/ext/lib. Ce type de conditionnement conduit généralement à deux problèmes. Le premier est l'absence d'une classe dans un des fichiers JAR listés dans le CLASSPATH et dans le $JRE_HOME/lib/ext qui provoque l'abandon d'une exécution de l'application qui peut être fort avancée. Le second problème concerne l'incompatibilité de version des classes présentes dans l'environnement opérationnel avec celui qui a servi à compiler l'application. Ceci provoque également des erreurs non récupérables à l'exécution. OSGi remédie à ces deux problèmes en introduisant la notion de bundle. 4.2 Le composant OSGI: Bundle Il représente l unité fonctionnelle : composant qui offre des services. Physiquement c est l unité de livraison et de déploiement versionnée sous forme de fichier Jar contenant le code binaire des classes, des ressources comme des fichiers de configuration ou des images, et des bibliothèques de code natives (c.a.d. dépendant du processeur et du système d'exploitation). De ce point de vue une application est un ensemble coopératif de bundles livrés dynamiquement. Dans OSGi, les bundles sont utilisés pour conditionner et livrer les services avec leurs implémentations et leurs ressources. Les services sont les unités principales de construction 'applications dans le framework OSGi, et la plupart des services OSGi sont construits en

12 éparant l'interface de son implémentation. Ceci a comme résultat que les applications OSGi sont construites exclusivement à partir de ces interfaces et qu elles n'ont aucune connaissance de leurs implémentations. De plus, les Une plate-forme a composants adaptables au dessus d OSGi 5 applications sont construites de façon dynamique, au moment où de nouveaux services apparaissent ou disparaissent. LA structure d un bundle est la suivante :

13 Cycle de vie d un bundle OSGI spécifie un modèle dynamique. Les bundles ont un cycle de vie indépendant de celui de la plateforme Java. Il est alors possible de les installer, désinstaller, mettre à jour, arrêter, démarrer sans redémarrer la plateforme Java. Il en est de même pour la gestion des configurations et de la sécurité entre autres que l on peut modifier dynamiquement. Le passage automatique à l état RESOLVED ne se fait que si toutes les classes que nécessite le bundle sont disponibles. De cet état le bundle est prêt à démarrer A la fin de starting propre, le bundle enregistre les services dans le service registry et obtient les services dont il a besoin. Ses services seront éliminés du registry une fois il a stoppé.

14 Dépendance et dynamisme Présentation de Service Le service au sens OSGI est composé de : -un ou plusieurs interfaces - multiples implémentations possibles conditionnées dans les bundles - normalement non publiques - se trouve dans différents packages - Qualifiés par des propriétés

15 package org.device.print; public interface PrintService { public Job print(inputstream in, Dictionary printparams) throws PrintException; public Job[] list(); public interface Job { public final static int STATUS_WAITING=0; public final static int STATUS_ACTIVE=1; public final static int STATUS_STOPPED=2; public final static int STATUS_COMPLETED=3; public final static int STATUS_KILLED=4; public int getjobid(); public int getremainingpages(); public int getpages(); public int getstatus(); public void kill() throws PrintException; public class PrintService extends Exception { public interface Constants { public final static String TYPE="org.device.print.type"; public final static String DPI="org.device.print.dpi"; public final static String COLOR="org.device.print.color"; public final static String NPM="org.device.print.npm";

16 Les données de description Les méta-données d un bundle contiennent les informations nécessaires à l administration du bundle par le framework. Elles sont décrites dans un fichier associé au JAR du bundle appelé manifeste. Le manifeste contient un ensemble de paires attribut - valeur. Certains attributs sont standardisés par la spécification OSGi. Ils décrivent le chemin des classes (classpath) du bundle, les packages Java exportés ou importés par le bundle, Le manifeste peut également contenir un attribut qui spécifie une classe d'activation du bundle appelée «activateur» (Activator). L'activateur joue un rôle important car il permet au bundle d obtenir un contexte pour accéder aux fonctionnalités du framework. Le contexte permet aux bundles de rechercher des services dans le registre de services du framework, d enregistrer leurs propres services, d accéder à d'autres bundles et d installer des bundles additionnels. La classe activateur enregistre chaque service avec au minimum le nom de l interface qu il implémente, et éventuellement des propriétés supplémentaires (version, ). La Recherche de services se fait au moyen d une requête LDAP simple qui peut limiter la recherche à l ensemble des services qui ont des propriétés spécifiques (e.g. version>2.0). Une requête peut retourner zéro ou plusieurs références de services. Un bundle OSGi peut livrer des bibliothèques de fonctions natives. Ces bibliothèques sont décrites dans le manifeste grâce à l'entrée Bundle-NativeCode. Cette entrée décrit le chemin dans le fichier JAR, le processeur cible et le système d'exploitation requis. Une bibliothèque peut être liée à la JVM quand le bundle est activé et déliée quand le bundle est arrêté. Le chargeur vérifie préalablement la compatibilité du processeur et du système d'exploitation de la plate-forme avant de lier la bibliothèque. Cependant seuls les objets créés par le bundle peuvent invoquer les fonctions de la bibliothèque liée. L'invocation se fait via le mécanisme des JNI (Java Native Interface)

17 Permet en cours d exécution d importer des packages non présents à la résolution _ activator.getclass().getclassloader().loadclass(clazzname)

18 En introduisant le bundle comme l unité de deployment, OSGI impose la déclaration explicite des dépendances : Import-Package: org.osgi.framework;1.3 org.device.print; 1.0 Import-Service: org.device.print.printservice Bundle-Activator: org.eclipse.texteditor.impl.activator Bundle-Classpath:.;/lib/resources.jar Bundle-Name: TextEditor HP DeskJet Printer Import-Package: org.osgi.framework;1.3 org.device.print; 1.0, Export-Service: org.device.print.printservice, Bundle-Activator: com.hp.printer.deskjet.impl.activator Bundle-Name: HP Deskjet Printer HP OfficeDesk FaxPrinter : Import-Package: org.osgi.framework;1.3 org.device.print; 1.1, org.device.fax; 1.1 Export-Service: org.device.print.printservice, org.device.fax.faxservice Bundle-Activator: com.hp.printer.officedesk.impl.activator Bundle-Name: HP OfficeDesk FaxPrinter FaxServer Interface : Export-Package: org.device.fax; 1.1 Bundle-Name: FaxService Bundle-Version: PrintService Interface : Export-Package: org.device.print; 1.1 Bundle-Name: PrintService Bundle-Version: 2.0.1

19 Template de classe Bundle Le manifeste peut contenir un attribut qui spécifie une classe d'activation du bundle appelée (Activator). L'activateur joue un rôle important car il permet au bundle d obtenir un contexte pour accéder aux fonctionnalités du framework. Le contexte permet aux bundles de rechercher des services dans le registre de services du framework, d enregistrer leurs propres services, d accéder à d'autres bundles et d installer des bundles additionnels. La classe activateur enregistre chaque service avec au minimum le nom de l interface qu il implémente, et éventuellement des propriétés supplémentaires (version, ). La recherche de services se fait au moyen d une requête LDAP simple qui peut limiter la recherche à l ensemble des services qui ont des propriétés spécifiques (e.g. version>2.0). Une requête peut retourner zéro ou plusieurs références de services Le bundle ne requiert pas obligatoirement une classe activateur. Il peut être simplement une bibliothèque de packages Java qui ne nécessitent pas l accès au framework. Les classes publiques d activation du BundleActivator Start (BundleContext ctxt) Elle se déroule en général de la manière suivante : recherche des services nécessaires ou optionnels, liaison avec les services sélectionnés, création des objets implémentant les interfaces Java d'un contrat, enregistrement de ces objets comme des services avec les propriétés de courtage, positionnement d'écouteurs (listener) sur les événements de services, des bundles et de la plate-forme. Stop (BundleContext ctxt) Relâcher les références vers les objets de service utilisés et de libérer les ressources utilisées retrait des écouteurs désenregistrement des services enregistrés, Suppression des objets de services relâche des services auxquels il est lié, Libération de ressources, BundleContext Passé lors des appels de Start et stop de l activator et permet : 1. L enregistrement de services 2. Le courtage de services 3. L obtention et la libération des services 4. La souscription aux évènements du Framework 5. L accès aux ressources du bundle 6. L accès aux propriétés du framework 7. L installation de nouveaux bundles 8. L accès à la liste des bundles

20 Traitement des services L architecture OSGI permet un couplage faible entre bundles et un suivi de service à l exécution grâce aux notifications d évènements d apparition ou de disparition de service. C est un modèle SOA intra JVM. 1- Enregistrement de services (Lexmark Laser Printer) Import package org.osgi.framework package com.lexmark.printer.laser.impl; public class Activator implements BundleActivator { private ServiceRegistration reg=null; private PrintService theservice=null; public void start(bundlecontext ctxt) throws BundleException { theservice=new PrintServiceImpl(); Properties props=new Properties(); props.put("type", "laser"); props.put("dpi", "72,150,300,600,1200"); props.put("location", "1st floor"); reg=ctxt.registerservice("org.device.print.printservice", theservice, props); public void stop(bundlecontext ctxt) throws BundleException { if(reg!= null) reg.unregister();

21 2- Recherche de services (TextEditor) package org.eclispe.texteditor.impl import org.device.print.printservice; class Activator implements BundleActivator { public void start(bundlecontext ctxt) throws BundleException{ private PrintService ser; // Courtage : On va voir si quelqu'un offre un PrintService... ServiceReference[] temprefs =ctxt.getservicereferences ("org.device.print.printservice", "(location=1st floor)"); if(temprefs!=null) { System.out.println("Found a PrintService! I will use it!!!"); // On prend le premier offert! ser=(printservice) ctxt.getservice(temprefs[0]); Exemple de requêtes de Recherche de services Tous les services d impression refs=bundlecontext.getservicereferences("org.device.print.printservice", null); refs=bundlecontext.getservicereferences(null,"(objectclass=org.device.print.printservice)"); Certains services d impression refs=bundlecontext.getservicereferences("org.device.print.printservice", "(&(!(type=laser))(capability=double-sided)(!(dpi<=300))(location=*)" ); Tous les services de org.device refs=bundlecontext.getservicereferences(null,"(objectclass=org.device.*)"); Le service d impression et de fax au 3ième étage refs=bundlecontext.getservicereferences(null, "(&(objectclass=org.device.print.printservice)(objectclass=org.device.fax.faxservice)" + "(location=4th floor))" );

22 Traitement des evenments Les bundles «requesters» doivent impérativement prendre en compte l enregistrement et le retrait de services «importés». Dans l interface ServiceListener, la méthode servicechanged Permet le traitement séquentiel et synchrone des listeners public class PrintListenerActivator implements BundleActivator { private PrintServiceListener listener = null; public void start(bundlecontext context) { PrintServiceListener listener = new PrintServiceListener(context); context.addservicelistener(listener); public void stop(bundlecontext context) { context.removeservicelistener(listener); class PrintServiceListener implements ServiceListener { public void servicechanged(serviceevent e) { //Surcharge ServiceReference ref = e.getservicereference(); if(((string)ref.getproperty("objectclass").equals("org.device.print.printservice"))){ switch (e.gettype()) { case ServiceEvent.REGISTERED: println(ref + " has been registered by "+ ref.getbundle().getlocation()); break; case ServiceEvent.UNREGISTERING: println(ref + " is being unregistered"); break; case ServiceEvent.MODIFIED: println("properties of "+ref+" have been modified:"); String[] keys = ref.getpropertykeys(); for (int i=0; i<keys.length; i++) println(keys[i] + "=" + ref.getproperty(keys[i])); break; void println(string msg) { System.out.println("events: "+msg);

23 Le service d administration des événements Ce service permet d offrir un modèle de communication évenementiel entre les bundles. Le principe est basé sur le pattern Observer : création d un médiateur de publication-souscription d événement : - l éditeur poste un evenement au service EventAdmin - L EventAdmin le diffuse en parallèle à tous les souscripteurs du topic. - Chaque souscripteur enregistre un service EventHandler. - L'éditeur peut être synchronisé (ou non) sur la terminaison des exécutions de tous les services EventHandler concernés. 4. Conclusion OSGI apporte de l organisation à l exécution à la plateforme Java. C est un transfert de responsabilité du développeur au Framework OSGI. Le développeur est ainsi libérer de certaines tâches non essentielles et peut se consacrer pleinement au cœur de son métier : répondre aux exigences de son client. Il n est plus dans une intention constante d écriture de ligne de code, mais de composition et de réutilisation. Cette architecture de haut niveau a pour avantage d apporter de la discipline et de la lisibilité dans les développements des applications d entreprise.