5.1.2 Représentation d’un service SLCA avec notre modèle de graphe . . . 100 5.2 Les Aspects d’Assemblage (AA) . . . 102 5.2.1 Vocation des AA et auto-adaptation au contexte . . . 102 5.2.2 Approches de production des AAs . . . 104 5.3 Tisseur d’aspects d’assemblage . . . 106 5.3.1 Instanciation des greffon des AAs . . . 107 5.3.2 Transformation : Instance de greffon ↔ un graphe . . . 108 5.3.3 Extension du tisseur . . . 108 5.4 Expérimentation : application dans le domaine domotique . . . 110 5.4.1 Scenarios . . . 110 5.4.2 Description des AAs . . . 111 5.4.3 Application du scénario . . . 112 5.5 Conclusion . . . 122
Dans ce chapitre, nous présentons l’implémentation des concepts que nous avons présentés pré- cédemment : le modèle d’application et le modèle d’adaptation. À partir d’un scénario, que nous appliquerons au cadre de la domotique, nous proposons une mise en oeuvre de notre mécanisme de composition qui prendra en entrée une application basée sur une infrastructure logicielle de services pour dispositifs et des spécifications d’adaptations. Pour cette mise en œuvre, nous utiliserons la plate- forme d’exécution à base de composants WComp.
5.1
Modèle d’application SLCA
Les caractéristiques de l’IAm exposés dans le chapitre 1, lorsqu’elles sont combinées les unes avec les autres, sont à l’origine des choix effectués pour l’implémentation de notre solution. Dans cette section, nous détaillons le modèle d’application utilisé dans le cadre de l’informatique ambiante. Ce modèle permet de créer des applications dynamiques à partir d’une infrastructure de services basés sur des communications par évènements [Hou10]. Ce modèle vise à prendre en compte les différentes problématiques pour l’adaptation des applications d’informatique ambiante. Les approches orientées service ont apporté des solutions aux problèmes de l’hétérogénéité et l’interopérabilité. L’interopéra- bilité est apportée par les services web [PTDL07] au niveau des protocoles de communication en repo- sant sur des technologies web largement utilisées tels que le protocole HTTP et le langage XML. Ces technologies ont permis de créer des applications à partir de services s’exécutant avec des langages de programmation hétérogènes, et des architectures matérielles différentes. Fournisseurs et consom- mateurs peuvent utiliser des architectures matérielles et/ou logicielles différentes. Un autre enjeu se
réfère à la manière de gérer l’imprévisibilité de disponibilité de ces entités pour pouvoir les intégrer et les retirer facilement du système ambiant. Les composants sont beaucoup plus faciles à manipu- ler que les services puisqu’ils s’exécutent dans un environnement contrôlé et peuvent être instanciés et manipulés dynamiquement. Pour bénéficier des avantages des différents paradigmes, il existe des modèles d’application multi-paradigmes qui combinent à la fois services et composants. Nous utili- sons le modèle SLCA (Service Lightweight Component Architecture) [CFW09] qui a pour but de créer des applications basées sur les dispositifs présents dans l’environnement en utilisant une composition dynamique de services pour dispositif. SLCA définit un modèle d’architecture compositionnelle basé sur trois paradigmes : composant, service et événement :
– Assemblage de composants. Un service web composite est créé à partir d’un assemblage de composants.
– Architecture orientée service. Une application est un graphe de service web et de service web composites.
– Communication événementielle. L’utilisation ce type de communication augmente le décou- plage entre les entités et favorise donc la dynamicité [Hou10].
5.1.1 Les éléments du modèle
5.1.1.1 Assemblage de composants légers
Pour concevoir des services Web pour dispositif composites, le modèle SLCA utilise des compo- sants légers selon le modèle LCA (Lightweight Component Architecture). C’est un modèle inspiré de Beans [Eng97]. Un composant se définit par un ensemble de ports d’entrées, de sorties et des proprié- tés. Ces composants sont dits légers car ils sont rattachés à un même processus et ils s’exécutent dans un même espace de mémoire. Ceci va impacter leurs interactions qui deviennent plus simples et plus efficaces. Ces composants respectent le concept de boîte noire ; ils ne contiennent pas de référence entre eux lors de la conception. Ces composants sont dits légers dans le sens où ils n’embarquent pas de services techniques inutiles dans un environnement local. La gestion des événements et des pro- priétés sont les seuls codes non-fonctionnels qui doivent être présents dans le code des composants.
Dans ce modèle, les composants possèdent une interface qui est un ensemble de ports d’entrée (des méthodes) et de ports de sortie (des événements). Chaque port a un identifiant unique et est typé par des paramètres. Les interactions entre les composants relient un port de sortie d’un composant à un ou plusieurs ports d’entrée de composants. Lorsque l’événement est envoyé par le composant qui est à la source de la liaison, le flot de contrôle passe alors aux composants destinataires dans un ordre indéterminé. Cet ordre pourra être fixé par l’utilisation de connecteurs tel que la séquence ce qui rend la gestion de flot de contrôle de l’application déterministe. Les composants sont décrits par des fi- chiers sauvegardés dans un répertoire (Repository). Ils sont instanciables dans une application à partir de ces fichiers. Cette liste de fichier peut être modifiée à l’exécution, c’est à dire charger et décharger des fichiers. Deux types de composants sont définis : les composant proxies et les composants fonc- tionnels. Lorsqu’un service représentant un dispositif est découvert, un composant spécifique appelé composant proxy peut être généré à partir de la description du service et instancié pour faire partie de l’assemblage de composants. Les composants proxies jouent le rôle d’interface entre les services de l’infrastructure et les composants d’un assemblage. La figure 5.1 illustre un service composite selon le modèle SLCA. Ce dernier propose un modèle d’architecture pour la composition de services basé sur des assemblages de composants légers.
FIGURE5.1 – Un service composition selon le modèle d’architecture SLCA
5.1.1.2 Service Composite SLCA
Le modèle SLCA construit les applications à partir des services de l’infrastructure découvrables dynamiquement qui représentent les dispositifs disponibles. Ces applications sont conçues par compo- sition de services en assemblant des composants. Un service composite encapsule donc un assemblage de composants. Les composants proxies d’autres services composites et des services web peuvent faire partie de cet assemblage de composants. Cela va créer des applications à partir des dispositifs présents dans l’environnement ainsi que d’autres compositions de service. De ce fait, un service com- posite peut créer une application communiquant avec un autre service composite. La figure 5.2 montre qu’une application selon SLCA est alors un graphe de services dont chacun encapsule un assemblage de composants légers. L’apparition d’un dispositif va engendrer l’instantiation d’un composant proxy qui sera à son tour utilisé dans la composition interne d’un ou plusieurs services. Le graphe de l’ap- plication va alors subir cette variation et va être incrémenté.
Un service composite possède deux interfaces dynamiques : une interface fonctionnelle et une de contrôle. L’interface fonctionnelle permet d’exporter une application créée localement par l’assem- blage de composants vers l’infrastructure de service (ceci permettra d’utiliser un service composite par d’autres). L’interface de contrôle permet d’agir dynamiquement sur l’assemblage interne de composants. Elle permet d’ajouter ou supprimer des composants et des interactions et de récupérer des informations sur l’assemblage (type de composants disponibles, liste des composants instanciés, liste des interactions, etc.). Ce modèle fournit donc les éléments nécessaires pour l’adaptation. En effet, une entité qui utilise un service composite à travers un proxy, pourra agir sur la structure de ce dernier. L’adaptation structurelle des services composites et des applications est donc possible dans le modèle par ses propres entités.
Le changement dans l’infrastructure (apparition ou disparition des dispositifs) se traduit par l’ins- tantiation ou bien la suppression des composants proxies ainsi que leurs interactions. L’adaptation porte alors sur la composition interne d’un service composite ou bien une application locale LCA.
FIGURE5.2 – Un graphe de composition de services SLCA
Dans la suite nous représentons à l’aide de notre modèle de graphe l’assemblage de composants d’un service composite (ou une application locale).
5.1.2 Représentation d’un service SLCA avec notre modèle de graphe
Nous avons présenté dans la section 3.1 notre modèle de graphe qui est une abstraction d’une application en cours d’exécution. Ce modèle a été défini indépendamment des outils de transforma- tion de graphes. Pour sa mise en œvre, nous avons utilisé AGG (Attributed Graph Grammar) [Tae00]. C’est un environnement général pour la transformation algébrique des graphes, basé sur un concept d’attribution très flexible. Les objets d’un graphe selon AGG sont autorisés à être attribués par toute sorte d’objets Java. Les règle de réécriture de graphes peuvent être équipées de calculs arbitraires (dé- crits par une expression Java) sur ces objets Java. L’environnement AGG se compose d’une interface graphique comprenant plusieurs éditeurs visuels, et un interprète, qui est également disponible sous forme d’API Java.
Dans notre implémentation, nous considérons le modèle de graphe (appelé aussi typed graph) illus- tré par la figure 5.3. Les nœuds (la classe Node) sont une abstraction des entités impliquées dans une application. Ils peuvent être un nœud de sémantique connue (connecteurs) ou bien un nœud de séman- tique inconnue (port de composants). Chaque nœud est spécifié par deux attributs : CTy est le type de nœud et CN est le nom de l’instance qui doit être unique. Comme exemple, nous définissons le type graphe d’une application à base de composants. Pour les nœuds de sémantique inconnue, nous repré- sentons les ports des composants CTy=’Port’ et CN est sous la forme Component_Name.PortName.
Pour les nœuds de sémantique connue, le CTy spécifie le type du connecteurs(SEQ, AND, etc.).
FIGURE5.3 – Implémentation du modèle de graphe sous AGG
Les arcs du graphe (classe Link dans la figure 5.3) modélisent les interactions entre les entités impliquées dans nos applications. Chaque arc modélise une liaison port à port. Il est étiqueté par une chaîne de caractères dont la signification est liée à la sémantique du nœud source. Par exemple nous avons vu précédemment que le connecteur SEQ exécute deux actions dans un ordre défini. Pour spécifier cet ordre au niveau du graphe des étiquettes «out1» et «out2» sont ajoutées au niveau des arcs marquant cet ordre. L’étiquette par défaut est «L», c’est à dire il n’y a pas de sémantique spécifique pour cet arc. Le tableau 5.1 présente l’ensemble des étiquettes utilisées dans notre implémentation.
TABLE5.1 – Ensemble d’étiquettes pour les arcs.
Type de Nœud Étiquettes
SEQ out1, out2
IF T, F, C
Notre typed graph définit une autre classe de nœud : ⊗. Ces nœuds sont utilisés pour marquer dans le graphe les endroits où une interférences a été détectée. La figure 5.4 est une instance d’un graphe selon le modèle défini. L’émission de l’événement SetOn du composant Switch1 déclenche deux actions en séquence : light1.SetTarget ensuite light2.setTarget.
Nos graphes sont obtenus à l’issu de l’application d’un ou plusieurs entités d’adaptation. Dans la section suivante nous présentons la technique utilisée pour la spécification de ces entités d’adaptation (les aspects d’assemblage). Nous présentons aussi la transformation de ces entités d’adaptation vers un graphe à partir duquel nous appliquons notre raisonneur pour la gestion des problèmes d’interférences.
FIGURE5.4 – Un exemple de graphe de composition en utilisant le modèle défini sous AGG