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

53 service Web 2 service Web 1 Compagnie A service Web 4 service Web 3 Compagnie B Registry Réseau P2P de Registres Registry service Web 5 Registry Registry Registry Compagnie C service Web 6 Fig. 4.9 Réseau P2P de registres Approches basées sur les Logiques de description Une approche basée sur la Logique de Description (LD) pour la découverte sémantique de services Web a été proposée dans [35]. L auteur définit le problème de découverte de services Web comme suit : ayant une requête et des services exprimés dans une logique de description, comment trouver les combinaisons des services qui couvrent au mieux la requête, telles que le maximum d informations de la requête se retrouve dans les combinaisons des services et que le minimum d informations en plus soit apporté par ces combinaisons. Le problème de découverte de services Web peut donc être formalisé de manière générale par une nouvelle instance du cadre de la réécriture. Nommé recherche des meilleures couvertures d un concept en utilisant une terminologie [17], il est défini de la manière suivante : soit une description Q et une terminologie T, une description E est une meilleure couverture de Q en utilisant T si et seulement si : E est une conjonction de concepts définis de T, Q E Q, i.e. E partage des informations non triviales avec Q, E minimise la taille de Q E par rapport à la subsomption, i.e. l information de Q non couverte par E est la plus petite possible et E minimise la taille de E Q par rapport à la subsomption, i.e. l information 52

54 apportée par E et absente de Q est aussi la plus petite possible. Ce problème n est valide que dans le cadre des langages où la différence entre descriptions est sémantiquement unique, i.e. pour deux descriptions A et B quelconques de ces langages, la différence A B ne donne qu une seule description modulo l équivalence. Pour réaliser cette réécriture de requête, l auteur se base sur les travaux de Teege sur la différence entre concepts. Dans [49], Teege propose une classe de langages pour lesquels la différence entre concepts peut être calculée de la même manière qu une différence ensembliste grâce à des descriptions sous forme clausale. Comme la définition du problème est basée sur cette différence, c est un langage de représentation de cette classe qui a été choisi pour supporter ce raisonnement, et donc pour définir les services Web, même si son expressivité est réduite. Pour rechercher les meilleures couvertures d un concept en utilisant une terminologie, l auteur utilise un algorithme issu de la théorie des hypergraphes : cette recherche est équivalente à la recherche des transversaux minimaux de coût minimal dans un hypergraphe où les sommets sont les services Web et les arêtes sont les clauses de la requête. L approche présentée par l auteur a été implémentée à travers le projet MKBEEM 2 dont le but est de permettre la création d un marché électronique basé sur l utilisation de e-services multilingues et intelligents. L architecture MKBEEM est une architecture centralisée. La connaissance dans cette architecture est représentée sur trois niveaux : le premier niveau regroupe l ontologie globale et les ontologies de domaines (ensemble des concepts généraux et des concepts relatifs à un domaine particulier, comme le tourisme par exemple), le deuxième niveau est l ontologie des services (définis à l aide des concepts du premier niveau) et le troisième niveau est la couche fournisseurs (vues des systèmes fournisseurs exprimées comme concepts LD). A ce stade les approches proposées pour la découverte de services Web en général, et les services Web sémantiques en particulier ne sont basées que sur les critères fonctionnels des services. Cependant, lors de la découverte l utilisateur espère avoir des services qui soient adéquats avec son contexte (localisation, type de dispositif utilisé, profil, etc.), hors les approches actuelles pour la découverte de services Web sont insensibles à l utilisateur et à son contexte. C est pour cette raison que de nouvelles approches ont été proposées prenant en compte le contexte de l utilisateur. De telles approches sont dites approches sensibles au contexte. L objectif de ces approches est de fournir des services Web dont le contexte est adéquat avec celui de l utilisateur. 2 http ://mkbeem.elibel.tm.fr/ 53

55 4.4 Découverte basée sur le Contexte Dey défini le contexte comme étant : " toutes les informations pouvant être utilisées pour caractériser la situation d une entité, où une entité est une personne, un lieu, ou un objet qui peut être pertinent pour l interaction entre l utilisateur et l application, y compris l utilisateur et l application eux-mêmes" [1]. Par cette définition chacune des deux entités, utilisateur et service Web, a son propre contexte. Le contexte d un service Web peut grouper la localisation du service (restriction d usage géographique du service), le coût d utilisation, la catégorie de service, etc. Le contexte de l utilisateur peut être formé de la localisation de l utilisateur, son profil, etc Modèles de représentation du contexte A ce jour, six modèles de représentation du contexte ont été proposés [45] : Modèle Clé - Valeur Considéré comme la plus simple structure de données pour la représentation du contexte, ce modèle est généralement utilisé dans les architectures orientées services où les paires clé-valeur sont utilisées pour décrire les caractéristiques d un service. La découverte de services est effectuée par l application d un algorithme de recherche basé clé-valeur. La clé correspond au nom de la méta-donnée. La valeur représente l information que doit porter la méta-donnée Modèle basé Schéma Markup Ce modèle a une structure hiérarchique de balises markup, tel que chaque balise contient un attribut et sa valeur. CC/PP (Composite Capabilities / Preference Profil) [12] est un exemple caractéristique de ce modèle. Modèle graphique UML (Unified Modeling Language) peut être utilisé comme modèle de représentation du contexte. Il a été adopté dans plusieurs approches pour modéliser le contexte comme par exemple dans les travaux réalisés par Sheng et Benatallah dans [39]. Modèle orienté objets Représenter le contexte en utilisant les techniques de l orienté objet offre toute la force du paradigme orienté objet tel que : l encapsulation, l héritage et la réutilisation. Les différents paramètres formant le contexte sont représentés par des objets tel que : température, localisation, etc. 54

56 Modèle logique Ce modèle permet un haut degré de formalisme. Faits, expressions et règles sont utilisés pour définir le modèle du contexte. Ce modèle est généralement adopté dans les systèmes basés logique. De plus, grâce au processus d inférence du système, d autres informations relatives au contexte peuvent être déduites. Modèle basé ontologie L ontologie permet de décrire différents concepts et leur relations. Caractérisée par un formalisme hautement expressif et la possibilité d utiliser des techniques de raisonnement, l ontologie a été adoptée dans différents systèmes sensibles au contexte comme modèle de représentation des données Approches de découverte basées sur le contexte 1. Approche UDDI+ L idée principale de cette approche est de faire des extensions au niveau du serveur UDDI afin de prendre en compte les informations du contexte lors de la découverte de services. Le nouveau serveur UDDI est appelé UDDI+ [32], l objectif de ce nouveau UDDI est de : 1. Permettre une découverte sémantique de services Web 2. Fournir à l utilisateur des services qui sont adéquats avec son contexte (localisation, etc.) UDDI+ est constitué de quatre composants principaux : Le composant Proxy (1) permet la publication des descriptions syntaxiques et sémantiques des services. Lorsque le Proxy reçoit une requête de publication ou de mise à jour, ce dernier la transmet au serveur UDDI qui lui assigne un identifiant unique (Universal Unique Identifier UUID). Le Proxy vérifie si le message de description contient un t-model décrivant le service en DAML-S, si c est le cas alors la description sémantique est sauvegardée dans le répertoire DAML-S avec le même identifiant UUID, sinon la description est sauvegardée dans UDDI. Le fournisseur de service peut spécifier la durée de validité des informations publiées. Cette information est utilisée par le module planificateur (scheduler) responsable de la suppression des descriptions des services au niveau de UDDI et du répertoire DAML-S dont la date de validité des informations est dépassée. Le deuxième composant (2) est une interface simple de recherche relative au standard UDDI. Pour des recherches avancées, les auteurs ont proposé une in- 55

57 terface nommée Inquiry+ permettant à l utilisateur d introduire une description du service voulu ainsi que les informations contextes. Le composant (3), Matcher, utilise les ontologies pour découvrir tous les services qui correspondent à la requête de l utilisateur sur le plan sémantique et filtre les services qui ne sont pas appropriés à l utilisateur sur le plan contextuel. Enfin, le composant (4) est une base de données des ontologies tel que l ontologie de représentation du contexte. Fig Architecture de UDDI+ 2. SOAP : contexte intégration L approche proposée dans [16] consiste a intégrer le contexte dans le protocole de communication SOAP. Le but de cette approche est de rechercher et de sélectionner des services Web selon un contexte prédéfini intégré dans le standard SOAP. Ce contexte prend principalement en compte le dispositif utilisé et la localisation de l utilisateur. La sélection basée contexte des services, réalisé par l intermédiaire du gestionnaire de contexte (Context Manager), s effectue en quatre étapes (Fig :4.11) 1. La requête SOAP est prétraitée par le gestionnaire de contexte, afin de faire ressortir le contexte transmis par ce protocole de communication. Ce processus permet de trouver à l étape suivante un service Web adéquat avec le contexte utilisateur. 2. Le gestionnaire de contexte invoque un service Web en correspondance avec le contexte défini. 56

58 Fig Découverte de services Web par contexte d aprés Keidl 3. La réponse du Service invoqué est ensuite transmise au gestionnaire de contexte pour vérifier si elle correspond bien au contexte. 4. Enfin, le résultat du service traité est envoyé au module de traitement SOAP (SOAP Request Processing) afin d être traduit dans ce langage et être renvoyé au client. 3. Architecture CASD Le système CASD (Context Aware Service Discovery) [6] est un système de découverte de services Web basé sur le contexte. Dans ce système un module de découverte sémantique est responsable de déterminer les catégories des services qui ont une relation sémantique avec la requête de l utilisateur en se basant sur des ontologies du domaine. Lorsque l utilisateur formule sa requête (Q usr ) en terme de mots clés une autre requête (Q ctx ) est attachée à cette dernière. La requête Q ctx contient les informations du contexte de l utilisateur, tel que le type de dispositif et le profil de l utilisateur, ces deux informations sont récupérées des deux bases de données des profils utilisateurs et types de dispositifs respectivement. D autres informations relatives au contexte de l utilisateur tel que sa localisation et l heure d envoi de la requête sont attachées à la requête Q ctx. La requête Q usr permet de trouver les services Web qui ont une relation sémantique avec les termes de recherche de l utilisateur tandis que la requête Q ctx joue le rôle de filtre permettant de sélectionner les services qui ont une correspondance contextuelle avec l utilisateur. L architecture CB-SeC CB-SeC est une architecture pour la découverte et la composition basée sur le contexte des services Web [13]. Cette architecture est composée de quatre couches 57

