Cours état de l’art sur la composition des Services Web, tutoriel & guide de travaux pratiques en pdf.

Composition des Services Web

Ces dernieres annees, la recherche dans le domaine des Services Web a et tres deve-loppee. Une grande partie de cette recherche a et 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 complexit est due principalement aux raisons suivantes [4] :
{ Le nombre de Services Web disponibles sur le Web 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 cre es par des organisations di erentes 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 en-vironnement 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 seman-tique durant la composition des Services Web a n de minimiser les fausses reponses et d’ameliorer la qualite globale des resultats.
La composition des Services Web 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 im-plique 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].

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.

Composition statique des Services Web

Une composition est statique quand tous les Services Web qui font partie de la compo-sition 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 des-cription des Services Web. Dans la composition statique, tout est completement speci et en particulier tous les Services Web sont connus.
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 dyna-mique. Pour ces raisons, les chercheurs fournissent beaucoup d’e orts 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 conside-ree trop restrictive : les composants doivent s’adapter automatiquement aux changements imprevisibles.

Composition dynamique des Services Web

Une composition est dynamique quand les Services Web qui font partie de la com-position sont connus progressivement, ainsi que l’ordre d’execution necessaire pour la composition. Une approche dynamique pour la composition de services o re 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.
Dans cette approche, les Services Web a composer sont choisis au moment de l’excution durant laquelle une recherche des services est e ectuee dans les registres. A titre d’exemple, StarWSCOP 8 [18]. Pour faire la composition dynamique des Services Web, StarWSCOP e ectue 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.

Reecriture de requetes en termes de vues

Le probleme de reecriture de requ^etes a et principalement aborde dans les applications d’optimisation de requ^etes et d’integration de donnees. La principale question a laquelle la re ecriture 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 vues V ?. Dans le contexte d’integration de donnees, la reecriture d’une requ^ete consiste a determiner les vues pertinentes pour l’execution de la requ^ete d’utilisateur et a utiliser leurs de nitions pour reformuler cette requ^ete. Les techniques de reecriture de requ^etes ont et largement explorees dans le domaine de base de donnees. Une bonne etude des algorithmes de reecriture de requ^ete est presentee dans [2].
Dans ce qui suit, nous decrivons trois algorithmes de reecriture permettant de repondre aux requ^etes en utilisant des vues. Ces algorithmes sont : « l’algorithme Bucket », « l’al-gorithme de regles inversees » et « l’algorithme MiniCon ».

L’algorithme Bucket

L’idee principale de l’algorithme Bucket est de reduire le nombre de reecritures qui doivent ^etre etudiees en considerant chaque sous-but de la requ^ete en isolation a n de de-terminer les vues pertinentes pour chaque sous-but. L’algorithme procede en deux etapes :
(i) construction d’un bucket pour chaque sous-but de la requ^ete contenant les vues contri-butives pour la re ecriture de ce sous-but , et (ii) construction de toutes les requ^etes conjonctives possibles en prenant une source de chaque bucket. Le resultat nal de l’algo-rithme est l’union de toutes les requ^etes conjonctives (reecritures candidates).
Dans sa premiere phase, l’algorithme Bucket essaie de trouver l’ensemble des vues qui sont pertinentes pour chaque sous-but de la requ^ete. Une vue V est pertinente pour un sous-but g d’une requ^ete Q si les conditions suivantes sont veri ees :
{ V contient un sous-but g1 tel que g peut ^etre uni e avec g1. L’uni cation est faite sur des sous-buts ayant le m^eme nom en tenant compte de la position des variables. Elle consiste a construire les mappings entre les variables des deux sous-buts ;
{ Toutes les variables distinguees de Q sont mappees a des variables distinguees de V lors de l’uni cation de g et g1 ;
{ Les predicats de comparaison de V et de Q ne sont pas con ictuels.
Dans la deuxieme phase, l’algorithme Bucket trouve un ensemble de re ecritures de requ^etes conjonctives. Il considere toutes les combinaisons possibles de sources de donnees en prenant une source de chaque bucket. Chacune de ces reecritures represente un moyen d’obtenir une partie de la reponse a Q a partir des vues. L’inconvenient majeur de l’algorithme Bucket est son incapacite de detecter le fait qu’il doit utiliser la m^eme vue pour couvrir plusieurs sous-buts de la requete. Cet algorithme est egalement incapable de trouver les vues qui ne peuvent pas ^etre pertinentes avant d’avoir test toutes les solutions possibles.