Services Web s´ emantiques

Les principes de l’architecture orient´ee-service apportent une r´eponse `a l’h´e- t´erog´en´eit´e des plate-formes et des langages de programmation des fonctionna-

lit´es. Cependant, leur utilisation repose sur une int´egration manuelle par des d´eveloppeurs, qui choisissent les services appropri´es et les int`egrent aux applica- tions. Cette d´emarche ne convient pas compl`etement aux cas d’environnements ouverts, dans lesquels il n’est pas garanti que les fonctionnalit´es int´egr´ees lors de la conception soient disponibles et conservent leurs caract´eristiques.

Le Web s´emantique s’int´eresse `a prendre en charge cette h´et´erog´en´eit´e `a l’aide de techniques de repr´esentation et de gestion des connaissances. Grˆace `a ces techniques, des outils automatis´es peuvent faciliter la conception d’applica- tion `a partir de services h´et´erog`enes. L’approche des services Web s´emantiques exploite les possibilit´es du Web s´emantique dans le cadre des services Web.

Cette section d´etaille les principes du Web s´emantique et des services Web s´emantiques qui permettent une int´egration dynamique de services Web h´et´ero- g`enes.

a) Le Web s´emantique

Le Web s´emantique propose une vision du Web dans laquelle les informa- tions peuvent ˆetre interpr´et´ees par des machines, et non plus seulement par des humains (Berners-Lee et al., 2001). Cette vision pose le probl`eme de gestion de l’h´et´erog´en´eit´e des informations repr´esent´ees sur le Web. Pour y r´epondre, le Web s´emantique propose la repr´esentation et l’´echange de l’information de mani`ere `a faciliter son traitement automatique.

La vision du Web s´emantique repose sur un certains nombres de technologies organis´ees en plusieurs couches. Les principaux ´el´ements de l’architecture du Web s´emantique sont les suivants :

URI : identification de ressources Les URI (Uniform Resource Identi- fiers) fournissent une solution de nommage global des ressources. En particu- lier, les URI sont utilis´ees pour d´efinir des adresses accessibles sur le Web (aussi nomm´ees URL, Uniform Resource Locator ). Un URI suit la syntaxe suivante :