59 (fig). La couche physique (The Physical layer) : cette couche représente les ressources appartenant à l environnement. Les ressources décrivent toutes les entités qui peuvent être impliquées dans le processus d exécution d une application comme par exemple des dispositifs physiques de connexion, des composants logiciels et aussi des capteurs. La couche contexte (The Context layer) : cette couche est responsable de cueillir et traiter les informations contextuelles. Il est composé de deux modules : le module de collecte des informations sur le contexte et une base de données pour les données du contexte. Le module de recueille des informations Contexte consiste en un Système Multi agent dans lequel chaque agent est responsable de cueillir et de traiter un certain type d informations du contexte (par exemple le contexte d utilisateur, le contexte de dispositif, etc.) et de sauvegarder ces informations au niveau de la base de données des informations du contexte. Les informations contextuelles sont acquises par des capteurs, ou à l aide des agents dans le système. La couche services (The services layer) : Cette couche est responsable de la découverte, composition et exécution des services Web. La couche application utilisateur (The End-User Application layer) : consiste en un ensemble d interfaces permettant aux différents utilisateurs de spécifier leurs profils et préférences. Fig Architecture CB-SeC Dans l architecture CB-SeC chaque description de service Web contient quatre parties : 58

60 Une partie consacrée à décrire l interface du service (interface description) en terme d opérations pouvant être invoquées ainsi que leurs paramètres d entrées et sorties La deuxième partie fournit les informations nécessaire pour localiser et accéder au service (URL) ainsi que les protocoles pour l invoquer (HTTP, HTTPS, SMTP, etc.), ainsi que les types et les ports. Une description des contraintes du service : cette partie permet de spécifier les conditions d utilisation du service. Cette partie est nécessaire lorsque différents fournisseurs offrent le même service (même interface) mais avec différentes contraintes par rapport aux paramètres d entrée et sortie du service. La dernière partie décrit la fonction de sensibilité du service au contexte. Contrairement aux trois premières parties, la valeur de cette fonction n est pas connue en avance, elle est calculée lors de l étape de découverte. Chaque service a sa fonction de sensibilité au contexte, ainsi lorsqu on a plusieurs services similaires cette fonction est utilisée pour sélectionner un des services selon le contexte. Dans cette architecture cinq types d informations sur le contexte sont considérées à savoir le contexte de l utilisateur (localisation, etc.), le contexte relatif aux ressources physiques, le contexte relatif au temps (date, saison, etc.), le contexte relatif à l environnement (température, etc.) et l historique du contexte qui englobe l historique des données du contexte relatives à l utilisateur, l environnement, les ressources et le temps. Trois types d agents sont utilisés dans l architecture CB-SeC ; agent de collecte des informations du contexte (the context gathering-agent), agent manager (the manageragent) et l agent de traitement de service (the service handler-agent). Le rôle de l agent manager est de composer des services simples afin de satisfaire des requêtes complexes. Les techniques qu utilise l agent manager sont du domaine de la planification en intelligence artificielle. Le rôle de l agent de collecte est de collecter les données du contexte à travers les différentes sources de données tel que les capteurs, etc. Il est aussi responsable d enregistrer ces différentes informations au niveau de la base de données des informations du contexte. Enfin, l agent de traitement de service est responsable de trois tâches principales : découverte, composition et exécution des services. La découverte est faite en sélectionnant les services selon le contexte localisation et le type de dispositif de l utilisateur. 4.5 Synthèse des approches de découverte Les services Web constituent un moyen pour les entreprises d offrir leurs services à travers le Web. 59

