Détermination des similarités entre divers SDPs

Un SDP fonctionne suivant un mode centralisé, un mode distribué, ou un mode mixte [51] selon que la découverte de services dans une architecture de services

ubiquitaires est centralisée, distribuée, ou mixte (centralisée et distribuée). Comme

introduit dans le chapitre 2, lorsque la découverte de services est centralisée, la découverte se fait par l’intermédiaire d’un annuaire via un protocole de communication en mode point-à-point. En revanche, lorsqu’elle est décentralisée, la découverte se fait directement entre les clients et les services à l’aide d’un protocole

multicast basé sur le principe des groupes de diffusion afin de réaliser la découverte

et la localisation de services suivant un modèle qui peut être actif, passif ou mixte (actif et passif). Avec un modèle actif, les clients diffusent périodiquement des requêtes multicast afin de découvrir les services distants. Ces derniers, quant à eux, attendent passivement la réception de ces requêtes et répondent aux clients qui les sollicitent par un message unicast annonçant leur présence/localisation. En revanche, avec un modèle passif, les clients se mettent en attente passive d’annonces multicast en provenance des services. Ces derniers doivent périodiquement diffuser des notifications indiquant leur présence/localisation dans l’environnement.

Le protocole SLP [50], implémente les modes de fonctionnement centralisé et

distribué [181]. Dans le mode décentralisé, la découverte se fait selon le modèle mixte, les requêtes des clients (resp. les annonces des services) sont diffusées dans le

groupe multicast identifié par l’adresse IP de classe D [156] suivante 239.255.255.253 :427, tandis que dans le mode centralisé, les clients et les services interagissent avec l’annuaire selon une communication point-à-point au dessus de TCP ou d’UDP. Le protocole UPnP/SSDP [157] fonctionne uniquement avec le mode

décentralisé. En revanche, il implémente les deux modèles de découverte actif et passif : les services annoncent leur présence et les clients diffusent leurs requêtes de

recherche dans le groupe multicast 239.255.255.250:1900. Le SDP de ZeroConf [161], [162] a un comportement similaire à celui d’UPnP, et utilise le groupe

exclusivement le mode centralisé, et la découverte de services se fait à l’aide d’un protocole de communication de type RPC comme RMI. Toutefois, Jini offre à ses clients et services l’opportunité de découvrir dynamiquement l’annuaire, (et uniquement ce dernier) via un SDP qui lui est dédié à l’aide du groupe multicast 224.0.1.85:4160. Un annuaire, comme UDDI [23], peut également être considéré comme un SDP, comparable à Jini, dont la découverte de services est centralisée et dont le protocole est de type RPC (par exemple, SOAP pour UDDI). Cependant, contrairement à Jini, les clients et les services doivent être préconfigurés afin de connaître à l’avance la localisation de l’annuaire. Enfin, le protocole JESA [159], dont l’objectif est de fournir des fonctionnalités similaires à celle de Jini indépendamment de la présence d’un annuaire, est quant à lui opérationnel aussi bien en mode centralisé, qu’en mode décentralisé selon un modèle mixte.

Les différents modes de fonctionnement, centralisé, décentralisé actif, décentralisé