scheme:[//authority][/path][#fragment][?query]

Dans le cas d’une ressource effectivement accessible sur le Web, scheme d´esigne g´en´eralement un protocole qui permet d’acc´eder `a la ressource (par exemple http), authority d´esigne un nom de domaine ou de serveur, path d´esigne le chemin auquel est accessible le document, fragment d´esigne un emplacement dans le document et query d´esigne un ensemble de paires param`etre-valeur. Ce- pendant, un URI ne correspond pas n´ecessairement `a une ressource accessible et il est possible d’utiliser un URI pour identifier n’importe quel type de ressource. RDF : description de ressources RDF (Resource Description Framework ) est un langage qui permet d’ajouter des m´eta-donn´ees aux ressources du Web. Chaque ressource est identifi´ee par un URI. RDF permet d’exprimer des infor- mations sur les ressources sous la forme de triplets(Subject Property Object) (parfois not´e P(S,O)). Dans un triplet, Subject et Property sont des URI (identifiant des ressources) et Object est soit un URI, soit un litt´eral. Un ensemble de triplets d´ecrit des connaissances sur les ressources r´ef´erenc´ees par ces triplets, en ´etablissant des relations entre elles. Un tel ensemble de triplet est un jeu de donn´ees RDF (RDF dataset ). Un jeu de donn´ee RDF peut s’exprimer sous la forme d’un graphe orient´e ´

etiquet´e, dans lequel les nœuds sont les sujets ou les objets et les propri´et´es sont les ´

OWL : expression d’ontologies OWL (Web Ontology Language) permet d’ex- pliciter le sens des termes utilis´es dans un document, de mani`ere `a autoriser une interpr´etation automatis´ee par des machines. Dans le cadre du Web s´emantique, les connaissances sont d´efinies formellement sous la forme d’ontologies, c’est-`a-dire d’une (( sp´ecification formelle explicite d’une conceptualisation partag´ee )) (Gruber, 1993). L’int´erˆet d’une ontologie est de d´efinir les diff´erents concepts utilis´es au sein d’un do- maine et leurs relations de mani`ere explicite et formelle. De cette mani`ere, une machine peut effectuer des raisonnements sur ces connaissances et fournir une interpr´etation similaire `a une interpr´etation humaine. Le partage de cette formalisation est une ca- ract´eristique essentielle des ontologies, en particulier dans le cadre du Web s´emantique. Le langage OWL est le standard qui permet de d´efinir des ontologies destin´ees `a ˆetre publi´ees et partag´ees sur le Web.

Langages de r`egles Les ontologies permettent d’exprimer des connaissances sur les classes, les propri´et´es, leurs hi´erarchies et certaines contraintes. Cependant, il est parfois n´ecessaire d’exprimer des relations plus complexes entre les entit´es, telles que des r`egles de la forme(( si A, alors B )). Bien qu’il n’existe pas encore de standard pour l’expression de r`egles dans le Web s´emantique, plusieurs propositions existent (SWRL, WSML).

b) Langages de description s´emantique de services

Les technologies du Web s´emantique permettent de repr´esenter, de manipuler et de partager des connaissances h´et´erog`enes. De nombreux travaux se sont ainsi attach´es `a d´efinir des langages de description s´emantique pour les services Web, qui permettent d’exprimer de mani`ere pr´ecise les fonctionnalit´es offertes. Ces langages permettent ensuite des traitements automatiques pour la s´election, la composition et l’invocation de services Web.

SAWSDL Semantic Annotation for WSDL (SAWSDL) (W3C, 2004a) est destin´e `a faciliter le traitement automatique de descriptions WSDL en pr´ecisant ces descriptions `

a l’aide de concepts d´efinis dans des ontologies. Ce langage privil´egie l’extension du langage de description d’interface existant (WSDL) pour faciliter son adoption. En particulier, SAWSDL permet d’associer des concepts d´ecrits formellement dans des ontologies de domaine aux diff´erents ´el´ements d’une description WSDL (par exemple, les param`etres des op´erations du service).

OWL-S OWL for Services (OWL-S) (Martin et al., 2007) est une ontologie qui permet de d´ecrire des services. L’objectif est d’exploiter la formalisation apport´ee par OWL pour permettre la d´ecouverte, la composition et l’invocation de services (Ankolekar et al., 2002). OWL-S organise la description d’un service en trois parties : le profile (profil), le process model (mod`ele) et le grounding (ancrage). Ces trois parties correspondent `a trois aspects du service.

– le profile d´ecrit ce que fait le service. Il a notamment pour but de permettre la d´ecouverte et la s´election automatique d’un service par un agent logiciel. Il comprend une description textuelle sur le service (pour un humain), une descrip- tion fonctionnelle, en termes d’entr´ees, de sorties, de pr´e-conditions et d’effets (IOPE : input, output, precondition, effect ) et d’autres attributs.

– le process model d´ecrit comment fonctionne le service. Il d´efinit les entr´ees, sor- ties, pr´e-conditions et effets. Il permet de sp´ecifier un processus atomique (atomic process) ou compos´e de plusieurs autres processus (composite process) `a l’aide de structures de contrˆole (telles que Sequence, If-then-else).

– le grounding d´ecrit comment invoquer le service. Cet aspect de la description exprime comment former les messages qui permettent d’invoquer les op´erations

d´ecrites. En particulier, il peut ˆetre exprim´e en lien avec la sp´ecification WSDL d’un Web service. Le grounding permet une certaine ind´ependance par rapport au type de services consid´er´e. Martin et al. (Martin et al., 2007) rapportent ainsi plusieurs exp´eriences d’utilisation de OWL-S en dehors du cadre des services Web, notamment dans des syst`emes pair-`a-pair ou en utilisant l’infrastructure UPnP (UPnP Forum, 2006).

OWL-S se caract´erise aussi par la volont´e d’exprimer les descriptions de services en utilisant OWL. Cependant, il apparaˆıt que de nombreuses constructions ne peuvent ˆ

etre exprim´ees simplement en utilisant OWL. En particulier, les pr´e-conditions et les effets n´ecessitent l’expression de formules logiques, pour lesquelles un langage annexe doit ˆetre utilis´e.

WSMO Web Service Modeling Ontology (WSMO) (Fensel et al., 2007) fait partie d’un ensemble de solutions destin´ees `a permettre la r´ealisation de services Web s´e- mantique (WSMO framework). WSMO d´efinit une ontologie destin´ee `a d´ecrire tous les aspects d’un syst`eme fond´e sur les services Web s´emantiques. WSMO d´efinit ainsi quatre concepts fondamentaux :

– les ontologies, qui d´efinissent de mani`ere formelle les concepts employ´es pour les descriptions.

– les services Web, qui offrent des fonctionnalit´es accessibles par des interfaces bien d´efinies.

– les buts, qui d´ecrivent les besoins des utilisateurs de services (humain, applica- tions ou autre services)

– les m´ediateurs, qui assurent l’interop´erabilit´e entre les diff´erentes entit´es dans le cadre d’un environnement ouvert et h´et´erog`ene.

Pour chacun de ces types d’´el´ements, WSMO d´efinit un mod`ele de description qui permet de concevoir des syst`emes fortement d´ecoupl´es. Chaque ´el´ement peut-ˆetre d´e- fini ind´ependamment des usages possibles par d’autres entit´es du syst`eme, dans la mesure o`u il est accompagn´e d’une description exprim´ee `a l’aide de WSMO. Lors de l’utilisation, l’int´egration des ressources est r´ealis´ee grˆace aux descriptions et permet de fournir un service int´egr´e qui satisfait un but particulier.

Dans un tel syst`eme ouvert, le rˆole des m´ediateurs pour assurer l’interop´erabilit´e est particuli`erement important. WSMO d´efinit plusieurs types de m´ediateurs op´erant entre les diff´erents types d’´el´ements pr´ec´edemment cit´es. Les m´ediateurs ont `a r´esoudre plusieurs types d’h´et´erog´en´eit´e. Ainsi, l’h´et´erog´en´eit´e au niveau des donn´ees est trait´ee par un alignement des termes utilis´es pour d´efinir des entit´es similaires. L’h´et´erog´en´eit´e au niveau des processus d’interaction est trait´ee par `a des m´ecanismes de manipulation des messages ´echang´es entre services (fusion, ordonnancement ...). L’h´et´erog´en´eit´e au niveau des fonctionnalit´es est trait´ee par des m´ecanismes de comparaison et de red´e- finition des fonctionnalit´es fournies et attendues.

Contrairement `a OWL-S, WSMO repose sur un langage de repr´esentation des connaissances sp´ecifiquement d´evelopp´e pour r´epondre aux besoins de description de service : WSML. WSML int`egre ainsi plusieurs types de construction logique pour atteindre l’expressivit´e requise.

c) El´´ ements de description non-fonctionnelle des services

