Adaptation dynamique par tissage d’aspects
d’assemblage

 Service pour l’informatique ambiante

La notion de service est souvent raccrochée à la problématique de la distribution logicielle [168]. Les architectures orientées service permet de séparer les préoccupations en ne permettant aux éléments de base comme les services de communiquer avec d’autres services uniquement à travers de leur interface. Le principal avantage est le fort découplage entre les services, ce qui permet la réactivité et la réutilisabilité. La notion de service permet de travailler avec la problématique de l’adaptation réactive. Les concepts de service et celui de composant sont bien définis, mais peuvent entrer en conflit sur certains points. Nous étudions d’abord ces conflits et ensuite nous nous focaliserons sur les caractéristiques de notre modèle de service.

Service et composant

La frontière entre la notion de service et celle de composant peut paraître floue à première vue. Des modèles de composant complexes offrent parfois des fonctionnalités similaires à celles fournies par les services : programmation distribuée, découverte dynamique, interopérabilité, etc. Ils permettent alors le déploiement d’applications sur plusieurs noeuds. Le point important à mettre en valeur en informatique ambiante est de pouvoir créer des applications qui sont capables de s’adapter aux modifications de l’environnement telles que l’apparition de dispositifs ou la modification de leur interface, bien plus que de provoquer ces changements. De plus, la notion de service inclut une existence autonome. Cela est un avantage lorsque nous les utilisons pour des dispositifs physiques. Par conséquent, nous basons notre approche sur le concept de service qui représentera la communication entre les entités diverses dans l’environnement incluant les dispositifs et pour la capacité d’adaptation des composants logiciels. La notion de service n’est pas contraire au concept de localité, ni à celui de blackbox qui sont souvent raccrochés à la notion de composant. Service et localité. La localité détermine l’espace d’exécution des entités (local/distribué). Rassembler des entités dans un même espace d’adressage permet d’obtenir de meilleures performances au niveau de la communication, mais permet surtout de garder un état stable d’une application sans se soucier des variations de l’environnement. Les services OSGi illustrent ces entités s’exécutant dans un même espace d’adressage. 82 Service et blackbox. D’une part, une entité blackbox limite les interactions à travers la notion de service en restreignant les communications et les modifications aux interfaces fournies ou requises et en interdisant tout accès direct à l’implémentation (par exemple, pour effectuer des adaptations). D’autre part, utiliser des entités blackbox améliore la réutilisabilité lors de l’exécution puisque l’on dispose de la garantie que son implémentation est exactement la même. Nous emploierons la notion de service dans sa définition la plus minimale et stricte : une interface contractuelle entre les entités de notre application. Cette notion autorise la distribution et améliore la réutilisabilité en interdisant la modification de l’implémentation des entités blackbox.

Caractéristiques conférées aux services

Les dispositifs de l’infrastructure en informatique ambiante ressemblent aux services de part leur autonomie, leur indépendance et parce qu’ils offrent un ensemble de fonctionnalités que l’on peut exploiter. Ces dispositifs évoluent, changent de position géographique, changent d’interface ; par conséquent les schémas de communication ne sont plus les mêmes. Les modèles de service ont beaucoup évolués depuis 10 ans [108, 169, 170, 171] et incluent les concepts de services à ceux de plates-formes à événements en plus de la découverte dynamique. De nouvelles caractéristiques telles que l’interopérabilité contribuent maintenant à la résoudre le problème d’adaptation réactive.

Réactivité Traditionnellement, les invocations distantes (RPC) permettent de passer le flot de contrôle d’un service à un autr

. Ces invocations conviennent bien aux applications de traitement d’information. En informatique ambiante, les utilisateurs (que ce soit des êtres humains ou d’autres services) souhaitent être notifiés d’un changement. Les mécanismes de publish/subscribe ou de notification d’événements proviennent de ce besoin de réactivité dans les applications. De plus, le mécanisme d’événement apporte un découplage plus important entre les services. 

Interopérabilité

Nous distinguons deux types d’interopérabilité : celle des entités et celle de la plate-forme. L’interopérabilité des services (système s’exprimant par un protocole qui lui est propre), c’est-àdire au niveau de la communication, est réalisée par l’ajout de stubs/skeleton en CORBA ou encore de l’utilisation d’une technologie commune comme TCP/IP, HTTP ou XML dans le cas des services Web. Elle est résolue par une couche logicielle intermédiaire. L’interopérabilité de la plate-forme (exécution d’une même entité logicielle sur des unités physiques différentes) est réalisée par la présence d’une machine virtuelle. Le programme exécutable est écrit dans un langage intermédiaire interprété par une machine virtuelle. Cela permet de simplifier le mécanisme de déploiement des applications. Nous avons vu que les services ne sont plus réservés à des applications à grande échelle (comme le Web par exemple) pour des systèmes d’information, mais sont de plus en plus tournés vers l’informatique ambiante par exemple. En effet, ils offrent à présent des communications basées sur les événements et une gestion de l’interopérabilité. Toutefois, un fossé est toujours présent entre le développement d’applications pour l’informatique ambiante essentiellement basé sur des services à cause du découplage trop fort qu’il occasionne (moins de flexibilité), le manque de confiance au niveau des interfaces et leur disponibilité que temporaire (dynamisme de l’infrastructure). Nous proposons dans les sections suivantes un modèle de service incluant les propriétés énoncées et traitant du problème de fort découplage et de forte variabilité.