passif, ou décentralisé mixte (c'est-à-dire mode décentralisé selon respectivement le modèle actif, passif, ou mixte), implémentés par un SDP conditionnent les différents

types de requêtes/réponses que ce dernier est susceptible de générer. A partir des travaux réalisés par les auteurs des références [178], [179], [180], [181] on déduit la classification suivante :

• Avec le mode centralisé, les SDPs requièrent l’utilisation de requêtes/réponses permettant l’enregistrement et la découverte de services auprès d’un annuaire suivant un protocole point-à-point.

• Avec le mode décentralisé actif, les SDPs définissent les requêtes/réponses permettant aux clients de découvrir des services distants suivant un protocole multicast.

• Avec le mode décentralisé passif, les services distants diffusent deux types d’annonces : celles émises pour notifier leur présence, et celles émises pour indiquer leur intention de disparaître.

Un autre aspect important de la découverte de services est le format/contenu des requêtes/réponses échangées. En effet, dans le mode centralisé et décentralisé actif, pour qu’un client découvre un service distant, il lui faut générer une requête contenant une description partielle ou complète de l’interface du service recherché qui soit compatible avec celle des services distants déployés dans l’environnement

ubiquitaire. Dans le mode décentralisé passif, la description de l’interface du service

incluse dans les annonces des services doit être compatible à celle qu’attendent leurs clients potentiels.

Avec le protocole SLP, la description des services se fait en employant des modèles de service (service templates) [158] standardisés par l’IETF (Internet Engineering

Task Force) et publiés par l’IANA (Internet Assigned Number Authority). Les

d’attributs d’un service. Un attribut est un couple (clé, valeur), la clé étant le type de l’attribut, et la valeur pouvant prendre la forme d’un entier, d’une chaîne de caractères, d’un Booléen, ou de données binaires. Lorsqu’un service SLP s’enregistre auprès d’un annuaire, il intègre dans sa requête son URL et sa description en attribuant, suivant ses caractéristiques, des valeurs aux attributs du modèle lui correspondant. Quant aux clients SLP, ils découvrent la présence/localisation des services distants en intégrant dans leurs requêtes des prédicats sur les valeurs d’un certain nombre d’attributs correspondant aux modèles des services qu’ils recherchent. L’enregistrement et la découverte de services Jini (resp. UDDI) fonctionnent de façon analogue à SLP ; cependant, la description des services est réalisée par le biais d’interface Java compilée (resp. de documents WSDL).

Avec le protocole UPnP/SSDP, qui fonctionne sans annuaire, les services s’annoncent en intégrant dans leurs messages : (i) une URI (Universal Resource

Identifier) afin de s’identifier de façon unique et (ii) une URL non pas du service

mais d’un document XML contenant la description complète du service. Si le service qui s’annonce correspond à celui que le client recherche, ce dernier doit rapatrier la description complète du service afin d’obtenir entre autres, l’URL et les attributs du service distant. Comme pour SLP, les clients UPnP recherchent des services distants en intégrant dans leur requête des prédicats sur leur URI.

Le SDP de ZeroConf réutilise les messages définis dans le protocole DNS pour annoncer et rechercher des services. En effet, ce SDP est une adaptation du protocole DNS (Domain Name System) afin de découvrir la présence de services distants via un protocole multicast plutôt qu’unicast afin d’éviter l’utilisation d’un serveur DNS. Ainsi, les services s’annoncent via des messages DNS incluant le nom, le type, le protocole d’accès, la description et l’adresse IP du service. Les clients découvrent, comme précédemment, les services en intégrant dans leur requête des prédicats sur leur description.

Un point essentiel qu’il est nécessaire d’évoquer ici est la notion de compatibilité entre les descriptions des services recherchés ou annoncés inclus dans les messages des différents SDPs. En effet, nous distinguons deux types de compatibilité : la

compatibilité syntaxique et la compatibilité sémantique. La description d’interfaces

de services selon des langages de description différents sont compatibles syntaxiquement s’il est possible de résoudre l’hétérogénéité de leur format, cependant cela n’implique pas nécessairement leur comptabilité sémantique. En effet, deux descriptions de services distincts, syntaxiquement équivalentes, peuvent avoir une signification différente. Dans ce document, nous considérons que les interfaces des services d’une architecture de services ubiquitaires sont standardisées bien qu’elles puissent être décrites par des langages de description différents. En d’autres termes, nous considérons que la compatibilité syntaxique implique systématiquement la

dernière¹⁰. En effet, l’interprétation sémantique de la description d’un service se réalise au niveau applicatif plutôt qu’au niveau de l’intergiciel [175], et nous nous intéressons exclusivement à l’hétérogénéité des intergiciels et non pas de celle des applications. Le travail des auteurs des références [173], [177], [182] sur la

compatibilité sémantique des services d’un environnement ubiquitaire est

complémentaire à nos travaux [175] et s’intègre parfaitement au système de traduction SysTDyP comme présenté dans section 5.3.

Par ailleurs, les incompatibilités entre des SDPs fonctionnant selon le mode

centralisé, relèvent davantage des problèmes d’incompatibilités entre protocoles de

communication étant donné que leurs protocoles de découverte utilisés pour interagir avec un annuaire est de type RPC (à l’exception des annuaires SLP). Par conséquent, les incompatibilités entre SDPs fonctionnant selon le mode centralisé sont résolues à l’aide de NEMESYS présenté dans la section 5.2, qui considère un annuaire comme un service quelconque accédé via un protocole de communication, plutôt qu’à l’aide d’INDISS qui se retrouve spécialisé pour les SDPs fonctionnant selon le mode

décentralisé, c'est-à-dire pour les SDPs multicast.

Enfin, les SDPs fonctionnant selon le mode décentralisé passif opèrent en général également selon un mode décentralisé actif [178], [181]. Par conséquent, quel que soient leurs modèles, les SDPs partagent dans le pire des cas seulement deux types de messages en commun, c'est-à-dire les requêtes de découverte de services et leurs réponses associées. Dans le meilleur des cas, les SDPs partagent, en plus de ces messages, ceux correspondants aux annonces générées par les services distants pour notifier leur présence ou leur disparition. Bien que le format de ces messages diffère suivant les différents SDPs, la description des services recherchés ou annoncés, qu’ils véhiculent, contient toujours le nom, le type, l’URL et les attributs d’un service. En ce qui concerne le comportement des différents SDPs, il reste relativement simple et correspond soit à un paradigme d’interaction de type requête/réponse asynchrone, soit à un paradigme d’interaction de type diffusion.

Les différentes similitudes entre les SDPs fonctionnant selon le mode décentralisé étant dorénavant établies, nous sommes en mesure, dans la section suivante, d’utiliser le connecteur C-UNIV-Réseau pour résoudre leur incompatibilité et en particulier de raffiner l’architecture logicielle du système SysTDyP.