Découverte de Services Web Sémantiques : une Approche basée sur le Contexte M. CHELBABI

Transcription

1 Découverte de Services Web Sémantiques : une Approche basée sur le Contexte M. CHELBABI 18 novembre 2006

2 Table des matières 1 Le Web Sémantique Introduction Les Ontologies Structure du Web sémantique URI (Uniform Resource Identifier) XML (extensible Markup Language) Schéma XML (XMLS) RDF (Resource Description Framework) Schéma RDF (RDFS) OWL (Ontology Web Langage) Conclusion Les Services Web Introduction Caractéristiques des services Web Standards des services Web SOAP (Simple Object Access Protocol) WSDL (Web Service Description Language) UDDI (Universal Description Discovery and Integration) BPEL4WS (Business Process Execution Language for Web Services) Conclusion Les Services Web Sémantiques Introduction Approches proposées pour la réalisation des services Web sémantiques WSDL-S (Web Service Description Language-Semantic) OWL-S (Ontology Web Language for Services) IRS-II (Internet Reasoning Service) WSMF (Web Service Modeling Framework) Conclusion

3 4 Les Mécanismes de découverte de services Web Introduction Approches basées sur la représentation syntaxique Architecture centralisée Architecture distribuée Approches Web sémantique Architecture centralisée Architecture distribuée Approches basées sur les Logiques de description Découverte basée sur le Contexte Modèles de représentation du contexte Approches de découverte basées sur le contexte Synthèse des approches de découverte Conclusion Vers une approche de découverte basée sur le contexte Introduction Ontologies de description des informations du contexte Ontologie du Contexte de l utilisateur proposée Contexte d un service Web Ontologie de Qualités de Service (QoS) Ontologie de dispositif Conclusion L architecture de découverte basée sur le contexte Introduction Architecture de découverte proposée Les agents et leurs rôles Communication entre Agents Protocole d enregistrement des descriptions sémantiques des services Web Découverte de services Web sématiques basée sur le contexte Etape 1 : Recherche sémantique Etape 2 : Sélection selon le contexte Implémentation Technologies d implémentation Développement des ontologies Développement de la partie publication des services Web Interface de publication Registre UDDI Conclusion Conclusion et perspectives 90 2

4 A Ontologie du contexte de l utilisateur 95 B Ontologie de Qualité de Services (QoS) 97 C Ontologie de type de dispositif 99 D Extensions apportées à OWL-S 101 3

5 Table des figures 1.1 Exemple graphique d une ontologie Structure du Web sémantique Schéma des URIs XML Schema qui décrit la structure et les types de données d un document XML décrivant la ressource "livre" Graphe de trois déclarations RDF Représentation RDF du Triplet Description de la ressource "livre" Organisation hiérarchique des classes RDF Définition d une propriété en RDF Origine du langage OWL Standards des services Web Structure d un message SOAP Traitements successifs de l en-tête d un message SOAP Extrait d une requête SOAP/HTTP Structure d une description WSDL Ressemblance d UDDI avec un annuaire structure de données d UDDI Relation entre UDDI et WSDL Extrait du code BPEL d un service composé Opération WSDL augmentée de sémantique Relations entre OWL-S et WSDL Modéle de connaissance UPML Architecture IRS-II Architecture AASDU Extrait de l algorithme Matchmaking Niveaux de correspondance Ontologie de véhicule Régles d assignation du niveau de correspondance Procédure de classification du résultat de recherche Architecture IRS-II

6 4.8 Découverte sémantique basée P2P Réseau P2P de registres Architecture de UDDI Découverte de services Web par contexte d aprés Keidl Architecture CB-SeC Représentation graphique de l ontologie du contexte de l utilisateur proposée Aperçu du code de l ontologie du contexte de l utilisateur proposée Paramètres fonctionnels du service Web Extensions apportées à la classe ServiceParameter de l ontologie OWL-S Représentation graphique de l ontologie QoS Aperçu du code de l ontologie de QoS Ontologie de description de dispositifs Aperçu du code de l ontologie de dispositif proposée Architecture Orientée Services Architecture multi agents proposée Protocole de publication des descriptions des services Web Protocole de découverte de services Web sémantiques basée contexte Interface de publication des descriptions des service Web

7 Liste des algorithmes 1 : Sélection basée Localisation des services Web sémantiques : Sélection basée QoS des services Web sémantiques

8 Introduction générale Les services Web sont une technologie émergeante. Ce sont des composants softwares qui fournissent des fonctionnalités accessibles via des protocoles standardisés du Web. Basés sur le standard XML, ils sont caractérisés par leur indépendance aux platformes et aux systèmes d exploitations, ce qui a impliqué leur adoption par différentes organisations commerciales et industrielles offrant leurs services à travers le Web, et par conséquent l augmentation du nombre des services Web offerts. Les technologies standards des services Web sont : WSDL (Web Services Description Language)[23], UDDI (Universal Discovery, Description, and Integration)[25] et SOAP (Simple Object Access Protocol)[24]. WSDL est le langage de description des services Web en terme de paramètres, protocoles de communications, etc. UDDI est un répertoire des descriptions des services Web, il est utilisé pour l enregistrement et la recherche des services Web. Enfin, SOAP sert de protocole de transmission entre l utilisateur et le fournisseur du service. La découverte des services Web représente un axe de recherche émergeant. En général, la découverte est faite au niveau du registre UDDI, elle est basée essentiellement sur la recherche syntaxique des descriptions WSDL des services Web. La tendance actuelle de la communauté des chercheurs est d exploiter les technologies du Web sémantique, par exemple RDF (Resource Description Framework)[42], RDFS (Resource Description Framework Schemas)[42], OWL (Ontology Web Langage)[38], afin d enrichir les services Web de descriptions sémantique. La combinaison des technologies des services Web et du Web sémantique a mené au concept des services Web sémantiques. Les services Web sémantique sont des services Web dotés de descriptions sémantiques. Cette sémantique est apportée grâce aux ontologies une des technologies importente du Web sémantique. Ainsi, des agents logiciels peuvent être développés afin de raisonner sur ces ontologies rendant la découverte des services Web dynamique et automatique. La découverte des services Web sémantiques est basée essentiellement sur leurs aspects fonctionnels (Entrées, Sorties, Pré-conditions et Effets). Cependant, vu la diversité des utilisateurs et des conditions dans lesquelles ils accèdent aux services Web, d autres paramètres doivent êtres considérés lors de la découverte, tel que le type du dispositif utilisé (PDA, ordinateur portable, etc.), préférences de l utilisateur, localisation de l utilisateur, etc. Tous ces paramètres forment un contexte d utilisation particulier. 7

9 Dans le cadre de ce travail, nous allons nous intéresser aux problèmes de découverte dynamique des services Web sémantiques. En particulier, nous allons nous focaliser sur la prise en compte des informations qui définissent le contexte de l utilisateur et celui du service Web, et ce dans le but de satisfaire au mieux l utilisateur. Notre contribution consiste en plusieurs points : 1. Actuellement, peu de travaux sur la découverte de Services Web sémantiques prennent en considération le contexte de l utilisateur. Pour pallier à ce manque, nous proposons une ontologie du contexte de l utilisateur. Cette ontologie est un modèle de représentation des diverses informations qui caractérisent l utilisateur ainsi que l environnement dans lequel il évolue. 2. Nous proposons, aussi, deux extensions aux niveaux de l ontologie des services Web OWL-S (Ontologie Web Langage- Semantic)[19] en termes de paramètres qualités de service et paramètres de descrption des dispositifs supportant les données transmises par le service Web. Ces paramètres font référence à deux ontologies ; une ontologie de Qualité de Service (QoS) et une ontologie de dispositif de connexion. L ontologie qualité de service permet de définir le contexte du service Web en termes de paramètres de QoS. L ontologie de dispositif permet de définir les types et caractéristiques des dispositifs que prend en charge le service Web. 3. Enfin, l approche que nous proposons est supportée par une architecture multi agents. Ce document est organisé comme suit : Le premier chapitre est consacré aux technologies du Web sémantique. Le deuxième chapitre est une présentation des technologies de services Web. Le troisième chapitre est une introduction aux concepts de services Web sémantiques. Le quatrième chapitre est une présentation des différentes approches proposées pour la découverte de services Web. Le cinquième et sixième chapitres sont consacrés à notre contribution. Le cinquième chapitre présente les différentes ontologies proposées pour la représentation des informations formant le contexte (contexte de l utilisateur, contexte du service Web). Le sixième chapitre présente notre architecture de découverte de services Web sémantiques basée sur le contexte. 8

10 Chapitre 1 Le Web Sémantique 1.1 Introduction Le Web d aujourd hui est essentiellement syntaxique (environ 3 milliards de documents statiques, consultés par près de 300 millions d utilisateurs à travers le monde), dans le sens où la structure des documents, ou ressources au sens large, est bien définie mais que leur contenu sémantique reste quasi inaccessible aux traitements machines. Tim Berners-Lee, Directeur du Consortium World Wide Web (W3C) 1 a mentionné que le futur du Web sera le Web sémantique. L objectif du Web sémantique est de lever les difficultés rencontrées sur le Web d aujourd hui (recherche d information, services,...), en rendant la grande masse d information disponible, accessible et interprétable par les machines, en plus de l automatisation de certaines fonctionnalités grâce à la représentation sémantique du contenu des documents, des services, des ressources sur le Web au sens large. Une représentation explicite de la sémantique des données, programmes, pages html, services Web et autres ressources du Web, permettra d avoir un Web basé "connaissances", qui fournira à son tour un niveau de service qualitativement meilleur. Pour réaliser cette représentation, les ontologies ont été introduites. Les ontologies représentent la technologie clé pour la réalisation du Web sémantique. 1.2 Les Ontologies Le mot Ontologie vient du mot grec ontos pour être et de logos pour univers. C est un terme philosophique introduit au XIXeme siècle qui caractérise l étude des êtres 1 9

