Exemples d’intergiciels interopérables

Comme exemples de concrétisation du connecteur C-SUB, nous présentons dans la section 3.4.1 ReMMoC³ [109], [120] puis OSGI⁴ [117], le premier appartenant à la dernière génération des intergiciels réflexifs, le second étant un des intergiciels ubiquitaires industriels le plus souvent utilisé, tandis que pour le connecteur C-TRAD nous introduisons dans la section 3.4.2 les ESBs⁵ [118] qui définissent les bases de la

traduction de protocoles à grande échelle.

3.4.1 Implémentation de la substitution de protocoles

La spécification de la substitution de protocole donnée dans la section précédente dénote le caractère dynamique et reconfigurable du connecteur C-SUB et implicitement celui de l’intergiciel ainsi modélisé. Dans la solution présentée dans les références [41], [42], la capacité d’un intergiciel à se reconfigurer dynamiquement est une fonctionnalité clé de la prochaine génération d’intergiciels afin qu’ils puissent s’adapter aux changements susceptibles de survenir dans leur environnement. L’auteur de la référence [42] prône la création d’intergiciels reconfigurables via le mariage des techniques de réflexion [112] et des technologies à composants logiciels [111]. Ces composants, sont des briques logicielles préfabriquées et indépendantes conçues pour être composées les unes avec les autres [110]. Il existe plusieurs technologies à composants : COM [121], EJB [122], CCM [123], FRACTAL [124], .Net [125]. Bien que la définition d’un composant varie d’une technologie à une autre, les concepts clés sont les interfaces, les réceptacles et les connexions (voir Figure 20). Un composant est décrit par des interfaces et des réceptacles précisant respectivement les fonctions (ou opérations) fournies et requises par le composant. Une connexion représente une liaison entre deux composants ayant une interface et un réceptacle identiques.

Figure 20. Composants logiciels

L’utilisation de composants logiciels pour construire la structure interne d’un intergiciel favorise sa reconfiguration, et la réflexion le dote de la capacité à s’inspecter et à se modifier lui-même au cours de son exécution. Un groupe d’intergiciels réflexifs expérimentaux implémentant ces principes ont émergé ces dix

3 Reflective Middleware for Mobile Computing. 4 Open Service Gateway Initiative.

5 Enterprise Service Bus.

Composant Logiciel 1 Composant Logiciel 2 Interface Réceptacle Connexion

dernières années [113], tel que OpenOrb [42], DynamicTAO [114], OpenCORBA [115], et OpenCOM [126] et constituent le point de départ de la conception d’intergiciels réflexifs conçus pour résoudre l’hétérogénéité d’intergiciels [109]. C’est dans ce contexte que nous présentons, comme premier exemple, ReMMoC [120], héritier d’OpenCOM, qui appartient à la dernière génération d’intergiciels réflexifs développés à l’université de Lancaster [116]. Comme second exemple, nous introduisons, OSGi, pour deux raisons : (i) c’est un intergiciel reconfigurable provenant du milieu industriel usuellement embarqué dans divers objets

communicants de notre quotidien [117], et (ii) c’est un intergiciel Java souvent

réutilisé dans des architectures de services ubiquitaires comme Gravity [119] et Amigo [127].

• ReMMoC

Un objet communicant d’un environnement ubiquitaire ne sait pas à l’avance avec

quels intergiciels les services distants, avec lesquels il est susceptible d’interagir, sont implémentés. Etant donné la diversité d’intergiciels existants, il est fort probable que cet objet communicant ait à interagir avec d’autres objets reposant sur des intergiciels incompatibles avec le sien. ReMMoC est un intergiciel réflexif conçu pour résoudre cette problématique : il est capable d’interagir avec divers intergiciels malgré l’hétérogénéité de leurs fonctions de communication et de découverte de services suivant le principe de la substitution de protocole. ReMMoC a la capacité de se reconfigurer dynamiquement, afin de sélectionner le protocole de découverte services, et le protocole de communication adapté suivant son environnement d’exécution.

Pour atteindre cet objectif, la structure interne de ReMMoC se décompose en deux conteneurs de composants (composant framework) [110] qui en fonction de leur configuration respective, permettent de gérer différents types de protocoles. Chaque

framework, gère le cycle de vie de ses composants : leur activation, désactivation, la

validité de leur assemblage/réassemblage et de leurs dépendances [126]. En d’autres termes, un framework contrôle l’évolution dynamique de l’intergiciel et s’assure que ce dernier reste dans un état stable quelles que soient les reconfigurations engagées. ReMMoC se compose donc :

1. D’un premier framework (Figure 21A), dénommé discovery

framework, qui rassemble les composants implémentant divers SDPs

tels que SSDP, SLP.

2. D’un second framework (Figure 21B), appelé binding framework, qui regroupe, les composants implémentant différents protocoles de communication tel que IIOP, SOAP.

