Une approche formelle pour la composition des services web

Transcription

N° d’ordre :
N° de série :
République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de
la Recherche Scientifique
UNIVERSITÉ ECHAHID HAMMA LAKHDAR - EL-OUED
FACULTÉ DES SCIENCES ET TECHNOLOGIE
Mémoire de fin d’étude
Présenté pour d’obtention du diplôme de
MASTER ACADEMIQUE
Domaine : Mathématique et Informatique
Filière : Informatique
Spécialité : Système Distribué et Intelligence
Artificielle
Présenté par


Melle DAHA Hanane
Melle LIFA Siham
Thème
Une approche formelle pour la composition
des services web
Soutenue en juin 2015 devant le jury :
Mr
Kerthiou Ismail
Président
Mr
Meklid AbdEssalam
Examinateur
Mr
Meftah Mohammed Charaf Eddine
Encadreur
Année universitaire : 2014-2015
Remerciements
Nous remercions Allah le tout puissant, qui nous a donné la force et la
patience pour l’accomplissement de ce travail.
Nous adressons nos vifs remerciements à notre encadreur Mr Meftah.
qui nous a aidé tout la durée de notre travail et par patience et les
précieux conseils dont Il nous a entouré.
Nous adressons également nos remerciements, à tous nos enseignants
D’universitaire Echahide Hamma Lakhdhar d'El-Oued,
Surtout Mr.Messoud Abbas pour leurs aides inestimables.
Nous adressons également nos remerciements,
à l'enseignants Amrane Leila et Zaiz Toufik.
On remercie également tous les étudiants de Master 2 (SD &IA) de la
promotion 2014-2015pour leur soutien et leurs précieux encouragements,
Enfin, pour finir et pour être sûre de n’oublier personne,
Nous remercions tout le monde.
i
Dédicaces
Je dédie ce mémoire :
Tout d’abord à mes parents qui m’ont apportés tout le confort
et les moyens pour avoir le meilleur parcours possible tout en
me soutenant tout au long de mon cursus universitaire en me
poussant à donner le maximum de moi-même
A tous mes frères, mes sœurs et toute ma famille
A tous mes amies sans exception
A tous mes collègues de travail dans
CFPA KOUININE
A tous mes stagiaires
A tous ceux qui me sont chers…..
Je dédie ce modeste travail
Avec tout mon amour et tendresse.
Siham
ii
Dédicaces
Louange à Dieu, le seul et unique.
A mes très chers parents
Témoignage d’affection et de grande reconnaissance,
Que Dieu les garde pour moi.
A mes chers frères Ahmed Choukri et sa marie Radja et sa fille
Bouchra, Ben Salem, Nour Eddine
A ma sœur Amel et Son mari Abdellatif et ses filles Rania et
Salsabile.
A mon fiancé Belgacem.
A tous mes proches grands et petits.
À mon binôme Siham que j'estime beaucoup.
A tous mes amies surtout Afaf,
Yousra,Salima,Sara,Besma,Ahlem,Rowa,Intissar et Hadia.
A tous ceux que j’aime.
Je dédie ce modeste travail.
Hanane
iii
Résumé
De nos jours, les services web sont devenus très utilisés notamment par
les entreprises pour rendre accessible leurs métiers et leurs données via le Web.
La composition des services web est un sujet qui suscite l’intérêt des chercheurs,
elle offre la possibilité de traitement de problèmes complexes même avec des
services simples existants tout en coopérant entre eux. Toutefois, cette tâche reste
très complexe et nécessite pour son accomplissement des techniques formelles
[SOF ,14] .
L’objectif principal de notre travail est présente une approche formelle
pour la modélisation de langages de compositions de Services Web et du langage
BPEL4SW en particulier. Ce langage est l’un des standards les plus populaires
pour les orchestrations de Services Web. Nous utilisons ainsi un formalisme que
nous appelons la méthode B et qui est conçu autour des caractéristiques les plus
importantes de BPEL4SW.
Mots-clés : service web, composition de services web, BPEL4SW, Méthode B.
iv
Abstract
In our days, web services have become very used mainly by the
companies to make available their business and data via the Web. The web
services composition is a topic that attracts the interest of researchers. It offers
complex problems process ability even with simple existing web services while
cooperating with each other. However, this task remains highly complex and
requires modeling tools and formal techniques for its completion [SOF ,14] .
In this work, we are presented an approach to formal approach to model
languages for Web Services compositions and BPEL4SW in particular that is one
of the most popular standard for Web Services orchestrations. We propose a
language, called the B method, that is designed around most important BPEL4SW
specific features and that aims to be a formal presentation of this standard.
Keywords: web service, web service composition, BPEL4SW, B method.
v
‫ملخص‬
‫في أيامنا هذه أصبحت خدمات الويب كثيرة االستخدام خصوصا من قبل الشركات وذلك من أجل‬
‫عرض أعمالهم وبياناتهم عبر شبكة االنترنت‪ .‬تعتبر عملية تركيب خدمات الويب من أكثر المواضيع التي‬
‫جلبت اهتمام الباحثين ‪،‬حيث أنها تمكن من معالجة المشاكل المعقدة باالعتماد على خدمات ويب بسيطة‬
‫أخرى وذلك من خالل التعاون فيما بينهم‪ ،‬غير أن هذه العملية معقدة جدا وتتطلب استعمال تقنيات منهجية‬
‫من أجل استعماله ]‪. [SOF ,14‬‬
‫في هذه المذكرة ركزنا اهتمامنا على نماذج للغات تركيب خدمات الويب على وجه الخصوص لغة‬
‫‪، BPEL4SW‬هذه األخيرة التي تعتبر من أكثر المعايير شيوعا بالنسبة لخدمات الويب القياسية ومن‬
‫أجل التنفيذ الصحيح لتركيب خدمات الويب نستخدم نموذج يدعى األسلوب ‪ B‬تم تصميمه حول أهم مالمح‬
‫‪.BPEL4SW‬‬
‫الكلمات الرئيسية ‪ :‬خدمة ويب ‪ ،‬تركيب الخدمات ‪ ، BPEL4SW ،‬األسلوب ‪. B‬‬
‫‪vi‬‬
Glossaire
BPEL4WS: Business Process Execution Language for Web Services;
HTTP: Hypertext Transfer Protocol
LOTOS: Language Of Temporal Ordered Systems;
QoS: Quality of Service;
RdP: Réseau de Petri ;
SOA: Service-Oriented Architecture;
SOAP: Simple Object Access Protocol;
UDDI: Universal Description Discovery and Integration;
UML: Unified Modeling Language;
W3C: World Wide Web Consortium;
Ws: Service Web;
WSCI: Web Services Choreography Interface;
WSCL : Web Service Conversation Language ;
WSDL : Web Services Description Language
WSDL: Web Service Description Language;
WSFL: Web Service Flow Language;
XLANG: Web Services for Business Process Design;
XML: eXtensible Markup Language ;
vii
Table Des Matières
Remerciements ..................................................................................................................................... i
Dédicaces................................................................................................................................................ii
Résumé ..................................................................................................................................................iv
Abstract ..................................................................................................................................................v
‫ ملخص‬.......................................................................................................................................................vi
Glossaire .............................................................................................................................................. vii
Table Des Matières ........................................................................................................................... viii
Listes des figures ................................................................................................................................. xi
Listes des tableaux ............................................................................................................................. xii
Introduction générale ........................................................................................................................ 1
Chapitre I : Architecture Orienté Service & Service web & Approches formelles existantes
I.
Introduction : ................................................................................................................................... 4
II.
Architecture Orientée Services (SOA) : .......................................................................................... 4
II.1
Définition : .............................................................................................................................. 4
II.2
Caractéristiques de l’architecture SOA : ................................................................................. 5
II.3
Acteurs de l’architecture SOA : .............................................................................................. 5
Les services web :........................................................................................................................ 6
III.
III.1.
Définition : .............................................................................................................................. 6
III.2.
Caractéristiques des services web : ......................................................................................... 6
III.3.
Fonctionnement des services web: .......................................................................................... 7
III.4.
Standards de services Web : .................................................................................................... 7
Composition de services Web : ................................................................................................. 15
IV.
V.
IV.1
Définition : ............................................................................................................................ 15
IV.2
Les principales approches de composition de services Web : ............................................... 15
IV.3
Langages utilisés pour la composition des services web : ..................................................... 17
Approches de modélisation et de composition des services Web : ............................................... 19
V.1
Les approches Semi-Formelles (Modélisation)::................................................................... 19
1.
UML : .................................................................................................................................... 19
2.
Réseaux de Petri : .................................................................................................................. 20
V.2
Les approches Formelles (Composition): .............................................................................. 22
1.
Algèbre des processus : ......................................................................................................... 22
viii
2.
Automates.............................................................................................................................. 23
3.
Langage Z : ............................................................................................................................ 24
4.
LOTOS : ................................................................................................................................ 26
Conclusion :............................................................................................................................... 27
VI.
Chapitre II : Analyse du langage BPEL
I.
Introduction : ................................................................................................................................. 30
II.
Présentation : ................................................................................................................................. 30
III.
Avantages et fonctionnalités du BPEL : .................................................................................... 33
IV.
Syntaxe du langage BPEL : ....................................................................................................... 33
Les activités de BPEL : ................................................................................................................. 34
V.
V.1
Les activités basiques : .......................................................................................................... 35
V.2
Les activités de communication : .......................................................................................... 36
V.3
Les activités structurées :....................................................................................................... 37
VI.
Gestion des données : ................................................................................................................ 39
VII.
Corrélation des messages : ........................................................................................................ 39
VIII.
Les scopes : ............................................................................................................................... 40
IX.
Compensation et gestion des erreurs : ....................................................................................... 40
Conclusion :................................................................................................................................... 41
X.
Chapitre Ⅲ : L’Approche Proposée
I.
Introduction : ................................................................................................................................. 43
II.
La méthode B : .............................................................................................................................. 43
II.1
Historique : ............................................................................................................................ 43
II.2
Présentation théorique : ......................................................................................................... 43
II.3
Structure d'une machine abstraite : ........................................................................................ 44
II.4
Raffinement : ......................................................................................................................... 46
II.5
Dépendances entre modules : ................................................................................................ 47
L’approche proposée ................................................................................................................. 48
III.
III.1
Tableau de correspondance B-PBEL4SW................................................................................. 50
IV.
V.
Les règles de traductions : ..................................................................................................... 48
Conclusion :................................................................................................................................... 51
Chapitre IV : Étude de cas : Agence de voyage
I.
Introduction : ................................................................................................................................. 53
II.
Outils B : ....................................................................................................................................... 53
II.1
Objets manipulés par l'Atelier B : ......................................................................................... 53
ix
II.2
Modes d'utilisation de l'Atelier B : ........................................................................................ 54
II.3
Présentation générale :........................................................................................................... 54
III.
Présentation de notre exemple : ................................................................................................. 58
IV.
Scénario de composition : ......................................................................................................... 59
V.
Correspondance B /BPEL : ........................................................................................................... 62
VI.
Spécification formelle de notre exemple : ................................................................................. 63
VII.
Présentation de la preuve formelle de notre exemple : .............................................................. 67
VII.
Conclusion :............................................................................................................................... 69
Conclusion générale ......................................................................................................................... 70
Bibliographies .................................................................................................................................... 72
x
Listes des figures
Figure I. 1:Principaux acteurs de SOA. ...................................................................................... 6
Figure I. 2:Structure de message SOAP. .................................................................................... 9
Figure I. 3:les trois facettes de l'annuaire [HUB, 03]. .............................................................. 11
Figure I. 4:Structures de données de l’annuaire UDDI [ARN ,05]. ......................................... 12
Figure I. 5:Structure d’une description WSDL. ....................................................................... 14
Figure I. 6:Vue générale de l’orchestration [LOP, 08]............................................................. 16
Figure I. 7:vue générale de la chorégraphie [LOP,08]. ............................................................ 17
Figure I.8 :Exemple de modélisation UML pour la composition de service ........................... 20
Figure I. 9:Exemple de modélisation par réseau de Pétri d’un service composé. .................... 21
Figure I. 10:Exemple de représentation en π-calculs d’un service composé ........................... 22
Figure I. 11:Exemple de modélisation de service composé avec les automates ...................... 24
Figure II. 1: BPEL dans l’architecture des services Web ........................................................ 31
Figure II. 2: Structure d'un processus WS-BEPEL .................................................................. 32
Figure Ⅲ. 1:Structure d’une machine abstraite B .................................................................... 46
Figure Ⅲ. 2: La traduction ascendante (BPEL4SW-B) ........................................................... 49
Figure Ⅲ. 3: Les règles de codage (B-BPEL4SW): ................................................................ 49
Figure IV. 1: L'interface principale de l'Atelier B .................................................................... 55
Figure IV. 2: Fenêtre d'éditeur intégré ..................................................................................... 56
Figure IV. 3: Les services Web offerts par l’agence de voyage .............................................. 59
Figure IV. 4: le diagramme de séquence de scénario d’agence de voyage .............................. 60
Figure IV. 5: le diagramme d’activité de scénario d’agence de voyage. ................................. 61
Figure IV. 6: Le schéma global de la Machine d'agence de voyage ReserveAV ................... 63
Figure IV. 7: la Machine global d'agence de voyage ReserveAV .......................................... 63
Figure IV. 8: l'implémentation la Machine global d'agence de voyage ReserveAV.............. 64
Figure IV. 9: la Machine ReserveVOL .................................................................................... 64
Figure IV. 10: la Machine ReserveHOTEL ............................................................................. 65
Figure IV. 11: la Machine ReserveLV ..................................................................................... 66
Figure IV. 12: la Machine ReserveBANK ............................................................................... 66
Figure IV. 13: les étapes de preuve .......................................................................................... 68
Figure IV. 14: les étapes de preuve .......................................................................................... 69
xi
Listes des tableaux
Tab I. 1: Couches technologiques des Web Services [VEZ, 05] ............................................... 7
Tab II. 1: Activités basiques du langage BPEL. ...................................................................... 34
Tab II. 2: Activités complexes du langage BPEL. ................................................................... 34
Tab III. 1: Clauses d'architecture d'une machine abstraite B ................................................... 44
Tab III. 2: différentes actions de raffinage ............................................................................... 47
Tab III. 3 : Clauses de visibilité d'un composant B .................................................................. 47
Tab IV. 1:tableau d’entrées/sorties de chaque service ............................................................. 60
xii
Introduction générale
L’architecture orientée service web (SOA) conçoit les logiciels comme des services et
utilise les services comme des plates-formes. L’orchestration des services décrit quant à elle
comment les services Web peuvent interagir entre eux selon une perspective opérationnelle,
avec des structures de contrôle, incluant l’ordre exécution des interactions. Plusieurs langages
permettent d’exprimer des processus exécutables, mettant en œuvre des services Web. Ces
langages permettent de décrire comment les interactions entre les multiples services sont
coordonnées pour atteindre un but. Cependant, la sémantique opérationnelle de chacune des
structures de ces langages n’est pas formellement définie et limite ainsi les raisonnements et la
vérification des architectures orientées service Web.
Notre travail propose une approche formelle pour la composition des services web. Cette
approche consiste en la génération d'une implémentation de l’application à partir de
spécifications formelles. On décrit préalablement l'application à l'aide de notations graphiques
(UML), puis un processus automatique est appliqué afin de les traduire en spécifications
formelles B. En utilisant le processus de raffinement B, un ensemble de règles de raffinement,
opérant sur les opérations, est appliqué sur les spécifications ainsi obtenues. Ces phases de
raffinement ont pour but de rendre les spécifications finales proches du langage
d'implémentation cible choisi BPEL4SW, de telle sorte que la dernière phase de codage
devienne intuitive et naturelle. De manière générale, le processus de raffinement est une tâche
manuelle, relativement coûteuse, en particulier en phase de preuve. Grâce au caractère
générique de ces règles de raffinement, un outil de raffinement assisté peut être réalisé,
permettant ainsi la réduction du coût du processus de raffinement.
1
Organisation du mémoire
Ce mémoire est organisé suivants les chapitre suivantes :
Chapitre I : Dans ce chapitre, nous introduisons des définitions générales du concept «
Service web». Nous y présentons leur origine, une architecture de référence ainsi que les
langages et protocoles utilisés pour leur déploiement. Nous abordons également le sujet de la
composition des services web. Enfin, nous présentons un aperçu sur les différentes approches
de modélisation et de composition des services web proposées dans la littérature.
Chapitre II : ce chapitre présente plus en détails le langage BPEL.
Chapitre III : ce chapitre est le cœur de notre travail. Il se divise aussi en trois parties: la
première partie est consacrée à étudier la méthode B. La deuxième partie présente l’approche
proposé .la troisième partie présente Tableau de correspondance B-BPEL4SW.
Chapitre IV : Dans ce chapitre nous présentons une étude de cas pour valider notre travail.
Et nous terminerons ce mémoire par une conclusion et des perspectives.
2
Chapitre I
Architecture Orienté Service ( SOA) & Service
web (SW) & Approches Formelles Existantes
Chapitre I
I.
Architecture Orienté Service & Service web & Approches formelles existantes
Introduction :
Avec la grande utilisation du web, les chercheurs ont développé des logiciels pour
assurer et simplifier la communication entre les machines et les applications connectées via le
réseau, ces logiciels sont appelés «services web».
Les services web sont devenus une technique incontournable pour construire des
systèmes distribués faiblement couplés. L’architecture Orientée service a été largement
employée dans plusieurs domaines tel que dans les systèmes e-business, e-gouvernement,
systèmes automobiles, services multimédia, finances et dans beaucoup d’autres domaines
Dans ce chapitre nous allons présenter l’architecture orienté service web et les
différentes couches que les lier, ainsi que les compositions de services web et quelques
langages utilisés, et finalement on situé les différent approches formelle et semi-formelles pour
la modélisation de l’orchestration de service web.
II.
II.1
Architecture Orientée Services (SOA) :
Définition :
Il n’y a pas une définition exacte de l’architecture orienté service. En effet plusieurs
définitions ont été proposées, mais toutes les définitions sont d’accord que SOA est un
paradigme destiné à résoudre les problèmes d’hétérogénéité et interopérabilité des logiciels qui
constituent le système d’information.
SOA est un paradigme permettant d’organiser et d’utiliser des savoir-faire distribués
pouvant être de domaines variés. Cela fournit un moyen uniforme d’offrir, de découvrir,
d’interagir et d’utiliser des savoir-faire pour produire le résultat désiré avec des préconditions
et des buts mesurables [POU, 07].
« L’architecture orientée service constitue un style d’architecture basée sur le principe de
séparation de l’activité métier en une série de services. »
« Ces services peuvent être assemblés et liés entre eux selon le principe de couplage lâche pour
exécuter l’application désirée. »
4
Chapitre I
« Ces services sont définis à un niveau supérieur de la traditionnelle approche composants»
[GAR, 96]
«Architecture orientée service (SOA):est un paradigme d’organisation des ressources
distribuées, potentiellement contrôlées par des domaines différents. »[JEA, 09]
L’architecture SOA peut être utilisée dans un cadre interne à l’entreprise, ainsi les
services peuvent être classés par domaine fonctionnel (achat, finance, marketing, etc.), mais
surtout SOA présente un moyen efficace pour faciliter la communication avec d’autres
entreprises [TOU, 07].
II.2
Caractéristiques de l’architecture SOA :
L’architecture orienté service architecture est caractérisée par :
 Un couplage faible entre les services : implique qu’un service n’appelle pas
directement un autre service.
 La réutilisation de service web.
 L’indépendance par rapport aux aspects technologiques : c-à-d les services avec cette
architecture sont indépendants de ses plates-formes.
 La découverte des services disponibles.
 La mise à l’échelle est rendue possible grâce à la découverte et à l’invocation des
nouveaux services lors de l’exécution.
II.3
Acteurs de l’architecture SOA :
L’architecture orienté service est basée sur trois acteurs principaux (FigureI.1)
définis comme suit :
 Service fournisseur : On peut l’appeler fournisseur il met le service web en
application et il le rend disponible pour tout le monde sur internet.
 Service consommateur : C’est un client demandeur ou un consommateur qui fait la
demande d’un service web bien précis pour répondre à ses besoins.
 Service annuaire : Le registre fournit un endroit où le consommateur peut trouver des
nouveaux services web et le fournisseur dispose une description pour des nouveaux
services web.
5
Chapitre I
Figure I. 1:Principaux acteurs de SOA.
III.
Les services web :
III.1.
Définition :
Un service web est un mécanisme qui tend à donner plus d’interactions pour
permettre à deux entités hétérogènes (entreprises, clients, applications, etc. ...) de
dialoguer à travers un réseau Internet.
Les logiciels écrits dans divers langages de programmation (C#, Visual Basic, Java,
etc....), sur diverses plateformes (Linux, Windows, etc. ...) et avec diverses architectures
peuvent employer des services Web pour échanger des données à travers des réseaux
informatiques. Chaque service web doit pouvoir être découvert et invoqué
dynamiquement par les applications [CYR, 05].
III.2.
Caractéristiques des services web :
Les caractéristiques des services web de type SAOP sont :
 Accessible via le web.
 Décrit à partir de XML.
 Indépendant de plate-forme.
 Conçus pour résoudre des problèmes bien définit et complexe.
6
Chapitre I
III.3.
Fonctionnement des services web:
Dans sa première génération, le fonctionnement des Services web repose sur trois
couches fondamentales présentées comme suit:

Invocation : visant à établir la communication entre le client et le fournisseur en
décrivant la structure des messages échangés.

Découverte : permettant de localiser un service web particulier dans un annuaire de
services décrivant les fournisseurs ainsi les services fournis.

Description : dont l'objectif est la description des interfaces des services web
(paramètres des fonctions, types de données).
Pour assurer ces fonctionnalités, trois technologies de base ont été proposées et disposées en
couches pour construire l'architecture de base des Services web, comme le montre dans la table
suivante (Table I.1) :
Tab I. 1: Couches technologiques des Web Services [VEZ, 05]
Les couches XML et SOAP sont les couches de plus bas niveau, elles permettent le
transport de l'information alors que WSDL permet de décrire le service aux utilisateurs externes.
Enfin la couche la plus haute UDDI décrit ce que peut produire le service, c'est la couche la
plus sémantique [VEZ, 05].
III.4.
Standards de services Web :
Une caractéristique qui a permis un grand succès de la technologie des services web
est qu'elle est construite sur des technologies standards, nous présentons dans cette
section les trois standards de base, à savoir, SOAP (Simple Object Access Protocol),
WSDL (Service web Description Language) et UDDI (Universal Description,
Discovery and Integration) .Ces trois standards sont basés sur le langage XML
(eXtansible Markup Language).
7
Chapitre I
4.1 SOAP :
Les communications entre les différentes entités impliquées dans le dialogue avec le
service web se font par l’intermédiaire du protocole SOAP (Simple Object Access
Protocol). Ce protocole est normalisé par le W3C.
Principe
SOAP, est un standard du Consortium W3C définissant un protocole de transmission de
messages permettant la normalisation des échanges de données. Il présente un ensemble de
règles pour structurer des messages, qui peuvent être utilisées dans de simples transmissions
unidirectionnelles, mais il est particulièrement utile pour exécuter des dialogues requêteréponse RPC (Remote Procedure Call) en utilisant http comme protocole de communication,
mais aussi les protocoles SMTP (Simple Mail Transport Protocol) et POP (Post Office
Protocol) [MIT, 03].
SOAP assure l’interopérabilité entre composants tout en restant indépendant des
systèmes d'exploitation et des langages de programmation, donc, théoriquement, les clients et
serveurs de ces dialogues peuvent fonctionner sur n'importe quelle plate-forme et être écrits
dans n'importe quel langage à partir du moment où ils peuvent formuler et comprendre des
messages SOAP. Il représente donc un composant de base pour développer des applications
distribuées, qui exploitent des fonctionnalités publiées comme services par des intranets ou
Internet.
SOAP utilise principalement les deux standards HTTP et XML :
 HTTP comme protocole de transport des messages SOAP. Il constitue un bon moyen de
transport en raison de sa popularité sur le web.
 XML pour structurer les requêtes et les réponses, indiquer les paramètres des méthodes,
les valeurs de retours, et les éventuelles erreurs de traitements.
Structure du message SOAP
Les messages échangés lors de l’utilisation du protocole SOAP sont basés sur le langage XML.
Ils sont composés de deux parties, l'en-tête de protocole de transport et l'enveloppe SOAP
(Figure I. 2).
8
Chapitre I
Figure I. 2:Structure de message SOAP.
1. L’en-tête du protocole de transport: qui dépend de protocole de transport utilisé, par
exemple si le protocole HTTP est utilisé, l'en-tête contient :
 La version de protocole HTTP utilisé.
 La date de génération de message SOAP.
 Le type d’encodage du contenu (généralement de type XML).
2. L’enveloppe SOAP : la partie principale d’un message SOAP est l’enveloppe
(symbolisée par la balise enveloppe), cette dernière est subdivisée en deux sous-parties:
la partie en-tête (Header) et la partie corps du message (Body).
 L’en-tête du message SOAP: est optionnelle et extensible. Les balises XML
qui permettent de symboliser cette partie sont :<env:Header>
et
</env:Header>.
Ces balises peuvent être complétées par des attributs permettant de définir le domaine
de noms du service Web. En effet, l’en-tête permet principalement d’ajouter des informations
sur le comportement des différents nœuds intermédiaires, lors de traitement du message.
Un nœud étant un intermédiaire SOAP, incluant le récepteur et l’émetteur SOAP, désignable
depuis un message SOAP. Son rôle est de traiter l’en-tête, ensuite de transférer le résultat (le
message SOAP modifié) à un autre intermédiaire (qui peut être le récepteur final).
Les principaux attributs des éléments qui forment le bloc d'en-tête sont :
env :role: permet d’indiquer à quel nœud la fonction décrite est destinée.
9
Chapitre I
env:mustUnderstand: c’est une valeur booléenne, elle permet de préciser que le traitement
devient obligatoire pour un nœud intermédiaire, par exemple, pour un calcul très long, il peut
être utile d’envoyer un e-mail à chaque étape.
env:relay: cet attribut permet de relayer un message à un autre nœud si le premier nœud n’est
pas capable de le traiter.
 Le corps du message SOAP: l'élément corps de message SOAP contient des
données spécifiques à l'application. Les balises symbolisant cette partie sont:
<env:Body>et </env:Body>. Les données doivent donc être sérialisées selon
l’encodage XML. En plus, des données de cette partie peuvent transporter un
type spécial comme: les messages d’erreurs (SOAP Faut).
4.2 UDDI :
UDDI (Universel Description, Discovery and Integration)
est un standard défini par
OASIS. Il définit la structure d’un annuaire de services Web, et
la structure de gestion de
services (publication, localisation, découverte) Sous forme de répertoire, il permet de stocker
les informations nécessaires pour retrouver et accéder à un service, telles que les informations
techniques et l’adresse des services Web, le nom de la personne/société qui gère un service
donné, la description des fonctionnalités [CLE , 03].
Un service d’annuaire UDDI est un service Web qui gère les méta-données des services,
l’information sur les fournisseurs de services et les implémentations des services. Afin de
trouver un service Web, il est possible d’utiliser un annuaire UDDI en précisant des exigences
concernant service requis. On cherche le service par son nom et/ou par des mots clés.
Consultation de l'annuaire :
L'annuaire UDDI se concentre sur le processus de découverte de l'architecture orientée
services (SOA), et utilise des technologies standards telles que XML, SOAP et WSDL qui
permettent de simplifier la collaboration entre partenaires dans le cadre des échanges
commerciaux. L'accès au référentiel s'effectue de différentes manières.
Les informations sur un service publié dans un annuaire UDDI se présentent sous trois facettes
comme illustre dans (la Figure I. 3) [HUB, 03] :

Les pages blanches comprennent la liste des entreprises ainsi que des informations
associées à ces dernières (coordonnées, description de l'entreprise, identifiants...).
10
Chapitre I

Les pages jaunes recensent les services Web de chacune des entreprises sous le standard
WSDL.

Les pages vertes fournissent des informations techniques précises sur les services
fournis.
Figure I. 3:les trois facettes de l'annuaire [HUB, 03].
Un annuaire UDDI est conçu pour être interrogé par des messages SOAP et afin de
pouvoir stocker et fournir des informations permettant l’accès aux documents WSDL (Web
Services Description Language) décrivant les protocoles et les formats de messages nécessaires
pour interagir avec les services Web répertoriés dans l’annuaire ,Les outils de recherche
disponibles sont basés sur des mots-clés et ne prennent pas en considération les relations entre
les services Web et les caractéristiques sémantiques de chaque service Web, forçant l’utilisateur
à recommencer la recherche depuis le début en utilisant de nouveaux termes clés.
Les spécifications UDDI inclue notamment :
Des API SOAP qui permettent l’interrogation et la publication d’informations.
La représentation XML du modèle de données de l’annuaire et des formats de message
SOAP
Des définitions de l’interface WSDL de SOAP,
Des définitions d’APIs de différents modèles techniques qui facilitent le travail des systèmes
d’identification et de catégorisation des enregistrements UDDI.
Un annuaire UDDI se compose de quatre types de structures de données [ARN ,05] : le
businessEntity, le businessService, le bindingTemplate et la tModel. Cette répartition par
11
Chapitre I
type fournit des partitions simples pour faciliter la localisation rapide et la compréhension des
différentes informations qui constituent un enregistrement.
Figure I. 4:Structures de données de l’annuaire UDDI [ARN ,05].

BusinessEntity (entité d'affaires)
Les « businessEntities » sont en quelque sorte les pages blanches d'un annuaire UDDI. Elles
décrivent les organisations ayant publié des services dans le répertoire. On y trouve notamment
le nom de l'organisation, ses adresses (physiques et Web), des éléments de classification, une
liste de contacts ainsi que d'autres informations.

BusinessService (service d'affaires)
Les « BusinessServices » sont en quelque sorte les pages jaunes d'un annuaire UDDI. Elles
décrivent de manière non technique les services proposés par les différentes organisations. On
y trouve essentiellement le nom et la description textuelle des services ainsi qu'une référence à
l'organisation proposant le service et un ou plusieurs « BindingTemplate ».

BindingTemplate (modèle de rattachement)
UDDI permet de décrire des services Web utilisant HTTP, mais également des services
invoqués par d'autres moyens (SMTP, FTP...). Les « BindingTemplates » donnent les
coordonnées des services. Ce sont les pages vertes de l'annuaire UDDI. Ils contiennent
notamment une description, la définition du point d'accès (une URL) et les éventuels «tModels
» associés .
12
Chapitre I

tModel (index)
Les « tModels » sont les descriptions techniques des services. UDDI n'impose aucun format
pour ces descriptions qui peuvent être publiées sous n'importe quelle forme et notamment sous
forme de documents textuels (XHTML, par exemple). C'est à ce niveau que WSDL intervient
comme le vocabulaire de choix pour publier des descriptions techniques de services.
4.3 WSDL :
Le besoin d’une description claire de la communication entre services Web a abouti à des
normalisations aux niveaux des messages échangés et des protocoles. Une grammaire XML
bien structurée était proposée pour décrire les services Web et paramétrer les échanges de
messages. Un langage de description s’est basé sur cette grammaire et est devenu le standard
des services Web, c’est le "Web Service Description Language" (WSDL).
Principes du standard
WSDL [CHR, 01], est un standard du W3C, qui permet de définir une syntaxe XML pour décrire
les méthodes et les paramètres des services Web invocables par le biais de messages au format
SOAP. Il permet de définir qu’est-ce qu’un service Web est capable de faire, son emplacement
et comment l’invoquer.
Eléments de WSDL
Le standard offre une description à deux parties : une première partie de description
abstraite et une deuxième partie Les éléments de description représentent des concepts du
modèle WSDL.
Les éléments de la partie abstraite décrivent principalement le service en termes de
messages (envoyés et reçus). Ils sont indépendamment décrits par un schéma XML de
description concrète.
Au niveau d’une balise XML notée "types", la partie abstraite inclut des éléments notés
"opération" dont chacune associe un ou plusieurs messages à un modèle d’échange de
messages. Le modèle spécifie le nombre et l’ordre ainsi que la cible et la source abstraites des
messages. Les opérations sont groupées dans un élément noté "interface" ou aussi portType"
sans préciser le moyen (le protocole) d’échange de messages.
13
Chapitre I
Techniquement, la structure d’un élément "binding" ressemble à la structure d’un
élément "interface/portType" mais avec des détails en plus. La spécification WSDL offre deux
types de "binding" pour l’envoi de messages entre client et services Web :
 soit intégrés dans des messages du protocole SOAP transmis par exemple en HTTP,
 soit directement par exemple dans des messages du protocole http.
Figure I. 5:Structure d’une description WSDL.
En résume un fichier WSDL contient donc sept éléments :
Types : fournit la définition de types de données utilisés pour décrire les messages échangés.
Messages : représente une définition abstraire (noms et types) des données en cours de
transmission.
PortTypes : décrit un ensemble d'opérations. Chaque opération a zéro ou un message en entrée,
zéro ou plusieurs messages de sortie ou d'erreurs.
Binding : spécifie une liaison entre un <portType> et un protocole concret (SOAP, HTTP...).
Service : indique les adresses de port de chaque liaison.
Port : représente un point d'accès de services défini par une adresse réseau et une liaison.
Opération : c'est la description d'une action exposée dans le port.
14
Chapitre I
IV.
Composition de services Web :
IV.1
Définition :
Une composition de services Web est constituée de plusieurs services qui interagissent
les uns avec les autres [AIT, 08], afin d'offrir de nouvelles fonctionnalités qu'un seul service
ne pourrait pas les offrir.
La composition permet de combiner des services pour former un nouveau service dit
composé ou composite. L’exécution d’un service composé implique des interactions avec
des services partenaires en faisant appel à leurs fonctionnalités. Le but de la composition est
avant tout la réutilisation de services (simples ou composés) et de préférence sans aucune
modification de ces derniers.
IV.2
Les principales approches de composition de services Web :
2.1 : Orchestration de services Web :
L'orchestration de services Web résulte un nouveau service Web dit service Web
composé, qui peut être défini comme l'agrégation de plusieurs autres services Web atomiques
ou composés. Ce service composé contrôle la collaboration entre les services Web engagés dans
la composition, tel qu'un chef d’orchestre [DUM ,10].
L’orchestration de services Web exige de définir l’enchaînement des services Web selon
un canevas prédéfini, et de les exécuter selon un script d’orchestration. Ces derniers (le canevas
et le script) décrivent les interactions entre services Web en identifiant les messages, et en
spécifiant la logique et les séquences d’invocation. Le module exécutant le script
d’orchestration de services Web est appelé un moteur d’orchestration. Ce dernier est une entité
logicielle qui joue le rôle d’intermédiaire entre les services, en les appelants suivant le script
d’orchestration [LOP, 08].
15
Chapitre I
Figure I. 6:Vue générale de l’orchestration [LOP, 08].
2.2 : Chorégraphie de services Web :
La chorégraphie de services Web est une généralisation de l’orchestration qui consiste à
concevoir une coordination décentralisée des services Web. Dans une chorégraphie, les
interactions de type pair-à-pair (P2P) sont décrites dans un langage de description de
chorégraphie (CDL). Les services suivent alors le scénario global de composition sans point de
contrôle central [DUM ,10].
La chorégraphie est aussi appelée composition dynamique. En effet, l’exécution n’est
pas régie de manière statique comme dans une composition de type orchestration. Dans une
chorégraphie à chaque pas de l’exécution, le service Web choisit le service Web qui lui succède
et implémente ainsi une partie de la chorégraphie. La composition de type chorégraphie n’est
pas connue, ni décrite à l’avance [LOP, 08].
16
Chapitre I
Figure I. 7:vue générale de la chorégraphie [LOP,08].
 L'orchestration et la chorégraphie sont toutes deux des manières de composition de
service web agrégé. La différence principale entre ces deux manières, est que dans la
chorégraphie, chaque service connaît les autres services qui interagissent, alors que dans le
cas de l'orchestration, le service qui joue le rôle de chef d'orchestre est le seul qui connaît les
services en interaction.
IV.3
Langages utilisés pour la composition des services web :
Il y a quelque langage pour la composition des services web :
3.1 : Le langage XLANG :
XLANG: (Web Services for Business Process Design) Créé par Microsoft, le XLANG
est une extension de WSDL. Elle fournit en même temps un modèle pour une
orchestration des services et des contrats de collaboration entre celles-ci. XLANG a été
conçus avec une base explicite de théorie de calcul [RAZ, 07].
3.2 : Le langage WSFL
WSFL: (Web Service Flow Language) est un langage basé sur XML pour la description
des services web composite. WSFL considère deux types de compositions de services
web:
 Le premier type indique le modèle approprié d'utilisation d'une collection de
services web, de telle manière que la composition résultante décrive comment
17
Chapitre I
réaliser le but particulier d’un business; typiquement, le résultat est une
description d'un processus métier.
 Le deuxième type indique le modèle d'interaction d'une collection de services
web; dans ce cas, le résultat est une description de l’interaction globale associée
[NER, 06].
3.3 : Langage WSCI :
WSCI : (Services Web Chorégraphie Interface) est un langage de description basé sur
XML dont l'objectif est de décrire les messages échangés entre le service web
participant à des interactions de chorégraphie et les autres services de cette
chorégraphie[WAE, 11].
3.4
Langage WSCL :
WSCL : (Web Services Conversation Language) permet de décrire les conversations
du niveau de la logique du métier ou les processus publics basé sur la définition d’un
service web. Les définitions de conversation en WSCL sont elles-mêmes des
documents XML et peuvent donc être interprétées par des infrastructures de services
web et des outils de développement [CHE, 10].
3.5
Langage BPEL :
BPEL : (Business Process Exécution Language) représente un langage de
programmation standard aidant les entreprises à définir la manière de combiner des
services web[NER, 06].
18
Chapitre I
V.
Approches de modélisation et de composition des services Web :
La composition des services web est un sujet qui a suscité l’attention des chercheurs
qui tentent de fournir des modèles sémantiques rigoureux, des langages et des plateformes pour
la proposition des résultats efficaces pour cette issue.
Comme présenté précédemment, plusieurs langages de composition de services web
ont été proposés au cours de ces dernières années. Il s’agit malheureusement de langages
textuels exécutables conçus pour satisfaire à la phase d’implémentation d’un service web
composé et qui négligent de fait l’étape de spécification qui est importante, car elle facilite la
compréhension globale du système ainsi que la tâche de développement. De plus, l’analyse
formelle des langages proposés n’est pas possible à cause de leur manque de formalisme.
Donc, il est indispensable d’utiliser des techniques et des modèles permettant la
spécification formelle de la composition de services web, dans le but de s’assurer du bon
fonctionnement des services avant de les implémenter.
Différents formalismes, pour la modélisation et la spécification de la composition de
services, ont été proposés. Nous pouvons citer : UML, réseaux de Pétri, les algèbres de
processus et les Automates, langage Z et LOTOS.
V.1
Les approches Semi-Formelles (Modélisation):
1. UML :
UML (Unified Modeling Language ou « langage de modélisation unifié »)
standardisé par l'OMG (Object Management Group) est un langage de modélisation
graphique à base de pictogrammes. Il est apparu dans le monde du génie logiciel, dans
le cadre de la « conception orientée objet ». Couramment utilisé dans les projets
logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine
informatique [WEB, 03].
UML, en particulier le diagramme d’activités, a été adapté pour la modélisation de la
composition de services. L’exécution d’un service est généralement représentée par une
action, c’est à dire une étape de l’activité. La transition vers cette activité modélise alors
l’appel au service et inversement celle en sortie indique la fin de l’exécution du service.
Ce choix de modélisation a été utilisé pour la représentation de l’exemple de
composition dans la figure.
19
Chapitre I
Plusieurs chercheurs ont proposé d’utiliser UML dans le domaine de services
web. Par exemple, dans [Jim, 04], un profil UML a été introduit pour la modélisation
de processus métier à l’aide des diagrammes d’activités. Un nouveau langage basé sur
le diagramme d’activité UML 2.0 pour la modélisation de la composition de services a
été présenté dans [RED, 05]. En utilisant ce langage, le code BPEL peut être généré à
partir des modèles de la composition. Dans [CHR, 08], UML-S (UML pour les Services)
a été proposé pour modéliser la composition de services. Les auteurs ont également
introduit des règles de transformation des diagrammes UML-S en BPEL [WAF, 12].
Figure I.8 :Exemple de modélisation UML pour la composition de service
2. Réseaux de Petri :
Les réseaux de Petri constituent une approche bien établie pour la modélisation de
processus. Un réseau de Petri est un graphe dirigé, connecté et biparti, c’est à dire composé de
deux types de nœuds. Les nœuds représentent soit des places, soit des transitions. Les places
peuvent éventuellement contenir des jetons, qui correspondent généralement aux ressources
disponibles. Lorsqu’un jeton est présent dans chacune des places en entrée d’une transition, la
transition est dite activée et peut alors s’exécuter. L’exécution d’une transition consomme un
jeton dans chaque place en entrée et place un jeton dans chaque place en sortie [CHR, 10].
Les RdPs constituent un Framework pour la modélisation de la composition de services.
La facilité de la compréhension, l’utilisation de ses notations graphiques, ainsi que sa puissance
de vérification et d’analyse formelles à travers un ensemble de bases et techniques
mathématiques, justifient le choix de l’utilisation de cet outil pour des problématiques de
modélisation et de vérification de la composition de services [WAF, 12].
20
Chapitre I
Un service web est modélisé sous forme de RdP en associant les opérations aux
transitions et les états de service en places. Cette approche a été proposée par Hamadi et al dans
[RAC, 03]. Ensuite, pour composer des services web, il suffit d'appliquer des opérateurs de
composition aux réseaux de Petri représentant les dits services web (chaque service web est
représenté par un réseau de Petri). Un réseau de Petri avec une place d'entrée (input place)
pour recevoir des informations et une place de sortie (output place) pour émettre des
informations, facilite la définition des opérateurs de composition, ainsi que l'analyse et la
vérification de certaines propriétés [ANI, 08]. Ce choix de modélisation a été utilisé pour la
représentation de l’exemple de composition proposé précédant dans la figure suivant :
Figure I. 9:Exemple de modélisation par réseau de Pétri d’un service composé.
Les auteurs Ouyang et al. Dans [CHU, 06] présentent une traduction complète et
rigoureuse de BPEL en réseaux de Petri. Cette étude est complète en termes de couverture des
structures de contrôle et des actions de communication de BPEL. Ces règles de traduction sont
utilisées dans Wof BPEL, un outil permettant la vérification de manière automatisée de
processus BPEL [CHR, 10].
Par ailleurs les auteurs Srini al. Dans [SRI, 02] ont défini la sémantique d’un ensemble
d’instructions DAML-S en RdP. En se basant sur cette sémantique, ils ont décrit la
décomposition de services à l’aide du formalisme RdP, et ont mis en œuvre un outil pour décrire
et vérifier automatiquement la composition de services [WAF, 12].
21
Chapitre I
V.2
Les approches Formelles (Composition):
1. Algèbre des processus :
Les algèbres de processus sont des familles de langages formels permettant de modéliser
les systèmes logiciels, en particulier les systèmes distribués et concurrentiels. Au cours des
dernières années, de nombreux chercheurs ont cherché à exploiter les nombreux travaux sur les
algèbres de processus dans le but de définir un modèle sémantique adéquat et de poser des
fondations rigoureuses pour l’étude des applications basées sur les services ainsi que de leur
composition. La nature compositionnelle des algèbres de processus découle naturellement de
leur définition algébrique. Cela est très utile dans le cadre de l’étude des SOA [FAY, 10].
La théorie algèbres de processus est basée sur π- calcul, dans laquelle l'entité de base
est un processus qui peut être un processus vide, un choix entre plusieurs opérations I/O et leurs
continuations, une composition parallèle, une définition récursive, ou une invocation récursive.
Les opérations I/O peuvent être des inputs (receive) ou bien des outputs (send). Par
exemple, x(y) dénote la réception du tuple y sur le canal x; x̅[y] dénote l’envoie du tuple y sur
le canal x. une notation pointillée qui spécifie une séquence d’action par exemple c̅ [1,
d].d(x,y,z). c̅[x+y+z], dans laquelle un processus envoi le tuple [1, d] sur le canal "c", reçoit
dans le canal "d" les composants dont sont reliés aux variable x,y,z puis envois la somme
x+y+z de ces dernières sur le canal "c". La composition de processus parallèle est dénotée A|B.
Plusieurs processus peuvent s’exécuter en parallèle et communiquent en utilisant des canaux
compatibles [CHO, 08]. En utilisant le π- calcul en peut décrire l’exemple précédent par la
figure suivant :
Figure I. 10:Exemple de représentation en π-calculs d’un service composé
22
Chapitre I
De nombreuses variantes de langages formels ont été proposées dans la littérature pour
modéliser les processus algébrique. Nous citons par exemple, CSP (Calculus of Sequential Processes)
proposé par Hoare, CCS (Calculus of Communicating Systems) introduit par Milner et utilisé pour
évaluer l’exactitude qualitative des propriétés d’un système comme le blockage, et LOTOS (Language
Of Temporal Ordered Systems) qui a été standardisé par ISO [WAF, 12].
Récemment, plusieurs travaux de recherche ont utilisés les algèbres de processus pour modéliser
et vérifier la composition de services. Par exemple, une technique de formalisation basée sur CCS pour
la chorégraphie de service avec WSCI a été proposée dans [CAM, 06]. Dans [KOS, 04], la sémantique
du langage de chorégraphie WS-CDL est décrite à l’aide de CSP pour permettre la vérification
automatique de propriétés. Le langage de spécification formel LOTOS a également été considéré,
notamment par Ferrara dans [AND, 04]. Des règles sont présentées pour traduire un processus BPEL en
spécification LOTOS et inversement [CHR, 10].
2. Automates
Un automate est un modèle très connu dans le domaine de la spécification formelle de
systèmes. Un automate est composé d’un ensemble d’états ou nœuds, un ensemble d’actions et
un ensemble de transitions étiquetées entre les états. Les actions sont modélisées par des
étiquettes et une transition étiquetée modélise ainsi l’exécution de l’action lors du
franchissement de celle-ci [CHR, 10].
Le comportement d’un automate est dirigé par un mot fourni en entrée, l’automate passe
alors d’un état à un autre pour exécuter ce mot. On retrouve les automates dans la modélisation
de processus, dans les protocoles de communications, dans l’étude des langages formels et dans
la spécification des processus de composition de services [WAF, 12].
Pour modéliser la composition de service à l’aide d’un automate, on assigne
généralement un état à chaque invocation de service, un événement à chaque réponse d’un
service et un deuxième état pour indiquer la fin de l’activité d’invocation [CHR, 10].
Puisque la sémantique des automates ne prend pas directement en charge la concurrence,
Yan et Dague ont proposé une solution consiste que chaque branche parallèle d’exécution est
modélisée par un automate indépendant et des événements de synchronisation. Ceci nécessite
malheureusement la duplication de l’état d’entrée et de celui de sortie dans chaque branche
parallèle [CHR, 10]. Un exemple d’une telle modélisation est fourni dans la figure.
23
Chapitre I
Figure I. 11:Exemple de modélisation de service composé avec les automates
Différentes classes d’automate ont été proposées pour modéliser le comportement d’un
système, tels que les automates entrée/sortie (E/S) [CHR, 10]. et leurs nombreuses variantes,
les automates temporisés [WAF, 12] [CHR, 10], les automates à états finis [CHR, 10] ou les
automates (max,+) [WAF, 12].
3. Langage Z :
Le langage Z a été développé à l'Université d'Oxford à la suite des travaux de Jean René
Abrial. Selon Davis dans [DAV ,96], Le langage Z est un langage de spécifications formelles
sert à la représentation abstraite de certains aspects d’un produit logiciel, principalement quant
à la manipulation des données (data manipulation design). Ce que nous pouvons comprendre
de la définition de Davis c’est que le langage Z permet de donner une représentation
parfaitement découplée de toute implémentation et c’est exactement ce qu’il veut dire par une
représentation abstraite.
Dans [SPI, 98] Spivey a défini le langage Z comme des Méthodes formelles Techniques,
basées sur les mathématiques, pouvant être utilisées à tous les stages du développement
logiciel. L’idée de Spivey c’est que le langage Z a une sémantique formelle qui permet de rendre
24
Chapitre I
précises des idées de développement auparavant vagues ou simplement intuitives et ça en
réduisant toute expression du langage à une expression logique. Au point de vue sémantique,
le Z peut être subdivisé en trois parties [FOU, 03] :
1. Un langage mathématique utilisant propositions, logique prédicative, ensembles et
relations.
2. Un langage schématique représentant des manipulations algorithmiques de données
ou des objets.
3. Une théorie du raffinement entre des types abstraits de données.
En ce qui nous concerne ce n’est pas la notation mathématique mais celle
schématique car selon Spivey dans [SPI, 98] c’est la notation schématique qui permet de faire
le lien entre les mathématiques pures et une abstraction informatique, n’est basée sur aucune
formalisation.
Alors pour spécifier un système avec le langage Z nous devons utiliser les définitions et
les schémas suivants [MAZ, 01]:
 Définition des ensembles de base.
 Définition des types.
 Schéma d’état (espace d’état).
 Schéma d’initialisation.
 Schéma d’opération.
A partir des éléments constituants de la spécification Z décrites au dessus, nous
concluons qu’elle est structurée en schémas ; cependant nous pouvons tirer deux composantes
principales d’une spécification formelle en Z qui sont :
a)- Des déclarations globales : noms de types, d’ensembles, abréviations (équivalences
syntaxiques et définitions génériques).
b)- Un ou plusieurs types de schémas.
Nous avons vu que la seconde composante d’une spécification formelle en langage Z
c’est le schéma. Les schémas viennent toujours en trois parties [FOU, 03]:
 Un nom qui identifie le schéma en portée globale sur la spécification.
25
Chapitre I
 Une partie déclarative (peut être vide) qui définit les différentes données
membres du schéma. Les données définies pour la première fois sont de portée
locale. Son contenu s’appelle signature.
 Une partie prédicative (peut être vide) qui énumère les contraintes que doivent
respecter les données accessibles dans la portée courante, localement ou
globalement, pour que le schéma soit suivit.
Généralement nous pouvons distinguer aussi deux types de schémas qui sont :
1) Orientés données: ils regroupent ou décrivent alors un ensemble de données. Ils
donnent possiblement leur état initial.
2) Orientés opérations: ils donnent alors des manipulations abstraites des données
définies ailleurs, possiblement dans des schémas orientés données.
Finalement nous pouvons dire que le langage Z est utilisé pour composer et
structurer une série de descriptions mathématiques c'est-à-dire qu’il permet de grouper
ensemble des informations (données ou opérations), de les encapsuler et de les nommer pour
réemploi.
4. LOTOS :
LOTOS est un langage parallèle qui s'inspire des algèbres de processus: le contrôle
des programmes est décrit par des expressions algébriques appelées comportements. La
synchronisation et la communication s'exécutent exclusivement par rendez-vous, sans partage
de mémoire.
Comme la plupart des langages de programmation, LOTOS permet de définir et de
manipuler des structures de données. Mais, à la différence des langages classiques, LOTOS
utilise le formalisme des types abstraits algébriques (Abstract Data Types, ADT).
Dans une large mesure, le choix des types abstraits pour la description des structures de
données est conforme aux objectifs d'un langage de spécification [HUR ,89]: les spécifications
algébriques constituent un modèle mathématique exprimant les propriétés que doit vérifier toute
26
Chapitre I
réalisation, sans imposer de contraintes d'implémentation superflues les propriétés des données
et des opérations sont complètement décrites.
En choisissant les types abstraits, LOTOS évite les difficultés rencontrées en Estelle où
les données sont spécifiées au moyen des types du langage PASCAL, ce qui pose des problèmes
bien connus.
Les spécifications LOTOS
Selon Garavel dans [GAR ,89], une spécification LOTOS est un texte ASCII qui
regroupe un ensemble de définitions de processus (encadrées par les mots-clés \process" et
\endproc") et de définitions de types (délimitées par les mots-clés \type"et \endtype").LOTOS
possède une structure de blocs imbriqués :
Chaque définition de processus peut contenir des définitions de processus ou de types
qui lui sont locales ; en revanche une définition de type ne peut pas englober d'autres définitions
de types ni de processus. Au plus haut niveau, une spécification LOTOS se comporte comme
une définition de processus, bien que la syntaxe soit légèrement différente de celle des
processus ordinaires (les mots-clés \spécification"et \endspec"sont utilisés).
Les définitions de processus décrivent le contrôle et les définitions de types décrivent
les données. Cette dichotomie qui apparait au niveau syntaxique rend bien compte du fait que
le langage LOTOS se compose de deux parties tout à fait orthogonales qui seront, pour cette
raison, présentées séparément : les structures de contrôle et les structures de données.
Les identificateurs utilisées dans une spécification LOTOS se répartissent en six classes
(processus, portes, variables, types, sortes, opérations) qui seront définies tour à tour. Dans tous
les exemples, les mots clés seront écrits en minuscules et les identificateurs en majuscules.
Le langage de lotos présente deux points forts :
 Il permet de donner une bonne idée du comportement du système surtout au niveau le
plus externe.
 Il possède des opérateurs et des types abstraits assez complets pour exprimer les
fonctions du système.
VI.
Conclusion :
27
Chapitre I
Dans ce chapitre, nous avons présenté de manière générale quelques concepts liés
à la technologie des services web. Nous avons d’abord présenté quelques définitions de
ce concept. Nous avons également décrit l’architecture fondamentale des services web
ainsi que les langages et les protocoles de base permettant leur déploiement. Après quoi
nous avons abordé le sujet de la composition de services web. Enfin, nous avons
présenté un survol sur les différentes approches de modélisation et de composition des
services web existantes dans la littérature.
28
Chapitre II
Analyse du langage BPEL
Chapitre II
Chapitre II
I.
Introduction :
Plusieurs langages de compositions de services ont été proposés dans la littérature, le
langage BPEL (Business Process Exécution Langage) est l‘un des plus importants formalismes.
Il est largement utilisé dans le cadre de la mise en œuvre d’une architecture orientée services.
Langage BPEL se caractérise par rapport aux autres langages par sa gestion des
exceptions (fautes et événements), l’exécution parallèle des activités et la synchronisation des
flots, son mécanisme de compensation, et sa gestion de la corrélation des messages.
Dans ce chapitre, nous allons présenter les concepts et syntaxe de langage BPEL.
II.
Présentation :
BPEL, tout d’abord nommé BPEL4WS [IBM, 03] et WS-BPEL [OAS, 07] depuis 2005,
s’est imposé comme le langage standard OASIS d’orchestration de services Web. Il est
largement utilisé dans le cadre de la mise en œuvre d’une architecture orientée services.
Le langage BPEL permet de décrire à la fois :
i.
l’interface comportementale : via la définition d’un processus abstrait spécifiant les
échanges de messages entre différents partenaires.
l’orchestration : via la définition d’un processus privé exécutable qui représente la
ii.
nature et l’ordre des échanges entre partenaires.
BPEL se caractérise par rapport aux autres langages (d’orchestration) par :
 sa gestion des exceptions, en particulier, des fautes et des événements ;
 l’exécution parallèle des activités et la synchronisation des flots ;
 la description des transactions contextuelles (stateful) et de longue durée ;
 son mécanisme de compensation qui est très utile pour les transactions de longue durée
;
 sa gestion de la corrélation des messages
30
Chapitre II
Notons qu’un processus BPEL est directement exécutable par un moteur
d’orchestration de BPEL (e.g. activeBPEL [ACT, 12], Oracle BPEL Process Manager
[ORA ,12]).
BPEL s’appuie sur le langage WSDL puisque chaque processus BPEL est exposé
comme un service Web via une interface WSDL. BPEL utilise les opérations, les données ainsi
que les liens des partenaires décrits dans son interface WSDL. Ce dernier décrit aussi tous les
éléments nécessaires à un processus BPEL pour interagir avec ses partenaires, à savoir,
l’adresse des partenaires, les protocoles de communication et les opérations disponibles.
En outre, BPEL fait appel aux standards WSDL, SOAP, UDDI, mais aussi aux autres
standards de services Web (Figure II.1) tels que :
Figure II. 1: BPEL dans l’architecture des services Web
WS-Addressing, qui est un mécanisme permettant de transporter des messages SOAP de façon
bidirectionnelle, en mode synchrone ou asynchrone [WAD, 14].
WS-Policy, qui est une extension de WSDL permettant d’exprimer les fonctionnalités et les
caractéristiques générales des partenaires (e.g. politiques d’usage, gestion des transactions,
fiabilité, sécurité) [WPO, 14].
WS-Security, qui est une extension de SOAP permettant de sécuriser les échanges de messages
[WSE, 14].
31
Chapitre II
WS-Reliable Messaging, qui est un protocole permettant aux messages d’être délivrés de
manière fiable entre différentes applications réparties, dans le cas de pannes de composants, de
réseaux ou de systèmes [OSI ,11].
WS-Transactions, qui définissent des mécanismes interopérables permettant de réaliser des
transactions entre différents domaines de services Web [IWS ,10].
La description d’un processus BPEL (voir Figure II.) Contient quatre parties principales :
(i)
la déclaration des variables utilisant des types décrits ou importés dans l’interface
WSDL,
(ii)
la description des partenaires
(iii)
la déclaration des gestionnaires de fautes qui sont déclenchés après une exception,
(iv)
l’activité principale qui décrit le comportement du processus.
Figure II. 2: Structure d'un processus WS-BEPEL
32
Chapitre II
III.
Avantages et fonctionnalités du BPEL :
Le langage BPEL présente plusieurs avantages dont nous citons quelques-uns :
 BPEL est basé sur XML, et il supporte les protocoles standards des services web comme
SOAP, WSDL, UDDI.
 Sa spécification a été faite par plusieurs acteurs industriels majeurs, ce qui la rendue
plus finie, plus complète et moins ambiguë. Les objectifs sont donc fixés de manière
claire et précise et chaque élément est bien détaillé.
 Les éléments syntaxiques de BPEL permettent de modéliser les processus abstraits et
les processus exécutables.
 le processus permettant le parallélisme présente également des liens de
synchronisations.
IV.
Syntaxe du langage BPEL :
Une composition des services Web spécifié en langage BPEL est composée de quatre
parties qui sont:
• Les attributs supérieurs :
Cette première partie permet la déclaration des informations concernant le processus métier
comme son nom, les espaces de nom supportés, les documents WSDL ou schémas XML
importés par le processus métier.
• Lien de partenaire :
Cette deuxième partie permet la déclaration des partnerlinks: ces derniers définissent une
liaison entre les ensembles d’opérations des services invoqués par le service Web composite
décrit en BPEL, et un nom de liaison bien précis du service Web engagé dans la composition.
Ces liaisons sont appelées Partner permettent ainsi d’identifier facilement les différents services
Web utilisés dans cette composition (processus métier).
• Les variables :
Cette troisième partie permet de déclarer des variables, utilisant les types importés de
descriptions WSDL associées à la spécification BPEL. Ces variables seront utilisées dans la
partie description comportementale du processus métier, pour maintenir un état au niveau du
service Web, et ainsi assurer des liaisons de données entre deux opérations.
33
Chapitre II
• Les activités:
Les activités décrivent le comportement du processus métier lui-même en utilisant différents
opérateurs. Elles peuvent être basiques ou complexes. Les activités complexes sont composées
d’autres activités basiques ou complexes.
Les deux tableaux Tableau ( II-1 ) et Tableau ( II-2 ) illustrent les différentes activités
basiques et complexes du langage BPEL.
Tab II. 1: Activités basiques du langage BPEL.
Tab II. 2: Activités complexes du langage BPEL.
V.
Les activités de BPEL :
Les activités, pouvant être effectuées par un processus BPEL, sont classées en trois
catégories : activités basiques (ou de base), activités de communication et activités structurées
[OAS, 07].
34
Chapitre II
V.1
Les activités basiques :
Les activités de base sont des activités simples.
Ce sont les activités : <empty>, <throw>, <exit>, <assign> et <wait>.
empty : modélise une absence d’activité ou une activité vide.
La syntaxe est :
<empty standard-attributes>
standard-elements
</empty>
throw : permet de signaler une faute interne au processus BPEL.
syntaxe de cet élément est comme suit :
<throw faultName="qname" faultVariable="ncname" ?
standard-attributes>
standard-elements
</throw>
exit : termine instantanément l’instance d’un processus BPEL.
assign : est utilisée pour mettre à jour les variables du processus BPEL en leur affectant de
nouvelles données.
wait : permet de définir une durée d’attente ou une échéance. Un seul critère d’expiration doit
être spécifié à la fois.
La syntaxe est :
<sequence>
<wait until=’2009-11-19T20 :30’/>
<invoke operation="releaseSlides" .../>
</sequence>
35
Chapitre II
V.2
Les activités de communication :
Les activités de communication sont : <receive>, <reply>, et <invoke>.
Elles sont utilisées pour l’échange des messages entre un processus BPEL, son client et ses
partenaires.
receive : permet d’attendre une invocation d’un service partenaire. Elle peut créer une
instance d’un processus BPEL et le préparer ainsi à l’arrivée d’une réponse.
La syntaxe de l’élément receive est la suivante :
<receive partnerLink="ncname" portType="qname" operation="ncname"
Variable ="ncname"? createInstance="yes|no"?
standard-elements
</receive>
reply : envoie un message en réponse à l’invocation d’un partenaire.
La syntaxe est:
<reply partnerLink="ncname" portType="qname" operation="ncname"
Variable ="ncname"? faultName="qname"?
standard-elements
</reply>
invoke : permet d’invoquer une opération d’un service partenaire. Elle peut servir à la fois pour
une communication synchrone ou asynchrone. L’activité <invoke> asynchrone joue le même
rôle qu’une activité <reply> ; tandis que l’activité <invoke> synchrone invoque une opération
d’un service partenaire mais attend sa réponse.
L’activité invoke est définie comme suit :
<invoke partnerLink="ncname" portType="qname" operation="ncname"
inputVariable="ncname"? outputVariable="ncname"?
</invoke>
36
Chapitre II
V.3
Les activités structurées :
Les activités structurées décrivent l’ordre d’exécution de leurs sous-activités.
Les activités <sequence>, <if>, <while> et <repeat Until> permettent un contrôle
séquentiel.
L’activité <flow> permet quant à elle une exécution parallèle de ses activités ainsi que leur
synchronisation.
Enfin, l’activité <pick> définit un choix contrôlé par l’arrivée d’un événement.
sequence : permet de définir une collection d’activités pouvant être exécutées
séquentiellement.
La syntaxe est :
<sequence standard-attributes>
standard-elementsactivity+
</sequence>
while : permet une exécution répétée de sa sous-activité tant que sa condition booléenne
est satisfaite au début de chaque itération.
Syntaxe :
<while >
<condition> bool-expr </condition>
activity
</while>
repeat Until : permet aussi une exécution répétée de sa sous-activité mais jusqu’à la
satisfaction de sa condition.
Syntaxe :
<repeatUntil standard-attributes>
activity
<condition >
bool-expr
</condition>
</repeatUntil>
37
Chapitre II
if : définit une liste ordonnée de choix conditionnels permettant de sélectionner une seule
activité à exécuter.
pick : attend qu’un message particulier (un événement extérieur) arrive ou qu’une alarme
soit déclenchée. Quand l’un des deux événements se produit, l’activité associée est ainsi
exécutée.
La syntaxe de l’élément <pick>est la suivante :
<pick createInstance="yes|no"? standard-attributes>
standard-elements
<onMessage partnerLink="ncname" portType="qname"
operation="ncname" variable="ncname" ?>+
<correlations>?
<correlation set="ncname" initiate="yes|no" ?>+
</correlations>
activity
</onMessage>
</pick>
flow :permet une exécution parallèle d’un ensemble d’activités et de spécifier un ordre
partiel d’exécution. Une ou plusieurs de ses sous-activités seront donc concurrentes. Les
liens définis dans cette activité permettent de synchroniser et/ou de spécifier des
dépendances temporelles entre les sous-activités de <flow>.
La syntaxe de l’élément<flow>est définie ainsi :
<flow standard-attributes>
standard-elements
<links> ?
<link name="ncname">+
</links>
activity+
</flow>
38
Chapitre II
VI.
Gestion des données :
Un des principaux défis dans l’intégration des services Web, et en particulier des
processus métier, est de traiter les interactions contextuelles (stateful). Ainsi, il est
nécessaire pour tout langage d’orchestration de fournir les moyens nécessaires pour traiter
l’état d’une instance d’un processus métier.
Les processus BPEL permettent de spécifier ces interactions contextuelles
impliquant l’échange de messages entre partenaires. L’état d’une instance d’un processus
métier inclut les messages échangés ainsi que les données intermédiaires utilisées dans le
logique métier et dans les messages envoyés aux partenaires. Le maintien de l’état de cette
instance de processus nécessite l’utilisation de variables.
En plus, les données des états ont besoin d’être extraites et utilisées de façon adéquate
pour contrôler le comportement de l’instance du processus nécessitant des expressions sur
les données.
Enfin, la mise à jour de l’état du processus métier nécessite la notion d’assignation
(de nouvelles valeurs aux variables en utilisant des affectations). BPEL fournit ces fonctions
pour les types de données XML et les types de messages WSDL.
VII.
Corrélation des messages :
La corrélation des messages est le mécanisme de BPEL permettant à des processus
de participer aux conversations. Quand un message arrive à un processus BPEL, il doit être
délivré à une nouvelle instance ou à une instance déjà existante.
Le rôle de la corrélation des messages est donc de déterminer à quelle conversation
un message appartient, et d’instancier/localiser une instance de processus.
BPEL définit un ensemble de corrélation (i.e. <correlationset>) comme un
ensemble de propriétés partagées par tous les messages échangés dans un groupe corrélé.
Cet ensemble est employé pour lier les messages d’entrée et de sortie à une instance de
processus BPEL grâce aux valeurs de corrélation contenues dans ces messages.
Il peut être déclaré dans l’élément <process> de BPEL ou dans une activité <scope>.
Chaque ensemble de corrélation est identifié par un nom qui sera utilisé dans une activité
de communication.
39
Chapitre II
VIII.
Les scopes :
BPEL permet de structurer un processus métier de manière hiérarchique sous forme
de scopes imbriqués.
L’activité <scope> fournit un contexte influant sur l’exécution de ses activités.
Ce contexte inclut des variables, des liens partenaires et des ensembles de
corrélation. Il a ses propres gestionnaires de fautes, d’événements, de terminaison et de
compensation. Ce contexte limite la visibilité de ces définitions aux activités englobées.
Enfin, chaque activité <scope> a une activité principale qui décrit son comportement.
Un scope est défini de la manière suivante :
<scope variableAccessSerializable="yes|no" standard-attributes>
standard-elements
<variables> ?
...
</variables>
<correlationSets>?
...
</correlationSets>
<faultHandlers>?
...
</faultHandlers>
<compensationHandler>?
...
</compensationHandler>
<eventHandler>?
...
</eventHandler>
<terminationHandler>?
...
</terminationHandler>
activity
</scope>
IX.
Compensation et gestion des erreurs :
40
Chapitre II
Les processus métier impliquent des transactions de longue durée qui sont basées sur
des communications (i.e. échanges de messages) asynchrones.
Ces transactions conduisent à un certain nombre de mise à jour pour les partenaires. Par
conséquent, si une erreur se produit, il est nécessaire d’inverser les effets de certaines ou
même de la totalité des activités antérieures. Cela est le rôle de la compensation.
Durant l’exécution d’un processus BPEL, des conditions d’exception peuvent se
produire et doivent être gérées. Un service Web invoqué peut retourner une faute WSDL
qui doit être traitée ; un processus BPEL lui-même peut avoir besoin de signaler une faute
à des clients. Ajoutant à cela, que certaines erreurs peuvent aussi se produire au niveau de
l’environnement d’exécution (des processus BPEL).
Pour BPEL, la gestion des fautes peut être effectuée au niveau d’un processus et/ou
d’un scope. Une activité <scope> définit une unité logique de travail recouvrable et
réversible, pour lequel un ensemble de gestionnaires de fautes et de compensation peut être
défini. Cela en vue de traiter les fautes interceptées, et de défaire le travail effectué dans un
scope en cas d’erreurs. Notons que BPEL permet aussi d’associer des gestionnaires de
fautes à une activité <invoke> (synchrone) pour traiter les fautes d’invocation.
X.
Conclusion :
Au niveau recherche, il existe des langages d’orchestration et des implémentations
commerciales de ces langages permettant d’exécuter des processus basés sur le concept
d’orchestration.
BPEL est une spécification qui représente un langage orienté à la modélisation des
processus qui utilisent les services web pour leur implémentation. Néanmoins, BPEL est un
langage de bas niveau, proche des langages de programmation ce qui le rend difficile à
comprendre.
41
Chapitre Ⅲ
L’Approche Proposée
Chapitre III
L’approche proposée
Chapitre Ⅲ
I.
Introduction :
Le besoin de méthodes formelles et d’outils de génie logiciel est largement reconnus,
et certain travaux ont été déjà réalisés dans ce but. Ce chapitre vise à donner une vue théorique
de la méthode B, Ensuit la raffinement et l’approche proposé. En fin nous allons présenter la table de
correspondance.
II.
II.1
La méthode B :
Historique :
La méthode B (Le choix de la lettre B est un hommage à Bourbaki, groupe de
mathématiciens français qui entreprit en 1939 une refonte des mathématiques, en les reprenant
à leur point de départ logique.) a été introduite au milieu des années 80 par J.-R. Abrial.
[ABR,96]. Sans entrer dans les détails, il est possible de situer B comme une méthode sousjacente aux méthodes formelles VDM (Vienna Développement Method, issue de recherches
réalisées au laboratoire IBM de Vienne dans les années 60. Mise au point par Bjorner et Jones
au cours des années 70.) [JON,93] et Z (Notation introduite par Abrial dans les années 70 (Z
comme Zermelo)) [SPV,94].
Cependant, à la différence de ces dernières, B ne se limite pas à la phase de description
: elle permet d'établir une chaîne de production qui va de la spécification du programme au code
source associé.
II.2
Présentation théorique :
L'objectif initial de B est de fournir une technique et des outils associés capables
d'aider la construction de logiciels de la façon la plus sûre possible. C'est une méthode
transformationnelle : on part d'un modèle abstrait (une machine abstraite), puis on en réduit
le niveau d'abstraction, étape par étape (par des raffinements), jusqu'à l'obtention d'un
modèle concret, proche du code source (l'implémentation).
L'ensemble des composants spécifiant un comportement (du plus abstrait au plus
concret) est appelé module. Un module peut dépendre de plusieurs autres modules, les
principes de dépendance seront vus par la suite.
Il est alors possible, pour un projet (un ensemble de modules) donné, de générer un
code exécutable sécurisé, car totalement prouvé.
43
Chapitre Ⅲ
II.3
Structure d'une machine abstraite :
Une machine abstraite est un sous-système de la spécification du logiciel, caractérisé par
:

un en-tête

la définition d'un état, désigné par les données et l'invariant que ces données doivent
respecter

la description des opérations capables de transformer cet état
Les variables d'état ne peuvent être directement modifiées de l'extérieur de la machine (elles
sont encapsulées), c'est pourquoi il est nécessaire d'introduire non seulement des opérations de
modification, mais aussi des opérations de consultation permettant aux utilisateurs extérieurs
de connaître l'état de la machine.
Une machine abstraite peut être décrite au moyen de nombreuses clauses, dont les plus
courantes sont présentées dans le tableau suivant (Clauses d'architecture d'une machine
abstraite B) :
Tab III. 1: Clauses d'architecture d'une machine abstraite B
Description
Nom
en-tête de la machine : nom et paramètres éventuels.
MACHINE
ensembles de base manipulables par la machine. Ces ensembles
peuvent être abstraits (aucune indication sur le type des
SETS
éléments) ou énumérés (définis par la liste de leurs éléments).
abréviations utilisables dans le texte des autres classes.
DEFINITIONS
variables de la machine, représentant l'état de la machine. Les
variables sont les seules entités qui peuvent être modifiées dans
VARIABLES
l'étape d'initialisation et dans les opérations de la machine. Toute
clause VARIABLES doit être accompagnée des
clauses INVARIANT (typage des variables)
et INITIALISATION.
44
Chapitre Ⅲ
ensemble de prédicats (formules logiques) permettant de typer
les variables de la machine, de définir des propriétés
INVARIANT
mathématiques sur les variables, mais aussi de définir certaines
contraintes que doit vérifier l'état de la machine à tout moment.
valeurs initiales des variables de la machine. Toute variable doit
INITIALISATION
être initialisée en satisfaisant l'invariant.
déclaration et définition des opérations. Les opérations peuvent
être paramétrées en entrée et en sortie. Le corps d'une opération
définit un comportement, et peut être accompagné d'une préOPERATIONS
condition (PRE) qui fixe les conditions sous lesquelles un appel
de l'opération garantit ce comportement.
La figure suivent (III.1) présente la structure syntaxique d'une machine abstraite B.
Dans la figure III.1, les clauses CONSTRAINTS, PROPERTIES, INVARIANT, etc.
Regroupent un ensemble de prédicats (C, P, I, etc.). Le prédicat minimal est le prédicat de
typage qui permet de déterminer le type (le domaine de valeurs) de chacune des données de la
machine. X(j) signifie que la donnée apparait dans le prédicat X. Les prédicats C, Pet I, Init ,
preet S doivent être écrits de telle sorte qu'ils garantissent la consistance interne de la machine
[LAN ,96].
45
Chapitre Ⅲ
Figure Ⅲ. 1:Structure d’une machine abstraite B
II.4
Raffinement :
Le raffinement en B permet d'obtenir une machine plus concrète : c'est le moyen de lever
le non-déterminisme et de préciser les choix de réalisation, tout en conservant un comportement
compatible avec la machine raffinée. L'invariant d'un raffinement contient, en plus du typage
des variables et des contraintes liées au modèle, des prédicats de liaison entre les nouvelles
variables et les variables du composant raffiné : ils forment l'invariant de collage.
Principe du raffinage :
46
Chapitre Ⅲ
L’opération du raffinage se fait en une ou plusieurs étapes successives selon la
complexité de la machine à raffiner et consiste à reformuler les variables et les opérations de la
machine abstraite ; tout au long du raffinage on passera des données abstraites aux données plus
concrètes, et la dernière étape de raffinage est l'étape d'implantation ,dans le tableau ci-dessus
nous résumons en quoi consiste les différentes actions de raffinage aussi bien sur les données
du système(aspect statique) que sur les traitements(aspect dynamique).
Tab III. 2: différentes actions de raffinage
La structure d'un raffinement est très similaire à celle d'une machine abstraite. Seul l'entête
change
:
clause REFINEMENT
la
clause MACHINE est
remplacée
par
une
(ou IMPLEMENTATION, s'il s'agit de l'ultime raffinement du
module), suivie d'une clause REFINES introduite pour désigner le nom du composant raffiné.
II.5
Dépendances entre modules :
Un projet B est constitué de différents modules reliés entre eux par des clauses de
visibilité, dont les plus importantes sont présentées au tableau suivant (Clauses de visibilité d'un
composant B) :
Tab III. 3 : Clauses de visibilité d'un composant B
Nom
Description
47
Chapitre Ⅲ
composition de plusieurs machines (utilisé dans les machines
INCLUDES
abstraites et les raffinements intermédiaires). Une machine ne
peut être incluse qu'une seule fois dans l'ensemble d'un projet.
même principe que la clause INCLUDES, mais pour les
IMPORTS
implémentations.
partage de données entre machines (aucun accès aux opérations
USES
d'une machine utilisée).
accès en lecture seule aux constituants d'une machine
SEES
III.
(impossibilité d'appeler une opération de modification).
L’approche proposée
Une notion importante lors de la conception d’une orchestration est celle d’activité. Les
activités permettent de décrire les différents chemins d’interaction entre les services web, et
permettant d’atteindre un objectif particulier. Le modèle d’activité que nous avons considéré
est décrit par le diagramme d’activité UML.
III.1
Les règles de traductions :
La traduction (descendant/ascendant) en B nécessite des règles de traduction pour
représenter ces structures de contrôle.
1. La traduction descendante (UML-B)
Capturer l’aspect comportemental (diagrammes d’activités) des processus de
l’application. Puis représenter l’exécution des activités des services comme un ensemble de
processus (séquentiels ou parallèles composés d’affectations) en B. Ces affectations sont
ordonnancées par un ensemble de structures de contrôle : composition séquentielle, boucles,
if then else…
2. La traduction ascendante (BPEL4SW-B)
48
Chapitre Ⅲ
Capturer l’aspect comportemental de code source (BPEL4SW) .Puis représenter
l’exécution de ces instructions comme un ensemble de processus : séquentiels ou parallèles
composés d’affectations en B.
Figure Ⅲ. 2: La traduction ascendante (BPEL4SW-B)
3. Les règles de codage (B-BPEL4SW):
Les spécifications abstraites (B), sont raffinées jusqu’à l'obtention du niveau
d'abstraction (en langage B) correspondant à la formalisation des concepts du code source
BPEL4SW. Ce niveau d’abstraction a été défini comme un ensemble d’affectations. Ces
affectations sont ordonnancées par un ensemble de structures de contrôle en BPEL4SW :
composition séquentielle,
boucles, if then else…
Figure Ⅲ. 3: Les règles de codage (B-BPEL4SW):
49
Chapitre Ⅲ
IV.
Tableau de correspondance B-BPEL4SW
WSComposition
BPEL Process
Profile Element
Element
BPEL code
<process name="..."
Transformation(B)
Machine
targetNamespace="..."xmlns Name()
<process>
"CordinateWS"
="..."
...
</process>
"Actor"et
<partnerlinks>
<partnerLinks>
extends *
<partnerLink name="…"
< context identifier >
partnerLinkType="…"
...
partnerRole=".."myRole="..
"WebService"
"/>
</partnerLinks>
"Variable"
"Receive"
<variables>
<variables>
VARIANT
<variable/>
<variable name="..."
variables
...
element="..." </variable>
END
</variables>
</variables>
<receive>
<receive partnerLink="…"
Permet de
portType="QName"
recevoir un
operation="…"
message d’un
variable="…" …
web service
</receive>
Service ∧ message
partenaire
"Reply"
<reply>
<reply …
Réponse = { OK,
Envoie un
</reply>
ERREUR}
<sequence>
Activity
<activity1/>
PRE
<activity2/>
Condition
message (ou une
exception) en
sortie de
processus.
<sequence>
"Sequentiel"
50
Chapitre Ⅲ
…
THEN
</sequence>
ANY Activity
WHERE
Condition
THEN
Activity
END
END ;
<if condition="…">
if condition then
activity
activity
<elseif condition="…">
else
activity
activity
…
end if ;
</if>
end
<while>
<while condition="…">
WHILE (condition)
Effectue un
activity
DO
traitement tant
…
VAR variable IN
que la condition
</while>
Activity1 ;
<if>
"Aternative"
"Iterative"
associée n’est
Activity2 ;
pas respectée.
..
END
V.
Conclusion :
Dans ce chapitre nous nous sommes intéressés les plus utilisés dans le domaine de
la spécification formelle des systèmes complexes. Il s’agit la méthode formelle B.
Dans un premier temps, nous avons présenté la méthode B présentation théorique
et outil ensuite une structure de la machine abstraite et le principe du raffinement puis
les dépendances entre modules. Enfin nous avons proposons une table de transformation
BPEL vers la méthode B.
51
Chapitre Ⅳ
Étude de cas : Agence de voyage
Chapitre IV
Chapitre Ⅳ
I.
Introduction :
Notre approche pour vérifier la composition des services web a été présentée en détails
au cours du chapitre précédent. Pour illustrer les différentes idées et concepts inclus dans notre
proposition nous allons présenter un exemple sous la forme d’une étude de cas. Nous allons
choisir la réservation de voyages en ligne comme un domaine d’application.
II.
Outils B :
Il existe deux ateliers de génie logiciel qui permettent la mise en œuvre de la
méthode B dans des projets industriels : l'Atelier B, diffusé par la société française ClearSy, et
le B-Toolkit de la société britannique B-Core. Tous deux disposent d'outils pour :

l'analyse lexicale des composants

le contrôle de types

la génération d'obligations de preuve

la démonstration automatique des propriétés

la démonstration interactive des propriétés

la traduction en langages de programmation impératifs (C, C++ ou ADA)

la gestion et la documentation des projets
Cette partie a pour but de présenter les différentes fonctionnalités offertes par l'Atelier B.
L'Atelier B est un ensemble d'outils logiciels permettant le développement d'applications
suivant la méthode B.
L'Atelier B assiste le concepteur dans la formalisation de son application :
 En exécutant automatiquement sur les spécifications et leurs raffinements, un certain
nombre d'actions dictées par la méthode,
 En proposant des services annexes à la méthode, mais néanmoins indispensables à des
développements industriels, comme la gestion, l'analyse et la documentation d'un projet.
II.1
Objets manipulés par l'Atelier B :
Nous introduisons dans ce paragraphe les principaux objets manipulés par les fonctions de
l'Atelier B.
53
Chapitre Ⅳ
Composant : Fichier contenant une source écrit en langage B. Il constitue la base d'un
développement suivant la méthode B. Un composant est un terme générique et représente :
_ soit une spécification B (machine abstraite),
_ soit un raffinement de cette spécification,
_ soit son implémentation (dernier niveau de raffinement).
La saisie des composants est réalisée grâce à l'éditeur de texte de la station de développement.
Projet : Ensemble de fichiers (composants, fichiers annexes sources C, C++, HIA, ou ADA,
makefiles) utilisés ou produits durant le développement d'une application suivant la méthode
B, complété des informations nécessaires à la gestion de ces fichiers sous l'Atelier (voir BDP).
Utilisateur : Il est nécessaire de définir une liste d'utilisateurs autorisés à accéder et modifier
le projet. Notez que tous les utilisateurs ont les mêmes pouvoirs, et qu'il est nécessaire qu'au
moins un utilisateur soit renseigné.
Base de Données Projet (BDP) : Toutes les informations internes nécessaires à la bonne
exécution des outils de l'Atelier B sont stockées dans un répertoire nommé BDP. Ce répertoire
contient aussi des fichiers produits par les outils de documentation de l'Atelier B.
II.2
Modes d'utilisation de l'Atelier B :
Nous appelons Outils B les outils liés à l'application de la méthode B, ainsi qu'à l'analyse,
la mise au point et la documentation de logiciels écrits en B. L'environnement B, propose deux
modes d'utilisation des outils B :
-
Un mode interactif, utilisant une interface graphique à base de fenêtres et de boutons
de commande ; dans la suite du document nous appellerons ce mode interface utilisateur
graphique,
-
Un mode programmé, reposant sur un langage appelé langage de commande; dans la
suite de ce document, nous appellerons cette interface utilisateur mode commande.
II.3
Présentation générale :
A) Interfaces
L'interface graphique de l'Atelier B se décompose en deux parties majeures : l'une est dédiée à
la gestion des projets B, et l'autre permet une édition aisée via un éditeur spécialement conçu
pour assister l'utilisateur dans son développement B.
54
Chapitre Ⅳ
Nous aborderons par la suite les détails de l'utilisation de ces dernières.
-
IHM principale
L'interface principale se présente de la façon suivante :
Figure IV. 1: L'interface principale de l'Atelier B
C'est à partir de cette interface que la majeure partie de la gestion des projets B
s'effectue.
-
Éditeur intégré
L'Atelier B est livré avec un éditeur spécifiquement adapté à l'édition de composants B.
Celui-ci propose des fonctionnalités comme l'auto-complétion de mot-clé, le
soulignement en cas d'erreur, etc.
Un aperçu de la fenêtre est donné ci-dessous :
55
Chapitre Ⅳ
Figure IV. 2: Fenêtre d'éditeur intégré
Cette application offre les fonctionnalités suivantes :
-
L'édition des composants,
-
L'édition des fichiers PMM associés aux composants,
-
L'édition des fichiers RMF associés aux composants,
-
L'édition des fichiers PatchProver et PatchRafiner,
-
La coloration syntaxique,
-
L'impression,
-
L'auto complétion et l'indentation automatique,
-
La vérification syntaxique du parenthésage,
-
Une navigation par onglets entre les fichiers.
-
Il inclut en outre un tableau permettant l'insertion aisée des symboles B.
Ce dernier s'utilise comme un éditeur de texte classique et a été conçu de façon à rendre son
utilisation intuitive.
56
Chapitre Ⅳ
B) Pour démarrer
Ce paragraphe décrit plus particulièrement la démarche générale permettant d'utiliser
les fonctions de l'Atelier B.
En résumé, afin de démarrer un développement avec l'Atelier B, vous devez :
1. Créer un projet,
2. Ouvrir ce projet,
3. Ajouter des composants à ce projet.
Ou plus simplement, si vous disposez d'une archive de projet, vous pouvez restaurer cette
dernière et commencer à travailler.
Une fois ces étapes accomplies vous pouvez commencer à appliquer la méthode B sur vos
composants ; il est possible de :
1. Effectuer l'analyse syntaxique et le contrôle de types,
2. Générer les obligations de preuve,
3. Démontrer automatiquement une partie de ces obligations de preuve,
4. Afficher les obligations de preuve,
5. Utiliser le prouver interactif pour démontrer les obligations de preuve restantes
Après avoir créé les implémentations de votre projet, vous serez en mesure de :
1. Contrôler le langage des implémentations,
2. Traduire le projet en langage cible en utilisant un traducteur.
Lors de ces phases du développement, utilisez les fonctions d'analyse de l'Atelier B, pour :
1. Afficher l'état d'avancement du projet ou d'un composant,
2. Afficher des graphes de dépendances entre les composants,
Vous pouvez également utiliser des fonctions de documentation pour produire
automatiquement des documentations au format des traitements de texte LATEX, PDF, ou
RTF.
Lorsque vos projets atteignent une taille importante, vous pouvez :
1. Les archiver pour en faire des sauvegardes,
2. découper vos gros projets en plusieurs petits projets en utilisant la notion de
bibliothèques.
57
Chapitre Ⅳ
III.
Présentation de notre exemple :
Une agence de voyages (service01) fournit les trois services suivants : réservation de billets
d’avion (service02), réservation de chambres d’hôtel (service03) et de location de voiture
(service04). Afin de fournir ces services à ses clients, l’agence doit établir des liens avec d’autres
services : compagnies aériennes, des hôtels, des compagnies de location de voiture et des
banques (service05) pour faciliter les transactions financières entre les clients et l’agence de
voyages et entre l’agence et les autres partenaires.
A cet effet cinq services web peuvent être proposés :
 WS-AV: fournit une interface avec le client, et établir des liens avec les autres
services,
 WS-VOL : permet de réserver les vols selon une date précisée, la ville de départ et
d’arrivée et le nombre de personnes.
 WS-Hôtel : permet de réserver les chambres d’hôtel selon la date et la ville précisé et
le nombre de personnes.
 WS-LV : permet de réserver les voitures selon une date précisée et les nombres de
jours.
 WS-Bank : permet à l’agence et les clients de payer les différentes réservations.
La figure suivante (IV.3) présente les services de notre exemple :
58
Chapitre Ⅳ
Figure IV. 3: Les services Web offerts par l’agence de voyage
IV.
Scénario de composition :
L’objectif principal de ce scénario est de faciliter la compréhension et de montrer
l'enchaînement d'événements de notre approche à travers un exemple simple mais réaliste. Nous
ne cherchons pas ici à montrer que notre approche peut être utilisée pour le développement de
service composés complexes, bien que cela soit tout à fait possible.
Dans cet exemple le service (WS-AV) est la composition de quatre services (WS-VOL, WSHôtel, WS-LV et WS-Bank).
Donc le service WS-AV a comme rôle d’organiser le voyage par internet. Le service fournit aux
clients une interface pour saisie les informations suivantes :
Date de départ, date de retour, ville départ, ville arrivé et nombre de personnes et retournera les
billets et le prix total de voyage.
59
Chapitre Ⅳ
Le scénario interne qui dirigera les interactions entre les services est le suivant : Le service WSAV va d’abord connecter à la fois les services WS-Hôtel et WS-VOL à travers ses méthodes
respectivement reserveCHam() et reserveVol().En suite et après assurer les réservations
présidents , elle va connecter au service WS-LV par la méthode reserveVoiture().En fin elle va
envoyer le prix de chaque service au service WS-Bank pour calculer le prix total et payer par sa
méthode payer( ) comme le montre le diagramme de séquence UML suivant .
Figure IV. 4: le diagramme de séquence de scénario d’agence de voyage
Le tableau IV.1 représente les différentes entrées et sorties de chaque méthode :
Tab IV. 1:tableau d’entrées/sorties de chaque service
méthode
reserveVol()
Entrées
types
Sorties
(Date_Départ ,
(date ,date ,string ,string ,in
(Code_Vol,
Date_Retour,
t)
prix)
Ville_Départ ,
Ville_Arrivé ,
Nb_Personne)
60
Type
(string, Prix)
Chapitre Ⅳ
(Date_Départ ,
reserveVoitur()
(date ,date )
(Id_voitur , prix) (string, Prix)
(date ,date ,string ,int)
(Num_Cham,
Date_Retour)
(Date_Départ ,
reserveChambre
Date_Retour,
()
Ville_Arrivé ,
(int,Prix)
prix)
Nb_Personne)
payer()
Liste_Prix
(Prix ,Prix ,Prix)
Prix_Total
Prix
Nous désirons créer un service composé appeler WS_AV pour organiser le voyage par
Internet. Le service prendra alors date départ, date retour, ville départ, ville arrivé et nombre
de personnes et retournera code billet et le prix total de voyage. Le scénario interne qui dirigera
les interactions entre les services est le suivant.
Le service va d’abord connecter à la fois les services WS-Vol et WS-Hôtel à travers
de ses méthodes respectivement reserveVol() pour réserver des billets d’avion et
reserveCham() pour réserver des chambres dans un hôtel. En suite et après assurer les
réservations précédentes, elle va connecter WS-Vol autre fois pour location de voitures par la
méthode reserveVoiture(). En fin elle va envoyer le prix de chaque service au service WSBank pour calculer le prix total et payer avec sa méthode payer(). La figure IV.5 décrit le
diagramme d’activité pour représenter ces interactions.
Figure IV. 5: le diagramme d’activité de scénario d’agence de voyage.
61
Chapitre Ⅳ
V.
Correspondance B /BPEL :
Ok<?xml version="1.0" encoding="ISO-8859-1"?>
<process name=" ReserveAV"xmi:version="2.0"xmlns="bpel20" >
<partnerLinks>
<partnerLink name="Actor" partnerLinkType="Actor"/>
<partnerLink name="ws2" partnerLinkType="Class"/>
</partnerLinks>
<sequence>
<receive partnerLink="Actor" operation="Make_Res()"/>
<if name="Transport choice" ordre="0">
<condition expressionLanguage="Aircraft price < 1000"/>
<invoke partnerLink="ws1" operation="Get_res(A,B,Date)"/>
<reply partnerLink="ws1" operation="Res_OK"/>
<elseif>
<condition expressionLanguage="Aircraft price > 1000 "/>
<invoke partnerLink="ws2" operation="Get_res(A,B,Date)"/>
</elseif>
</if>
<flow name =" Hotel & Car" >
<sequence>
<invoke partnerLink="ws3" operation="Get_res(Date)"/>
</sequence>
<sequence>
<invoke partnerLink="ws4" operation="Get_res(Date)"/>
</sequence>
</flow>
<reply partnerLink="Actor" operation="Res_OK"/>
</sequence>
</process>
62
MACHINE
ReserveAV
VARIABLES
nbplace ,Date_Départ , Date_Retour,
Ville_Départ , Ville_Arrivé ,
Nb_Personne,Num_Cham, prixAV,Id_voitur,
Liste_Prix,Prix_Total,Actor,ws2,ws4,ws3,ws1
INVARIANT
nbplace : {0..500} ,Nb_Personne : NAT
Ville_Départ ∈{Alger,Eloued}
Ville_Arrivé∈{Alger,Eloued}
prixAV = prixVOL + prixHOTEL + prixLV
(prixAV < 1000) ∧ ReserveVOL=TRUE ∧
ReserveHOTEL=TRUE ∧ ReserveLV=TRUE
INITIALISATION
nbplace := 100 prixAV < 1000
ANY
prix,ReserveAV,ReserveVOL,ReserveHOTEL,
ReserveLV WHERE
IF name="Transport choice" ordre="0"
THEN
PRE "prixAV < 1000"
IF "ws1":= "Get_res(A,B,Date)"
THEN
"ws1" := "Res_TRUE"
ELSE IF
PRE "prixAV > 1000 "
IF "ws2" := "GetRes(A,B,Date)"
THEN "ws2" := "Res_TRUE"
END IF ;
ELSE IF
IF name =" Hotel & Car"
IF "ws3":= "Get_res(Date)"
THEN
"ws3" := "Res_TRUE"
ELSE
PRE
"ws4":= "Get_res(Date)"
THEN
"ws4":= "Res_TRUE"
END;
"Actor" := "Res_TRUE"
reserver =
PRE nbplace > 0 & prix <1000
THEN
nbplace := nbplace - 1
END;
liberer =
PRE nbplace < 100
THEN nbplace := nbplace + 1
END;
reponse  disponibilite =
IF 0 < nbplace
THEN reponse:= TRUE
ELSE
reponse:= FALSE
END END END
reponse:: BOOL
// ou reponse:= bool(0 < n_rsrc)
END
END
Chapitre Ⅳ
VI.
Spécification formelle de notre exemple :
 Le schéma global de notre exemple de travail est la suivante :
Figure IV. 6: Le schéma global de la Machine d'agence de voyage ReserveAV
 La machine globale de réservation agence de voyage qui définit les opérations
élémentaires issues de l'agence de voyage et les règles principale pour vérifier les
services inclus, Cette machine est écrite en notation B Ascii :
Figure IV. 7: la Machine global d'agence de voyage ReserveAV
63
Chapitre Ⅳ
 Implimentation de la Machine ReserveAV
Figure IV. 8: l'implémentation la Machine global d'agence de voyage ReserveAV
 Machine ReserveVOL
La machine ReserveVOL qui définit les opérations élémentaires issues pour réservation d'une
place dans l'avion et les règles principale pour vérifier le service ReserveVOL, Cette machine
est écrite en notation B Ascii :
Figure IV. 9: la Machine ReserveVOL
64
Chapitre Ⅳ
 Machine ReserveHOTEL
La machine ReserveHOTEL qui définit les opérations élémentaires issues pour réservation
d'une chambre dans un hôtel et les règles principale pour vérifier le service ReserveCHam,
Cette machine est écrite en notation B Ascii :
Figure IV. 10: la Machine ReserveHOTEL
 Machine ReserveLV
La machine ReserveLV qui définit les opérations élémentaires issues pour réservation d'une
location dans une Park du voitures et les règles principale pour vérifier le service ReserveLV ,
Cette machine est écrite en notation B Ascii :
65
Chapitre Ⅳ
Figure IV. 11: la Machine ReserveLV
 Machine ReserveBANK
La machine ReserveBANK qui définit les opérations élémentaires issues pour payer dans une
Bank après la fin d'opération de réservations, Cette machine est écrite en notation B Ascii :
Figure IV. 12: la Machine ReserveBANK
66
Chapitre Ⅳ
VII.
Présentation de la preuve formelle de notre exemple :
L’activité de preuve formelle s’inscrit globalement dans l’activité de validation formelle
qui consiste à apporter l’assurance de la validité d’un théorème. La validation peut mettre en
œuvre différentes techniques, les deux principales sont la preuve formelle et le model checking.
La preuve formelle consiste à démontrer des théorèmes à l’aide d’un assistant à la preuve. Ces
outils permettent, pour certains, d’exécuter automatiquement des parties d’une preuve mais
surtout de valider la preuve faite par l’utilisateur de manière à ce qu’on ne prouve pas un
théorème de manière erronée.
Un assistant à la preuve est un outil auquel est associé un langage de description de théorèmes
et un langage de description de preuves (qui peut être le même ou pas).
Il existe un certain nombre d’assistants à la preuve qui ont été développés et qui sont utilisés
soit dans le monde académique, soit dans l’industrie. Ils peuvent mettre en œuvre des techniques
diverses.
La spécificité de la méthode formelle B est que les lemmes qui doivent être prouvés sont
produits par un outil (générateur d’obligation de preuve) dans un langage correspondant à la
logique du premier ordre associée à la théorie des ensembles.
Les outils de preuve utilisés dans le cadre de la méthode comprennent : une base de règles
d’inférence associée à un moteur contenant des heuristiques un prouveur de type SAT
À chaque étape du développement, des obligations de preuve sont imposées par la méthode B.
Une obligation de preuve est une propriété qui doit être satisfaite pour que le système construit
soit
correct.
Au niveau des machines abstraites, la preuve consiste à vérifier l'établissement et la
conservation de l'invariant :
1. l'initialisation U doit établir l'invariant I : [U] I
2. si
l'invariant I est
établi,
alors
toute
opération
de
la
forme PRE P THEN G END (substitution P | G) doit le garder établi, en vérifiant pour
cela le prédicat
Au niveau d'un raffinement, les obligations de preuve consistent à montrer que le modèle raffiné
est cohérent avec le modèle abstrait :
67
Chapitre Ⅳ
1. il s'agit d'abord de montrer que l'initialisation Ur du raffinement ne fait rien qui soit
contraire à l'initialisation U du composant abstrait : [Ur] ¬ [U] ¬ Ir
2. il s'agit ensuite de montrer que l'exécution d'une opération du raffinement qui établit
l'invariant correspond à une exécution de l'opération respective du niveau abstrait :
 Dans les figure suivante en va utiliser la preuve automatique jusqu'à obtenue un scénario
correct :
Figure IV. 13: les étapes de preuve
 En va contenue cette étape jusqu'à obtient un scénario correct et pratique.
68
Chapitre Ⅳ

Figure IV. 14: les étapes de preuve
VII.
Conclusion :
Nous avons proposé dans ce chapitre une étude de cas comme application de notre approche
proposée. Nous avons d’abord présenté un scenario de composition inspiré de la vie réelle. Le scenario
met en œuvre une collaboration entre plusieurs services Web distincts afin de faciliter la réservation et
le voyage via l'internet. Ensuite nous avons proposé un modèle pour la composition de ces services à
l’aide de diagramme d’activité. En fin, nous avons procédé la vérification de ce modèle avec notre
proposition et l’environnement B/BPEL
L'objectif de ce chapitre était principalement d'aider à la compréhension de notre approche à
travers l’étude d’un exemple simple mais concret. Cependant, il est important de noter que les
perspectives d’application de notre approche sont beaucoup plus vastes et concernent tous les domaines
dans lesquels la composition de services Web peut être envisagée.
69
Conclusion générale
En guise de conclusion, une approche formelle pour l’orchestration des services web
est proposée dans le cadre de notre travail de mastère. La composition de services est
principalement basée sur l'intégration des opérations c’est qu’on peut avoir comme des règles
mathématiques. Donc, notre approche se base principalement sur le paradigme formel.
Cette thèse décrit une approche formelle de développement de service web. Cette
approche est basée principalement sur la technique de raffinement B. Le processus de
raffinement décrit dans ce papier est dédié à la génération d’une implémentation relationnelle
à partir de spécifications formelles B qui traduisent les données et fonctionnalités d’un service
web décrite à l’aide de diagrammes UML. Nous avons défini un ensemble de règles qui permet
non seulement le raffinement des données mais aussi des opérations associées. En utilisant le
prouveur de l’Atelier B (version 4.1), l’ensemble des règles définies dans ce processus a été
prouvé (75% des preuves sont automatiques), donnant lieu à des scénarios de preuves
génériques et donc réutilisables par instanciation.
L’approche présentée dans cet article présente plusieurs avantages :

réduction du coût de développement : automatisation des phases de spécification et de
raffinement,

obtention d’une implémentation correcte et cohérente : les compositions web sont
spécifiées conjointement,

normalisation du code généré : les deux phases de traduction et de raffinement sont
dictées par des règles précises et déterministes. Cette normalisation de code offrira une
meilleure compréhension et maintenance du code ainsi produit.
Nous travaux actuels portent sur la vérification de l'orchestration formelle peut être
répétée itérativement jusqu’à l’obtention d’un scénario de composition correct et raffiné.
Nous travaillons aussi sur le processus de réutilisation des différentes preuves élémentaires
(chaque preuve élémentaire est associée à une règle de raffinement) lors de l’établissement de
preuves plus complexes associées à la composition de plusieurs règles de base.
70
Nous propositions ouvrent plusieurs perspectives scientifiques à court et à plus long
terme. Nous soulignons ici certaines de ces perspectives:
- La réalisation d’un outil de traduction automatique. Cet outil viendra compléter cet outil,
permettant la traduction automatique des diagrammes UML et en spécifications B.
- La réalisation d’un outil de raffinement automatique. Cet outil Viendra compléter cet outil, et
qui permettant la génération automatique des documents WSDL associés aux services
composés.
- Nous travaillons aussi sur les mêmes idées afin de les appliquer sur l’autre aspect
technologique des applications Web 2.0 qu’est AJAX.
71
Bibliographies
1. [ACT,12] :
active
endpoints.
activeBPEL
Jan
2012.
http://www.activevos.com/community-open-source.php.
2. [ABR,96] : J.R. Abrial, The B-Book, Combridge University Press, 1996.
3. [AIT,08] : A. Aît-Bachir, Archi Med, un canevas pour la détection et la résolution des
incompatibilités des conversations entre services web, thèse de doctorat, Université
Joseph Fourier-Grenoble 1, 2008.
4. [ARN ,05] : Arnaud VEZAIN, Les service web - présentation générale, rapport
technique, Association HERMES, Février 2005.
5. [CHE,10] : Chemame Chaouki, Implémentation d'une infrastructure collaborative
asynchrone basée sur les services web, Mémoire de Master, 2010.
6. [CHR,01] : E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, Web
Services
Description
Language
(WSDL)
1.1,
rapport
téchnique,W3C,
http://www.w3.org/TR/wsdl, 2001.
7. [CLE,03] : Clement L., Hately A., von Riegen C. et Rogers T., UDDI v.3.0.2, OASIS
Specification, http://uddi.org/pubs/uddi_v3, 2004.
8. [CYR,05] : Cyrielle.L, Florens.S, Sébastien.G, Rapport de TE, Université de NiceSophia
Antipolis, 2005.
9. [DAV,96] :Davies, Jim , Jim Woodcock. «Using Z », Prentice Hall, 1996.
10. [DUM ,10] : C. Dumez, Approche dirigée par les modèles pour la spécification, la
vérification formelle et la mise en œuvre de services Web composés, thèse de doctorat
Université de Technologie de Belfort-Montbéliard, 2010.
11. [FOU,03] : Fourmanoit, S. E, Merlo. R, Roy. « Introduction au langage Z Cours
LOG2000 -Eléments du génie logiciel», Ecole Polytechnique de Montréal 2003.
12. [GAR ,89] : Garavel, Hubert. « Introduction au langage LOTOS ». Verilog RhoneAlpes Centre d'Etudes Rhone-Alpes.1989
13. [GAR,96] : Gartner Group, Note de recherche, 1996.
14. [HUB,03] : K. Hubert , M. Valérie , LES WEB SERVICES, Edition DUNOD, 2003.
15. [HUR ,89] : Garavel, Hubert. « Compilation et vérification de programmes LOTOS».
Université Josef Fourier- Grenoble I. Pour obtenir le grade de DOCTEUR. novembre
1989.
16. [IBM,03] :IBM.
BPEL4WS
(version1.1),
http://www.ibm.com/developerworks/library/ws-bpel.
72
May
2003.
17. [IWS ,10] IBM.WS-Transactions,Fer2010.
http://www.ibm.com/developerworks/library/specification/ws-tx/.[22] Constantin
18. [JEA,09] : Jean DALAT, Introduction à WCF, Association Dotnet France, Janvier
2009.
19. [JON,93] : Jones, C.B., VDM une méthode rigoureuse pourle développement du
logiciel,Méthodologie du logiciel, Masson, 1993.
20. [LAN,96] : Lano K, The B Language and Method: A Guide to Practical Formal
Development FACIT. Springer-Verlag, ISBN3-540-76033-4.1996.
21. [LOP,08] : C. Lopez-velasco, Sélection et composition de services Web pour la
génération d’applications adaptées au contexte d’utilisation, thèse de doctorat,
université JOSEPH FOUR IER, 2008
22. [MAZ,01] :Mazouzi, Hamza. «Ingénierie des protocoles d’interaction : des systèmes
distribués aux systèmes Multi-agents» : thèse de docteur de l’université paris 9
Dauphine, octobre 2001.
23. [MIT,03] : Mitra N. et Lafon Y, SOAP Version 1.2 Part 0: Primer (Second Edition),
W3C, http://www.w3.org/TR/soap12-part0/, 2003.
24. [NER,06]: Nerea Arenaza, Composition semi-automatique de Services Web, Projet
de Master, Février 2006
25. [OAS,07] :OASIS Standard. WSBPEL Ver. 2.0, April 2007. http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html.
26. [ORA ,12] :
ORACLE.
Oracle
BPEL
Process
Manager.
http://www.oracle.com/technology/products/ias/bpel/index.html.
27. [OSI ,11] :
OASIS.
OASIS
Web
Services
Reliable
Messaging
,Nov2011.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm.
28. [POU,07] : Pourraz, Frederic. 2007. “Diapason: une Approche Formelle Et Centrée
Architecture Pour La Composition Évolutive Des Services Web”. SAVOIE.
29. [RAZ,07] : Razika DRIOUCHE, Proposition d’une architecture d’intégration des
applications d’entreprise basée sur l’interopérabilité sémantique de l’EbXML et la
mobilité des agents, thèse doctorat, 2007.
30. [SOF ,14] : Sofiane Chemaa, Une approche de composition de services Web à l’aide
des
Réseaux
de
Petri
orientés
objet , Thèse
de
Doctorat ,UNIVERSITÉ
ABDELHAMID MEHRI, CONSTANTINE 2 ,2014.
31. [SPI,98] : Spivey, John M. «The Z notation : a reference manual », Prentice Hall, 1998.
32. [SPV ,94] : Spivey, J.M., La notation Z, Méthodologie du logiciel, Masson, 1994.
73
33. [TOU,07] : Touzi, Jihed. 2007. “Aide à La Conception Des Systèmes D’information
Collaboratif Support De L’interopérabilité Des Entreprises”.
34. [VEZ,05] : A. VEZAIN, "LES SERVICES WEB – Présentation générale", Version
0.0.1, Association HE.R.M.E.S, Château du Montet, 2005.
35. [WAD,14] : W3C. WS-Addressing, Mar 2014. http://www.w3.org/Submission/wsaddressing/.
36. [WAE,11] : Wael SELLAM, Une approche formelle pour la vérification des propriétés
non fonctionnelles d'orchestration des services web, Mémoire de Master, 2010-2011.
37. [WPO,14] : W3C. WS-Policy, Mar 2014. http://www.w3.org/TR/2007/REC-wspolicy-20070904/.
38. [WSE,14]:W3C.WS-Security,Mar2014.
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss.
74

Une approche formelle pour la composition des services web

Transcription

Documents pareils

Master 2 MIAGE NTDP Nom : Le Prof ! UE « Web Services et SOA

スライド 1 - Language Grid

Comparatif des intergiciels présentés

IGR Contractuel Info UBFC Rectorat Dijon

Objectifs Plan de cours Pré-Requis

Les Services Web

Ressources Humaines Pôle Belge BELPARK S.A. Walibi Belgium

Services Web – UDDI

Web Services