11 dans notre univers. Le mot Ontologie possède différentes significations et demeure assez ambigu. Il y à une quinzaine d années la communauté de la représentation des connaissances transforme ce concept philosophique en un objet ; une ontologie Une ontologie est définie comme : étant une représentation formelle d un domaine de connaissance sous la forme de terminologies dotées de relations sémantiques[18]. L ontologie est utilisée dans différents domaines, par exemple dans : la représentation d informations et de connaissances, l intégration des systèmes d informations, la spécification des systèmes, etc. Mais aussi dans : La communication : Une ontologie ne permet jamais que deux mots différents possèdent la même sémantique. L intéropérabilité : Une ontologie peut être considérée comme un pont ou une passerelle entre différents systèmes. Elle sert à définir le format d échange entre les systèmes [48]. Fig. 1.1 Exemple graphique d une ontologie Dans le cas du Web sémantique, une ontologie permet à l utilisateur, lors d une recherche sur le Web, d accéder non seulement aux documents liés aux mots clés de la requête, mais aussi à ceux qui sont liés ontologiquement (sémantiquement) à ces derniers, ce qui rend la recherche encore plus pertinente. Une ontologie permet de définir quelles primitives sémantiques sont nécessaires pour la représentation des connaissances d un domaine donné. Tous les ontologistes 10

12 s accordent à considérer que les primitives sémantiques de base d une ontologie sont les concepts et les relations entre ces concepts. Une ontologie est souvent représentée en terme de classes, relations, propriétés, attribut et valeurs. La Figure 1.1 est une représentation graphique d une ontologie de description de vehicule. 1.3 Structure du Web sémantique A l état Actuel, le Web sémantique est fondé sur des langages structurés en couches (voir figure 1.2) Fig. 1.2 Structure du Web sémantique URI (Uniform Resource Identifier) Une URI est un identificateur d une ressource mais surtout d un concept, c est une forme d étiquette. Définies par la RFC 2396, les URI(s) constituent une des notions fondamentales du Web sémantique, elles sont composées d URN et d URL (voir figure 1.3) L URL est un identifiant qui permet de repérer de manière unique un objet sur le réseau. Les URLs peuvent être utilisées pour créer des URIs, mais dans le cadre du Web sémantique, l URI n envoie pas nécessairement vers un document, elle est utilisée comme identifiant d un concept dans un fichier RDF, cela bien sûr ne veut pas dire que l URI par elle-même a un sens, c est juste un mot. Le sens est donné de la même façon que dans le langage naturel, c est à dire par le contexte, les définitions ou les références. L URN est une URI qui identifie une ressource indépendamment de son endroit physique. 11

13 Fig. 1.3 Schéma des URIs XML (extensible Markup Language) XML est un standard soutenu par le W3C pour le balisage des documents. C est un ensemble de règles syntaxiques définissant des étiquettes sémantiques pour la création de langages Markup riches sémantiquement [43]. Conçu et optimisé pour la transmission des données via le Web, XML fournit un mécanisme simple mais robuste pour l encodage des informations sur le Web sémantique. Un document XML peut faire référence aux namespaces dont le mécanisme a pour but la création des noms uniques pour les éléments et attributs d un langage Markup. Les Namespaces sont importants pour deux raisons : la première, est qu ils permettent de lever l ambiguïté sur le sens de deux noms identiques dans différents langages Markup. La seconde est qu ils permettent de mixer différents langages markup sans ambiguïté. XML est utilisé pour différents objectifs : Il fournit une syntaxe commune pour les différents langages Markup Il permet la séparation du contenu de la forme pour un document Il est considéré comme étant un format uniforme d échange de données, tel qu un document XML peut être transféré comme étant un objet entre deux applications Schéma XML (XMLS) Schéma XML est un langage de définition à syntaxe XML, il permet de construire des documents XML suivant un vocabulaire et une structure hiérarchique spécifique [42]. Appliqué pour la description des structures de données des documents XML, il 12

14 Fig. 1.4 XML Schema qui décrit la structure et les types de données d un document XML décrivant la ressource "livre" définit d une part, l imbrication des éléments entre eux, et d autre part le type d éléments avec leurs attributs. L exemple de la figure 1.4 (extrait du livre [4]) représente le schéma XML (Livre.xsd) pour la description de la ressource "Livre" dans un document XML (Livre.xml) RDF (Resource Description Framework) Conformément à la recommandation du W3C, RDF est un langage de base pour le traitement des méta-données ; il permet l interopérabilité entre applications pour l échange d information compréhensible par machine sur le Web [46]. RDF permet de 13

15 voir le Web comme un ensemble de ressources reliées par des liens étiquetés "sémantiquement". Il peut être considéré comme étant le premier langage propre au Web sémantique. RDF a une syntaxe XML, mais contrairement à un document XML où on trouve des méta-données ne concernant que certaines parties du document, RDF est utilisé pour la création de méta données décrivant l ensemble du document [42]. Les méta-données en RDF peuvent être imbriquées à l intérieur du document luimême (bloc de commentaire ou à l intérieur d une balise <meta> de l entête d un fichier html) ou peuvent être situées sur une ressource externe (un autre document ou encore une base de donnée). Elles peuvent être aussi distribuées (exemple de RSS - RDF Site Summary) ou centralisées dans un référentiel, par exemple un répertoire UDDI (paragraphe 2.3.3). Une description RDF est basée sur le triplet ressource, propriété, valeur [42], où une ressource est toute entité d information (exemple pages Web, des parties ou des collections de pages Web, application Web, service Web,...) pouvant être référencée par un nom symbolique (littéral) ou un identificateur. L identificateur est obligatoirement une URI. Une propriété est un attribut spécifique, une caractéristique, ou une relation utilisée pour décrire une ressource. Chaque propriété a une signification spécifique, des valeurs autorisées, des types de ressources qu elle peut décrire et des relations avec d autres propriétés. Une ressource associée à une propriété, ayant une valeur correspondante est une expression ou déclaration (statement) RDF. Le triplet ressource, propriété et valeur sont aussi appelées : Objet, Attribut et Valeur) respectivement, généralement dénotés A (O, V). Avec RDF un Objet peut jouer le rôle d une valeur, c est-à-dire l objet d une déclaration (i.e. la valeur de la propriété associée à une ressource) peut être une autre déclaration RDF (réification) ou un littéral, c est à dire une ressource (spécifiée par une URI), ou une chaîne de caractères simple ou encore un autre type de donnée primaire défini par Schéma XML. Le graphe de la figure 1.5 représente trois relations RDF selon le format A (O, V) : Le premier triplet (Triplrt1) dénoté en format A (O, V) a la syntaxe XML suivante (voir figure 1.6) : 14

16 Fig. 1.5 Graphe de trois déclarations RDF <rdf :Description rdf :about= "http :// <hasname rdf :resource ="Jim Lerners"/> </rdf :Description> Fig. 1.6 Représentation RDF du Triplet1 RDF permet aussi d indiquer qu un objet donné est d un type donné, par exemple dans la figure 1.7 l objet ISBN est de rdf :type book tout en faisant référence à la définition de book via RDFS. <rdf :Description rdf :about= "http :// <rdf :type rdf :resource= "http ://description.org/schema/book"/> </rdf :Description> Fig. 1.7 Description de la ressource "livre" Cependant, il est important de noter qu RDF n est qu un modèle de données primaires pour méta-données, la sémantique qu il délivre est décrite de façon informelle. De plus comme en XML, le modèle de données RDF ne fournit aucun mécanisme 15

17 pour la déclaration des noms des propriétés à employer Schéma RDF (RDFS) Schéma RDF est une extension de RDF. Permettant de décrire les ressources dans le contexte du Web sémantique, RDFS ajoute à RDF la possibilité de définir des hiérarchies de classes dont les ressources seront des instances et des propriétés dont l applicabilité et le domaine de valeur peuvent être contraintes à l aide des attributs rdfs : range et rdfs : domaine respectivement. Chaque domaine applicatif peut être associé à un schéma identifié par un préfixe particulier qui correspond à une URI unique. RDFS s écrit toujours à l aide du triplet RDF. RDFS permet aux développeurs de définir un vocabulaire particulier pour des données RDF, telles que hasname de l exemple précédant, et d indiquer les types d objet auxquels ces attributs peuvent être appliqués. En d autres termes, le mécanisme RDFS offre un système de base pour la classification des objets des modèles RDF. Ce système de classification utilise quelques mots réservés prédéfinis, comme par exemple Class, subpropertyof et subclassof. Les objets RDF peuvent être définis comme instances d une ou plusieurs classes en utilisant la propriété type. La propriété subclassof permet au développeur de spécifier l organisation hiérarchique de telles classes (voir figure 1.8) <rdfs :Class rdf :about="book"/> <rdfs :Class rdf :about="hardcover"> <rdfs :subclassof rdf :resource="book"/> <rdfs :Class> <Hardcover rdf :resource= "http :// Fig. 1.8 Organisation hiérarchique des classes RDF <rdfs :Property rdf :about="hasprice"> <rdfs :domain rdf :resource="book"/> </rdfs :Property> Fig. 1.9 Définition d une propriété en RDF Les propriétés sont définies à l aide des attributs rdfs : domaine et rdfs : range. Elle peuvent être aussi organisées en hiérarchie en utilisant subpropertyof (voir figure 1.9). 16

