ETUDE COMPARATIVE DES SERVICES DE RECHERCHE SUR PROPRIETES

Transcription

1 ETUDE COMPARATIVE DES SERVICES DE RECHERCHE SUR PROPRIETES Dhouha Ayed, Chantal Taconet et Guy Bernard GET / INT, CNRS Samovar 9 rue Charles Fourier, Évry, France {Dhouha.Ayed, Chantal.Taconet, Guy.Bernard}@int-evry.fr France RESUME Avec l évolution des systèmes répartis et des services réseaux, un simple service de nommage permettant d accéder à un service à partir de son nom s avère insuffisant. Les utilisateurs ont besoin d outils plus intelligents leur permettant de rechercher des services à partir de leurs propriétés. L OMG, Sun Microsystems, Salutation et Ariba n ont pas manqué de répondre à ce besoin et ont défini chacun leur propre service de recherche. Le but de cet article est d étudier et évaluer les services de recherche proposés par chacune de ces organisations. MOTS CLES Systèmes répartis, recherche sur propriétés, trading. 1. INTRODUCTION Le progrès de l informatique mobile et l évolution de la technologie des terminaux tels que les PC portables, les PDAs et les téléphones mobiles offrent aux utilisateurs une large accessibilité aux différents services offerts sur un réseau. Les téléphones mobiles et les PDAs modernes sont capables de former dynamiquement des réseaux Ad- Hoc avec d autres machines accessibles grâce aux interfaces réseau avec lesquels ils sont équipés tels que IrDA, Bluetooth et GSM/GPRS. De cette manière, un utilisateur entrant dans un bâtiment particulier, doit être capable d interagir avec les services offert au niveau du réseau de ce bâtiment. Généralement, pour accéder à un service offert sur un réseau, l utilisateur commence par le chercher à partir d un nom symbolique ; c est le type de recherche utilisé dans des pages blanches où il faut connaître le nom de la personne recherchée pour trouver son numéro de téléphone. Ce genre de recherche ne répond qu aux besoins des utilisateurs connaissant à l avance les services offerts sur le réseau. Mais comme dans le cas que nous venons de citer, les utilisateurs mobiles ne connaissent pas les services offerts par le réseau du bâtiment auquel ils se connectent dynamiquement, ils ont besoin d un mécanisme de recherche plus dynamique que celui des pages blanches pour localiser les objets et les services dont ils ont besoin. Ce mécanisme doit permettre de localiser des objets à partir de leurs propriétés sans connaître leur nom ; c est le rôle rempli par un service de recherche sur propriétés. Un service de recherche sur propriétés ne stocke pas les noms des objets mais une description détaillée des objets. Les utilisateurs peuvent alors bénéficier d une recherche dynamique des services basée sur des requêtes contenant des descriptions de l objet demandé. Ce type de recherche peut être comparé à des pages jaunes ; au lieu de lister les services par leur nom, les pages jaunes catégorisent les entrées par sujet et décrivent chaque entrée. Dans cet article, nous ferons une étude comparative de quatre services de recherche sur propriétés : le service de recherche de Corba [1], le service de recherche de Jini [2], le service de recherche de Salutation[3] et le service de recherche de UDDI [4]. Cette étude est faite dans le but d éclaircir le principe de fonctionnement de chacun de ces services et exhiber leurs points forts et leurs points faibles. La section 2 présente quelques concepts de la recherche sur propriétés. Dans la section 3, nous étudions les fonctionnalités de chaque service de recherche cité ci-dessus et dans la section 4 nous faisons une comparaison entre les quatre services de recherche avant de conclure dans la section CONCEPTS ET TERMINOLOGIE Le service de recherche sur propriétés appelé aussi trader, service de vente ou service de médiation est un service qui facilite la publication et la découverte des services sur un réseau. Le principe de fonctionnement d un service de recherche se résume comme suit : une application serveur va enregistrer les services qu elle offre au niveau du trader en fournissant une description de ses services : c est une opération d exportation. Les applications clientes désirant utiliser ces services interrogeront le trader en fournissant des critères de sélection : c est une opération d importation. Les services enregistrés au niveau du trader s appellent des offres de service.