61 Avec le nombre grandissant de fournisseurs de services il est nécessaire de disposer de mécanismes pour la découverte de services de manière efficace et flexible. La découverte de services Web consiste à localiser les descriptions des services Web décrivant certains critères fonctionnels. Initialement, les descriptions des services Web n étaient faites qu au niveau syntaxique, la découverte de services Web était basée sur des techniques issues du domaine de la recherche d information. Cependant, avec le développement des technologies du Web sémantique et afin d automatiser la découverte de services Web de nouvelles approches basées sur la sémantique des descriptions des services ont été proposées. En général, les approches de découverte dépendent du niveau de représentation, sémantique ou syntaxique, des descriptions des services Web. Cependant, les approches varient selon l architecture centralisée ou distribuée adoptée. Le tableau suivant représente une synthèse des principales approches (syntaxique et sémantiques) présentées dans ce chapitre. Description des services Architecture adoptée Ontologie de domaine + Ontologie des PSM Technique de découverte Technologie adoptée AASDU [28] WSDL OWL-S [19] Ontologie OWL pour service Speed-R [41] Mapping entre WSDL et ontologie de domaine IRS-II [21] PSWSD [51] Ontologie WSMO + WSDL Distribuée Centralisée Distribuée Centralisée Distribuée TFIDF Multi agents Algorithme Matchmaking SOAP Mots clés / sémantique multi agents sous réseau P2P/ PSM SOAP Matchmaker multi agents sous réseau P2P. Tab. 4.1 Synthèse des approches de découverte Dans le tableau 4.1 on peut remarquer que lorsque l architecture est distribuée les approches proposées sont implémentées en utilisant la technologies multi-agents. Cela est bien justifié puisque cette technologie est bien adaptée à la nature distribué du problème. On remarque aussi que les approches sémantiques proposées, tel que (OWL-S [19], Speed-R [41] et PSWSD [51], sont toute basées sur une même technique qui consiste à calculer le niveau de correspondance sémantique entre les paramètres fonctionnels des services et ceux mentionnés dans la requête de recherche. La différence 60

62 entre ces approches est le langage d ontologie choisi, par exemple dans PSWSD [51] une ontologie WSMO est adoptée tandis que dans [19] une ontologie OWL-S pour service basée OWL est utilisée. De ces deux ontologies, l ontologie OWL-S est celle qui est sur le point de devenir un standard. Les mécanismes de découverte doivent prendre en considération le contexte de la découverte de services afin de ne proposer à l utilisateur que des services qui répondent au mieux à ses besoins et dont le contexte de chaque service offert est adéquat avec celui de l utilisateur. Le contexte de la découverte est un ensemble d informations implicites, relatives à l utilisateur et au service Web, pouvant affecter la qualité du résultat offert. A ce jour, les systèmes de découverte de services Web sensibles au contexte sont peu fréquents. Le contexte de l utilisateur est formé par un ensemble de paramètres. Le tableau 4.2 représente les paramètres du contexte de l utilisateur considérés par les approches proposées. UDDU+ [32] SOAP contextuel [16] CB-SeC [13] CASD [6] Localisation utilisateur Dispositif utilisateur + +/- + + Profil utilisateur + - +/- + Tab. 4.2 Paramètres du contexte utilisateur Considérés La construction du contexte de l utilisateur est faite selon trois approches : approche manuelle, approche automatique et semi automatique. Dans l approche manuelle c est l utilisateur qui introduit les paramètres relatifs à son contexte, cela est fait par l intermédiaire d une interface dédiée à cet effet, comme par exemple dans l approche UDDI+ [32] et CB-SeC [13]. Dans les deux dernières approches, automatique et semi automatique, le contexte est construit automatiquement au moment d exécution par l intermédiaire d agents logiciels sauf que pour l approche semi automatique ou une partie du contexte est construite manuellement, comme par exemple dans l architecture CASD [6]. Le contexte du service Web englobe plusieurs paramètres tel que la catégorie du service, ses qualités de service, sa localisation, etc. Cependant, la plupart des approches proposées ne focalisent que sur deux paramètres, paramètre de localisation et paramètre type de dispositif pour lesquels le service peut s adapter. De plus, peu de travaux ont considéré les qualités de service lors de la découverte basée sur le contexte. 61

63 4.6 Conclusion La découverte de services Web présente un axe de recherche émergeant. Diverses approches ont été proposées dans la littérature. L objectif commun de ces approches était de découvrir des descriptions, non connues auparavant, de services Web décrivant certains critères fonctionnels. Au début, les descriptions des services Web étaient essentiellement syntaxiques, cependant, avec la fusion des deux technologies services Web et Web sémantique une nouvelle génération de services Web est née connue sous le nom de services Web sémantiques. Les services Web sémantiques sont des services Web dont les descriptions ont une sémantique. Avec le développement des services Web sémantiques de nouvelles approches de découverte ont été proposées. La plupart des approches sémantiques proposées étaient basées sur le calcul du niveau de correspondance sémantique entre les critères fonctionnels définis dans la description sémantique des services et ceux définis dans la requête de recherche. Les approches de découverte sémantique donnent de bons résultats comparées aux approches syntaxiques. Par ailleurs, pour améliorer le processus de découverte, de nouvelles approches émergent qui prennent en considération le contexte de la découverte. A travers notre étude des différentes approches de découverte basées sur le contexte nous avons remarqué que la définition du contexte d un service Web est séparée de la définition sémantique de ce dernier. De plus, peu de travaux prennent en compte les qualités de service lors de la sélection des services Web. Dans la suite de ce mémoire nous allons proposer une approche de découverte de services Web sémantiques basée sur le contexte. Dans un premier temps nous présenterons les différentes ontologies proposées pour la prise en compte du contexte lors de la découverte ainsi que les extensions faites au niveau de l ontologie OWL-S. Dans un second temps nous présenterons notre architecture multi agents pour la découverte de services Web sémantiques basée contexte. 62

64 Chapitre 5 Vers une approche de découverte basée sur le contexte 5.1 Introduction Actuellement, la découverte de services Web sémantiques est basée sur les paramètres d Entrées attendues et résultats produits en Sortie (E/S) [50]. Cependant, vu la diversité des utilisateurs et des conditions dans lequelles 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 de découverte particulier. Dans différents contextes, les utilisateurs accèdent aux mêmes services Web mais reçoivent des réponses qui peuvent être différentes ou présentées différemment ou encore à des niveaux de détails différents. Avoir un système de découverte prenant en considération les paramètres formant le contexte est dit système sensible au contexte. Dans le sens où le système retourne des services Web qui soient adaptés au contexte de l utilisateur. Dans l objectif d avoir un système de découverte sensible au contexte, nous proposons de décrire les divers paramètres du contexte à travers des ontologies qui sont décrites dans la suite de ce chapitre. 5.2 Ontologies de description des informations du contexte Les entités entrant en jeu lors de la découverte de services Web sont l utilisateur et les services Web eux mêmes. Le contexte d un service Web est formé par divers paramètres tel que le coût d utilisation du service, la localisation du service (restriction d usage géographique du service), types de dispositifs pris en charge, Qualités de Service (QoS), etc. Le contexte de l utilisateur quand à lui est caractérisé par les paramètres suivants : identité de l utilisateur, ses préférences, type de dispositif utilisé, 63

65 sa localisation, etc. Différents modèles de représentation du contexte ont été proposés [45]. Notre choix s est porté sur les ontologies pour la représentation du contexte. Ce choix se justifie par le fait que les ontologies sont considérées comme étant le modèle de représentation le plus expressif ; Elles permettent de représenter la sémantique existante entre les différents paramètres qui forment le contexte ainsi que leurs relations, elles sont basées sur les langages du Web sémantique ce qui permet le partage et la réutilisation Ontologie du Contexte de l utilisateur proposée L ontologie proposée permet de modéliser le contexte de l utilisateur. Ce contexte est formé par un ensemble de paramètres [30]. De ces paramètres nous avons choisi les suivants : l identité de l utilisateur (nom, prénom), ses préférences en terme de Qualité de Services (QoS) du service Web, sa fonction (compagnie, rôle, etc.), le type de dispositif utilisé (PDA, ordinateur portable, téléphone WAP, etc). Ces paramètres peuvent êtres classés comme suit : Paramètres statiques du contexte de l utilisateur Les paramètres statiques représentent les dimensions permanentes dans la vie personnelle de l utilisateur. Dans notre cas deux aspects statiques sont considérés : le nom et le prénom. Nom : ce nom peut être le nom usuel de l utilisateur ou un pseudonyme. Prénom : cet aspect permet de compléter l identité de l utilisateur si besoin. Paramètres dynamiques du contexte de l utilisateur Les paramètres dynamiques représentent les dimensions qui évoluent durant la vie de l utilisateur. Les aspects dynamiques considérés sont : les préférences en termes de QoS, la localisation et la fonction de l utilisateur. Préférences : ce paramètre englobe de nombreux aspects, il peut s agir par exemple du moyen de transport préféré, du sport pratiqué, etc. L aspect considéré dans notre cas est les QoS du service Web à chercher, par exemple la probabilité de disponibilité du service. Localisation : l utilisation de dispositifs mobiles rend la localisation géographique de l utilisateur utile. Un outil est employé afin de connaître cette localisation de manière automatique : il s agit du GPS (Global Positionning System) [34]. Par l intermédiaire du GPS nous pouvons connaître les attributs suivants : le pays, la ville, etc. Ces valeurs sont calculées par l intermédiaire de la longitude, la latitude et l altitude. Dans le cas ou l utilisateur se déplace dans un bâtiment, une autre méthode de détection de la position de l utilisateur peut 64

66 être utilisée[22], cette méthode est basée sur les réseaux Wi-Fi. La méthode consiste à mesurer l intensité du réseau et à calculer la distance par rapport aux bornes Wi-Fi installées au sein du bâtiment. Dans le cas où le système GPS ou le réseau Wi-Fi ne sont pas disponibles l utilisateur peut introduire sa localisation de façon manuelle Fonction : ce paramètre englobe de nombreux aspects, telle que la compagnie dans laquelle l utilisateur est affilié, son rôle, etc. En effet lorsqu un service est accessible par un groupe de travail hiérarchisé, il est important que l utilisateur renseigne son rôle, car chaque membre d un groupe ne possède pas les mêmes droits ou ne peut exécuter que certaines opérations du service. Paramètres du contexte de l utilisateur liés au dispositif Cette catégorie de paramètres représente les contraintes matérielles et logicielles du dispositif avec lequel l utilisateur accède au service. En effet, ces paramètres sont devenus importants depuis que l utilisation des dispositifs mobiles s est accrue. Le dispositif est défini selon une description matérielle par l intermédiaire des paramètres suivants : taille de l écran, types de connexions, données multimédia acceptées (image, texte, vidéo, etc.). Une seconde description qui consiste à le décrire selon les capacités logicielles (plate-forme et type de navigateur). Utilisateur Identité Préférences Fonction Dispositif Localisation Nom Prénom QoS rôle Fig. 5.1 Représentation graphique de l ontologie du contexte de l utilisateur proposée La figure 5.1 est une représentation graphique de l ontologie du contexte de l utilisateur, les ellipses représentent des classes reliées par des lignes représentants les propriétés. L ontologie du contexte de l utilisateur regroupe cinq classes selon le type d informations qu elle fournit : à savoir l identité de l utilisateur, ses préférences, sa fonction, sa localisation et une description du dispositif de connexion de l utilisateur. La classe identité définit le nom et le prénom de l utilisateur. La classe préférence définit les préférences de l utilisateur en terme de paramètres QoS relatifs à l ontologie de Qualités de Service (QoS). La classe rôle détermine les privilèges de l utilisateur. La classe dispositif permet de décrire le dispositif utilisé. Cette description est réalisée 65

67 par l intermédiaire des paramètres définis dans l ontologie de dispositif développée. La classe localisation spécifie la localisation de l utilisateur. La figure 5.2 est un aperçu du code de l ontologie du contexte de l utilisateur développée, la totalité du code est présentée dans l annexe A. <owl :Ontology rdf :about=""> <owl :imports rdf :resource="http ://protege.stanford.edu/plugins/owl/protege"/> </owl :Ontology> <owl :Class rdf :ID="User"/> <owl :Class rdf :ID="UserHasIdentity"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :Class rdf :ID="UserHasLocation"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :Class rdf :ID="QoSPreference"> <rdfs :subclassof> <owl :Class rdf :ID="UserHasPreferences"/> </rdfs :subclassof> </owl :Class> Fig. 5.2 Aperçu du code de l ontologie du contexte de l utilisateur proposée Contexte d un service Web Dans notre étude nous avons choisi l ontologie OWL-S comme ontologie de représentation sémantique des services Web. Notre choix pour OWL-S se justifie par le fait que OWL-S est une ontologie OWL standard du Web sémantique, ce qui lui donne une grande chance de devenir un standard pour la représentation sémantique des services Web. La découverte de services Web sémantiques (OWL-S) est basée sur les paramètres fonctionnels des services. Ces paramètres sont définis au niveau de la classe profil sous classe de ServiceProfil de l ontologie OWL-S. Cependant, d autres paramètres non fonctionnels sont définis au niveau de la classe ServiceParameter sous classes de Profil et qui ne sont pas considérés lors de la découverte de services Web. Ces paramètres forment le contexte du service Web. Afin de permettre une découverte de services Web dont le contexte est adéquat avec celui de l utilisateur nous proposons de considérer les paramètres non fonctionnels du service, en plus des paramètres fonctionnels, lors de la découverte de services Web. Les paramètres qui forment le contexte du service Web que nous avons choisi sont : la localisation du service (restriction d usage géographique du service), les qualités de service du service Web et les paramètres des types de dispositifs dont le service peut 66

68 ServiceProfile Precondition Effect Profile Sortie Entrée Fig. 5.3 Paramètres fonctionnels du service Web adapter l information qu il diffuse. Actuellement, dans la version 1.1 de l ontologie OWL-S les paramètres de qualités de service et des types de dispositifs dont le service peut s adapter ne sont pas définis. Cependant, la classe ServiceParameter est extensible, étant donné cette caractéristique, nous allons l exploiter afin d enrichir la classe ServiceParameter par les paramètres des types de dispositifs. Cette extension consiste à introduire le nom du paramètre comme sous classe de la classe ServiceParameter et d indiquer sa valeur dans l ontologie dans laquelle il est défini. Les paramètres de QoS ainsi que les paramètres du type de dispositif sont définis dans l ontologie de QoS et l ontologie de dispositif que nous avons développé. 67

69 ServiceProfile Precondition Effect Profile Contexte Localisation Sortie Entrée ServiceParameter Disponibilité Temps Réponse } parameters QoS Modèle dispositif Taille écran } parameters dispositif Fig. 5.4 Extensions apportées à la classe ServiceParameter de l ontologie OWL-S Ontologie de Qualités de Service (QoS) Avec la prolifération des services Web comme solution d intégration d applications d entreprises, les QoS sont devenus de plus en plus importants pour les fournisseurs de services. Les QoS d un service Web sont principalement relatives aux aspects de qualité du service Web, c est-à-dire les qualités de services de l application offrant le service. Toutefois, il faut distinguer entre les QoS relatives à l application service et ceux relatifs au réseau, tel que délai de livraison de paquets, etc. Pour obtenir les QoS d un service Web, il faut que les mécanismes de QoS fonctionnent au niveau de l application offrant le service fonctionnent avec ceux au niveau réseau (ex : RSVP, MPLS, DiffServ, etc). En particulier, les paramètres QoS au niveau application doivent être associés convenablement aux paramètres de QoS au niveau réseau. Les QoS sont un critère de sélection trés important, c est pour cette raison que les QoS doivent être prises en considération lors de la phase de découverte de services Web. 68

70 L ontologie de QoS que nous avons proposé permet de spécifier les différents attributs de QoS relatifs aux services Web ainsi que leurs relations. Il existe beaucoup d attributs de QoS qui sont importants, cependant certains attributs sont spécifiques qu à un certain type de services Web. Ces attributs dépendent du domaine d application du Service Web. Par exemple l attribut bits par second sera considéré comme un attribut important pour un service Web multimédia, tandis que l attribut sécurité sera considéré comme important pour un service Web d une banque. Ainsi les attributs de QoS peuvent être classés en deux catégories : ceux qui sont dépendant du domaine et ceux qui sont indépendant au domaine. Les attributs dépendants du domaine sont des attributs spécifiques au domaine du service [31, 50]. L ontologie ainsi définie est flexible, dans le sens où différents providers de service peuvent définir les attributs de QoS correspondant à leur domaine. QoS Domaine Indépendant Domaine dépendant Performance Scalabilité Robustesse Sécurité Coût Disponibilité Fig. 5.5 Représentation graphique de l ontologie QoS Les attributs à domaine indépendant représentent des QoS qui ne sont spécifiques à aucun service particulier ou communauté de services. Ces attributs sont catégorisé comme suit, tel que chaque catégorie contient un certain nombre de paramètres QoS : Attributs de QoS liés au temps d exécution Scalabilité : c est la capacité d augmenter les capacités de calculs du serveur de services, ainsi que l habilité du système de traiter plus d opérations ou de transactions dans une période donnée. Capacité : c est le nombre maximum de requêtes simultanées que le système prend en charge avec des performances garanties. Performance : c est la vitesse d exécution d une requête. 69