18 En dépit de la similitude dans leurs appellations, Schéma RDF joue un rôle différent de celui de Schéma XML. Schéma XML spécifie l ordre et combinaison des étiquettes dans un document XML. En revanche, Schéma RDF ne fournit que des informations supplémentaires au sujet de l interprétation des déclarations (statements) donnés dans le modèle de données RDF, il ne contraint pas l aspect syntaxique d une description RDF. Schéma RDF peut être considéré comme un langage primaire d ontologie. Cependant, beaucoup de types de connaissances ne peuvent pas être exprimées avec un tel language. A titre d exemple les déclarations suivantes, relatif à l exemple de la figure 1.5, ne peuvent pas être exprimées en Schéma RDF : Déclarer que chaque livre a exactement un seul prix, mais au moins un auteur (ou plus) ; Déclarer que les titres des livres sont de type string et que les prix des livres sont de type intger ; Déclarer qu aucun livre ne peut être hardcover et softcover en même temps ; Déclarer que chaque livre est soit hardcover ou softcover (c.-à-d. il n y a pas une autre option que ces deux la) OWL (Ontology Web Langage) Le langage d ontologies OWL [38] est le résultat du développement des précédants langages d ontologie OIL [9], DAML [5] et DAML+OIL [10]. Recommandation du W3C, il est dédié aux définitions des classes et des types de propriétés. Fig Origine du langage OWL 17

19 OWL est un langage caractérisé par une grande expressivité, il est fractionné en trois sous langages d expressivité croissante, de tel sorte que chaque sous langage (OWL LITE, OWL DL, OWL FULL) représente une extension par rapport à son prédécesseur : OWL LITE est destiné aux utilisateurs ayant principalement besoin d une hiérarchie de classification et de contraintes simples. Par exemple, bien qu obéissant à des contraintes de cardinalité, il n admet que des valeurs de cardinalité de 0 ou 1. OWL Lite a également une complexité formelle inférieure à celle de OWL DL ; il ne contient qu un sous-ensemble réduit de constructeurs puisqu il : Reprend tous les constructeurs de RDF (c est-à-dire fournit des mécanismes permettant de définir un individu comme instance d une classe, et de mettre des individus en relation), Utilise les mots-clés de RDFS (rdfs :subclassof, rdfs :Property, rdfs :subpropertyof, rdfs :range, rdfs :domain), avec la même sémantique, Permet de définir une nouvelle classe (owl :Class) comme étant plus spécifique ou équivalente à une intersection d autres classes, owl :sameindividualas et owl :differentindividualfrom permettent d affirmer que deux individus sont égaux ou différents, Des mots-clés permettent d exprimer les caractéristiques des propriétés : owl :inverseof sert à affirmer qu une propriété p est l inverse de p (dans ce cas, le triplet <s p o> a pour conséquence <o p s>) ; d autres caractéristiques sont par exemple la transitivité (owl :TransitiveProperty), la symétrie (owl :SymmetricProperty). owl :allvaluesfrom associe une classe C à une propriété P. Ceci définit la classe des objets x tels que si <x P y> est une relation, alors la classe de y est C. OWL DL est destiné aux utilisateurs qui demandent une expressivité maximale tout en retenant la complétude du calcul (toutes les inférences sont garanties calculables) et la décidabilité (tous les calculs s achèveront dans un intervalle de temps fini). Les constructeurs de OWL DL sont constités de : l ensemble des constructeurs OWL LITE, mais avec des contraintes particulières sur leur utilisation (par exemple, alors qu une classe peut-être une sous-classe de plusieurs classes, une classe ne peut pas être une instance d une autre). tout entier positif dans les contraintes de cardinalité. owl :oneof permet de décrire une classe en extension par la liste de ses instances, owl :hasvalue affirme qu une propriété doit avoir comme objet un certain individu, owl :disjointwith permet d affirmer que deux classes n ont aucune instance commune, 18

20 owl :unionof et owl :complementof permettent de définir une classe comme l union de deux classes, ou le complémentaire d une autre classe. OWL FULL est sans aucune contrainte, il est destiné aux utilisateurs qui veulent une expressivité maximale et la liberté syntaxique de RDF. OWL Full autorise une ontologie à augmenter le vocabulaire prédéfini (RDF ou OWL). Il est peu probable qu un système de raisonnement puisse mettre en oeuvre toutes les caractéristiques de OWL Full. Les constructeurs de OWL Full sont : reprend tous les constructeurs d OWL DL, reprend tout Schéma RDF. OWL Full peut être considéré comme une extension de RDF, tandis que OWL Lite et OWL DL comme des extensions d une vue restreinte de RDF. Tout document OWL (Lite, DL, Full) est un document RDF, et tout document RDF est un document OWL Full, mais seuls certains documents RDF seront des documents OWL Lite ou OWL DL légaux. A cause de cela, il faut se montrer prudent lors de la migration d un document RDF vers OWL Conclusion La manipulation des ressources du Web par des machines requiert l expression ou la description de ces ressources. Plusieurs langages ont été définis à cet effet, ils permettent d exprimer données et méta-données, de décrire les services Web et leur fonctionnement, et de disposer d un modèle abstrait de ce qui est décrit grâce à l expression d ontologies (RDFS, OWL). Ces langages sont la base pour la réalisation du Web sémantique. Cependant, il reste beaucoup de choses à faire pour standardiser le tout, mais comme l écrit, Tim Berners-Lee, le Web sémantique est ce que nous obtiendrons si nous réalisons le même processus de globalisation sur la représentation des connaissances que celui que le Web fit initialement sur l hypertexte. 19

21 Chapitre 2 Les Services Web 2.1 Introduction Les services Web permettent de définir les données transmises entre deux applications, mais aussi comment traiter ces données, et comment les relier à l interne et à l externe d une application logicielle sous-jacente d une manière standard [23]. Un service Web est donc la partie middleware d une application, tel que derrière le service Web on trouve une implémentation de l application (ou des applications) qui fournit le service. Les services Web [14] sont des applications qui relient des programmes, des bases de données ou des processus d affaires à l aide de XML et de protocoles Internet standards. Ils sont développés à l aide de langages tel que visual basic, C, C++, Java et autres. Les services Web permettent aux entreprises et individus de publier des liens vers leurs applications de la même manière qu ils publient des liens vers leurs pages Web. Conséquemment, les services Web peuvent faire en sorte que toutes les ressources informatiques, dont une entreprise a besoin, soient des ressources distribuées à la grandeur de l Internet. Contrairement à la plupart des applications de type client/serveur, les services Web ne fournissent pas d interface usager. Ils sont utilisés afin d envoyer des données destinées à être lues par des machines. Cependant, les programmeurs peuvent tout de même développer une interface graphique pour l utilisateur. Les services Web peuvent être publics ou privés. Un service Web public est accessible par n importe quel utilisateur voulant l utiliser (exemple : annuaire des s). Par contre, un service Web privé est destiné à une catégorie restreinte d utilisateurs ou à être utilisé dans un environnement restreint. 20

22 2.2 Caractéristiques des services Web Le consortium W3C 1 définit un service Web comme étant une application ou un composant logiciel qui vérifie les propriétés suivantes : Il est identifié par une URI, Capacité des interfaces et liaisons (bindings) d être publiées, localisées et invoquées via XML. Un service Web peut-être publié dans un registre situé à l intérieur ou à l extérieur d un SI (Système d Information). Un service Web peut être localisé en interrogeant le registre qui l héberge. Une fois localisé, un service Web peut être invoqué (même par un autre service Web) en envoyant une requête appropriée. Il peut interagir directement avec d autres services Web à travers le langage XML et en utilisant des protocoles Internet (HTTP, SMTP,...) Composante logicielle légèrement couplée à interaction dynamique, c est-à-dire, le service Web et le programme (requérant du service Web) qui l invoque peuvent être modifiés indépendamment l un de l autre, ce qui permet une grande flexibilité. De plus, le service Web peut être localisé et invoqué au moment de l exécution du programme par le requérant sans avoir à programmer cette habileté à l avance. Une définition globale d un service Web, au niveau technologique, peut être [14] : Une application logicielle, légèrement couplée, à interaction dynamique, identifiée par une URI, pouvant interagir avec d autres composantes logicielles, et dont les interfaces et liaisons (bindings) ont la capacité d être publiées, localisées et invoquées via XML et protocoles Internet communs. 2.3 Standards des services Web HTTP est le protocole de base pour le transport des messages entre services Web. Il existe une multitude de standards XML, ZapThink 2 en a dénombré audelà de 450 organisés en quatre catégories : les spécifications XML de bases, les spécifications orientées messages, les spécifications orientées document et les vocabulaires de communauté. Selon cette catégorisation, les standards des services Web (SOAP,WSDL,UDDI,BPEL4WS) appartiennent à la catégorie "spécifications orien- 1 http :// 2 http :// 21

