Programmation par composant avec la technologie OSGi (Partie 1)

La couche module permet la mise en œuvre des bundles dans le conteneur. Elle a la responsabilité de la gestion des différents chargeurs de classes et des versions des dépendances.

En effet, une des caractéristiques de la technologie consiste en l'isolation des classloaders des composants. En effet, chaque composant ou bundle OSGi dispose d'un classloader indépendant pour ses traitements. Cet aspect permet par exemple la mise en œuvre dans deux bundles différents d'une même bibliothèque avec deux versions différentes et incompatibles.

Cet aspect offre la possibilité à OSGi de complètement maîtriser les classes et packages du composant visibles depuis l'extérieur et visibles par les autres composants. Par défaut, la stratégie est la plus restrictive possible, à savoir que rien n'est visible. Par contre, lors de la mise à disposition d'un package d'un composant, un numéro de version spécifique peut être spécifié. Ainsi, deux versions de packages peuvent coexister dans le conteneur OSGi sans aucun problème.

Comme dans tout conteneur, les éléments contenus dans ce dernier possèdent un cycle de vie bien particulier puisque le conteneur OSGi a la responsabilité de les gérer. Nous pouvons distinguer deux grandes parties dans les différents états supportés :

• Non opérationnel. Les états correspondent à la présence du bundle dans le conteneur, mais ce dernier n'est pas utilisable par les autres bundles pour leurs traitements;
• Opérationnel. Les états de ce type correspondent aux moments où le bundle est utilisable ou en phase de l'être ou de ne plus l'être.

La figure suivante illustre les différents états de gestion des bundles par le conteneur ainsi que leurs enchaînements possibles:

Nous verrons par la suite que le conteneur OSGi offre une API standardisée afin de gérer le cycle de vie des composants. Veuillez vous reporter à la section 5.2 BundleContext pour plus de précisions. De plus, ces différents états sont mis en œuvre par le bundle manager du conteneur qui a la responsabilité de gérer la plateforme.

Le tableau suivant récapitule les différents états supportés par le bundle manager des conteneurs OSGi ainsi que leurs principales caractéristiques :

Nous pouvons noter qu'une entité peut être associée au cycle de vie des bundles et correspond à l'entité d'activation, entité appelée lors du démarrage et de l'arrêt d'un bundle. Cette entité peut être mise en œuvre par l'intermédiaire de l'interface BundleActivator et configurée avec l'en-tête Bundle-Activtator. Nous reviendrons plus en détail sur ce mécanisme dans la section 5.1 BundleActivator.

Nous pouvons noter que la plupart des conteneurs OSGi fournissent des outils afin de gérer le cycle de vie des bundles et de visualiser leurs états. Dans cette optique, le conteneur OSGi
Felix [11] offre une console d'administration en ligne de commande possédant les commandes suivantes :

Avec la console de cet outil, le conteneur peut être complètement administré à chaud en ligne de commandes. Le scénario suivant peut être mis en œuvre afin d'installer un bundle, de le démarrer, puis l'arrêter avec les commandes respectives install, start et stop. Le code suivant illustre concrètement l'enchaînement de ces différentes commandes :

-> ps
START LEVEL 1
   ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.0.0)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.0.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.0.0)
-> install /home/templth/developpez/OSGi/simplebundle.jar
Bundle ID: 3
-> ps
START LEVEL 1
   ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.0.0)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.0.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.0.0)
[   3] [Installed  ] [    1] Simple Bundle (1.0.1)
-> start 3
-> ps
START LEVEL 1
   ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.0.0)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.0.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.0.0)
[   3] [Active     ] [    1] Simple Bundle (1.0.1)
-> stop 3
-> ps
START LEVEL 1
   ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.0.0)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.0.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.0.0)
[   3] [Resolved   ] [    1] Simple Bundle (1.0.1)

La couche Services offre la possibilité de mettre à disposition certains traitements des composants par l'intermédiaire de services. Nous désignons par le terme service des traitements structurés de la manière suivante. Il s'agit d'une entité dont le contrat est clairement défini par l'intermédiaire d'une interface Java. Seule cette interface est connue par les consommateurs du service. La ou les implémentations du service doivent rester internes aux composants et implémenter la précédente interface.