71 Fiabilité : capacité d un service d exécuter ses fonctions requises dans des conditions indiquées pendant une période donnée. Disponibilité : c est la probabilité que le système soit actif. Robustesse/Flexibilité : représente le taux pour lequel un service peut s exécuter correctement dans le cas de données d entrées inadmissibles, incomplets ou contradictoires. Exactitude : représente le taux d erreur produit par le service. Attributs de QoS liés à la sécurité Authentification : Permet de savoir comment le service Web établit l authenticité de l utilisateur ou des autres Web Services qui interagissent avec ce service. Confidentialité : Comment le Web Service traite les données de tel sorte que les parties autorisées puissent leurs accéder ou les modifier. Cryptage des données : Comment le Web Service crypte ces données. Attributs de QoS liés au coût Coût : l attribut coût permet de spécifier le coût impliqué par l invocation du service. La figure 5.6 est un aperçu du code de l ontologie de QoS développée, la totalité du code est présentée dans l annexe B. <owl :Class rdf :ID="Avaibility"> <rdfs :subclassof> <owl :Class rdf :ID="DomaineDependante"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :about="#domainedependante"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="ResponceTime"> <rdfs :subclassof> <owl :Class rdf :about="#domainedependante"/> </rdfs :subclassof> </owl :Class> Fig. 5.6 Aperçu du code de l ontologie de QoS Ontologie de dispositif Aujourd hui, l utilisateur peut accéder aux services Web par l intermédiaire d un PC, d un ordinateur portable, d un téléphone WAP, d un PDA, etc. Afin d adapter l information diffusée par le service Web aux capacités du dispositif utilisé, nous 70

72 proposons une ontologie de description de dispositif. Cette ontologie procure un vocabulaire commun aux fournisseurs de services pour décrire les différents types de dispositifs pouvant supporter les données transmises par leurs services Web. Elle est formée de trois classes ; la classe de description du dispositif, la classe hardware et la classe software. La classe de description du dispositif fournit l information de base sur l appareil de connexion tel que le type, le modèle et le nom du fabricant, etc. La classe software définit le type et la version du système d exploitaion et du navigateur utilisés respectivement. La classe Hardware définit la taille et la résolution de l écran du dispositif ainsi que le type d affichage (couleur ou non). La figure 5.8 est un aperçu du code de l ontologie de dispositif développée, la totalité du code est présentée dans l annexe C. Dispositif Description Dispositif Description Hardware Description Software Constructeur Modèle Affichage Système exploitation Navigateur Ecran Résolution Taille Couleur Fig. 5.7 Ontologie de description de dispositifs <owl :Class rdf :ID="Device"> <rdfs :label>device</rdfs :label> <rdfs :subclassof rdf :resource="http ://exemple.com/ontologies/ context-discovery/location#thinghaslocationcontext" /> </owl :Class> <owl :Class rdf :ID="DeviceHasSoftwareParameters"> <rdfs :label> DeviceHasSoftwareParameters </rdfs :label> <rdfs :subclassof rdf :resource="#device" /> </owl :Class> <owl :Class rdf :ID="DeviceHasHardwareParameters"> <rdfs :label> DeviceHasHardwareParameters </rdfs :label> <rdfs :subclassof rdf :resource="#device" /> </owl :Class> Fig. 5.8 Aperçu du code de l ontologie de dispositif proposée 71

73 5.3 Conclusion La classe ServiceProfile de l ontologie OWL-S fournit les informations nécessaires à la découverte des services Web sémantiques. Cependant, lors de la découverte d autres informations doivent être prises en considération. Ces informations concernent le contexte de l utilisateur et celui du service Web. Dans ce chapitre nous avons proposé un modèle de représentation du contexte de l utilisateur. Ce modèle est basé sur l ontologie OWL. De plus, nous avons fait deux extensions au niveau de la classe ServiceParameter de l ontologie OWL-S ; la première consiste en un ensemble de paramètres de Qos de l ontologie de QoS que nous avons définit. Cette ontologie permet au providers de services de définir les QoS de leurs services Web avec un même vocabulaire. La seconde extension consiste en un ensemble de paramètres de description du dispositif pouvant traduire les données transmises par le service Web, ces paramètres sont définis dans l ontologie de description de dispositif proposée. 72

74 Chapitre 6 L architecture de découverte basée sur le contexte 6.1 Introduction Nous avons vu dans le chapitre précédant les différentes ontologies proposées ; ontologie du contexte de l utilisateur, ontologie de qualités de service (QoS) et ontologie de dispositif. Ces ontologies permettent le partage d un vocabulaire commun pour la représentation des données relatives aux deux entités utilisateur et services Web. Dans ce chapitre nous présenterons notre architecture pour la découverte de services Web sémantiques utilisant les ontologies. Plus précisément, nous nous baserons sur la prise en compte du contexte de l utilisateur et du service Web lors du processus de découverte afin d offrir à l utilisateur des services Web dont le contexte est adéquat avec le sien. 6.2 Architecture de découverte proposée L architecture proposée est une extension de l architecture orientée services SOA (Service Oriented Architecture). Dans l architecture SOA un service Web est offert par un fournisseur de service qui publie la description de son service Web dans un registre d enregistrements construit à cet effet. Généralement, les fournisseurs de service utilisent UDDI comme répertoire d enregistrements. La description du service Web est effectuée par le langage de définition WSDL. Lorsqu un utilisateur cherche un service Web, il utilise le même répertoire UDDI. L utilisateur prend connaissance des services disponibles dans UDDI grâce aux dé- 73

75 finitions WSDL diffusées par les fournisseurs de service. Dès qu un service Web est choisi par l utilisateur, le lien entre ces deux entités est établi par l intermédiaire du langage SOAP. Fournisseur de service 1. Publie 3.Intéraction Registre des descriptions des services Web (UDDI) 2. Découvre Utilisateur Fig. 6.1 Architecture Orientée Services Notre travail met en évidence le manque de prise en compte de l utilisateur et de son contexte ainsi que le contexte des services Web lors du processus de découverte de services Web dans l architecture SOA. Notre but est de faire en sorte que l utilisateur puisse avoir comme résultat un service Web qui répond à son contexte. En d autres termes, le service retourné par le système proposé doit pouvoir répondre à l objectif de l utilisateur tout en étant en adéquation avec les diverses caractéristiques qui constituent son contexte. Avant de présenter notre architecture il est nécessaire de rappeler que dans SOA les descriptions des services Web ne sont faites qu au niveau syntaxique. Dans l architecture que nous avons proposé les services Web sont décrits sémantiquement via la classe ServiceProfil de l ontologie OWL-S, laquelle a été étendue par des paramètres pour la prise en compte du contexte du service Web (paragraphe 5.2.2). Le système proposé est un Système Multi Agents (SMA)[52]. Notre intérêt pour les agents est dû à plusieurs raisons : - Ils s adaptent bien à la réalité dans la mesure où de nombreux problèmes sont de nature distribuée. - L utilisation de nombreux agents résolvant le problème de façon différente produit généralement des solutions de meilleure qualité en terme de complétude et de 74

76 précision. - Ils permettent d intégrer des connaissances diverses et complexes adoptant des formalismes hétérogènes. - Ils permettent de résoudre des problèmes de taille et de complexité telle qu il n est pas réaliste d essayer de les résoudre avec un seul agent. - Efficacité : les agents peuvent fonctionner en parallèle lorsque l environnement matériel et logiciel le permet. Ceci augmente par conséquence la rapidité de la résolution. - Réutilisabilité : un agent peut être réutilisé pour implanter une partie d un système. - Fiabilité : les SMA sont capables de mieux fonctionner dans un environnement dégradé qu un système mono agent. L arrêt de fonctionnement d un agent n influe pas sur l arrêt de la résolution. - Modularité : partitionner un système en N agents (sous systèmes) réduit sa complexité par un facteur parfois plus grand que N, et la configuration résultante se trouve plus facile à développer et à tester Les agents et leurs rôles Le système proposé est basé sur cinq différents agents. Agent Service Web Cet agent sert d interface entre le système et le fournisseur du service Web, tel que pour chaque service Web un agent lui est assigné de façon automatique. L agent Service Web permet l enregistrement de la description sémantique relative au service Web. De plus, il permet des mises à jour automatiques des informations relatives au service Web. Agent Vérificateur Le rôle de cet agent est de vérifier l authenticité des informations relatives au service Web en terme de qualité de service (QoS), car il se peut qu un fournisseur de service malhonnête puisse publier des QoS falsifiées afin d augmenter ses chances d être sélectionné. Les attributs QoS considérés sont Disponibilité(D) et Temps de Réponse(TR). Ces deux paramètres sont vérifiés comme suit : pour l attribut Disponibilité l Agent Vérificateur envoie des messages de test (beacon) au service Web pendant une période de temps T3. On a alors : D = T1/T3 D = T1 / (T1 + T2) tel que : 75