Modèle de service pour l’IAm

L’infrastructure est constituée de l’ensemble des services accessibles et des dispositifs utilisables. Notre modèle s’appuie sur une infrastructure de services utilisant les événements et que l’on peut découvrir dynamiquement. Ces services représentent les dispositifs utilisés aussi bien dans les applications IAm que dans les services composites. Le problème d’interopérabilité des services est résolu par ce modèle, ce qui permet de programmer les dispositifs en utilisant le langage que l’on souhaite. Celle de la plate-forme dépend de la cible utilisée. Un service est un ensemble de fonctions fournies par un système logiciel à un autre système logiciel. Il est généralement accessible à travers une API. Nous distinguons deux catégories de services : – Service classique – Service pour dispositif Les services classiques constituent une approche pour faciliter leur interopérabilité indépendamment des technologies sous-jacentes comme c’est le cas pour la technologie Web Service standard [28]. Utiliser cette approche pour accéder à des dispositifs permet de gérer l’apparition et la disparition de dispositifs comme l’arrivée ou le départ d’un service. Cette approche s’appuie sur la technologie Web Service pour Dispositifs [172] dont une première mise en œuvre est apparue avec le standard UPnP. La notion de service pour dispositif requiert deux extensions majeures du modèle de service classique : – un mécanisme de recherche et de découverte dynamique de nouveaux services pour dispositifs dans l’environnement proche du système IAm ; – un mode de communication par événements pour garantir un minimum de réactivité aux variations des entrées-sorties des dispositifs. Les dispositifs étant le plus souvent connectés à l’environnement physique, les services associés doivent offrir les caractéristiques pour prendre en compte la réactivité de l’application aux variations de l’environnement. Le rythme des échanges environnement/système est fixé par l’environnement et a également pour effet d’accroître également le découplage entre les entités qui le composent [173] La publication et la découverte d’un service s’accompagne d’une description dynamique de son interface qui assure l’indépendance du fournisseur de service par rapport au consommateur [174]. Pour avoir un découplage plus fort, cette description peut être étendue [175, 176] par l’ajout de méta-données. Les services pour dispositifs sont contraints par les cibles auxquels ils sont associés [28]. Certains mécanismes permettent de déterminer les services les mieux adaptés à la résolution d’une tâche [177]. En fonction des approches, il peut s’agir de prendre en compte l’auto-organisation [178]. Nous conditionnons la découverte d’un service au contexte. plus généralement, sa disponibilité peut être alors conditionnée à des conditions contextuelles d’utilisation [179, 180]. Notre modèle de service. Dans notre modèle, nous avons une unique notion de service. Un service a une interface qui détermine les ports par lesquels le service est connecté à l’infrastructure. Nous distinguons deux catégories de port : – l’ensemble des points d’entrée noté I – l’ensemble des événements noté O. La paire (I, O) caractérise la notion d’interface (parfois notée (I I O) [181]). Ce modèle supporte cinq fonctionnalités : – Découverte des dispositifs : les dispositifs peuvent être découverts dans l’infrastructure du système IAm passivement (attente d’une notification) ou activement (envoi régulier de messages) ; – Entités de l’infrastructure multi-service : les entités de l’infrastructure peuvent fournir un ou plusieurs services. Ces capacités sont fixes et spécifiées à travers la description d d’une entité ; 84 – Invocations synchrones des points d’entrée : on attend la fin de l’exécution des fonctionnalités offertes ; – Mécanisme de souscription aux événements : pouvoir s’abonner aux événements diffusés par l’entité de l’infrastructure ; – Description générale d’une entité : possibilité d’obtenir une description plus générale de l’entité de l’infrastructure. Notons que nous ne considérons pas les notions de sécurité qui peuvent être ajoutées a posteriori à ce modèle. 

Système informatique ambiant

Un modèle de service pour l’informatique ambiante est la solution que nous proposons à partir de l’étude que nous avons faite : faire face à la variabilité de l’infrastructure logicielle liée à sa distribution. Un système informatique ambiante est un graphe de services qui collaborent pour construire plusieurs applications pour plusieurs utilisateurs. Les modèles d’orchestrations centralisées ne peuvent plus s’appliquer. 

Graphe de services

Notre modèle définit une modèle d’architecture composée de services et s’appuyant sur des événements. Il permet de construire des graphes de coopération entre services et applications. L’environnement physique est constitué d’utilisateurs mobiles interagissant avec le monde réel et d’autres utilisateurs portant des dispositifs sur eux. Le modèle permet de les percevoir comme des services disponibles momentanément dans l’infrastructure. Nous constatons qu’il n’existe plus d’application prédéfinie, mais seulement un graphe de services qui collaborent. Figure 4.1 – Graphe de services basés sur des événements

Pas d’orchestration centralisée

L’enjeu principal de l’informatique ambiante est de trouver une solution pour résoudre le problème de l’informatique multiple. Plusieurs utilisateurs peuvent utiliser simultanément plusieurs applications fragmentées en plusieurs services. Ces utilisateurs interagissent avec plusieurs dispositifs afin de communiquer avec d’autres utilisateurs localisés en différents espaces physiques et environnements. En effet, l’informatique ambiante est multi-application, multi-user et multi-dispositif. Il ne peut plus y avoir d’orchestration centralisée.