Vérification de la compatibilité des services web pour une composition

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université Constantine2
Faculté des Nouvelles Technologies de l’Information
Information et de la Communication
N° d’Ordre :
Série :
Thèse
Pour l’Obtention du Diplôme de
Magister en Informatique
Vérification de la Compatibilité
ompatibilité
des Services
ervices Web pour une Composition
omposition
Présenté par : KHELLAF Radhia
Devant le Jury :
•
•
•
•
MAAMRI Ramdane
ZEGHIB Nadia
BELALA Faiza
SAIDOUNI Djamel-eddine
eddine
Professeur
MCA
Professeur
Professeur
Université Constantine 2
Université Constantine 2
Université Constantine 2
Université Constantine2
Date de Soutenance le …./ …./ 2014
Président
Rapporteur
Examinateur
Examinateur
Remerciements
Tout d'abord, je remercie mon Dieu de m'avoir donné la santé, la patience, la volonté et
le courage pour terminer cette thèse sous cette forme satisfaisante.
Nombreux sont ceux qui m’ont aidé, encouragé, réconforté, soulagé, tout au long de ces
années et je ne saurais leur exprimer mes remerciements autant que je le souhaiterais ; leurs
discussions, leurs conseils, leur présence, me furent éminemment précieux.
Tout d'abord, je tiens à exprimer ma gratitude à monencadreur Mme ZAGHIB Nadia maître
de conférence à l’université de constantine2 pour m’avoir proposé ce sujet très intéressant et
m’avoir dirigé au cours de ce travail, pour sa confiance et son soutien total tout au long de
l'élaboration de ce travail.
Mes plus sincères remerciements vont également aux membres du jury qui m’ont fait
l’honneur d’avoir accepté d’examiner et de juger ce travail dans des délais plus que limités.Je
souhaite mentionner : M. MAAMRI Ramdane professeur à l’université de constantine2de
m’avoir fait l’honneur de présider le jury de ma soutenance. Mme BELALA Faiza professeur
à l’université de constantine2 ainsi le professeur SAIDOUNI Djamel-eddine de l’université de
constantine2pour l’intérêt qu’ils ont porté à ce travail en acceptant d’être examinateurs.
Mes remerciements à mes amies houda, imen, nadia et nessrine pour leur soutien
C'est un énorme remerciement que j'adresse vers les êtres qui mes sont le plus chers, qui ont
eu un rôle essentiel et continu pendant ma réussite, et qui sans eux aucune réussite n’aurait été
possible.
J’adresse de tout mon cœur mes remerciements à ma chère mère qui fut toujours mon seul
exemple, je suis infiniment reconnaissant pour son soutien, son amour et la confiance qu’elle
m’a offerte tout au long de ces années. Un très grand merci à mon père que Dieu le plus
puissant m’aide pour lui rendre un minimum de ce que je lui dois.
Je veux leurs dire que leurs soutien a été toujours ma source d’espoir et m’a incité toujours à
penser à s’améliorer chaque lendemain. Qu’ils trouvent dans ce travail le fruit de leur travail.
Un grand merci à mes sœurs et frères, pour leur encouragement, leur aide et leur amour
depuis ma tendre enfance.
Je ne pourrais clôturer ces remerciements sans adresser un remerciement particulier et
chaleureux à mon époux BOUOUDEN Hakim pour son encouragement, sa patience et son
aide dans tous les moments de ce mémoire.
KHELLAF Radhia
6
Résumé
Le travail présenté dans cette thèse rejoint les travaux qui explorent le domaine vaste de la
composition des services Web. Celle-ci se réfère au processus de création d’un service
composite offrant une nouvelle fonctionnalité, à partir de services Web existants plus
simples, par le processus de découverte dynamique, d’intégration et d’exécution de ces
services dans un ordre bien défini afin de satisfaire un besoin bien déterminé.
Cette thèse étudie en particulier les incompatibilités qui peuvent surgir lors de la composition
des services Web. Ces incompatibilités peuvent concerner les aspects syntaxiques,
sémantiques, comportementaux ou de qualité de service. Pour chacun de ces types
d’incompatibilité, nous proposons une approche de vérification dans un cadre formel
approprié.
Mots clés : Service Web, Composition, Compatibilité.
Abstract
The work presented in this thesis joins the works exploring the vast domain of Web service
composition. This refers to the process of creating a composite service offering a new
functionality, from simpler existing Web services, with the dynamic discovery process,
integration and execution of these services in a defined order in the aim to satisfy a definite
need.
This thesis examines in particular the incompatibilities that may arise during the composition
of Web services. These incompatibilities may be syntactic, semantic, behavioral, or on quality
of service. For each of these incompatibility types, we propose a verification approach in an
appropriate formal framework.
Keywords: Web Service, Composition, Compatibility.
‫ملخـــص‬
‫ ھذا يشير إلى عملية‬.‫العمل المقدم في ھذه األطروحة انضم إلى األعمال الخاصة بالميدان الواسع لتركيب خدمات الويب‬
،‫ باستعمال عملية االكتشاف الديناميكية‬،‫ و ذلك من خالل أبسط خدمات الواب القائمة‬،‫إنشاء خدمة مركبة ذات ميزة جديدة‬
.‫التكامل وتنفيذ ھذه الخدمات في ترتيب محدد جيدا لتلبية حاجة محددة‬
،‫ أوجه عدم التوافق ھذه قد تتعلق بالجوانب النحوية‬.‫يتناول ھذا البحث عدم التوافق الذي قد ينشأ أثناء تكوين خدمات الواب‬
.‫ نقترح منھج تحقق في إطار منھجي مناسبة‬،‫ لكل من ھذه األنواع من عدم التوافق‬.‫الداللية والسلوكية أو نوعية الخدمة‬
.‫ توافق‬،‫ تركيب‬،‫خدمة الواب‬: ‫الكلمات المفاتيح‬
7
Table des figures
1.1: Modèle Fonctionnel de l’architecture SOA…………………………………11
1.2: Principe de Fonctionnement des Services Web……………………………..14
1.3 : Exemple de document XML………………………………………………..15
1.4 : Structure d’un message SOAP……………………………………………..17
1.5 : Spécification d’un service Web avec WSDL………………………………18
2.1 : Etapes de réalisation d’une composition de services………………………23
2.2 : Orchestration et chorégraphie des services web……………………………25
3.1 : Exemples de services web syntaxiquement incompatibles…………………35
3.2 : Compatibilité sémantique..............................................................................36
3.3 : Exemple d’incompatibilité de comportement entre services……………….37
3.4 : C faiblement compatible mais n’est pas compatible……………………….38
4.1 : Exemples de compatibilité/incompatibilité syntaxique…………………….45
4.2 : Modélisation d’un service de réservation des billets de vol en ligne
à l’aide des LTS………………………………………………………...…..49
4.3 : Ajout d’une opération dans une séquence………………………………….50
4.4 : Suppression d’une opération dans une séquence…………………………...51
4.5 : Exemples de (in)compatibilité des types de données………………………53
4.6 : Principe d’un médiateur……………………………………………………55
4.7 : Adaptation structurelle……………………………………………………..55
4.8 : Adaptation de type de données……………………………………………..56
5.1 : Les classes supérieures d’une ontologie OWL-S…………………………..60
5.2 : Correspondance sémantique entre deux services web……………………...61
5.3 : Correspondances identique et de généralisation entre les paramètres des services
Web………………………………………………………………………………...63
6.1 : Incompatibilité due à l’hétérogénéité des comportements……………….…67
6.2 : Modélisation de services Web à l’aide des SWN…………………………..70
6.3 : Siphons dans un Réseau composite…………………………………………73
7.1 : Gestion de QdS dans l’architecture des services Web………………………82
7.2 : Fonctions d’agrégation pour le calcul de la qualité de service selon
la structure du composite…………………………………………………….83
7.3 : Exemple d’utilisation de la fonction d’agrégation sur une composition
de services Web………………………………………………….…………..84
8.1 : Représentation schématique du scénario…………………………………….88
8.2 : Architecture systématique du scénario………………………………………90
8.3 : Représentation du processus de vérification…………………………………91
8.4 : Compatibilité syntaxique entre les deux interfaces………………………….92
8.5 : Incompatibilité syntaxique entre les deux interfaces………………………...92
8.6 : Illustration d’un cas incompatible……………………………………………94
8.7 : Réseaux de Petri de la composition du scénario de la Figure 8.6……………94
8.8 : Exemple sur la composition de l’agence de voiture……………………….…95
8
Table des matières
Introduction
Contexte..…………………….……………………….……………………………..………...6
Problématique…..………………….….……………………………………………...………..7
Objectif…………………………………….……………………………………………..…....8
Organisation de la thèse………………………………………………………………...……...8
Partie1 : Composition et Compatibilité dans les Services Web
Chapitre 1 : Généralités sur les services Web
1. Introduction…………………………………………..…………………….………...10
2. Architecture orienté service(SOA)…….… ………….………………….…….…..…..10
2.1 Notion de Service…………………...........…………………………….……......10
2.2 Modèle fonctionnel du SOA………………………………….……………......11
3. Service Web………………………………………………….………….………...…...12
3.1 Définition……………….………………………………………….…...…........12
3.2 Propriétés d’un service Web…………………………………...………...….......13
4. Principe de fonctionnement des services Web..……….………………………….......13
5. Principaux standards des services Web ……...………………….……………….......15
5.1 XML (« Extensible Marckup Language ») ..…………………………...…........15
5.2 SOAP (« Simple Object Acces Protocol ») …..…………………...…................16
5.3 WSDL (« Web Service Description Language ») ………………………….......17
5.4 UDDI (« Universal Description Discovery and Integration ») ……….………...19
6. Conclusion……………………………………………………………………………..20
Chapitre 2 : Composition des Services Web
1. Introduction……………………………………………………………………………22
2. Définition…………...………………………………….………………….…………...22
3. Types de composition des services Web………………….…………………...………24
3.1- Orchestration/Chorégraphie………………………………..……………………..24
3.2- Composition Statique/Dynamique……………..……..…..………………………25
4. Degré d’automatisation d’une composition des services ….……..…………...………27
4.1- Composition Manuelle…………………………….…………..………………….27
4.2- Composition Semi-automatique……………………………….…………………27
9
4.3- Composition automatique…………………….…………………..………………27
5. Techniques de composition des services web…….……………….….……..……..…..27
5.1 Composition par Workflow………..…………………….………………….….28
5.2 Composition orientée intelligence artificielle…………………………….…….29
6. Langages de composition des services Web………………………………………....31
7. Conclusion……………………………………………………………………………32
Chapitre 3 : Compatibilité des Services Web dans une Composition
1. Introduction …………………………………………..………….………………….34
2. Notion de compatibilité dans une composition………..………….…………………34
3. Types de compatibilité……………………………………...……………………….35
3.1 Compatibilité Syntaxique………………………………..……………………...35
3.2 Compatibilité Sémantique……………………..……………………………..…36
3.3 Compatibilité Comportementale…………….…………………………………..36
a- Compatibilité Faible/Forte………………………….…………………………37
b- Compatibilité Totale/Partielle…………..……………………………………..38
3.4 Compatibilité de QdS………………………………….……………………….39
4. Conclusion…………….………..……………………………………………………40
Partie2 : Vérification de compatibilité des services Web
Chapitre 4 : Vérification de la compatibilité Syntaxique
1.Introduction…… ……………………………………………………………….….43
2. Définition Informelle………………….….………....………………………….….44
3. Exemples………………..………………….………...……….………………….…44
4. Approches de vérification existantes…………………...…..……………………….45
5. Approche proposée…………………………………...…….…….…………………46
5.1. Vérification de la compatibilité structurelle…………….…..………………….46
5.1.1 Cadre formel………..……………………………….……………………..47
5.1.2. Exemple……………………….…………………….…………………….48
5.1.3. Définition formelle : (Compatibilité structurelle)……………..…………50
5.1.4 Principe de vérification……………………………...…………………….50
5.1.5. Algorithme de vérification………………………………………..……….51
5.2. Vérification de la compatibilité des types des données……………….………..52
5.2.1. Définition formelle : (Compatibilité des types de données)…..…………..53
5.2.2. Exemple….…………………………...……………………………………53
5.2.3. Principe de vérification…………………………………………..………..53
5.2.4. Algorithme de vérification………………………………………………...54
6. Génération d’adaptateur………………………………………………………….…55
7. Conclusion…………………………………………………………………………..56
10
Chapitre 5 : Vérification de la compatibilité Sémantique
1.
2.
3.
4.
Introduction………………………………………………………………………58
Définition informelle……………………………………………...………………58
Approches de vérification existantes…………………………………………...…58
Approche proposée………………………………………………………………..59
4.1 Cadre formel……………………………………………………………..……59
4.2 Définition formelle………………………………………………………..…..60
4.3 Principe de vérification…………………………………………….………….61
4.4 Algorithme de vérification…………………………………………………….62
4.5 Exemple……………………………………………………………………….63
5. Conclusion…………………………………………………………………...……64
Chapitre 6 : Vérification de la compatibilité Comportementale
1. Introduction………………………………………………………………..……..66
2.
3.
4.
5.
Définition informelle (compatibilité comportementale)………………………….66
Exemple…………………………………………………………………………..67
Approches de vérification existantes……………………………………….…….67
Approche proposée…………………………………………………………...…..68
5.1 Cadre formel………………………………………………………………….68
5.2 Exemple………………………………………………………………………70
5.3 Définition formelle (compatibilité comportementale)………………………..71
5.4 Algorithme de vérification……………………………………………....……75
6. Conclusion………………………………………………………………….…….76
Chapitre 7 : Vérification de la compatibilité de QdS
1. Introduction…………………………………………………………….…….…78
2. Définition informelle…………………………….……………………….……...79
3. Approches de vérification existantes………….……………………….……..…79
4. Approche proposée…………………………………………… ;……….….……80
4.1 Critères de qualité pour services élémentaires………………………....……80
4.2 Critères de qualité pour service composite……………….…………..……..82
4.3 Exemple………………………………………………………….…….……84
4.4 Algorithme de vérification………………………………………..…..……..86
11
5. Conclusion……………………………………………………………………….86
Partie3 : Etude de cas
Chapitre 8 : Etude de Cas
1.
2.
3.
4.
Introduction…………………………………………………..………………..88
Description……………………………………………………………….…….88
Déroulement du processus de vérification………………………………..……91
Conclusion………………………………………………………………....…..96
Conclusion générale
Références Bibliographiques
97
99
12
Introduction
1.
Contexte......................................................................................................................................... 14
2.
Problématique................................................................................................................................ 10
3.
Objectif .......................................................................................................................................... 11
4.
Organisation de la thèse................................................................................................................. 11
13
1. Contexte
De nos jours, les systèmes logiciels sont devenus indispensables dans de nombreux domaines.
La taille et la complexité des logiciels est en croissance continue. Les systèmes informatiques
sont devenus de plus en plus complexes et hétérogènes avec un marché toujours plus exigeant
et évolué en matière de performance, d’efficacité, d’innovation, de compétitivité et de
productivité. Les développeurs doivent ainsi faire face à de nouveaux défis tels que:
L’évolution qui s’exprime comme une combinaison de plusieurs facteurs : l’évolution des
plates-formes d’exploitation et d’exécution,
l’évolution des technologies
d’implémentation des logiciels, l’évolution des outils de développement, et l’évolution des
exigences des utilisateurs (qui désirent que les logiciels soient de plus en plus évolutifs et
que ces évolutions soit réalisées le plus rapidement possible).
La complexité des logiciels liée, en général, aux besoins propres des domaines applicatifs
et à la complexité des plateformes technologiques.
La Diversité et hétérogénéité qui peut être sur plusieurs axes tels que les outils, les
technologies d’implémentation, et les composants logiciels à intégrer.
L’intégration qui permet de réduire le coût de développement des logiciels en réutilisant le
plus possible les différents artéfacts dont ils disposent ( logiciels, sources de données, ou
des bases de données déjà créées,…).
Face à ces besoins, l’approche orientée services [1] est apparue comme une solution
efficace. Elle propose de construire des applications à partir d’entités logicielles qui peuvent
être fournies par des organisations différentes. Ces entités sont nommées services. Un service
fournit une fonctionnalité qui, pour être mise à disposition, est spécifiée, de façon syntaxique
et/ou sémantique, par une description de services. La description des services permet aux
éventuels clients de rechercher, découvrir et par la suite appeler un service. De manière idéale,
ce protocole (découverte, sélection, invocation) peut être réalisé à l’exécution, cela donnant
lieu à la création d’applications dynamiques utilisant des services disponibles à un moment.
Les principes de l’approche orientée service ont été promus essentiellement avec le
développement des services Web [2] [3]. Ces derniers ont pour vocation de favoriser une
architecture orientée services SOA (« Service Oriented Architecture ») [1] pour l’intégration
des applications et les interactions dans un environnement hétérogène et versatile qui est le
Web.
14
La notion de « service web » désigne essentiellement une application (un programme) mise à
disposition sur Internet par un fournisseur de service. Leurs particularités par rapport aux
autres technologies de l'informatique répartie est l’utilisation de la technologie Internet
comme infrastructure pour la communication entre eux.
Dans le but de fournir des fonctionnalités de plus en plus élaborées, la composition [4] des
services Web joue un rôle primordial et constitue une évolution naturelle de cette technologie.
En particulier, si aucun service Web simple ne peut satisfaire une requête d’un client, il
devrait y avoir une possibilité de combiner (composer) un ensemble de services Web existants
pour accomplir cette requête.
La composition des services permet donc de créer des applications et des processus en
fonction d’une requête d’un client à l'aide de services issus d'environnements hétérogènes,
quelque soient les détails et les différences de ces environnements. Du coté du client, cette
composition semblera un unique service. La composition sera transparente au client, même si
elle met en jeu la combinaison de plusieurs services Web. A titre d’exemple, nous pouvons
modéliser le service de planification de voyage d’une agence de voyages comme la
composition de plusieurs services Web atomiques (basiques) appartenant à des
organisations différentes : réservation de vol, réservation d’hôtel et location de véhicules.
2. Problématique
Malgré les efforts de recherche et de développement autour de la composition des services,
elle reste une tâche hautement complexe et pose un certain nombre de défis. Sa complexité
provient généralement des sources suivantes :
• L’augmentation dramatique du nombre des services sur le Web rend très difficile la
recherche et la sélection des services pouvant répondre à un besoin donné.
• Les services sont créés et mis à jour de façon hautement dynamique.
• Les services Web sont d’habitude développés par différentes organisations qui
utilisent différents modèles conceptuels pour décrire leurs caractéristiques.
• La modularité constitue une caractéristique importante des services Web, par
conséquent, les services Web composites doivent garder récursivement les mêmes
caractéristiques que les services Web basiques à savoir auto-descriptifs, interopérables,
et facilement intégrables.
La coopération entre les services pour offrir un nouveau service composite, peut s’avérer une
tâche dure puisque l’opération de composition est souvent confrontée à des problèmes
d’incompatibilité entre les services. Ces incompatibilités sont dues au fait que les services
Web sont développés indépendamment les uns des autres et dans différentes parties du
monde.
Ces incompatibilités peuvent être de différents types :
•
•
•
•
Elles peuvent concerner la structure des interfaces des services (nombre et types de ports
d’entrées/sortie).
Elles peuvent être dues à des différences syntaxiques et/ou sémantiques des données
échangées entre les services.
Elles peuvent être d’ordre comportemental où la coopération des services composés
donne un comportement anormal de l’ensemble (tel que l’inter-blocage).
Elles peuvent concerner des aspects de qualité de service (QdS) où la composition fournit
un service composite de qualités non satisfaisante.
Ces incompatibilités entre services Web peuvent avoir des conséquences néfastes sur la
composition telle que le blocage lors de l’exécution. Il est donc nécessaire de vérifier la
compatibilité entre les services Web pour promouvoir la correction et la cohérence des
interactions.
3. Objectif
Dans le cadre de cette thèse, nous nous focalisons sur la vérification de la compatibilité des services
Web en vue d’une composition. Pour cela, les problèmes auxquels il faut répondre et les aspects
auxquels nous nous intéressons sont multiples :
•
•
•
Une première étape consiste à étudier les principaux types d’incompatibilités qui peuvent
surgir lors d’une composition.
Ensuite nous présentons un état de l’art des approches de vérification existantes pour chaque type
de compatibilité.
Enfin nous proposons une approche de vérification pour chacun de ces types d’incompatibilité.
Chacune des approches de vérification proposées sera basée sur un cadre formel approprié (s’il
existe) car certains types de compatibilité sont plus simples à vérifier dans un formalisme
que dans un autre.
•
Notre contribution sera illustrée par une étude de cas.
4. Organisation de la thèse
Cette thèse est divisée en trois parties.
La première partie, est consacrée à la présentation du domaine de notre étude et les
principaux concepts utilisés dans cette thèse. Elle contient trois chapitres :
•
Chapitre 1 présente une introduction au domaine des services Web, leur architecture ainsi
que leurs différents standards XML, SOAP, WSDL, UDDI.
•
Chapitre 2 donne un aperçu sur la composition des services Web. Il décrit l’approche de
composition, et cite ses différents types. Il évoque également les différentes techniques et
les principaux langages de la composition des services Web.
11
•
Chapitre 3 s’intéresse aux différents aspects de la compatibilité ( compatibilité
syntaxique, sémantique, comportementale et QdS ) des services Web pour s'assurer que
les interactions réciproques entre eux ne conduisent pas à des conflits ou à des blocages.
La deuxième partie est consacrée à notre contribution et se focalise en particulier sur la
vérification de la compatibilité entre les services Web. Elle est divisée en quatre chapitres,
chacun d’eux traitant un type de compatibilité.
•
Chapitre 4 est consacré à la compatibilité syntaxique. Il présente l’état de l’art dans ce
domaine. Ensuite il détaille l’approche que nous proposons avec le cadre formel pour la
vérification de ce type de compatibilité.
•
Chapitre 5 est destiné à la compatibilité sémantique. Il évoque les principaux travaux
correspondants, et présente notre approche de vérification de cette compatibilité.
•
Chapitre 6 est dédié à la compatibilité comportementale des services Web. Il évoque les
principales investigations entreprises dans ce domaine et présente notre approche de
vérification avec son cadre formel.
•
Chapitre 7 s’intéresse à la compatibilité au niveau qualité de service. Il survole quelques
travaux du domaine et donne une présentation de notre approche de vérification de ce
type de compatibilité.
La dernière partie est réservée pour une étude de cas pour mieux illustrer notre contribution.
12
Chapitre 1
Généralités sur les services Web
1.
Introduction ................................................................................................................................... 14
2.
Architecture orientée service (SOA) ............................................................................................. 14
3.
2.1
Notion de Service .................................................................................................................. 14
2.2
Modèle fonctionnel du SOA.................................................................................................. 15
Service Web .................................................................................................................................. 16
3.1
Définition............................................................................................................................... 16
3.2
Propriétés d’un service Web .................................................................................................. 17
4
Principe de fonctionnement des services Web .............................................................................. 17
5.
Principaux standards des services Web ......................................................................................... 19
5.1. XML (« Extensible Marckup Language »)................................................................................. 19
5.2. SOAP (« Simple Object Access Protocol») .............................................................................. 20
5.3. WSDL (« Web Service Description Language ») ...................................................................... 22
5.4 UDDI («Universal Description, Discovery and Integration»).................................................... 23
6.
Conclusion ..................................................................................................................................... 24
[1] [2] [3] [4]
13
1. Introduction
Les services Web poursuivent un vieux rêve de l'informatique distribuée où les applications
pourraient inter-opérer à travers le réseau, indépendamment de leur plate-forme et de leur
langage d'implémentation. Ils sont considérés comme étant l´évolution naturelle du Web où
on peut distinguer trois phases de développement [5]:
•
•
•
Les Documents Web, le phénomène Internet originel, utilisé principalement par des
organisations et des particuliers pour publier des informations sur leur travail, leurs
produits, …etc.
Les applications Web, le progrès grâce auquel les entreprises ont commencé à utiliser
le Web à des fins commerciales. Les sites Internet sont devenus plus interactifs, et
plus complexes, gérés par des serveurs d’applications, capables de distribuer leur
charge avec d’autres serveurs, en fonction des besoins.
Les Services Web est la phase émergente, dans laquelle les serveurs d’applications
précédents communiquent désormais entre eux. Cette évolution a été poussée par le
désir de pouvoir réaliser des échanges interentreprises dans un environnement
automatisé et ouvert tel qu’Internet.
De nos jours, les services Web sont devenus un domaine de recherche à part entière. Ils
suscitent beaucoup d’intérêt de la part de chercheurs dans des communautés très variées. On
peut citer à titre d’exemple, le génie logiciel, les bases de données, la modélisation des
entreprises et la représentation des connaissances ou les multi-agents.
Dans ce chapitre, nous allons présenter l’architecture orientée service et les concepts généraux
des services Web. Nous présenterons la pile des technologies des services Web tout en
mettant en relief la multitude de standards et de technologies existants.
2. Architecture orientée service (SOA)
L’architecture orientée service désignée par le vocable de SOA (« Service Oriented
Architecture »), est un style d’architecture [1] permettant de construire des systèmes
informatiques évolutifs et adaptables, en améliorant leur qualité et en simplifiant leur
intégration dans l’infrastructure informatique de l’entreprise, par recours à des composants
réutilisables appelés services. Dans ce qui suit, nous présentons les concepts sur lesquels
repose l’architecture SOA.
2.1
Notion de Service
Le terme de service est un terme clef du SOA. Il est inspiré des services simples et
réutilisables du monde réel tel que le service de distribution de billets automatique. Au sens
14
SOA, un service est un programme autonome, réutilisable, qui peut être invoqué par un
utilisateur ou un autre service.
Plus précisément, un service expose donc un ensemble d’opérations (fonctionnalités) mises à
disposition par un fournisseur à l’attention d’un(ou de plusieurs) client(s) selon un ou des
contrats prédéfinis.
2.2
Modèle fonctionnel du SOA
Le modèle SOA est un modèle (abstrait) qui définit un système par un ensemble de
composants logiciels distribués qui collaborent afin de réaliser une fonctionnalité globale
préalablement établie. Ce modèle permet de répondre aux problèmes d'intégration dans les
architectures logicielles en facilitant l’ajout et la suppression d’un module sans remettre en
cause toute l'architecture [6].
L'architecture SOA vise trois objectifs importants [7]:
(i)
(ii)
(iii)
Identification des composants fonctionnels,
Définition des relations entre ces composants et
Etablissement d’un ensemble de contraintes sur chaque composant de manière à
garantir les propriétés globales de l’architecture.
Cette architecture s’articule autour d’un « médiateur » central qui garantie la publication des
services proposés par des fournisseurs au profit des futurs clients. Les trois opérations de base
de cette architecture sont la publication de la description, la découverte du service suite au
déclenchement de la recherche et l’interaction entre le client et le fournisseur par invocation.
La Figure 1.1 montre le modèle fonctionnel de l’architecture SOA.
Client
3. invocation
2. Recherche
Fournisseur de Service
1. Publication
L'annuaire
de service
Figure 1.1: Modèle Fonctionnel de l’architecture SOA.
L'architecture SOA comprend trois acteurs : [8]
Le fournisseur du service : il désigne l'entité propriétaire du service. D'un point de
vu technique, un fournisseur est constitué par la plate-forme d’accueil du service.
15
Le client ou demandeur du service : C’est le consommateur de service. D’un point
de vue technique, le service client est constitué de l’application qui va rechercher et
invoquer un service.
L'annuaire de service : Correspond à un registre de descriptions de services offrant
des facilités de publication de services à l’intention des fournisseurs ; et des facilités
de recherche de services à l’intention des clients. En d'autres termes, l'annuaire joue le
rôle d'intermédiaire entre les clients et les fournisseurs de services.
3. Service Web
L’approche la plus répandue pour mettre en œuvre une architecture SOA est l’utilisation de
services Web. Les services Web visent à la transposition des SOA dans le cadre du Web.
Le terme « service Web » désigne essentiellement une application (un programme) mise à
disposition sur Internet par un fournisseur de service, et accessible par les clients à travers des
protocoles Internet standards [9] [10].
3.1
Définition
Il y a actuellement autant de définitions des Services Web que de sociétés qui en proposent.
La définition communément admise, d’un point de vue technique, définit un Service Web
comme :
« un composant logiciel implémenté dans n'importe quel langage, déployé sur n'importe
quelle plate-forme et enveloppé dans une couche de standards dérivés du XML(« eXtensible
Markup Language »). Il doit pouvoir être découvert et invoqué dynamiquement par d'autres
services » [10].
Un service Web est donc un composant logiciel qui offre des services à travers une interface
standardisée. La particularité des services Web réside dans le fait qu’ils utilisent la
technologie Internet comme infrastructure pour la communication entre les composants
logiciels (les services Web) et ceci en mettant en place un cadre de travail basé sur un
ensemble de standards.
L'avantage de ce modèle tient du fait qu’il est possible de présenter ces services comme des
"boîtes noires". En fait, les entrées-sorties d'un service sont gérées au sein de messages dont
on connaît le format grâce à des interfaces clairement exposées mais sur lesquels
l'implémentation interne du traitement n'influe pas au niveau de la structure. Ceci permet un
haut niveau de modularité et d'interopérabilité. L'avantage du modèle est qu'il permet de
s'abstraire de l'architecture, du langage ou encore de la plate-forme qui va supporter le
16
service: il suffit juste que le message respecte une structure donnée pour qu'il puisse être
utilisé.
L’objectif ultime de l’approche service Web est de transformer le Web en un dispositif
distribué de calcul où les programmes (services) peuvent interagir de manière intelligente en
étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en
des services plus complexes [10] [11] [12].
3.2
Propriétés d’un service Web
Le consortium W3C1 [7] définit un service Web comme étant une application ou un
composant logiciel qui vérifie les propriétés suivantes :
•
•
•
•
Les services Web peuvent être définis, décrits et découverts à travers le Web qui
permet une accessibilité facile. Non seulement les utilisateurs de services Web
peuvent localiser les services appropriés, mais les services eux-mêmes peuvent se
décrire et s’annoncer de sorte qu’il leur soit possible d’interagir entre eux.
Un service Web est complètement indépendant des langages de programmation et des
systèmes d’exploitation.
Un service Web est localisé automatiquement via un mécanisme de recherche simple.
Les services Web sont décrits par des langages standards basés sur XML. Bien que les
services Web puissent être implémentés par différents langages de programmation,
leurs interfaces sont décrites par des langages XML standards.
Les services Web répondent à une double demande : celle d’un échange sûr et celle d’un
échange ouvert. Il s’agit de donner les moyens à deux applications de s’échanger simplement.
L’échange ouvert est permis, puisqu’un serveur ne doit pas nécessairement connaître à
l’avance son client pour offrir son service vers l’extérieur [2]
Pour les avantages évoqués ci-dessus, les services Web sont aujourd’hui de plus en plus
employés dans les entreprises pour construire des applications orientées Business ou Web.
Grace à cette technologie les entreprises peuvent faire communiquer leurs systèmes
d’informations avec ceux de leurs clients ou partenaires, via Internet.
Principe de fonctionnement des services Web
Le principe de fonctionnement des services Web est représenté dans la Figure 1.2. Il est fondé
sur le model fonctionnel du SOA et sur des standards basés sur XML.
17
Client
5. Réponse à l’Invocation
• Recherche/Localisation
• Lier (bind)/Connecter
• Invocation
4. Invocation (SOAP)
Fournisseur de services
• Implémentation
• Déploiement
• Description et publication
service/méthodes
2. Recherche WSDL
WSDL
1. Publication
3. Réponse à la Recherche
Annuaire
de
Services
UDDI
Figure 1.2: Principe de Fonctionnement des Services Web
Les interactions dans lesquelles les trois acteurs (fournisseur, client, annuaire) peuvent
s’engager sont décrites par les cinq opérations suivantes [3] :
a). Publication: le fournisseur de services déploie le SW sur un serveur et génère une
description du service (WSDL :Web Service Description Language). Il doit la publier
dans l’annuaire de services (UDDI : Universal Description, Discovery and
Integration) afin de permettre aux futurs utilisateurs de prendre connaissance des
caractéristiques du service. Cette opération consiste en la fourniture des informations
concernant le fournisseur (Information commerciales), relatives au service lui-même
(les fonctions assurées) ainsi que les informations techniques (méthode d’invocation,
adresse…etc.).
b). Recherche du service : le client du service Web lance une recherche auprès de
l’annuaire (UDDI) qui peut être public ou privé par l’envoi d’une requête encapsulée
dans une enveloppe SOAP (Simple Object Access Protocol) afin de rechercher le(s)
service (s) répondant à ses besoins. Dans le cas de plusieurs réponses, des techniques
de sélection de services sont offertes (premier trouvé, aléatoirement) ou sur la base de
paramètres techniques telle que la Qualité de service (QdS) (Contraintes non
fonctionnelles).
18
c). Réponse à la recherche: Le résultat de la recherche dans l’annuaire est un fichier
WSDL qui sera transmis, dans un message SOAP, au client demandeur. Ce fichier
contient la description du service et les informations techniques nécessaires pour son
invocation.
d). Invocation: Le client utilise la description du service qui existe dans le fichier WSDL,
et interagit directement avec le fournisseur du service. Il envoie un message SOAP,
contenant en plus du (des) nom(s) de(s) l’opération(s) à exécuter et de ses paramètres,
l’adresse (URI) et le type de protocole de communication (HTTP). Techniquement,
cette invocation est basée sur un appel de procédure à distance (RPC).
e). Réponse à l’invocation: Le fournisseur réagit à la réception du message d’invocation
de la part du client en envoyant au client la réponse résultant de l’exécution de la
procédure. Cette réponse est transmise sous la forme d’un document XML via SOAP.
5. Principaux standards des services Web
f).
Une caractéristique qui a permis un grand succès de la technologie des services Web est
qu’elle est construite sur un certain nombre de technologies standards de l’industrie. En
commençant par XML, comme langage de base commun ensuite les trois principaux
standards qui sont : SOAP, WSDL et UDDI que nous détaillons ci-dessous.
5.1. XML (« Extensible Marckup Language »)
XML [13] est un langage de balisage, il a été soumis auprès du W3C [14] en 1998. XML est
inspiré du langage SGML (Standard Generalized Markup Language) et de l’expérience
d’utilisation de http pour aboutir à une technologie infiniment plus flexible et plus simple à
utiliser. De ce fait, XML est alors flexible et extensible, et est devenu rapidement le standard
de représentation et d’échange de documents sur Internet. Sa simplicité, sa portabilité sur
différentes plate-formes, son auto-description ainsi que son extensibilité ont conduit à sa
grande popularité et son adoption comme standard d’échange à travers le Web.
Un document XML est un arbre composé d’un ensemble d’éléments structurés sous forme de
balises. Cette structuration hiérarchisée ouvre la voie au traitement automatique du document
pour l’extraction d’information de leur structure aussi bien que de leur contenu.
19
<personne>
<nom>
<prenom>Mohamed</prenom>
<nomdefamille>Khalil</nomdefamille>
</nom>
<adresse>
<numero>28</numero>
<rue> rue des martyres</rue>
<ville>Constantine</ville>
<pays>Algérie</pays>
</adresse>
</personne>
Figure 1.3 : Exemple de document XML.
Il existe une panoplie d’outils permettant l’exploitation des documents XML. Parmi celles-ci
nous pouvons citer [14] :
• XPath: pour définir la manière d’adresser des parties d’un document XML.
• XQuery: s’intéresse à la structure logique abstraite d’un document XML.
• XSL : pour définir la présentation de document XML.
Un ensemble de standards basés sur XML et traitants des différents aspects inhérents au
déploiement des services Web s’est développé et se développe encore. Ces spécifications
émanant de constructeurs et consortium divers permettent de construire des services Web,
d’assurer l’interopérabilité entre composants applicatifs et de garantir des conditions
opérationnelles d’exploitation réelles de manière à:
• Assurer le fonctionnement et le déploiement des services Web: SOAP, WSDL,
UDDI…
• Effectuer l’échange de données dans un contexte de commerce interentreprises: xCBL
RosettaNet, …Etc.
• Assurer l’intégration de processus collaboratifs sur le Web (Workflow): BPML,
XLANG, BPEL …
• Fournir des mécanismes de sécurité: XKMS …
Nous détaillerons dans ce qui suit les 03 standards de base: SOAP, WSDL et UDDI.
5.2. SOAP (« Simple Object Access Protocol»)
SOAP est un standard proposé par W3C [15]. C’est un protocole à la fois simple et léger
destiné à l'échange d'informations. SOAP est un protocole de type RPC (Remote Procedure
Call) d’échange de messages entre Web services, standard ouvert et entièrement basé sur le
langage XML pour assurer l’interopérabilité entre composants et les appels de procédures
20
distantes (RPC). Ce protocole ne requiert aucune plate-forme spécifique, ni d’exigence
particulière en ce qui concerne l’implémentation de l’application. Au contraire, ce mécanisme
fournit une sémantique tout à fait indépendante des contraintes techniques et, de fait,
compréhensible par tous. Dans la pratique, le transfert est le plus souvent assuré via le
protocole HTTP. SOAP peut cependant reposer sur d’autres protocoles de transport comme
par exemple SMTP ou JMS (Java Message Service) mais HTTP est le plus populaire.
Un message SOAP est un document XML encapsulé dans une enveloppe permettant
d’organiser les informations d’une manière qu’elles puissent être échangées entre partenaires.
Il existe deux types de messages SOAP [16] :
• Request : il inclut le nom de la méthode à invoquer et la liste de ses paramètres.
• Response : il inclut le résultat de la méthode invoquée dans le message Request.
Un message SOAP est structuré comme le montre la Figure 1.4 [16] où :
<Envelope> : c’est l’en-tête de tous les messages SOAP dans lequel on distingue entre
les différentes versions existantes, (1.1, 1.2).
<Body> : c’est le corps du message SOAP dans lequel le type de message est spécifié,
soit il s’agit d’un message Request ou Response.
<Header> : optionnel, il indique que le message SOAP doit être traité par plusieurs
intermédiaires.
SOAP Enveloppe
SOAP Header
Attributs
SOAP Body
Appels de méthodes et
données
Figure 1.4: Structure d’un message SOAP.
SOAP a pour objectif de [3] :
• Offrir un format de message pour les communications entre partenaires, décrivant
comment les informations à échanger sont structurées dans un document XML.
21
•
Définir les conventions nécessaires à l’appel de procédures à distance pour invoquer
un service par un client, en envoyant un message SOAP, et comment le service répond
par un autre message SOAP.
• Décrire comment un message SOAP doit être transporté au dessus de HTTP ou
SMTP.
Il s’agit, donc, d’un mécanisme fondamental pour assurer l’interaction et le dialogue entre
applications distribuées dans un environnement services Web, du moment que clients et
fournisseurs peuvent formuler, transmettre et comprendre les messages SOAP échangés.
5.3. WSDL (« Web Service Description Language »)
WSDL décrit les services Web et, particulièrement, leur interface dans le format XML. En
plus de la spécification des opérations offertes par le service, WSDL décrit les mécanismes
pour l’accès aux services Web (Protocole de communication) et sa localisation (URI), afin de
préciser où envoyer les messages SOAP. Un document WSDL décrit essentiellement le nom
de la méthode utilisée, son nombre de paramètres, et leur type, ce qu'un service Web offre, où
il est hebergé et comment on peut l'invoquer.
Les objectifs de WSDL[17] sont:
• Décrire les interfaces des services en précisant les opérations offertes et leur signature
(Paramètres d’Entrée/Sorties et types). Ces interfaces constituent les contrats que les
clients doivent respecter pour pouvoir interagir avec le service.
• Préciser le (s) protocole (s) d’accès au service (HTTP, SMTP…).
• Fournir la localisation du service où il peut être invoqué (URI).
• Définir une description de la sémantique du service par la fourniture des informations
permettant, éventuellement, aux développeurs de traiter la sémantique des services.
La structure globale d’un document WSDL est représentée par la Figure 1.5.
Spécification WSDL
Partie abstraite
Partie concrète
Types
Messages
Opérations
Liaisons (binding)
Services et ports
Types port
Figure 1.5: Spécification d’un service Web avec WSDL.
22
Dans une spécification WSDL, on décrit chaque service Web nouvellement créé par six
éléments [16] :
• Types : définit le type de données échangées entre le client et le fournisseur du service
sous la forme d’un schéma XML.
• Message : Par l'intermédiaire de cette section, on définit le format des messages
échangés. Un message correspond aux données qui seront véhiculées selon les
méthodes invoquées. Chaque méthode du service possède deux éléments message :
Request : inclut les paramètres du message.
Response : inclut les valeurs retournées du message.
Un message à un nom et potentiellement des parties qui font référence à des
paramètres et des valeurs de retour.
• Type de port (portType) : combine plusieurs messages pour former une opération. Il
y a quatre types d’opération : one-way, request-response, solicit-response et
notification. Le document WSDL est constitué d’autant d’élément portType que le
service contient de groupe de méthodes.
• Opération : décrit les opérations invoquées à l’aide des messages reçus, émis par le
service et éventuellement des messages d’erreur.
• Port : est un point d’accès au service identifié de manière unique par la combinaison
d’un binding et d’une adresse internet.
• Rattachement (binding): spécifie le protocole de communication (le plus souvent
HTTP, mais aussi SMTP, FTP, etc.) et le format d’encodage des données (encodage
RPC, Literal Document, etc.) pour les opérations et messages définis par un type de
port donné. Il est possible grâce à des extensions internes de WSDL de définir des
binding SOAP.
• Service : regroupe un ensemble de ports. Chaque port offre une alternative (différents
protocoles, etc.) pour accéder au service.
Ainsi, la spécification WSDL joue un rôle important dans l'interopérabilité des services Web.
Moyennant cette spécification, WSDL permet aux services de définir ce qui est nécessaire à
leur invocation et à la réception de leur résultat. La spécification WSDL sépare la définition
abstraite du service (échange de messages) de ses mécanismes de liaison (définition des
protocoles applicatifs). Cette dernière caractéristique permet au service d'interagir même si
l'application a été modifiée ce qui est un point important pour assurer l'interopérabilité des
services.
5.4 UDDI («Universal Description, Discovery and Integration»)
Un troisième standard a été conçu pour réduire l’écart entre les applications clientes et les
services Web, appelé UDDI [18]
Contrairement à SOAP et WSDL, UDDI n’est pas supporté par le W3C mais par le
consortium OASIS [19]. UDDI est un annuaire mondial d’entreprises s’appuyant sur le réseau
Internet. Il permet d’automatiser les communications entre prestataires, clients, … etc.
23
UDDI est une spécification qui définit les mécanismes qui permettent aux entreprises de
publier leurs services et de découvrir et interagir avec d'autres services via le Web. UDDI se
comporte lui-même comme un Web service dont les méthodes sont appelées via le protocole
SOAP. Les opérations pouvant être effectuées concernent la recherche, la navigation, l’ajout
et la suppression de services. UDDI permet aux développeurs de découvrir les détails
techniques d’un service Web (le WSDL) ainsi que les informations orientées métier. Par
exemple, en utilisant UDDI, il devient possible de répertorier tous les services Web reliés aux
informations boursières, implémentés sur HTTP, et qui sont gratuits d’utilisation. De plus,
UDDI permet de fournir un niveau d’indirection permettant un couplage faible entre les
services d’une composition. Concrètement un répertoire UDDI est un fichier XML qui décrit
un business et les services qu’il offre.
Les objectifs de l’annuaire UDDI sont [20]
• Offrir un cadre pour la description et la découverte des services Web, en fournissant
des structures de données et des API (Application Programming Interfaces), pour la
publication des descriptions des services dans le registre et pour la découverte de ces
publications pour les clients.
• Soutenir les développeurs dans la recherche des informations concernant le service
afin qu’ils puissent réaliser des clients pour interagir avec ces services.
• Permettre les liens (Binding) dynamiques en offrant aux clients la possibilité
d’interroger le registre UDDI et récupérer les références des services (description
WSDL..) qui les intéressent.
6. Conclusion
L'architecture orientée service (SOA) a été mise en avant afin de faciliter les interactions entre
applications. Cette architecture est construite autour de la notion de service, qui est
matérialisée par un composant logiciel assurant une fonctionnalité particulière et accessible
via son interface.
Le développement rapide des systèmes distribués, et tout particulièrement la « vulgarisation »
de l'accès à Internet a permet l’émergence des services Web qui sont actuellement largement
utilisés et particulièrement promus par, entre autres, Sun, Oracle, HP, Microsoft et IBM.
L'essor incontestable des services Web a permis la naissance d'une nouvelle génération de
systèmes caractérisés par une meilleure intégration d'applications hétérogènes et une
meilleure communication entre ses différents composants.
Les services Web regroupent tout un ensemble de technologies bâties sur des standards
(SOAP, WSDL, UDDI, XML). Ils permettent de créer des composants logiciels distribués, de
décrire leur interface et de les utiliser indépendamment de la plate-forme sur laquelle ils sont
implémentés. La recherche dans ce domaine est très active et s'intéresse entre autres à la
composition, l'orchestration, la sécurité, la sémantique des services Web...etc.
24
Aux termes de ce chapitre, nous avons introduit le domaine des services Web en présentant
leur architecture, leur principe de fonctionnement et leurs standards de base.
Dans le chapitre suivant nous aborderons le concept de composition des services Web.
25
Chapitre 2
Composition des Services Web
1. Introduction ....................................................................................................................................... 27
2. Définition........................................................................................................................................... 27
3. Types de composition des services Web .......................................................................................... 29
3.1- Orchestration/Chorégraphie ....................................................................................................... 29
3.2- Composition Statique/Dynamique ............................................................................................. 30
4. Degré d’automatisation d’une composition des services .................................................................. 32
4.1- Composition Manuelle ............................................................................................................... 32
4.2- Composition Semi-automatique ................................................................................................. 32
4.3- Composition automatique .......................................................................................................... 32
5. Techniques de composition des services web ................................................................................... 32
5.1 Composition par Workflow ........................................................................................................ 33
5.2 Composition orientée intelligence artificielle ............................................................................ 34
6. Langages de composition des services Web .................................................................................... 36
7. Conclusion ......................................................................................................................................... 37
[1] [2] [3] [4] [5] [6] [7] [8] (Fensel, Bussler, & Maedche, Semantic Web Enabled Web
Services, 2002)
26
1. Introduction
Les services Web commencent à se proliférer sur le Web et sont déjà présents dans plusieurs
secteurs d’activité. En effet, plusieurs entreprises exposent leurs services Web aux partenaires
et clients. Cependant, chaque service Web, pris individuellement, ne fournit qu’une
fonctionnalité limitée. Alors que pour réaliser leurs activités réelles, les clients n’invoquent
pas de simples opérations. Ils réalisent, plutôt, des activités complexes ou «processus
métiers». Il devient, alors, opportun de rechercher l’ensemble des services Web disponibles,
de sélectionner les plus satisfaisants et de les combiner pour répondre à la requête du client.
L’application cliente obtenue, peut à son tour être exposée comme service Web. C’est le
principe de la composition des services. Le problème de la composition de services Web se
réfère à la construction des nouveaux services Web « services Web composite » à partir des
services individuels existants. Par exemple, un service de planification de voyage peut être
développé en combinant plusieurs services élémentaires tels que la réservation d’hôtel,
l’achat d’un billet d’avion, location de voiture, … etc.
Dans ce chapitre nous présentons le concept de composition des services Web. Nous citerons
les principaux types de compositions : orchestration/chorégraphie, statique/dynamique. Nous
mettons en relief le fait qu’une composition peut être manuelle ou (semi)automatique. Ensuite
nous montrons que les différentes techniques de la composition peuvent être regroupées en
deux sous familles : les techniques utilisant une approche basée sur les workflows (processus
métier),et celles basées sur les concepts d’intelligence artificielle. Nous évoquerons
également quelques langages et outils de composition.
2. Définition
La composition de services est le mécanisme qui permet l’intégration des services dans une
application [15]. Le résultat de la composition de services peut être un nouveau service,
appelé service composite. Dans ce cas, la composition est dite composition hiérarchique.
La composition de services est aujourd’hui un sujet de grand intérêt autant pour le monde de
la recherche que pour le monde industriel. De nombreuses recherches visent à développer des
modèles de composition de services et à fournir les outils nécessaires pour la composition de
services.
La réalisation d’une application par composition de services comporte plusieurs étapes (voir
la Figure 2.1) qui permettent le passage incrémental d’une spécification abstraite vers une
composition concrète de services, c’est à dire une composition prête à être exécutée [16].
27
1. Définition abstraite
Identification des services abstraits
Liaisons
2. Planification
Identification des fournisseurs
des services disponibles
Services candidats
3. Construction
Sélection des services utilisés
Adaptation
Configuration
Interroge fournisseurs
disponibles
Registre
des services
Publie description
de services
Récupère services concrets
Dépôt de
composants
services
Application
4. Exécution
Invocation des services
Figure 2.1 : Etapes de réalisation d’une composition de services
1. La définition abstraite de la composition de services a comme point de départ
l’identification des fonctionnalités qui doivent être remplies par l’application ainsi créée.
Elle demande l’identification des fonctionnalités abstraites que les différents participants
doivent fournir ainsi que celle des interactions qui auront lieu entre ces participants.
2. La planification identifie les fournisseurs mettant à disposition des services compatibles
avec les besoins fonctionnels identifiés au préalable. Les fournisseurs ainsi identifiés
représentent des candidats pour la réalisation de la composition concrète de services.
3. La construction sélectionne, selon une stratégie donnée, les fournisseurs qui mettent à
disposition les fonctionnalités nécessaires parmi les candidats précédemment identifiés.
Cette étape prépare pour l’exécution les services concrets correspondants : les services sont
configurés et d’éventuelles adaptations sont réalisées. Dans le cas d’un service composite,
la description du service ainsi réalisée est publiée dans un ou plusieurs registres de services
4. La phase d’exécution de l’application ainsi obtenue qui réalise l’invocation des services
préparés au préalable
Malgré son organisation en étapes facilitant une mise en place effective, la réalisation d’une
composition de services reste une activité complexe. Chaque étape est composée d’une ou
plusieurs tâches que les développeurs exécutent parfois manuellement. De plus, de nombreux
28
problèmes d’incompatibilité peuvent survenir à chaque étape de la composition. A titre
d’exemples :
• Lors de la planification, les services sélectionnés ne fournissent pas toujours la
fonctionnalité correspondant aux besoins de la composition. Par exemple, une requête de
fonctionnalité demandant un service Web de < vente d’avions > peut renvoyer comme
résultat aussi bien des services proposant la vente d’avions grandeur nature que d’avions
miniatures pour enfants.
• Lors de la construction, de nombreuses incompatibilités peuvent apparaître entre les
fonctionnements des services Web. Ces derniers peuvent suivre des types d’interactions
différents (requête simple, requête avec réponse, réponse simple, réponse avec accusé de
réception), ou échanger les données selon différentes séquences d’échanges de messages,
• Lors de l'exécution, les données échangées entre les services peuvent présenter des
différences de structure et de signification.
Les développeurs se retrouvent rarement dans la situation idéale où tous les services
nécessaires à la réalisation d’une composition de services sont compatibles. Dans la majorité
des cas, afin de remplir correctement leur tâche, ils doivent résoudre les différentes
incompatibilités des services participants.
3. Types de composition des services Web
Les services Web sont composés quand une requête du client ne peut pas être satisfaite par un
seul service disponible, mais par un service composite obtenu en combinant d’autres services
disponibles. Le problème de la composition de services Web est de synthétiser un nouveau
service composé qui réalise la requête du client, donc de spécifier comment coordonner les
services Web disponibles pour réaliser cette requête. Cette coordination est décrite par un
processus métier (workflow).
3.1-
Orchestration/Chorégraphie
Dans la littérature sur les Services Web, les termes “orchestration” et “chorégraphie” sont
utilisés pour décrire la composition de services dans un flot de processus métier. Elles
constituent une des classifications les plus évoquées en ce qui concerne les types de
composition des services Web.
a). Orchestration
L’orchestration décrit l’interaction des services Web au niveau de messages, incluant la
logique métier et l’ordre d’exécution des interactions. Les services Web impliqués dans cette
orchestration n’ont pas de connaissance (et n’ont pas besoin de l’avoir) d’être mêlés dans une
composition d’un processus métier. Seulement, le coordinateur de l’orchestration (dit aussi
orchestrateur ou moteur d’orchestration) a besoin de cette connaissance.
29
La coordination d'une orchestration d'un service est un processus centralisé qui contrôle et qui
coordonne l'ordre et l'exécution des interactions du service avec les partenaires impliqués dans
la composition.
Une orchestration de Services Web est vue donc comme un « orchestre », où un processus
particulier joue le rôle de chef d’orchestre. Celui-ci coordonne l’exécution des autres services.
Il s’agit d’un point de vue individualiste : les services, à l’exception de l’orchestrateur, n’ont
pas besoin de savoir qu’ils sont mêlés à une composition. Il y a un seul document de haut
niveau représentant les étapes du processus et ce document est seulement connu et traité par
l’orchestrateur. La Figure 2.2(a) illustre ce type de composition.
Service
web1
Service web
coordinateur
Service
web1
Service
web2
(a) Orchestration
Service
web2
Service
web3
(b) Chorégraphie
Figure 2.2 : Orchestration et chorégraphie des services web
b). Chorégraphie
Contrairement à la l’orchestration, la chorégraphie ne nécessite pas de coordinateur central.
Chaque service Web impliqué dans la composition connaît exactement quand ses opérations
doivent être exécutées et avec qui l’interaction doit avoir lieu.
La chorégraphie est de nature plus collaborative, chaque participant impliqué dans le
processus décrit le rôle qu'il joue dans le processus.
Dans une chorégraphie, les services sont vus comme des « danseurs » qui savent exactement
quoi faire et de quelle manière interagir avec leurs partenaires. Il s’agit d’une approche
collaborative où chacun des participants a besoin d’un document dans lequel l’interaction est
décrite. Ces documents mettent l’accent sur l’échange de messages. La Figure2.2 (b) illustre
ce type de composition.
3.2-
Composition Statique/Dynamique
Nous pouvons également classer les types de compositions en deux grandes familles : les
techniques de composition dites « statiques », ou « dynamiques » selon que cette composition
a lieu avant ou pendant l’exécution des services Web.
30
a). Composition statique
Ce type de composition peut être appliqué dans des environnements « stables » où les services
Web participants sont toujours disponibles et où le comportement du service composite est le
même pour tous les clients. La composition des services web prend place durant la période de
conception. Les composants sont choisis, reliés entre eux et enfin compilés et déployés. Le
service composite ainsi obtenu fonctionnera bien tant que son environnement et les services
qui le composent ne changent pas ou ne changent que rarement. Les stratégies de récupération
en cas d’échec des services, tel que substitution du service ou la gestion des erreurs, sont
prédéfinis. Microsoft BizTalk et Bea WebLogic sont des exemples de moteurs de
compositions statiques [18] [17]. Cependant, l'environnement des services Web est un
environnement fortement flexible et dynamique, de nouveaux services deviennent disponibles
et leurs fonctionnalités peuvent changer fréquemment, ainsi que le nombre de fournisseurs de
service progresse constamment.
Des problèmes peuvent survenir si un fournisseur actualise un service ou si l’un d’entre eux
est substitué par un autre. Dans cette situation il est inévitable de changer l’architecture
logicielle, et dans le pire des cas changer la définition du processus et reconcevoir le système.
Dans ce cas, la composition statique peut être trop restrictive et les composants doivent
s’adapter automatiquement aux changements inattendus ainsi qu’aux exigences du client avec
l'intervention minimale de l'utilisateur. La composition statique considère que les fonctions du
service ne changent pas et que les services sont toujours disponibles. Pour cela de nouveaux
types de compositions ont été considérés.
b). Composition dynamique
Dans ce type de composition, les services Web à composer sont déterminés lors de
l’exécution de la requête d’un client. Ils peuvent être déterminés selon les contraintes de
chaque client, la disponibilité des services Web, …etc. La composition dynamique apparaît la
plus intéressante d’une part, elle promet d’être capable de faire face à un environnement très
dynamique dans lequel des services apparaissent et disparaissent de manière fréquente.
D’autre part, elle permet de mieux satisfaire les besoins de chaque client en minimisant son
intervention.
Le système de composition dynamique doit donc détecter et gérer ces changements. La
composition dynamique des services web implique : i) La découverte des « bons » services à
composer selon des contraintes et des besoins. ii) La dynamicité et la flexibilité dans la
composition de services Web. Dans ce contexte StarWSCoP (Star Web Services Composition
Plateform) [19] est l’une des plateformes de composition dynamique de services Web. Elle
inclut plusieurs modules: un système intelligent qui décompose les exigences de l'utilisateur
en des descriptions abstraites du service, un registre de service qui est un entrepôt du services
web; un moteur de découverte pour trouver des services adéquats qui satisfont les exigences
de l'utilisateur dans le registre de services, un moteur de composition qui supervise les
31
services composés afin qu’il soient exécutés dans le bon ordre, un adaptateur (wrapper) qui
assure l’ interopérabilité des services hétérogènes qui ont été développés séparément par des
fournisseurs différents, une bibliothèque qui stocke les traces d’informations sur l'exécution
des services composites, une estimation en temps réel des qualités de service du service
composite et un moniteur qui contrôle les événements et notifie le moteur de composition.
4. Degré d’automatisation d’une composition des services
Du point de vu degré d’automatisation, une composition est classée dans l’une des trois
catégories.
4.1-
Composition Manuelle
Cette classe suppose que le développeur génère la composition à la main via un éditeur de
texte par la sélection et la fusion des services à incorporer. Elle s’adapte aisément aux besoins
de l’utilisateur, car il peut tout définir à son goût depuis le début. Seulement, il ne dispose
d’aucun outil dédié et il est obligé de maîtriser les techniques de programmation.
4.2-
Composition Semi-automatique
Les techniques de composition semi-automatiques font des suggestions sémantiques aux
utilisateurs pour les aider à sélectionner les services impliqués dans le processus de
composition. L’utilisateur maintient certains contrôles sur le processus de composition, sans
avoir à maîtriser les techniques de programmation de bas niveau. Il dispose d’outils
graphiques de modélisation et de conception pour définir ses propres processus.
4.3-
Composition automatique
La composition totalement automatisée prend en charge tout le processus de composition et le
réalise automatiquement, sans qu’aucune intervention de l’utilisateur ne soit requise.
Le service Web composite est une boite noire inaccessible et dont la flexibilité est minimisée.
5. Techniques de composition des services web
Les différentes techniques existantes pour la composition de services Web peuvent être
regroupées en deux courants :
• Le premier se base sur le fait qu’un service Web composite est défini par un ensemble
de services atomiques et par la façon dont ils communiquent entre eux. Cette
définition est du même type que la manière dont est défini un processus métier
(workflow).
32
•
Dans le second courant, la composition est vue comme la génération automatique
d’un plan d’exécution des services Web. Les approches envisagées sont des
approches du domaine de l’intelligence artificielle et plus particulièrement de la
planification. Ces techniques sont basées sur le fait qu’un service Web peut être
spécifié par ses préconditions et ses effets.
5.1 Composition par Workflow
D’une certaine façon, un service composite est similaire à un processus métier [20]. Un
service composite inclut un ensemble de services atomiques ainsi que les contrôles et
échanges de données entre ces services. De la même façon, un processus métier est composé
d’un ensemble d’activités élémentaires structurées, ainsi que l’ordre d’exécution entre elles.
Un workflow statique signifie que le demandeur doit établir un modèle de processus abstrait
avant de commencer la composition. Ce processus abstrait inclut un ensemble de tâches et
leurs dépendances de données. Chaque tâche contient une clause de la requête qui est utilisée
pour chercher le bon service Web atomique afin d’accomplir cette tâche. Dans ce cas,
seulement la sélection [21]et les liens au service Web atomique sont faits par un programme
automatiquement.
Parmi les travaux qui investissent dans ce type de techniques de composition on peut évoquer
les travaux ci-dessous.
•
Casati présente EFlow, [22] [23]une plateforme pour la spécification, la création et la
gestion de services composites développée par HP. EFlow s’exécute au dessus des platesformes e-services (ESPs). Ces plates-formes permettent le développement, le déploiement
et la livraison sécurisée des e-services aux entreprises et clients. Les fournisseurs de
services peuvent enregistrer les descriptions des services qu’ils offrent et peuvent contrôler
et gérer l’exécution de services. Les services peuvent être découverts par les
consommateurs en spécifiant des critères de recherche. L’invocation de services est limitée
aux utilisateurs autorisés.
Dans EFlow, le service composite est décrit comme un schéma de processus qui compose
des services de base ou composites. Les services composites sont modélisés par un graphe
définissant les flux d’invocations de services semblable aux diagrammes d’activité
d’UML, qui est également traduit en une structure XML. Le graphe contient des nœuds
services, décisions et événements. Les nœuds services représentent l’invocation d’un
service atomique ou composite, les nœuds décisions spécifient les règles de contrôle du
flux d’exécution, et les nœuds événements permettent aux processus du service d’envoyer
et recevoir plusieurs types d’événements. Les arcs dans le graphe représentent les
dépendances d’exécution entre les nœuds.
33
•
Khalaf [24] propose de regarder les chorégraphies créées avec BPEL4WS en tant que
services Web, c.-à-d. créer des patrons de composition qui pourront être composés,
formant ainsi de nouveaux patrons de composition. Cette solution facilite la composition
par une intégration plus simple de patrons d’assemblage prédéfinis dans un nouveau
patron mais ne règle pas le problème de la dynamicité de la composition des services
Web.
•
Laukkanen et Helin [25] identifient deux solutions possibles pour composer
dynamiquement des processus métier : remplacer un service Web dans un processus
métier existant par un autre service ayant des fonctionnalités similaires, ou définir un
nouveau workflow à partir des services Web disponibles. Les auteurs proposent d’utiliser
les descriptions sémantiques des services Web pour pouvoir comparer les fonctionnalités
en utilisant les notions de préconditions et d’effets de OWL-S. La solution proposée peut
être résumée en 4 étapes :. identifier les fonctionnalités requises, trouver les services
adaptés grâce à leur description sémantique, créer ou modifier le workflow, et Exécuter le
workflow en vérifiant son exécution.
•
Dans le même esprit, Osman [26] propose de limiter les points négatifs des techniques de
composition de type workflow en utilisant les technologies du Web sémantique, plus
particulièrement OWL. Il ne s’agit pas directement de composition automatique mais le
but est de limiter le nombre de services Web disponibles afin de créer plus facilement des
workflows. Pour cela, les auteurs proposent de regrouper les services Web en domaines
spécifiques (e.g., domaine des services Web d’hôtels, de transports, etc.) Ainsi le choix
des services à utiliser est restreint au domaine des services ayant comme fonctionnalités
les objectifs du workflow.
• Yang et Papazoglou [27] proposent une approche pour la planification, la définition et
l’exécution de la composition en se basant sur le concept du composant Web dans le but
de rendre la composition de services flexible et extensible. Ce concept regroupe un
ensemble de services préexistant (atomiques ou composites) et présente leurs interfaces
et opérations d’une façon cohérente et unifiée sous forme de définitions de classes. Une
fois qu’une classe composant Web est définie, elle peut être réutilisée, spécialisée et
étendue. Un composant Web spécifie la logique de composition en termes de
constructions de dépendances de messages et de type de composition. Le composant est
spécifié dans le langage SCSL (Service Composition Spécification Langage) et enregistré
dans une bibliothèque.
5.2 Composition orientée intelligence artificielle
La composition dynamique de services Web par des techniques d’intelligence artificielle, et
plus particulièrement par des techniques de planification, est l’une des voies qui semblent
prometteuses [28] . En effet, les concepts de OWL-S sont très fortement inspirés de ceux de la
planification, les préconditions présentent les conditions qui doivent être satisfaites pour
34
garantir la bonne exécution d’un service Web. Les effets sont le résultat du succès de
l’exécution d’un service. Dans ce qui suit, nous présentons quelques axes de recherche actuels
concernant la composition par planification et par d’autres techniques d’intelligence
artificielle.
•
McIlraith et al. [29] [30] [31] proposent d’adapter et d’étendre le langage Golog pour la
construction automatique de services Web. Golog est un langage de programmation
logique qui sert à représenter des changements ou évolutions en termes de situations,
d’actions et d’objets. Le problème de la composition de services Web est abordé de la
façon suivante : la requête de l’utilisateur et les contraintes des services sont représentées
en termes de prédicats du premier ordre dans le langage de calcul situationnel. Les
services sont transformés en actions (atomiques ou complexes) dans le même langage.
Puis, à l’aide de règles de déduction et de contraintes, des modèles sont ainsi générés et
sont instanciés à l’exécution à partir des préférences utilisateur.
•
Waltinger [32] a élaboré une approche pour la composition de services par preuve de
théorèmes. Cette approche est basée sur la déduction automatique et la synthèse de
programmes. Les services disponibles et les requêtes utilisateur sont traduits dans un
langage du premier ordre. Puis, des preuves sont produites à partir d’un prouver de
théorèmes. La composition est obtenue à partir de preuves particulières. Dans le même
axe, Rao et al [33] ont introduit une méthode de composition automatique de services
Web sémantiques en utilisant des preuves de théorèmes de la logique linéaire.
•
Cheng et al [34] voient les services web comme des agents et proposent le langage
ASDL (Agent Service Description Language) pour décrire le comportement externe des
services Web. Une spécification ASDL décrit les messages compris par un service, ainsi
que les protocoles d’interactions utilisés. Puis, la composition est effectuée à l’aide du
langage ASCL (Agent Service Composition Language) qui permet de décrire la logique
avec laquelle un nouveau service est composé à partir de services existants. L’avantage
de ces travaux est de mettre l’accent sur les interactions entre services au sein de la
composition et d’adapter celle-ci en fonction des contraintes résultant des interactions.
Muller et Kowalczyk [35] travaillent aussi sur un système multi-agent pour la
composition de services basé sur la concurrence entre coalitions de services ; les agents
représentants les services se contactent les uns les autres pour proposer leurs services en
fonction de leurs capacités de raisonnement et ainsi former des coalitions d’agents
capables de résoudre les buts fournis par l’agent utilisateur.
•
Un intérêt croissant de la communauté planification pour la composition de services Web
peut être expliqué par la similarité entre les descriptions OWL-S et les représentations en
planification. En effet, la communauté du Web sémantique s’est fortement inspirée du
langage PDDL lors de la conception du langage de description OWL-S. Ainsi, une
description OWL-S peut être facilement traduite en une représentation PDDL : les
services Web sont représentés par des opérateurs ayant des préconditions et produisant
35
des effets. Puis, un planificateur peut alors être utilisé pour produire un plan qui
correspond à la composition des services Web. Carman et al. [36], mais également
Constantinescu et al [37] ont utilisé cette correspondance pour composer un ensemble de
services Web.
6. Langages de composition des services Web
De nombreux langages ont été proposés pour modéliser la composition de services: WSBPEL [38] qui est issue de XLANG [39] de Microsoft et WSFL [40] d’IBM, WSCI [41], WSCDL [42]. Certains de ces langages issus de l’industrie tels que WS-BPEL, modélisent la
composition sous forme d’un processus métier exécutable. D’autres langages tels que WSCDL définissent des opérateurs de construction simples permettant de décrire la collaboration
entre un ensemble de services.
Des initiatives ont été prises dans le but de fournir des plates-formes et des langages qui
offrent l’intégration des systèmes hétérogènes, tels que WSCI, WSCL, WSFL, BPEL4WS.
Dans cette partie, nous présenterons quelques standards ayant émergé dans le domaine de la
composition des services Web.
•
BPML (Business Process Modeling Language):
C’est un métalangage de modélisation des processus collaboratifs qu’engage l’entreprise avec
ses partenaires sur Internet. Il prend en compte aussi les aspects les plus complexes de la
gestion et de la coordination de ces processus, en abordant les transactions, la sécurité et la
liaison dynamique avec les services Web en cours d’exécution.
•
XLANG
XLANG de Microsoft, permet de décrire formellement les processus d’entreprises comme des
interactions entre participants. La description complète d’un processus consiste aussi bien à
définir le comportement de chaque participant, qu’à décrire la manière dont l’ensemble des
participants interagit pour produire le processus complet..
• WSFL (Web Service Flow Language)
C’est une approche IBM qui permet d’intégrer la composition de services Web comme un
processus métier statique. C’est un langage basé XML permettant de décrire des
orchestrations de services Web.
•
BPEL4WS (Business Process Execution Language For Web Services)
BPEL4WS est un langage de composition pour décrire les interactions entre les services Web
qui composent un processus métier, proposé par Microsoft, IBM, BEA et d’autres grands
acteurs du monde de l’informatique et de l’Internet pour palier le problème de composition
des SW. Il a remplacé les précédents langages XLANG (Microsoft) et WSFL (IBM).
BPEL4WS permet la coordination des services Web dans un fprocessus métier.
36
•
WSCL (Web Service Conversation Language)
WSCL a été proposé par le consortium W3C, il permet de définir les interfaces abstraites des
services Web, c-à-d les conversations au niveau métier soutenues par un service Web. Il
spécifie les documents XML à échanger et leur ordre.
.
• WSCI (Web Service Choregraphy Interface)
C’est un langage reposant sur XML et qui décrit le flux de messages échangés par un service
Web participant à une chorégraphie.WSCI fonctionne en conjonction avec WSDL pour
construire l’interface dynamique du service Web en réutilisant les opérations définies pour
l’interface statique.
7. Conclusion
La composition des services web est un point crucial qui a un grand impact sur plusieurs
domaines de recherches. De nombreux efforts ont été fourni afin de permettre une
composition utilisable et acceptable de services Web.
L’objectif de la composition de services est de répondre, justement, aux exigences des clients
en offrant des fonctionnalités à valeur ajoutée par articulations de fonctionnalités déjà offertes
par d’autres services Web.
La composition de services implique la capacité de sélectionner, d’articuler et de faire interopérer des services existants, pour réaliser cette activité. Contrairement aux Business Process
«traditionnels» qui sont exécutés d’une manière prévisible et répétitive dans un
environnement statique, les services Web composés s’exécutent dans un environnement
ouvert et versatile, où les services offerts sont diversifiés et évolutifs et où la forte compétition
engendrée par la multitude de fournisseurs oblige les entreprises à mieux adapter leurs
services pour répondre aux besoins croissants des clients et à moindre coût.
Cependant, pour permettre une telle composition, des abstractions, des outils et des
environnements sont nécessaires. Ils permettent de sélectionner les services impliqués dans la
composition, de spécifier l’ordre des opérations à invoquer, de gérer et de contrôler le flux de
données à travers les services à composer, ainsi que la gestion des transactions et des
situations d’exception.
Après une étude des services Web et de la composition de services, nous allons examiner dans
le prochain chapitre, Les différents types d'incompatibilité qui peuvent apparaître lors de la
création d’une composition.
37
Chapitre 3
Compatibilité des Services Web dans une
Composition
1. Introduction....................................................................................................................................... 39
2. Notion de compatibilité dans une composition ................................................................................ 39
3. Types de compatibilité ...................................................................................................................... 40
3.1-
Compatibilité Syntaxique ...................................................................................................... 40
3.2-
Compatibilité Sémantique ..................................................................................................... 41
3.3-
Compatibilité Comportementale .......................................................................................... 41
a-
Compatibilité Faible/Forte .................................................................................................... 42
b-
Compatibilité Totale/Partielle ............................................................................................... 43
3.4-
Compatibilité de QdS............................................................................................................. 44
4. Conclusion ......................................................................................................................................... 45
[1] [1] [2] [3] [4] [5] [6] [7] [8] (Fensel, Bussler, & Maedche, Semantic Web Enabled Web
Services, 2002) (Casati & Shan, Models and languages for describing and discovering eservices, 2001) [11] (Kellert & Toumani, 2003) [13] (Bray T. , Paoli, Sperberg-McQueen, &
Maler., 6 Octobre 2000) [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28]
[29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]
38
1. Introduction
La technologie « Service Web » est la technologie clé permettant l’intégration des
applications via le web. Dans ce domaine, la composition de services web constitue l’un des
champs de recherche les plus actifs et l'une des principales motivations pour favoriser
l’utilisation de services Web et ainsi répondre aux exigences de plus en plus complexes.
Avant son exécution, une composition est spécifiée par un processus métier, qui orchestre les
échanges de données entre les services Web composés. Ces données sont représentées par les
paramètres d’entrée/sortie détaillées dans les descriptions des services. Ce sont
respectivement les données transmises au service Web et nécessaires à son exécution, et les
données émises par le service comme résultat de cette exécution. Du point de vue de la
composition, un échange de données entre deux services consiste à recevoir les données
envoyées par un service Web émetteur, et à transmettre des résultats à un service Web
destinataire.
Pendant l’étape d’exécution d’une composition, il est possible que des incompatibilités
provoquent l’inconsistance des échanges de données entre services Web. En effet, la syntaxe
et la sémantique associées aux données par le service émetteur peuvent, par exemple, être
différentes de celle attendue par le service destinataire. Ainsi, il est nécessaire de fournir des
méthodes pour déceler ces hétérogénéités pour permettre des échanges consistants, sur
différents niveaux entre des services Web participant à une composition.
Dans ce chapitre, nous discutons la notion de compatibilité entre les services Web d’une
composition. Cette notion permet de s'assurer, avant la mise en œuvre d'une application
complexe composée, du bon déroulement de la collaboration entre les services Web
composants.
Nous présentons d’abord quelques définitions, ensuite nous examinons une classification des
différentes incompatibilités qui peuvent apparaître lors de la création d’une composition.
2. Notion de compatibilité dans une composition
Un ensemble de services Web est dit compatible si les services peuvent collaborer
« correctement ». La collaboration se réalise par l'échange d'un ensemble de messages, i.e.,
par le biais de conversations. Une conversation durant laquelle aucun blocage n'apparaît, est
dite correcte. Les blocages qui peuvent surgir sont principalement dus à l'hétérogénéité des
services au niveau des types des messages, des types des données, des contraintes de données,
l'ordre dans lequel ces messages peuvent survenir ou bien être engendrés, par l'impact que
peuvent avoir les différentes contraintes temporelles et les diverses exigences imposées sur
l'ensemble des interactions des services Web.
39
En d’autres termes la vérification de la compatibilité consiste à vérifier si deux services
peuvent interagir correctement et engager des conversations entre eux, (si une conversation
peut être établie entre les services considérés) et chaque service peut se terminer
correctement.
3. Types de compatibilité
Il existe plusieurs types de (in)compatibilités. Dans ce qui suit, nous présentons celles les
plus évoquées dans la littérature [44] [45] [46] [47] où on distingue quatre aspects à vérifier
pour assurer la compatibilité entre les services Web participants à une composition. Ces
aspects concernent des propriétés syntaxiques, sémantiques, comportementales et les
propriétés de qualité de service (QdS) [44] [45] [46] [47].
3.1-
Compatibilité Syntaxique
La compatibilité syntaxique (dite aussi compatibilité d’interface) concerne la syntaxe et les
types des messages entre les services partenaires. Elle signifie que les interfaces structurelles
des services Web interactifs sont conformes, par exemple, les étiquettes et les types de
données des messages correspondants sont les mêmes. En effet, un message envoyé par un
service doit avoir la même structure que le message devant être reçu par le service partenaire.
Actuellement, le Web Service Description Language (WSDL) fournit une méthode
normalisée pour spécifier ces interfaces structurelles.
Il convient de rappeler que dans les services Web, la structure des messages qui transitent via
un port est définie par un schéma XML. Celui-ci est un arbre qui définit le nombre de
champs du message ainsi que leur organisation.
Deux service web ont des données syntaxiquement compatibles (en vue d’une composition) si
et seulement si chaque message commun (envoyé par l’un et devant être reçu par l’autre) a le
même schéma XML dans les deux services.
Exemple :
Les services Web de la Figure 3.1 ne sont pas compatibles car les schémas XML S-XML1 et
S-XML2 sont différents : S1 envoie un message Livre contenant deux informations (titre et
auteur) alors que S2 doit recevoir un message Livre contenant trois informations (titre, auteur
et éditeur)
S-XML1
Livre
titre auteur
S1
p
S-XML2
Livre
titre auteur éditeur
p
S2
40
Figure 3.1 : Exemples de services web syntaxiquement incompatibles.
3.2-
Compatibilité Sémantique
La compatibilité sémantique assure que les messages et leurs contenus sont correctement
interprétés. Ce type de compatibilité signifie que lors des interactions des services Web les
informations échangées sont comprises d'une manière cohérente et sans ambiguïté. En effet,
il est important de s’assurer que la signification d’une même donnée est identique dans
chacun des deux services en communication.
Exemple :
Bien que les deux services S1 et S2 de la Figure 3.2 soient syntaxiquement compatibles, le
sens de Id, Nom et Date dans chacun des deux services doit être le même. Si on suppose que
le Nom et Date envoyés par S1 sont le nom de l’entreprise et la date de sa création ; et que
pour le service S2 le Nom est celui du propriétaire et la Date est sa date de naissance, alors S1
et S2 ne sont pas sémantiquement compatibles.
S-XML1
Id
Nom
S1
S-XML2
Id
date
Nom
p
date
p
S2
Figure 3.2 : Compatibilité sémantique.
3.3-
Compatibilité Comportementale
La compatibilité du comportement signifie que les services Web partenaires (dans une
composition) sont en accord sur ce à quoi s'attendre de l'autre en termes d'opérations à
exécuter, de résultats à livrer, et de messages à envoyer et à recevoir. Le comportement réfère
41
ici à des séquences possibles de messages que les services Web s’échangent mutuellement en
réponse à des déclencheurs ou des dépendances commerciales. En effet, en plus de la
compatibilité syntaxique et sémantique, la composition des services doit garantir le bon
fonctionnement du composite résultant de la composition : les services composés doivent
accomplir leur tâches de façon cohérente sans qu’aucun d’eux ne perturbe (ou bloque)
l’exécution d’un autre.
Exemple :
Soient les deux services S1 et S2 représentés par la Figure 3.3. Le service S1 modélise le
comportement d’un client qui s’installe (PLACE), passe une commande (command) et attend
d’être servi (Repas), puis mange, avant de payer la facture (Argent). Par contre le service S2
prend la commande, attend le payement de la facture avant de servir le client. La composition
de ces deux services mène à une situation de blocage et par conséquent ils ont des
comportements incompatibles.
S1
S2
P5
P1
Command
PLACE
Accepter
Command
P2
P6
Repas
Repas
Recueillir de
l’argent
Manger
P3
P7
Payer
Faire cuire
P4
Argent
Argent
P8
Figure 3.3 : Exemple d’incompatibilité de comportement entre services.
Une compatibilité de comportement peut être d’une part faible/forte, ou d’autre part totale/
partielle. Nous précisons ci-dessous ces concepts.
a- Compatibilité Faible/Forte
Un service web composite C modélisé comme un réseau fermé est un service qui se compose
de la coordination de plusieurs services compatibles.
42
Nous nous concentrons sur ces trois exigences pour analyser cette compatibilité:
Faible-compatibilité : Un réseau fermé C est dite faiblement compatible si C est sans
interblocage. L’exemple illustré dans la Figure3.3, montre un composite C qui n'est
pas faiblement compatible. En effet, C se bloque car le service S1 de C attend le repas
pour exécuter l’action manger puis payer ; pendant que S2 attend l’argent pour servir
le repas.
Compatibilité : qui exclut non seulement les blocages, mais aussi les cycles non
productifs. Un réseau fermé C est dite compatible (comportement) si l’état initial (état
interne) est toujours accessible. L’exemple illustré sur la Figure 3.4 montre que le
réseau C est faiblement compatible mais C n’est pas compatible à cause des états qui
ne sont pas toujours accessibles. En effet, à la fin de l’exécution il est possible que les
messages envoyé par S2 vers S1 dans la place fichier ne soient pas consommés si S1
exécute l’action quitter la requête au lieu de l’action obtenir le fichier.
Forte-compatibilité : Un réseau fermé C est dit fortement compatible si C est
compatible et quasi-vivant (bonne fin, et aucune activité morte).
P8
P1
Ordre
P5
Requête
P11
Recevoir
Ordre
P2
Envoyer
identification
P3
Login
info
P9
P12
Accepter
login info
P6
Login
info
P13
P7
Fichier
Quitter la
requête
Retourner
Obtenir
le fichier
P10
Fichier
P14
P4
Figure 3.4 : C faiblement compatible mais n’est pas compatible
b- Compatibilité Totale/Partielle
Les conflits peuvent avoir un impact partiel ou total sur la collaboration de services Web. En
fonction de l'impact que peuvent avoir les conflits sur la collaboration de services Web. Nous
présentons ci-dessous, ces différentes classes de compatibilité.
Compatibilité totale :
43
Cette première classe de compatibilité regroupe des services Web qui peuvent coopérer sans
blocage. En effet, aucun type de blocage ne peut apparaître lors de l'interaction des deux
services. Donc toutes les exécutions des deux services peuvent interagir sans qu'un blocage ne
survienne.
Lors d'une coopération entre les services web, des messages peuvent être envoyés sans qu'ils
soient consommés. Pour cela, nous distinguons deux sous classes :
•
Compatibilité totale parfaite : On dit que les services Web d’une composition est
totalement et parfaitement compatible, si toutes les conversations ne contiennent
aucun blocage et tous les messages produits sont consommés.
•
Compatibilité totale non-parfaite : Lors de l'interaction des services web, aucun
blocage ne peut survenir, mais en même temps, certains messages produits au cours de
leurs conversations ne seraient pas consommés, c'est ce qu'on désigne par
compatibilité totale non-parfaite.
Compatibilité partielle ou (simple compatibilité) :
Les services web qui ne sont pas totalement compatibles mais peuvent introduire quelques
interactions correctes, sont des services partiellement compatibles. Donc deux services
peuvent mener correctement au moins une conversation et en même temps peuvent en
échouer en menant au moins une autre, sont des services partiellement compatibles.
Dans cette classe aussi, on distingue deux sous classes :
•
Compatibilité partielle parfaite :
Un ensemble de services Web est partiellement et parfaitement compatible, s'il existe
au moins une conversation menant à un blocage et en même temps, ils peuvent avoir
d'autres conversations correctes où tous les messages produits sont consommés.
•
Compatibilité partielle non-parfaite :
La compatibilité partielle non-parfaite concerne des services Web partiellement
compatibles où il existe au moins un message produit qui n'est pas consommé.
Incompatibilité totale
La dernière classe que nous proposons est l'incompatibilité totale. Cette classe rassemble
l'ensemble des services Web incapables d’avoir au moins une conversation correcte, i.e., les
services échouent dans toutes leurs conversations.
Le concept de compatibilité est très important pour les développeurs. D’un côté, les services
incompatibles (totalement ou partiellement) ne sont pas pris, en général, en considération
dans la phase de sélection. D’un autre coté, les développeurs doivent déterminer les
conversations permises dans le cas de compatibilité partielle.
3.4-
Compatibilité de QdS
44
La qualité de service (QdS) est un ensemble de propriétés et caractéristiques d'une entité ou
d’un service qui lui confèrent l'aptitude à satisfaire des besoins déclarés ou implicites [48].
Ces besoins peuvent être liés à des paramètres tels que l'accessibilité, la disponibilité, le temps
de réponse, le coût, la fiabilité, ... etc. Ces paramètres peuvent être alors considérés comme un
critère de choix lorsqu’on a affaire à sélectionner parmi plusieurs services web découverts
ceux qui respectent les contraintes imposées.
Exemple
Soient 2 services web S1 et S2 qui sont compatibles de chacun des points de vue syntaxique,
sémantique et comportemental. Si S1 n’est pas disponible la journée du Dimanche de
chaque semaine et S2 n’est pas disponible la journée du Vendredi de chaque semaine (pour
des raisons de week-end) ; la composition des deux services ne peut pas produire un service
composite disponible toute la semaine. Ainsi, si on considère le paramètre de qualité
disponibilité 7jours/7 (toute la semaine), les services S1 et S2 ne sont pas compatibles.
4. Conclusion
La composition de services Web offre la possibilité de faire coopérer plus d’un service pour
accomplir des tâches de plus en plus complexes. Cependant l’opération de composition est
confrontée à des problèmes d’incompatibilité entre services. En effet, quand un service fournit
des fonctionnalités qu'un autre service exige, il est peu probable que l’on puisse directement
composer les deux services s’ils ne sont pas programmés à l'avance pour collaborer.
Ce problème de la composition de services Web est en plein essor. Nous pouvons souligner
ici quelques sources de ces problèmes :
Un Web service n’est pas adaptable. Il est passif (non exécutable) jusqu’à ce qu’il
soit invoqué. Il a des connaissances de lui-même mais pas de ses applications ou de
ses utilisateurs clients ;
Puisque le nombre de services Web augmente jour après jour, il devient plus difficile
de trouver artificiellement le service Web qui soit à la fois compatible et qui peut
effectuer la tâche à accomplir.
Les services Web peuvent être créées et réactualisés. Par conséquent, deux services
compatibles aujourd’hui peuvent ne plus l’être demain. Ainsi, le schéma de la
composition devrait s’adapter en fonction des nouvelles informations.
Les services Web sont généralement établis par des organisations différentes qui
utilisent différents modèles conceptuels pour la présentation des caractéristiques des
services. Cela exige l’utilisation d’informations pertinentes pour faire correspondre
(matching) et composer les services web.
45
Dans ce chapitre, nous avons abordé la définition de la compatibilité entre les services web
dans une composition. Ensuite nous avons évoqué les différents types d’incompatibilité
possibles entre les services web.
La définition formelle de chaque type de compatibilité dépend du formalisme considéré pour
la modélisation des services Web.
Dans les chapitres suivants, nous allons présenter pour chaque type de compatibilité, un cadre
approprié pour représenter les services web et pour permettre la vérification de compatibilité.
46
Chapitre 4
Vérification de la compatibilité
Syntaxique
1. Introduction....................................................................................................................................... 71
2. Définition Informelle ......................................................................................................................... 72
3. Exemples............................................................................................................................................ 72
4. Approches de vérification existantes ................................................................................................ 73
5. Approche proposée ........................................................................................................................... 74
5.1. Vérification de la compatibilité structurelle............................................................................... 74
5.1.1 Cadre formel ......................................................................................................................... 74
5.1.2. Exemple ............................................................................................................................... 76
5.1.3. Définition formelle : (Compatibilité structurelle) ............................................................... 78
5.1.4 Principe de vérification......................................................................................................... 78
5.1.5. Algorithme de vérification................................................................................................... 79
5.2. Vérification de la compatibilité des types des données............................................................. 81
5.2.1. Définition formelle : (Compatibilité des types de données) ............................................... 81
5.2.2. Exemple : ............................................................................................................................. 81
5.2.3. Principe de vérification........................................................................................................ 82
5.2.4. Algorithme de vérification................................................................................................... 82
6.
Génération d’adaptateur............................................................................................................... 83
7.
Conclusion ..................................................................................................................................... 84
[1] [1] [2] [3] [4] [5]
47
1. Introduction
Etant donné que différents services Web écrits dans différents langages, par différents
fournisseurs et sur différentes plateformes, peuvent être utilisés dans la même application, des
outils d'analyse sont devenus cruciaux. Le but de ces outils est de vérifier que les interactions
des différents services sont correctes, i.e., les services Web peuvent mener leurs conversations
sans blocage. Ces vérifications sont très importantes, du fait qu'une mauvaise interaction (une
interaction qui n'est pas correcte) peut avoir des conséquences néfastes. En effet, les services
Web sont de nos jours utilisés dans plusieurs domaines, notamment dans des domaines
critiques, tels que le domaine médical et le domaine économique. Par conséquent, assurer que
les interactions sont correctes est primordial.
Du point de vue syntaxique, on doit pouvoir vérifier la compatibilité au niveau structurel ainsi
qu’au niveau des types de données échangées entre les services.
Au niveau structurel, l’ensemble des interactions n’est possible que s’il y a au moins des
échanges (envoi/réception de messages) possibles. Ceci suppose l’existence d’une
correspondance entre les ports d’entrée d’un service, et les ports de sortie du service
partenaire.
Au niveau types de données échangées, la vérification concerne chaque couple de ports (port
de sortie d’un service et le port d’entrées correspondant dans le service partenaire). Les
données envoyées via un port de sorties d’un service doivent avoir des types compatibles avec
ceux des données reçues par le port correspondant du service partenaire.
La compatibilité syntaxique est souvent dite compatibilité d’interface car elle consiste à
comparer les interfaces des deux services à composer. L’ensemble des interactions réalisées
entre un client et un service est appelé conversation. Selon que l’on se réfère à l’interface
qu’un service existant est capable de fournir, ou à l’interface qu’un service est censé fournir,
et donc attendue par les clients, on parle d’interface fournie ou d’interface requise.
L’interface fournie comprend donc les opérations par lesquelles un service Web fournit ses
fonctionnalités à d’autres services. L’interface requise inclut les opérations qu’un service web
a besoin pour mettre en œuvre sa fonctionnalité.
Lorsqu’il s’avère que suite à des modifications l’interface fournie d’un service ne correspond
plus à l’interface que ses partenaires requièrent, que ce soit par une comparaison, ou par un
test de conformité parce qu’une conversation a échoué, il y a deux solutions :
(1) Adapter l’interface requise comme interface fournie et modifier le service en
conséquence ;
48
(2) Introduire un adaptateur qui réconcilie l’interface fournie avec celle requise par les
partenaires.
La première solution est en général non utilisée car le même service peut interagir avec
plusieurs autres services partenaires qui considèrent son interface d’origine. Ce qui conduit à
la situation où le même service peut participer à diverses collaborations qui nécessitent
différentes interfaces fournies. La seconde solution remédie à ce défaut par la fourniture d’un
adaptateur ou d’un médiateur.
Dans ce chapitre nous examinons la compatibilité syntaxique entre deux services web et
nous proposons une approche de vérification de détection des incompatibilités syntaxiques qui
peuvent exister dans une composition de services web.
2. Définition Informelle (compatibilité syntaxique)
Deux services sont déclarés syntaxiquement compatibles si les deux processus sont disjoints
et pour chaque point d’entrée/sortie en commun, l’entrée de l’un correspond à une sortie de
l’autre et vise versa.
La compatibilité syntaxique exige donc que pour chaque opération de l’interface requise
d’une composition de service web, il ya au moins une opération portant le même nom dans
l’interface fournie d’un des services web élémentaires qui correspond en nombre de
séquence et types de paramètres.
3. Exemples
Afin d’illustrer ce type d’incompatibilité lors d'une collaboration, nous présentons des
exemples dans la Figure 4.1. Dans ces exemples, nous considérons deux services S1 et S2. Les
messages sortants sont notés par +m et les messages entrants par –m, un message contenant
des données est noté par m (d1, d2,.., dn). La notation m1&m2 dénote une agrégation (un
message composé) des messages m1 et m2.
S1
+m1 (d1)
-m1 (d1)
-m2 (d2)
+m2 (d2)
S2
49
(a) : Une composition de services web compatibles
+m1&m2
-m1
S1
-m2
S2
(b) : Incompatibilité syntaxique due à un incompatibilité structurelle
S1
+m1 (d0)
-m1 (d1)
-m2 (d2)
+m2 (d2)
S2
(c) : Incompatibilité syntaxique due à l’hétérogénéité des types de données
+m1 (d1)
S1
-m2 (d2)
-m0 (d1)
+m2 (d2)
S2
(d) : Incompatibilité syntaxique due à l’hétérogénéité des types des messages
Figure4.1 : Exemples de compatibilité/incompatibilité syntaxique
4. Approches de vérification existantes
Dans les approches à base de réseaux de Petri [49] [50] [51], les algorithmes de bissimilarité
sont utilisés pour détecter les incompatibilités structurelles entre l’interface fournie par le
service et celle attendue par le client. En cas d’incompatibilité, une trace des erreurs est
retournée au concepteur afin qu’il réajuste la définition de la structure du service. Ces
approches ne traitent pas la situation où, suite à une modification de l’interface fournie par le
service, celle-ci n’est plus compatible avec celle requise par ses clients. De ce fait, le service
fournisseur aussi bien que ses partenaires doivent adapter leurs interfaces structurelles à
chaque nouvelle modification.
Dans d’autres approches ont étudié les incompatibilités syntaxiques qui peuvent se produire
où les messages reçus ou envoyés n’ont pas la structure (type) attendue. La plupart de ces
50
travaux proposent des adaptateurs qui s’appuient sur des outils de transformation de données
tels que Xpath, XQuery, XSLT. Les approches étudient les incompatibilités structurelles
induites par les différents modes d’envois et de réceptions des messages (voir par exemple
[52] [53] [54]). Les adaptateurs sont construits de manière semi-automatique en se basant sur
des patrons d’incompatibilité identifiés ou en utilisant des opérateurs d’adaptation. Parmi ces
patrons d’incompatibilités structurelles, certains ont une influence sur le comportement,
comme par exemple l’envoi ou la réception de messages superflus, des envois multiples
versus une réception unique, un envoi unique versus des réceptions multiples. Les approches à
base de médiateurs (on parle de patrons de médiation dans [55]), suggèrent la définition de
fournisseurs virtuels qui transforment la structure des messages envoyés et reçus. Cependant,
ces propositions se limitent aux cas d’opérations optionnelles qui n’influent pas sur la logique
métier du service. Ici aussi, l’adaptation des interfaces est faite à la conception. Par suite, les
incompatibilités peuvent se produire à la suite des évolutions des interfaces. Ce qui oblige le
concepteur du service à redéfinir l’adaptateur à chaque évolution et pour chaque client.
Des approches sont proposées dans [56] [57] pour l'adaptation d'une interface WSDL de
service aux clients syntaxiquement incompatibles. Dans [57] les auteurs supposent que les
interfaces de tous les services qui fournissent des fonctionnalités similaires soient tirées d'une
interface de base commune à l'aide d'un certain nombre d'opérateurs de dérivation qui
permettent d'ajouter ou de retirer des paramètres de fonctionnement. Cependant, les noms
d'opérations et d'autres aspects de l'interface de service sont les mêmes.
Dans [56] , les auteurs proposent de définir des vues de service au dessus des interfaces
WSDL en modifiant les interfaces WSDL pour permettre les interactions avec les services
incompatibles. Toutefois, aucun soutien automatique à la production de vues n’est proposé.
5. Approche proposée
Dans le but le procéder à la vérification de la compatibilité syntaxique entre deux services
dans une composition, nous distinguons entre deux niveaux : le niveau structurel et le niveau
type de données.
5.1. Vérification de la compatibilité structurelle
Avant de procéder à la vérification il faut représenter les services web dans un contexte
formel commun. Puisqu’il existe différents types de compatibilité à vérifier, certain types de
compatibilité sont plus simples à vérifier dans un formalisme que dans un autre.
Il existe plusieurs formalismes pour la modélisation de la composition des services comme les
réseaux de Petri, la logique temporelle, l’algèbre de processus,...etc. Dans le contexte de notre
travail, nous allons utiliser la modélisation avec les systèmes de transitions étiquetées LTS
(Labled Transition Systems) pour vérifier la compatibilité syntaxique, puisqu’ils permettent
51
de décrire la structure du service et le
messages).
contrôle de son exécution (envoi/réception de
5.1.1 Cadre formel
Nous allons modéliser l’interface d’un service web par un système de transition étiquetées
(Labelled Transition Systems, LTS) qui fournit une représentation formelle des interfaces de
service permettant de comparer plus facilement les interfaces et de détecter leurs
incompatibilités structurelles.
Un système de transitions étiquetées (LTS) est un automate, représenté par un graphe orienté
où :
•
Les nœuds désignent les états possibles d’un système. On a trois types d’états : un état
initial, des états finaux (échec ou succès), et les états intermédiaires (traitement
interne).
• Les arcs désignent les transitions entre les états. Ces transitions sont déclenchées par
des événements. Chaque arc est étiqueté par l’évènement dont l’occurrence déclenche
le passage de l’état origine de la transition vers l’état destination. Autrement dit
l’étiquette est soit envoi de messages, réception de messages ou appels d’opération
interne.
Une condition (ou garde) sous forme d’expression booléenne peut être associée à une
transition et le système peut passer d'un état vers un autre en déclenchant la transition
seulement si la contrainte associée est satisfaite.
Definition (LTS)
Un LTS est décrit un 6-uplet P=(S, s0, A, T, F, M) où :
− S : est un ensemble fini d’états ;
− s0 : est l’état initial avec s0 ∈ S ;
− A : est un ensemble fini des évènements (actions) ;
− T : SxA →S est la fonction de transition qui associe à un état source si ∈ S et à un
évènement ak ∈ A , un état destination sj ∈ S noté par ( si, ak, sj) ou « si ak sj » ;
− F : est un ensemble non vide des états finaux avec F⊆ S ;
− M : est un ensemble des messages ;
Un message m peut être envoyé noté !m ou reçu ?m. Il contient une liste de paramètres
m(d1,d2,.., dn) noté m(d)
On a trois types de transitions :
a= !m, a= ?m, ou a= (d1, d2,.., dm ; d1’, d2’,.., dm’).
52
Une trace est une séquence de plusieurs transitions (un chemin) notée comme suit :
s0
α
α
α
→
s →
s ...→
sn
0
1
1
n−1
2
ou bien (s0,α0,s1) (s1,α1,s2) …..(sn-1,αn-1,sn)
On note :
− s• l’ensemble des transitions sortantes de l’état s
− •s l’ensemble des transitions entrantes dans l’état s
− t• l’état cible de la transition t
− •t l’état source de la transition t
Pour pouvoir vérifier la compatibilité syntaxique de deux services web, nous supposons
disposer de la modélisation de leurs interfaces par des LTS. Les deux interfaces à étudier sont
définies donc par deux LTSs P et P’ qui sont respectivement décrit par P=(S, s0, A, T, F, M)
et P’= (S’, s0’, A’, T’, F’, M’).
5.1.2. Exemple
La Figure 4.2 donne un exemple de modélisation par des LTS de deux services Web : le
service de réservation de billets et le service de paiement par carte de crédit (PCC).
Le demandeur spécifie la destination (ville) ainsi que la date du Voyage. Ensuite, le service de
réservation de billets propose une liste de description des billets. Le demandeur fait un choix,
et il fournit un numéro de carte de crédit (ncc) pour compléter la réservation. Ensuite, le
service de réservation de billets appelle le service (PCC) pour vérifier la validité du numéro
de la carte de crédit (ncc) afin de garantir le paiement.
Vu l’intérêt de l’analyse de compatibilité structurelle des services web dans une composition,
nous essayons dans cette partie, de détecter les différentes incompatibilités structurelles entre
deux interfaces de services.
53
? Description
de la demande
(ville, date)
Recherche de
billets (ville, date,
N°, prix, horaires)
S1
S0
! Liste de billets
(N°, prix, horaires)
? Billet choisi
S3
S2
S4
! Prix à
payer (prix)
? Billet payé
(prix, ncc)
! Réservation
confirmée (billet)
S9
S8
! Billet à payer
(prix, ncc)
S7
? Numéro de carte
de crédit (ncc)
S6
? Échec
(ncc erroné)
S5
? Réservation
abandonnée ()
S10
Service de réservation de billets
? Billet à payer
(prix, ncc)
t0
Vérifier ncc
(ncc, approuvé)
t1
Si approuvé=’ok’)
débiter (prix, ncc)
! Billet payé
(prix, ncc)
t3
t2
t5
Si approuvé≠’ok’)
? Échec (ncc erroné)
t4
Service de paiement par carte de crédit (PCC)
Figure 4.2 : Modélisation d’un service de réservation des
billets de vol en ligne à l’aide des LTS
54
5.1.3. Définition formelle : (Compatibilité structurelle)
Soient P= (S, s0, A, T, F, M) et P’= (S’, s0’, A’, T’, F’, M’), deux LTS modélisant les interfaces
de deux services Web. P et P’ sont compatibles pour une composition s’il existe une
conversation entre P et P’ (au moins un chemin d’exécution complet de P et supporté par P’).
Soit mi
le message à invoquer pour la transition courante mi(s1, a, s2) ∈ P
et mj (s1’, a’, s2’) ∈P’ , la compatibilité des messages mi et mj est vérifiée si :
•
•
•
Les noms des messages sont identiques ;
L’état cibles s2 correspond à l’état cible s2’
Les polarités (a, a’) se compensent ( !, ?).
Donc pour détecter les incompatibilités entre P et P’, il suffit d’identifier toutes les différences
qui font que P et P’ ne vérifient pas la définition ci-dessus.
5.1.4 Principe de vérification
Une conversation est incohérente entre deux services si l’interface fournie est différente de
l’interface requise. La détection de l’incompatibilité entre deux services Web repose sur
l’application de l’algorithme de détection des incompatibilités qui examine les LTSs P et P’
correspondant à leurs interfaces. A partir de leurs états initiaux respectifs, on compare les
transitions sortantes des états d’une paire d’états courante (s, s’) et on vérifie les
incompatibilités.
Parmi les incompatibilités structurelles des interfaces on trouve :
• Ajout d’opérations dans une séquence :
.
Une opération est dans les transitions sortantes de s’ (i.e appartient à s’ ) qui n’est
.
pas dans les transitions entrante de s (i.e. n’appartient pas à s)
Interface P
Interface P’
Ajout
S1
!a
S2
?b
S3
S’1
!c
S’2
?a
S’3
55
Figure4.3 : Ajout d’une opération dans une séquence.
•
Suppression d’une opération dans une séquence :
.
Une opération est dans s qui n’est pas dans s’
Interface P
Suppression
.
Interface P’
S1
?c ?b
S2
S3
!a
!a
S1’
!c
?d
!b
S2’
S5
S3’
?a
!a
S4
?a
S4’
Figure4.4 : Suppression d’une opération dans une séquence
•
•
•
P: {?c, ?b, ?d, !a}
P’: {!c, !b, ?a}
| {?c, ?b, ?d, !a} |-| S{!c, !b, ?a} | ≥1
S1 correspond à S1’
S2 correspond à S2’
S3 correspond à S3’
Redéfinition d’une séquence :
Le service requis sollicite une opération avant ou après une autre.
Ajout ou suppression d’une alternative
Modification d’une opération :
.
Une opération qui apparait dans s qui est modifiée par une autre opération dans s’
.
5.1.5. Algorithme de vérification
Début
Entrée : P=(S, s0, A, T, F, M) et P’= (S’, s0’, A’, T’, F’, M’); //Les LTSs modélisant les
//interfaces des deux services
Sortie : Décision sur la compatibilité structurelle des deux interfaces P et P’
56
1. Compatible := Vrai // Booléen Vrai si la compatibilité structurelle est vérifiée
2. Correspond :=∅
// ensemble de couples de chemins (c,c’) en correspondance
3. Pour tout état final sf∈F déterminer l’ensemble Cheminssf des chemins de s0 à sf
en faisant abstraction des transitions internes (τ)
4. Chemins-P= ∪ sf∈F Cheminssf
// Chemins-P est l’ensemble de tous les chemins
dans P allant de l’état initial vers un état final
5. Pour tout état final sf’∈F’ déterminer l’ensemble Cheminssf’ des chemins de s0 à sf’
en faisant abstraction des transitions internes (τ)
6. Chemins-P’= ∪ sf’∈F’ Cheminssf
// Chemins-P’est l’ensemble de tous les chemins
dans P allant de l’état initial vers un état final
7. Chemins := Chemins-P
8. Tant que (Compatible = Vrai) ∧ (Chemins ≠∅) Faire
9.
Prendre un chemin c∈ Chemins (c=(s0,a0,s1)….(si,ai,si+1)…(sn,an,sf))
10.
Si (∃c’∈ Chemins-P’) ∧ (c’=(s0’,a0’,s1’)….(si’,ai’,si+1’)…(sn’,an’,sf’))
∧∀i=1..n ( (ai= !m∧ ai’= ?m) ∨ (ai= ?m)∧( ai’=!m) )
11.
Alors Chemins :=Chemins –{c} ;
12.
Correspond := Correspond ∪ {(c,c’)}
13.
Sinon Compatible := Faux
14.
Finsi
15. Fin tant que
16. Chemins := Chemins-P’
17. Tant que (Compatible = Vrai) ∧ (Chemins ≠∅) Faire
18.
Prendre un chemin c’∈ Chemins (c’=(s0’,a0’,s1’)….(si’,ai’,si+1’)…(sn’,an’,sf’))
19.
Si (∃c∈ Chemins-P) ∧ (c=(s0,a0,s1)….(si,ai,si+1)…(sn,an,sf))
∧∀i=1..n ( (ai= !m∧ ai’= ?m) ∨ (ai= ?m)∧( ai’=!m) )
20.
Alors Chemins :=Chemins –{c} ;
21.
Correspond := Correspond ∪ {(c,c’)}
22.
Sinon Compatible := Faux
23.
Finsi
24. Fin tant que
25. Imprimer (« Compatibilité structurelle : », Compatible)
Fin
57
5.2. Vérification de la compatibilité des types des données
Pour prendre en compte l’aspect compatibilité des types de données échangées dans la
compatibilité syntaxique, nous proposons la définition suivante.
5.2.1. Définition formelle : (Compatibilité des types de données)
Soient :
− Deux services S1 et S2 (structurellement compatibles) ayant respectivement les
ensembles de ports d’entrée In1={in11,in12,…..in1k1} et In2={in21,in22,..in2k2} ; et les
ensembles ports de sortie Out1={out11,out12,…..in1k3}et Out2= ={out21,out22,..in2k4}
− Une relation de correspondance (liaison) L⊆ Out1xIn2∪ Out2xIn1 entre les ports de
S1 et S2.
S2 et S2 sont compatibles au niveau types de données selon la correspondance L si et
seulement si :
∀(m1,m2)∈L (tm1= tm2) ∨ (tm1 < tm2)
Où
tm est le type du message m
t1 < t2 dénote la relation de sous-type (t1 est sous-type de t2)
On notera (S1 ≈ S2) le fait que deux services S1 et S2 sont syntaxiquement compatibles.
syn
5.2.2. Exemple :
Soit la composition de quatre services (S1, S2 , S3 et S4), les paramètres d’entrée et de sortie
sont indiqués à coté de chaque service. (Figure 4.5)
S1 et S2 sont syntaxiquement compatibles parce que le format des données de S1 (A : entier)
est un sous-type de celui du service S2 (A : réel).
S3 et S4 ne sont pas syntaxiquement compatibles car le type Réel n’est pas sous-type des
entiers.
S1
S3
A (entier)
A (réel)
B (entier)
B (entier)
C (Réel)
C (entier)
S2
S4
58
Figure4.5 : Exemples de (in)compatibilité des types de données
5.2.3. Principe de vérification
Le principe de la vérification de la compatibilité des types de données est simple. Il consiste à
comparer les types des ports de service S1 avec les types des de ports ceux de S2. Dans la
section précédente nous avons supposé que les ports en relation portent le même nom dans les
deux services, ce qui n’est pas le cas dans la réalité (vu que les services sont développés
indépendamment les uns des autres). Cette relation est définie par celui qui procède à la
composition des services. La vérification se résume à vérifier que chaque type d’un port de
sortie de l’un des deux services est égal ou est sous-type, du type du port d’entrée
correspondant dans l’autre service.
5.2.4. Algorithme de vérification
Début
Entrées :
t1: In1∪Out1→TYPE // Fonction typage des ports de S1
t2: In2∪Out2→TYPE // Fonction typage des ports de S2
L1⊆ Out1xIn2
// Correspondance entre ports de sortie de S1 et entrée de S2
L2⊆Out2xIn1S2
// Correspondance entre ports de sortie de S2 et entrée de S1
Sortie : Décision sur la compatibilité des types de données de S1 et S2
1. Compatible := Vrai
2. L :=L1
3. Tant que (Compatible=Vrai) ∧ (L ≠∅ ) faire
4.
Prendre (m1,m2)∈L
5.
Si t1m1 =t2m2 ∨ t1m1<t2m2
6.
Alors L := L-{(m1,m2)}
7.
Sinon Compatible :=Faux
8.
Finsi
9. Fin tanque
10. L :=L2
11. Tant que (Compatible=Vrai) ∧ (L ≠∅ ) faire
59
12.
Prendre (m2,m1)∈L
13.
Si t1m1 =t2m2 ∨ t2m2<t1m1
14.
Alors L := L-{(m2,m1)}
15.
Sinon Compatible :=Faux
16.
Finsi
17. Fin tant que
18. Imprimer (« Compatibilité structurelle : », Compatible)
Fin
Remarque :
La vérification des structures de données dans les compositions de services Web se ramène à
un problème de vérification du typage. Les informations de typage des ports des services sont
disponibles dans la description WSDL du service.
6. Génération d’adaptateur
Les incompatibilités syntaxiques sont assez fréquentes car les services sont développés par
différents fournisseurs. Certaines de ces incompatibilités peuvent être résolues grâce à
l’utilisation de médiateurs ou adaptateurs.
En effet, sur la base de types d’incompatibilité qui peuvent être détectés entre les LTSs, un
adaptateur pourra être généré automatiquement pour résoudre ces incompatibilités lors de
l’exécution.
En d’autres termes, si un client envoie un message vers un fournisseur, le message est dans un
premier temps reçu par le médiateur avant que ce dernier ne décide de le transmettre à son
destinataire après traitement si nécessaire. Le rôle de ce médiateur est de garantir la cohérence
des interactions entre deux services web c.à.d. de réconcilier la conversation initiée par un
service client selon l’interface qu’il requiert avec celle que le service fournisseur fournit.
Envoi et
réception de msg
SOAP
Service
fournisseur
msg
SOAP
Service
client1
⁞
Médiateur
⁞
Service
client2
Figure4.6: Principe d’un médiateur
60
Par exemple le médiateur peut résoudre certaines incompatibilités structurelles comme par
exemple celle représentée dans la Figure suivante :
+m1&m2
S1
Adaptateur
(split)
-m1
-m2
S2
Figure 4.7: Adaptation structurelle
Le médiateur peut également résoudre certaines incompatibilités de types de données. Par
exemple si le type de données envoyées par S1 est un couple (a,b) et S2 requiert le couple
(b,a), un médiateur peut également être conçu pour procéder à une telle transformation de
types de données.
+(a,b)
S1
Adaptateur
(de type)
-(b,a)
S2
Figure 4.8 : Adaptation de type de données
Cependant un médiateur ne peut pas résoudre toutes les incompatibilités syntaxiques
possibles.
7. Conclusion
Dans cette partie, nous avons abordé la définition de la compatibilité syntaxique entre les
services web dans une composition en l’illustrant par des exemples. Ensuite nous avons
évoqué les différentes approches de vérifications existantes.
Pour aboutir à une composition syntaxiquement correcte, nous avons divisé la vérification en
deux parties : une vérification de la structure de données et une vérification des types de
données.
Pour assurer une approche rigoureuse de vérification de la compatibilité syntaxique
(structurelle) nous avons utilisé les systèmes de transitions étiquetées comme formalisme. Sur
la base de ce modèle, nous analysons la compatibilité structurelle dans une composition et
nous avons élaboré un algorithme de détection de ces incompatibilités.
61
Pour la deuxième partie de la vérification concernant la compatibilité des types de données
échangées entre les services d’une composition nous avons proposé une méthode d’analyse et
de vérification.
Enfin nous avons montré que la génération de médiateur peut résoudre certaines
incompatibilités qui sont détectées entre les différents services lors d’une composition.
Le chapitre suivant est dédié à la vérification de l’incompatibilité sémantique entre les
services web d’une composition.
[1] [1] [2] [3] [4] [5] [6] [7] [8] (Fensel, Bussler, & Maedche, Semantic Web Enabled Web
Services, 2002) (Casati & Shan, Models and languages for describing and discovering eservices, 2001) [11] (Kellert & Toumani, 2003) [13] (Bray T. , Paoli, Sperberg-McQueen, &
Maler., 6 Octobre 2000) [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28]
[29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46][47]
[48]
62
Chapitre 5
Vérification de la compatibilité
Sémantique
1. Introduction....................................................................................................................................... 64
2. Définition informelle ......................................................................................................................... 64
3. Approches de vérification existantes ................................................................................................ 64
4. Approche proposée ........................................................................................................................... 65
4.1. Cadre formel ............................................................................................................................... 65
4.2. Définition formelle ..................................................................................................................... 66
4.3. Principe de vérification............................................................................................................... 67
4.4. Algorithme de vérification.......................................................................................................... 68
4. 5. Exemple ..................................................................................................................................... 70
5. Conclusion ......................................................................................................................................... 70
[1] [1] [2] [3] [4] [5] [6] [7] [8] (Fensel, Bussler, & Maedche, Semantic Web Enabled
Web Services, 2002) (Casati & Shan, Models and languages for describing and
discovering e-services, 2001) [11] (Kellert & Toumani, 2003) [13] (Bray T. , Paoli,
Sperberg-McQueen, & Maler., 6 Octobre 2000) [15] [16] [17] [18] [19] [20] [21] [22]
[23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40]
[41] [42] [43] [44] [45] [46][47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]
63
1. Introduction
Comme mentionné dans le chapitre 3, les services web présentent des hétérogénéités au
niveau des données qu’ils échangent. La vérification de la compatibilité syntaxique
(structurelle et types de données) entre les services web composés n’est pas suffisante pour
assurer un échange cohérent des données. En effet la signification véhiculée par ces données
doit être la même dans ces services composés. La sémantique des paramètres est nécessaire à
reconnaitre si l’on considère que la sortie d’un service peut être associée à l’une des entrées
d’un autre service Web.
Dans ce contexte, l’utilisation des ontologies permet de fixer la signification des vocabulaires
utilisés.
Dans ce chapitre, nous nous concentrons sur les flux de données et la vérification de la
compatibilité sémantique entre eux dans une composition de services web.
2. Définition informelle (compatibilité sémantique)
La composition des services web nécessite de définir non seulement l’ordre dans lequel les
services doivent être appelés, mais aussi l’ensemble des paramètres en correspondance.
Chaque paire de paramètres est l’association d’une sortie de service web avec l’une des
entrées de service web suivant. Un tel couplage ne peut exister qu’entre les paramètres
sémantiquement compatibles.
Informellement, deux services web sont sémantiquement compatibles si et seulement si il
existe une correspondance sémantique entre les données émises par un service et celles reçues
par le service suivant.
La sémantique d’une composition de services web est le fait de prendre plusieurs services
web sémantiquement décrits et de les lier ensemble pour répondre aux besoins de l’utilisateur.
3. Approches de vérification existantes
Le problème de l'intégration des données n'est pas un nouveau problème. En particulier, on le
retrouve aussi dans les bases de données hétérogènes distribuées.
Quelques architectures efficaces avec une sémantique ont été développées [58]. Un grand
nombre de ces solutions sont basées sur le modèle relationnel. Ensuite, des méthodes basées
64
sur XML ont été développés [59] . Méthodes de correspondance (matching) de schéma ont été
explorées dans de nombreux ouvrages et en particulier dans [60] [61],
Cependant, dans de nombreux cas, l'approche de correspondance de schéma ne fournit pas
une solution facile pour générer des transformations correspondantes. Le système Clio [62]
fournit l'intégration de XML et des schémas relationnels dans des cadres communs et permet
la génération de transformations après une opération de correspondance (matching) de
schémas. Cependant Clio exige des interactions avec l'utilisateur. Ces interactions sont en
général nombreuses et donc pas toujours souhaitables.
L'intégration des données dans les services Web n’est pas encore bien maitrisée. Des travaux
tels que [63] [64] [65] explorent ce domaine pour trouver des solutions en présentant une
architecture d'intégration pour la composition de services.
Parmi les leaders du matching sémantique entre les services web d’une composition on trouve :
OWLSUDDI [66], RACER [67], le SDS [68], MAMA [69], HotBlu [70] et [71], OWLS-MX [72].
La majorité d'entre eux comparent le profil des services sur la base (entrée/sortie) à la demande
en utilisant le test de subsomption des logiques de description. D'autres approches proposent un
modèle de processus de matching (d’appariement) de service [73]. Dans [74] les auteurs
développent un point à point à la découverte de services Web. Bansal et Vidal [75] utilisent
l'appariement des arbres récursifs pour atteindre le problème de la récupération.
Dans [76] on propose un ensemble de médiateurs pour faire une découverte sémantique de
services web basés WSMO. L'approche METEOR-S [77] améliore la norme WSDL, avec des
descripteurs sémantiques afin de faire une recherche efficace. LARKS [78] et OWLS-MX [85]
proposent une recherche hybride, dans le sens où ils exploitent les deux sémantiques explicites et
implicites par des moyens complémentaires de logique à base et correspondance approximative.
OWLS-MX [79][85] propose quatre variantes de l'algorithme de matching. Le premier est
purement logique et les autres sont des hybrides (c'est à dire qu'ils combinent les contenus en
fonction des paramètres utilisés dans la recherche d'information ainsi que la subsomption
logique). Nous notons que chaque variante utilise un ensemble de filtres et produit sept partitions
de matching.
Dans ce qui suit nous allons proposer une approche de vérification de matching sémantique
entre les services d’une composition basée sur OWLS.
4. Approche proposée
4.1. Cadre formel
Nous nous concentrons sur l’utilisation des annotations sémantiques pour vérifier la
compatibilité des paramètres de services web dans un workflow où l’ordre d’exécution du
service web est déjà connu.
65
L’interprétation consistante des données échangées entre les services web composés est
gênée par les différences dans les représentations et dans les interprétations sémantiques.
Pour surmonter ce problème, le concept d’ontologie est introduit. OWLS (Ontology Web
Language Services) [80] fournit un cadre ontologique, ce qui permet une description abstraite
d'un service. OWL-S respecte une syntaxe XML et une sémantique de OWL qui est lui-même
inspiré de la logique de description. Il s'agit d'une ontologie de haut niveau dont la classe
racine est la classe de service qui correspond directement au service réel qui est décrit
sémantiquement à travers trois classes d’informations :
o ServiceProfile qui spécifie la fonctionnalité d'un service, et un ensemble d'attributs non
fonctionnels, il donne également une description informelle.
o ServiceModel spécifie comment invoquer le service et ce qui arrive quand le service est
exécuté.
o ServiceGrounding spécifie la façon selon laquelle le service doit être invoqué.
Service
profile
Ressources
Fournit
Présente
Service
Supports
Décrit par
Service
grounding
Service
model
Figure5.1 : Les classes supérieures d’une ontologie OWL-S
4.2. Définition formelle (compatibilité sémantique )
Deux services Si et Sj sont sémantiquement compatibles (pour une composition) noté par :
Si ≈ Sj si et seulement si les sorties (pas nécessairement tous) d’un service s’apparient
sémantiquement avec les entrées de l’autre.
Une composition Si ⊕ Sj est définie entre Si et Sj si et seulement si il y a une similarité
sémantique entre Osi et Isj, où :
o Osi (Output of Si) est l’ensemble des sorties du service Si
o Isj (Inputs of Sj) est l’ensemble des entrées du service Sj.
Les paramètres (par exemple : entrée et sortie) de service web font référence à des concepts
dans une ontologie δ où le profile OWL-S [81] peut être utilisé pour les décrire.
66
Lors de chaque passage d’un service web à l’autre, nous examinons toutes les combinaisons
possibles d’une sortie du premier service web avec une entrée du suivant.
4.3. Principe de vérification
Supposons une interaction de deux services Web. Tous d’abord, nous effectuons un matching
sémantique entre les paramètres de ces services au moyen d’une ontologie de domaine et son
raisonneur. Cela donne un jumelage entre les paramètres.
Nous vérifions que la correspondance entre l’entrée (sortie, respectivement) de l'interface du
premier service à la sortie (l’entrée, respectivement) dans l'interface du deuxième service.
La mise en correspondance sémantique est un mécanisme qui vise à trouver les similarités
sémantiques entre deux information. Quatre situations peuvent se présenter :
1) Correspondance identique (exacte) : l’entrée et la sortie ont exactement le même
genre ; formellement, δ→ OSi ≡ ISj
2) Correspondance de généralisation : l’entrée est plus générale que la sortie du service
antérieur ; formellement, δ→ OSi ⊆ ISj
3) Correspondance de spécialisation : l'entrée est plus spécifique que la sortie du service
précédent. Il appartient à l'utilisateur de s'assurer que les conditions d'utilisation du
premier service seront toujours des résultats qui sont sémantiquement compatibles
avec l'entrée du service suivant; formellement, δ→ ISj ⊆ OSi
4) Incompatibilité: l'entrée ne peut pas être conciliée avec la sortie du service précédent.
C'est soit parce que le couplage doit être exclu, ou parce que l'ontologie est
incomplète.
O0Si I0Sj
I0Si
ISi
InSi
Service
Si
OSi
OnSi
ISj
O0Sj
Service
Sj
OSj
InSj
OnSj
La correspondance
entre (OSi et ISj)
Figure5.2 : Correspondance sémantique entre deux services web
67
Nous notons qu’un service web sémantique possède un document OWLS avec un «profil:
hasinput» et un «profil: hasoutput» éléments.
4.4. Algorithme de vérification
Etant donnés deux services Si et Sj, la vérification de la compatibilité sémantique entre des
deux interfaces de Si et Sj revient à vérifier la correspondance entre Out_si et In_sj où Out_si
est un paramètre de sortie du service si , et In_sj est un paramètre d’entrée du service sj
Début
Entrée : C
// ensemble des correspondances entre paramètre de Si et Sj
Sortie : Compatibilité
// booléen Vrai si compatibilité sémantique vérifiée
Compatibilité :=Vrai
Pour chaque correspondance (Out_si, In_sj) ∈ C faire
// Out_si est un paramètre de sortie du service si
// In_sj est un paramètre d’entrée du service sj
Si Out_si ≡ In_sj
alors (Out_si, In_sj) est une correspondance identique ;
Sinon Si Out_si ⊆ In_sj
alors (Out_si, In_sj) est une correspondance de généralisation ;
Sinon Si In_sj ⊆ Out_si
alors (Out_si, In_sj) est une correspondance de spécialisation ;
Sinon si disjoint (Out_si, In_sj)
alors (Out_si, In_sj) est une correspondance incompatible ;
Compatible :=Faux
Finsi
Finsi
Finsi
Finsi
Si ((Out_si, In_sj) est une correspondance identique ou de
généralisation) ∧
(Out_si sémantiquement compatible avec In_sj ) ∧
(aucune correspondance de spécialisation n’a été détectée)
alors Le bon couplage peut être généré automatiquement ;
Sinon
Si ((Out_si, In_sj) est une correspondance identique ou de
généralisation) ∧
(Out_si sémantiquement compatible avec In_sj) ∧
( au moins une correspondance de spécialisation a également été détectée)
68
alors L'appariement sémantiquement compatible est probablement le bon mais d'autre(s)
alternative (s) peut être présentées à l'utilisateur;
Sinon
Si ( (Out_si, In_sj) n’est pas une correspondance identique ou de
généralisation) ∧
(Out_si n’est pas sémantiquement compatible avec In_sj ) ∧
( au moins une correspondance de spécialisation a été détecté)
Alors L'utilisateur doit vérifier laquelle (le cas échéant) de ces alternatives est correcte;
Sinon
Si ((Out_si, In_sj) n’est pas une correspondance identique ou de généralisation) ∧
( Out_si n’est pas sémantiquement compatible avec In_sj ) ∧
( aucune correspondance de spécialisation n’a été détectée)
alors La situation ne peut pas être résolue automatiquement et l'utilisateur doit décider
si le problème réside dans le workflow lui-même ou dans l'ontologie utilisée pour
décrire les paramètres ;
Finsi
Finsi
Finsi
Finsi
Fin Pour
Fin
Remarque :
De la correspondance de données générées, l’utilisateur final peut alors valider, modifier ou
rejeter la correspondance de données suggérées.
69
4. 5. Exemple
Dans notre exemple nous avons trois services Web, le premier service prend un auteur comme
entrée et donne un livre scientifique comme résultat (Figure 5.3). Le deuxième service Web
renvoie l’éditeur d’un certain livre scientifique. Le troisième service Web renvoie l’éditeur
d’un livre donné.
Livre
scientifique
Editeur
S2
Correspondance
identique
Auteur
S1
Livre
scientifique
Correspondance
de généralisation
Livre
Editeur
S3
Figure5.3 : Correspondances identique et de généralisation entre les paramètres des services Web
Notre algorithme cherche s’il ya une correspondance entre ces service Web. Dans ce cas, le
premier service et le deuxième service peuvent être combinés parce qu’il ya une
correspondance exacte (livre scientifique en commun).
De plus, lors de l’application de l’algorithme de vérification entre le premier et le troisième
service on trouve que la sortie du premier service correspond a l’entrée du troisième service
de sorte que la connexion est possible par une correspondance de généralisation (un livre est
la classe supérieure du livre scientifique).
Enfin, grâce à notre approche, nous obtenons des workflow avec une compatibilité
sémantique définie entre les entrées et les sorties des services.
5. Conclusion
Cette partie confirme que la vérification de la compatibilité sémantique est possible en
utilisant les technologies existantes. D’abord, nous avons défini la compatibilité sémantique,
Ensuite, nous avons cité quelques approches existantes. Enfin, nous avons proposé une
approche de vérification de la compatibilité sémantique dans une composition de services web
basé sur les ontologies pour améliorer les descriptions sémantique.
Le prochain chapitre est consacré pour la vérification et la détection du blocage dû à
l’incompatibilité comportementale dans une composition.
70
1. Introduction
Etant donné que différents services Web écrits dans différents langages, par différents
fournisseurs et sur différentes plateformes, peuvent être utilisés dans la même application, des
outils d'analyse sont devenus cruciaux. Le but de ces outils est de vérifier que les interactions
des différents services sont correctes, i.e., les services Web peuvent mener leurs conversations
sans blocage. Ces vérifications sont très importantes, du fait qu'une mauvaise interaction (une
interaction qui n'est pas correcte) peut avoir des conséquences néfastes. En effet, les services
Web sont de nos jours utilisés dans plusieurs domaines, notamment dans des domaines
critiques, tels que le domaine médical et le domaine économique. Par conséquent, assurer que
les interactions sont correctes est primordial.
Du point de vue syntaxique, on doit pouvoir vérifier la compatibilité au niveau structurel ainsi
qu’au niveau des types de données échangées entre les services.
Au niveau structurel, l’ensemble des interactions n’est possible que s’il y a au moins des
échanges (envoi/réception de messages) possibles. Ceci suppose l’existence d’une
correspondance entre les ports d’entrée d’un service, et les ports de sortie du service
partenaire.
Au niveau types de données échangées, la vérification concerne chaque couple de ports (port
de sortie d’un service et le port d’entrées correspondant dans le service partenaire). Les
données envoyées via un port de sorties d’un service doivent avoir des types compatibles avec
ceux des données reçues par le port correspondant du service partenaire.
La compatibilité syntaxique est souvent dite compatibilité d’interface car elle consiste à
comparer les interfaces des deux services à composer. L’ensemble des interactions réalisées
entre un client et un service est appelé conversation. Selon que l’on se réfère à l’interface
qu’un service existant est capable de fournir, ou à l’interface qu’un service est censé fournir,
et donc attendue par les clients, on parle d’interface fournie ou d’interface requise.
L’interface fournie comprend donc les opérations par lesquelles un service Web fournit ses
fonctionnalités à d’autres services. L’interface requise inclut les opérations qu’un service web
a besoin pour mettre en œuvre sa fonctionnalité.
Lorsqu’il s’avère que suite à des modifications l’interface fournie d’un service ne correspond
plus à l’interface que ses partenaires requièrent, que ce soit par une comparaison, ou par un
test de conformité parce qu’une conversation a échoué, il y a deux solutions :
(3) Adapter l’interface requise comme interface fournie et modifier le service en
conséquence ;
71
(4) Introduire un adaptateur qui réconcilie l’interface fournie avec celle requise par les
partenaires.
La première solution est en général non utilisée car le même service peut interagir avec
plusieurs autres services partenaires qui considèrent son interface d’origine. Ce qui conduit à
la situation où le même service peut participer à diverses collaborations qui nécessitent
différentes interfaces fournies. La seconde solution remédie à ce défaut par la fourniture d’un
adaptateur ou d’un médiateur.
Dans ce chapitre nous examinons la compatibilité syntaxique entre deux services web et
nous proposons une approche de vérification de détection des incompatibilités syntaxiques qui
peuvent exister dans une composition de services web.
2. Définition Informelle (compatibilité syntaxique)
Deux services sont déclarés syntaxiquement compatibles si les deux processus sont disjoints
et pour chaque point d’entrée/sortie en commun, l’entrée de l’un correspond à une sortie de
l’autre et vise versa.
La compatibilité syntaxique exige donc que pour chaque opération de l’interface requise
d’une composition de service web, il ya au moins une opération portant le même nom dans
l’interface fournie d’un des services web élémentaires qui correspond en nombre de
séquence et types de paramètres.
3. Exemples
Afin d’illustrer ce type d’incompatibilité lors d'une collaboration, nous présentons des
exemples dans la Figure 4.1. Dans ces exemples, nous considérons deux services S1 et S2. Les
messages sortants sont notés par +m et les messages entrants par –m, un message contenant
des données est noté par m (d1, d2,.., dn). La notation m1&m2 dénote une agrégation (un
message composé) des messages m1 et m2.
S1
+m1 (d1)
-m1 (d1)
-m2 (d2)
+m2 (d2)
S2
(c) : Une composition de services web compatibles
+m1&m2
S1
-m1
-m2
S2
(d) : Incompatibilité syntaxique due à un incompatibilité structurelle
72
S1
+m1 (d0)
-m1 (d1)
-m2 (d2)
+m2 (d2)
S2
(c) : Incompatibilité syntaxique due à l’hétérogénéité des types de données
+m1 (d1)
S1
-m2 (d2)
-m0 (d1)
+m2 (d2)
S2
(d) : Incompatibilité syntaxique due à l’hétérogénéité des types des messages
Figure4.1 : Exemples de compatibilité/incompatibilité syntaxique
4. Approches de vérification existantes
Dans les approches à base de réseaux de Petri [49] [50] [51], les algorithmes de bissimilarité
sont utilisés pour détecter les incompatibilités structurelles entre l’interface fournie par le
service et celle attendue par le client. En cas d’incompatibilité, une trace des erreurs est
retournée au concepteur afin qu’il réajuste la définition de la structure du service. Ces
approches ne traitent pas la situation où, suite à une modification de l’interface fournie par le
service, celle-ci n’est plus compatible avec celle requise par ses clients. De ce fait, le service
fournisseur aussi bien que ses partenaires doivent adapter leurs interfaces structurelles à
chaque nouvelle modification.
Dans d’autres approches ont étudié les incompatibilités syntaxiques qui peuvent se produire
où les messages reçus ou envoyés n’ont pas la structure (type) attendue. La plupart de ces
travaux proposent des adaptateurs qui s’appuient sur des outils de transformation de données
tels que Xpath, XQuery, XSLT. Les approches étudient les incompatibilités structurelles
induites par les différents modes d’envois et de réceptions des messages (voir par exemple
[52] [53] [54]). Les adaptateurs sont construits de manière semi-automatique en se basant sur
des patrons d’incompatibilité identifiés ou en utilisant des opérateurs d’adaptation. Parmi ces
patrons d’incompatibilités structurelles, certains ont une influence sur le comportement,
comme par exemple l’envoi ou la réception de messages superflus, des envois multiples
versus une réception unique, un envoi unique versus des réceptions multiples. Les approches à
base de médiateurs (on parle de patrons de médiation dans [55]), suggèrent la définition de
fournisseurs virtuels qui transforment la structure des messages envoyés et reçus. Cependant,
ces propositions se limitent aux cas d’opérations optionnelles qui n’influent pas sur la logique
73
métier du service. Ici aussi, l’adaptation des interfaces est faite à la conception. Par suite, les
incompatibilités peuvent se produire à la suite des évolutions des interfaces. Ce qui oblige le
concepteur du service à redéfinir l’adaptateur à chaque évolution et pour chaque client.
Des approches sont proposées dans [56] [57] pour l'adaptation d'une interface WSDL de
service aux clients syntaxiquement incompatibles. Dans [57] les auteurs supposent que les
interfaces de tous les services qui fournissent des fonctionnalités similaires soient tirées d'une
interface de base commune à l'aide d'un certain nombre d'opérateurs de dérivation qui
permettent d'ajouter ou de retirer des paramètres de fonctionnement. Cependant, les noms
d'opérations et d'autres aspects de l'interface de service sont les mêmes.
Dans [56] , les auteurs proposent de définir des vues de service au dessus des interfaces
WSDL en modifiant les interfaces WSDL pour permettre les interactions avec les services
incompatibles. Toutefois, aucun soutien automatique à la production de vues n’est proposé.
5. Approche proposée
Dans le but le procéder à la vérification de la compatibilité syntaxique entre deux services
dans une composition, nous distinguons entre deux niveaux : le niveau structurel et le niveau
type de données.
5.1. Vérification de la compatibilité structurelle
Avant de procéder à la vérification il faut représenter les services web dans un contexte
formel commun. Puisqu’il existe différents types de compatibilité à vérifier, certain types de
compatibilité sont plus simples à vérifier dans un formalisme que dans un autre.
Il existe plusieurs formalismes pour la modélisation de la composition des services comme les
réseaux de Petri, la logique temporelle, l’algèbre de processus,...etc. Dans le contexte de notre
travail, nous allons utiliser la modélisation avec les systèmes de transitions étiquetées LTS
(Labled Transition Systems) pour vérifier la compatibilité syntaxique, puisqu’ils permettent
de décrire la structure du service et le contrôle de son exécution (envoi/réception de
messages).
5.1.1 Cadre formel
Nous allons modéliser l’interface d’un service web par un système de transition étiquetées
(Labelled Transition Systems, LTS) qui fournit une représentation formelle des interfaces de
74
service permettant de comparer plus facilement les interfaces et de détecter leurs
incompatibilités structurelles.
Un système de transitions étiquetées (LTS) est un automate, représenté par un graphe orienté
où :
•
Les nœuds désignent les états possibles d’un système. On a trois types d’états : un état
initial, des états finaux (échec ou succès), et les états intermédiaires (traitement
interne).
• Les arcs désignent les transitions entre les états. Ces transitions sont déclenchées par
des événements. Chaque arc est étiqueté par l’évènement dont l’occurrence déclenche
le passage de l’état origine de la transition vers l’état destination. Autrement dit
l’étiquette est soit envoi de messages, réception de messages ou appels d’opération
interne.
Une condition (ou garde) sous forme d’expression booléenne peut être associée à une
transition et le système peut passer d'un état vers un autre en déclenchant la transition
seulement si la contrainte associée est satisfaite.
Definition (LTS)
Un LTS est décrit un 6-uplet P=(S, s0, A, T, F, M) où :
− S : est un ensemble fini d’états ;
− s0 : est l’état initial avec s0 ∈ S ;
− A : est un ensemble fini des évènements (actions) ;
− T : SxA →S est la fonction de transition qui associe à un état source si ∈ S et à un
évènement ak ∈ A , un état destination sj ∈ S noté par ( si, ak, sj) ou « si ak sj » ;
− F : est un ensemble non vide des états finaux avec F⊆ S ;
− M : est un ensemble des messages ;
Un message m peut être envoyé noté !m ou reçu ?m. Il contient une liste de paramètres
m(d1,d2,.., dn) noté m(d)
On a trois types de transitions :
a= !m, a= ?m, ou a= (d1, d2,.., dm ; d1’, d2’,.., dm’).
Une trace est une séquence de plusieurs transitions (un chemin) notée comme suit :
s0
α
α
α
→
s →
s ...→
sn
0
1
1
n−1
2
ou bien (s0,α0,s1) (s1,α1,s2) …..(sn-1,αn-1,sn)
On note :
− s• l’ensemble des transitions sortantes de l’état s
75
− •s l’ensemble des transitions entrantes dans l’état s
− t• l’état cible de la transition t
− •t l’état source de la transition t
Pour pouvoir vérifier la compatibilité syntaxique de deux services web, nous supposons
disposer de la modélisation de leurs interfaces par des LTS. Les deux interfaces à étudier sont
définies donc par deux LTSs P et P’ qui sont respectivement décrit par P=(S, s0, A, T, F, M)
et P’= (S’, s0’, A’, T’, F’, M’).
5.1.2. Exemple
La Figure 4.2 donne un exemple de modélisation par des LTS de deux services Web : le
service de réservation de billets et le service de paiement par carte de crédit (PCC).
Le demandeur spécifie la destination (ville) ainsi que la date du Voyage. Ensuite, le service de
réservation de billets propose une liste de description des billets. Le demandeur fait un choix,
et il fournit un numéro de carte de crédit (ncc) pour compléter la réservation. Ensuite, le
service de réservation de billets appelle le service (PCC) pour vérifier la validité du numéro
de la carte de crédit (ncc) afin de garantir le paiement.
Vu l’intérêt de l’analyse de compatibilité structurelle des services web dans une composition,
nous essayons dans cette partie, de détecter les différentes incompatibilités structurelles entre
deux interfaces de services.
76
? Description
de la demande
(ville, date)
Recherche de
billets (ville, date,
N°, prix, horaires)
S1
S0
! Liste de billets
(N°, prix, horaires)
? Billet choisi
S3
S2
S4
! Prix à
payer (prix)
? Billet payé
(prix, ncc)
! Réservation
confirmée (billet)
S9
S8
! Billet à payer
(prix, ncc)
S7
? Numéro de carte
de crédit (ncc)
S6
? Échec
(ncc erroné)
S5
? Réservation
abandonnée ()
S10
Service de réservation de billets
? Billet à payer
(prix, ncc)
t0
Vérifier ncc
(ncc, approuvé)
t1
Si approuvé=’ok’)
débiter (prix, ncc)
! Billet payé
(prix, ncc)
t3
t2
t5
Si approuvé≠’ok’)
? Échec (ncc erroné)
t4
Service de paiement par carte de crédit (PCC)
Figure 4.2 : Modélisation d’un service de réservation des
billets de vol en ligne à l’aide des LTS
77
5.1.3. Définition formelle : (Compatibilité structurelle)
Soient P= (S, s0, A, T, F, M) et P’= (S’, s0’, A’, T’, F’, M’), deux LTS modélisant les interfaces
de deux services Web. P et P’ sont compatibles pour une composition s’il existe une
conversation entre P et P’ (au moins un chemin d’exécution complet de P et supporté par P’).
Soit mi
le message à invoquer pour la transition courante mi(s1, a, s2) ∈ P
et mj (s1’, a’, s2’) ∈P’ , la compatibilité des messages mi et mj est vérifiée si :
•
•
•
Les noms des messages sont identiques ;
L’état cibles s2 correspond à l’état cible s2’
Les polarités (a, a’) se compensent ( !, ?).
Donc pour détecter les incompatibilités entre P et P’, il suffit d’identifier toutes les différences
qui font que P et P’ ne vérifient pas la définition ci-dessus.
5.1.4 Principe de vérification
Une conversation est incohérente entre deux services si l’interface fournie est différente de
l’interface requise. La détection de l’incompatibilité entre deux services Web repose sur
l’application de l’algorithme de détection des incompatibilités qui examine les LTSs P et P’
correspondant à leurs interfaces. A partir de leurs états initiaux respectifs, on compare les
transitions sortantes des états d’une paire d’états courante (s, s’) et on vérifie les
incompatibilités.
Parmi les incompatibilités structurelles des interfaces on trouve :
• Ajout d’opérations dans une séquence :
.
Une opération est dans les transitions sortantes de s’ (i.e appartient à s’ ) qui n’est
.
pas dans les transitions entrante de s (i.e. n’appartient pas à s)
Interface P
Interface P’
Ajout
S1
!a
S2
?b
S3
S’1
!c
S’2
?a
S’3
78
Figure4.3 : Ajout d’une opération dans une séquence.
•
Suppression d’une opération dans une séquence :
.
Une opération est dans s qui n’est pas dans s’
Interface P
Suppression
.
Interface P’
S1
?c ?b
S2
S3
!a
!a
S1’
!c
?d
!b
S2’
S5
S3’
?a
!a
S4
?a
S4’
Figure4.4 : Suppression d’une opération dans une séquence
•
•
•
P: {?c, ?b, ?d, !a}
P’: {!c, !b, ?a}
| {?c, ?b, ?d, !a} |-| S{!c, !b, ?a} | ≥1
S1 correspond à S1’
S2 correspond à S2’
S3 correspond à S3’
Redéfinition d’une séquence :
Le service requis sollicite une opération avant ou après une autre.
Ajout ou suppression d’une alternative
Modification d’une opération :
.
Une opération qui apparait dans s qui est modifiée par une autre opération dans s’
.
5.1.5. Algorithme de vérification
Début
Entrée : P=(S, s0, A, T, F, M) et P’= (S’, s0’, A’, T’, F’, M’); //Les LTSs modélisant les
//interfaces des deux services
Sortie : Décision sur la compatibilité structurelle des deux interfaces P et P’
26. Compatible := Vrai // Booléen Vrai si la compatibilité structurelle est vérifiée
79
27.
Correspond :=∅
// ensemble de couples de chemins (c,c’) en
correspondance
28. Pour tout état final sf∈F déterminer l’ensemble Cheminssf des chemins de s0 à sf
en faisant abstraction des transitions internes (τ)
29. Chemins-P= ∪ sf∈F Cheminssf
// Chemins-P est l’ensemble de tous les chemins
dans P allant de l’état initial vers un état final
30. Pour tout état final sf’∈F’ déterminer l’ensemble Cheminssf’ des chemins de s0 à sf’
en faisant abstraction des transitions internes (τ)
31. Chemins-P’= ∪ sf’∈F’ Cheminssf
// Chemins-P’est l’ensemble de tous les chemins
dans P allant de l’état initial vers un état final
32. Chemins := Chemins-P
33. Tant que (Compatible = Vrai) ∧ (Chemins ≠∅) Faire
34.
Prendre un chemin c∈ Chemins (c=(s0,a0,s1)….(si,ai,si+1)…(sn,an,sf))
35.
Si (∃c’∈ Chemins-P’) ∧ (c’=(s0’,a0’,s1’)….(si’,ai’,si+1’)…(sn’,an’,sf’))
∧∀i=1..n ( (ai= !m∧ ai’= ?m) ∨ (ai= ?m)∧( ai’=!m) )
36.
Alors Chemins :=Chemins –{c} ;
37.
Correspond := Correspond ∪ {(c,c’)}
38.
Sinon Compatible := Faux
39.
Finsi
40. Fin tant que
41. Chemins := Chemins-P’
42. Tant que (Compatible = Vrai) ∧ (Chemins ≠∅) Faire
43.
Prendre un chemin c’∈ Chemins (c’=(s0’,a0’,s1’)….(si’,ai’,si+1’)…(sn’,an’,sf’))
44.
Si (∃c∈ Chemins-P) ∧ (c=(s0,a0,s1)….(si,ai,si+1)…(sn,an,sf))
∧∀i=1..n ( (ai= !m∧ ai’= ?m) ∨ (ai= ?m)∧( ai’=!m) )
45.
Alors Chemins :=Chemins –{c} ;
46.
Correspond := Correspond ∪ {(c,c’)}
47.
Sinon Compatible := Faux
48.
Finsi
49. Fin tant que
50. Imprimer (« Compatibilité structurelle : », Compatible)
Fin
80
5.2. Vérification de la compatibilité des types des données
Pour prendre en compte l’aspect compatibilité des types de données échangées dans la
compatibilité syntaxique, nous proposons la définition suivante.
5.2.1. Définition formelle : (Compatibilité des types de données)
Soient :
− Deux services S1 et S2 (structurellement compatibles) ayant respectivement les
ensembles de ports d’entrée In1={in11,in12,…..in1k1} et In2={in21,in22,..in2k2} ; et les
ensembles ports de sortie Out1={out11,out12,…..in1k3}et Out2= ={out21,out22,..in2k4}
− Une relation de correspondance (liaison) L⊆ Out1xIn2∪ Out2xIn1 entre les ports de
S1 et S2.
S2 et S2 sont compatibles au niveau types de données selon la correspondance L si et
seulement si :
∀(m1,m2)∈L (tm1= tm2) ∨ (tm1 < tm2)
Où
tm est le type du message m
t1 < t2 dénote la relation de sous-type (t1 est sous-type de t2)
On notera (S1 ≈ S2) le fait que deux services S1 et S2 sont syntaxiquement compatibles.
syn
5.2.2. Exemple :
Soit la composition de quatre services (S1, S2 , S3 et S4), les paramètres d’entrée et de sortie
sont indiqués à coté de chaque service. (Figure 4.5)
S1 et S2 sont syntaxiquement compatibles parce que le format des données de S1 (A : entier)
est un sous-type de celui du service S2 (A : réel).
S3 et S4 ne sont pas syntaxiquement compatibles car le type Réel n’est pas sous-type des
entiers.
S1
S3
A (entier)
A (réel)
B (entier)
B (entier)
C (Réel)
C (entier)
S2
S4
81
Figure4.5 : Exemples de (in)compatibilité des types de données
5.2.3. Principe de vérification
Le principe de la vérification de la compatibilité des types de données est simple. Il consiste à
comparer les types des ports de service S1 avec les types des de ports ceux de S2. Dans la
section précédente nous avons supposé que les ports en relation portent le même nom dans les
deux services, ce qui n’est pas le cas dans la réalité (vu que les services sont développés
indépendamment les uns des autres). Cette relation est définie par celui qui procède à la
composition des services. La vérification se résume à vérifier que chaque type d’un port de
sortie de l’un des deux services est égal ou est sous-type, du type du port d’entrée
correspondant dans l’autre service.
5.2.4. Algorithme de vérification
Début
Entrées :
t1: In1∪Out1→TYPE // Fonction typage des ports de S1
t2: In2∪Out2→TYPE // Fonction typage des ports de S2
L1⊆ Out1xIn2
// Correspondance entre ports de sortie de S1 et entrée de S2
L2⊆Out2xIn1S2
// Correspondance entre ports de sortie de S2 et entrée de S1
Sortie : Décision sur la compatibilité des types de données de S1 et S2
19. Compatible := Vrai
20. L :=L1
21. Tant que (Compatible=Vrai) ∧ (L ≠∅ ) faire
22.
Prendre (m1,m2)∈L
23.
Si t1m1 =t2m2 ∨ t1m1<t2m2
24.
Alors L := L-{(m1,m2)}
25.
Sinon Compatible :=Faux
26.
Finsi
27. Fin tanque
28. L :=L2
29. Tant que (Compatible=Vrai) ∧ (L ≠∅ ) faire
82
30.
Prendre (m2,m1)∈L
31.
Si t1m1 =t2m2 ∨ t2m2<t1m1
32.
Alors L := L-{(m2,m1)}
33.
Sinon Compatible :=Faux
34.
Finsi
35. Fin tant que
36. Imprimer (« Compatibilité structurelle : », Compatible)
Fin
Remarque :
La vérification des structures de données dans les compositions de services Web se ramène à
un problème de vérification du typage. Les informations de typage des ports des services sont
disponibles dans la description WSDL du service.
8. Génération d’adaptateur
Les incompatibilités syntaxiques sont assez fréquentes car les services sont développés par
différents fournisseurs. Certaines de ces incompatibilités peuvent être résolues grâce à
l’utilisation de médiateurs ou adaptateurs.
En effet, sur la base de types d’incompatibilité qui peuvent être détectés entre les LTSs, un
adaptateur pourra être généré automatiquement pour résoudre ces incompatibilités lors de
l’exécution.
En d’autres termes, si un client envoie un message vers un fournisseur, le message est dans un
premier temps reçu par le médiateur avant que ce dernier ne décide de le transmettre à son
destinataire après traitement si nécessaire. Le rôle de ce médiateur est de garantir la cohérence
des interactions entre deux services web c.à.d. de réconcilier la conversation initiée par un
service client selon l’interface qu’il requiert avec celle que le service fournisseur fournit.
Envoi et
réception de msg
SOAP
Service
fournisseur
msg
SOAP
Service
client1
⁞
Médiateur
⁞
Service
client2
Figure4.6: Principe d’un médiateur
83
Par exemple le médiateur peut résoudre certaines incompatibilités structurelles comme par
exemple celle représentée dans la Figure suivante :
+m1&m2
S1
Adaptateur
(split)
-m1
-m2
S2
Figure 4.7: Adaptation structurelle
Le médiateur peut également résoudre certaines incompatibilités de types de données. Par
exemple si le type de données envoyées par S1 est un couple (a,b) et S2 requiert le couple
(b,a), un médiateur peut également être conçu pour procéder à une telle transformation de
types de données.
+(a,b)
S1
Adaptateur
(de type)
-(b,a)
S2
Figure 4.8 : Adaptation de type de données
Cependant un médiateur ne peut pas résoudre toutes les incompatibilités syntaxiques
possibles.
9. Conclusion
Dans cette partie, nous avons abordé la définition de la compatibilité syntaxique entre les
services web dans une composition en l’illustrant par des exemples. Ensuite nous avons
évoqué les différentes approches de vérifications existantes.
Pour aboutir à une composition syntaxiquement correcte, nous avons divisé la vérification en
deux parties : une vérification de la structure de données et une vérification des types de
données.
Pour assurer une approche rigoureuse de vérification de la compatibilité syntaxique
(structurelle) nous avons utilisé les systèmes de transitions étiquetées comme formalisme. Sur
la base de ce modèle, nous analysons la compatibilité structurelle dans une composition et
nous avons élaboré un algorithme de détection de ces incompatibilités.
84
Pour la deuxième partie de la vérification concernant la compatibilité des types de données
échangées entre les services d’une composition nous avons proposé une méthode d’analyse et
de vérification.
Enfin nous avons montré que la génération de médiateur peut résoudre certaines
incompatibilités qui sont détectées entre les différents services lors d’une composition.
Le chapitre suivant est dédié à la vérification de l’incompatibilité sémantique entre les
services web d’une composition.
85
Chapitre 6
Vérification de la compatibilité
Comportementale
1. Introduction....................................................................................................................................... 87
2. Définition informelle (compatibilité comportementale) .................................................................. 87
3. Exemple ............................................................................................................................................. 88
4. Approches de vérification existantes ................................................................................................ 88
5. Approche proposée ........................................................................................................................... 89
5.1. Cadre formel ............................................................................................................................... 89
5.2 Exemple ....................................................................................................................................... 92
5.3. Définition formelle (compatibilité comportementale) .............................................................. 92
5.4. Algorithme de vérification.......................................................................................................... 97
6. Conclusion ......................................................................................................................................... 98
[1] [1] [2] [3] [4] [5] [6] [7] [8] (Fensel, Bussler, & Maedche, Semantic Web Enabled
Web Services, 2002) (Casati & Shan, Models and languages for describing and
discovering e-services, 2001) [11] (Kellert & Toumani, 2003) [13] (Bray T. , Paoli,
Sperberg-McQueen, & Maler., 6 Octobre 2000) [15] [16] [17] [18] [19] [20] [21] [22]
[23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40]
[41] [42] [43] [44] [45] [46][47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58]
[59] [60] [61] (Miller, et al., 2001) [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]
[73] [74] [75] [76] [77] [78] [79] [80] [81]
86
1. Introduction
A ce stade, nous supposons que la compatibilité au niveau syntaxique et sémantique sont
satisfaites, c'est à dire, les interfaces d'entrée et de sortie ont les mêmes types de ports,
opérations, types de messages et mêmes significations. Ce chapitre se concentre sur la
détection du blocage dû à l’incompatibilité comportementale dans une composition.
Une façon de traiter les problèmes de blocage est de modéliser une composition avec les
réseaux de Petri. Les réseaux de Petri ont été reconnus comme l'un des outils les plus
puissants pour décrire et analyser facilement le comportement d’une composition de services
Web. En raison des avantages tels que la nature graphique et la disponibilité des techniques
d’analyses mathématiques, de nombreux chercheurs adoptent des modèles de réseaux de Petri
comme formalisme pour le contrôle d’exécution de services et la détection rapide des interblocages et des cycles [82] [83] [84] [85] [86] [87].
Pour faire face à des blocages basés sur un formalisme des réseaux de Petri, quatre approches
différentes sont développées. La première est appelée évitement d'inter-blocage [88] [89] [90]
[91]. Une fois cette approche adoptée, certaines contraintes sont imposées sur les évolutions
du système de telle sorte qu'il soit toujours possible que le traitement de chaque tâche se
termine. La seconde est la détection de blocage et récupération. Elle permet de détecter le
blocage. Une fois le blocage détecté, certaines actions de récupération peuvent être
manuellement ou automatiquement prises [92] [93]. Cette approche est appropriée quand les
blocages sont rares dans un système et une procédure de détection et de récupération est mise
en place. Les deux dernières approches appartiennent à une approche de prévention de
blocage. La première consiste à utiliser une approche de synthèse de réseaux de Petri pour
construire des modèles avec des propriétés souhaitées telles que la vivacité.
Dans ce chapitre nous allons proposer une approche de vérification des incompatibilités
comportementales dans une composition basée sur les Réseaux de Petri.
2. Définition informelle (compatibilité comportementale)
La compatibilité du comportement signifie que les services Web en interaction sont d'accord
sur ce à quoi s'attendre de l'autre en termes d'opérations à exécuter, de résultats à fournir, et
les messages à envoyer et/ou recevoir.
87
Deux conditions doivent être vérifiées afin d’assurer la compatibilité du comportement dans
une composition des services Web: fin accessible et bonne terminaison [94]. Ceci signifie que
chaque service Web dans une composition peut atteindre un état terminal pour annoncer son
accomplissement.
Bonne terminaison signifie que tous les flux de contrôle du service Web doivent se terminer
lorsque la composition atteint un état terminal. Les deux conditions peuvent être utilisées pour
traiter l'adaptation comportementale des services Web.
Malheureusement, pour la vérification de terminaison correcte, il faut examiner tous les états
terminaux accessibles de la composition. Dans le cas d'un grand nombre d'états, l'examen
énumératif de ces états est très coûteux et fastidieux. Il est donc jugé opportun d'assouplir la
condition de terminaison appropriée de sorte que la complexité de la vérification de la
compatibilité peut être réduite. À cette fin, nous montrons que seule l'exigence de résiliation
accessible doit être satisfaite lors de la vérification de compatibilité comportementale des
services bien structurés
3. Exemple
Comme le montre la Figure 6.1, le service S1 doit recevoir le message m0 (d0) pour envoyer
le message m1 (d1) et en même temps, le service S2 doit recevoir le message m1 (d1) pour
envoyer le message m0 (d0). Ce cas de figure présente un interblocage.
-m0
(d0)
-m1 (d1)
S1
S2
+m1 (d1)
+m0 (d0)
Figure 6.1 : Incompatibilité due à l’hétérogénéité des comportements
Un certain nombre d'approches ont été proposées pour résoudre ces problèmes.
4. Approches de vérification existantes
Les méthodes actuelles suivent essentiellement deux étapes, à savoir, la modélisation et
l'analyse. Il existe une grande variété de méthodes de modélisation pour la vérification de
l'incompatibilité d'un comportement, par exemple, des machines à états abstraits [95],
machines à états finis [96] [97], le processus formel et approches fondées sur π-calcul [98].
Bordeaux et al. [99] utilisent les systèmes de transitions étiquetés pour formaliser le
comportement des services Web. Wohed et al. [100] proposent une analyse de BPEL en
termes d'un ensemble de modèles de workflow. Par extraction du message d'interaction,
Foster et al. [101] proposent une approche basée sur un modèle pour vérifier la composition
88
de services Web à l'aide de diagrammes de séquence de messages. Heckel et Mariani [102]
proposent une méthode basée sur les tests pour vérifier si un service Web par rapport à un
ensemble de règles de transformation de graphes peut satisfaire les opérations d'interaction.
Les réseaux de Petri sont également un outil de modélisation adéquat pour le comportement
de service Web comme il a été montré dans [103], où il est possible de définir et de vérifier
facilement la compatibilité et l'équivalence des services web. Les méthodes basées sur les
réseaux de Petri sont directement applicables à des exemples du monde réel. Presque tous les
formalismes ci-dessus couvrent les activités de base de BPEL.
Chu et Xie [104] ont proposé une méthode basée sur MIP pour détecter les blocages. Par leur
méthode, un siphon banalisé maximale peut être trouvé à un marquage donné. Sur la base des
résultats de Chu, Huang et al. [105] [106] ont proposé un algorithme d'extraction de siphon
minimal de telle sorte que l'énumération complète des siphons a été évitée avec succès.
Plus tard, Huang et al. [107] ont proposé des politiques de prévention de blocage itératifs
basés sur MIP. Dans leurs méthodes, deux types de lieux de contrôle appelés lieux de contrôle
ordinaires et lieux de contrôle pondérés ont été ajoutées au modèle d'origine pour éviter de
banaliser les siphons. Moody et al. [108] ont présenté une méthode basée sur les P-invariants.
Cette méthode a été utilisée par de nombreux chercheurs (Li et Zhou, [109]; Uzam et Zhou
[110]).
5. Approche proposée
5.1. Cadre formel
Les réseaux de Petri est un cadre théorique adéquat pour la vérification et l’analyse de la
composition des services Web. Ils constituent une approche bien fondée ayant une
sémantique formelle pour la modélisation des processus de composition. L’approche basée
sur les réseaux de Petri propose d’utiliser plusieurs opérateurs algébriques tels que: séquence,
choix alternatif, arbitraire.
Un réseau de Petri (RdP) est un graphe orienté, connexe et biparti dans lequel chaque nœud
est une place ou une transition. Les places représentent l’état du système (service) et les
transitions représentent les actions ou évènements dont l’occurrence change l’état du système.
Les réseaux de Petri possèdent une représentation graphique intuitive et très visuelle ainsi que
de nombreux outils de vérification. Des similitudes existent entre les concepts de services web
et celui des réseaux de Petri : les services web sont considérés ici comme un ensemble
d’opérations ordonnées et un ensemble d’états ; les opérations correspondent aux transitions
et les états sont décrits par les places.
À un moment donné, un service Web peut être dans l'un des états suivants : pas instancié,
prêt, en marche, suspendu ou terminé.
Définition 1 : un réseau de Petri (Petri Net) est défini par le tuple N= (P, T, W) où :
P est un ensemble fini de places
89
T est un ensemble fini de transitions (activités de service)
W ⊆ (PXT) U (TXP) est un ensemble d’arcs orientés (relation flux)
Un marquage est une fonction M :P → N + qui associe à chaque place un nombre de jetons
* Un réseau marqué est notée par (N, M).
* p est marquée par M ssi M(p)>0
.
* Une transition t est tirable (franchissable)ssi : ∀ p ∈ t : M(P)>0
noté M[t>
* Le tir d’une transition t dans un marquage M donne un nouveau marquage M’ tel que :
∀p∈P M’( p) = M(p)-1 si p∈ .t -t.
M’( p) = M(p)+1 si p∈ t.-.t
M’( p) = M(p) sinon
On note M[t>M’ le fait que le tir de la transition t dans le marquage M donne M’
* une séquence σ =(t1,t2,..tn) de transitions est tirable dans M0 ssi
M0 [t1>M1 [t2>…Mn-1[tn> M’
* Un marquage M’ est accessible à partir de M0 ssi il existe séquence σ =(t1,t2,..tn)
tirable à partir de M0.
*L’ensemble des marquages accessibles à partir de M0 est noté R(M0)
* Un réseau N est mort sous M0 ssi ∀ t ∈ T, (M0 [t>) i.e aucune transition n’est tirable à
l’état initial.
* Une transition t ∈ T est morte sous M0 si ∄M ∈ R ( M0) où t est franchissable.
L’intérêt de la vérification de la composition est d’offrir des services Web composites
corrects. Ceci est vital pour les entreprises. Un service Web qui contient des erreurs par
exemple des blocages («deadlock») peut causer une perte des clients. Un des avantages des
réseaux de Petri c’est qu’ils sont dotés d’un formalisme très rigoureux avec une disponibilité
d’outils de vérification (détection d’interblocage, et des situations d’erreur).
Un réseau de Petri qui modélise un service web présente quelques caractéristiques qu’il faut
mettre en évidence dans la modélisation. En effet, un service web a état initial d’exécution et
un (ou plusieurs) état(s) finaux. Il a également un état interne et un état interface (ports
d’entrée/sorties des messages). Par conséquent, des classes de réseaux de Petri ont été
définies pour capturer ces caractéristiques des services Web.
Définition 2 : un réseau workflow séquentiel simple (SSN : Simple Sequential workflow Net)
est un réseau N= (P U {i, o}, T, W, A, L) tel que :
• (P U {i, o}, T, W ) est un réseau de Petri
.
i est une place source i.e i= {t ∈T/ (t,i) ∈ W}=Ø
.
o est une place puit i.e o = {t ∈T/ (o,t) ∈ W}=Ø
.
.
• L’ajout d’une transition t qui connecte la place o avec i c.à.d. t = o et t = i, donne un
graphe fortement connexe.
90
•
•
•
•
A est un ensemble d’étiquettes tel que τ ∈ A
L est une fonction d’étiquetage L : T→A telle que τ est l’étiquette des transitions
internes (silencieuses)
A l’état initial, seule la place initial i est marquée : (M0 (i) =1) et ∀ p ≠ i M0 (p) =0
Dans un marquage final Mf ∈ R(M0) Mf (o) ≠ 0
Le comportement d’un SSN est correcte ssi pour tout marquage M accessible à partir de M0
il existe une séquence de transitions σ ∈ T*, qui mène de l’état M vers un marquage final Mf
i.e ∀M∈R(M0), ∃ σ ∈ T*, M[σ> Mf ∧ Mf ∈ F
On note F est l’ensemble de tous les marquages finaux.
Définition 3 : un réseau workflow de service (SWN : Service Workflow Net) est un réseau
de Petri étendu N= (P U PI U PO, T, W) où :
• Le sous réseau généré par P est un SSN correcte.
• PI est l’ensemble des places interface d’entrée
• PO est l’ensemble des places interface de sortie tel que :
(PI ∩PO)= Ø, (PI U PO) ∩ P= Ø
• M0(i)=1 et M0(p) =0 ; ∀ p ≠ i (le marquage initial d’un SWN suit celui de son SSN)
Les places interfaces PI U PO sont représentées par des cercles en pointillés.
91
5.2 Exemple
S1
P0
S2
.
M
q0
t0
.
t’0
P1
M
Y
q1
t1
t’1
P2
Y
q2
t2
t’2
D
P3
P4
X
q3
X
A
D
t3
t4
t’3
K
P5
P6
q4
t5
P7
t’4
t’5
A
B
q5
Figure 6.2 : Modélisation de services Web à l’aide des SWN.
5.3. Définition formelle (compatibilité comportementale)
Définition 4 :
Soient deux services SWN Nj= (Pj U PIj U POj, Tj, Wj ), j ∈ {1, 2}
N1 et N2 sont composables noté N1 ≈ N2 ssi :
• P1∩ P2= Ø ∧ T1 ∩T2= Ø
92