77 T1 : est le temps total pendant lequel le service Web a été actif (message beacon reçu) durant la période mesurée. T2 : est le temps total pendant lequel le service Web a été inactif (message beacon non reçu) durant la période mesurée. T3 : est le temps mesuré total, il est la somme de T1 et T2. Pour l attribut Temps de Réponse (TR) l agent Vérificateur envoie une requête au service Web, l instant de l envoie de la requête est déterminé par T4, le temps écoulé entre l envoie de la requête et la réception de la réponse est T5. Le Temps de Réponse est alors donnée comme suit : TR = T5 - T4. A la fin de la procédure de vérification des QoS, l agent vérificateur attribue un identificateur unique au service Web testé. Cet identificateur est ensuite stocké dans une base de données pour services Web certifiés en plus des certaines informations sur le service Web. Un certificat d authenticité des QoS est délivré pour chaque service Web testé. Agent Enregistreur Le rôle de l agent enregistreur est de sauvegarder les descriptions sémantiques des services Web au niveau du registre UDDI. Agent Utilisateur Cet agent sert d interface entre l utilisateur et le système. L Agent Utilisateur récupère la requête introduite par l utilisateur en terme de paramètres fonctionnels (entrée et sortie) et paramètres de QoS désirés. De plus, il permet de supplémenter la requête de l utilisateur par d autres informations qui sont relatives à son contexte tel que le dispositif utilisé et sa localisation. Ces informations sont récupérées de façon automatique du dispositif de l utilisateur. Agent Découverte Le rôle de cet agent est la découverte des descriptions des services Web satisfaisant la requête envoyée par l agent utilisateur sur le plan sémantique et contextuelle Communication entre Agents La communication entre les agents dans le système est faite par envoi de messages. La communication par envoi de message permet aux agents de se partager la charge d un problème en se distribuant des sous problèmes. Ce modèle de communication permet également aux agents de raisonner par la donnée, en se partageant des 76

78 connaissances ou des résultats. A son besoin un agent entre en communication directe avec un autre agent qu il connaît en lui transmettant des messages. Ces derniers peuvent contenir des demandes de renseignement ou l envoi d informations suite à une demande antérieure. La structure générale d un message envoyé entre deux agents contient plusieurs champs tel que chaque champ comprend une donnée spécifique. La structure d un message est la suivante : Numéro : contient le numéro du message Expéditeur : identifie l agent qui envoie le message Destinataire : indique l agent destinataire Type : indique le type du message (requête, information, réponse) Cas d échec : l action à effectuer en cas d erreur de message Condition : condition de traitement du message Etat : traité ou non Diffusion : point à point Contenu : corps du message Résultat attendue : résultat envoyé 6.3 Protocole d enregistrement des descriptions sémantiques des services Web Dans l architecture proposée un fournisseur de service annonce son service Web en publiant le ServiceProfil d une description OWL-S. Dans cette description d autres paramètres non fonctionnels (paramètres de QoS, localisation, dispositifs supportant les données transmises par le service) sont introduits. Une des caractéristiques qui fait la différence entre un service Web et un autre est la qualité de service. Un service Web ayant des QoS meilleurs sera favorisé sur un autre. Cependant on peut imaginer qu un fournisseur de service malveillant puisse publier des QoS falsifiées afin d augmenter ses chances d être sélectionné. Pour garantir l authenticité des QoS déclarées par le fournisseur, une procédure de vérification est effectuée avant l enregistrement de la description du service Web. Pour Chaque service Web un Agent Service Web lui est assigné. L Agent Service Web communique les données QoS du service Web qu il représente à l Agent Vérificateur. Ce dernier authentifie les informations QoS envoyées, si les données sont authentiques un identificateur unique est assigné au service Web certifié. De plus, l Agent Vérificateur délivre un certificat d authentification des données QoS à l Agent Service Web. Une copie du certificat délivré est enregistrée dans une base de données de services Web certifiés ainsi que leurs identificateur. L Agent Service Web utilise le certificat d authenticité pour enregistrer la descrip- 77

79 Fournisseur de service (serviceweb) Utilisateur Agent Service Web Ontologies Agent Utilisateur Agent Vérificateur Agent Enregistreur Agent Découverte Registre des services Web certifiés QoS Registre des descriptions des services Web (UDDI) Fig. 6.2 Architecture multi agents proposée tion OWL-S dans UDDI. Avant que la description soit réellement enregistrée dans UDDI, l Agent Enregistreur entre en communication avec l Agent Vérificateur afin de vérifier l existence du certificat délivré a l Agent Service Web, si le certificat existe, alors la description est enregistrée. La figure 6.3 représente le diagramme des séquences du protocole de publication des descriptions des services Web dans le système que nous avons proposé. 78

80 Fournisseur (Service Web) Agent Service Web Agent Enregistreur Agent Vérificateur BD services Web certifiés UDDI 1.Enregistrement description service Web 2.Requête de certification des QoS 3. Vérification des QoS 4.Résultats vérification 6. Envoi du certificat 5. Enregistrement ID + certificat 7. Description service Web plus certificat QoS 8. Vérification du certificat 9. Confirmation 10. Enregistrement de la description du service Web 12.Notification d'enregistrement 11. Notification Fig. 6.3 Protocole de publication des descriptions des services Web 6.4 Découverte de services Web sématiques basée sur le contexte Dans l approche proposée la découverte de services Web sémantiques est faite en deux étapes. La première est la recherche des descriptions sémantiques des services Web satisfaisant la requête de l utilisateur en terme de paramètres fonctionnels (Entrées, Sorties) [50]. La seconde étape consiste à sélectionner les services Web issus de l étape de recherche, selon les paramètres du contexte (QoS, localisation, type de dispositif de l utilisateur). L utilisateur introduit sa requête en termes de paramètres d Entrées/ Sorties du service Web voulus et des paramètres de QoS via l interface du système. La localisation de l utilisateur et les paramètres du dispositif utilisé sont ajoutés automatiquement à la requête Etape 1 : Recherche sémantique Au début de l étape de recherche, l Agent Découverte initialise le système de raisonnement avec les ontologies du domaine lesquelles seront utilisées pour calculer le degré de correspondance sémantique entre les concepts mentionnés dans paramètres d entreé et sortie mentionnés dans la requête et ceux des services Web. L Agent Utilisateur transmet à l Agent Découverte la requête de recherche. Une 79

81 fois la requête reçue, l Agent Découverte transmet les paramètres d entrée et sortie au système de raisonnement. Cette requête est traitée par application de l algorithme Matchmaking [29]. Cet algorithme permet de calculer le degré de correspondance entre les paramètres fonctionnels des services Web avec ceux réclamés par l utilisateur. Le résultat est un ensemble de services Web satisfaisant la requête de l utilisateur en terme d Entrées et Sorties Etape 2 : Sélection selon le contexte Après avoir déterminé l ensemble des services Web satisfaisant la requête de l Agent Découverte en termes de paramètres fonctionnels l étape suivante consiste à filtrer cet ensemble en sélectionnant les services Web dont les paramètres du contexte (QoS, localisation et type de dispositif) sont adéquats avec ceux déterminés dans la requête de l utilisateur. La sélection contextuelle est faite en trois phases : Phase A : sélection selon le contexte localisation de l utilisateur, Phase B : sélection selon les QoS voulues par l utilisateur, Phase C : sélection selon le type de dispositif. Phase A- Sélection selon le contexte localisation de l utilisateur Avec l utilisation des dispositifs mobiles et la restriction d usage géographique des services Web, la localisation de l utilisateur est devenue un paramètre important à considérer lors de la sélection des services Web. Pour ce fait, supposons que le dispositif de connexion de l utilisateur comprend un service qui donne la localisation de l utilisateur de manière périodique grâce au système GPS. Lors de l interaction de l utilisateur avec le système de découverte proposé l agent interface récupère la localisation de l utilisateur de façon automatique. Dans le cas où le service de localisation n est pas disponible au niveau du dispositif, l agent interface demande à l utilisateur d introduire sa localisation via l interface utilisateur du système. L information localisation est ensuite envoyée par l agent Interface à l agent Découverte via la requête de l utilisateur. En se basant sur l ontologie de localisation relative à un pays donné ou une région donnée, l agent Découverte peut inférer d autres informations sur la localisation de l utilisateur, tel que la région, la ville, etc. Ayant la localisation de l utilisateur, l agent Découverte parcoure l ontologie de localisation afin de sélectionner les services Web disponibles dans la périphérie de l utilisateur. Cette sélection est faite sur la base de l algorithme ci-après. 80

82 Algorithm 1 : Sélection basée Localisation des services Web sémantiques Entrée: User.Loc, OntoLoc, SW S = {SW S 1, SW S 2,..., SW S N } Sortie: LSW S 1: LSW S = Ø, j = 1 2: Tant que j N faire 3: si User.Loc = SW S j.loc alors 4: LSW S = LSW S {SW S j } 5: sinon 6: si User.Loc = getchildrenclass(sw S j.loc, OntoLoc) alors 7: LSW S = LSW S {SW S j } 8: sinon 9: LSW S = LSW S 10: fin si 11: fin si 12: j = j : fin Tant que 14: Afficher LSW S L algorithme admet comme entrées la localisation de l utilisateur (User.Loc), l ontologie de localisation (OntoLoc) et l ensemble des services Web sémantiques issus de l étape de recherche sémantique (SWS). Le résultat est un ensemble de services Web sémantiques (LSWS) offrant leur service dans la périphérie de l utilisateur. Par exemple, dans la ligne 3 de l algorithme, si la localisation de l utilisateur correspond à celle du service Web ce dernier sera sélectionné. Dans le cas contraire, ligne 6, l algorithme parcoure l ensemble des sous classes de l ontologie localisation à partir de la classe représentant la localisation du service Web grâce à la fonction getchildren- Class, si une des sous classes correspond à celle de la localisation de l utilisateur ce service Web sera sélectionné sinon le service Web n est pas sélectionné. A la fin on a un ensemble de services Web satisfaisant la contrainte de localisation. Phase B- Sélection selon les qualités de services (QoS) Cette phase consiste à raffiner encore plus l ensemble des services Web en faisant une sélection basée sur les préférences de l utilisateur en terme de QoS par application de l algorithme 2. L ensemble A représente l ensemble des Attributs de QoS réclamés par l utilisateur, tel que pour chaque attribut QosAt i (1 i m) un poids (P d i ) lui est assigné. SWS est l ensemble des m services Web résultas de l étape de sélection basée localisation. Après application de la fonction de score f(sws j ) sur chque service Web de l ensemble SWS, si f(sws j ) U seuil alors SW j est sélectionné. V (Q ij ) représente la valeur du i eme attribut de QoS du j eme service Web tel que 1 j m. 81

