Afin d'adresser l'hétérogénéité de technologies protocolaires ou programmatiques, il est naturel d'emprunter des techniques de médiation. La médiation est l'action de jouer l'intermédiaire entre deux interlocuteurs aux langages ou à la culture distincte. En informatique, la médiation est la transformation soit d'un langage dans un autre, soit d'un protocole dans un autre ou encore d'une interface programmatique dans une autre afin de permettre la communication entre plusieurs programmes qui ne sont pas interopérables. 4.2.1 Passerelles et pivot commun
Lorsque seuls deux protocoles (ou langages ou interfaces programmatiques) distincts existent, il est naturel d'utiliser une passerelle afin de transformer les appels effectués dans un protocole en appels dans l'autre protocole. Dans les applications de contrôle d'équipements, il est possible d'élaborer des passerelles entre un protocole de découverte et un autre. Indiss [BrI05] démontre la faisabilité d'un tel système. Tous les messages de découverte émanant d'équipements SLP sont réémis par la passerelle en UPnP et vice-versa. Les passerelles Internet sont un autre exemple, elles retranscrivent les adresses locales des équipements domestiques en l'adresse publique de la passerelle dans les messages de requêtes sortantes et permettent la retranscription inverse pour les messages de retour. Cela permet de générer un nombre d'adresses IP locales important sans occuper les bandes d'adresses Internet qui sont comptées tout en permettant aux équipements locaux d'accéder à des informations sur
Internet de manière transparente. JNI est un autre exemple de passerelle : JNI est une librairie Java permettant à un programme Java d'inter-opérer avec des librairies écrites dans un langage natif. L'article [YSHT07] montre un exemple de pont entre interfaces programmatiques. Le système décrit enregistre les objets Xlets d'une plateforme (Java) MHP dans le register de service OSGi tandis que les services OSGi sont accessibles dans le repertoires iXC de la plateforme MHP.
Lorsque les protocoles (ou langages ou interfaces programmatiques) deviennent nombreux, il devient plus efficace d'élire ou d'élaborer un protocole (ou langage ou interface programmatique) commun. En effet, comme le montre de nombreux travaux (MSDA [RCCI05], une architecture de pilotes Jini [Vay01], etc.), le nombre de passerelles à élaborer lorsque un nombre n de protocoles existe augmente en O(n²) – le nombre total de passerelles entre n protocoles est n(n+1) – alors que l'élaboration d'un protocole commun entre n protocoles ne nécessite qu'une transformation de chaque protocole en le protocole commun, soit n transformations. C'est ainsi que MSDA [RCCI05] propose un protocole commun afin de composer les réseaux d'équipements aux protocoles divers : SLP, UPnP, Jini et quelques autres. Le consortium Salutation a suivi une approche similaire durant quelques années au tournant du siècle (cf. Chapitre III.1.1.7). C'est ainsi que la spécification JBI (Java Business Integration) propose une API commune afin que des applications disparates puissent communiquer entre elles. Les ESB (Enterprise Service Bus) proposent un bus à messages commun afin de permettre la communication entre des applications qui ne sont pas écrites pour être interopérables au préalable. La médiation vers un pivot commun est aussi l'approche prise par les travaux finaux de cette thèse nommés Home SOA (cf. Chapitre V.4) pour le contrôle d'équipements domestiques.
4.2.2 Approche protocolaire et approche programmatique
Le pivot commun entre moyens de communication distincts (langage, protocole, interface programmatique) peut être de nature protocolaire ou programmatique, c'est-à-dire décrite dans un langage de programmation. Lorsque plusieurs applications sont distribuées et qu'aucun protocole n'existe, il est naturel d'élaborer ou d'élire un pivot de nature protocolaire. Ce pivot protocolaire commun nécessite une réécriture partiels des clients et serveurs afin qu'ils communiquent dans ce protocole. C'est une approche prise par les protocoles indépendants des langages programmatiques en général. Elle est suivie par
• par la plupart des protocoles de contrôle d'équipements qui lient des applications embarquées sur des équipements hétérogènes (cf. Chapitre III.1 pour la définition de protocoles de contrôle d'équipements),
• par les protocoles d'administration d'équipements qui permettent à des serveurs d'administrer des équipements hétérogènes (cf. Chapitre III.3 pour la définition des protocoles d'administrations, cf. Chapitre V.6 et Chapitre VI.6 pour l'élaboration du protocole UPnP DM)
• les ESBs et les Web Services qui lient des applications disparates,
• etc.
Lorsque plusieurs protocoles existent, il est aussi possible d'élire ou d'élaborer un protocole commun Toutefois, ce moyen de médiation protocolaire s'avère souvent peu efficace : premièrement, il induit des retransmissions d'information dans un protocole distinct, ce qui augmente la bande passante nécessaire et qui allonge le temps de communication entre deux applications aux protocoles distincts (2 protocoles et le protocole pivot) par rapport à une communication directe entre deux applications communicant avec le même protocole (seulement un protocole) ou même au travers d'une passerelle (seulement 2 protocoles). Deuxièmement, sa pertinence dépend de la sémantique des applications utilisant les protocoles différents. Si la sémantique des applications est très proche, par exemple celle
d'applications de messagerie instantanée textuelle qui utiliseraient des protocoles différents, l'une Windows Messenger et l'autre le protocole Jabber, les passerelles protocolaires seront simples et ne nécessiteront aucune modification des applications afin d'inter-opérer. Lorsque la sémantique est variable, par exemple dans les applications de contrôle d'équipements où les types d'applications sont divers, la simple réémission des messages d'un protocole dans un autre génère des interférences sans aucune interopération. C'est le cas des architectures proposant un protocole pivot entre protocoles aussi divers que SLP, UPnP, Jini sans cibler d'applications. Ces protocoles étant très génériques, un client Jini ne pourra inter-opérer avec une télévision UPnP que si le client est une application multimédia et que le pont est spécifique à l'application de jeu de flux sur une télévision. Si le pont protocolaire n'est pas spécifique, une des deux parties (client ou serveur) devra être réécrite afin de communiquer avec l'autre partie. C'est probablement la raison de l'échec du standard Salutation par exemple (cf. Chapitre III.1.1.7).
Dans de nombreux cas, il est plus pertinent d'élaborer des interfaces programmatiques communes. Le pivot commun est alors effectué au niveau programmatique. REMMOC [GBS03] est un modèle pionnier dans la médiation de protocoles de découverte au travers d'interfaces programmatiques communes. OSGi [OSGi05] est un des standards qui s'est fondé sur une approche programmatique, sur cette vision que le contrôle d'entités hétérogènes nécessite des techniques au niveau langage. Home SOA (cf. Chapitre V.4) affine l'approche dans le cadre du contrôle d'équipements dans les réseaux pervasifs. Certaines équipes comme celle de Keith Edwards [NTKR06][KNS01] proposent aussi une approche programmatique mais avec un grain plus fin de composition qui la fait appartenir au domaine des approches sémantiques. Dans tous les cas, le patron Adapteur [GHJV95] est utilisé afin de représenter des objets existants selon les interfaces d'un pivot commun.
4.2.3 Approche syntaxique et approche sémantique
La différence majeure entre les deux approches tient en la définition du grain de transformation. Les approches usuelles considèrent le type du service, parfois même le type associé à l'ensemble des services d'un équipement comme grain de comparaison et de transformation. La médiation établit des transformations entre types reconnus de manière syntaxique.
Un courant théorique plus marginal mais en expansion aujourd'hui considère que le grain de comparaison et de traduction doit être plus sémantique. Les approches dites sémantiques reposent en finale évidemment sur des comparaisons syntaxiques mais la sémantique ressort de comparaisons syntaxiques de grain plus fin : le nom de chaque opération et type des arguments d'entrée et de retour sont considérés. Si les signatures d'opérations sont proches, cela donne des indices sur la proximité sémantique des opérations. Grace à ce grain plus fin, les chances de substitutions d'opération par une autre sont plus grandes que la substitution d'un service par un autre avec l'approche syntaxique usuelle. L'équipe de Keith Edwards [NTKR06][KNS01] œuvre sur des systèmes de recombinaison d'opérations identifiées par les types de données d'entrée et de sortie. Les comparaisons sémantiques peuvent aussi reposer sur des équivalences sémantiques indiquées par des sortes de dictionnaires appelés "ontologies". La souplesse des équivalences sémantiques montre toutefois rapidement ses défauts dans les applications concrètes où la rigueur des approches syntaxiques est préférée. Cette thèse a été l'occasion d'une preuve de concept d'une approche sémantique (cf. Chapitre V.4.4).
4.2.4 Génération semi-automatique et automatique d'adapteurs
Grâce aux techniques de passerelles et d'approches de médiation protocolaire, le nombre d'entités contrôlables – les services d'une architecture orientée service – dans un même protocole augmente. Ces situations augmentent l'ampleur du problème d'hétérogénéité sémantique visible dans tout environnement ouvert à des applications développées par
différentes parties. Dans ces environnements, il s'avère que de nombreuses interfaces sont sémantiquement proches mais syntaxiquement incompatible. Le type "imprimante" peut par exemple être trouvé en plusieurs exemplaires sous des formes syntaxiques différentes. Ce phénomène est parfois nommé "fragmentation d'interfaces" [Vay01][Law00]. D'autres travaux [PoF03] montrent que les adapteurs peuvent être qualifies "à perte", c'est-à-dire générer des pertes en nombre et en qualité des opérations et ne pas fournir totalement les fonctionnalités attendues. Ces travaux proposent une approche d'évaluation de ces pertes.
Différents travaux tentent de générer automatiquement ces adapteurs. Des méthodes de génération semi-automatiques sont proposés dans quelques projets. Elles permettent à l'utilisateur – ou l'administrateur – d'indiquer au système qu'une application est compatible avec une autre malgré une incompatibilité syntaxique apparente. Grâce à l'analyse de l'utilisateur, le système peut alors tenter de générer un adapteur après introspection des interfaces requises par l'application cliente et les interfaces fournies de l'application serveuse. Si l'adaptation n'est pas simple et que l'utilisateur possède quelques connaissances techniques, le système peut encore proposer à l'utilisateur d'indiquer quelles méthodes semblent sémantiquement proches et, plus loin, lui proposer un panneau graphique pour la programmation de conversion de types d'arguments [KeB03]. La génération d'adapteurs semi-automatique repose ainsi sur différents degrés de compétences de l'utilisateur pour l'adaptation du système.
La génération automatique d'adapteurs repose sur des techniques algorithmiques et sémantiques avancées. Certaines constructions algorithmiques peuvent rapprocher et adapter des interfaces dont les signatures de méthodes sont proches par leurs types d'entrée et de sortie [Tha94]. L'héritage de l'orientation objet et le polymorphisme des méthodes sont des critères d'analyse. Ces techniques logiques ne tiennent toutefois pas compte des noms de méthodes et d'arguments. Elles peuvent être associées à des techniques sémantiques. Les ontologies, une sorte de dictionnaires de correspondances de noms et de types à tout niveau, permettent dans quelques cas simples d'analyser et d'adapter automatiquement des interfaces syntaxiquement incompatibles. Ces techniques sont gourmandes en ressources et leurs résultats sont souvent limités, l'objectif étant ambitieux.
4.3 Exigences techniques
4.3.1 Exigences générales de l'Informatique Pervasive
La flexibilité est l'exigence technique principale face à l'ouverture des environnements pervasifs. La flexibilité visée doit permettre aux architectures déployées d'accepter rapidement et sans heurt des nouveaux protocoles à la demande tout en gardant des applications en cours de fonctionnement. La flexibilité concerne aussi l'intégration d'équipements aux fonctions sémantiquement pertinentes découverts avec les pilotes présents. Des exigences techniques précises découlent de cette demande générale de flexibilité :
• Couplage lâche : Les applications bâties sur l'utilisation d'équipements disponibles dans un environnement ouvert doivent être faiblement couplées avec ces équipements. De la lâcheté du couplage dépend l'évolutivité de l'application à l'exécution et au développement d'améliorations futures.
• Interfaces uniformes. L'hétérogénéité des protocoles doit être masquée au développeur. Celui-ci doit pouvoir aisément utiliser les équipements les plus adaptés sans connaître profondément les interfaces réseaux de chaque technologie. Cela rejoint l'exigence technique de séparation des préoccupations générale : la logique de l'application doit être séparée de la gestion générique totale ou partielle de certains aspects par le système
environnant – dans le cas des travaux de cette thèse, les trois aspects sont répartition, hétérogénéité, dynamique.
• Chargement logiciel à la demande. La gestion d'un nouveau protocole ou d'un nouvel équipement ne doit idéalement arrêter le fonctionnement d'aucune application. Cela implique des propriétés de chargement dynamique de code ou de fonctionnalités par le système. Dans un système moins performant, l'ajout de fonctionnalités au redémarrage est aussi possible et moins couteux. Et si le système ne possède pas de telles propriétés, la demande de modularité peut être comblée par l'installation de passerelles protocolaires. Toutefois, comme il est montré dans la section 4.2.2, les passerelles protocolaires s'avèrent couteuses ou peu pertinentes dans certaines situations.
• Découverte protocolaire réactive. L'entrée et le départ d'un équipement doit être notifié sur la plateforme de composition. Un équipement apportant des fonctions requises mais qui est accessible selon un nouveau protocole déclenche le processus d'installation du pilote pour celui-ci.
4.3.2 Communication interpersonnelle
Les scénarios de communication personnelle enrichie (cf. Figure 11) exposent des exigences techniques particulières. L'exigence suivante concerne l'hétérogénéité :
Figure 11 Communication interpersonnelle entre deux réseaux domestiques
• La négociation et l'adaptation de flux initiés par les applications de contrôle. Afin de faire inter-opérer les équipements du réseau domestique avec les terminaux de communication interpersonnelle, les applications doivent non seulement faire face à l'hétérogénéité des protocoles de contrôle mais aussi négocier et parfois adapter les formats et protocoles de flux multimédia selon les cas. La situation typique est celle des équipements UPnP/DLNA qui utilisent exclusivement le protocole de flux HTTP alors que les équipements SIP utilisent exclusivement RTP. UPnP/DLNA est le standard principal des équipements multimédia de la maison tandis que SIP est majoritairement accepté comme le protocole de la communication interpersonnelle sur IP.
4.3.3 Administration d'équipements
Deux objectifs distincts sont rencontrés sur le thème de l'hétérogénéité des protocoles du réseau domestique pour l'administration. Premièrement, combler le besoin de pont entre un protocole d'administration tel TR-069 [TR6904] et les protocoles de contrôle tel UPnP, ce qui est l'objectif de travaux comme [NPD07]. Cela permet de tester les services domestiques existants à partir d'un serveur d'administration. Ce besoin est similaire à l'exigence d'interfaces uniformes afin de représenter tous les équipements quels que soient leur protocole de contrôle. Cette fois, le protocole commun est celui du protocole d'administration. L'enjeu sera alors de spécifier un modèle de conversion entre chaque protocole domestique et le protocole d'administration.
Le deuxième objectif est de définir une interface générale d'administration pour les équipements en général. C'est l'objectif notamment du Comité de Travail UPnP Device Management (ex-Execution Platform) [2007-9] (cf. Chapitre V.6). Cette fois, le besoin est de définir un protocole qui s'appliquera de manière uniforme sur chacune des technologies. Les fonctions doivent pouvoir s'adapter à chaque plateforme à l'implémentation.