3.4.1 Techniques de Proxy
Dans les années 80, Birrel et Nelson [BiN84] asseyaient les bases de la transparence d'appels répartis distants associée au paradigme procédural. La structure de leur système de répartition annonce la structure des futurs Objets Distribués et du patron "export-bind". [BiN84] décrit des modules de programmes qui importent et exportent des interfaces au travers d'un espace de nommage réparti. Une interface contient alors un ensemble de procédures avec leurs types d'arguments et de retours. Un générateur de stubs crée le code binaire des stubs associés à une interface lors de la compilation.
Figure 7 Système d'appel de procédure distant [BiN84]
Corba [CORB95] et DCOM [DCOM98] reprennent les concepts d'appels de procédures répartis et les transposent dans le paradigme objet. Les interfaces sont des ensembles de méthodes dont la signature contient les types d'arguments d'entrée et de sortie. Ces intergiciels définissent un Langage de Description d'Interface (IDL) indépendant du langage de programmation afin d'adresser le défi de l'hétérogénéité des machines. Les stubs de Corba et DCOM traduisent (marshalling) des appels locaux d'un langage de programmation du client en des messages dans un protocole de communication neutre. Les skeletons traduisent (unmarshalling) alors ces messages dans le langage de programmation du serveur. Le retour de l'appel de méthode s'effectue de manière inverse du serveur vers le client. [DCOM98] spécifie un système de gestion d'appel réparti au-dessus de la technologie COM.
Java RMI (Remote Method Invocation) diffère des technologies RPCs comme Corba, DCOM car elle n'adresse pas l'hétérogénéité des plateformes d'exécution [Wal98]. En raison de cette hypothèse d'hétérogénéité, Corba et DCOM ne permettent pas le polymorphisme des objets passés entre client et serveur. Le lien défini statiquement par l'IDL ne peut pas être redéfini par le serveur à l'exécution sans la définition de conventions complexes pour la transposition entre IDL et les différents langages de programmation.
Java RMI impose le langage Java sur toutes les plateformes distribuées participant à une application. Fort de cette hypothèse et des capacités de chargement dynamique de classe permis par Java, le client (ou le serveur) d'une communication distribuée peuvent définir des sous-types d'interfaces. La machine recevant l'objet inconnu sera capable de reconnaître le sous-type et d'installer le stub adéquat. Le stub aura été compilé durant la compilation de l'objet. Le téléchargement de stubs et le chargement de classes de Java permet ensuite le chargement dynamique des classes du sous-type sur le membre recevant le code inconnu auparavant. La responsabilité de la génération du stub repose sur l'objet alors que dans les systèmes RPCs comme Corba et DCOM, la responsabilité repose sur chacune des parties prenantes de la communication.
3.4.2 Découverte de service et Proxy
L'appel distant d'une méthode ou d'une procédure implique que la localisation de l'entité distante soit connue au préalable. Dans un système simple, l'adresse des entités distribuées peuvent être connues par elles avant exécution. Dans la plupart des systèmes (le système de Birrell et Nelson [BiN84], Corba [CORB95], Jini [GTA02]), une entité commune sert d'annuaire de références réparties. Les serveurs s'enregistrent auprès de cet annuaire tandis que les clients s'y connectent pour rechercher leurs interlocuteurs durant l'exécution. Les premiers annuaires étaient des serveurs de nommage (e.g., Corba Naming Service) qui répertoriaient les références d'implémentations d'interfaces sous un nom de serveur. Ensuite sont apparus les serveurs de courtage ou répertoires de services (e.g., Corba Trading Service, Jini Lookup Service). Ces serveurs permettent un courtage des objets enregistrés selon une liste extensible de critères (cf. section 2.3).
3.4.3 Réingénierie de code binaire et Proxy
Coign [HuS99] démontre la faisabilité de la réingénierie de code binaire pour la répartition d'une application. Le système Coign agit sur les composants de la technologie COM (Component Object Model de Microsoft). Dans une première phase de profilage, Il permet d'intercepter tous les appels aux interfaces COM définies dans le programme. Un échantillon de scénarios pertinents est alors nécessaire afin de déterminer quelles interfaces sont possiblement "distribuables". Si des arguments pointent sur un système de mémoire partagée, les interfaces correspondantes sont déclarées non distribuables. Les interfaces appelées peu fréquemment sont les plus éligibles. Dans une deuxième phase, lorsque les interfaces à distribuer sont choisies parmi les interfaces distribuables, Coign génère des objets proxys (stubs et skeletons) de type DCOM [DCOM98] afin de "distribuer" les interfaces choisies.
Figure 8 Partitionnement automatique de programmes Java avec J-Orchestra J-Orchestra [TiS02] est un système de partitionnement automatique de programmes Java. Il transforme le bytecode d'applications Java (code binaire Java) en applications distribuées s'exécutant sur plusieurs machines virtuelles. Selon un plan de déploiement inscrit par l'utilisateur en entrée, J-Orchestra réécrit le bytecode des appels locaux de méthodes en appels RMI et transforme la représentation des objets appelés en proxys distants, etc. Une phase distincte d'analyse statique et de profilage permet de minimiser le trafic réseau associé à la partition. Le profilage est effectué selon des heuristiques simples procurées par J-Orchestra. L'analyse statique permet d'indiquer à l'utilisateur les parties qui peuvent être distribuées (cf. Figure 8). Les parties qui doivent demeurer entières sont généralement des parties de code natives même si J-Orchestra parvient à distribuer aussi le code natif grâce à des proxys Java.
3.4.4 Découverte de service, réingénierie de code binaire et Proxy
La technologie OSGi [OSGi05] spécifie un système de déploiement de modules applicatifs, appelés bundles, sur une plateforme Java locale (cf. Chapitre III.3.3.1). Utiliser la frontière de ces modules applicatifs comme frontière naturelle possible pour la répartition est l'option choisie par plusieurs travaux récents. La modularité du système permet une délimitation naturelle par le développeur des entités à distribuer sans utilisation indispensable d'un outil de profilage (cf. section 3.4.3)
Au-dessus de ce système modulaire, la technologie définit un système de recherche et de liaison de services locaux entre bundles. Ce système est basé sur le patron de conception Service Locator [Fow04] qui répond à la demande de découplage d'une application par rapport à des composants substituable, communément appelés plugins, et qui donne le contrôle de la composition applicative à une entité extérieure à l'application et ses plugins. Ce patron de conception est l'application objet du paradigme d'orientation service :
• Une interface de service est une interface dans un langage objet, sous le nom de laquelle un objet est enregistré.
• Un fournisseur de service enregistre un objet dans le registre de service. Les références enregistrées sont disponibles à tous les objets de la plateforme sous condition de partage de domaine d'application et de droits d'accès éventuels.
• Un demandeur de service, ou client, est un objet qui requiert la référence et invoque des méthodes sur l'interface recherchée.
Ce patron combiné au patron "Remote Proxy" permet le choix transparent d'une liaison locale (appel programmatique) si les clients et serveurs sont co-localisés et d'une liaison distante (appel protocolaire) dans le cas réparti.
Parmi les travaux basés sur ces deux possibilités, certains visent les scénarios de contrôle d'équipements domestiques standards, ce qui implique une certaine influence du développement par les interfaces standardisées des équipements :
• Implémentations de l'OSGi Device Service Specification [OSGi05] (par exemple, Apache UPnP Base Driver1) allié à des outils de génération de code source Java pour UPnP sur OSGi [2006-3] comme les outils de D. Donsez2. Ces implémentations et ces outils permettent aux développeurs de concevoir des applications de contrôle d'équipements en utilisant des APIs Java qui représentent les services UPnP par des interfaces Java aux méthodes projetant noms et types naturellement dans le système Java. Les objets appelés sont soit le code d'implémentation du service dans un bundle OSGi, soit un objet mandataire du service UPnP distant qui est réifié sur la plateforme par le Base Driver. La publication [2006-3] expose la finalité de ces outils (cf. Chapitre VI.4.3).
D'autres travaux visent la répartition d'applications de manière complètement transparente pour le développement :
• Knopflerfish OSGi-Axis bundle3 : un bundle qui, grâce au générateur dynamique de mandataires Web Services Apache Axis et au serveur HTTP de la spécification OSGi, permet de représenter toute implémentation de service OSGi
1 http://felix.apache.org/site/apache-felix-upnp.html
2 http://www-adele.imag.fr/users/Didier.Donsez/dev/osgi/upnpgendevice/readme.html
3
comme un Web Service servi par la plateforme. La génération est une instanciation d'objets adaptée à l'offre de service OSGi qui est analysée par réflexivité Java. La génération de stubs clients semble naturellement possible. Ce système manque toutefois d'un système complémentaire de découverte de services répartis sur les plateformes OSGi impliquées.
• Newton1 : ce projet est basé sur les technologies OSGi [OSGi05] et Jini [GTA02] et suit les concepts d'architecture SCA (Service Component Architecture), un ensemble de spécifications issu de la collaboration industrielle nommée Open SOA (www.osoa.org). Newton propose un modèle à composants consistant en la composition de services locaux OSGi et distants Jini en ensembles appelés composites décrits par un fichier de métadonnées. Celui-ci indique les classes à instancier, classes qui représentent les composants de l'application. Il décrit aussi les services que chaque composant requiert ou offre avec le type de lien. Le type peut être spécifié local ou distant. Si le lien est dit local, il sera fait d'appels programmatiques direct Java comme dans la programmation OSGi classique et utilisera le registre de service OSGi. S'il est dit distant, il sera fait d'appels RMI et utilisera le répertoire de service Jini.
• Extended Service Binder : ce travail, qui fait partie des contributions de cette these est principalement basé sur les technologies OSGi, SLP, RMI [2008-3][2006-6][2006-4][2006-2][2005-1] et a fait l'objet de quelques variantes [2006-5]. Il est l'objet de la section Chapitre VI.2.
• R-OSGi [RAR07] : ce travail tire son originalité de la complétude de son approche. Celle-ci combine un système de réécriture binaire à l'exécution allié à un algorithme de "closure" de ressources dépendantes de code, un répertoire de services OSGi réparti masquant la recherche distante de service, l'utilisation du modèle du patron de conception "Tableau Blanc" pour la communication asynchrone et l'utilisation des exceptions de chargement et de déchargement de module afin de masquer les erreurs dues à la distribution. Si certains traits de l'implémentation et les choix des scénarios sont critiquables, force est de reconnaître que l'article [RAR07] est une référence de la communauté OSGi qui pose clairement le problème et la solution de scénarios de répartition d'applications post-développement en regard des possibilités procurés par les nouvelles technologies de déploiement modulaires telles qu'OSGi [OSGi05].
• D-OSGi [MSSG08] : l'objectif de ces travaux est de distribuer le modèle d'application orienté service d'OSGi à une fédération de plateformes. L'originalité de cette nouvelle plateforme appelée D-OSGi réside en l'utilisation du modèle publish-subscribe pour les échanges entre plateformes et sur le choix de l'intergiciel Lime pour l'implémentation de cette architecture distribuée. Cet intergiciel connu dans l'InformTraatique Mobile [MPR06] permet le partage d'un espace constitué de données appelées tuples entre différentes plateformes à la connexion intermittente. L'intergiciel Lime offre tolérance aux pannes, mobilité de code et d'autres propriétés intéressantes dans l'Informatique Pervasive. Les performances associées sont toutefois inférieures à celles de R-OSGi. Les auteurs présentent ce défaut comme bien inférieur aux avantages apportés par le support de Lime. D-OSGi est comparé à R-OSGi dans [MSSG08] et utilise officiellement une technique similaire de closure de ressources dépendantes que l'article appelle la technique du porte-documents ("briefcase").
1
R-OSGi est probablement la tentative la plus achevée de distribuer des services sur plusieurs plateformes homogènes de manière transparente. La phase de réécriture s'effectue à l'exécution, phase la plus tardive après développement. Le travail débuta en 2005 dans un laboratoire Suisse et a été le sujet de plusieurs articles publiés par Jan S. Rellermeyer jusqu'à la fin de l'année 2007. Le résultat du projet est livré en open source1. Le projet Newton de la Société Paremus et l'Extended Service Binder (cf. Chapitre VI.2) ont été concurrents dans cette recherche de transparence sur un système d'applications modulaires. L'Extended Service Binder utilise RMI pour la génération de proxies au moment des liaisons de services et SLP pour la découverte de services sur des plateformes OSGi réparties. Le choix de SLP, commun à R-OSGi, n'est certainement pas un choix pertinent puisque c'est un des rares protocoles à ne permettre que la découverte active alors que le mode événementiel est demandé par les applications pervasives. Si R-OSGi est plus avancé, c'est qu'il optimise la génération de proxies avec le kit de développement ASM. Cette génération de proxies et la communication sont démontrées plus efficaces sur R-OSGi par rapport à un système RMI (cf. [RAR07]). L'utilisation des erreurs de déploiement de modules afin de masquer les erreurs dues à la distribution est aussi une astuce intéressante. Surtout il met en œuvre une analyse des dépendances de code afin de déployer le code manquant sur la plateforme cliente distincte.
4 GESTION DE L'HETEROGENEITE DES EQUIPEMENTS
Alors que les applications pervasives deviennent possibles et que le réseau domestique devient une réalité [Aie06], seules quelques rares ilots d'équipements montrent une collaboration réelle au service de l'utilisateur. Connecter les ilots de découverte ("Connecting Islands of Discoverability") est un des quatre thèmes de recherche en Informatique Ubiquitaire discerné par Keith Edwards [Kei06].
Le meilleur exemple est certainement représenté par les équipements domestiques multimédia dont le succès est accompagné aujourd'hui par un effort de normalisation important par les deux consortiums UPnP – www.upnp.org – et DLNA – www.dlna.org : des équipements jouent le rôle de serveurs de contenus (Media Server), par exemple les équipements de stockage autonomes appelés NAS (Network-Attached Storage), le mobile, le PC. Un deuxième type d'équipements possède le rôle de serveur de restitution (Media Renderer), par exemple la télévision, la chaine Hi-Fi, le centre multimédia, la Set-Top-Box. Ces deux entités sont mises en relation par une troisième entité appelée point de contrôle (Control Point). Ce dernier va permettre à l'utilisateur au travers d'interfaces graphiques de naviguer dans le contenu disponible, de choisir un contenu à visionner, et de jouer ce contenu sur l'équipement de son choix, par exemple la télévision du salon.
D'autres exemples existent par exemple dans la domotique. Un système centralisé se connecte à de nombreux capteurs et appareils électronique de confort. Il permet à l'utilisateur de contrôler les lumières, les volets et les portes afin d'optimiser le confort et la sécurité dans les situations de la vie quotidienne. Le système contrôle habituellement tous les équipements au travers d'un protocole unique.
Ces exemples de systèmes domestiques montrent non seulement que les domaines d'applications demeurent séparés mais que de nombreux protocoles concourent pour l'implémentation des mêmes systèmes (cf. Figure 9). Le domaine multimédia est par exemple occupé principalement par UPnP/DLNA, les technologies Apple (Bonjour, iTunes) et le standard IGRS – www.igrs.org. La domotique est, elle, visées par les organisations ou marques importantes suivantes : KNX (la convergence des standards européens EHS,
1
BatiBUS, EIB), l'initiative asiatique Echonet, l'Alliance ZigBee, la compagnie LonWorks, la compagnie X10.
Les scénarios ci-dessous montrent le besoin de permettre aux applications d'utiliser aisément plusieurs protocoles issus de domaines d'applications parfois distincts. Le problème ne se limite pas seulement au besoin passerelles de traduction ou dans le besoin d'interfaces génériques pour accéder à tout protocole. En effet, la variété de la sémantique des interfaces définies au-dessus de ces protocoles hétérogènes rend inutile les passerelles simples entre protocoles. Il s'agit aussi de surmonter la "fragmentation des interfaces" [Vay01]. Même dans un seul protocole, deux types d'interfaces définissant sémantiquement une imprimante peuvent être décrites dans un ensemble d'actions sémantiquement proches mais syntaxiquement distincts. Des techniques de médiation évoluées sont nécessaires afin de rapprocher les protocoles et interfaces à la sémantique similaire mais à la syntaxe distincte.
4.1 Scénarios
L'innovation dans les services de télécommunications est tirée par les possibilités de convergence du réseau IP – ADSL, IPTV, VoIP, Partage multimédia, domotique. De nombreux scénarios innovants reposent sur le rapprochement de plusieurs protocoles et de différents domaines d'applications. Dans cette section sont proposés trois types de scénarios : les scénarios de contrôle d'équipements, de communication personnelle et d'administration d'équipements. Dans chaque scénario, l'hétérogénéité des protocoles et le rapprochement de domaines d'applications distincts sont mis en exergue.
4.1.1 Contrôle d'équipements
Figure 9 Domaines d'applications et protocoles hétérogènes
Maxandre est un jeune homme qui a installé les dernières technologies réseaux dans son appartement.
4.1.1.1 Système home cinéma intelligent
Maxandre a installé une télévision UPnP qui lui permet de rechercher des fichiers vidéo sur son PC à partir de la télévision dans son salon afin de les visionner sur celle-ci. Il possède aussi un boitier intelligent qui écoute les événements UPnP afin de réagir à ceux-ci en adaptant les services de confort environnant comme les lumières X10 et les volets ZigBee. Lorsqu'un film démarre sur la télévision, les lumières se tamisent et les volets se ferment dans le salon.
Ce premier scénario mêle la domotique au multimédia et utilise plusieurs protocoles dans le domaine de la domotique. Plusieurs protocoles, UPnP et iTunes, auraient pu aussi être
utilisé pour la recherche de contenus multimédia sur des applications diverses, UPnP et Apple iTunes.
4.1.1.2 Partage de services entre plateformes intelligentes
Le boitier intelligent de Maxandre est un équipement qui est branché au réseau domestique par un cable Ethernet et un cable éléctrique avec une technologie de courants porteurs. Cependant, le boitier n'est pas capable d'écouter les protocoles sans fils comme le protocole ZigBee. Par conséquent, la compagnie vendant le boitier vend aussi une passerelle complémentaire afin de lier les équipements radio aux applications du boitier. La passerelle fait le pont entre les équipements radios ZigBee et un protocole connu par le boitier.
Une mise à jour du boitier intelligent est nécessaire afin de communiquer avec les nouveaux services procurés par le boitier complémentaire. Par conséquent, lorsque Maxandre branche la passerelle, il lui est demandé s'il accepte que la mise à jour puisse être effectuée.
Ce deuxième scenario illustre une application domotique usuelle où les équipements sont accédés au travers d'une passerelle spécifique. La passerelle est connectée utilise une couche physique spécifique du réseau capillaire formé par les équipements radio ZibBee. Cette passerelle permet à d'autres plateformes d'utiliser les services domotiques.
4.1.1.3 Diagnostique du fonctionnement d'équipements
Maxandre s'aperçoit que l'une des lumières du salon ne se tamise pas lorsqu'un film commence sur la télévision. Il ouvre les pages web du boitier intelligent afin de tester et de configurer son réseau domestique. Il teste les équipements de lumières du salon un par un et configure la localisation des lumières ZigBee. La localisation de la lumière correspondante n'était pas configurée avant cette opération. Le système Home Cinema permet maintenant de tamiser toutes les lampes du salon.
Ce scenario d'auto-diagnostique par l'utilisateur (self-care) montre le besoin d'outils agnostiques aux technologies afin d'aider les utilisateurs dans leurs taches d'analyse des dysfonctionnements de leur réseau. Des scénarios utilisant les protocoles du réseau domestique dans des applications d'administration sont décrits dans plusieurs travaux, par exemple [NPD07].
4.1.2 Communication interpersonnelle
Figure 10 Terminal de télécommunication éclaté sur plusieurs équipements Alice communique avec Bob confortablement assise dans le salon. Grâce aux capteurs disséminés dans le salon et à une caméra adaptée à la visiophonie, le système de communication permet à Bob de voir Alice parler dans son canapé. Le téléphone perfectionné de Bob envoie aussi des images à Alice qui les voit directement sur son