83 Algorithm 2 : Sélection basée QoS des services Web sémantiques Entrée: A = {QoSAt 1, QoSAt 2,..., QoSAt n}, SW S = {sws 1, sws 2,..., sws m}, P oids = {P d 1, P d 2,..., P d n}, U seuil Sortie: Sel Resultat 1: Sel Resultat = Ø, j = 1 2: Tant que j m faire n 3: f(sws j ) = V (Q ij ) P d i i=1 4: si f(sws j ) U seuil alors 5: Sel Resultat = Sel Resultat {sws j } 6: sinon 7: Sel Resultat = Sel Resultat 8: fin si 9: j = j : fin Tant que 11: Afficher Sel Resultat Phase C- Sélection selon le type de dispositif La dernière phase consiste à sélectionner les services Web qui s adaptent au type de dispositif de l utilisateur. Chaque description de service Web inclut les types de dispositifs supportés par ce dernier. La description du type de dispositif est réalisée selon l ontologie de dispositif définie dans le chapitre précédant. Sur la base des informations du type de dispositif de l utilisateur l Agent Découverte sélectionne les services Web capables d adapter les résultats transmis aux caractéristiques du dispositif utilisé. A la fin on a un ensemble de services Web classés selon le degré de correspondance sémantique et dont le contexte (localisation, QoS, type de dispositif) est adéquat avec celui de l utilisateur. 82

84 Utilisateur Agent Utilisateur Service Web Agent Découverte Système de raisonnement 1.Requête de découverte (E/S, QoS) 2. Requête (E/S, Localisation, QoS, Type Dispositif) 3.Requête en terme de E/S 4.Résultat 5.Sélection selon Localisation QoS et type de dispositif 7.Résultat 6.Résultat (ensemble services Web) 8.Communication 9.Réponse Fig. 6.4 Protocole de découverte de services Web sémantiques basée contexte 6.5 Implémentation Le développement de l architecture proposée est fait en cinq étapes principales : Développement des ontologies proposées Développement de l interface de publication des descriptions sémantiques OWL- S et du registre UDDI Développement de l interface Utilisateur pour la découverte de services Web Développement et déploiement du système multi agents ainsi que le système de raisonnement RACER Tests de vérification afin de s assurer du fonctionnement cohérent de l ensemble du système Technologies d implémentation Quatre types de technologies ont été choisis pour l implémentation de l architecture : 83

85 technologies de développement des ontologies technologie de développement des systèmes agents technologie de raisonnement sémantique technologie pour l implémentation du registre des descriptions OWL-S des services Web et la base des données des services Web certifiés. Technologie de développement des ontologies Les différentes ontologies que nous avons proposées sont réalisées grâce à l éditeur d ontologies Protégé Cet éditeur permet de construire une ontologie pour un domaine donné, de définir des formulaires d entrée de données et d acquérir des données à l aide de ces formulaires sous forme d instances de cette ontologie. Protégé est également une librairie Java qui peut être étendue pour créer de véritables applications à bases de connaissances en utilisant un moteur d inférence pour raisonner et déduire de nouveaux faits par application de règles d inférence aux instances de l ontologie et à l ontologie elle même (méta-raisonnement). Dans le contexte du Web sémantique des plugin pour les langages RDF, DAML+OIL et OWL ont été développés pour l éditeur Protégé. Ces plugin permettent d utiliser Protégé comme éditeur d ontologies pour ces différents langages. Technologie de développement des systèmes agents L outil choisi pour l implémentation du système multi agents est DAMS Builder (Distributed Multi-Agents System Builder). DAMS Builder 2 est un outil de programmation de systèmes multi agents basé sur le langage Java. DAMS Builder peut être divisé en deux modules principaux : l environnement de développement et la librairie de classes pour le support à la programmation Orienté Agent. Similaire aux environnements de développement d applications (JBuilder, Visual- Cafe ou autres), DAMS Builder est un utilitaire graphique permettant le développement d applications Java standards et / ou des systèmes à base d agents en Java totalement distribués. Développé à l Université du Québec à Trois-Rivières par Garneau et Delisle, DAMS Builder offre un meilleur système de développement d agents comparé aux systèmes existants tel que JADE 3, AgentTool 4, AgentBuilder 5, etc. 1 http ://protege.stanford.edu/ 2 http :// 3 http ://jade.tilab.com/ 4 http ://macr.cis.ksu.edu/projects/agenttool/agentool.htm 5 http :// 84

86 DAMS Builder permet : De simplifier et d accélérer le développement des systèmes multi agents totalement distribués et complexe. Une bonne extensibilité du code. La création d applications indépendantes de l environnement. Le déploiement simple. La spécification, via des interfaces, des différents sous-systèmes et de leurs agents et bases de connaissances ainsi que les modes de communication entre les différentes machines et autres. Le développement Orienté Agent grâce à la librairie de classes Orienté Agent (environ 200 classes) intégrée. La génération complète du code source des composants du système. L archivage des différents sous-systèmes et la création d un exécutable pour chaque sous systèmes. Ceci permet un déploiement extrêmement simple d applications totalement distribuées. L exécution de l environnement sur différentes plates-formes (Windows, Unix, Linux, etc.) sans aucune modification. L exécution des sous-systèmes (fichier exécutable.jar) sur les différentes plate formes (Windows, Unix, Linux, etc.) sans aucune modification. L outil DAMS Builder est implémenté en Java. Technologie du raisonnement sémantique L outil de raisonnement choisi est le raisonneur RACER (Renamed A-box and Concept Expression Reasoner). RACER 6 est un outil de raisonnement basé sur la logique de description. Il permet le raisonnement sur des ontologies OWL tel que la consistance des descriptions de classes et le calcul du niveau de correspondance entre classes. Technologie d implémentation des bases de données Pour l implantation du registre des descriptions des services Web et des services certifiés, nous avons choisi le système de base de données MySQL 7, un système de base de données doté d un serveur relativement performant et disposant d un driver JDBC qui prend en charge la compatibilité avec les applications Java. MySQL est un SGBD disponible en distribution open-source. 6 http :// r.f.moeller/racer/ 7 http :// 85

87 6.6 Développement des ontologies Les différentes ontologies proposées sont basées sur le langage OWL[38]. Notre choix pour OWL est dû pour trois raisons : 1) Comparé à d autres langages d ontologie tels que RDFS, OWL est plus expressif, 2) OWL permet l interopérabilité sémantique, 3) OWL a été choisi plutôt que DAML+OIL, puisque DAML+OIL est la version ultérieure de OWL, de plus OWL est une norme W3C. Le développement de ces ontologies a été réalisé en utilisant l éditeur Protégé Le code source des différentes ontologies développées est en annexe(s) de ce mémoire. 6.7 Développement de la partie publication des services Web Cette partie de l architecture consiste à intégrer un système développé à l institut de robotique de l université de Carnegie Mellon 8. Appelé OWL-S/UDDI Matchmaker, ce système est composé d une interface pour la publication des profils OWL-S des services Web, d une implémentation du registre UDDI pouvant sauvegarder les descriptions sémantiques des services. Pour permettre une recherche sémantique au niveau du registre, le serveur UDDI intègre le moteur de raisonnement RACER. RA- CER permet de calculer le niveau de correspondance sémantique entre la requête d utilisateur et les descriptions des services en terme d entrées attendus et sorties produits en sorties en se basant sur l algorithme du Matchmaking [44] Interface de publication L interface de publication permet aux fournisseurs de services de construire des descriptions OWL-S de leurs services. Ces descriptions sont ensuite soumises au registre UDDI. Pour pouvoir enregistrer une description OWL-S dans UDDI une mise en correspondance doit être faite entre les champs de la description OWL-S et ceux du registre UDDI. Cette mise en correspondance est réalisée en utilisant un script Javascript au niveau du navigateur client. L interface permet de publier le profil OWL-S d un service Web via plusieurs champs. Ces champs sont organisés selon le type d information qu ils fournissent. En général, sept types d informations constituent le ServiceProfil d une description OWL-S d un service. Ces informations sont : les informations sur le service, les informations de contact du fournisseur du service, les ontologies à importer pour définir les classes utilisées pour décrire les caractéristiques fonctionnelles du service, les paramètres d entrées attendus par le service, les paramètres de sorties produits par le 8 http :// 86

88 service, la catégorie du service et enfin les paramètres optionnels du service. Fig. 6.5 Interface de publication des descriptions des service Web Information sur le service Cette partie de la description permet d introduire des informations sur le service via trois champs : Nom du service : permet d introduire le nom du service Web Description textuelle : ce champ est réservé pour introduire une courte description du service. Cette description est généralement destinée aux humains Processus du service : ce champ est réservé à l url du processus qui représente le service. Informations de contact Cette section de la description permet d introduire les informations de contact relatives au fournisseur de service tel que le nom du fournisseur, adresse mail, url du 87

89 site Web du fournisseur, fax, etc. Ontologies importées En définissant les fonctionnalités du service il est nécessaire de définir les classes d ontologies utilisées. Pour ce fait, un champ permet d indiquer les URLs des ontologies des classes utilisées afin de les importer. Ce champ est très important, car il permet de spécifier les ontologies (ontologie de qualités de service et ontologie de dispositif) que nous avons développées et utilisées pour définir les paramètres de qualités de service et des types de dispositifs supportés par le service Web introduit au niveau de la classe ServiceParamater. Entrées attendues par le service Web Cette partie permet de spécifier les entrées du service Web. Elle est constituée de deux champs : Nom du paramètre : ce champ indique le nom du paramètre d entrée Type du paramètre : permet d indiquer le type (la classe OWL) du paramètre d entrée. Résultats produits en sorties Cette partie permet de spécifier les résultats produits en sorties par le service Web. Elle est constituée de deux champs : Nom du paramètre : ce champ indique le nom du paramètre de sortie Type du paramètre : permet d indiquer le type (la classe OWL) du paramètre de sortie. Catégorie du service Cette partie permet au fournisseur de spécifier la catégorie du service sur la base de taxonomie. Paramètres optionnels du service Cette partie de la description permet de spécifier les paramètres optionnels du service. Ainsi les extensions proposées en termes de paramètres de qualités de service et de type de dispositif peuvent être faites au niveau de cette partie de la description. Pour définir un paramètre optionnels il suffit d introduire le nom du paramètre dans 88

