reconfiguration dynamique
4. Apports et limites du GL en synthèse
Pris séparément, les requis techniques pour l’implémentation et pour l’exécution de systèmes interactifs plastiques trouvent quelques solutions. Les intergiciels répondent aux problèmes de la distribution et de certains niveaux d’hétérogénéité, les approches à composants proposent des pistes quant à la reconfiguration dynamique et les approches à services semblent adaptées pour traiter la question de la disponibilité dynamique des différents éléments, matériels ou logiciels, d’un système interactif plastique. Malheureusement, aucune approche ne couvre à la fois tous ces requis. Si certaines combinaisons sont possibles, notamment aux niveaux des intergiciels [Grace03] et des services [Amigo-D2.1][Cervantes04][Escoffier07], ces tentatives ne répondent pas totalement à la problématique posée par les systèmes interactifs plastiques.
Si la sélection d’un élément d’interface utilisateur à la manière de l’approche à services est envisageable, elle ne peut pas se faire sur la base des descripteurs de service en vigueur dans les technologies actuelles. En effet, ces descripteurs ne permettent la sélection que sur la fonctionnalité offerte par le service à son client, voire sur la qualité de service attendue, en termes, par exemple, de latence, de précision, de fiabilité ou de sécurité. Un élément d’interface utilisateur, lui, sert deux types de clients à la fois : un client logiciel : le noyau fonctionnel et un client humain : l’utilisateur. Sa sélection doit être faite sur la fonctionnalité qu’il offre au noyau fonctionnel d’une part, et à l’utilisateur d’autre part. En plus de la prise en compte des critères traditionnels de qualité de service, il est impératif d’ajouter celui de l’utilisabilité, propre au domaine l’interaction homme–machine, et au cœur de la question de la plasticité des systèmes interactifs. En outre, si la localisation d’un service sur le réseau importe peu dans l’approche traditionnelle, ce n’est pas le cas pour une interface utilisateur : dans l’exemple d’une interface graphique il est primordial de pouvoir décider sur quel écran elle sera affichée. Par conséquent,
il doit être possible de décider de la localisation d’un service d’interaction homme–machine.
Au-delà de l’insuffisance descriptive des descripteurs de services traditionnels, la question de l’hétérogénéité des technologies reste à traiter. L’intergiciel ReMMoC [Grace03], permet d’implémenter des clients capables d’interagir avec un ensemble de services implémentés au-dessus d’un ensemble de technologies hétérogènes. Ce niveau d’hétérogénéité est géré de manière transparente par l’intergiciel. Cependant, la réciproque n’est pas possible : un service ne peut pas être implémenté au-dessus de ReMMoC de manière à être accessible par n’importe quel client. Or, la fonction d’une interface utilisateur est de permettre d’une part de rendre observable à l’utilisateur des concepts du noyau fonctionnel et d’autre part de permettre à l’utilisateur d’agir sur le système, c’est-à-dire de manipuler le noyau fonctionnel. Dans cette mesure, une interface homme–machine est à la fois service et client.
L’approche à services dans [Amigo-D2.1] autorise l’existence d’entités à la fois cliente et service. Mieux, leur solution permet de gérer de manière transparente l’hétérogénéité des technologies à services sous-jacentes aussi bien pour les services et pour les clients, mais également pour leurs développeurs. Leur solution s’inscrit également 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. Pourtant, leur solution par traducteur de protocole s’avère gourmande en puissance de calculs, notamment au moment de la génération des traducteurs. Dans leur contexte de réseaux domestiques ouverts [Amigo04] ceci ne pose pas de problème car leur solution n’a pas besoin d’être déployée sur l’ensemble de la plate-forme : il suffit au minimum qu’une seule des plates-formes élémentaires héberge le générateur de traducteur. Or, la plate-forme cible dans [Amigo04] comporte toujours un dispositif assez puissant pour cette tâche.
Dans notre problématique, deux plates-formes élémentaires aux ressources de calculs limités peuvent former ensemble une plate-forme. Dans ce cas, aucune des deux ne pourrait prendre en charge la génération des traducteurs nécessaires. Notre approche doit être capable de résoudre la question de l’hétérogénéité des technologies également dans ce type de configuration. Enfin, l’utilisateur doit garder le contrôle sur le système. À l’instar de la manière avec laquelle il compose sa plate-forme, l’utilisateur doit pouvoir décider du remodelage et de la distribution de l’interface homme–machine du système interactif qu’il utilise [Coutaz06]. Or, dans l’approche à services, l’initiative de la sélection d’un service et la liaison au service est de la responsabilité du client. À
l’inverse, l’initiative de la sélection des composants et de la liaison entre composants relève de la responsabilité d’un tiers. Ainsi, il apparaît que des concepts-clés des approches à composants et à services doivent être inévitablement associées au sein d’une même approche pour pouvoir construire des systèmes interactifs plastiques. L’approche de [Cervantes04] a ouvert la voie en proposant le premier « modèle à composants orienté services ».
Cependant, dans l’approche de [Cervantes04], une reconfiguration ne peut avoir lieu que sur la disparition ou l’apparition d’un composant dans le référentiel et non sur un événement contextuel. La reconfiguration est alors gérée par auto–adaptation grâce aux facultés des gestionnaires d’instance. Cette approche rend donc difficile la possibilité de donner à l’utilisateur l’initiative et le contrôle sur la reconfiguration du système. Comme nous le montrons dans [Balme04], un système interactif plastique doit être capable à la fois, selon les termes définis par [Oreizy99] de reconfiguration interne et externe, c’est-à-dire respectivement par ses propres moyens ou grâce au concours d’un tiers. Si un rapprochement entre les paradigmes à composants et à services est nécessaire, l’approche de [Cervantes04] ne peut pas convenir, en l’état, à notre problématique. La notion de disponibilité dynamique des composants est indispensable. Cependant, le principe de l’approche à services, qui consiste à laisser seul au client l’initiative de la connexion à un service, doit être complétée par la possibilité laissée à un tiers d’accomplir cette fonction. En revanche, les lacunes de l’approche de [Cervantes04] semblent être, au regard des requis de la plasticité, comblées par le caractère extensible des conteneurs de composant iPOJO [Escoffier07]. Il conviendrait alors de développer des handlers spécialisés pour la plasticité qui permettraient, d’une part, la délégation à un tiers des prises de décision quant à la sélection et à l’établissement des liaisons, et d’autre part, d’élargir à l’ensemble des évènements relatifs au contexte de l’interaction la possibilité de déclancher une reconfiguration.