23 tées message". XML-S UDDI BPEL4 WS XML WSDL SOAP HTTP URI Fig. 2.1 Standards des services Web SOAP (Simple Object Access Protocol) Proposé au W3C par Microsoft, IBM, Lotus, DevelopMentor et Userland, SOAP est un protocole de communication entre services Web, il fournit les mêmes fonctionnalités que les technologies CORBA, DCOM et Java RMI, mais comme il est basé entièrement sur XML cela le rend indépendant des langages et des plateformes d exploitation employés pour l implémentation des services Web. Par exemple, un client SOAP Java s exécutant sur Linux ou un client SOAP Perl s exécutant sur Solaris peut se connecter à un serveur SOAP Microsoft s exécutant sur Windows Un message SOAP est composé de trois parties ou blocs : l enveloppe (Envelope), l entête du message (Header) et le corps du message (Body) (voir Fig.2.2) L enveloppe SOAP L enveloppe SOAP <Envelope> marque le début et la fin d un message SOAP. Elle englobe les deux autres éléments d un message SOAP (Header et Body). Les spécifications du protocol SOAP imposent que tous les éléments imbriqués soient explicitement associés à un namespace, pour permettre de multiple règles d encodage du même message et afin d éviter toute ambiguïté. L en-tête SOAP L en-tête ou <Header>, élément facultatif imbriqué dans l enveloppe, permet de passer dans le message SOAP des informations complémentaires (des caractéristiques 22

24 Enveloppe SOAP En-tête SOAP (header facultatif ) Corps du message SOAP (body) Message Fig. 2.2 Structure d un message SOAP et des fonctionnalités additionnelles) sur ce même message. L en-tête peut apparaître une ou plusieurs fois dans le message SOAP, elle est généralement qualifiée par l attribut mustunderstand qui prend la valeur 0 ou 1. La valeur 1 indique que le récepteur du message doit prendre en considération l information présente dans l entête et que son traitement est obligatoire ; la valeur 0 indique que l en-tête peut être ignorée par le serveur. Un message SOAP peut avoir à "traverser" plusieurs serveurs intermédiaires avant d atteindre son destinataire final [11]. Dans ce cas, l en-tête joue un rôle primordial : à chaque arrêt le long de l itinéraire, le serveur intermédiaire extrait de l en-tête ce qui le concerne en propre et ajoute ce qui est nécessaire au serveur intermédiaire suivant (voir figure 2.3). Les éléments concernant un serveur intermédiaire sont marqués par la présence de l attribut SOAP-ENV :ACTOR avec une valeur conventionnelle : SOAP-ENV :Actor="http ://schemas.xmlsoap.org/soap/actor/next" Le corps du message SOAP Le corps du message SOAP <Body>, contient les éléments à transmettre, il est composé d un ou de plusieurs sous éléments. Ces sous éléments son : FAULT et MESSAGE L élément FAULT permet d indiquer les défaillances de transmission des massages SOAP. Il renvoie des informations sur le type d erreur, une description de l erreur et l adresse du serveur SOAP qui a généré l erreur. L élément MESSAGE contient les données à transmettre via le protocole SOAP. 23

25 Fig. 2.3 Traitements successifs de l en-tête d un message SOAP WSDL (Web Service Description Language) Développé par Microsoft, Ariba et IBM [20], WSDL est une application XML créé pour décrire et publier les interfaces et protocoles des services Web d une manière standard. L interface d un service Web est nécessaire, car elle permet d éviter de décrire des interactions spécifiques pour chaque serveur Web. WSDL présente un format commun pour la description et la publication des interfaces et protocoles relatifs aux services Web. Une description WSDL d un service Web est faite sur deux niveaux, niveau abstrait et niveau concret. Au niveau abstrait (voir Fig.2.5), la description du service Web consiste à définir les éléments de l interface du service tel que : Types de données (DataTypes), les messages (Message), les opérations (Operation), les types de ports (porttype), et les liaisons (Bindings). Types de données (Data Types) : Data types est l élément qui définit les types de données utilisées dans les messages échangés par le service Web. Une fois définis, 24

26 POST / StockQuote HTTP/1.1 Host : Content-Type : text/xml ; chartset="uft-8" Content-Length : nnnn SOAPAction : "Some-URI" <soapenv : Envelope xmlns : soapenv= "http ://schemas.xmlsoap.org/soap/envelope/"> <soapenv : Body> <m : GetLastTradePrice xmlns :m= "Some-URI"> <m : tickersymbol>dis</m :tickersymbol> </m : GetLastTradePrice> </soapenv : Body> </soapenv : Envelope> Fig. 2.4 Extrait d une requête SOAP/HTTP les Data types, ou type, peuvent être référencés dans n importe quel message. Opération : l élément operation spécifie les types d opérations supportées par le service Web, il permet d incorporer une séquence de messages corrélés sans avoir à spécifier les caractéristiques du flux de données, par exemple un message Input et un message Output corrélés sont mis en correspondance dans une seule operation de type Request/Response. Quarte types d opérations peuvent être définies en WSDL : One Way : ne nécessite pas de réponse ; Request / Response : similaire à RCP ; Solicit response : une simple requête, sans aucune donnée, pour solliciter une réponse ; Notification : similaire à broadcast. PortType : porttype est un groupement logique ou une collection d opérations supportées par un ou plusieurs protocoles de transport, il est analogique à une définition d un objet contenant un ensemble de méthodes. Au niveau concret (service implementation file) le service Web est défini grâce aux deux éléments ; port et service. Port : l élément port, dans la partie concrète, identifie un ou plusieurs bindings (ou liaisons) aux protocoles de transports (HTTP, SMTP, SOAP,...) pour un porttype donné. La séparation du protocole de transport de la définition du porttype permet a un service Web d être valable à travers plusieurs protocoles de transports sans avoir à redéfinir l ensemble du fichier WSDL. 25

27 Définition WSDL Interface service Data types Messages Operation Port type binding Implementation service Port Service Fig. 2.5 Structure d une description WSDL Finalement, l élément service spécifie l adresse complète du service Web et permet à un point d accès d une application distante de choisir à exposer de multiples catégories d opérations pour divers types d interactions UDDI (Universal Description Discovery and Integration) Introduit en 2000 par Ariba, Microsft et IBM, UDDI [25] a été créé pour faciliter la découverte de services Web en plus de leurs publications. UDDI est un annuaire orienté Business pour services Web. Les organisations publient les informations décrivant leurs services Web dans l annuaire, et l application client ayant besoin d un certain service, consulte cet annuaire pour la recherche des informations concernant le service Web qui fournit le service désiré pour une éventuelle interaction. UDDI est subdivisé en deux parties principales : partie publication ou inscription, et partie découverte. La partie publication regroupe l ensemble des informations relatives aux entreprises et à leurs services. Ces informations sont introduites via une API d enregistrement. La partie découverte facilite la recherche d information contenue dans UDDI grâce à l API SOAP. UDDI peut être vu comme un annuaire tel que : 26

28 Pages Blanches UDDI Pages Jaunes Pages Vertes Nom entreprise Emplacement géographique Description service Information contact Adresse Fig. 2.6 Ressemblance d UDDI avec un annuaire Les pages blanches : contiennent le nom, l adresse de l entreprise et l information de contact. Les pages jaunes : contiennent les données du genre : type d activité commerciale, emplacement géographique, types de produits offerts et type d industrie. Les pages vertes : contiennent des informations techniques du service offert, la manière d interagir avec le service, une définition du business process et aussi un pointeur vers le fichier WSDL et une clé unique identifiant le service. Structure de données du registre UDDI La structure de données du registre UDDI contient cinq types de données : businessentity : contient une description de l entreprise offrant le service. Les quatre autres types de données sont référenciés via cette partie. businesservice : contient le nom et une description du service offert bindingtemplate : information concernant le service incluant son adresse physique. Il est possible d enregistrer de multiple binding template pour le même service afin de définir différents points d accès (adresse physique plus port). Les différents points d accès de binding template incluent les types d URL suivant : (mailto, http, ftp, https,...). tmodel : identifie d une façon unique les specifications relatives à l interface d un service Web. tmodel est un mécanisme d échange de méta données relatives au service, tel qu une description du service Web ou un pointeur vers le fichier WSDL décrivant le service. tmodel peut être considéré comme étant un point d accès alternatif aux types de données contenues dans UDDI. publishassertion : met en correspondance deux ou plusieurs structures businessentity selon le type de relation (filiale de, département de). 27

29 1 businessentity 1 1 refersto publishes publishes publishes publisherasserti businessservice tmodel 1 has refersto bindingtemplate Fig. 2.7 structure de données d UDDI Relation entre UDDI et WSDL Conçu avant WSDL, UDDI permet de prendre en charge n importe quel langage de description des services Web grâce à son modèle de donnée extensible. Une description WSDL d un service Web peut être traduite dans UDDI grâce à la combinaison de businessservice, bindingtemplate et de tmodel (voir figure 2.8) BPEL4WS (Business Process Execution Language for Web Services) Dans la réalité il est rare de trouver un seul service Web satisfaisant une requête complexe de l utilisateur. Pour ce faire un autre type de service Web existe appelé services Web composés. Un service Web composé est un service Web faisant interagir un ensemble de services Web afin de satisfaire la requête de l utilisateur. Généralement, il existe trois types de compositions des services Web [53] : Composition exploratoire (explorative composition) Dans cette catégorie, le service composé est généré à la volée sur la base de la requête exprimée par le requérant. Le client spécifie les fonctionnalités du service désiré à l aide d un langage de requête de haut niveau. Les services constituant le service composé sont alors comparés aux caractéristiques des services Web édités dans UDDI. Le processus conforme aux spécifications du client, génère un ensemble de services composés alternatifs. Les compositions alternatives sont alors classées, ou choisies par le requérant, selon des critères non fonctionnels tel que : le coût, la qualité de service, la disponibilité. Ce type de composition (adopté dans [2]) exige que les services constituants du service composé soient dynamiquement orchestrés. 28