90 un champ dédié à cet effet et de spécifier la valeur de ce paramètre dans l ontologie dans laquelle il est défini. Dans notre cas les paramètres de qualités de service et de type de dispositif revoient vers les deux ontologies proposées respectivement Registre UDDI Dans notre architecture les descriptions des services Web sont sauvegardées dans le registre JUDDI 9. JUDDI est un registre open source implémenté en Java pour représenter le registre UDDI. Il est caractérisé par son indépendance aux plateformes. JUDDI peut être utilisé avec n importe quelle base de donnée relationnelle supportant le standard ANSI SQL comme par exemple : MySQL, JDataStore, etc. Dans notre cas JUDDI est utilisé avec MySQL. 6.8 Conclusion Dans ce chapitre nous avons présenté notre architecture multi agents pour la découverte des services Web sémantiques basée sur le contexte. La recherche sémantique des services est faite par application de l algorithme du Matchmaking. La sélection des services est basée sur le contexte de localisation, de qualité de service des services Web et paramètres du dispositif utilisateur décrits dans des ontologies. A ce stade, la partie de publication des descriptions des services Web est en cours de développement, les autres parties de l architecture font l objet d un projet de fin d étude. 9 http ://ws.apache.org/juddi 89

91 Chapitre 7 Conclusion et perspectives Les services Web sont la dernière technologie adoptée pour l intégration et l interopérabilité des systèmes répartis. Ils sont caractérisés par leurs indépendance aux plateformes 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équence l augmentation du nombre de services offerts. La découverte de services Web constitue un axe de recherches émergeant. Diverses approches ont été proposées. Ces approches sont passées d une recherche basée mots clés (correspondance syntaxique de la requête avec les descriptions des services Web) aux méthodes basées sémantique (degré de correspondance sémantique de la requête avec la sémantique des descriptions des services Web). Cependant, vu la diversité des utilisateurs et des conditions dans lesquelles ils accèdent aux services Web, d autres paramètres doivent être 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. Dans ce travail nous avons proposé de décrire les différents paramètres du contexte de l utilisateur et des services à travers les ontologies : du contexte de l utilisateur, de service Web, de qualités de service et de paramètres de dispositif. Ensuite, autour de ces ontologies, nous avons conçu une architecture à base d agents pour la découverte des services Web sémantiques basée sur le contexte. A court terme, nous allons implémenter notre proposition d architecture. Afin de valider notre travail, nous effectuerons des tests avec différents utilisateurs et un panel de services Web. A long terme, nous ferons des extensions à l architecture pour permettre la composition contextuelle des services Web. 90

92 Bibliographie [1] Gregory D. Abowd, Anind K. Dey, Peter J. Brown, Nigel Davies, Mark Smith, and Pete Steggles. Towards a better understanding of context and contextawareness. In HUC 99 : Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing, [2] Stanislaw Ambroszkiewicz. entish : An approach to service composition. In TES, pages , [3] H.McCabe-F.Newcomer E.Champion M.Ferris C.Orchard : Booth, D.Haas. Web services architecture. [4] Jean-Marie Chauvet. Services Web avec SOAP, WSDL, UDDI, ebxml..., chapter 5.Understanding the Resource Description Framework. Eyrolles, [5] R. Cost, T. Finin, A. Joshi, Y. Peng, C. Nicholas, H. Chen, L. Filip, P. Youyong, Z. Sovrin, and T. Ian. Ittalks : A case study in the semantic web and daml, [6] Christos Doulkeridis, Nikos Loutas, and Michalis Vazirgiannis. A system architecture for context-aware service discovery. In International Workshop on Context for Web Services CWS-05, [7] Casati Fabio and Ming chien Shan. Dynamic and adaptive composition of e- services. Inf. Syst., 26(3) : , [8] Bussler-C Fensel, D. The web service modeling framework wsmf. Eletronic Commerce : Research and Applications, 1 : , [9] Dieter Fensel, Ian Horrocks, Frank van Harmelen, Stefan Decker, Michael Erdmann, and Michel C. A. Klein. OIL in a nutshell. In Knowledge Acquisition, Modeling and Management, pages 1 16, [10] Ian Horrocks. DAML+OIL : A reason-able web ontology language. In Extending Database Technology, pages 2 13, [11] J.Chauvet. Services Web avec SOAP, WSDL, UDDI, ebxml..., chapter Communiquer : SOAP. Eyrolles, Mars [12] Woodrow C. Ohto H. Hjelm J. Butler M.H. Klyne G., Reynolds F. and Tran L. Composite capability/preference profiles (cc/pp) : Structure and vocabularies 1.0,

93 [13] Kouadri Mostéfaoui G. Kouadri Mostéfaoui, S. Towards a contextualisation of service discovery and composition for pervasive environments. In Workshop on Web Services and Agent Based engineering (WSABE 2003), [14] Michel Leblanc. Les web services et leur impact sur le commerce b2b. Master s thesis, CIRANO : Centre Interuniversitaire de Recherche en Analyse des Organisations, Août [15] Todd A. Letsche and Michael W. Berry. Large-scale information retrieval with latent semantic indexing. Information Sciences, 100(1-4) : , [16] Keidl M. and Kemper A. Toward context-aware adaptable web services. In 13th World Wide Web Conference (WWW), New York, USA, [17] C. Rey M-S. Hacid, A. Leger and F. Toumani. Dynamic discovery of e-services. Proceedings of BDA 02, [18] Mohamed Mahdi Malik. Le rôle de la logique floue dans le web semantique. Master s thesis, Statistiques Médicales et Epidémiologiques, Faculté de Médecine de la Timone, [19] David Martin and al. Owl-s : Semantic markup for web services. Technical report, W3C, [20] Kevin T. Smith Michael C. Daconta, Leo J. Obrst. The Semantic Web : A Guide to the Future of XML, Web Services, and Knowledge Management, chapter 4, Understanding Web Services. Wiley, John and Sons, Incorporated, June [21] Enrico Motta, John Domingue, Liliana Cabral, and Mauro Gaspari. Irs-2 : A framework and infrastructure for semantic web services. In International Semantic Web Conference, pages , [22] Miguel A. Munoz, Marcela Rodreguez, Jesus Favela, Ana I. Martinez-Garcia, and Victor M. Gonzalez. Context-aware mobile communication in hospitals. Computer, 36(9) :38 46, [23] Eric Newcomer. Understanding Web Services- XML, WSDL, SOAP and UDDI, chapter 3, Describing Web Services : WSDL. Addison Wesley Professional, May [24] Eric Newcomer. Understanding Web Services- XML, WSDL, SOAP and UDDI, chapter 4, Accessing Web Services : SOAP. Addison Wesley Professional, May [25] Eric Newcomer. Understanding Web Services- XML, WSDL, SOAP and UDDI, chapter 5, Finding Web Services : UDDI Registry. Addison Wesley Professional, May. [26] Crubezy-M. Fensel D. Benjamins R. Wielinga B. Motta E. Musen M. Omelayenko, B. Upml : The language and tool support for makiing the semantic web alive. Technical report, MIT,

94 [27] M. Ouzzani. Efficient Delivery of Web Services. PhD thesis, Virginia Polytechnic, USA, [28] Paul Palathingal and Sandeep Chandra. Agent approach for service discovery and utilization. In HICSS, [29] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, and Katia P. Sycara. Semantic matching of web services capabilities. In ISWC 02 : Proceedings of the First International Semantic Web Conference on The Semantic Web, pages , London, UK, Springer-Verlag. [30] Kollipara S. Pashtan A. and Pearce M. Adapting content for wireless web services. IEEE Internet Computing, 7(5), [31] Koul Neeraj Caragea Doina Pathak, Jyotishman and Vasant Honavar. Discovering web services over the semantic web. In 7th ACM International Workshop on Web Information and Data Management.,, Bremen, Germany, [32] Stanislav Pokraev, Johan Koolwaaij, and Martin Wibbels. Extending uddi with context-aware features based on semantic service descriptions. In ICWS, pages , [33] J.Miller M. Nagarajan M. Schmidt A. Sheth K. Verma R. Akkiraju, J. Farrell. Web service semantics : Wsdl-s. Technical report, IBM, [34] ressources Naturelles du Canada division des levés géodésiques. Guide pour le positionnement du gps. Technical report, Ministère des Ressources Naturelles du Canada, [35] Christophe Rey. Découverte dynamique de e-services. Symposium on the Effectiveness of Logic in Computer Sciences (ELICS02), [36] Pornpong Rompothong and Twittie Senivongse. A query federation of uddi registries. In ISICT 03 : Proceedings of the 1st international symposium on Information and communication technologies, pages Trinity College Dublin, [37] Atul Sajjanhar, Jingyu Hou, and Yanchun Zhang. Algorithm for web services matching. In APWeb, pages , [38] Jim Hendler Ian Horrocks Deborah L. McGuinness Peter F. Patel-Schneider Lynn Andrea Stein Sean Bechhofer, Frank van Harmelen. Owl web ontology language. Technical report, W3C, [39] Q. Z. Sheng and B. Benatallah. Contextuml : A uml-based modeling language for model-driven development of context-aware web services. In The 4th International Conference on Mobile Business (ICMB 05), [40] Kaarthik Sivashanmugam, Kunal Verma, Amit P. Sheth, and John A. Miller. Adding semantics to web services standards. In ICWS, pages , [41] Verma K. Mulye R. Zhong Z. Sivashanmugam, K. and A. : Sheth. Speed-r : Semantic p2p environment for diverse web service registries. 93

