Republique Algerienne Democratique et Populaire
Universite Abou Bakr Belkaid{ Tlemcen
Faculte des Sciences
Departement d' Informatique
MEMOIRE
Pour l'obtention du dipl^ome de
MASTER EN INFORMATIQUE
Realise par
BOUHASSOUN Jamel & BOUHASSOUN Leila
Interrogation de sources de donnees
medicales a base de Services Web DaaS
Presente le 29 septembre 2011 devant la commission compose de MM.
President : - Abderrahim M.A.
Examinateurs : - Benamar A.
- Chouiti S.
- El yebdri Z.
- Halfaoui A.
- Benmansour F.
Encadreurs : - Midouni S.D.
- Settouti S.L.
Annee Universitaire : 2010 - 2011
Resume
La composition des Services Web permet de repondre aux besoins d'un utilisateur
qui ne peuvent ^etre satisfaits par un seul Service Web. Dans ce travail, nous nous int
eressons a automatiser la composition des Services Web DaaS (Data-as-a-Service Web
Services) en tenant compte de la relation semantique entre les entrees/sorties d'un service.
Pour atteindre notre objectif, nous modelisons nos Services Web DaaS par des vues
RDF/RDFS sur une ontologie de mediation. En plus, nous proposons une approche de
reecriture de requ^ete qui permet la selection, l'invocation et la composition des Services
Web DaaS an de repondre a une requ^ete d'utilisateur.
Mots-cles: ServicesWeb, composition des ServicesWeb, ServicesWeb DaaS, RDF/RDFS,
ontologie de mediation, reecriture de requ^ete.
i
Abstract
Web Services composition allows to answer the needs of a user that can not be satis-
ed by a single Web Service. In this work, we focus to automate DaaS (Data-as-a-Service)
Web Services composition taking into account the semantic relationship between the inputs/
outputs of a service.
To achieve our goal, we model our DaaS Web Services by RDF/RDFS views over a
mediated ontology. In addition, we propose an approach to rewrite queries that allows the
selection, invocation and composition of DaaS Web Services to answer a user query.
Keywords: Web Services, Web Services composition, DaaS Web Services, RDF/RDFS,
mediated ontology, query rewriting.
ii
Remerciements
Nous tenons tout d'abord a remercier DIEU le tout puissant pour nous avoir donne
la force de realiser ce travail, et aussi nos parents pour leurs soutiens et encouragements
durant nos annees d'etudes.
Nous remercions profondement notre encadreur Mr. MIDOUNI Sid Ahmed Djallal
pour son aide, ses encouragements et ses critiques constructives qui nous ont beaucoup
aide a apprecier ce travail.
Un remerciement special est adresse a notre co-encadreurMr. SETTOUTI Lot Soane
pour ses conseils et pour les nombreux eclaircissements qu'il a bien voulu nous apporter
durant tout ce projet.
Nous remercions egalement les membres du jury qui ont accepte de participer a la
discussion de notre travail.
Nous exprimons aussi toute notre gratitude aux enseignants du departement d'informatique
ainsi que tous nos collegues et nos amis et a tous ce qui ont contribue de pres ou
de loin a la realisation de notre memoire.
iii
A nos parents
A nos familles
A nos amis(es)
iv
Table des matieres
Table des gures 3
Liste des tableaux 5
Introduction Generale 6
Chapitre 1
Notions Preliminaires
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Qu'est ce qu'un Service Web ? . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Modele de base des Services Web . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Les Services Web DaaS (Data as a Service) . . . . . . . . . . . . . . . . . . 12
1.5 Les Services Web semantiques . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Ontologies pour le Web semantique . . . . . . . . . . . . . . . . . . . . . . 15
1.7 RDF/RDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8 SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapitre 2
Etat de l'art sur la composition des Services Web
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Composition des Services Web . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Composition statique des Services Web . . . . . . . . . . . . . . . . 22
2.3.2 Composition dynamique des Services Web . . . . . . . . . . . . . . 23
2.4 Reecriture de requ^etes en termes de vues . . . . . . . . . . . . . . . . . . . 23
1
2.4.1 L'algorithme Bucket [2] . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 L'algorithme de regles inversees [2] . . . . . . . . . . . . . . . . . . 25
2.4.3 L'algorithme MiniCon [2] . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapitre 3
Conception de notre systeme de mediation
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Architecture globale du systeme . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Exemple de motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Services DaaS et modele de requ^ete . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 Ontologie de mediation . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 Requ^ete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Vue RDF Parametree (RPV) . . . . . . . . . . . . . . . . . . . . . 38
3.5 Pre-traitement des vues RDF . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6 Algorithme de reecriture de requ^ete . . . . . . . . . . . . . . . . . . . . . . 47
3.6.1 Trouver les sous graphes pertinents . . . . . . . . . . . . . . . . . . 48
3.6.2 Generation du service composite . . . . . . . . . . . . . . . . . . . . 55
3.6.3 Execution du service composite . . . . . . . . . . . . . . . . . . . . 59
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Conclusion Generale 61
Bibliographie 63
2
Table des gures
1.1 Modele du Service Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Exemple d'une partie d'ontologie des images medicales . . . . . . . . . . . 16
1.3 Exemple de graphe RDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Architecture globale du systeme . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Scenario de motivation propose . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Apercu de l'approche proposee . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Ontologie de mediation proposee . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Representation graphique de la requ^ete Q . . . . . . . . . . . . . . . . . . 37
3.6 Representation SPARQL de la requ^ete Q . . . . . . . . . . . . . . . . . . . 37
3.7 Graphe RDF des services S1 et S2 . . . . . . . . . . . . . . . . . . . . . . 39
3.8 Graphe RDF du service S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9 Graphe RDF des services S4 et S5 . . . . . . . . . . . . . . . . . . . . . . 40
3.10 Graphe RDF du service S6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.11 Graphe RDF du service S7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.12 Graphe RDF du service S8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.13 Graphe RDF du service S9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.14 Graphe RDF du service S10 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.15 Graphe RDF du service S11 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.16 Application des contraintes semantiques RDFS . . . . . . . . . . . . . . . . 43
3.17 Graphe RDFS des services S1 et S2 . . . . . . . . . . . . . . . . . . . . . 43
3.18 Graphe RDFS du service S3 . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.19 Graphe RDFS des services S4 et S5 . . . . . . . . . . . . . . . . . . . . . 44
3.20 Graphe RDFS du service S6 . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.21 Graphe RDFS du service S7 . . . . . . . . . . . . . . . . . . . . . . . . . 45
3
3.22 Graphe RDFS des services S8 . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.23 Graphe RDFS des services S9 . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.24 Graphe RDFS du service S11 . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.25 Exemple de graphe de dependance . . . . . . . . . . . . . . . . . . . . . . 59
4
Liste des tableaux
3.1 Services Web DaaS proposes . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Table de couverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3 Exemples de compositions candidates . . . . . . . . . . . . . . . . . . . . . 57
3.4 Verication de l'executabilite de la composition C2 . . . . . . . . . . . . . 58
5
Introduction Generale
Les besoins d'acceder de facon uniforme a des sources de donnees multiples sont
chaque jour de plus en plus fort, particulierement, dans les systemes decisionnels qui ont
besoin d'une analyse comprehensive des donnees. Les systemes d'integration de donnees
sont apparus pour repondre a ces besoins. Un systeme d'integration de donnees est un
systeme d'information qui integre des donnees de sources dierentes et fournit a l'utilisateur
une vision d'une base de donnees unique. En eet, les sources de donnees sont le
plus souvent reparties, autonomes et heterogenes.
Les systemes de mediation sont des exemples de systemes d'integration de donnees
qui fournissent un acces a des donnees extraites a partir de diverses sources de donnees
et permettent de les integrer pour repondre aux requ^etes des utilisateurs. Ils permettent
aussi de decouvrir les sources pertinentes etant donne une requ^ete, acceder a ces sources
et enn combiner automatiquement les reponses partielles obtenues de plusieurs sources
de facon a delivrer une reponse globale. Un systeme de mediation est specique a un
domaine d'application donne. Il comprend un schema global ou ontologie dont le r^ole est
central. C'est un modele du domaine d'application du systeme. Il fournit un vocabulaire
structure servant de support a l'expression des requ^etes des utilisateurs et la description
des contenus des sources par un ensemble de vues. Par ailleurs, il etablit une connexion
entre les dierentes sources accessibles.
L'approche de mediation presente l'inter^et de pouvoir construire un systeme d'interrogation
de sources de donnees a base de Services Web sans toucher aux donnees qui restent
stockees dans leurs sources d'origine. En eet, un Service Web est une entite logicielle
permettant la communication et l'echange de donnees entre applications et systemes het
erogenes dans des environnements distribues. Etant donne qu'il y a plusieurs Services
6
Web publies sur Internet, beaucoup d'entre eux ne peuvent seuls satisfaire les dierents
besoins complexes d'un utilisateur. De plus, il arrive qu'un besoin quelconque en termes
de fonctionnalite ne puisse pas ^etre satisfait par un seul Service Web, mais, par la combinaison
d'un ensemble de Services Web. Il sera donc necessaire dans ce cas d'ordonner
plusieurs ServicesWeb basiques en un ServiceWeb plus complexe. Pour repondre a une requ^
ete d'utilisateur, un mediateur doit reformuler la requ^ete initiale en un plan de requ^etes
directement executables sur les sources de donnees disponibles. Cette reformulation est
obtenue par la reecriture de requ^ete en termes de vues. Les Services Web composites ainsi
obtenus peuvent entrer a leur tour dans d'autres compositions pour fournir des Services
Web plus complexes a forte valeur ajoutee.
Problematique
Le probleme majeur, auquel nous nous interesserons dans notre travail est le probleme
de reecriture de requ^ete en termes de vues. Etant donne un ensemble de Services Web et
une requ^ete d'utilisateur, comment trouver les combinaisons de services qui satisfont au
mieux la requ^ete ?. C'est a la fois le probleme de localisation, identication et composition
automatique de Services Web dont l'enjeu est de creer des Services Web complexes qui
resolvent le probleme a partir de Services Web plus simples avec l'etude de l'apport des
descriptions semantiques qui leurs sont associees. Notre objectif principal est de proposer
un systeme de mediation qui concerne le domaine medical a base de Services Web DaaS.
Ce systeme permet de repondre aux requ^etes des utilisateurs qui sont souvent complexes
et sophistiques par composition de Services Web DaaS.
Contribution
Dans le cadre de ce travail, nous decrivons un scenario de motivation necessitant la
composition de Services Web DaaS et nous proposons un ensemble de services DaaS
qui peuvent ^etre utilises par le systeme de mediation pour l'interrogation des sources de
donnees structurees (e.g. BDDR, XML). Ensuite, nous presentons une approche de reecriture
de requ^ete pour la composition automatique de Services Web DaaS. Nous proposons
egalement notre ontologie de mediation qui concerne le domaine medical permettant de
fournir le vocabulaire necessaire pour l'expression des requ^etes des utilisateurs ainsi que
la description des contenus des sources par un ensemble de vues RDF/RDFS. Enn, nous
7
presentons notre algorithme de reecriture de requ^ete qui permet la selection, l'invocation
et la composition de Services Web DaaS an de repondre aux requ^etes d'utilisateur.
Ce memoire est organise en trois chapitres :
Chapitre 1 : Notions Preliminaires. Dans ce chapitre, nous presentons les concepts
de base concernant les Services Web, les Services Web DaaS et les Services Web semantiques.
Nous donnons la denition de l'ontologie et nous parlons de son r^ole tres important
pour le Web semantique, puis nous citons les langages de description RDF/RDFS et le
langage d'interrogation SPARQL.
Chapitre 2 : Etat de l'art sur la composition des Services Web. Dans ce chapitre,
nous commencons tout d'abord a introduire la notion de composition des Services
Web avec leurs approches existantes. Ensuite, nous presentons les travaux relatifs au probl
eme de reecriture de requ^etes en termes de vues et enn, nous discutons notre travail
par rapport aux autres travaux.
Chapitre 3 : Conception de notre systeme de mediation. Ce chapitre est dedie
a la conception de notre systeme de mediation. Nous commencons tout d'abord a decrire
un scenario de motivation pour la composition des services DaaS. Ensuite, nous presentons
notre approche pour la composition, notre modele de requ^ete propose et notre ontologie
de mediation ainsi que la description des services DaaS proposes. Enn, nous presentons
notre algorithme de reecriture de requ^ete permettant la composition des Services Web
DaaS an de repondre a la requ^ete d'utilisateur.
Enn, nous terminons ce memoire par une conclusion generale dans laquelle nous
discutons notre travail et nous proposons quelques perspectives de recherche que nous
souhaitons les realiser dans le futur.
8
Chapitre 1
Notions Preliminaires
Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Qu'est ce qu'un Service Web ? . . . . . . . . . . . . . . . . . . 10
1.3 Modele de base des Services Web . . . . . . . . . . . . . . . . . 11
1.4 Les Services Web DaaS (Data as a Service) . . . . . . . . . . . 12
1.5 Les Services Web semantiques . . . . . . . . . . . . . . . . . . . 13
1.6 Ontologies pour le Web semantique . . . . . . . . . . . . . . . 15
1.7 RDF/RDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8 SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 Introduction
Dans ce chapitre, nous presentons quelques concepts de base qui nous semblent indispensables.
Dans la section 1.2, nous donnons quelques denitions du concept "Service
Web" et nous presentons son modele dans la section 1.3. De la m^eme facon, nous introduisons
les concepts "Service Web DaaS" et "Services Web semantiques" respectivement
dans les sections 1.4 et 1.5. Ensuite, nous denissons le concept "ontologie" (section 1.6),
les langages de description RDF/RDFS (section 1.7) et enn, le langage d'interrogation
SPARQL (section 1.8).
9
1.2. Qu'est ce qu'un Service Web ?
1.2 Qu'est ce qu'un Service Web ?
Le Web est de plus en plus le support privilegie des applications. Les Services Web
constituent le developpement ultime dans ce domaine. Un Service Web est souvent vu
comme une application accessible a d'autres applications sur le Web. Cependant, il existe
plusieurs denitions pour le Service Web, nous citerons quelques unes :
Denition 1 : Le consortium W3C1 denit un Service Web comme etant :< une
application, ou un composant logiciel qui verie les proprietes suivantes > [23] :
{ Il est identie par un URI 2 ;
{ Ses interfaces et ses liens peuvent ^etre decrits en XML ;
{ Sa denition peut ^etre decouverte par d'autres Services Web ;
{ Il peut interagir directement avec d'autres Services Web a travers le langage XML
en utilisant des protocoles Internet standards.
Denition 2 : < Un Service Web est une application accessible a partir du
Web. Il utilise les protocoles Internet pour communiquer et un langage stan-
dard pour decrire son interface > [12].
Denition 3 : < Les Services Web sont la nouvelle vague des applications
Web. Ce sont des applications modulaires, auto-contenues et auto-descriptives
qui peuvent ^etre publiees, localisees et invoquees depuis le Web. Les Services
Web eectuent des actions allant de simples requ^etes a des processus metiers
complexes. Une fois qu'un Service Web est deploye, d'autres applications (y
compris des Services Web) peuvent le decouvrir et l'invoquer > [14].
1. World Wide Web Consortium
2. Uniform Resource Identier
10
1.3. Modele de base des Services Web
1.3 Modele de base des Services Web
Le modele des Services Web repose sur une Architecture Orientee Service (SOA) 3.
Celle-ci fait intervenir trois categories d'acteurs : le fournisseur de service, l'annuaire
des services et le client. Un fournisseur de service fournit un module logiciel accessible
sur le reseau et denit une description de service pour le Service Web. Ensuite, il le publie
dans l'annuaire des services de telle sorte que le client peut le trouver. L'annuaire des
services correspond a un registre de descriptions des Services Web orant des facilites
de publication des Services Web a l'intention des fournisseurs, ainsi que des facilites de
recherche des Services Web a l'intention des clients. La description de service contient des
informations telles que l'entree du service, sa sortie et l'adresse ou le service est situe.
Le client interroge l'annuaire pour un certain type de service et recupere sa description.
Ensuite, il utilise les informations dans la description du service pour se lier avec le fournisseur
et d'invoquer le Service Web [6]. Les interactions de base entre ces trois acteurs
montrees dans la gure 1.1 incluent les operations de publication, de recherche et de liens
d'operations. Nous citons, notamment les standards emergents suivants :
{ SOAP4 : Denit un protocole de transmission de messages base sur XML. Il permet
l'echange d'informations a distance en utilisant le formalisme XML pour a la
fois, denir les messages envoyes entre les applications et representer les donnees
echangees.
{ WSDL5 : Un standard fonde sur XML qui permet la description des Services Web.
{ UDDI 6 : Fournit l'infrastructure de base pour la publication et la recherche des
Services Web.
3. Service Oriented Architecture
4. Simple Object Access Protocol
5. Web Service Description Language
6. Universal Description Discovery and Integration
11
1.4. Les Services Web DaaS (Data as a Service)
Figure 1.1 { Modele du Service Web
1.4 Les Services Web DaaS (Data as a Service)
Au cours de la derniere decennie, les Services Web ont ete largement percus comme
un moyen standardise pour l'integration d'applications sur le Web. Ils reposent sur une
architecture orientee service permettant ainsi aux applications de dierents fournisseurs
d'^etre encapsulees comme des services, puis publiees, localisees, invoquees, composees et
coordonnees de maniere a couplage faible. Recemment, les Services Web ont commence a
^etre un support populaire pour la publication et le partage des donnees sur le Web.
Les entreprises modernes evoluent vers une architecture orientee service de partage de
donnees sur le Web en mettant leurs bases de donnees derriere les Services Web, fournissant
ainsi la methode interoperable d'interagir avec leurs donnees. En outre, les donnees
qui ne sont pas stockees dans des bases de donnees traditionnelles sont egalement mises
a disposition via des Services Web. Nous appelons ce type de Services Web en tant que
Services Web DaaS.
< Un Service DaaS fournit une vue simpliee, integree en temps reel , une
information de haute qualite sur une entite commerciale specique comme un
client ou un produit. Il peut ^etre fourni par le middleware ou emballe comme
un composant logiciel individuel. Les informations qu'il fournit proviennent
d'un ensemble diversie de ressources d'informations > [11].
12
1.5. Les Services Web semantiques
Une autre denition de Composite Software : < Les Services Web DaaS sont une
forme de Services Web optimisee pour les demandes d'integration de donnees
en temps reel. Ils visualisent les donnees pour decoupler les emplacements
physiques et logiques et donc, d'eviter la replication des donnees inutiles. Les
ServicesWeb DaaS resument des structures de donnees complexes et de la syn-
taxe. Ils federent des donnees disparates en composites utiles et supportent
l'integration de donnees a travers les applications de l'architecture orientee
service > 7.
Les Services Web DaaS permettent l'acces aux sources de donnees des organisations.
L'invocation d'un service DaaS resulte dans l'execution d'une requ^ete sur le schema de
la source de donnees. Lorsqu'un tel service est execute, il accepte d'un utilisateur une
donnee d'entree d'un format specie et il lui retourne des informations comme une sortie.
Les Services Web DaaS sont maintenant utilises dans de nombreux domaines d'application
comme un moyen standard pour la publication et le partage des donnees. Exemples
de domaines d'application comprennent, entre autres, le partage des donnees scientiques
(par exemple, la bioinformatique, traitement et partage de donnees geospatiales , etc),
le partage des donnees medicales (eHealth), les entreprises d'integration de donnees, le
partage des donnees entre les organismes gouvernementaux (eGovernment), etc).
1.5 Les Services Web semantiques
Les Services Web semantiques se situent a la convergence de deux domaines de recherche
importants qui concernent les technologies d' Internet : le Web semantique et
les Services Web. Cette t^ache de convergence est accomplie en rendant les Services Web
auto-exploitables par machines, et de realiser l'interoperabilite entre les applications via
le Web en vue de rendre le Web plus dynamique.
En eet, le Web semantique a ete invente en 1989 par Tim Berners-Lee. Ce dernier a
proclame que le Web semantique est la prochaine evolution du Web, c'est-a-dire que l'on
7. http ://compositesoftware.com/solutions/soa.shtml
13
1.5. Les Services Web semantiques
va arriver a un Web intelligent ou les informations sont stockees de facon comprehensible
par les machines an d'apporter a l'utilisateur ce qui cherche vraiment. Aujourd'hui, les
humains sont les seuls qui ont la capacite de comprendre ce que nous trouvons et de decider
en quoi cela se rapporte a ce que nous voulons chercher vraiment. Par quels moyens ?
Ce sont les moteurs de recherche qui nous aident, mais ils sont capables de repondre seulement
aux deux questions : Quelles sont les pages contenant un terme ? et Quelles sont les
pages les plus populaires a un sujet ?.
< Le Web semantique est une extension du Web actuel dans lequel l'in-
formation est munie d'une signication bien denie permettant aux machines
et aux personnes de travailler en cooperation > [19]. Le Web semantique reste
entierement fonde sur le Web classique et ne le remet pas en cause. Cela reste un moyen
de publier et consulter des documents, mais les documents traites par le Web semantique
contiennent non pas des textes en langage naturel mais des informations formalisees
pouvant ^etre traitees automatiquement par des agents logiciels. Un des objectifs du Web
semantique est d'aner la recherche sur Internet. Ceci est realise par l'annotation du
contenu du Web en ajoutant aux informations existantes une couche de metadonnees
pour ameliorer la comprehension pour la machine. Pour le faire, on utilise le vocabulaire
conceptuel fourni par une ontologie.
Un Service Web semantique est un Service Web decrit en utilisant des annotations semantiques
dans un langage duWeb semantique bien deni, qui permettent au ServiceWeb
d'avoir une interface comprehensible par les humains et les machines. Ces Services Web
semantiques s'appuient en general sur les langages du Web semantique pour decrire leurs
fonctionnalites et les donnees qu'ils echangent. Les motivations pour developper, ou tendre
vers les Services Web semantiques sont evidemment de faciliter les phases automatiques
de decouverte, selection et composition de Services Web. En eet, si leur semantique est
connue, alors chercher et composer des Services Web pourra ^etre fait automatiquement
en donnant la semantique cible.
14
1.6. Ontologies pour le Web semantique
1.6 Ontologies pour le Web semantique
L'ontologie joue un r^ole tres important pour le Web semantique parce qu'elle represente
la semantique des documents en permettant leur exploitation par les applications
et les agents intelligents. Elle est tres utile pour structurer et denir la signication des
termes de metadonnees actuellement collectees et normalisees. Donc, a l'aide des ontologies,
les applications sur le Web de demain pourrons devenir intelligentes, au sens ou elles
pourront operer plus precisement au niveau conceptuel humain.
Une des denitions de l'ontologie qui fait autorite est celle de Gruber [17] : < Une
ontologie est une specication formelle et explicite d'une conceptualisation
partagee >. La conceptualisation represente la collection des objets, de concepts et
des autres entites qui sont supposes exister dans un certain domaine d'inter^et, et les relations
qui les relient. Une conceptualisation est une vue abstraite, simpliee du monde que
l'on veut representer. Explicite signie que le type des concepts utilises et les contraintes
sur leur utilisation sont explicitement denis. Formelle se refere au fait que l'ontologie
doit ^etre comprehensible par les machines. Partagee re
ete la notion de connaissance
consensuelle decrite par l'ontologie, c'est-a-dire qu'elle n'est pas restreinte au point de
vue de certains individus seulement, mais re
ete un point de vue plus general, partage et
accepte par un groupe.
Une ontologie est une structure de donnee operationnelle qui rend compte des concepts
d'un domaine et de leurs relations. Le developpement des ontologies croissant en Intelligence
Articielle vient de leur inter^et pour associer du sens a des ressources textuelles,
pour localiser et gerer des connaissances dans diverses applications. Son but est donc de
denir quelles primitives avec leur semantique associee sont necessaires pour la representation
des connaissances dans un contexte donne. Elle est representee par un graphe oriente
qui contient :
{ Les nuds (concepts) representant le vocabulaire d'un domaine particulier.
{ Les arcs representant les relations (ou r^oles) nommees entre les concepts.
15
1.7. RDF/RDFS
La gure suivante montre un exemple d'ontologie pour les images pneumologiques :
Figure 1.2 { Exemple d'une partie d'ontologie des images medicales
(images pneumologiques) [1]
A partir de cette structure, la semantique de chaque mot est deduite par les relations
que ce mot possede dans l'ontologie, ce qui permet de restreindre les interpretations
possibles. Cependant pour ^etre exploitable par une machine, une ontologie doit respecter
certaines regles :
{ Etre denie par une syntaxe formelle et une semantique non ambigue.
{ Permettre la deduction de nouvelles connaissances qui sont presentees implicitement.
De plus, pour assurer sa perennite, une ontologie doit posseder un niveau d'abstraction
permettant son extension [15].
1.7 RDF/RDFS
1. < RDF (Resource Description Framework) est un modele standard pour
l'echange de donnees sur le Web. Il permet de decrire de facon formelle
les ressources Web et leurs metadonnees > [21]. En utilisant RDF, les ressources
sont decrites par un ensemble de declarations RDF sous forme de triplets
<Sujet,Propriete,Objet> ou :
16
1.7. RDF/RDFS
{ Sujet : represente la ressource a decrire. Il est identie par une URI.
{ Propriete ou predicat : il s'agit d'une propriete utilisee pour caracteriser et decrire
une ressource. Une propriete est une liaison etiquetee et orientee du sujet vers
l'objet. Elle est identiee par une URI.
{ Objet : la valeur de la propriete pouvant ^etre un litteral ou bien une autre ressource
(identiee par une URI).
Cet ensemble de triplets RDF peut ^etre represente par un graphe oriente etiquete
(Figure 1.3) ou les elements apparaissant comme sujet ou objet sont des nuds et
les proprietes sont des arcs.
Figure 1.3 { Exemple de graphe RDF.
Les nuds peuvent se presenter sous la forme :
{ Valeur litterale : Ex : Michel Tremblay.
{ URI.
{ Vide : permet de designer une ressource par ses proprietes sans expliciter cette
ressource.
Les arcs peuvent se presenter sous la forme :
{ URI :
{ Forme longue : http ://purl.org/dc/elements/1.1/title
{ Forme raccourcie : faisant appel a un prexe dc :title
17
1.8. SPARQL
A noter : un prexe c'est un raccourci de l'URI complet de la ressource. Ecrire
dc :title equivaut a ecrire l'URI de la propriete dans sa forme longue.
2. RDFS (Resource Description Framework Schema)
Il est necessaire, pour donner une semantique ou un sens aux informations stockees
sous forme de triplets RDF, de se donner un vocabulaire (classes et proprietes).
< RDFS est un langage extensible de representation des connaissances
qui permet de decrire precisement par vocabulaires les ressources d'un
domaine donne et les relations entre elles. RDFS fournit des elements de
base pour la denition d'ontologies ou vocabulaires destines a structurer
des ressources RDF > [20].
Il permet d'organiser les classes en une hierarchie de classes en utilisant les relations
de subsomption entre classes "subClassOf" et d'organiser les proprietes en
une hierarchie de proprietes en utilisant des relations de subsomption entre propri
etes "subPropertyOf". De plus, RDFS ore le moyen de specier le typage des
proprietes en indiquant leur "domaine" et leur "co-domaine" (range).
1.8 SPARQL
< SPARQL est un langage de requ^etes pour l'interrogation de metadonnees
et l'extraction des donnees sous forme d'un graphe RDF ou plus exactement
un langage d'interrogation de triplets RDF > [22].
SPARQL est adapte a la structure specique des graphes RDF et s'appuie sur les triplets
qui les constituent . Il denit la syntaxe et la semantique necessaire a l'expression de
requ^etes sur une base de donnees de type RDF. Il est dierent du classique SQL (langage
de requ^ete qui est adapte aux bases de donnees relationnelles) mais s'en inspire clairement
dans sa syntaxe et ses fonctionnalites. Il a aussi quelques traits de ressemblances mineures
avec Prolog. SPARQL permet d'exprimer des requ^etes interrogatives ou constructives :
{ Une requ^ete SELECT de type interrogative permet d'extraire du graphe RDF un
sous-graphe correspondant a un ensemble de ressources veriant les conditions de-
18
1.9. Conclusion
nies dans une clause WHERE.
{ Une requ^ete CONSTRUCT de type constructive, engendre un nouveau graphe qui
complete le graphe interroge.
La structure d'une requ^ete SPARQL est tres similaire a celle employee dans le langage
SQL :
SELECT ?v1?v2 : : : ?vn
FROM <description.rdf>
WHERE f
(sujet1 jvi) (predicat1 j vj) (objet1 j vk) . . . (sujetx jva) (predicaty j vb) (objetz j vc)
g
1.9 Conclusion
Les Services Web representent aujourd'hui la technologie la plus adaptee pour assurer
le developpement des systemes distribues sur Internet. Un des concepts interessants
qu'ore la technologie de Service Web et qui suscite beaucoup d'inter^et est la possibilite
de creer un nouveau Service Web a valeur ajoutee par composition de plusieurs Services
Web existants.
19
Chapitre 2
Etat de l'art sur la composition des
Services Web
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Composition des Services Web . . . . . . . . . . . . . . . . . . 21
2.3 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Composition statique des Services Web . . . . . . . . . . . . . 22
2.3.2 Composition dynamique des Services Web . . . . . . . . . . . . 23
2.4 Reecriture de requ^etes en termes de vues . . . . . . . . . . . . 23
2.4.1 L'algorithme Bucket [2] . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 L'algorithme de regles inversees [2] . . . . . . . . . . . . . . . . 25
2.4.3 L'algorithme MiniCon [2] . . . . . . . . . . . . . . . . . . . . . 26
2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Introduction
Ce chapitre est essentiellement consacre a l'etat de l'art relatif a la composition des
Services Web. Nous commencons tout d'abord par introduire le besoin de composition
des Services Web dans la section 2.2 et nous presentons les approches existantes pour la
composition des Services Web dans la section 2.3. Ensuite, nous introduisons le probleme
de reecriture de requ^etes en termes de vues pour lequel, nous presentons trois algorithmes
(section 2.4). Enn, nous discutons notre travail par rapport aux autres travaux.
20
2.2. Composition des Services Web
2.2 Composition des Services Web
Ces dernieres annees, la recherche dans le domaine des Services Web a ete tres developp
ee. Une grande partie de cette recherche a ete consacree a la composition de Services
Web. Reellement, il n'est pas toujours facile de trouver des Services Web qui s'apparient
avec les requ^etes des utilisateurs. Par consequent, la composition des services satisfaisant
la requ^ete est un besoin grandissant de nos jours. La composition de services est une t^ache
complexe. Cette complexite est due principalement aux raisons suivantes [4] :
{ Le nombre de ServicesWeb disponibles sur leWeb est potentiellement tres important
et en constante augmentation ;
{ Les Services Web peuvent ^etre crees et modies, le systeme de composition doit
donc detecter et gerer ces changements ;
{ Les Services Web sont crees par des organisations dierentes qui n'ont pas forcement
les m^emes modeles de concepts pour decrire ces services.
La composition des Services Web devient de plus en plus incontournable dans un environnement
ouvert et dynamique comme Internet. Il est evident qu'une composition a
la demande sera tres preferable, en plus, il sera judicieux de prendre en charge la semantique
durant la composition des Services Web an de minimiser les fausses reponses et
d'ameliorer la qualite globale des resultats.
La composition des ServicesWeb est le processus de construction de nouveaux Services
Web a valeur ajoutee a partir de deux ou plusieurs Services Web deja presents et publies
sur le Web. Un Service Web est dit compose ou composite lorsque son execution implique
des interactions avec d'autres Services Web et des changements des messages entre
eux an de faire appel a leurs fonctionnalites. La composition de Services Web specie
quels services ont besoin d'^etre invoques, dans quel ordre et comment gerer les conditions
d'interactions [5].
21
2.3. Approches existantes
2.3 Approches existantes
Il existe principalement deux grandes approches de composition des Services Web :
l'approche statique et l'approche dynamique. Nous presentons brievement chacune de ces
approches dans ce qui suit.
2.3.1 Composition statique des Services Web
Une composition est statique quand tous les Services Web qui font partie de la composition
sont connus, ainsi que leur ordre d'execution. Dans cette composition, les services
sont connus avant leur execution, c'est-a-dire, au moment ou la composition est faite. De
plus, nous connaissons egalement l'ordre d'execution ainsi que la localisation et la description
des Services Web. Dans la composition statique, tout est completement specie
et en particulier tous les Services Web sont connus. [7]
De plus, la creation des processus metiers se fait durant le developpement du systeme
et reste statique pendant son utilisation, or l'environnement des Services Web est dynamique.
Pour ces raisons, les chercheurs fournissent beaucoup d'eorts pour la creation
des processus metiers et le rendre plus dynamique en restreignant, autant que possible,
l'intervention du developpeur dans le choix et la composition des Services Web. Ce type
de composition est la composition dynamique. Microsoft Biztalk et Bea Weblogic
sont deux exemples de moteurs de composition statique de Services Web [18]. Si les
fournisseurs de services proposent d'autres services ou changent les anciens services, des
incoherences peuvent ^etre causees, ce qui demanderait un changement de l'architecture
du logiciel, voire de la denition du processus et creerait l'obligation de faire une nouvelle
conception du systeme. Dans ce cas, la composition statique des Services Web est consider
ee trop restrictive : les composants doivent s'adapter automatiquement aux changements
imprevisibles.
22
2.4. Reecriture de requ^etes en termes de vues
2.3.2 Composition dynamique des Services Web
Une composition est dynamique quand les Services Web qui font partie de la composition
sont connus progressivement, ainsi que l'ordre d'execution necessaire pour la
composition. Une approche dynamique pour la composition de services ore le potentiel
de realiser des applications
exibles et adaptables, en selectionnant et en combinant les
services de maniere appropriee sur la base de la requ^ete et du contexte de l'utilisateur [7].
Dans cette approche, les Services Web a composer sont choisis au moment de l'execution
durant laquelle une recherche des services est eectuee dans les registres. A titre
d'exemple, StarWSCOP8 [18]. Pour faire la composition dynamique des Services Web,
StarWSCOP eectue les quatre etapes suivantes :
{ Les fournisseurs des Services Web publient leurs services dans un registre.
{ StarWSCOP decompose les requ^etes des utilisateurs en services abstraits et envoie
une requ^ete SOAP au registre pour trouver les services appropries.
{ Le registre de Services Web disponibles renvoie une liste de Services Web concrets.
{ StarWSCOP envoie une requ^ete SOAP aux Services Web trouves, ensuite se lie avec
eux.
StarWSCOP contient plusieurs modules : un systeme intelligent pour decomposer les
requ^etes des utilisateurs en plusieurs services abstraits, un moteur de recherche de Services
Web pour decouvrir les Services Web qui respectent les conditions de l'utilisateur, un
moteur de composition qui execute les services en ordre. Une couche axee ontologie est
aussi rajoutee a UDDI an de faire de l'appariement semantique pour les Services Web.
2.4 Reecriture de requ^etes en termes de vues
Le probleme de reecriture de requ^etes a ete principalement aborde dans les applications
d'optimisation de requ^etes et d'integration de donnees. La principale question a laquelle
la reecriture essaie de repondre est : Etant donne une requ^ete Q est un ensemble de vues
V = fV1; ::::; Vng, est-il possible de repondre a Q en utilisant uniquement les donnees des
8. Star Web Services Composition Platform
23