Registre de services Web pour le développement d applications Céline Lopez-Velasco Marlène Villanova-Oliver Jérôme Gensel Hervé Martin LIG Équipe STEAMER 681, rue de la passerelle BP 72, 38402 Saint Martin d Hères Cedex prénom.nom@imag.fr RÉSUMÉ. Les systèmes des organisations sont de plus en plus basés sur une architecture orientée services (AOS) puisque les services de base peuvent être réutilisés et partagés. Afin d adopter le concept d AOS les services Web sont principalement utilisés. Les standards de description (WSDL) et de communication (SOAP) de services Web étant éprouvés, seules des méthodes standard de recherche et de sélection tardent à émerger. Ces phases sont difficiles à réaliser puisque les registres existants (comme UDDI) ne fournissent pas de description de services enrichies et de méthodes de recherche puissantes. Cet article propose la description d un modèle de représentation de services qui, lors de la publication, apporte de nouvelles informations sur le service. Ces informations, ajoutées à WSDL, sont relatives au domaine d application du service, aux fournisseurs et au contexte d utilisation pour lequel le service est adapté. Nous avons implémenté un registre reposant sur ce modèle qui propose un moyen de faciliter la recherche et la sélection de services Web et d établir une recherche de services répondant aux besoins d une implémentation d une application particulière. ABSTRACT. Systems of organizations are more and more based on Service-Oriented Architecture (AOS) since the elementary services can be reused and shared. In order to adopt the AOS concept, the Web services are mainly used. The standards of description (WSDL) and communication (SOAP) of Web services being approved, only standard methods of search and selection are long in emerging. These processes are difficult to realize since existing registries (such as UDDI) do not provide an enriched description of services and powerful search methods. In this paper, we propose a model of services representation which, during the publication, brings new information about Web services. These information, added to WSDL, are relate to the application domain of the service, the providers and the use context for which the service is adapted. We have implemented a registry based on this model which proposes a way to facilitate the search and the selection of Web services and to establish a search of services which answer to needs of an implementation of a particular application. MOTS-CLÉS : Services Web, registre, interopérabilité, adaptation, contexte d utilisation. KEYWORDS: Web services, registry, interoperability, adaptation, use context.
1. Introduction L Architecture Orientée Service (AOS ou SOA Service Oriented Architecture en anglais) permet aux concepteurs de systèmes d entreprise d organiser un ensemble de logiciels isolés en un ensemble de services interconnectés, accessibles par une interface et des protocoles standard (Papazoglou, 2003). Le principal avantage de l utilisation de ce type d architecture est la réutilisation des services élémentaires (i.e. les services qui composent le système). Selon (Nickull et al., 2005), cette réutilisation repose sur le fait que chaque service utilisé dans un système basé sur une AOS doit être, au préalable, décrit par son concepteur. Afin d implémenter des systèmes basés sur une AOS, les concepteurs ont à leur disposition diverses technologies telles que les composants log iciels. Notre choix d implémentation se dirige intuitivement vers les services Web, étant intéressés par la mise à disposition des systèmes sur le Web. (Haas et al., 2004) définissent un service Web comme étant un logiciel conçu pour supporter l interaction entre machines interopérables à travers un réseau. Cette interopérabilité est rendue possible grâce à un langage (WSDL Web Service Description Language, Booth et al., 2006) et à un protocole (SOAP Simple Object Access Protocol, Mitra, 2003) standard. Le cycle de vie d un service Web est généralement composé de quatre étapes. i) Le fournisseur décrit le service Web qu il désire diffuser à l aide de WSDL ; ii) il le publie dans un annuaire de services Web ; iii) à l aide de cet annuaire, un client de services Web recherche et sélectionne les services dont il a besoin ; iv) la communication entre le client et le fournisseur (i.e. l appel proprement dit du service Web) s établit par l intermédiaire de SOAP. Aujourd hui, seuls WSDL et SOAP ont atteint une certaine maturité et sont devenus des standards du fait de leur large utilisation. En utilisant les registres existants (tels que les spécifications UDDI 1 Universal Description Discovery and Integration, ou le site XMethods 2 ), le processus de recherche repose sur l hypothèse que le client connaît au préalable des propriétés du service tels que son nom ou son fournisseur. À la suite de la recherche, le registre, quel qu il soit, retourne au client un ensemble de services Web. Le client procède alors à la sélection du service Web qu il juge le plus adéquat à ses besoins. En utilisant les registres existants, en particulier ceux relevant des spécifications UDDI, le processus de sélection se limite à l analyse de la description des services, basé essentiellement (si ce n est exclusivement) sur la description WSDL et, plus rarement, sur la description du fournisseur. Afin d améliorer les processus de recherche et de sélection, il serait intéressant d enrichir la description de services Web de métadonnées supplémentaires. Les méthodes de recherche de services en se basant sur de nouveaux critères seraient plus efficaces. De plus, la phase de sélection faite par les clients de services serait facilitée s ils avaient à leur disposition des 1 http://www.uddi.org/ 2 http://xmethods.com/
informations supplémentaires sur les services retrouvés. Lors de travaux précédents (Lopez-Velasco et al., 2006), nous avons enrichi la description de services Web en vue de représenter le contexte d utilisation pour lequel ils sont adaptés. Dans ce même travail, nous avons proposé un système multi-agents en charge de la sélection des services. Cependant ayant le souci d être générique, la description proposée s avère trop restrictive. Cette dernière vise uniquement l adaptation des services Web à un contexte d utilisation spécifique alors qu ici nous désirons prendre en compte des aspects plus larges en vue d implémenter n importe quelle application (adaptée ou non). Pour permettre aux fournisseurs de publier des services Web et aux clients de rechercher et sélectionner ces services dans un registre commun, nous proposons un modèle qui enrichit la description des services de métadonnées supplémentaires. Nous faisons l hypothèse que la recherche de services est faite dans le cadre d une conception d une application (i.e. les services retrouvés sont offerts par des fournisseurs externes et permettent la mise en œuvre de l application en cours de conception). C est pourquoi, nous confondons ici les termes de clients et concepteurs, qui ont pour but de rechercher et sélectionner des services. La formalisdation de ce modèle est la base de la mise en œuvre d un registre proposant les fonctionnalités de publication et de recherche de services Web. Dans cet article, nous mettons dans un premier temps en évidence les besoins d information en vue de représenter les services Web. La section 3 décrit le modèle de représentation de services Web issu de l étude des besoins. Dans la section 4, nous décrivons la mise en œuvre du registre de services Web en mettant en évidence les choix technologiques et les fonctionnalités proposées aux utilisateurs. Enfin, nous étudions les travaux voisins avant de conclure. 2. Évaluation des besoins en matière de représentation de services Web L objectif de notre travail est de faciliter pour les concepteurs, la mise en œuvre de systèmes à base de services Web. Par mise en œuvre, nous entendons essentiellement la publication de services Web développés, la recherche et la sélection de services Web existants. Nous considérons que les étapes de description et d invocation sont éprouvées étant basées sur les standards WSDL et SOAP. Il existe de nombreux registres de services Web tels que XMethods. Cependant, les méthodes de recherche (par exemple par mot-clé) et les descriptions de services ne suffisent pas à répondre à une attente rigoureuse de conception de systèmes. L étude faite des registres existants (tels que BindingPoint 3, RemoteMethods 4 ) nous a permis de mettre en évidence quatre catégories d information qui nous semblent indispensables en vue de faciliter la recherche et la sélection de services Web. 3 http://www.bindingpoint.com/default.aspx 4 http://www.remotemethods.com
Le service Afin de sélectionner un service, il est important de connaître les méthodes proposées, les paramètres d entrée et de sortie, le protocole à utiliser pour appeler le service et la localisation du service (son URL). WSDL permet de décrire ces informations. Le fournisseur et l information associée Nous pensons que la description du fournisseur est une information que le client doit connaître pour deux raisons. Tout d abord, cette description peut orienter et faciliter le choix du service lors du processus de sélection. En effet, la confiance accordée au fournisseur, le coût (en termes de droit d invocation), le temps de réponse du service, la confidentialité des informations transmises, etc., sont des informations qui peuvent intervenir dans les critères de choix. Ensuite, la description du fournisseur est intéressante à prendre en compte pour la maintenance du service. Si, lors de l exécution du service, un concepteur fait face à des problèmes, par exemple de connexion, si ce concepteur est en possession d informations sur le fournisseur, il peut alors prendre contact avec le responsable du service pour une assistance technique. Le domaine d application Un système couvre des fonctionnalités qui peuvent être exécutées par des services Web appartenant à un domaine d application, tel que la géomatique, du business-to-business ou du e-learning. Prenons l exemple d une conception d un Système d Information Géographique (SIG). Le domaine d application de ce système est la géomatique et les résultats de ce développement doit fournir à l utilisateur final un ensemble de tâches prédéterminées, telles que l affichage d une carte ou la visualisation d une adresse sur une carte. Si nous nous intéressons à la conception d un SIG à base de services Web, les différentes fonctionnalités à fournir dans le système sont autant de services Web à appeler (par conséquent à chercher, à sélectionner, et si besoin est, à développer). De ce fait, nous pensons qu il est nécessaire d intégrer à la description du service le domaine d application (par exemple la géomatique) dans lequel il peut intervenir et les fonctionnalités (par exemple, l affichage de cartes) qu il met en œuvre. Le contexte d utilisation Les développeurs doivent prendre en compte le plus tôt possible lors de la conception de systèmes le besoin d adaptation au contexte afin de répondre au mieux aux attentes des utilisateurs. Selon (Dey, 2001), le contexte est n importe quelle information qui peut être utilisée pour caractériser la situation d une entité. Dans ce travail, nous nous focalisons sur les éléments du contexte qui caractérisent l utilisation d un système, pouvant être détectés et utilisés par ce système afin d offrir un résultat adapté. Nous appelons cet ensemble d éléments le contexte d utilisation. Nous considérons quatre principaux éléments dans la description du contexte d utilisation : l utilisateur (droits d accès, activité, etc.), l information liée à la localisation (coordonnées GPS, température, etc.), le temps (heure, jour, mois, etc.) et les entités informatiques (caractéristiques logicielles et matérielles du dispositif, le réseau utilisé, etc.). Si les fournisseurs de services Web mettent à la disposition des clients une description du contexte d utilisation pour lequel le service est adapté, la recherche et la sélection peuvent être facilitées.
3. Modèle de représentation de services Web Les standards et spécifications (WSDL et UDDI) ne suffisent pas à décrire l ensemble de l information qu il nous semble important de prendre en compte lors de la publication, recherche et sélection de services Web : le service, le fournisseur, le domaine d application et le contexte d utilisation. C est pourquoi, nous proposons un modèle qui enrichit la description d un service en représentant chacune de ces catégories. Dans cette section, nous décrivons chaque partie de ce modèle (service, domaine d application, profil fonctionnel qui complète la description du service, profil non fonctionnel qui inclut la description du fournisseur, et contexte d utilisation) et les liens qui existent entre elles. 3.1. Description de chaque package du modèle de représentation de services Web Ce modèle enrichit la description des services lors de leur publication afin de faciliter les phases ultérieures de recherche et de sélection. Nous avons choisi ici de décrire le modèle par l intermédiaire du langage UML. Cinq packages UML composent le modèle (cf. Figure 6). Le package central (Service), relié à tous les autres packages, représente le service. Le package Application Domain permet de décrire le domaine associé au service représenté. Toutes les informations permettant aux concepteurs d utiliser le service sont intégrées dans le package Functional Profile. Le package Non Functional Profile rassemble les informations sur le service non directement liées à son utilisation, mais utiles lors du processus de sélection (par exemple, la description du fournisseur). Enfin, ce modèle intègre la description du contexte d utilisation dans le package Use Context, afin de mettre en œuvre l adaptation. Figure 1. Classes et associations du package Service. Le package Service comprend des informations élémentaires sur le service divisées en trois classes (cf. Figure 1). Les deux premières classes (ServiceCategory et ConcreteService) représentent n importe quel type de service (Web ou non) alors que la troisième classe (WebService) est spécifique à l utilisation de services Web. La classe ServiceCategory décrit la catégorie du service. Nous offrons la possibilité d exprimer des sous-catégories avec la relation de composition sur cette même classe. Une catégorie de service est associée à un service concret (association entre les classes ServiceCategory et ConcreteService). La classe ConcreteService représente le service publié par le fournisseur, est identifié par son nom (variable name) et doit appartenir au moins à une catégorie. Cette contrainte permet d ajouter
un niveau de sémantique à notre représentation (les services ne sont plus seulement identifiés par leur nom mais aussi par une catégorie). La troisième classe du package Service est celle spécifiant les services Web (WebService). Elle spécialise la classe ConcreteService et possède un variable (wsdlurl) qui permet aux clients de services Web de localiser la description standard du service Web (exprimée en WSDL). Prenons l exemple d un fournisseur qui souhaite publier un service Web nommé LocalizeMe qui propose un moyen de localiser un utilisateur. Ce service est une instance de la classe WebService et est associé à la catégorie Localisation (instance de la classe ServiceCategory). Le package Application Domain caractérise, au moyen de concepts, le système conçu (lors de la publication de service) ou à concevoir (lors de la recherche et sélection de services). Ce package est composé de trois classes (cf. Figure 2). La classe Domain décrit le domaine d application tel que les domaines de la géomatique, du travail collaboratif ou du e-learning. Dans ce modèle, nous associons à un domaine une ou plusieurs applications (classe Application) faisant référence ici à des applications de type logiciel. L association entre les classes Domain et Application permet de représenter l ensemble des applications pouvant intervenir dans un domaine donné. Par exemple, l application TomTom 5 (logiciel de navigation) peut être une instance de la classe Application et être associée à l instance géomatique de la classe Domain. Une application est développée à l aide de composants qui implémentent chacun une tâche (classe Task). Cette classe décrit les fonctionnalités proposées par l application. Si une tâche est trop complexe, elle peut être décomposée en sous tâche(s) (introduite(s) par la relation de composition sur la classe Task). Considérons les tâches suivantes : l affichage de carte, le calcul d itinéraire, l affichage de l itinéraire et la localisation de l utilisateur. Ces instances de la classe Task peuvent être associées à l instance TomTom de la classe Application à l aide de l association entre les classes Application et Task. Figure 2. Classes et associations du package Application Domain. Le package Functional Profile rassemble les informations permettant aux concepteurs d utiliser les services. Nous nous sommes basés sur le modèle conceptuel de WSDL afin de construire ce package composé de cinq classes (cf. Figure 3). Ces classes permettent de décrire aussi bien des services Web que des services dits classiques. La classe Method décrit le nom des méthodes proposées par les services décrits. Lorsque le service est hébergé sur le Web, les concepteurs ont 5 http://www.tomtom.com/
besoin de connaître le moyen d accès au service (i.e. le protocole à utiliser, tel que SOAP ou HTTP). La classe Binding représente ce type d information. L association entre les classes Method et Binding représente le moyen d accès de chaque méthode. Enfin, les paramètres (classe Parameter) de chaque méthode sont représentés dans le modèle par l intermédiaire de l association entre les classes Method et Parameter. Un paramètre est décrit par son nom (variable name) et son type (variable type). Lors de l appel de méthode il est nécessaire de différencier les paramètres d entrée et de sortie (respectivement instances des classes InParameter et OutParameter spécialisant la classe Parameter). Figure 3. Classes et associations du package Functional Profile. Figure 4. Classes et associations du package Non Functional Profile. Le package Non Functional Profile décrit les informations qui ne sont pas directement liées à l appel du service. Ces informations sont exploitées pour les processus de recherche et de sélection. Ce package est composé de trois classes (cf. Figure 4), chacune associée à la classe ConcreteService du package Service. La classe Provider décrit le fournisseur du service. Elle est utilisée, d une part lorsque le concepteur de système a besoin de prendre contact avec le fournisseur du service choisi (par exemple, lors d un problème de connexion), et, d autre part, pour aider le concepteur lors du processus de sélection (par exemple, si une organisation a l habitude de travailler avec un fournisseur en particulier). La classe DeploymentProfile comporte les informations concernant le service mais non liées
directement à son invocation. Ces informations (prix du service variable price, temps de réponse variable responsetime, taux de réponse responserate) peuvent être utilisées lors des processus de recherche et de sélection pour faciliter la tâche des concepteurs. La classe ExecutionConstraint permet de décrire les contraintes d exécution des services. Les instances de cette classe peuvent aider les clients lors du processus de sélection ou durant l appel du service. Par exemple, un service renvoie le résultat seulement si l utilisateur s est inscrit sur le site du fournisseur. Le package Use Context est un moyen d ajouter le concept d adaptation à la description d un service (cf. Figure 5). Dans de précédents travaux (Kirsch-Pinheiro et al., 2004), nous avons proposé une formalisation du contexte d utilisation qui repose sur deux classes : celle représentant la description du contexte (ContextDescription) et celle représentant les différents éléments du contexte (ContextElement). La description du contexte d utilisation est composée d un ensemble d éléments du contexte (relation de composition entre les classes ContextDescription et ContextElement). Ici, le contexte d utilisation comporte quatre catégories principales (l utilisateur, le temps, les entités informatiques et la localisation), chacune représentée dans ce package par une classe (respectivement, les classes User, Time, ComputingEntity, Localization) qui spécialise la classe ContextElement. Notre objectif étant l adaptation aux utilisateurs nomades de services Web, nous prenons en compte les spécificités de leur dispositif et de leur environnement en ajoutant la représentation des dispositifs mobiles (classe MobileDevice spécialisant la classe ComputingEntity). Figure 5. Classes et associations du package Use Context. 3.2. Relations entre packages Cette sous-section décrit comment sont liés les packages présentés précédemment (cf. Figure 6). Nous étudions, dans un premier temps, les relations impliquant le package Service, centre du modèle. Puis nous mettons en évidence les
spécificités d utilisation du package Use Context en décrivant les relations qu il a avec les autres packages. Relations entre les packages Service et Application Domain L association reliant les classes ServiceCategory et Domain représente le domaine auquel appartient une catégorie de service. Par exemple, la catégorie de service Localisation peut être liée au domaine Système d Information Géographique. L association entre les classes ConcreteService et Task permet aux concepteurs de connaître les services concrets effectuant une tâche. Relations entre les packages Service et Functional Profile Si le service décrit est un service classique (non Web), la seule relation entre ces deux packages relie les classes ConcreteService et Method. Cette relation permet aux concepteurs de connaître les méthodes fournies par le service. Si le service décrit est un service Web, nous extrayons de la description WSDL les informations concernant l accès (classe Binding), les méthodes fournies (classe Method), les paramètres d entrée et de sortie (classes InParameter et OutParameter) afin d instancier les classes correspondantes. Par conséquent, chacune de ces classes est reliée à la classe WebService. Relations entre les packages Service et Non Functional Profile Toutes les classes du package Non Functional Profile sont liées à la classe ConcreteService puisqu elles ajoutent un niveau descriptif au service fourni. Relation entre les packages Use Context et Service La représentation du contexte d utilisation permet d exprimer le contexte pour lequel un service est adapté (relation entre les classes ConcreteService et ContextDescription). Par exemple, un service donné est développé pour retourner un résultat lisible sur un dispositif mobile de type Sony EricssonK750i. Relation entre les packages Use Context et Non Functional Profile Le contexte d utilisation peut représenter les contraintes d exécution (relation entre les classes ExecutionConstraint et ContextDescription). Par exemple, un service retourne à l utilisateur une image lisible sur un écran dont la dimension est d au moins 176x220. Relation entre les packages Use Context et Functional Profile Les paramètres décrits à l aide des classes du package Functional Profile, ne contiennent que les informations concernant leur nom, leur type (variables de la classe Parameter) et le fait qu ils soient d entrée ou de sortie (s ils sont instances de la classe InParameter ou de la classe OutParameter). À l aide de la relation entre les classes Parameter et ContextElement un niveau de description sémantique est ajouté aux paramètres. Considérons un service qui possède deux paramètres d entrée X et Y. Parallèlement, considérons deux instances de la classe Localization (sous classe de la classe ContextElement cf. section 3.6) : la première, LT, instancie la variable latitude, la seconde, LG, instancie la variable longitude. Si les instances X, Y sont associées respectivement aux instances LG et LT, alors les concepteurs lors de
l appel au service savent ce que représente chacun des paramètres d entrée, et par conséquent, quelles valeurs leur attribuer. Figure 6. Diagrammes de classes représentant les relations entre les cinq packages composant notre modèle (NB : toutes les classes et associations de notre modèle ne sont pas représentées sur cette figure). Il est important de noter que, même s il existe des liens entre les packages, ils sont indépendants. Le package Service peut décrire un service non issu de la technologie de services Web, un service dit Web, un service dédié à une adaptation au contexte d utilisation ou non. Le package Application Domain est utilisé dans ce modèle pour décrire le domaine d application et la tâche associée au service publié. Ce même package peut exprimer les attentes des clients, en termes de domaine, d application et de tâches lors de l élaboration d un projet logiciel. Les packages Functional Profile et Non Functional Profile peuvent être utilisés pour compléter les descriptions de tout composant logiciel ré-utilisable. Enfin, le package Use Context offre un moyen de formaliser le contexte d utilisation en vue, soit de la mise en œuvre de l adaptation, soit d une demande d adaptation. 4. Implémentation du registre L objectif d un registre est de proposer aux utilisateurs de services (et plus particulièrement Web) un moyen de publier, rechercher et sélectionner des services. Dans cet article, l implémentation du registre repose sur le modèle de représentation de services Web décrit dans la section précédente. Dans cette section, nous justifions tout d abord les choix technologiques fait lors de l implémentation du registre, puis nous mettons en évidence les deux fonctionnalités principales proposées aux utilisateurs (la publication et la recherche de services).
4.1. Choix technologiques Le registre est composé de deux parties : le noyau (où sont stockées les informations et les méthodes de publication et de recherche) et l interface de communication avec les utilisateurs. Nous choisissons d héberger le noyau sur un serveur. Une application Web (formulaires HTML et Java Server Pages JSP) permet la communication entre les utilisateurs et le noyau d exécution. L implémentation du noyau du registre de services se base sur un Système de Représentation de Connaissances par Objets (SRCO). Ce choix repose tout d abord sur le fait qu une implémentation objet semble naturelle puisque le modèle de représentation de services est formalisé par le biais d une représentation par objets. De plus, les SRCO permettent d établir des inférences sur la valeur des instances des classes. Le système choisi est AROM (Associer Relations et Objets pour Modéliser) 6 (Page et al., 2001), un SRCO qui se présente sous la forme d'un ensemble d interfaces de programmation (API) Java. AROM reprend les principes classiques de la représentation de connaissances par objets telles que la distinction entre classes et instances, la spécialisation de classes et la présence de facettes de typage. Le système AROM se démarque des autres SRCO notamment par la représentation explicite des associations entre les objets. La majorité des SRCO ne disposent typiquement que du concept de classe. Afin de permettre les inférences d une valeur d une variable ou d interroger les bases de connaissances, AROM propose un langage (LMA Langage de Modélisation Algébrique). Ce langage est utile à l implémentation des méthodes sous jacentes aux registres (telles que la recherche de services). Il est important de noter qu en utilisant AROM nous créons des ontologies représentant notre description de services Web. En effet, selon (Gruber, 1993), une ontologie est une spécification explicite d une conceptualisation. Une conceptualisation est un modèle abstrait qui représente la manière dont les personnes conçoivent les choses réelles dans le monde (Buccella et al., 2005) et une spécification explicite signifie que les concepts et les relations d un modèle abstrait reçoivent des noms et des définitions explicites (Gruber, 1993). Le résultat du modèle de représentation de services (cf. section 3) et de son implémentation à l aide d AROM répond à la définition d une ontologie donnée précédemment. La conceptualisation est apportée par le modèle de représentation, tandis que la spécification explicite est mise en œuvre lors de l implémentation en AROM du modèle. Le registre implémenté apporte de la sémantique à la publication, recherche et sélection de services. De plus, le modèle de représentation de services est extensible puisqu il peut intégrer des concepts existants définis par ailleurs dans d autres ontologies. Nous pensons plus particulièrement aux travaux de (Moisuc et al., 2005) proposant une représentation spatio-temporelle à l aide d AROM. 6 http://www.inrialpes.fr/romans/pub/arom
4.2. Fonctionnalités du registre Le registre propose aux fournisseurs de publier leurs services et aux clients de les rechercher. Fonction de publication Lors de la publication d un service, le fournisseur doit renseigner les informations issues du modèle de représentation de services (cf. section 3). Les informations seront de type : nom du service, localisation du fichier WSDL, catégorie du service, type de tâche effectuée, etc. À l exception du nom du service et de la localisation du ficher WSDL (s il s agit d un service Web) les autres informations sont optionnelles (mais conseillées afin de faciliter la sélection du service publié). Si le service publié est un service Web, les variables des classes du package Functional Profile (cf. section 3) sont instanciées automatiquement par l intermédiaire d une méthode d analyse du fichier WSDL. Concernant le concept d adaptation, le fournisseur a à sa disposition un moyen d associer un contexte d utilisation au service qu il va publier. Nous proposons deux moyens d associer le contexte d utilisation au service. Le contexte d utilisation peut être utilisé afin de (1) représenter les contraintes d exécution du service, (2) représenter le contexte auquel le service est adapté. Sur la page Web de publication de services apparaissent l ensemble des attributs de la représentation du contexte d utilisation (cf. section 3, description du package Use Context). Le fournisseur sélectionne les attributs du contexte qui lui conviennent. Figure 7. Extrait de l application Web pour la recherche d un service Web selon le besoin d adaptation au contexte d utilisation. Fonction de recherche La recherche repose ici sur quatre méthodes. La première, dite classique, propose une recherche par nom de service. La méthode sous-jacente à cette recherche permet aussi une recherche par mot-clé (où le nom demandé appartient au nom du service). Les trois autres méthodes supportent une recherche de services exprimant un besoin lors d une conception de systèmes. Premièrement, le client peut faire une recherche selon la catégorie du service recherché (cf. section 3, description du package Service). Nous proposons au client une page Web où apparaissent dans une liste déroulante toutes les catégories présentes dans la base de connaissances. Le client sélectionne la (ou les) catégories désirées. Deuxièmement, nous proposons aux clients de faire une recherche de services selon la tâche à effectuer. Le client choisit, par l intermédiaire d une page Web, parmi l ensemble des tâches présentes dans la base de connaissances, la tâche
recherchée. Enfin, le client peut rechercher un service selon le contexte d utilisation auquel il désire que le service soit adapté en sélectionnant les attributs du contexte d utilisation auquel il souhaite que le service soit adapté (cf. Figure 7). 5. Travaux voisins UDDI a été implémenté en vue de devenir le registre standard des services Web. Il se compose de trois parties (White paper pages blanches, Yellow paper pages jaunes, Green paper pages vertes) et repose sur XML. Les pages blanches contiennent l information décrivant le fournisseur du service (nom, adresse, etc.) jugées pertinentes pour l identifier. Les informations contenues dans les pages jaunes sont la description non technique des services fournis par le fournisseur (type de services et conventions d utilisation prix, qualité de service, etc.), et son secteur d activité. Cette description repose sur les classifications standard de l industrie nord américaine telle que le NAICS 7. Enfin, les pages vertes comportent des informations techniques liées aux services Web décrites en WSDL. Une description WSDL (fichier XML) comprend les informations concernant les méthodes disponibles, les messages et données échangés, la localisation du service et les protocoles de communication à utiliser. A l origine, des registres UDDI dits publics (tels que ceux de Microsoft ou IBM) offraient un libre accès en tant que fournisseur ou client. L universalité de ces registres devait mener UDDI à devenir le standard de publication. Malgré le nombre important de services publiés (50000 en 2006), UDDI n a jamais atteint son but initial : devenir le registre standard des services Web. Par conséquent, la maintenance des registres publics UDDI a été suspendue. Le vrai succès de UDDI se situe au niveau des registres privés. En effet, de nombreuses organisations utilisent les spécifications de UDDI, auxquelles IBM et Microsoft continuent à contribuer, afin d implémenter leur propre registre de services Web à accès restreint. Cependant, d après (Dovey et al., 2005) les spécifications UDDI souffrent de certaines limitations : il n existe pas de plate-forme d édition ; les APIs de UDDI sont insuffisantes pour développer efficacement les méthodes de publication et de recherche ; le modèle de recherche de UDDI est pauvre (recherche portant sur l identifiant, le nom du service, ou sur les éléments du document WSDL). De plus, les classifications des organisations nord américaines (NAICS) ne suffisent pas à décrire intégralement le domaine d application comme nous l entendons dans la représentation de services Web utilisée (cf. section 3). Enfin, UDDI ne prend pas en compte le contexte d utilisation. Les travaux de (Balke et al., 2003b) recherchent des services Web centrés utilisateurs. La publication de ce type de services repose sur une description spécifique. Les auteurs classent les services Web selon leur interaction (B2B business-to-business entre services, ou B2C business-to-consumer entre un service et un utilisateur final), la tâche que les services accomplissent et l adaptation qu il 7 NAICS North America Industry Classification System, http://www.naics.com
apporte (telle que l adaptation à l utilisateur). Des ontologies décrivent les services Web à l aide de DAML-S (Ankolear et al., 2002). La recherche de services Web est exprimée par l intermédiaire de requêtes à la SQL. À partir de la requête, les ontologies décrivant les services Web sont parcourues jusqu à trouver une instance de service Web correspondant à la requête. Afin d améliorer la recherche, les auteurs ont construit une ontologie comprenant le profil de l utilisateur et un patron d utilisation (descriptions d utilisation anticipée incluant les préférences des utilisateurs) appelé use pattern (Balke et al., 2003a). L ontologie décrivant le service Web trouvé et celle décrivant le profil de l utilisateur sont comparées afin de vérifier si le service Web est adéquat au profil de l utilisateur. Nous pensons que la description des services Web proposée dans ces travaux n est pas suffisante. Il manque des informations telles que la description du fournisseur, ou celle du domaine d application. En termes d adaptation, le profil de l utilisateur (non clairement caractérisé) et les patrons d utilisation sont statiques et non mis à jour. (Heb et al., 2004) proposent un outil d annotation sémantique pour les services Web, nommé ASSAM Automated Semantic Service Annotation with Machine learning. Ce travail évite les erreurs humaines lors du processus de description des services Web. Ce travail permet l intégration d annotations sémantiques à WSDL dans le but de générer automatiquement une description OWL-S (Martin et al., 2004). Les auteurs proposent trois types d annotation. Premièrement, l annotation dite de catégorie, qui permet d ajouter de la sémantique à la tâche effectuée par le service Web. La seconde annotation apporte de la sémantique aux méthodes fournies par le service. Enfin la troisième annotation ajoute de la sémantique aux variables des méthodes. Dans ce travail, le processus de recherche est basé sur un regroupement de services web. Les auteurs rassemblent (à l aide d une méthode de catégorisation) les services Web dont les méthodes possèdent des paramètres d entrée et sortie similaires. Cette méthode de catégorisation est permise grâce aux annotations faites sur les éléments port type (ensemble des méthodes) et message (messages échangés) d une description WSDL. Nous pensons que ce choix n est pas pertinent puisqu il regroupe l ensemble des méthodes proposées par les services. Par conséquent, les catégories construites sont composées de services Web qui ont exactement le même ensemble de méthodes. Il aurait été préférable de construire les catégories à partir de l annotation sur l élément operation (une méthode proposée par le service). De ce fait, les services Web auraient été regroupés selon une méthode particulière. Enfin, il manque dans ce travail l intégration à la description du service des informations concernant le fournisseur et le contexte d utilisation. 6. Conclusion et perspectives Dans cet article, nous avons évalué les besoins d informations en vue d une représentation de services Web. Quatre catégories ont été mises en évidence : le service, le fournisseur, le domaine d application et le contexte d utilisation. Un modèle prenant en compte l ajout de ces catégories a été exposé. Ce modèle permet,
tout en ajoutant un niveau de description supplémentaire, de respecter le cycle de vie des services Web, plus particulièrement l utilisation des standards (WSDL et SOAP). Ce modèle a été validé par l implémentation d un prototype basé sur le système de représentation de connaissances par objets AROM. À l aide de ce registre, lors de la publication de services, les fournisseurs ont à leur disposition une application Web qui les aide à ajouter les nouvelles catégories d information. Les clients de services établissent une recherche de services Web multi-critères (basée sur les catégories pré-établies), toujours à l aide d une application Web. Enfin, les services résultant du processus de recherche sont accompagnés de leur description augmentée. Ceci facilite la phase de sélection puisque les clients ont en leur possession l ensemble des informations sur les services Web. Les perspectives de notre travail s orientent vers deux aspects : l amélioration du registre et la composition de services Web. Bien que les registres publics UDDI ne soient plus maintenus, il serait intéressant de permettre aux fournisseurs de services Web, qui ont déjà publié leurs services via UDDI, d enregistrer leurs services dans notre registre sans surcharge de travail. Une perspective d extension du registre est de proposer une méthode qui analyse les spécifications UDDI et qui les traduit dans notre modèle (à l instar de la méthode d analyse de WSDL). En intégrant le concept d adaptation lors de la conception de systèmes, les concepteurs sont confrontés à la résolution de tâches complexes. Afin de résoudre une tâche complexe un simple appel à un service (en particulier Web) n est pas suffisant, il faut alors faire appel à une composition de services Web. Selon (Wagner et al., 2002), afin de résoudre une tâche complexe il est préférable de décomposer la requête en sous tâches. Ceci peut être implémenté par un module spécifique d AROM nommé AROMTasks, déjà utilisé dans le domaine de la bio informatique (Chabalier et al., 2005). 7. Bibliographie Ankolekar, A., Burstein, M., Hobbs, J., Lasolla, O., Martin, D., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Payne, T., and Sycara, K., «DAMLS: Web Service Description for the Semantic Web», Actes de la conférence internationale ISWC 02, juin 2002, Sardinia, Italie, Springer LNCS, p. 348-363. Balke, W.-T., and Wagner, M., «Cooperative Discovery for User-centered Web Service Provisioning», Actes de la conférence internationale ICWS 03, juin 2003, Las Vegas, USA, CSREA Press, p. 191-197. Balke, W.-T., and Wagner, M., «Towards Personalized Selection of Web Services», Actes de la conférence internationale WWW 03, mai 2003, Budapest, Hungary, ACM Press. Booth, D., and Liu, C. K., Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, W3C Candidate Recommendation, mars 2006, W3C. Buccella, A., Cechich, A., Brisaboa, N.R., «Ontology-Based Data Integration Methods: A Framework for Comparison», Colombian Journal of Computation, vol. 6, n 2, décembre 2005.
Chabalier, J., Capponi, C., Quentin, Y., Fichant, G., «ISYMOD: a knowledge warehouse for the identification, assembly and analysis of bacterial integrated systems», Bioinformatics, vol. 21, n 7, 2005, p. 1246-1256. Dey, A. K., «Understanding and using context», Personal and Ubiquitous Computing, vol. 5, n 1, 2001, p. 4-7. Dovey, M., Kostadinov, I., Giddy, J., Green, P., Berry, D., Chonan, D., Wang, X., UK Engineering Tasks Force Evaluation of UDDI for UK e-science, UK Technical Report, juillet 2005. Gruber, T.R., «A translation approach to portable ontologies», Knowledge Acquisition, vol. 5, n 2, juin 1993, p. 199-220. Haas, H., and Brown, A., Web Services Glossary, W3C Working Group Note, février 2004. Heb, A., Johnston, E., and Kushmerick, N., «ASSAM: A Tool for Semi-automatically Annotating Semantic Web Services», Actes de la conférence internationale ISWC 04, novembre 2004, Hiroshima, Japan, Springer LNCS, p. 320-334. Kirsch-Pinheiro, M., Gensel, J., and Martin, H., «Representing Context for an Adaptative Awareness Mechanism», Actes de l atelier international CRIWG 04, septembre 2004, San Carlos, Costa Rica, Springer LNCS, p. 339-348. Lopez-Velasco, C., Carrillo-Ramos, A., Villanova-Oliver, M., Gensel, J., Martin, H., «Sélection de services Web adaptés au contexte d utilisation», Actes du XXIV Congrès Inforsid, mai-juin 2006, Hammamet, Tunisie, p. 199-214. Martin, D., Paolucci, M., McIlraith, S., Burstein, M., McDermott, D., McGuinness, D., Parsia, B., Payne, T., Sabou, M., Solanki, M., Srinivasan, N., and Sycara, K., «Bringing Semantics to Web Services: The OWL-S Approach», Actes de l atelier international SWSWPC 04, juillet 2004, San Diego, USA, Springer LNCS, p. 26-42. Mitra, N., SOAP Version 1.2 Part 0: Primer, W3C Recommendation, juin 2003. Moisuc, B., Davoine, P.-A., Gensel, J., Martin, H., «Design of Spatio-Temporal Information Systems for Natural Risk Management with an Object-Based Knowledge Representation Approach», Geomatica, vol. 59, n 4, 2005. Nickull, D., Connor, M, MacKenzie, C.M., Watson, B., and Cowan, M., Service Oriented Architecture, White paper, Adobe Systems, 2005. Page, M., Gensel, J., Capponi, C., Bruley, C., Genoud, P., Ziébelin, D., Bardou, D., and Dupierris, V., «A New Approach in Object-Based Knowledge Representation: The AROM System», Actes de la conférence internationale IEA/AIE 01, juin 2001, Budapest, Hungary, Springer LNAI, p. 113-118. Papazoglou, M. P., «Service - oriented computing: Concepts, characteristics and directions», Actes de la conférence internationale WISE 03, décembre 2003, Roma, Italia, IEEE Computer Society, p. 3-12. Wagner, M., Balke, W.-T., Hirschfeld, R., and Kellerer, W. A Roadmap to Advanced Personalization of Mobile Services», Actes de la conférence internationale DOA/ODBASE/CoopIS 02 Industry Program, novembre 2002, Irvine, CA.