30 Fig. 2.8 Relation entre UDDI et WSDL Composition semi fixée (semi fixed composition) Dans cette catégorie, la composition des services est spécifiée statiquement, mais les liaisons bindings des services avec les services Web ne sont faites qu au moment de l exécution, en sélectionnant le service Web le plus adéquat. Quand un service composé est invoqué, la composition est générée dynamiquement en sélectionnant les services Web comparables aux services spécifiés dans la composition. Enfin, la définition du service composé est alors enregistrée dans un dépôt de services composés, et peut être utilisé comme n importe quel autre service Web. eflow [7],développé par HP, est un exemple de ce type de services composés. Composition fixe (fixed composition) Un service Web composé fixe, est un service où les liaisons des services constituants avec les services Web sont définies au moment du développement du service Web composé. Microsoft Biztalk et WebLogic sont deux exemples de ce type de service composé [47]. BPEL (Business Process Execution Language for Web services) est un langage de définition et d exécution des services Web composés (appelé aussi business process) faisant intervenir plusieurs services Web. Basé XML, BPEL est le fruit de la convergence de deux précédent langages de représentation de workflow, à savoir Web Services Flow Language (WSFL) et XLang. WSFL, technologie IBM, est basé sur les graphes orientés, tandis que XLang, produit Microsoft, est un langage qui a une 29

31 structure en blocs. BPEL combine les deux approches, il fournit un vocabulaire riche pour la description d un business processes. BPEL permet de décrire un business processes sur deux niveaux ; Exécutable business process et Abstract business protocols. -Executable business processes : définit l ordre d invoquation des services Web impliqués dans la composition et le flux de données entre ces services Web. Executable business processes est basé sur le paradigme orchestration et peut être exécuté par un moteur d exécution d orchestration (orchestration engine). -Abstract business protocols : permet de spécifier uniquement les messages publics à échanger entre services Web. Il n inclut pas les détails internes du flux de données du processus, de plus il n est pas exécutable. BPEL contient deux ensembles de constructeurs : constructeurs primitifs et constructeurs structurels. Ces constructeurs permettent la description d un processus d affaire exécutable "Executable business processes". Les constructeurs primitifs permettent des fonctionnalités. Parmi ces constructeurs on trouve : <Invoque> invoquer un service Web <Receive> attendre qu un client ou un service invoque le business processes par envoie de requête <Reply> générer une réponse synchrone <Assign> permet de manipuler les données des variables <Throw> indique les erreurs et les exceptions <Wait> bloque l exécution pour un temps donné Les constructeurs primitifs peuvent être combinés pour definir un algorithme complexe spécifiant les étapes par lesquelles passe le business process en utilisant les constructeurs structurels tel que : <Sequence> définit un ensemble de constructeurs invoqués par ordre d apparition dans la séquence <Flow> définit un ensemble de constructeurs invoqués en parallèle <Switch> pour le choix d une branche à exécuter <while> définit une boucle. Quand on définit un business process, on définit essentiellement un nouveau service composé d autres services Web existants. 30

32 Etapes de développement d un service Web composé (BPEL) Trois étapes sont nécessaires pour le développement d un business process, à savoir, définition de l interface du service Web composé via WSDL, définition des partner- LinkTypes, développement du business process. 1. Définition de l interface du service Web composé : afin d exposer le nouveau service (service composé) il est nécessaire de définir son interface en termes de port Types, de messages et d opérations en utilisant WSDL. 2. Définition des partnerlinktypes : partner Link Type décrit la communication existante entre le processus BPEL et les différentes parties impliquées dans la composition, incluant ainsi les services Web invoqués et le client qui a invoqué le service composé. 3. Description du corps du processus BPEL : la structure de base d un processus BPEL a la forme suivante : Le bloc <partner Links> cite plusieurs partner link qui font référence aux différentes parties impliquées dans la composition. Chaque partner Link imbrique un partner link type specifique qui le caractérise. Partner Link contient deux attributs : myrole : qui définit le rôle du business processes lui-même. partnerrole : spécifie le rôle du partenaire du processus. Le bloc Variables : le bloc variables est employé pour stocker, et transformer les messages reçus et envoyés entre les partenaires et le processus. Définition du corps principale du business process : Dans cette partie l invocation des partenaires du processus BPEL et le contrôle du flux de données entre ces partenaires sont gérés grâce aux constructeurs primitifs et structurels. 31

33 <process name="ticketorder"> <partners> <partner name="customer" servicelinktype="agentlink" myrole="agentservice"/> <partner name="airline" servicelinktype="buyerlink" myrole="ticketrequester" partnerrole="ticketservice"/> </partners> <containers> <container name="itinerary" messagetype="itinerarymessage"/> <container name="tickets" messagetype="ticketsmessage"/> </containers> <flow> <links> <link name="order-to-airline"/> <link name="airline-to-agent"/> </links> <receive partner="customer" porttype="itinerarypt" operation="senditinerary" container="itinerary" <source linkname"order-to-airline"/> </receive> <invoke partner="airline" porttype="ticketorderpt" operation="requesttickets" inputcontainer="itinerary" <target linkname"order-to-airline"/> <source linkname"airline-to-agent"/> </invoke> <receive partner="airline" porttype="itinerarypt" operation="sendtickets" container="tickets" <target linkname"airline-to-agent"/> </receive> </flow> </process> Fig. 2.9 Extrait du code BPEL d un service composé 2.4 Conclusion Les services Web sont la dernière technologie pour l intégration et l interopérabilité des systèmes répartis. Basés sur le standard XML, ils sont caractérisés par leurs indépendances aux plates formes et aux systèmes d exploitation, ce qui a impliqué leur adoption par les différentes organisations commerciales et industrielles offrant leurs services à travers le Web, et par conséquent l augmentation du nombre de services offerts. La découverte de service devient de ce fait un des aspects les plus importants relatifs aux services Web. La technologie fondamentale pour la découverte de services Web est le registre UDDI. Destiné a être utilisé par les utilisateurs humains, UDDI permet la recherche 32

34 (ou le passage en revue des descriptions des services) et la sélection manuelle des descriptions des services Web. UDDI fournit une API de recherche basée mots clés. De plus il permet aussi de faire la recherche des services en se basant sur leurs descriptions WSDL. Cependant la recherche dans UDDI (comparaison de la requête avec les descriptions des Services Web) n est faite qu au niveau syntaxique, cette méthode présente quelques limitations ; la recherche syntaxique ne permet pas de trouver le service demandé à chaque fois ; De plus, un agent logiciel ne peut pas examiner la description textuelle destinée pour des humains, il ne peut pas distinguer entre deux services Web différents ayant la même description syntaxique, ce qui présente un handicap pour l automatisation de la découverte, composition, et collaboration des services Web. Pour permettre l automatisation des diverses tâches liées aux services Web, l idée consiste à enrichir les descriptions des services Web (limitées qu aux aspects fonctionnels) par d autres informations supplémentaires compréhensibles par machines. Ces informations sont des données sur comment interpréter les descriptions des services Web. En d autres termes, c est la sémantique des descriptions des services Web, puisque deux services Web peuvent avoir la même description syntaxique mais avoir deux sens différents. Des services Web dotés de description sémantique sont dis services Web sémantiques. 33

35 Chapitre 3 Les Services Web Sémantiques 3.1 Introduction Les services Web sémantiques sont la convergence de la technologie de services Web et du Web sémantique, ce sont des services Web à descriptions dotées de sémantique. Actuellement les services Web sont décrit par le langage WSDL qui permet de définir les opérations et les paramètres autorisés par le service Web. Cela est fait en attribuant des noms aux opérations et aux paramètres, puis associer ces paramètres à des types abstraits de données (exemple : string, char,...). Par exemple le service Web TranslateFrenchToArabic accepte deux paramètres, un paramètre en entrée (input parameter) nommé WordToTranslate de type String, et un paramètre en sortie (output parameter) nommé TranslatedWord de type String aussi. TranslateFrenchToArabic Abstract type Parameter Name Input String WordToTranslate Output String TranslatedWord Tab. 3.1 Description syntaxique simplifiée du service Web TranslateFrenchToArabic Cependant, le problème avec ce type de description est que lorsqu on veut automatiser les divers aspects liés aux services Web (découverte, composition,...), l agent manipulant les paramètres du service Web ne peut pas avoir la signification de ces données. Pour l agent logiciel c est juste des variables dénotées contenant de l information. La seule chose que l agent logiciel peut inférer de la description précédente est que les deux paramètres WordToTranslate et TranslatedWord sont respectivement un paramètre d Entrée et un paramètre de Sortie de type String. A ce stade, les services Web ne sont décrits qu au niveau syntaxique. Un développeur voulant programmer une application client interagissant avec un service Web doit tout d abord avoir connaissance de la syntaxe de sa description, l interpréter, puis écrire le code client conforme aux paramètres de la description du service Web. Cependant, un 34