Les langages de description des services pr´esent´es dans la section pr´ec´edente s’int´e- ressent en priorit´e `a la description fonctionnelle des services. Ils permettent d’enrichir les langages de descriptions d’interface avec des concepts bien d´efinis. Cependant, dans de nombreux cas, le choix de services est conditionn´e par des informations qui ne concernent pas directement la fonctionnalit´e fournie, mais plutˆot les caract´eristiques non-fonctionnelles.

Description non-fonctionnelle de services Web Dans le cas des services Web, certains travaux se sont int´eress´es `a d´ecrire des caract´eristiques non-fonctionnelles concernant en particulier la qualit´e de services (QoS). La prise en compte de ces aspects permet de discriminer des services fonctionnellement similaires. Par exemple, Claro et al. (Claro et al., 2006) consid`erent un mod`ele dans lequel les aspects de coˆut, de temps de r´eponse, de disponibilit´e et de r´eputation sont pris en compte. Ben Mokhtar et al. (Ben Mokhtar et al., 2005) proposent de consid´erer d’autres crit`eres, en diff´erenciant les aspects quantitatifs et qualitatifs.

Description non fonctionnelle d’autres types de services Dans le cas d’autres architectures orient´ee-service, d’autres aspects peuvent apparaˆıtre. Ainsi, cer- taines architectures sont destin´ees `a la gestion de services multim´edia. Dans ces ar- chitectures, il existe de nombreuses contraintes non fonctionnelles afin notamment d’assurer une qualit´e de service suffisante pour les utilisateurs. Behre (Berhe Hagos, 2006) propose par exemple une description des caract´eristiques de contenu multim´edia.

Description du contexte physique Dans le domaine de l’informatique diffuse, l’utilisation de description s´emantique de services est aussi envisag´ee (Chakraborty et al., 2006) . Dans ce cas, la description du contexte physique associ´e `a un service est essentielle (Maamar et al., 2005).

d) Synth`ese

Int´erˆets Grˆace `a l’introduction de technique de repr´esentation des connaissances, l’approche des services Web s´emantiques comble certaines lacunes de l’approche orient´ee- service. En particulier, les descriptions s´emantiques permettent d’automatiser l’in- t´egration dynamique de fonctionnalit´es qui n’ont pas ´et´e con¸cues pour fonctionner ensemble. De plus, les descriptions s´emantiques offrent un cadre plus flexible, dans lequel il est possible d’introduire des mod`eles permettant d’expliciter des aspects non- fonctionnels et contextuels des fonctionnalit´es.

Inconv´enients Dans le cadre des applications attentives, l’utilisation de services s´emantiques semble int´eressante. Cependant, il apparaˆıt que les langages de description existants (principalement destin´es aux services Web) sont insuffisants pour les besoins des applications attentives. En particulier, les descriptions d’interactions prolong´ees et d’informations non-fonctionnelles et contextuelles sont assez peu d´evelopp´ees. Ces aspects sont particuli`erement importants dans le cas des applications attentives.