L'adaptation logicielle est une approche du Génie Logiciel qui utilise les protocoles tels qu'ils sont et tente de les intégrer de manière opportuniste en insérant l'intelligence au sein des plateformes logicielles hébergeant les applications. L'approche Home SOA (cf. Chapitre V) fait partie de ces intergiciels qui prennent le meilleur de chaque protocole détecté afin de satisfaire l'activité de l'utilisateur.
4.6.1 Contrôle d'équipements
REMMOC [GBS03] est un modèle pionnier dans l'utilisation transparente d'intergiciels orientés services distincts. Tout protocole de découverte et de communication distante peut être pris en compte dans l'architecture modulaire de REMMOC. La reconfiguration dynamique de la plateforme en fonction des protocoles effectivement utilisés sur le réseau est l'aspect principal mis en avant dans ces travaux. Un module de l'architecture est responsable de la "découverte" des protocoles utilisés. La reconfiguration réagit sur les événements émis par ce module. La vision de l'interopérabilité est similaire à celle des travaux de cette thèse, nommée Home SOA : les fournisseurs et demandeurs de services sont écrits indépendamment des protocoles de découverte et de communication effectivement utilisés et une syntaxe de description générique joue le rôle de pivot commun. Cependant, l'adaptation dynamique de la disponibilité des services requis, la continuité entre
communication locale et distante, la nécessité d'une médiation technique plus riche ne sont pas adressées dans le projet REMMOC.
Les nombreux travaux au-dessus de la plateforme OSGi montrent la possibilité de masquer l'hétérogénéité des protocoles de découverte grâce à l'utilisation du registre de service OSGi et du service d'événements associé. Le registre de service OSGi implémente le patron de conception "Dynamic Service Locator" [Fow04] qui découple les applications des entités pervasives utiles à l'exécution. L'article [DFKM02] montre cette gestion partielle de l'hétérogénéité par l'utilisation de cette interface unique qu'est le registre de services OSGi. 4.6.2 Communication interpersonnelle
Les auteurs de [CCV06][VCC07] décrivent leur cadriciel qui éclate un terminal de communication interpersonnelle entre un téléphone SIP, un serveur de contenu et une télévision UPnP. L'architecture proposée suit une approche d'adaptation logicielle puisque les trois équipements formant le système de Vidéophonie sur IP suivent des interfaces standards : SIP User Agent, UPnP Media Server, UPnP Media Renderer. Toutefois, les équipements UPnP fournissent des flux RTP, ce qui est contradictoire avec la recommandation de facto pour le protocole de flux HTTP. Ils sont des prototypes inventés qui simplifient le problème. La gestion de l'hétérogénéité des flux n'est donc pas adressée. De surcroit, le système est écrit dans le langage C et ne montre aucune modularité logicielle nécessaire pour toute évolution future. Enfin, leur approche n'est pas générale face à l'hétérogénéité des protocoles multimédia et de communication personnelle puisque seuls deux protocoles sont utilisés : SIP et UPnP1.
4.6.3 Hétérogénéité sémantique
Figure 14 Service d'adaptation et répertoire d'Adapteurs [Vay01]
Les techniques d'adaptation logicielles sont utiles afin de faire face à la fragmentation d'interfaces [Vay01][Law00], c'est-à-dire de représenter les différents objets d'interfaces sémantiquement proches dans une interface commune. Afin d'adapter automatiquement les objets découverts, il peut être proposé un répertoire de multiples adapteurs simples [Vay01][PoF03]. Un gestionnaire présent sur une plateforme de services peut alors, dès qu'un service est enregistré sur la plateforme, enregistrer tous les adapteurs
1
Au passage, l'article tente de montrer la pertinence d'une normalisation UPnP éventuelle d'un "VVoIP device" mais la définition de l'interaction s'avère incomplète : En effet, le "VVoIP Control Point" et le "VVoIP device" se trouvent sur la même plateforme et l'ensemble d'actions et d'événements protocolaires qui définissent cette interaction n'est pas définie avec détails.
dont l'interface d'entrée correspond à l'interface enregistrée. Ces adapteurs peuvent former des chaines d'adaptations permettant aux demandeurs insatisfaits pour un type de service d'utiliser les services d'un type sémantiquement proche. Dans [Vay01], la chaine d'adaptation est chargée et instanciée dynamiquement sur la plateforme et enregistrée comme nouveau service dans le registre de service Jini (cf. Figure 14). Cette technique est raffinée par Home SOA. Des outils de générations spécifiques et une tentative de génération d'adapteurs sémantiques sont aussi proposés dans la section Chapitre V.4.
Le répertoire d'adapteurs proposé par [Vay01] et [PoF03] nécessite le développement d'adapteurs pour tous les types de situations d'offre de services que peut rencontrer une application. Certains travaux proposent une génération semi-automatique d'adapteurs. [KeB03] propose par exemple un système de requête élaboré de services remplaçant celui de la plateforme OSGi. Lorsque celui-ci est appelé, il présente à l'utilisateur un panneau graphique qui lui permet de choisir les services à utiliser. Parmi les services choisis, si la correspondance syntaxique n'est pas directe, le système introspecte grâce à la réflexion Java les méthodes accessibles de ces services et du service requis, pour les présenter à l'utilisateur. Ce dernier peut alors indiquer les correspondances entre les méthodes. Si les types d'entrée et de sortie ne sont pas identiques, l'utilisateur doit alors développer les conversions de types. A la fin de ce travail, qui peut être très laborieux, l'outil génère alors les adaptateurs nécessaires.
L'équipe de Keith Edwards œuvre sur des concepts d'"informatique recombinante" [KNS01][NTKR06]. Elle a proposé récemment un cadriciel, appelée uMiddle, permettant d'établir des ponts programmatiques entre plateformes intergicielles définies comme étant du type d'UPnP, Bluetooth, Jini. uMiddle est une approche programmatique spécifiant un pivot d'interface commune et un grain fin de composition défini comme un type d'entrée et de sortie d'un service. uMiddle vise la composition d'entités réseau hétérogènes dans les environnements pervasifs. Trois contributions présentées dans l'article [NTKR06] :
• "Service Shaping" : c'est une technique de composition de services décomposés en ports (types d'arguments et de flux). Un service est défini par un ensemble de types de données d'entrée et de sortie. L'API d'uMiddle permet aux applications de chercher dynamiquement les services requérant ou fournissant des types d'arguments donnés.
• USDL (Universal Service Description Language) : USDL est un format XML pour la génération dynamique d'adapteurs. Il permet aux concepteurs de décrire leurs services dans le système de ports d'uMiddle. Des modèles USDL sont écrits pour les événements, les états et les actions UPnP par exemple. Cela permet à un traducteur UPnP générique de générer des mandataires uMiddle pour tout équipement UPnP.
• Un mécanisme dynamique de liaison d'équipements : chaque nouveau service apparaissant sur la plateforme uMiddle est décomposé en ports. Ces ports sont dynamiquement comparés et liés aux ports déjà présents sur la plateforme. La décomposition en types d'entrée et de sortie singuliers augmente les possibilités de compositions chainées.
5 SELECTION, SUBSTITUTION ET CONTINUITE DE SERVICE
Le caractère pervasif des environnements exacerbe le besoin des applications en dynamisme et de comportement autonomiques. Ces environnements sont caractérisés par la variabilité et la mobilité des entités actives environnantes. Composer dynamiquement des applications tout en garantissant la continuité de service aux utilisateurs est un défi important de l’Informatique Pervasive.
L’auto-organisation des équipements d’un réseau et la composition de fonctionnalités offertes par l’environnement dans des services de haut niveau à l’utilisateur sont les objectifs des projets de l’Informatique Pervasive. L’orientation service est à la base de plusieurs travaux de part l’adéquation entre l’ouverture des environnements pervasifs et le couplage lâche apporté par les approches à services. C’est pourquoi les tentatives d’atteindre l’auto-organisation se concentre souvent sur la recherche de méthodes de composition de services.
Les intergiciels protocolaires orientés service existants sont bâtis sur des protocoles de découverte de services, de description de services, de contrôle de services et offrent des fonctionnalités de qualité de service et de sécurité [ZMN05]. La sélection de services et le classement des services selon des critères contextuels ne sont toutefois pas complètement adressés par ces ensembles protocolaires. Les mécanismes nécessaires sont complexes en raison de la richesse et de la dynamique du contexte ouvert des environnements pervasifs tels que le réseau domestique. Ces taches de sélection sont le plus souvent l’objet d’une configuration manuelle. La sélection automatique de services est une tache difficile que de nombreux travaux tentent de traiter [BSD03][FMK06].
La composition de service au sein des applications pervasives est forcément dynamique afin de répondre à un environnement changeant. Des mécanismes de reconfiguration dynamique rendent possible la réaction adéquate aux stimuli de l’environnement. Dans les applications à service, il s’agit de délier et de lier à nouveau le demandeur de service au fournisseur le plus adéquat à l’instant de la reconfiguration. La reconfiguration dynamique d’application est ici considérée en tant que reliaison dynamique de service.
Cette reliaison dynamique pose souvent le défi de la garantie de continuité de service. Garantir la continuité de service est aisé dans le cas où les services utilisés n’ont pas d’état, c.-à-d. que chaque opération appelée ne dépend pas des précédentes. Dans le cas de services à états, l’état du service utilisé précédent doit être passé au service nouvellement lié durant la reliaison. La complexité du passage d’état tient de la spécificité de l’état de l’application au type d’application donné.
Cette partie tente d’aborder les problèmes intergiciels auxquels sont confrontés les concepteurs d’applications attentives au contexte. Avant d’adresser la reliaison dynamique de service, le "contexte" est défini dans les applications pervasives. La littérature scientifique est emplie d’approches qui définissent et décrivent le contexte applicatif de manière générale. Ces définitions sont une première donnée pour ce travail. Une deuxième donnée provient des nombreux travaux sur les approches composants et leur cycle de vie. Ces travaux permettent d’appréhender la place du transfert d’état durant la composition.
La solution idéale visée dans cette thèse est un système qui se reconfigurerait de manière proactive. La reliaison proactive de service vient de l’idée que la composition de service puisse être changée par le système durant l’exécution par la seule connaissance des facteurs contextuels et sans action explicite de l’utilisateur. Le système est proactif lorsqu’il prend des décisions de reliaisons en prévoyant le transfert d’état nécessaire. Le système décide qu’un autre fournisseur de service est meilleur que le fournisseur courant remplace ce dernier par le premier en maintenant la continuité de service.
Une définition du "contexte" est présentée dans la section suivante. Des scenarios intéressants démontrent ensuite le besoin de reconfiguration dynamique dans les applications pervasives. Enfin, une section décrit les exigences techniques nécessaires pour l’automatisation de la description du contexte applicatif, de la sélection de services conséquente et de la reliaison durant l’exécution.