Avant-propos
Sur le plan technique, un système interactif plastique est un logiciel distribué, dynamiquement reconfigurable, et capable de traiter avec l’hétérogénéité de son environnement d’exécution. Cette nature logicielle s’inscrit à la croisée de plusieurs domaines de recherche en Génie Logiciel : les intergiciels pour la distribution, les approches à composants et à services pour la reconfiguration dynamique, et l’Ingénierie Dirigée par les Modèles (IDM) et sa notion de transformation pour le traitement de l’hétérogénéité des technologies.
Ce chapitre commence par une revue de l’état de l’art sur les intergiciels et les approches à composants et à services. Je ne reviendrai pas sur l’IDM dont j’ai résumé les avancées et les limites au chapitre précédent sous l’angle des IHM plastiques. Ce chapitre s’achève sur une discussion des limites des solutions du GL au regard de mes requis.
1. Intergiciels et distribution : le problème
de leur interopérabilité
Depuis le début des années 1990, les intergiciels constituent la solution la plus communément admise aux problèmes du logiciel réparti. L’objectif d’un intergiciel est d’offrir aux développeurs d’applications réparties un niveau d’abstraction qui masque la distribution des différents constituants d’une application et l’hétérogénéité des matériels, systèmes d’exploitation, et langage de programmation. [Mascolo02] montre que les intergiciels traditionnels, qui ont été conçus et utilisés avec succès dans le cadre de systèmes distribués sédentaires et construits sur des réseaux informatiques fixes, ne sont pas utilisables en l’état dans le domaine de l’informatique mobile, et donc, par extension dans celui de l’informatique ambiante.
Si certains ont été adaptés au cas de l’informatique mobile, notamment CORBA [Haahr99], beaucoup d’autres, comme ReMMoC [Grace03], ont été développés spécialement pour ce domaine. [Roman01] note que le foisonnement des dispositifs et des systèmes pour l’informatique ambiante introduit le problème de l’hétérogénéité des intergiciels. [Mascolo02] montre qu’il sera très difficile d’isoler un intergiciel suffisamment général capable de prendre en compte l’ensemble des possibles de l’informatique ambiante. Il paraît donc inévitable de traiter la question de
l’interopérabilité entre intergiciels. Les propositions les plus abouties dans ce sens concernent les intergiciels réflexifs et les approches par traduction de protocole. J’en étudie à présent un exemple représentatif pour chacune de ces deux classes: ReMMoc [Grace03] et AMIGO [Amigo-D2.1].
1.1 Un intergiciel réflexif : ReMMoC
La capacité réflexive d’un intergiciel se caractérise par la possibilité donnée à une application d’inspecter et de modifier des constituants de l’intergiciel sur lequel elle est construite pour changer le comportement de cet intergiciel [Roman01]. ReMMoC27 [Grace03] est un intergiciel réflexif dynamiquement reconfigurable conçu pour le développement d’applications dans le contexte très hétérogène de l’informatique mobile.
ReMMoC comprend deux constituants principaux : un environnement de liaison28 et un environnement de découverte de service29 (voir Figure IV-1). Le premier fournit les mécanismes pour assurer l’interopérabilité entre différents types d’intergiciels. Le deuxième permet la découverte de services dont l’existence est diffusée par une gamme de protocoles de découverte automatique.
Figure IV-1Vue générale de la plate-forme ReMMoC d’après [Grace03].
L’environnement de liaison se configure par ajouts ou retraits d’implémentation de type de liaison30. Chacune de ces implémentations est dédiée à un intergiciel donné. Elle permet d’établir une liaison de communication entre un client développé au-dessus de ReMMoC et un service implémenté au-dessus de
27 ReMMoC :Reflective Middleware for Mobile Computing
28 Binding Component Framework (Binding CF)
29 Service Discovery Component Framework (Service Discovery CF)
l’intergiciel ciblé. De la même manière, l’environnement de découverte de services se configure par ajouts ou retraits de protocoles de découverte et offre à un client développé au-dessus de ReMMoC le moyen de découvrir des services annoncés via ces protocoles. D’autre part, ReMMoC fournit une interface programmatique à l’usage de la couche applicative afin que les applications implémentées au-dessus de ReMMoC puissent utiliser directement l’implémentation de type de liaison ou le protocole de découverte de service qui lui convient.
L’une des faiblesses de ReMMoC concerne l’absence de réciprocité dans les mécanismes : s’il est possible, avec ReMMoC, d’implémenter un client capable d’interagir avec des services implémentés avec d’autres intergiciels, il est impossible, avec ReMMoC, de programmer un service qui serait disponible pour des clients implémentés avec d’autres intergiciels. C’est notamment cette limitation que se proposent de dépasser les approches à traduction de protocoles. Les travaux de recherche effectués au sein du projet AMIGO [Amigo04] sont de ceux-là.
1.2 Une approche par traduction de protocole : AMIGO
AMIGO [Amigo04] est un projet européen31 qui s’inscrit dans le cadre des réseaux domestiques, c’est-à-dire des réseaux informatiques pour la maison. Actuellement, ces réseaux informatiques relient les consoles de jeux ou les différents ordinateurs présents dans la maison entre eux et à Internet. Cependant, selon AMIGO, ces réseaux sont sous-utilisés. De nos jours, les habitations contiennent pléthore de dispositifs devenus numériques (télévision, chaîne HIFI, téléphone, électroménager, etc.) dont le raccordement au réseau domestique démultiplierait les possibilités pour l’utilisateur. Or, les procédures d’installation complexes, le manque d’interopérabilité entre les dispositifs issus de différents constructeurs et l’absence de service intéressant pour l’utilisateur freinent ce genre d’avancée. L’objectif d’AMIGO est de proposer une solution logicielle pour résoudre ces principales difficultés, notamment en proposant une infrastructure logicielle fondée sur la technique de traduction basée sur des évènements32 et explorée par [Ryan04].
L’étude de [Ryan04] s’intéresse à la question de l’interopérabilité entre les différentes versions d’un même protocole. À partir d'une spécification de protocole, un générateur crée une unité composée
31 Amigo : Ambient Intelligence for the networked home environment, European IP project, IST 004182.
d'un analyseur et d'un compositeur33. Le processus de traduction est le suivant (voir Figure IV-2) : Un composant A transmet, au moyen de la version X d'un protocole, des données à l'analyseur de l’unité générée pour le protocole X. Cet analyseur est capable de transformer sous forme d'événements ces données entrantes. Ces événements sont transmis via un mandataire au compositeur de l’unité générée pour le protocole Y qui va les transformer dans le format de la version Y du protocole. Ce compositeur délivre alors ces données transformées au composant B. Ainsi, bien que le composant A et le composant B ne partagent pas le même protocole de communication, ils peuvent interagir sans que l’un ou l’autre ait eu à subir de modification. De leur point de vue, les mécanismes d’adaptation de protocole sont transparents. Aujourd’hui, cette technique ne semble avoir été appliquée qu’au couple de protocole de communication HTTP 1.0 et HTTP 1.1, c’est-à-dire à deux protocoles très similaires. Dans sa solution technique, AMIGO reprend les concepts introduits par cette étude pionnière en la matière, mais les adapte selon deux axes : améliorer les mécanismes pour traduire des protocoles dont les différences sont plus importantes d’une part, et adapter cette approche pour les protocoles de découverte de services et les protocoles d’interaction d’autre part [Amigo-D2.1].
Figure IV-2 L'interaction entre deux composants via le mécanisme de traduction d'évènements de [Ryan04]. Le composant A utilise le protocole UPnP, tandis que le composant B utilise SLP (Schéma issu de [Amigo-D2.1])
Contrairement à ReMMoC, l’approche mise en œuvre dans [Amigo-D2.1] autorise l’existence d’entités qui sont à la fois cliente et service. Mieux, leur solution permet de gérer de manière transparente l’hétérogénéité des espaces technologiques sous-jacents aussi bien du point de vue des services et des clients, mais également pour leurs développeurs. De plus, comme c’est le cas dans notre problématique, leur solution s’inscrit dans le cadre de
plates-formes constituées de manière dynamique et opportuniste avec des plates-formes élémentaires des plus puissantes au plus légères.
Toutefois, cette approche par traducteur de protocole s’avère gourmande en puissance de calculs, notamment au moment de la génération des traducteurs. Dans un contexte de réseaux domestiques ouverts [Amigo04] ceci ne pose pas de problème car la solution AMIGO ne nécessite pas un déploiement sur l’ensemble de la plate-forme : il suffit au minimum qu’une seule des plates-formes élémentaires du réseau héberge le générateur de traducteur.
Ainsi, comme nous venons de le voir, le monde des intergiciels propose des solutions pour traiter ces questions de distribution du logiciel et de certains aspects de l’hétérogénéité des systèmes. Le traitement des questions relatives à la reconfiguration dynamique des applications passe par l’intégration d’approches complémentaires. Les approches à composants logiciels en font partie.