OSGi Pas à Pas/Chap03

Précédent Sommaire Suivant

---

Modèles de Composants pour OSGi

Rédacteur(s): Didier Donsez, Thomas Calmant

Introduction

L'observateur de la section de code précédente est relativement simple car un ServiceListener complet doit traiter les expressions de filtre pour restreindre le nombre de services et prendre en compte les changements de propriétés. Il peut éventuellement agir sur le cycle de vie de l'utilisateur des services si la disparition de ceux-ci empêche un fonctionnement normal. Cette tâche devient ingérable quand le nombre de services utilisés grandit. Le constat est que la prise en charge de la dynamique des services est une tâche très lourde pour le développeur OSGi et qu'elle conduit à un taux élevé d'erreurs de programmation qui peut provoquer un blocage partiel de la plate-forme. Une première réponse à ce constat est la classe utilitaire ServiceTracker (paquetage org.osgi.util.servicetracker)qui comme son nom l'indique suit un service. ServiceTracker est limité par le fait qu'il ne traque qu'un seul service et ne gère pas le cycle de vie de l'objet utilisateur des services en fonction de leurs disponibilités effectives.

Declarative Service et Service Binder

Didier (source chapitre ICAR) http://www2.lifl.fr/icar/Chapters/OSGI/osgi-body.html#tth_sEc7.4.6

Le Service Component Runtime} introduit dans la spécification 4, propose un modèle à composants\cite{Szyperski:1998} orienté services qui capture la dynamique des services et assujettit le cycle de vie de l'objet utilisateur en fonction de la présence des services requis obligatoires. Le développement est grandement simplifié par la décription du composant au moyen d'un descripteur déclaratif dans une grammaire XML. Il reprend à son profit les principales idées de ServiceBinder}\cite{DBLP:conf/cbse/CervantesH04}\cite{/phd/2004/Cervantes} mais le complète cependant par la possibilité de retarder l'activation des bundles} fournisseurs de services jusqu'à la demande de liaison (méthode getService(ServiceReference) de BundleContext.

L'exemple suivant présente deux composants interagissant via un service d'impression.

Le composant fournisseur du service est décrit par par le descripteur suivant. Ce composant enregistre un service comportant une interface fonctionnelle PrintService et une interface technique ConfigMBean \footnote{qui permet la configuration du composant via un agent JMX \cite{jmx} embarquable sur la passerelle}) avec leurs propriétés d'enregistrement. Les propriétés déclarées sont utilisées pour qualifier le service fourni. Le fournisseur de service peut être une fabrique de services (non présenté dans l'exemple) qui délivre des services personnalisés à chaque composant utilisateur au lieu du singleton commun à tous.

<component name="printer">
    <implementation class="com.hp.printer.deskjet.impl.PrinterComp"/>
    <property name="org.device.print.type" value="inkjet" type="String"/>
    <property name="location" value="4st floor" type="String"/>
    <property name="jmx.objectName"
              value="printer.hp:name=DeskJet 930c 4st fl." type="String"/>
    <service>
        <provide interface="org.device.print.PrintService"/>
        <provide interface="com.hp.printer.ConfigMBean"/>
    </service>
</component>

Le composant utilisateur du service est décrit par le descripteur suivant. Ce composant sera instancié dès qu'un PrintService est disponible et sera détruit dés que le dernier PrintService se désenregistre. L'attribut cardinality indique si la liaison est simple ou multiple. Les méthodes de callback pour le contrôle de la liaison sont décrit par les attributs bind /unbind<~/code>. L'attribut policy indique un service qui disparaît est substituable par un autre équivalent. L'attribut target restreint le courtage à un sous-ensemble de services PrintService<~/code>. Le second élément reference automatise la liaison avec un service optionel de journalisation.

<component name="editor">
    <implementation class="org.eclispe.texteditor.impl.EditorComp"/>
    <reference name="PRINT"
            interface="org.device.print.PrintService"
            target="(&(location=*)(org.device.print.type=inkjet))"
            cardinality="1..n"
            policy="dynamic"
            bind="bindPrintService"
            unbind="unbindPrintService"
    />
    <reference name="LOG"
            interface="org.osgi.service.log.LogService"
            cardinality="0..1"
            policy="dynamic"
            bind="setLogService"
            unbind="unsetLogService"
    />
</component>

Les chemins des descripteurs de composants du bundle} sont listés dans l'entrée Service-Component du manifeste du bundle}.

SCR reprend à son profit les principales idées de ServiceBinder [Cervantes and Hall 2004][Cervantes 2004]. SCR le complète néanmoins par la possibilité de retarder l'instanciation de l'objet de service jusqu'à la demande de liaison effective par un bundle usager. Cette fonctionnalité permet de limiter l'usage des ressources de la machine hôte lorsque de nombreux services sont déployés sans être utilisés. SCR reste cependant un modèle de composants simple et non-hièrarchique qui ne prend pas en charge les aspects non fonctionnels comme la persistance, la sécurité, la distribution, les sessions, etc. Le développeur OSGi doit encore gérer ceux-ci de manière ad-hoc et non transparente.

Dependency Manager

Spring DM

Spring Dynamic Modules (DM)

Ex Spring/OSGi

iPOJO

iPOJO s'intéresse à l'ingénierie des conteneurs dynamiques pour les services OSGi par l'utilisation de la programmation orientée aspect ou bien encore par l'injection de code sur des POJOs (Plain Old Java Objects). Le conteneur iPOJO peut être étendu par des handlers (qui peuvent être eux-meme des composants iPOJO).

Les métadonnées peuvent être décrites de 3 manières possibles: entrée de Manifest, XML et annotations Java 5.0.

Blueprint

SCA

NaScCA, Frascati, Tuscani

Autres

• Newton
• EasyBeans/OSGi
• Juice/OSGi
• ...

Conclusion