Le mécanisme de gestion des services est complètement dynamique. En effet, dès qu'un service est enregistré, il est automatiquement utilisable par tous les composants disponibles dans le conteneur OSGi. Comme nous le verrons par la suite, une API est disponible afin d'enregistrer des implémentations de services. De plus, par convention, il convient de faire correspondre le nom du service au nom de l'interface implémentée.

Dans le cadre de la technologie OSGi, l'architecture orientée service a la caractéristique d'être très « légère » et de pouvoir fonctionner de manière autonome dans un seul processus Java. Elle correspond à un modèle de services dans une unique machine virtuelle (in-VM).

Nous verrons dans la section 5.1 comment mettre en œuvre concrètement des services dans le cadre de la technologie OSGi.

L'architecture de la technologie OSGi permet de mettre en œuvre des composants et de mettre à disposition des services applicatifs. Elle offre également un cycle de déploiement de services très rapides par l'intermédiaire du cycle de vie des bundles tout en offrant une meilleure structuration des fondations des applicatifs.

Nous pouvons remarquer que la sécurité est prévue en standard puisqu'elle fait partie intégrante de la spécification OSGi. Elle offre la possibilité de spécifier des permissions d'accès aux entités gérées par le conteneur. Une de ses principales caractéristiques consiste dans le fait que sa configuration est complètement dynamique et ne nécessite aucun redémarrage après une modification.

Rentrons maintenant dans le détail technique de la technologie OSGi et voyons concrètement comment la mettre en œuvre.

Avec la technologie OSGi, le concept de composant est mis en œuvre par l'intermédiaire des bundles, un bundle correspondant à un composant. Ces derniers permettent de mettre en œuvre les différents concepts des composants et ce sont eux qui sont déployés dans les conteneurs OSGi.

Avec OSGi, un composant (bundle) est simplement stocké dans un fichier JAR de Java. Les informations de déploiement sont spécifiées par l'intermédiaire du fichier standard MANIFEST.MF présent dans le répertoire META-INF. En effet, OSGi reprend ce fichier en y ajoutant différents en-têtes afin de configurer le composant.

Il n'est pas nécessaire d'ajouter d'autres éléments au fichier JAR si ce n'est les classes bien sûr et les éventuelles bibliothèques utilisées, uniquement les bibliothèques n'étant pas définies en tant que dépendances. Nous pouvons constater que cet aspect favorise de manière importante la simplicité de mise en œuvre de composants dans des conteneurs de ce type. Les conteneurs OSGi sont de ce fait très légers. N'oublions pas qu'OSGi était à l'origine utilisé dans des systèmes embarqués donc très soucieux de la consommation mémoire.

Les conteneurs possèdent diverses caractéristiques quant à la gestion des composants. Tout d'abord, ils ont la particularité de permettre la gestion des dépendances entre composants. En effet, comme nous l'avons vu précédemment, un composant s'appuie la plupart du temps sur d'autres afin de réaliser ses traitements et de fonctionner correctement. Pour ce faire, OSGi offre la possibilité de rendre visibles dans le conteneur les packages de composants de manière très fine. La gestion des versions des dépendances est également supportée.

Comme nous l'avons précisé dans la précédente section, le fichier MANIFEST.MF correspond au descripteur de déploiement du bundle. Ce fichier est lu par le conteneur OSGi afin de configurer le bundle.

La spécification OSGi définit un ensemble d'en-têtes standards pour un composant, en-têtes utilisables dans le fichier MANIFEST.MF et dont la liste des principales est récapitulée dans le tableau suivant :

Le code suivant illustre la configuration d'un composant OSGi simple dans le fichier MANIFEST.MF. Ce bundle est identifié par simple.bundle, possède le nom « Simple Bundle », exporte le package org.developpez.osgi.service et utilise l'entité d'activation org.developpez.osgi.SimpleActivator.

 

Cacher/Afficher le codeSélectionnez

Manifest-Version = 1
Bundle-Activator = org.developpez.osgi.SimpleActivator
Bundle-SymbolicName = simple-bundle
Bundle-Name = Simple Bundle
Bundle-Description = Simple Bundle.
Import-Package = org.osgi.framework;version=1.3
Export-Package = org.developpez.osgi.services
Bundle-Version = 1.0.1
Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt

Afin de mettre à des dispositions des packages (ou exporter) d'un bundle, l'en-tête Export-Package doit être mis en œuvre dans le fichier MANIFEST.MF du composant. Cet en-tête contiendra la liste des packages pour lesquels l'accès est possible.

Il est à noter que la spécification d'un package dans ce cadre autorise l'accès à toutes les classes du package tout en gardant inaccessibles les classes contenues dans les sous-packages du package.

Lors de l'exportation d'un package, OSGi offre la possibilité d'ajouter des informations complémentaires telles que la version et dont la liste est récapitulée dans le tableau ci-dessous :

La syntaxe complète d'une valeur pour la propriété Export-Package est donc la suivante :

 

Cacher/Afficher le codeSélectionnez

Export-Package: nom-package;parametre:=valeur,nom-package;parametre:=valeur,...

Notons que, si la valeur d'un paramètre est une liste, les éléments doivent être séparés par des virgules et la valeur globale doit être entourée par des guillemets.

Le code suivant correspond à un extrait de la valeur de l'en-tête Export-Package du fichier MANIFEST.MF d'un bundle OSGi pour Hibernate 3 [12]. Nous remarquons la présence des paramètres uses et version pour le packageorg.hibernate.stat.

 

Cacher/Afficher le codeSélectionnez

Export-Package: org.hibernate.stat;uses:="org.hibernate.util,org.hibernate.cache,
 org.apache.commons.logging,org.hibernate.engine";version=3.1.3,
 org.hibernate.cache;uses:="org.hibernate.util,net.sf.swarmcache,
 org.hibernate.cfg,org.hibernate,net.sf.ehcache,org.hibernate.impl,...

La technologie OSGi offre la possibilité de spécifier les packages utilisés afin qu'ils soient visibles dans le bundle. Une fois spécifiées, les classes sont utilisables dans les classes implémentées par le bundle. Cet aspect se configure dans le fichier MANIFEST.MF par l'intermédiaire des en-têtes Import-Package et DynamicImport-Package. Détaillons tout d'abord l'usage du premier en-tête.

Lors de l'importation d'un package, OSGi offre la possibilité d'ajouter des informations complémentaires telles que la version et le mode de résolution dont la liste simplifiée est récapitulée dans le tableau ci-dessous :

La syntaxe complète d'une valeur pour la propriété Import-Package est donc la suivante :

 

Cacher/Afficher le codeSélectionnez

Import-Package: nom-package;parametre:=valeur,nom-package;parametre:=valeur,...

Notons que, si la valeur d'un paramètre est une liste, les éléments doivent être séparés par des virgules et la valeur globale doit être entourée par des guillemets.

Le code suivant correspond à un extrait de la valeur de l'en-tête Import-Package du fichier MANIFEST.MF du bundle OSGi de Spring AOP 2.0.5. Nous remarquons la présence des paramètres resolution pour le package com.jamonapi et version pour le package org.springframework.aop.

 

Cacher/Afficher le codeSélectionnez

Import-Package: com.jamonapi;resolution:=optional,net.sf.cglib.core;resolution:=optional,
 net.sf.cglib.proxy;resolution:=optional,net.sf.cglib.transform.impl;resolution:=optional,
 ...
 org.springframework.aop;version=2.0.5,org.springframework.aop.aspectj;version=2.0.5,...

Dans le cas de l'importation de packages, l'en-tête DynamicImport-Package est également disponible. Il se différencie du précédent par le fait que la résolution des dépendances spécifiées à ce niveau n'est réalisée qu'au moment du chargement des classes et non lors du passage du bundle de l'état Installé à Résolu.

L'en-tête fonctionne sinon de la même manière que l'en-tête Import-Package, si ce n'est qu'il ne supporte logiquement pas le paramètre resolution.

La technologie OSGi offre la possibilité de spécifier une entité appelée lors de l'activation (état Démarrage) et de la désactivation (état En cours d'arrêt) d'un composant, c'est-à-dire lorsque ce dernier est démarré ou arrêté. La classe implémentant cette entité doit nécessairement posséder l'interface BundleActivator et être configurée par l'intermédiaire de l'en-tête Bundle-Activator dans le fichier MANIFEST.MF.

L'interface BundleActivator définit la structure d'une classe d'activation en définissant les signatures des méthodes appelées lors des différents événements précédemment cités :