2 3. ETUDE DETAILLEE DES SERVICES DE RECHERCHE SUR PROPRIETES 3.1. Service de recherche CORBA L OMG a défini le service de recherche sur propriétés suite au besoin des objets distribués CORBA[5] d utiliser des pages jaunes [1]. Les offres de service au niveau d un service de recherche CORBA sont décrits d une manière abstraite à l aide d une structure appelée type de service. Un type de service représente les types d informations qu un importateur peut utiliser pour rechercher un service au niveau du trader. Il définit donc les propriétés utilisées pour décrire une offre de service. Toute importation ou exportation de service se fait par rapport à un type de service donné. Les types de service sont composés de quatre éléments: un nom unique identifiant le type de service, des super types hérités permettant de définir une classification des types par héritage multiple, une interface IDL (Interface Definition Language) à laquelle les services exportés doivent se conformer et un ensemble de types de propriétés définissant l aspect comportemental du service. Le service de recherche de CORBA offre une API permettant d exporter et d importer des services, de modifier des propriétés d un service enregistré et de configurer et administrer le service de recherche. Exporter un service revient à enregistrer au niveau du service de recherche le nom du type de service à exporter, une référence à l interface qui offre le service et des valeurs pour les propriétés du service. Une importation de service consiste à envoyer une requête vers le trader contenant. 1. Le nom du type de service recherché. Exemple : Impression. 2. Des contraintes sur le service recherché. Ces contraintes détermineront les imprimantes particulières recherchées part l utilisateur. Il peut par exemple chercher une imprimante couleur qui imprime recto-verso. 3. Des préférences définissant un ordre dans lequel seront retournés les résultats. Par exemple, afficher les imprimantes rapides en premier. 4. Des politiques contrôlant des aspects non fonctionnels de recherche tels que le nombre d offres retournées et s il s agit de retourner la description d un objet ou seulement la référence sur l objet. Le résultat de recherche d un objet avec le trader Corba est un IOR (référence Corba sur cet objet) permettant à l application d utiliser l objet à travers le bus CORBA [5]. Les contraintes et les préférences sont exprimées à l aide d un langage de contraintes appelé OCL (OMG Constraint Language). Elles sont construites à partir de noms de propriétés, d un type de service, des valeurs prises par ces propriétés et des opérateurs logiques, mathématiques et de comparaison. Le trader CORBA permet la fédération de la recherche en permettant l accès à un grand nombre d offres de services sans avoir besoin d enregistrer toutes les offres sur un seul trader. Cette fédération est transparente aux utilisateurs. Une des particularités du trader Corba est la possibilité d utilisation des propriétés dynamiques. Contrairement à des propriétés statiques qui ont une valeur fixe enregistrée par l exportateur, les valeurs des propriétés dynamiques sont évaluées à la demande, lors d une recherche, à travers un objet d évaluation de propriétés dynamiques désigné par l exportateur. Par exemple pour la recherche d actions dans la bourse, le prix d une action subit des fluctuations rapides. L utilisation de propriétés statiques n est pas adéquat à ce genre de services, il faut donc utiliser des propriétés dynamiques Service de recherche de Jini Jini [6] est un système distribué, défini par Sun Microsystems, qui étend l environnement d une application java d une seule machine virtuelle vers un réseau de machines locales. Jini offre plusieurs services mais nous ne nous sommes intéressés qu au trader (lookup service) [2]. Le service de recherche maintient une collection plate d enregistrements décrivant des services. Le trader Jini offre une interface permettant d exporter, d importer des services, de modifier certaines propriétés d un service enregistré et d administrer le service de recherche. La figure 1 illustre le fonctionnement de la recherche de services dans le système Jini. Un exportateur ou un importateur dans Jini commence par découvrir un service de recherche auprès duquel il exportera ou importera des services. Ceci est réalisé à travers un multicast (étape 1 de la figure 1) et une écoute de réponses à travers le réseau local (étape 2 de la figure 1). Tous les services de recherche de proximité fournissent une réponse à ces entités appelantes sous forme d objet de recherche (étape 3 de

3 la figure 1). Si on veut que l invocation des services de recherche se fasse à distance, au lieu de l objet proxy, un stub RMI sera placé au niveau de l exportateur ou l importateur. Salutation a été conçu pour résoudre les problèmes de découverte de services et leur utilisation dans un environnement étendu de connectivité et de mobilité. L architecture de Salutation est conçue de manière à ce qu il soit indépendant du processeur, du système d exploitation et des protocoles de communication [3]. L architecture de Salutation est construite autour d une entité Middleware appelée Salutation Manager qui joue le rôle d un courtier pour les différentes applications. Chaque entité sur le réseau doit être reliée au maximum à un Salutation Manager qui peut être placé localement sur l entité elle même ou sur une entité distante (dans ce cas Salutation Manager est invoqué à distance à travers du RPC). FIG. 1 Connexion, exportation et importation de services au niveau du service de recherche Jini. Une fois qu un exportateur a identifié le service de recherche de proximité, il peut y enregistrer son service avec l opération register en fournissant une copie de l interface du service qu il offre et un ensemble d attributs décrivant le service (étape 4 de la figure 1). Cette étape copie l objet de service qui représente une interface du service et les attributs au niveau du service de recherche. Les attributs d un service sont représentés comme un tableau d ensemble d attributs. Un ensemble d attribut est représenté comme une instance d une classe Java où chaque attribut est un champ public de cette classe ce qui permet un typage fort des attributs. De la même manière, une fois qu un importateur a identifié un service de recherche de proximité, il peut faire des recherches de services en passant à l opération lookup un type (l interface) du service recherché et un ensemble de valeurs d attributs (étape 5 de la figure 1). Une correspondance peut être faite en se basant sur le type de service ainsi que les attributs attachés au service. Le service de recherche enverra un ensemble de résultats parmi lesquels l importateur fait un choix (étapes 6 et 7 de la figure 1). Une fois que le choix de l utilisateur s est fixé sur un service, le service de recherche copiera l objet de service (une interface pour utiliser le service) au niveau de l importateur (étape 9 de la figure 1), ce qui lui permettra une communication directe avec le service demandé (étape 10 de la figure 1). D une manière générale le trader Jini est très utilisé dans la recherche de services de proximité. Il est basé sur Java-RMI, ce qui lui permet de fonctionner dans un environnement portable Service de recherche de Salutation Salutation Manager communique avec d autres Salutation Managers pour assurer son rôle de courtier en utilisant un protocole de communication qui lui est propre. Ce protocole utilise le RPC version 2 de Sun Microsystems. Salutation Manager offre deux interfaces indépendantes des couches basses du réseau : une API permettant l importation et l exportation de services et l utilisation directe des services offerts sur le réseau et une interface maintenant une séparation avec les couches basses du réseau appelée Salutation Manager Transport Interface utilisée par les entités dépendantes des couches réseau appelées Transport Managers. Un Salutation Manager fonctionne avec un ou plusieurs Transport Managers. Chaque Transport Manager découvre d autres Salutation Managers distants connectés aux réseaux qu il supporte à l aide d un broadcast. Les fonctionnalités offertes par un service sont représentées au niveau de salutation d une manière abstraite à l aide de ce qu on appelle une unité fonctionnelle (FUDR). Par exemple, l impression des documents peut définir une unité fonctionnelle qu on note [print]. A chaque unité fonctionnelle est associé un ensemble d attributs. Par exemple, l unité fonctionnelle [print] a comme attributs la taille du papier pouvant être utilisé, la densité des pixels et l impression en couleur. Une entité qui a plusieurs fonctions sur le réseau comme l impression, le fax et le scannage, a une multitude d unités fonctionnelles. L ensemble de ces unités fonctionnelles forme un service qui est décrit par un enregistrement de description de service (SDR). Les enregistrements de description d unités fonctionnelles