36 agent logiciel ne peut lire la description d un service Web comme un humain, il peut avoir connaissance de la structure syntaxique de la description mais pas sa sémantique. Les services Web sémantiques sont des services Web décrits de telle sorte qu un agent logiciel puisse interpréter les fonctionnalités offertes par le service Web. Un agent logiciel doit être capable de lire la description d un service Web pour déterminer si le service Web fournit les fonctionnalités désirées, et s il est lui-même capable d utiliser ce service. Pour permettre cela, la description du service Web doit être supplementée en information sémantique interprétable par machine. Les paramètres du service Web doivent être décrits de façon qu un agent logiciel puisse avoir connaissance de leur signification. Cela est fait par la définition de vocabulaires organisés en ontologies. Dans le domaine des services Web, les ontologies sont utilisées pour annoter les descriptions des fonctionnalités des services Web de sémantique. Ainsi pour qu un agent logiciel puisse avoir connaissance de la sémantique d une description d un service Web, il lui suffit juste d accéder à une ontologie du domaine. Le tableau 3.2 représente la même description du service précédent, sauf que cette description est augmentée d une sémantique. Une colonne supplémentaire contenant l annotation sémantique des paramètres est introduite. Les noms sémantiques utilisés dans la description sont plus descriptifs que les noms des paramètres. Ces noms font référence à des concepts définis dans des ontologies. TranslationService Abstract type Parameter Name Semantic Input String WordToTranslate FrenchWordToTranslate Output String TranslatedWord ArabicTranslatedWord Tab. 3.2 Description sémantique du service Web TranslateFrenchToArabic Un agent essayant d interpréter la description du service Web aura juste à utiliser l ontologie où les annotations sémantiques sont définies. En utilisant un moteur d inférence, l agent peut inférer les similitudes entre la sémantique employée pour décrire le service et la sémantique connue par l agent. La combinaison des technologies du Web sémantique à celles des Services Web permettra de : Automatiser la découverte de services Web, c est à dire localisation automatique des services Web qui fournissent une fonctionnalité particulière et qui répondent aux propriétés demandées par l utilisateur. Pour pouvoir effectuer une découverte automatique, le procédé de découverte devrait être basé sur la similitude sémantique entre la description déclarative, faite par l utilisateur, du service demandé et celle du service offert. 35

37 La composition automatique des services Web. Automatiser l invocation d un service Web, cela implique l automatisation de l exécution du service Web par le programme d utilisateur ou par un agent. Automatiser l interopérabilité des services Web. 3.2 Approches proposées pour la réalisation des services Web sémantiques Dans la littérature, diverses approches ont été proposées pour permettre la réalisation des services Web sémantiques. Parmi ces travaux on a : WSDL-S [33],OWL-S [19], IRS-II [21], et WSWF [8] WSDL-S (Web Service Description Language-Semantic) WSDL-S [33] est un langage de description sémantique des services Web. Une description WSDL-S de service Web est une description WSDL augmentée de sémantique, cette sémantique est ajoutée en deux étapes : La première étape consiste à faire référence, dans la partie définition de WSDL, à une ontologie dédiée au service à publier. La seconde étape consiste à annoter les opérations de la définition WSDL de sémantique en ajoutant deux nouvelles balises ; la balise Action et la balise Contrainte. La balise Action permet de représenter l action de l opération La balise Contrainte représente les pré et post condition d une opération <operation name = "checkstatus" pattern="mep :in-out" > <action element = "rosetta :QueryOrderStatus" /> <input messagelabel = "statusquery" element = "rosetta :PurchaseOrderStatusQuery" /> <output messagelabel = "status" element = "rosetta :PurchaseOrderStatusResponse" /> <pre condition="purchaseorderstatusquery.orderstatusdoc.?purchaseorder!=null" /> </operation> Fig. 3.1 Opération WSDL augmentée de sémantique OWL-S (Ontology Web Language for Services) OWL-S est un langage d ontologie pour services Web [19]. Il est basé sur le langage OWL [38]. Cette ontologie a pour objectif de d écrire de façon non ambiguë les services Web de telle sorte qu un agent logiciel puisse exploiter automatiquement ces 36

38 informations. OWL-S permet : La découverte automatique, la composition et l interopérabilité de services Web ainsi que la surveillance automatique de leurs exécution. OWL-S décrit un service à l aide des trois classes suivantes : ServiceProfile : définit le service Web. ServiceModel : définit le fonctionnement du Web service. ServiceGrounding : définit comment accéder au service Web. ServiceProfile Pour d écrire un service OWL-S définit la classe ServiceProfile. La classe Service- Profile spécifie trois informations. Nom du service, contacts et description textuelle du service : le nom du service est utilisé comme identificateur du service, tandis que les informations contacts et la description textuelle sont distinées aux utilisateurs humains. Description fonctionnelle du service : Elle spécifie ce que le service exige en terme d entrées (inputs) attendues et de résultats produits en sortie (outputs). Elle indique également les pré conditions et les effets du service. Classification taxinomique. ServiceModel La classe ServiceModel décrit le fonctionnement du service Web. Ceci est fait en exprimant les transformations faites par le service Web sur les données (input à output), et tramsformation d état (préconditions et effets). Les services Web peuvent être modélisés avec OWL-S en tant que processus grâce à la classe Process. La classe ainsi définie est une sous-classe de ServiceModel. Pour décrire un processus, on spécifie ces Entrées, Sorties et ses états. Les transitions d un état à un autre sont décrites par les pré-conditions et les effets de chaque processus. Il existe trois types de processus 1. Les processus atomiques (AtomicProcess) : exécutable en une seule étape, un processus atomique ne peut pas être décomposé de façon plus profonde. Son exécution correspond à une unique avancée dans l exécution du service, il est directement invoqué par l utilisateur du service. 2. Les processus composites (CompositeProcess) : un processus composite est constitué par l assemblage d autres processus (composite ou non composite). Les processus composites associent des processus à l aide de structures de contrôle permettant de décrire leur logique d exécution. Les structures de contrôles sont les suivantes : séquence (Sequence) représente une suite ordonnée de processus. exécutions concurrentes de processus sont décrites par Split. 37

39 synchronisation peut être décrite par Split+Join. exécution de processus sans ordre particulier avec Unordered. Le choix est décrit par Choice. Les branchements conditionnels du type si/alors/sinon sont décrits par If - Then-Else. Repeat, Iterate et Repeat-Until permettent d effectuer des itérations. 3. Les processus simples (SimpleProcess) : Les processus simples ne sont pas invocables mais comme les processus atomiques, leurs exécutions s effectuent en une seule étape. Les processus simples sont employés comme éléments d abstraction ; un processus simple peut être employé pour fournir une vue d un certain processus atomique, ou une représentation simplifiée d un certain processus composé. ServiceGrounding La classe OWL-S ServiceGrounding définit les détails techniques permettant d accéder au service Web. Les deux premières classes ServiceProfile et ServiceModel d une description OWL-S s attachent à abstraire la représentation d un service Web. ServiceGrounding est la forme concrète d une représentation abstraite, elle fournit les détails concrets d accès au service Web, tels les protocoles, les URIs, les messages envoyés, etc. Les concepteurs de OWL-S ont choisi de combiner OWL-S avec WSDL. L objectif de cette combinaison est de tirer profit de chacun d entre eux. Les types abstraits des messages employés dans les messages WSDL sont définis sémantiquement à l aide de classes OWL. Les bindings WSDL servent ensuite à définir comment ces messages sont formatés. Les relations entre OWL-S et WSDL sont les suivantes : Un processus atomique OWL-S correspond à une opération WSDL. Les entrées et sorties d un processus atomique OWL-S correspondent chacune à un message WSDL (d entrée ou de sortie). Les types des messages d un processus atomique OWL-S correspondent à l élément Types d une description WSDL. La classe OWL-S Grounding sert de base à WsdlGrounding qui contient une liste OWL d instances de WsdlAtomicProcessGrounding. Chaque instance de cette dernière classe se réfère à des éléments de la spécification WSDL en utilisant un jeu de propriétés effectuant la liaison. Au niveau des éléments propres à WSDL, des attributs XML OWL-S sont ajoutés aux balises WSDL. Ces extensions sont : owl-s-parameter (message WSDL) : indique le nom qualifié (QName) de l objet OWL-S utilisé dans la définition d un paramètre de message. 38

40 Fig. 3.2 Relations entre OWL-S et WSDL encodingstyle (binding WSDL) : spécifie la façon d encoder une classe OWLS dans un message transmis. owl-s-process (opération WSDL) : indique le processus atomique WSDL attaché à l opération. Avec OWL-S, un service Web est une entité qui présente une description de ce qu il offre, comment il fonctionne et enfin comment on peut l employer IRS-II (Internet Reasoning Service) IRS-II [21] est une architecture pour les services Web sémantiques. IRS-II est basée sur la structure UPML (Unified Problem Solving Method Development Language) [26] où diverses ontologies sont définies : Ontologie du domaine (Domain model) : elle permet de décrire le domaine d une application (ex : véhicules, maladies). Ontologie de tâche à résoudre (Task models) : elle fournit une description générique de la tâche à résoudre, spécifie les types d entrées (input) et sortie (output), le but à atteindre et les pré conditions à satisfaire. Ontologie des méthodes de résolution d un problème (Problem Solving Methods (PSMs)) : sépare la description de ce qu un service fait des paramètres et des contraintes d une mise en oeuvre particulière. Liens (bridges) : permettent la correspondance entre les différents modèles d une application. Les principaux composants de l architecture IRS-II sont : le serveur IRS-II (IRS-II server), éditeur de services (IRS-II Publisher) et la partie client (IRS-II Client). Ces trois composants interagissent entre eux via le protocole SOAP. 39