• Méthode start, appelée lors le démarrage du composant (état Démarrage);
• Méthode stop, appelée quant à elle lors de l'arrêt du composant (état En cours d'arrêt).

Ces deux méthodes prennent en paramètre le contexte OSGi du composant par l'intermédiaire de l'interface BundleContext, interface permettant d'interagir aussi bien avec le conteneur qu'avec le composant. Le contenu de l'interface BundleActivator est décrit ci-dessous :

 

Cacher/Afficher le codeSélectionnez

public interface BundleActivator { 
    void start(BundleContext context);
    void stop(BundleContext context);
}

Le code suivant illustre la mise en œuvre d'une entité d'activation pour un bundle par l'intermédiaire d'une implémentation simple appelée ici SimpleActivator :

public class SimpleActivator implements BundleActivator {
    private ServiceRegistration serviceRegistration;

    public void start(BundleContext context) {
        // Enregistrement d'un service
        SimpleService service  = new SimpleServiceImpl();
        this.serviceRegistration = context.registerService(
                      SimpleService.class.getName(), service, null);
    }

    public void stop(BundleContext context) {
        // Désenregistrement d'un service
        if( this.serviceRegistration!=null ) {
            this.serviceRegistration.unregister();
        }
    }
}

Le code suivant décrit la configuration de cette entité par l'intermédiaire de l'en-tête Bundle-Activator dans le fichier MANIFEST.MF du bundle :

Manifest-Version = 1
Bundle-Activator = org.developpez.OSGi.SimpleActivator
Bundle-SymbolicName = simple-bundle
Bundle-Name = Simple Bundle
Bundle-Description = Simple Bundle.
Import-package = org.OSGi.framework;version=1.3
Bundle-Version = 1.0.1
Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt

Nous avons vu dans la précédente section que l'entité d'activation s'appuie sur le contexte du composant. Détaillons maintenant les spécificités de l'interface BundleContext, interface relative au contexte du composant. Cette dernière permet d'interagir aussi bien au niveau du conteneur OSGi lui-même que du bundle dans lequel il est utilisé. Elle offre la possibilité de réaliser les différentes opérations suivantes :

Le contenu de l'interface BundleContext est décrit dans le code ci-dessous :

public interface BundleContext { 
    void addBundleListener(BundleListener listener); 
    void addFrameworkListener(FrameworkListener listener); 
    void addServiceListener(ServiceListener listener); 
    void addServiceListener(ServiceListener listener,
                            Java.lang.String filter); 
    Filter createFilter(Java.lang.String filter); 
    ServiceReference[] getAllServiceReferences(Java.lang.String clazz,
                                               Java.lang.String filter); 
    Bundle getBundle(); 
    Bundle getBundle(long id); 
    Bundle[] getBundles(); 
    Java.io.File getDataFile(Java.lang.String filename); 
    Java.lang.String getProperty(Java.lang.String key); 
    Java.lang.Object getService(ServiceReference reference); 
    ServiceReference getServiceReference(Java.lang.String clazz); 
    ServiceReference[] getServiceReferences(Java.lang.String clazz,
                                            Java.lang.String filter); 
    Bundle installBundle(Java.lang.String location); 
    Bundle installBundle(Java.lang.String location,
                         Java.io.InputStream input); 
    ServiceRegistration registerService(Java.lang.String[] clazzes,
                                        Java.lang.Object service,
                                        Java.util.Dictionary properties); 
    ServiceRegistration registerService(Java.lang.String clazz,
                                        Java.lang.Object service,
                                        Java.util.Dictionary properties); 
    void removeBundleListener(BundleListener listener); 
    void removeFrameworkListener(FrameworkListener listener); 
    void removeServiceListener(ServiceListener listener); 
    boolean ungetService(ServiceReference reference); 
}

Détaillons maintenant les spécificités relatives aux bundles et aux observateurs. Cette interface offre tout d'abord la possibilité de gérer et récupérer les instances des bundles présents dans le conteneur. Tout d'abord, l'installation de bundles se réalise par l'intermédiaire des méthodes installBundle, méthode prenant en paramètre le chemin du fichier JAR du bundle. Les méthodes getBundle et getBundles retournent quant à elle une ou plusieurs instances de bundles. Sont supportées les récupérations du bundle courant, d'un bundle en se fondant sur son identifiant dans le conteneur ou de tous les bundles du conteneur.