4 sont eux même composés d enregistrements contenant les valeurs d attributs décrivant les unités fonctionnelles. Pour importer un service, une application cliente construit un ou plusieurs enregistrements de description d unités fonctionnelles englobants les différentes fonctionnalités dont elle a besoin et l envoie au Salutation Manager à qui elle est reliée. Ce dernier fait des recherches locales et distantes en envoyant l enregistrement de description de service reçu vers d autres Salutations Managers. Cette recherche consiste en une comparaison entre le FUDR envoyé et celui enregistré dans le Salutation Manager. S il s agit du même type de FUDR, il comparera les types et les valeurs des attributs. Si la comparaison aboutit à un résultat positif, le Salutation Manager construit un nouveau FUDR représentant l union entre le FUDR envoyé et celui enregistré (une opération OU est exécutée) et le renvoie à l application cliente comme résultat. Si la comparaison échoue, un FUDR vide est retourné à l application cliente. Salutation se distingue par le fait qu il assure lui même le courtage entre les applications grâce à un protocole de communication qui lui est propre. Mais ce service de recherche est, comme Jini, limité à la recherche de services de proximité Service de recherche de UDDI UDDI (Universal Description, Discovery & Integration) [4] est un projet industriel qui a été lancé par Ariba, IBM et Microsoft. C est un service de recherche utilisé essenciellement dans la recherche des services Web. Son but principal est de faciliter l intégration B to B. Les informations qu une entreprise peut enregistrer au niveau de UDDI sont des informations sur son nom, des contacts, des codes industriels, des classifications de produits, des URLs, l ensemble des services offerts ainsi que des informations sur leurs interfaces techniques et leurs fonctionnements. La structure des données de UDDI est basée sur XML et SOAP [7]. Les informations enregistrées au niveau de UDDI, utilisent cinq types de structures de données organisés suivant une relation parent/descendant qui suit le modèle de la figure 2. Les informations sur les entreprises, leurs services et leurs informations techniques sont séparées pour qu ils soient accessibles individuellement. FIG. 2 Structure des données UDDI. La structure businessentity ne contient que des informations descriptives de l entreprise comme le nom et la description de l entreprise, les informations permettant d avoir un contact avec des personnes responsables comme des s et des URLs. En plus de ces informations, une businessentity contient un ensemble de businessservices. Chaque structure businessservice représente une description d un service offert par l entreprise. Elle comporte une référence sur le businessentity auquel elle appartient, un nom, une description d un service ainsi qu une liste de bindingtemplates. Un bindingtemplate représente un point d entrée aux différents services web. Exemple, une URL qui permet d accéder directement au service. Les tmodels sont des sortes de types de services. Ils servent à déterminer les compatibilités entre services et contiennent des références sur des documentations techniques. Deux entreprises liées utilisent des messages de type publisherassertion pour indiquer la relation entre eux. Prenons comme exemple une entreprise qui veut acheter des équipements informatiques à travers le web, elle cherchera, en utilisant UDDI, tous les vendeurs d équipements informatiques qui offrent un service web permettant de passer des commandes d une manière électronique. Pour réaliser un achat, notre entreprise, doit déterminer lequel de ces vendeurs d équipements informatiques offre des services web compatibles à ses systèmes. Par exemple, si elle supporte des commandes électroniques se basant sur SOAP, elle aura besoin d un vendeur qui accepte des commandes de ce type. Pour satisfaire ce genre de besoin, chaque entreprise enregistre au niveau de UDDI, en plus des informations générales sur les services qu elle offre, des informations de compatibilités entre services dans des tmodels. UDDI offre un ensemble d APIs sous forme de services web basés sur le protocole SOAP qui permettent l exportation et l importation de services.