41 Fig. 3.3 Modéle de connaissance UPML Le serveur IRS-II contient les descriptions des services Web sémantiques. Ces descriptions sont faites sur deux niveaux. Au niveau connaissance, une description est sauvegardée selon la structure UPML des tâches, PSM et l ontologie du domaine. De plus, deux types de mise en correspondances sont utilisés pour lier les descriptions aux niveaux connaissances à un service Web spécifique. Le composant éditeur (IRS-II Publisher) a deux fonctions. Premièrement, il permet de lier les services Web à leurs descriptions sémantiques respectives dans le serveur. Chaque PSM est associé à exactement un service Web. Un service Web peut être associé à plusieurs PSM, puisque un service Web peut avoir plus qu une fonction. Deuxièmement, il génère automatiquement un programme qui enveloppe le code LISP ou Java du service Web, afin de l invoquer, comme c est le cas d un service Web dans sa description WSDL. Un client IRS-II invoque un service Web en envoyant une requête de la tâche à traiter. Sur la base de cette tâche le serveur sélectionne le PSM approprié et invoque le service Web avec lequel est lié ce PSM WSMF (Web Service Modeling Framework) WSMF [9] est un modèle de représentation des divers aspects relatifs aux services Web. L objectif principal de cette approche est de permettre le développement du e-commerce par application des technologies du web sémantique aux services Web. WSMF est basé sur quatre éléments : les ontologies qui fournissent la terminologie utilisée par les autre éléments ; les répertoires d objectifs qui définissent les problèmes qui doivent être résolus par les services Web ; les descriptions des services Web et un ensemble de médiateurs contribuant à outrepasser les problèmes d interopérabilités. 40

42 Fig. 3.4 Architecture IRS-II L implémentation de WSMF est partagée en deux projets : le projet SWWS (Semantic Web enabled Web Services) [25] ; et le projet WSMO (Web Service Modelling Ontology) [28]. L objectif de SWWS est de définir une structure de description et de découverte de services Web, ainsi qu une plate-forme de médiation pour services selon une architecture conceptuelle. Le projet WSMO permettra de raffiner WSMF en plus du développement d ontologie formelle de service et un langage pour services Web sémantiques. 3.3 Conclusion Les services Web sémantique sont un domaine de recherche émergent. A l état actuel il existe des technologies pour le développement des services Web. Cependant, ces technologies exigent que l utilisateur humain interagisse avec le système tout au long du processus de découverte de services Web. Les technologies du web sémantique ont été utilisées pour palier à ce problème en enrichissant les services Web de sémantique, ce qui permet l automatisation des divers aspects relatifs aux services Web. Dans ce chapitre on a présenté les principales approches actuelles pour la réalisation des services Web sémantique à savoir : WSDL-S, OWL-S, IRS-II et WSMF. De ces approches, OWL-S est celui qui est sur le point de devenir un standard. 41

43 Chapitre 4 Les Mécanismes de découverte de services Web 4.1 Introduction Le succès des services Web a impliqué l adoption de cette technologie par divers fournisseurs de services à travers le Web, ce qui a induit l augmentation du nombre des services web, rendant par suite leur découverte une tâche fastidieuse. La découverte de services Web présente un axe de recherche important. Divers mécanismes de découverte ont été proposés dans la littérature. Dans [3], les auteurs ont défini le mécanisme de découverte comme étant "l acte de localisation d une description, traitable par machine, d un service Web non connu auparavant décrivant certains critères fonctionnels". Actuellement les descriptions des services sont publiées dans des registres spécialement conçus à cet effet (ex ; UDDI). Le but de ces registres est de faciliter la recherche des services publiés par les différents organismes commerciaux. Cependant, vu le nombre et la diversité des services Web, leur découverte reste une tâche ardue. Initialement la découverte de services Web était principalement syntaxique (correspondance syntaxique des mots clés de la requête avec les descriptions des services Web). Mais avec le développement des technologies du Web sémantique, les techniques proposées pour la découverte de service Web sont devenues essentiellement sémantiques (degré de similitude sémantique entre les termes de la requête et les descriptions sémantiques des services Web). En général, les approches de découverte peuvent être classées en deux catégories : 1. Approches basées sur des descriptions syntaxiques des services Web 2. Approches Web sémantique. Toutefois ces approches peuvent varier selon l architecture,centralisée ou distri- 42

44 buée, adoptée. 4.2 Approches basées sur la représentation syntaxique Le principe général des approches basées sur la syntaxe des descriptions des services est la comparaison syntaxique entre la requête, basée mots clés, de l utilisateur et les descriptions syntaxiques (WSDL) des services Web Architecture centralisée Dans une architecture centralisée les descriptions des services Web sont sauvegardées dans un même registre. Approche UDDI UDDI [25] est un registre de descriptions de services Web. Dans le cas d une architecture centralisée UDDI est utilisé comme registre central pour la publication et la découverte, basée mots clés, des services Web. A l étape de recherche, l utilisateur ou le programme de recherche envoie une requête constituée de mots clés, cette requête est ensuite comparée avec les mots clés du registre UDDI. Un ensemble de descriptions des services Web est ensuite donné comme résultat de recherche, l utilisateur sélectionne le service Web qui répond au mieux à ses exigences. L origine de cette approche est issue du domaine de recherche d information (Information Retrieval IR). Malgré sa simplicité et sa facilité d implémentation, elle présente quand même quelques inconvénients, la méthode renvoie un nombre important de résultats ou au contraire peu de résultats. Pour rendre la découverte de services Web basée mots clés plus efficace, une technique issue du domaine de IR a été adoptée [37]. Elle consiste à représenter les descriptions des services Web sous forme de vecteurs, tel que chaque vecteur contient un ensemble de mots issus des termes utilisés dans toutes les description des Services Web. Les vecteurs de description sont ensuite organisés sous forme de matrice (terme description). La deuxième étape consiste à appliquer, sur cette matrice, la technique LSI (Latent Semantic Indexing) 1. Cette méthode permet de renvoyer toute description de service Web qui a une relation sémantique avec la requête de recherche. 1 http :// berry/lsi++/node5.html 43

45 4.2.2 Architecture distribuée UDDI distribué Dans le cas d une architecture distribuée où les descriptions des services ne sont pas centralisées dans un même registre UDDI, une approche est proposée dans [36]. Cette approche consiste à connecter un nombre arbitraire de noeuds du réseau pour former de façon virtuelle le registre UDDI, tel que chaque noeud contient une partie des descriptions des services Web du réseau. Cet ensemble de noeuds est appelé nuage ou fédération UDDI. Lorsqu un utilisateur accède à l un des noeuds pour la recherche d un service Web, le noeud en question transmet la requête de recherche aux autres noeuds avec lesquels il est connecté, et ainsi de suite pour les noeuds recevant cette requête. Pour éviter qu un noeud renvoie la même requête, un identificateur unique (ID) est associé à la requête. De plus, le noeud source de propagation de la requête associe à cette requête un nombre de sauts, tel que chaque fois que cette requête est propagée par un noeud, le nombre de saut est décrémenté de un. Quand le nombre de sauts atteint zéro, la requête n est plus propagée à travers les noeuds du nuage UDDI. Les résultats de chaque noeud ayant reçu la requête sont ensuite expédiés au noeud source. Dans cette approche la découverte est faite au niveau syntaxique. Approche AASDU Une approche multi agents pour la découverte de services Web a été proposée dans [28]. Le système appelé AASDU (Agent Approach for Service Discovery and Utilization) contient quatre composants : Une interface utilisateur graphique (Graphical User Interface GUI) Un agent analyseur de requête (Query Analyzer Agent QAA) Un système référentiel des domaines d expertises des agents de service. Ce système permet de référencier les agents selon leur expertise, ainsi il n est pas nécessaire que chaque agent ait connaissance de tous les services publiés dans les registres distribués. Chaque agent a juste connaissance des services relatifs à son domaine d expertise. Dans ce système, chaque agent a un profil déterminant ses intérêts et son expertise. L expertise de l agent est représentée par un vecteur de mots clés tel que chaque mot clé représente un domaine donné. Pour chaque mot clé un score est assigné indiquant le degré d expertise de l agent dans ce domaine. De plus, chaque agent a une liste d agents voisins (Neighbor list). Cette liste indique les voisins de l agent ainsi que leurs domaines d expertise. Lorsqu un agent vient joindre le système, un ensemble de voisins lui est assigné de façon aléatoire. Le module de services : ce composant offre trois sous services. le premier service permet aux fournisseurs de services de publier les descriptions de leurs 44

46 services Web. Pour chaque fournisseur de service Web un agent lui est assigné. Le deuxième service consiste en un agent de négociation permettant la sélection de service. Le troisième service est offert par l agent composition, le rôle de cet agent est d invoquer un des services issus de l étape de sélection ou d invoquer un service similaire lors de la défaillance du service sélectionné en premier. Dans ce système l utilisateur entre sa requête de recherche sous forme de chaîne de caractères via l interface GUI. La requête est ensuite envoyée à l agent QAA, le rôle de cet agent est de faire ressortir de cette requête les mots clés pertinents qui seront utilisés pour sélectionner des agents du système référentiel des domaines d expertises des agents service. Pour ce faire l agent QAA utilise une simple variante de la technique TFIDF (Term Frenquency Inverse Document Frequency) pour ressortir les mots clés pertinents, sur la base de ces mots clés l agent QAA sélectionne un ensemble d agents experts [15]. Les agents sélectionnés transmettent par la suite les paramètres des services avec lesquels ils sont liés à l agent composition. Ce dernier invoque un des services selon le choix de l utilisateur. Fig. 4.1 Architecture AASDU 45