Le code suivant illustre la mise en œuvre de ces méthodes dans une entité ayant accès au contexte OSGi :

// Installation d'un nouveau bundle
Bundle bundleInstalle = contexte.installBundle(
            "file:///home/templth/developpez/OSGi/simplebundle.jar");
long idBundle = bundleInstalle.getBundleId();

// Récupération d'une instance d'un bundle présent dans le conteneur
Bundle bundle = contexte.getBundle(idBundle);
int etatBundle = bundle.getState();

Comme vous pouvez le constater, le code précédent repose sur l'interface Bundle correspondant à l'entité relative à un composant OSGi. Cette dernière permet de récupérer des informations sur le bundle mais également de gérer son état. Le code suivant décrit le contenu de l'interface Bundle :

public interface Bundle {
    public static final int UNINSTALLED = 0x00000001;
    public static final int INSTALLED = 0x00000002;
    public static final int RESOLVED = 0x00000004;
    public static final int STARTING = 0x00000008;
    public static final int STOPPING = 0x00000010;
    public static final int ACTIVE = 0x00000020;

    Enumeration findEntries(String path, String filePattern, boolean recurse)
    BundleContext getBundleContext()
    long getBundleId()
    URL getEntry(String path)
    Enumeration getEntryPaths(String path)
    Dictionary getHeaders()
    Dictionary getHeaders(String locale)
    long getLastModified()
    String getLocation()
    ServiceReference[] getRegisteredServices()
    URL getResource(String name)
    Enumeration getResources(String name)
    ServiceReference[] getServicesInUse()
    int getState()
    String getSymbolicName()
    boolean hasPermission(Object permission)
    Class loadClass(String name)
    void start()
    void start(int options)
    void stop()
    void stop(int options)
    void uninstall()
    void update()
    void update(InputStream in)
}

Il est ainsi possible par la programmation, après l'installation d'un bundle, de réaliser le démarrage du bundle et de récupérer les différents services mis à disposition par le bundle puis de l'arrêter, comme l'illustre le code suivant :

// Installation d'un nouveau bundle
Bundle bundleInstalle = contexte.installBundle(
            "file:///home/templth/developpez/OSGi/simplebundle.jar");

// Démarrage du bundle (état installed vers active)
bundle.start();

// Récupération des services mis à disposition
ServiceReference[] serviceReferences = bundle.getRegisteredServices();

// Arrêt du bundle (état active vers resolved)
bundle.stop();

Pour finir, le contexte offre la possibilité de spécifier des observateurs d'événements sur le conteneur OSGi lui-même, sur les bundles et sur les services. Cet aspect est couramment utilisé dans les bonnes pratiques de mise en œuvre de la technologie OSGi, notamment par l'intermédiaire du patron de conception Extender [13] au niveau des bundles.

Le principe consiste en la mise en œuvre d'un observateur utilisant les données des bundles afin de réaliser des traitements. Ce patron permet de mieux gérer les états des bundles lors de traitements généraux, traitements pouvant être réalisés de manière paresseuse. Cette approche est mise en œuvre dans des outils tels que Declarative Services [14], iPOJO[15], Spring Dynamic Modules [16].

Un observateur de bundles peut être mis en œuvre par l'intermédiaire des interfaces BundleListener et SynchronousBundleListener, respectivement déclenchées de manière asynchrone et synchrone. Les deux interfaces mettent en œuvre la méthode bundleChanged afin de notifier un changement pour un bundle. Cette méthode prend en paramètre un objet de type BundleEvent, objet permettant d'avoir accès au bundle impacté et à l'événement déclencheur dans le cycle vie. Le code suivant illustre le contenu de l'interface BundleListener :

public interface BundleListener extends EventListener {
    void bundleChanged(BundleEvent event);
}

La mise en œuvre d'un observateur de bundles se réalise de la manière suivante :

// Enregistrement de l'observateur
BundleListener observateur = new BundleListener() {
    public void bundleChanged(BundleEvent evenement) {
        // Récupération du bundle impacté
        Bundle bundle = evenement.getBundle();
        int etat = evenement.getType();
        (...)
    }
};

context.addBundleListener(observateur);