5 Enfin, nous pouvons dire que la particularité de UDDI par rapport aux autres pages jaunes du Web telles que celles de Yahoo, Lycos ou Mamma réside dans sa capacité à faciliter le B to B. 4. ETUDE COMPARATIVE DES SERVICES DE RECHERCHE SUR PROPRIETES Le tableau 1 présente une comparaison entre les quatre services de recherche : trader CORBA, Lookup Service Jini, Salutation et UDDI. Chacun des quatre services de recherche que nous avons étudié offre une API servant essentiellement à exporter et importer les services et gérer les services enregistrés dans un dépositaire. Le service de recherche Corba semble offrir des fonctionnalités assez complètes ; la sélection d offres de service se fait par une réduction de l ensemble d offres des différents traders par des politiques de recherche. Cet espace d offres est alors filtré par le type de service demandé et une expression de contraintes. Les offres sélectionnées par le filtre sont ensuite ordonnées par une expression de préférences (voir figure 3). Cette capacité de filtrage est assurée grâce à un langage de définition de contraintes et de préférences (OCL) qui lui permet d appliquer des opérations logiques et mathématiques entre valeurs et noms de propriétés. Ce langage de contraintes constitue un atout pour le service de recherche de Corba par rapport aux autres services qui se suffisent de faire des tests d égalités entre valeurs ou noms de propriétés de services offerts et recherchés. environnement CORBA. TORBA [8] présente une solution à la complexité de l API de CORBA [5]. L utilisation du service de recherche Corba n est pas très adaptée à des des réseaux Ad-hoc puisque pour l utiliser il faut connaître sa référence au préalable. Cette référence est généralement placée dans un fichier de configuration accessible par l application exportatrice ou importatrice. Les services de recherche Jini et Salutation semblent plus adaptées aux réseaux Ad-hoc puisqu ils permettent la découverte dynamique d un service de recherche par l utilisation de multicast. Les services de recherche Jini et Corba offrent un typage fort des services. Dans Corba les services sont conformes à ce qu on appelle des types de services et dans Jini les services ont la structure d une classe. Le typage fort facilite la programmation avec les APIs du service de recherche ; il permet la détection d erreurs de typage dès l étape de la compilation et donc évite les erreurs à l exécution. Le trader Corba et Salutation se distinguent par leur fédération des serveurs pour la recherche. Mais, la fédération de recherche du trader Corba peut s appliquer dans un réseau plus étendu et se base sur des graphes orientés de recherche. TAB. 1 Comparaison des services de recherche FIG. 3 Filtrage des offres par le trader Corba L inconvénient majeur du service de recherche Corba est qu il présente une API difficile à implémenter ; une recherche faisant appel à la méthode query de l interface lookup nécessite une centaine de lignes de code. En plus, il ne peut être utilisé que dans un Jini permet de faire le pontage avec des services de recherche d autres types comme Salutation ou autres. Par contre, Il est impossible de rechercher un service qui a été enregistré sur un site opérateur différent de celui au niveau duquel on fait la recherche.

