Les travaux sur la dynamique du réseau domestique tentent de raffiner les approches du laboratoire Adèle, Service Binder [CeH03] et aujourd’hui iPojo [EHL07] par addition de techniques de sélection dynamique de services. Après un travail de catégorisation du contexte [2006-1], un premier prototype [2007-3] est construit au-dessus du cadriciel OSGi Declarative Services [OSGi05] qui est la normalisation de l’approche appelée Service Binder. Les aspects contextuels sont mieux séparés par l’usage de techniques à POJO (Plain Old Java Object) dans un deuxième prototype [2007-7].
1.2.1 OSGi Declarative Services
Le chapitre "Declarative Services" de la spécification OSGi spécifie un modèle de composants à service et un conteneur automatisant la composition de services de manière paire-à-paire au niveau de chaque composant tel qu'ils sont décrits dans la section Chapitre V.2.3. Cette spécification est la normalisation des concepts développés dans le projet Service Binder [CeH03]. Le conteneur appelé SCR (Service Component Runtime) affecte un gestionnaire de composition à chaque composant décrit dans un fichier de description du bundle (3 composants C et fichier metadata.xml sont indiqués dans le bundle de la Figure 65). Ce gestionnaire utilise les méthodes de requête, d'écoute d'événements et d'enregistrement de service du registre OSGi afin de satisfaire les dépendances et l'offre de services décrites dans les composants. Chaque dépendance de service est décrite par :
Figure 65 Bundle OSGi et composants à service
• Le nom d'une interface Java, dite de service
• Le filtre de service, filtre LDAP d'assertions booléennes attribut-opération-valeur
• La cardinalité de la liaison
o 0..1 – Optionelle et singulière.
o 1..1 – Obligatoire et singulière.
o 0..n – Optionelle et multiple.
o 1..n – Obligatoire et multiple.
• La politique statique ou dynamique de la liaison
Le cycle de vie est simplement défini par le diagramme d'état de la Figure 66. Le gestionnaire instancie chaque objet indiqué comme point d'entrée du composant dans le fichier de description. Pour chacun de ces objets, il attache un gestionnaire de dépendances pour chaque dépendance. Ces gestionnaires lie et délie les services recherchés. Dès que les dépendances obligatoires sont satisfaites, le gestionnaire de composant appelle la méthode d'activation. Si la politique est dynamique, les services peuvent être lié et délié dans l'état validate. Avec cette politique, le composant n'est invalidé que si une liaison obligatoire vient à n'être satisfaite par aucun service. Si la politique est statique, tout départ d'un service lié invalide l'instance qui est alors abandonnée ("destroyed") pour l'instanciation d'un autre objet.
Figure 66 Cycle de vie d'un composant selon "Declarative Services" 1.2.2 Solutions à base de "POJOs" : Spring DM et iPOJO
POJO est un terme signifiant "Plain Old Java Object" ou "le bon viel objet Java". Ce concept a été introduit par Martin Fowler, Rebecca Parsons et Josh MacKenzie en l'an 2000 pour parler d'objets simples en dehors de tout modèle à composants complexe. L'utilisation de POJOs met en exergue le retour de cadriciels Java qui n'impliquent pas la soumission des développements à un modèle complexe. Les deux principaux cadriciels qui fournissent cette approche est les cadriciels pour serveurs d'application que sont EJB3 et Spring. Après analyse d'annotations laissées par le développeur dans le code, ils génèrent du code binaire (bytecode) pour la projection d'un modèle à composants dans le code au déploiement.
iPojo [EHL07] est une technique à POJO proposée dans la suite du projet Service Binder de l'équipe Adèle dont sont issus ces travaux de thèse et développée au sein du projet Apache felix. iPojo génère les gestionnaires du cycle de vie des composants à service déclarés dans une nouvelle syntaxe XML ou dans les annotations du code des bundles OSGi. Plus loin, iPojo propose la gestion de tout aspect fonctionnel par un conteneur au modèle quasiment transparent pour le développeur. Le développeur doit toutefois indiquer dans les techniques à POJO dans quels champs d'objets injecter les dépendances.
1.2.3 Pertinence et extensions pour le Home SOA
Le modèle d'automatisation de la composition de service est une technique du Home SOA (cf. Chapitre V.2.3) qui est réalisée par le modèle OSGi Declarative Services.
Description des dépendances et cycle de vie dont le contrôle est délégué à un conteneur. Le conteneur prend la forme d'un bundle nommé SCR.
Ce modèle de description de dépendances, de cycle de vie et le conteneur associé sont étendus dans les travaux de cette thèse afin d'enrichir les moyens de sélection de services et de supprimer l'ambigüité de celles-ci [2007-3][2006-4][2006-2]. En effet, le modèle OSGi Declarative Services montre les limitations suivantes :
• La déclaration des propriétés et du filtre de services est statique.
• Le filtre de services est une expression LDAP n'acceptant que types et opérateurs simples.
• Aucun algorithme de classement de services d'ordre total ne peut être ajouté. Par conséquent, 4 améliorations ont été pensées afin de réutiliser SCR dans le cadriciel Home SOA (cf. déclaration de la Figure 67) :
<!-- A component requiring a service --> <component name="service.requester"> <implementation class="pack.ControlPoint"/> <reference name="PLAYER" interface="api.Player" target="(location=$location{MaxAndre})" optionalfilters="(hifi=true)" cardinality="1..1" policy="dynamic" bind="bindPlayer" unbind="unbindPlayer" sort-method="sortPlayers"/> </component>
Figure 67 Déclaration de dépendances de service
1ère amélioration : des filtres optionnels sont ajoutés au premier filtre de service. Ils permettent une sélection plus fine des services lorsque plusieurs fournisseurs passent le filtre obligatoire. Les filtres optionnels peuvent être nombreux et organisés du plus important au moins important. De plus, des chiffres de cardinalité entre 1 et l'infini sont acceptés alors que le modèle OSGi Declarative Services ne les accepte pas.
2ème amélioration : les propriétés et les filtres de service deviennent modifiables à l'exécution. Cette amélioration utilise les techniques de contextualisation du registre de services du Home SOA (cf. section 1.6).
3ème amélioration : afin de montrer l'intérêt du demandeur de service pour la valeur de propriétés spécifiques dans l'environnement, il est permis d'écrire des modèles de valeurs interprétables par un gestionnaire de contexte particulier. Par exemple, une application cherchant les services disponibles dans la pièce où se trouve l'utilisateur Maxandre pourrait être exprimée par le filtre suivant : location=$location-room{Maxandre}. Les sources de contexte sachant interpréter ce modèle et ayant accès à l'information recherchée pourrait alors écrire la valeur à la place de l'expression modélisée. Chen et al. [ChK03] introduisent cette syntaxe pour les requêtes et la publication de valeurs contextuelles.
4ème amélioration : il est ajouté la déclaration du nom d'une méthode publique ("sort-method") à appeler afin de classer dynamiquement les services présents. Cela permet au développeur de programmer une méthode de tri complexe dans le langage de programmation des composants. Exposer tous les termes de l'algorithme dans des entités accessibles à l'extérieur du composant n'est pas aisé dans les applications usuelles et la sémantique de l'algorithme de yri peut être complexe. Pour ces raisons, l'algorithme est ici spécifié de manière interne au composant, ce qui apporte une contradiction à la lâcheté du couplage recherché. C'est une limite du système proposé. L'ajout de script à évaluer par un conteneur extérieur [DaL06] est une possibilité qui n'a pas été implémentée.
Figure 68 Recherche du meilleur service de restitution de messagerie ambiante Les articles [2007-3][2006-4][2006-2] prennent l'exemple de la recherche des meilleurs haut-parleurs dans le voisinage de l'utilisateur. Dans l'article [2007-7], le meilleur service de restitution d'une session de messagerie ambiante est recherché (Figure 68).
Figure 69 Boucle de rétroaction pour la reconfiguration de chaque composant Ce dernier article présentait un modèle affiné par l'utilisation de techniques à POJO. La déclaration de la sélection du meilleur service pour chaque dépendance est alors déléguée à un gestionnaire particulier ("handler" dans la nomenclature d'iPojo) nommé Cadep pour "Contextd-Aware DEPendency". La Figure 70 montre la déclaration d'un filtre acceptant un
modèle de valeur ("filter") et d'une méthode de classement interne ("ranking-method") associé à une dépendance de services simplement déclarée dans le code par un champ ("field") dont le type est pris comme interface de service pour la dépendance.
<ipojo xmlns:cadep="cadep.CadepHandler" > <component className="aim.App"> <cadep:dependency field="relay" filter="(location=${Context:maxandre.location})" ranking-method="rankRelays"/> </component>
<instance component="aim.App" name="IMApplication"/> </ipojo>
Figure 70 Dépendance de service contextualisée par un gestionnaire iPOJO Le gestionnaire de dépendances de service et le gestionnaire de classement contextual se partagent le travail de la gestion du cycle de vie du composant. Le détail de la boucle de rétroaction effectuée par ces gestionnaires est décrit par la Figure 69. Les événements d'enregistrement, de mise à jour et de dés-enregistrement de fournisseurs de service et les changements de propriétés du filtre de service déclenchent la mise à jour du système de représentation des services. Le classement des services et la reconfiguration du composant sont effectués dans le cas où les dépendances obligatoires peuvent être satisfaites.