95 [42] Michael C. Daconta Leo J. Obrst Kevin T. Smith. The Semantic Web : A Guide to the Future of XML, Web Services, and Knowledge Management, chapter 5.Understanding the Resource Description Framework. Wiley Publ, [43] Michael C. Daconta Leo J. Obrst Kevin T. Smith. The Semantic Web : A Guide to the Future of XML, Web Services, and Knowledge Management, chapter 3.Understanding XML and It s Impact on the Enterprise. Wiley Publ, [44] Naveen Srinivasan, Massimo Paolucci, and Katia P. Sycara. An efficient algorithm for owl-s based semantic search in uddi. In SWSWPC, pages , [45] Thomas Strang and Claudia and Linnhoff-Popien. A context modeling survey. In Workshop Proceedings, First International Workshop on Advanced Context Modelling, Reasoning And Management at UbiComp, [46] Rudi Studer, Raphael Volz, Gerd Stumme, and Andreas Hotho. Semantic web - state of the art and future directions. KI Heft, Special Issue on the Semantic Web, [47] Haiyan Sun, Xiaodong Wang, Bin Zhou, and Peng Zou. Research and implementation of dynamic web services composition. In APPT, pages , [48] TuanAnh Ta. Web sémantique et portails. Master s thesis, ENST, [49] Gunnar Teege. Making the difference : A subtraction operation for description logics. In Jon Doyle, Erik Sandewall, and Pietro Torasso, editors, KR 94 : Principles of Knowledge Representation and Reasoning, pages Morgan Kaufmann, San Francisco, California, [50] G. Shercliff P. J. Stockreisser W. A. Gray V. Deora, J. Shao and N. J. Fiddian. Incorporating qos specifications in service discovery. In 2nd International Web Services Quality Workshop, LNCS 3307., [51] Le-Hung Vu, Manfred Hauswirth, and Karl Aberer. Towards p2p-based semantic web service discovery with qos support. In Business Process Management Workshops, pages 18 31, [52] Michael Wooldridge. An Introduction to MultiAgent Systems. Wiley, [53] Jian Yang and Mike P. Papazoglou. Service components for managing the lifecycle of service compositions. Inf. Syst., 29(2) :97 125,

96 Annexe A Ontologie du contexte de l utilisateur L ontologie du contexte de l utilisateur proposée a été développée via l éditeur d ontologies Protégé Le langage utilisé est OWL. Pour valider cette ontologie nous avons utilisé un outil de validation d ontologie WebOnto 2 disponible sur le Web. <?xml version="1.0"?> <rdf :RDF xmlns :protege="http ://protege.stanford.edu/plugins/owl/protege#" xmlns :rdf="http :// xmlns :rdfs="http :// xmlns :owl="http :// xmlns :daml="http :// xmlns :dc="http ://purl.org/dc/elements/1.1/" xmlns="http :// xml :base="http :// <owl :Ontology rdf :about=""> <owl :imports rdf :resource="http ://protege.stanford.edu/ plugins/owl/protege"/> </owl :Ontology> <owl :Class rdf :ID="User"/> <owl :Class rdf :ID="UserHasIdentity"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :Class rdf :ID="UserHasLocation"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :Class rdf :ID="QoSPreference"> <rdfs :subclassof> 1 http ://protege.stanford.edu/ 2 http ://phoebus.cs.man.ac.uk :9999/OWL/Validator 95

97 <owl :Class rdf :ID="UserHasPreferences"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="FName"> <rdfs :subclassof rdf :resource="#userhasidentity"/> </owl :Class> <owl :Class rdf :about="#userhaspreferences"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :Class rdf :ID="UserHasFonction"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :Class rdf :ID="LName"> <rdfs :subclassof rdf :resource="#userhasidentity"/> </owl :Class> <owl :Class rdf :ID="UserHasDevice"> <rdfs :subclassof rdf :resource="#user"/> </owl :Class> <owl :DatatypeProperty rdf :ID="Ycoordinate"> <rdfs :domain rdf :resource="#userhaslocation"/> <rdfs :range rdf :resource="http :// </owl :DatatypeProperty> <owl :DatatypeProperty rdf :ID="lastName"> <rdfs :range rdf :resource="http :// <rdfs :domain rdf :resource="#lname"/» </owl :DatatypeProperty> <owl :DatatypeProperty rdf :ID="Userfonction"> <rdfs :domain rdf :resource="#userhasfonction"/> <rdfs :range rdf :resource="http :// </owl :DatatypeProperty> <owl :DatatypeProperty rdf :ID="Xcoordinate"> <rdfs :domain rdf :resource="#userhaslocation"/> <rdfs :range rdf :resource="http :// </owl :DatatypeProperty> <owl :DatatypeProperty rdf :ID="firstName"> <rdfs :domain rdf :resource="#fname"/> <rdfs :range rdf :resource="http :// </owl :DatatypeProperty> </rdf :RDF> 96

98 Annexe B Ontologie de Qualité de Services (QoS) L ontologie de Qualité de Service (QoS) proposée a été développée via l éditeur d ontologies Protégé Le langage utilisé est OWL. Pour valider cette ontologie nous avons utilisé un outil de validation d ontologie WebOnto 2 disponible sur le Web. <?xml version="1.0"?> <rdf :RDF xmlns :protege="http ://protege.stanford.edu/plugins/owl/protege#" xmlns :rdf="http :// xmlns="http :// xmlns :xsd="http :// xmlns :rdfs="http :// xmlns :owl="http :// xml :base="http :// <owl :Ontology rdf :about=""> <owl :imports rdf :resource="http ://protege.stanford.edu/ plugins/owl/protege"/> </owl :Ontology> <owl :Class rdf :ID="Avaibility"> <rdfs :subclassof> <owl :Class rdf :ID="DomaineDependante"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="QoS"/> <owl :Class rdf :ID="Price"> <rdfs :subclassof> 1 http ://protege.stanford.edu/ 2 http ://phoebus.cs.man.ac.uk :9999/OWL/Validator 97

99 <owl :Class rdf :about="#domainedependante"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="ResponceTime"> <rdfs :subclassof> <owl :Class rdf :about="#domainedependante"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="DomaineIdependante"> <rdfs :subclassof rdf :resource="#qos"/> </owl :Class> <owl :Class rdf :about="#domainedependante"> <rdfs :subclassof rdf :resource="#qos"/> </owl :Class> <owl :DatatypeProperty rdf :ID="Priceattribute"> <rdfs :domain rdf :resource="#price"/> <rdfs :range rdf :resource="http :// </owl :DatatypeProperty> <owl :DatatypeProperty rdf :ID="AvaibilityAttribut"> <rdfs :range rdf :resource="http :// <rdfs :domain rdf :resource="#avaibility"/> </owl :DatatypeProperty> <owl :DatatypeProperty rdf :ID="ResponceTimeAttribut"> <rdfs :domain rdf :resource="#responcetime"/> <rdfs :range rdf :resource="http :// </owl :DatatypeProperty> </rdf :RDF> 98

100 Annexe C Ontologie de type de dispositif L ontologie de dispositif proposée a été développée via l éditeur d ontologies Protégé Le langage utilisé est OWL. Pour valider cette ontologie nous avons utilisé un outil de validation d ontologie WebOnto 2 disponible sur le Web. <?xml version="1.0"?> <rdf :RDF xmlns="http :// xmlns :protege="http ://protege.stanford.edu/plugins/owl/protege#" xmlns :rdf="http :// xmlns :xsd="http :// xmlns :rdfs="http :// xmlns :owl="http :// xml :base="http :// <owl :Ontology rdf :about=""> <owl :imports rdf :resource="http ://protege.stanford.edu/ plugins/owl/protege"/> </owl :Ontology> <owl :Class rdf :ID="Vendor"> <rdfs :subclassof> <owl :Class rdf :ID="DeviceInfo"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="BrowserVersion"> <rdfs :subclassof> <owl :Class rdf :ID="SoftwarePrameters"/> </rdfs :subclassof> </owl :Class> 1 http ://protege.stanford.edu/ 2 http ://phoebus.cs.man.ac.uk :9999/OWL/Validator 99

101 <owl :Class rdf :ID="Screen"> <rdfs :subclassof> <owl :Class rdf :ID="HardwareParameters"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="DeviceModel"> <rdfs :subclassof> <owl :Class rdf :about="#deviceinfo"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="ScreenSize"> <rdfs :subclassof rdf :resource="#screen"/> </owl :Class> <owl :Class rdf :about="#deviceinfo"> <rdfs :subclassof> <owl :Class rdf :ID="Device"/> </rdfs :subclassof> </owl :Class> <owl :Class rdf :about="#hardwareparameters"> <rdfs :subclassof rdf :resource="#device"/> </owl :Class> <owl :Class rdf :about="#softwareprameters"> <rdfs :subclassof rdf :resource="#device"/> </owl :Class> <owl :Class rdf :ID="IsColor"> <rdfs :subclassof rdf :resource="#screen"/> </owl :Class> <owl :Class rdf :ID="OperatingSystem"> <rdfs :subclassof rdf :resource="#softwareprameters"/> </owl :Class> <owl :DatatypeProperty rdf :ID="ScrennColor"> <rdfs :range rdf :resource="http :// <rdfs :domain rdf :resource="#iscolor"/> </owl :DatatypeProperty> </rdf :RDF> 100

102 Annexe D Extensions apportées à OWL-S Le code source suivant présente les extensions apportées à l ontologie OWL-S. Ces extensions sont faites au niveau de la classe ServiceProfile sous forme de paramètres QoS et de paramètres du dispositif de connexion pouvant traiter les données transmises par le service Web. < Extension QoS > <owl :Class rdf :ID="Availability"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// /QoSOtology.owl#Availability"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="ResponceTime"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// QoSOtology.owl#ResponceTime"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> < Parametre de localisation du service > 101

103 <owl :Class rdf :ID="GeographicRadius"> <rdfs :subclassof rdf :resource="http :// Profile.owl#ServiceParameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="http :// Profile.owl#sParameter"/> <owl :allvaluesfrom rdf :resource="http :// Country.owl#Country"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> < Fin Parametre de localisation du service > < Parametres de dispositif > <owl :Class rdf :ID="SupportDeviceproductName"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// Device.owl#productName"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="DeviceScreenSize"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// Device.owl#ScreenSize"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="DeviceScreenIsColor"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> 102

104 <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// Device.owl#IsColor"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="DeviceOperatingSystemVersion"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// Device.owl#OperatingSystem"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> <owl :Class rdf :ID="DeviceBrowserVersion"> <rdfs :subclassof rdf :resource="#serviceparameter"/> <rdfs :subclassof> <owl :Restriction> <owl :onproperty rdf :resource="#sparameter"/> <owl :allvaluesfrom rdf :resource="http :// Device.owl#BrowserVersion"/> </owl :Restriction> </rdfs :subclassof> </owl :Class> < Fin Parametres de dispositif > 103