La reconfiguration de l’intergiciel, (c'est-à-dire, la modification de l’assemblage des composants des différents frameworks), est réalisée par ReMMoC suivant la détection du SDP en cours d’utilisation dans l’environnement réseau, et du protocole de communication utilisé par le ou les services distants nouvellement découverts. Le mécanisme de détection de protocoles de ReMMoC correspond à une implémentation possible du processus Switch de la spécification de C-SUB donnée dans la Figure 15 de la section précédente.

Techniquement, pour découvrir le SDP utilisé dans l’environnement réseau, le

discovery framework doit disposer d’autant de composants logiciels que de

protocoles de découverte de services (SDP) existants. Ainsi, par exemple, pour découvrir si UPnP/SSDP est utilisé dans l’environnement, ReMMoC doit : (i) charger et activer le composant UPnP/SSDP dans le discovery framework, (ii) générer une requête multicast de recherche de service, (iii) attendre une réponse. Si, pendant un certain laps de temps, aucune réponse ne parvient, cela signifie qu’aucun service n’annonce sa présence avec UPnP/SSDP. Pour découvrir l’ensemble des SDP utilisés dans l’environnement ambiant, ReMMoC doit réitérer ce processus en trois phases pour chaque SDP dont il possède le composant. La découverte de SDP est relativement coûteuse en termes de puissance de calcul pour charger/décharger les différents composants, de consommation de bande passante pour générer les différentes requêtes, et en temps d’attente puisqu’il faut attendre les réponses aux requêtes générées pour chaque SDP que l’on souhaite découvrir. Afin d’éviter les chargements/déchargements intempestifs des composants du discovery framework, la dernière version de ReMMoC utilise un composant, appelé discover discovery, qui vient se greffer sur le discovery framework. Ce composant implémente très partiellement les fonctionnalités des différents SDP. Son rôle est de générer les en-têtes des requêtes de recherche de service des différents SDP, et de les envoyer vers leurs adresses multicasts respectives. En retour, dès qu’il reçoit une réponse, il indique au discovery framework le SDP couramment utilisé afin de charger et d’activer le composant adéquat, qui est une implémentation complète du SDP découvert. Cette solution reste toutefois limitée. Elle nécessite toujours de générer un trafic additionnel pour découvrir le ou les SDP de l’environnement et elle n’améliore pas le temps d’attente nécessaire pour découvrir l’ensemble des SDP utilisés. Enfin, l’environnement réseau étant potentiellement dynamique, le ou les SDP courants peuvent changer rapidement, ce qui n’évite pas les reconfigurations successives des composants du discovery framework.

Enfin, ReMMoC détermine le protocole de communication des services distants grâce aux informations obtenues lors de leurs découvertes. Si le service recherché par une application cliente est présent dans l’environnement ambiant, celle-ci obtient, via le SDP adéquat, la description du service. A partir de cette description, ReMMoC détermine le protocole de communication en extrayant soit l’URI (Universal

Resource Identifiers) du service, soit les attributs du service. Une URI est un schéma

standardisé d’identification qui permet à la fois de localiser et de déterminer le protocole de communication du service. Cependant, étant donnée l’hétérogénéité des SDPs, l’URI n’est pas toujours la méthode utilisée pour identifier les services. Quant

aux attributs extraits de la description d’un service, il n’est pas garanti qu’ils indiquent toujours le protocole de communication de ce dernier. La détection du protocole de communication peut donc échouer.

Par ailleurs, comme modélisé par le connecteur C-SUB, et confirmé dans [120] et [119], l’utilisation d’un intergiciel dynamiquement reconfigurable n’est pas transparente pour le développeur d’applications, il doit explicitement programmer ses applications pour qu’elles prennent en charge chaque changement dynamique. Pour rappel, cette contrainte est modélisée par le fait que le port P1 d’un composant utilisant le connecteur C-SUB doit être conçu de façon à ce qu’il soit équivalent au rôle R1 de ce dernier, qui est sujet à des mutations (commutation dynamique de rôle). Par exemple, plus concrètement, si un service distant découvert est de type SOAP, l’application doit effectuer une invocation SOAP, tandis que si le service distant est de type RMI, il doit effectuer une invocation RMI. Afin de simplifier la tâche des développeurs, ReMMoC fournit une interface de programmation (API) unifiée qui lui

est spécifique pour le développement de ses applications⁶, comme illustré dans la

Figure 21C. Ainsi, l’API ReMMoC permet de concevoir des applications capables de découvrir et de communiquer avec des services de l’environnement ambiant indépendamment de la configuration du binding et du discovery framework et donc indépendamment des protocoles utilisés.

Figure 21. Structure globale de l’intergiciel ReMMoC

6 Au niveau du modèle, cela revient à remplacer le rôle R1 par (P1 || I) avec I

processus synchronisant les actions unifiées de P1 avec C-SUB.

Binding

Framework _Framework^{Discovery Structure} _{interne de}

l’intergiciel Interface de programmation unifiée Protocoles de communication Protocoles de découverte Applications Applications API ReMMoC Intergiciel ReMMoC Hôte B A C

• OSGi

OSGi est un consortium d’industriels formé en 1999 ayant pour objectif de définir et de promouvoir la spécification d’un intergiciel OSGi permettant le déploiement de services applicatifs, à l’origine, dans des équipements domotiques, et aujourd’hui, dans toutes sortes d’équipements, du PDA à la voiture [117]. L’intergiciel OSGi se superpose au-dessus d’une JVM (Java Virtual Machine) pour former un intergiciel Java composé d’un framework de composants (Figure 22A, B, C). Dans la terminologie OSGi, une application est une composition de briques logicielles appelées bundles, théoriquement similaires aux composants présentés précédemment. Chaque bundle fournit un certain nombre de fonctions (ou opérations) qui peuvent être réutilisées par d’autres bundles. Concrètement, un bundle est une archive de type JAR qui contient :

• Une description abstraite du bundle (manifest file). Cette description décrit ses caractéristiques : ses différentes propriétés, les packages Java qu’il fournit, et/ou les packages Java dont il dépend.

• Le code Java et les ressources associées (librairies externes, images, etc.) permettant d’instancier le bundle.

OSGi fournit différentes fonctions d’administration permettant d’installer, de désinstaller, d’activer, de désactiver et/ou de mettre à jour les différents bundles de son framework. Ces fonctions d’administration peuvent être utilisées : (i) directement par les bundles grâce à l’API OSGi (Figure 22G) ou (ii) par l’utilisateur via une console d’administration locale ou distante. Lorsqu’un bundle est installé puis activé, il peut publier ses fonctions ou découvrir des fonctions venant d’autres bundles grâce à un annuaire intégré à l’intergiciel. Si un bundle activé dépend de fonctions venant d’autres bundles non activés, il lui est également possible de les activer s’ils ont été préalablement installés. Par ailleurs, la publication, la découverte de fonctions et la composition de bundles ne peut se faire qu’entre bundles d’un même intergiciel : OSGi n’est pas un système distribué mais centralisé (Figure 22B, C). Toutefois, il est possible d’enrichir à la volée l’intergiciel OSGi en téléchargeant de nouveaux

bundles à partir d’une URL (Figure 22E).

Au niveau de l’implémentation, comparativement à un intergiciel réflexif, OSGi est un intergiciel reconfigurable non dynamique [128] : la gestion du cycle de vie des

bundles du framework est laissée à la charge du développeur des bundles et des

applications. Chaque application doit gérer elle-même, l’activation/désactivation, le contrôle et la gestion des dépendances des bundles qu’elle utilise (Figure 22F, G). Le projet Gravity [119] dote l’intergiciel OSGi d’un mécanisme, dénommé

ServiceBinder, automatisant la gestion du cycle de vie des bundles, proche de celui

employé dans les intergiciels réflexifs. Le ServiceBinder analyse automatiquement les dépendances des bundles utilisés afin de : (i) activer/désactiver en conséquence

les bundles dont ils dépendent, (ii) enregistrer/désenregistrer les fonctions qu’ils fournissent auprès de l’annuaire du framework.

Figure 22. Architecture de l’intergiciel OSGi

En ce qui concerne les protocoles de communication et de découverte de services pris en charge par OSGi, cela dépend des bundles installés. Par ailleurs, OSGI n’intègre pas, par défaut, un mécanisme permettant de détecter les protocoles en cours d’utilisation dans l’environnement ubiquitaire afin d’activer en conséquence les

bundles adéquats. L’implémentation de cette fonctionnalité est laissée à la charge du

développeur de l’application.

Le projet européen Amigo [127], dont l’objectif est de promouvoir la spécification d’un intergiciel adapté aux objets communicants d’un environnement ubiquitaire, propose, entre autres, une extension de OSGi, qui couplée au serviceBinder, permet l’intégration de la détection de protocoles et de la sélection de bundle au niveau de l’intergiciel plutôt qu’au niveau applicatif. L’objectif de cette extension est de concevoir des applications, pour des objets communicants équipés d’OSGi, qui profitent automatiquement des capacités de l’intergiciel à opérer une substitution de

protocoles suivant son contexte d’exécution. Ainsi, contrairement à la Figure 22D, où

les applications font référence explicitement aux bundles correspondants aux différents protocoles pris en charge, les applications doivent être liées à deux bundles génériques :

• Un bundle dédié à la découverte de service. Ce dernier fournit une interface générique de découverte de service. Ce bundle gère, en interne, de l’activation/désactivation automatique d’autres bundles

Hôte Téléchargement de nouveaux bundles à partir d’un serveur Web Bundle JVM