47 4.3 Approches Web sémantique De récents travaux se sont focalisés sur la description sémantique des services Web. Ce développement est de plus en plus significatif puisqu il semble pouvoir aborder certaines insuffisances des approches basées sur les mots clés. Les ontologies sont le modèle utilisé pour la représentation sémantique des services Web, elle permet d établir des relations sémantiques entre les différents concepts d un domaine Architecture centralisée Dans les architectures centralisées les descriptions sémantiques des services Web sont sauvegardées dans un registre central. Approche OWL-S Parmi les ontologies proposées pour la description des services Web nous avons l ontologie DAML-S. Cette ontologie est basée sur le langage d ontologie DAML. Elle est remplacée par une nouvelle ontologie basée sur le langage OWL, cette nouvelle ontologie est OWL-S [19]. OWL-S permet d étendre UDDI avec la description sémantique des services Web [29]. OWL-S décrit un service Web à l aide de trois classes. De ces classes, ServiceProfil est la classe qui fournit les paramètres fonctionnels nécessaires pour la découverte de services Web tel que les Entrées attendues, résultats produits en sortie, Pré conditions et Effets. La découverte de services Web sémantiques définis par l ontologie OWL- S est basée sur l algorithme Matchmaking. Cet algorithme permet de rechercher les descriptions des services Web qui ont une correspondance sémantique entre les paramètres fonctionnels définis dans les descriptions des services et ceux introduits dans la requête de recherche [44]. Il y a correspondance sémantique entre les paramètres de Sortie mentionnés dans la requête et ceux d un service Web si et seulement si pour chaque paramètre de Sortie de la requête il existe un paramètre de Sortie qui peut lui correspondre dans la description du service Web. Si un des paramètres de Sortie de la requête n a pas de correspondance sémantique avec un des paramètres de sortie du service alors le service n est pas sélectionné. La correspondance sémantique entre les paramètres d entrée est aussi faite de la même façon que pour les paramètres de sortie, sauf que l ordre est inversé, c est-àdire la recherche d une correspondance sémantique entre les paramètres d entrée d un service Web contre les paramètres d entrée cités dans la requête. 46

48 outputmatch(outputsrequest, outputsadvertisement) { globaldegreematch= Exact forall outr in outputsrequest do { find outa in outputsadvertisement such that degreematch= maxdegreematch(outr, outa) if (degreematch= fail) return fail if (degreematch < globaldegreematch) globaldegreematch= degreematch return sort (recordmatch) ;} Fig. 4.2 Extrait de l algorithme Matchmaking Le degré de correspondance sémantique entre deux paramètres de sortie ou deux paramètres d entrée dépend de la correspondance sémantique entre les concepts associés à ces paramètres d entrée et de Sortie. La correspondance sémantique entre deux concepts est basée sur la relation entre ces deux concepts dans leurs ontologies OWL. Par exemple, considérant un service Web de vente de véhicules (Selling vehicule Web Service) dont le paramètre de sortie est spécifié comme Vehicule, et une requête de recherche dont le paramètre de sortie est spécifiée comme Car. Bien qu il n y ait pas de correspondance sémantique exacte entre le paramètre de sortie de la requête et celui du service Web, étant donné le fragment de l ontologie de véhicule (voir figure), l algorithme a pu déterminer un autre niveau de correspondance puisque le concept Vehicule englobe (subsume) le concept Car. Fig. 4.3 Niveaux de correspondance L algorithme permet de déterminer quatre niveaux de correspondance sémantique entre deux concepts. Soit OutR représente le paramètre de sortie cité dans la requête de recherche, et OutA le paramètre de sortie d un service Web. Le degré de 47

49 Fig. 4.4 Ontologie de véhicule correspondance entre OutR et OutA peut être : Exact : Si OutR est OutA sont les même ou si OutR est une sous classe immédiate de OutA dans l ontologie du domaine de recherche. Plug in : Si OutA englobe (subsume) OutR Subsume : Si OutR englobe (subsume) OutA, dans ce cas le service Web peut ne pas satisfaire la requête complètement Disjoint : S il n y a aucune relation entre OutA et OutR. Le niveau de correspondance sémantique entre les paramètres d entrée est assigné de la même manière que pour les paramètres de Sortie, sauf que les arguments sont inversés, c est à dire : degreeofmatch(ina,inr)dans l algorithme degreeofmatch(outr, outa) { if outa= outr then return Exact if outr subclassof outa then return exact if outa subsumes outr then return plugin if outr subsumes outa then return subsumes otherwise fail Fig. 4.5 Régles d assignation du niveau de correspondance La dernière partie de l algorithme est la partie consacrée à la classification des descriptions des services sélectionnés. Les services sont classés selon le niveau de correspondance sémantique entre leurs paramètres de sortie et ceux cités dans la requête. Si deux services sont du même niveau de correspondance sémantique avec la requête de recherche par rapport à leurs paramètres de sortie, une comparaison sur le niveau de correspondance sémantique par rapport aux paramètres d entrée est alors effectuée. Cet algorithme permet de rechercher et de sélectionner un ensemble de services Web sémantiques candidats satisfaisant la requête de recherche en terme de para- 48

50 sortrule(match1, match2) { if match1.output > match2.output then match1 > match2 if match1.output = match2.output and match1.input > match2.input then match1 > match2 if match1.output = match2.output and match1.input = match2.input then match1 = match2 Fig. 4.6 Procédure de classification du résultat de recherche mètres d entrées et de sorties. Architecture IRS-II L architecture IRS-II [21] est une architecture centralisée. Les principaux composants de cette architecture sont : le serveur IRS-II (IRS-II server), éditeur de services (IRS-II Publisher) et la partie client (IRS-II Client). Ces trois composants interagissent entre eux via le protocole SOAP. Le serveur IRS-II contient les descriptions sémantiques des services Web. Ces descriptions sont faites sur deux niveaux. Au niveau connaissance, une description est sauvegardée selon la structure UPML des tâches [26], une Ontologie des méthodes de résolution du problème (PSM) et l ontologie du domaine. Le composant éditeur (IRS-II Publisher) a deux fonctions. Premièrement, il permet de lier les services Web à leurs descriptions sémantiques respectives dans le serveur. Chaque PSM est associé à exactement un service Web. Un service Web peut être associé à plusieurs PSM, puisque un service Web peut avoir plus qu une fonction. Deuxièmement, il génère automatiquement un programme qui enveloppe le code LISP ou Java du service Web, afin de l invoquer, comme c est le cas d un service Web dans sa description WSDL. Un client IRS-II invoque un service Web en envoyant une requête de la tâche à traiter. Sur la base de cette tâche le serveur sélectionne le PSM approprié et invoque le service Web avec lequel est lié ce PSM Architecture distribuée Architecture PSWSD L architecture PSWSD (P2P-based Semantic Web Service Discovery)[51] est une architecture pour la découverte de services dans un réseau P2P. Les services Web 49

51 Fig. 4.7 Architecture IRS-II sont décrits sémantiquement par les concepts de l ontologie WSMO en utilisant les techniques proposées dans [40]. Chaque description de service contient : une description WSDL du service la sémantique des paramètres fonctionnels du service (Entrée, Sortie, Pré condition et Effet) des informations de qualité de service. Dans cette architecture les fournisseurs de services publient les descriptions de leurs services Web dans divers registres distribués dans le réseau P2P (étape1). Un utilisateur cherchant un service Web, avec certaines qualités de service, peut interroger n importe quel registre du réseau comme point d accès (étape2). Le registre ayant reçu la requête de l utilisateur va la diriger vers le(s) registre(s) pouvant satisfaire cette requête. Chaque registre du réseau contient un ensemble de modules. Lorsqu un registre reçoit une requête qui peut la traiter, cette dernière est transmise au module de traitement de requêtes afin de faire ressortir les fonctionnalités du service demandé par l utilisateur, ces informations sont ensuite envoyées au module matchmaker. Le matchmaker sélectionne les descriptions des services ayant une correspondance sémantique avec la requête de l utilisateur en terme de fonctionnalités demandées par l utilisateur et offertes par le service (3). Les résultats sont ensuite transmis à l utilisateur (4), ce dernier choisit un service pour l invoquer. Dans ce système les utilisateurs peuvent faire des évaluations sur les qualités de service des services Web et les envoyer au registre contenant les descriptions de ces services. Pour vérifier l authenticité des évaluations des utilisateurs sur les qualités de service des services web invoqués, les auteurs ont utilisé des agents de surveillance de qualités de service, ces agents ont pour rôle d évaluer les qualités de service de certains service Web. Leurs évaluations sont ensuite utilisées pour déterminer les utilisateurs malveillants dans leurs rapports d évaluation de QoS. 50

52 Fig. 4.8 Découverte sémantique basée P2P Système Speed-R Développé à l université de Georgie, le système Speed-R [41] vise à connecter l ensemble des registres UDDI privés (chaque fournisseur de services a son propre registre UDDI) via le réseau P2P. Cependant, au lieu de décrire les services Web avec UDDI tmodels, ces derniers sont décrits en utilisant WSDL. Afin d apporter une sémantique aux descriptions des services, pour chaque registre du réseau P2P des ontologies spécifiques au domaine du registre sont implémentées à son niveau. La sémantique est apportée aux descriptions des services en faisant un mapping entre les spécifications du service et les concepts des ontologies. Quand un utilisateur veut chercher un service web, il doit choisir un registre du domaine de recherche, le choix du registre est fait en se basant sur l ontologie de domaine des registres. L utilisateur peut envoyer une requête simple ou peut utiliser l agent de recherche sémantique pour exécuter la recherche sémantique de services web dans le registre. La recherche sémantique des services est basée sur les paramètres fonctionnels du service. De plus, l interaction entre les utilisateurs et les registres du réseau est réalisée par l intermédiaire d agents logiciels. L implémentation du système est basée JXTA [27]. 51