6 Tous les services de recherche que nous venons d étudier supportent des propriétés de types simples et composés à l exception de UDDI où toutes les propriétés sont au format texte. Le trader CORBA et Jini lookup permettent de modifier des valeurs de propriétés de services déjà enregistrés. Le trader CORBA est le seul qui supporte les propriétés dynamiques. Les APIs de Jini ne peuvent être implémentés qu en Java, le trader CORBA se limite aux objets CORBA mais peut être implémenté avec plusieurs langages supportés par CORBA. L API de Salutation peut être implémentée avec n importe quel langage. Salutation ne fonctionne pas au dessus d un Middleware comme RMI ou CORBA, c est lui même qui assure le courtage entre les différentes applications. Lors d une importation d un service, il ne renvoie pas une référence ou une interface d un service à l importateur, mais il assure lui même l utilisation directe du service recherché à l aide d un protocole qui lui est propre basé sur du RPC. Un des avantages pratiques de Salutation c est qu il offre une interface qui assure l indépendance du transport. UDDI sert essentiellement à rechercher des services web. Sa particularité réside dans sa capacité d offrir des informations sur l interopérabilité et la compatibilité entre les différents services. 5. CONCLUSION ET PERSPECTIVES Les services de recherche sur propriétés sont comparables aux pages jaunes, ils permettent une recherche des différents services sur le réseau à partir de leurs propriétés. Nous avons étudié, dans cet article, quatre services de recherche sur propriétés. application de manière à ce qu elle s adapte le mieux à l environnement d exécution de l application. Nous avons choisi d utiliser le trader CORBA parce que nous nous plaçons dans un environnement CORBA CCM (CORBA Component Model[9]). De nos jours, la recherche sur propriétés est de plus en plus utilisée pour l adaptation des services au contexte de l utilisateur. Parfois lorsqu un utilisateur est entrain d utiliser un service et que son contexte change (changement de zone géographique, coupure de réseau, etc.), le service qu il utilise peut ne plus répondre à ses besoins. Dans ce cas, il y a une détection automatique de ce changement et une recherche dynamique d un nouveau service qui répond à ses nouveaux besoins. 6. REFERENCES [1] Trading Object Service Specification, OMG documents formal/ , Mai [2] Jini Lookup Service, Sun Microsystems, Décembre [3] Salutation Architecture Specification, the salutation consortium, http :// Juin [4] UDDI Version 2.0 API Specification, UDDI Open Draft Specification [5] CORBA Specification, OMG documents formal/ , Juin [6] Jini Architecture Specification, Sun Microsystems, Décembre [7] Simple Object Access Protocol (SOAP) 1.1. W3C Note, http :// 08 May [8] R. Marvie, P. Merle, J.M. Geib, & S. Leblanc, "TORBA : Trading Contracts for CORBA", in COOTS'01. 6th USENIX Conf. on Object-Oriented Technologies and Systems, San Antonio, Texas, [9] Object Management Group, Corba Component Model Specifications, Juillet Chacun de ces services présente des avantages et des inconvénients. Le trader Corba semble le plus complet, mais il n est utilisable que sur un bus CORBA. Jini et Salutation servent à découvrir des services de proximité dans des réseaux Ad-hoc et UDDI permet la recherche des services Web. Aujourd hui, les applications sont construites à partir de composants autonomes et coopératifs pouvant être placés sur des machines multiples. Notre travail de recherche consiste à trouver des solution pour le déploiement de ce genre d applications multicomposants. Nous utilisons la recherche sur propriétés pour trouver les différents composants d une