UFR Informatique & LSR - ADELE

Mathématiques Appliquées

ECOLE DOCTORALE
MATHEMATIQUES, SCIENCES ET TECHNOLOGIES DE
L’INFORMATION, INFORMATIQUE

Master Mathématiques Informatique

2e année, Recherche
Spécialité Systèmes et Logiciels

ORCHESTRATION A HAUT NIVEAU ET BPEL

Projet présenté par :

Hernán Darío ROJAS
Soutenu le 21 juin 2006 à Grenoble (France)

Sous la direction de :
Jacky Estublier

Jury :

Mme Joële COUTAZ

M. Jean-François MÉHAUT
M. Rachid ECHAHED
M. Roland BALTER (Rapporteur)
M. Jacky ESTUBLIER (Directeur)

Effectué au laboratoire Logiciels, Systèmes et Réseaux

de l’Institut d’Informatique et de Mathématiques Appliquées de Grenoble
Au sein de l’équipe Adèle

1
 RESUME

Le besoin d’adaptation rapide des entreprises à de nouveaux contextes du marché offrant aux
clients de meilleurs services plus complets dans les plus courts délais, a créé des demandes
d'établir des plate-formes communes d'échange et de collaboration d'information. Les
services les plus utilisés dans ces plate-formes sont des services web. La coordination entre
ces services est décrite par l’orchestration de ces services.

Dans le contexte de ce travail de DEA, nous utilisons la spécification BPEL4WS (Business

Process Execution Language for Web Services) ou simplement BPEL pour exprimer cette
coordination. Pour cette spécification, il existe des implémentations qui exécutent des
procédés décrits dans ce langage. Mais nous trouvons que BPEL4WS est un langage de bas
niveau, proche des langages de programmation et il n'est pas facile de comprendre sans
connaître tous les détails du langage.

Nous proposons d’utiliser le langage APEL (Abstract Process Engine Language) pour
effectuer l’orchestration de services web, et d’offrir ainsi une couche d’abstraction à cette
coordination pour simplifier l’expression du procédé. Nous avons réalisé dans ce travail une
analyse établissant les conditions initiales pour pouvoir « traduire » les procédés décrits dans
le langage APEL vers des procédés décrits en BPEL4WS, en gardant la même sémantique.
Nous avons également implémenté un outil permettant d’effectuer des traductions de procédé
APEL vers des procédés décrits en BPEL4WS afin de les exécuter sur des moteurs de
procédés BPEL4WS.

Mots clés : Orchestration, BPEL4WS (ou BPEL), APEL et Services web

2
 TABLE DES MATIERES

1. INTRODUCTION ......................................................................................................... 7
1.1 Motivation................................................................................................................. 7
1.2 Contexte .................................................................................................................... 8
1.3 Organisation du Rapport ......................................................................................... 8
2. ETAT DE L’ART ........................................................................................................ 10
2.1 Les Procédés Logiciels .......................................................................................... 10
2.1.1 APEL................................................................................................................ 10
2.1.2 Mélusine ........................................................................................................... 12
2.2 Services Web et Orchestration ............................................................................. 15
2.2.1 Services Web.................................................................................................... 15
2.2.2. Orchestration et chorégraphie de services web ................................................ 18
2.2.3. Langages d’orchestration et chorégraphie de services web ............................. 20
3. CONTRIBUTION ....................................................................................................... 27
1.1 Introduction ............................................................................................................ 27
3.2 Comparaison d’appel d’un service web .............................................................. 28
3.2.1 Implémentation de l’appel en AXIS................................................................. 28
3.2.2 Implémentation de l’appel en BPEL ................................................................ 29
3.2.3 Implémentation de l’appel en APEL :.............................................................. 30
3.2.4 Comparaison des différentes méthodes :.......................................................... 31
3.3 Patrons de flux de contrôle des workflows en APEL et BPEL....................... 32
3.3.1 Séquence (sequence) ........................................................................................ 33
3.3.2 Parallélisme (parallel split)............................................................................... 34
3.3.3 Synchronisation (synchronization)................................................................... 36
3.3.4 Choix Exclusif (exclusive choice).................................................................... 37
3.3.5 Fusion simple (simple merge) .......................................................................... 38
3.3.6 Choix Multiple (multiple choice) ..................................................................... 39
3.3.7 Fusion Synchronisée (synchronizing merge) ................................................... 40
3.3.8 MI avec synchronisation (MI with synchronization) ....................................... 43
3.3.9 Choix Différé (deferred choice) ....................................................................... 46
3.3.10 Activité d’annulation (cancel activity) et Cas d’annulation (cancel case) ....... 47
3.4 Patrons de communication en APEL et BPEL ................................................... 50
3.4.1 Demande/Réponse (request/reply) ................................................................... 50
3.4.2 Unidirectionnel (one-way) ............................................................................... 51
3.4.3 Synchronous Polling ........................................................................................ 53
3.4.4 Message Passing............................................................................................... 55
3.4.5 Publication/Abonnement (publish/subscribe) .................................................. 56
3.4.6 Diffusion (broadcast)........................................................................................ 57
3.5 Modèle de données ................................................................................................ 58
3.5.1 Modèle de données d’APEL ............................................................................ 58
3.5.2 Modèle de données de BPEL ........................................................................... 59
3.6 Conditions au moment de transformer ................................................................ 62
3.6.1 Pour les activités en général. ............................................................................ 62
3.6.2 Pour les ports d’une activité. ............................................................................ 64
3.6.3 Pour les flots de données.................................................................................. 65
3.6.4 Pour les activités composites............................................................................ 66
3.6.5 Pour les produits............................................................................................... 67

3
4. REALISATION DES PROCEDES APEL EN BPEL ....................................... 71
4.1 Introduction ............................................................................................................ 71
4.2 Construction des wrappers pour des fichiers WSDL ........................................ 72
4.3 Sections générales du fichier BPEL .................................................................... 73
4.3.1 La section des attributs supérieurs ................................................................... 73
4.3.2 La section des partnerLinks.............................................................................. 73
4.3.3 La section des variables.................................................................................... 74
4.3.4 Synthèse et hypothèses..................................................................................... 74
4.4 Section d’orchestration du fichier BPEL ............................................................ 75
4.4.1 Le patron CallWebService ............................................................................... 76
4.4.2 Le patron While................................................................................................ 77
4.4.3 Le patron If....................................................................................................... 78
4.4.4 Le patron Sequence .......................................................................................... 80
4.4.5 Le patron Parallèle ........................................................................................... 80
4.5 Outil de transformation ......................................................................................... 81
4.5.1 Codification BPEL pour la section des éléments généraux ............................. 82
4.5.2 Codification BPEL pour la section d’orchestration ......................................... 83
5. CONCLUSION ET PERSPECTIVES ................................................................... 84
5.1 Conclusion .............................................................................................................. 84
5.2 Perspectives ............................................................................................................ 85
6. Bibliographie ................................................................................................................ 86

4
 TABLE DES ILLUSTRATIONS

Figure 1. Le meta-modèle de APEL V5................................................................................... 11

Figure 2. Exemple d’un procédé dans APEL ........................................................................... 12
Figure 3. Concept Univers commun - Mélusine ...................................................................... 13
Figure 4. Composition de domaines Mélusine......................................................................... 15
Figure 5. Structure d’un document WSDL .............................................................................. 16
Figure 6. Éléments de SOAP................................................................................................... 17
Figure 7. Schéma général de UDDI. ........................................................................................ 18
Figure 8. Vue globale de la chorégraphie ................................................................................ 19
Figure 9. Le Méta-Modèle de BPEL ........................................................................................ 24
Figure 10. Structure de fichier BPEL....................................................................................... 25
Figure 11. Exemple d’un procédé BPEL dans Orchestra......................................................... 26
Figure 12. Implémentation Java pour appeler un service web ................................................. 29
Figure 13. Codification BPEL pour faire l’appel à un service web ......................................... 29
Figure 14. Activité APEL pour le test appel à un service web ............................................... 30
Figure 15. Résultats des appels à service web. ........................................................................ 31
Figure 16 : Le patron de la séquence........................................................................................ 33
Figure 17 : exemple de la séquence en BPEL - représentation graphique et code BPEL
correspondant ................................................................................................................... 34
Figure 18 : L’expression de la séquence en APEL .................................................................. 34
Figure 19 : Le patron du Parallélisme ...................................................................................... 35
Figure 20 : L’expression du parallélisme en BPEL ................................................................. 35
Figure 21 : L’expression du parallélisme en BPEL - code BPEL correspondant .................... 35
Figure 22 : L’expression du parallélisme en APEL ................................................................. 36
Figure 23 : Le patron de la Synchronisation ............................................................................ 36
Figure 24 : Le patron de la Synchronisation en APEL ............................................................ 37
Figure 25 : Le patron de la Choix Exclusif .............................................................................. 37
Figure 26 : L’expression du Choix Exclusif en BPEL............................................................. 37
Figure 27 : L’expression du Choix Exclusif en APEL............................................................. 38
Figure 28 : Le patron de la Fusion simple................................................................................ 38
Figure 29 : L’expression de la Fusion Simple en APEL.......................................................... 39
Figure 30 : Le patron du Choix Multiple ................................................................................. 39
Figure 31 : L’expression du Choix Multiple en APEL ............................................................ 40
Figure 32 : Le patron du Fusion Synchronisée ........................................................................ 40
Figure 33 : L’expression du Fusion Synchronisée en BPEL ................................................... 41
Figure 34 : L’expression du Fusion Synchronisée en BPEL ................................................... 42
Figure 35 : L’expression du Fusion Synchronisée en APEL ................................................... 43
Figure 36 : Le patron du MI avec synchronisation .................................................................. 43
Figure 37 : exemple du MI avec synchronisation - représentation graphique ......................... 44
Figure 38 : exemple du MI avec synchronisation - code BPEL.............................................. 45
Figure 39 : L’expression du MI avec synchronisation en APEL ............................................ 45
Figure 40 : Le patron du Choix Différé.................................................................................... 46
Figure 41 : L’expression du Choix Différé en BPEL............................................................... 46
Figure 42 : exemple du Choix Différé - code BPEL............................................................... 46
Figure 43 : L’expression du Choix Différé en APEL .............................................................. 47
Figure 44 : Les patrons Activité d’annulation et Cas d’annulation.......................................... 47
Figure 45 : exemple du patron Activité d’annulation - représentation graphique BPEL et code
correspondant ................................................................................................................... 48

5
Figure 46 : exemple du patron Cas d’annulation - représentation graphique BPEL et code
correspondant ................................................................................................................... 49
Figure 47. Représentation du patron Demande/Réponse ......................................................... 51
Figure 48. Représentation du patron Unidirectionnel .............................................................. 51
Figure 49. Exemple du patron Demande/Réponse en BPEL - représentation graphique et
code BPEL correspondant................................................................................................ 52
Figure 50. Exemple de Unidirectionnel en BPEL - code BPEL correspondant ...................... 52
Figure 51. L’expression du Demande/Réponse en APEL........................................................ 53
Figure 52. Représentation du patron Synchronous Polling...................................................... 53
Figure 53. Exemple de Synchronous Polling en BPEL ........................................................... 54
Figure 54. Exemple de Synchronous Polling en BPEL - code BPEL correspondant ............. 55
Figure 55. L’expression du Synchronous Polling en APEL .................................................... 55
Figure 56. Représentation du patron Message Passing ............................................................ 56
Figure 57. Code BPEL correspondant au patron Message Passing ........................................ 56
Figure 58. Représentation du patron Publication/Abonnement ............................................... 57
Figure 59. Représentation du patron Diffusion........................................................................ 57
Figure 60. Utilisation des produits APEL avec éléments versionables. .................................. 59
Figure 61. Activité et codification BPEL pour le type scope................................................... 60
Figure 62. Activité et codification BPEL pour le type assign. ................................................ 60
Figure 63. Exemple d’affectation dans BPEL.......................................................................... 61
Figure 64. Exemples des scénarios possibles dans APEL. ...................................................... 63
Figure 65. Exemples des scénarios possibles dans BPEL........................................................ 63
Figure 66. Exemples des ports dans activités APEL................................................................ 64
Figure 67. Exemples des flots de données sur des activités APEL......................................... 65
Figure 68. Activité composite dans APEL.............................................................................. 67
Figure 69. Produits d’une activité APEL ................................................................................. 68
Figure 70. Exemple pour variables BPEL locales et globales ................................................. 68
Figure 71. Relation entre les Modèles d’Activités et de Produits et les fichiers WSDL ......... 75
Figure 72. Représentation APEL pour l’appel à services web................................................. 76
Figure 73. Représentation APEL pour le type While............................................................... 77
Figure 74. Représentation APEL pour le type If...................................................................... 79
Figure 75. Représentation APEL pour le patron Sequence...................................................... 80
Figure 76. Représentation APEL pour le type Parallèle .......................................................... 81
Figure 77. Schéma de transformation APEL – BPEL Section des éléments généraux .......... 82
Figure 78. Schéma de transformation APEL – BPEL Section des éléments d’orchestration . 83

6
 1. INTRODUCTION
1.1 Motivation
Le besoin d’adaptation rapide des entreprises à de nouveaux contextes du marché offrant aux
clients de meilleurs services plus complets dans les plus courts délais, a créé des demandes
d'établir des plates-formes communes d'échange et de collaboration d'information ;
l'utilisation de l'architecture orientée services (Service-Oriented Architecture) facilite la
construction de ces plate-formes.

Dans le contexte de cette architecture :

- Un service est une unité de travail faite par un fournisseur pour atteindre les
résultats finaux souhaités par un consommateur du service ;
- Les services présentent une forte cohérence interne et des couplages externes
légers.
- Les services sont des modules autonomes et réutilisables indépendantes de leurs
utilisations et des plates-formes sur lesquelles ils fonctionnent.

Les services les plus utilisés dans ces plate-formes sont des services web. Les services web
ont gagné beaucoup d’importance dans le développement des logiciels grâce à leur
indépendance par rapport aux langages de programmation et parce qu’ils permettent d’être
réutilisables pour fournir des services plus élaborés.

Pour réaliser une application basée sur les services web, il nous faut un canevas pré-défini
permettant de décrire la coordination des services. Ce canevas s’appèle l’Orchestration.
L’Orchestration décrit un modèle de coordination de services qui sera exécuté à l’aide d’un
Moteur d'Orchestration.

L’Orchestration est représentée par un workflow (flux de travail) coordonnant des services (et
plus particulièrement des services web), ce qui offre des avantages comme l’optimisation et
l’automatisation de tâches. Un workflow modélise la gestion informatique de l'ensemble des
tâches à accomplir par les différents acteurs impliqués dans la réalisation d'un procédé métier.
Ces acteurs peuvent être des humains réalisant les tâches demandées, ou des services (services
web, applications locales ou distantes, COTS…). Le workflow se charge de l’administration
ou le contrôle de la coordination de ces acteurs et services.

Dans le contexte de ce travail de DEA, nous utilisons l’orchestration pour définir la

coordination des tâches dans les procédés. Pour cela, nous avons étudié plusieurs langages
d’orchestration, le plus utilisé de ces langages est BPEL4WS (Business Process Execution
Language for Web Services). BPEL4WS, ou simplement BPEL définit la coordination de
services web pour atteindre un objectif métier. Plusieurs implémentations industrielles ont été
réalisées pour offrir un moteur d’exécution de procédés décrits en BPEL4WS, parmi ces
implémentations Oracle BPEL et BSOA Orchestra.

Néanmoins, le langage BPEL4WS est un langage de bas niveau, proche des langages de
programmation. Ceci a plusieurs inconvénients :

- Il n'est pas facile de comprendre un modèle d’orchestration de services web décrit

en BPEL4WS sans connaître tous les détails de ce langage. Une connaissance
préalable des structures utilisées dans BPEL4WS est nécessaire pour comprendre
le modèle ;

7
 - Ce n'est pas un langage de haut niveau, dans lequel nous pouvons exprimer le
procédé en terme des tâches à accomplir et la coordination entre ces tâches. Au
contraire, c’est un langage de bas niveau qui ressemble à un langage de
programmation, et dans lequel il y a beaucoup de petits détail de programmation
qui surchargent et encombrent le modèle de procédé

L’idéal à notre avis serait d’utiliser un langage de haut niveau pour exprimer l’orchestration
de manière simple et compréhensible, et d’exécuter par la suite cette orchestration à l’aide
d’un moteur BPEL4WS comme Oracle BPEL ou BSOA Orchestra qui sont des
implémentation ayant faites leurs preuves.

1.2 Contexte

Notre proposition est d'utiliser notre langage APEL (Abstract Process Engine Language) pour
décrire l’orchestration de services web et d’offrir ainsi une couche d’abstraction à cette
coordination. APEL est un langage de modélisation de procédés logiciels centré activités,
développé au sein de notre équipe ADELE. APEL effectue non seulement des modélisations
de procédés, mais va plus loin, il fournit un formalisme de haut niveau d'abstraction qui peut
être utilisé dans des contextes différents et n’est pas spécialisé pour un domaine particulier.

Parmi les avantages d’APEL par rapport à BPEL4WS : APEL offre une facilité de
compréhension et une séparation de la complexité en utilisant des concepts comme les
activités composées. Dans le cadre de ce travail de DEA, nous effectuons une analyse
comparative de ces deux langages, afin de produire un outil qui permet de transformer un
processus décrit dans le formalisme APEL vers BPEL4WS en gardant une sémantique
équivalente.

Pour cela notre étude présente des comparaisons effectuées en utilisant des patrons. Un patron
est une solution à un problème récurrent. Les patrons pris en considération dans cette étude
sont les patrons de contrôle de flux des workflows et les patrons de communication. En
analysant la manière dans laquelle chaque langage peut mettre en oeuvre ces patrons, nous
avons établi les relations entre ces langages et nous avons identifié les patrons que nous
pouvons exprimer en APEL et qui seront facilement traduisibles en BPEL4WS.

1.3 Organisation du Rapport

Ce document est organisé en 5 chapitres. Le chapitre 2 présente un état de l’art sur les
procédés logiciels et sur l’orchestration et les services web . Ce chapitre débute par une
présentation sur les procédés logiciels, nous y décrivons plus particulièrement le langage de
procédé APEL et la plate-forme Mélusine que nous avons choisis et utilisé dans ce travail
pour réaliser notre proposition. APEL est langage de procédé de haut niveau, et plate-forme
Mélusine est une plate-forme permettant de construire des applications suivant une
architecture particulière et très avantageuse. Nous présentons par la suite dans ce chapitre une
étude sur les services web, l’orchestration et les langages d’orchestration et de chorégraphie
des services web.

8
Dans le chapitre 3 nous présentons l’analyse comparative de APEL et BPEL4WS que nous
avons effectuée dans ce travail. L’objective de cette l’analyse comparative est d’identifier les
conditions initiales que doivent suivre les procédés décrits en APEL pour pouvoir les
transformer vers des procédés en BPEL4WS.

Le chapitre 4 présente la réalisation de cette transformation de procédés APEL en BPEL4WS.

Ce chapitre décrit comment notre outil de transformation peut générer la codification requise
pour le formalisme BPEL4WS avec l'aide des patrons de représentation identifiés dans la
comparaison du chapitre 3.

Enfin, le chapitre 5 conclut ce rapport. Nous y présentons les conclusions et nous donnons
quelques perspectives de ce travail autour de l’orchestration des services web.

9
 2. ETAT DE L’ART

Notre objective est la définition des conditions pour réaliser une première approximation de
transformation entre les procédés APEL vers procédés dans le formalisme BPEL4WS. Par
conséquence, nous étudions, en premier lieu, les procédés logiciels en utilisant nos outils
APEL et Mélusine. Ensuite, nous faisons un étude sur des services web et orchestration avec
l’objectif de connaître le cadre de définition du langage BPEL4WS.

2.1 Les Procédés Logiciels

Dans cette section, nous allons présenter nos outils APEL et Mélusine.

2.1.1 APEL

APEL (en anglais, Abstract Process Engine Language) est un langage de modélisation des
procédés logiciels (PML) centré activités. APEL est un logiciel développé au sein de l’équipe
ADELE. Le travail autour d’APEL a commencé vers l’année 1988, dans l’objectif de fournir
un environnement de support complet pour la gestion des procédés logiciels. Actuellement, le
logiciel. Cinq versions de ce logiciel se sont succédées.

Un peu de histoire

Dans la première version, APEL V1 (ou WEADELE), l’implémentation était complètement

basée sur ADELE (il permet de modéliser des procédés de gestion de configuration [BE 87].).
Le procédé était complètement traduit en terme de triggers, implémentant un système ECA
(événement/condition/action). A partir de la deuxième version, l’objectif fut de construire un
formalisme de haut niveau pour cacher les triggers. Cette deuxième version d’APEL a utilisé
ADELE et Process Weaver. Le modèle de procédé décrit en APEL est compilé vers un
moteur de procédé abstrait, construit à partir de deux moteurs de procédé basiques : ADELE
et Process Weaver. L’assemblage des ces deux moteur s’étant révélé problématique, APEL
V3 s’est alors focalisé sur la définition d’un formalisme de haut niveau exécuté par un moteur
unique.

La quatrième version, APEL V4, forme un environnement de support des procédés logiciels
très riche en concepts, il contient un formalisme graphique de haut niveau pour modéliser les
procédés, un système d’exécution de procédés de haut niveau, et un support à l'évolution
dynamique de ces procédés logiciels.

La version actuelle

La version APEL V5 [Vil 03, Le 04], qui a un noyau minimal, ne contenant que les concepts
principaux, formant les éléments de base : les activités, les produits, leur types, les rôles, les
ressources, les flots de données, et les ports. La Figure 1 illustre le méta modèle d’APEL V5.
[SAN 05].

APEL a une sémantique basée sur des graphes dirigés, c'est-à-dire qu’un procédé dans le
domaine d’APEL est représenté à travers des nœuds et des liens. Un nœud est une activité qui
sera exécutée, tandis qu’un lien représente, cependant l’exécution des procédés, le flux de
contrôle et de données qui lie les activités.

10
 Figure 1. Le meta-modèle de APEL V5

Un procédé décrit dans le langage APEL a donc 7 éléments qui sont présentés dan la Figure 1.
Ensuite, nous allons présenter chaque un des éléments.

Les activités
Une activité dans le domaine d’APEL est considérée comme une étape du procédé au cours de
laquelle une action est exécutée. Une activité peut avoir un ou plusieurs ports (Figure 1)
d’entrée et de sortie, et peut être de type composé ou simple. L’activité est de type composé
quand elle contient autre activité imbriquée. Chaque activité a dans l’intérieur, un port
nommé desktop dans lequel les produits sont crées, modifiés et consommés. La
communication entre le desktop et les ports est réalisée par flot de données.

Les produits et les types des produits

Un produit est une information quelconque qui est produite, transformée et consommée par
une activité [VIL 04]. APEL gère les différentes versions de produits, pendant l’exécution du
procédé. Chaque produit fait référence à un type de produit dans un modèle du produit, ce
modèle défini la structure du produit qu’il contient.

Les rôles et les ressources

Un rôle est une qualification associée à une ou plusieurs personnes. Une activité généralement
a un à un responsable (une ressource) qui joue un rôle. Les ressources correspondent aux
différents participants de l’activité dans le procédé et ils sont spécifiés dans un autre modèle,
le modèle des ressources.

Les flots de données et de contrôle

Un flot de données se charge de transmettre le contrôle et ainsi que les produits entre les
différents ports des activités. Un flot de données est lié à un port de sortie d’une activité
d’une part et à un port d’entrée d’une autre activité dans l’une autre part.

Les ports
Les ports sont des interfaces de l'activité, ils définissent et contrôlent la communication entre
l'activité et le monde extérieur, c’est le point d’entrée et de sortie d’une activité. On peut le
voir aussi comme un point de liaison entre l’activité et le flot de données. Il existe deux types
de ports : les ports synchrones et les ports asynchrones. Un port d’entrée ou de sortie peut
attendre un ou plusieurs produits.

11
La Figure 2 illustre un procédé contenant avec les éléments définis ce dessus. Cet exemple
contient quatre activités: OrderTrip, ReserveTickets, BookTickets, ReceiveConfirmation ; la
localisation du port desktop ; les ports synchrones et asynchrones ; les flots des données et les
responsables pour chaque une des activités.
Port desktop

Flots des données

Activités Ports Synchrones

Role
Ports Asynchrones

Figure 2. Exemple d’un procédé dans APEL

La Figure 2 présente l’éditeur graphique. Dans cette figure, un modèle de procédé est
construit, à l’aide de cet éditeur, conformément au méta-modèle d’APEL.

Chaque activité d’APEL a des états. Le moteur APEL, intégré dans Mélusine (qui sera
présenté dans la section suivante), se charge de l’exécution du procédé. Il gère les transitions
d’états des activités de cette instance. Le

État Description
INIT L’activité est à l’état initial (démarrage du procédé).
READY L’activité est prête à recevoir un responsable, afin de démarrer.
ACTIVE Un responsable a été affecté à l’activité, et celle-ci a démarré.
TERMINATED L’activité est terminée.
ABORTED L’activité a été interrompue.
SUSPENDED L’activité est suspendue

Tableau 1. États d’une activité APEL

2.1.2 Mélusine

Mélusine est un environnement de conception, d’implémentation et d’exécution de logiciels

diriges par procédés, basés sur une architecture logicielle particulière qu’on appelle une
fédération. La conception de logiciels à l’aide de Mélusine se fait en deux étapes : la
première étape consiste à construire la Machine Virtuelle du Domaine d’Applications, la
deuxième étape consiste à construire l’Application du Domaine à l’aide de cette Machine
Virtuelle. [SAN 05].

12
Dans le contexte de Mélusine, une fédération est une architecture logicielle qui matérialise la
coordination et qui permet de structurer les applications comme un ensemble de mondes qui
coopèrent pour atteindre un but commun.

La Machine Virtuelle du Domaine d’Applications est un moteur permettant d’exécuter les

modèles d’applications construits conformément au méta-modèle du domaine d’applications.
Dans le contexte de ce travail de DEA e domaine d’applications est le domaine de procédé.
La Machine Virtuelle du Domaine d’Applications est donc le moteur APEL construit
conformément au méta modèle APEL.

Après avoir défini le méta-modèle du domaine d’applications, et construit, conformément à ce

méta-modèle, la Machine Virtuelle de ce domaine d’applications, la deuxième étape de
conception du logiciel à l’aide de la plate-forme Mélusine consiste à construire l’Application
du Domaine. L’architecture des applications conçues à l’aide de Mélusine est composée de
trois couches principales : la couche conceptuelle, la couche médiateur, et la couche outils.

La couche Conceptuelle
Contient le modèle métier décrivant la logique de ce logiciel. Ce modèle est défini
conformément au méta-modèle du domaine métier de ce logiciel. Au moment de l’exécution,
une instance du modèle que on a défini s’exécutera dans la couche conceptuelle du logiciel, à
l’aide de la Machine Virtuelle que nous avons spécifiée.

La couche Médiateur
Elle permet de faire le lien, de façon plus flexible, entre les concepts du modèle métier et leurs
implémentations en terme d’outils réalisant ces concepts. Ainsi les outils participants au
logiciel s’exécutent de manières coordonnées suivant la logique décrite dans le modèle métier.

La couche Outils
Représente les outils qui implémentent les fonctionnalités offertes par des services de la
couche médiateur. Chaque service est lié à un outil.

Au début de travaux dans le domaine de Fédération, au sein de l’équipe ADELE, la couche

conceptuelle était appelée l'Univers Commun. Ce dernier était défini comme étant “la
réification des relations entre les composants de domaines distincts” [VIL 03].

L'Univers Commun a été utilisé pour définir les concepts communs entre deux (ou plusieurs)
applications que nous souhaitons faire coopérer pour atteindre un but commun [SAN 05]. La
Figure 3 présente les relations des concepts.

l'Univers Commun
concepts communs
aux deux applications

Application 1 Application 2

Figure 3. Concept Univers commun - Mélusine

13
Actuellement la couche conceptuelle a évoluée en prenant une place plus importante. A
présent, cette couche n’est plus utilisée pour contenir uniquement les concepts communs,
mais elle est utilisée pour contenir les concepts métier décrivant la logique du logiciel global.
La couche conceptuelle contient donc le modèle métier décrivant la logique du logiciel que
nous souhaitons concevoir. Ce modèle est construit conformément au méta-modèle du
domaine de ce logiciel que nous avons défini.

Au moment de l’exécution, une instance du modèle défini s’exécutera dans la couche

conceptuelle du logiciel, à l’aide de la Machine Virtuelle que on a construit. Cette instance
coordonnera l’exécution des outils participants au logiciel suivant la logique que nous avons
spécifiée dans le modèle métier.

La couche médiateur contient deux sous-couches : les adaptateurs, et les services. Les
adaptateurs se chargent de faire le lien entre les concepts du modèle du logiciel, contenu dans
la couche conceptuelle et les services de la couche médiateur décrivant les outils participants.
La sous-couche services est un outil abstrait offrant un certain nombre de fonctionnalités, il
peut être vu comme la description d’un outil requis par le logiciel.

Actuellement, la plate-forme Mélusine permet d’intégrer certaines catégories dans la couche

des outils

Les outils distants : lorsque l’outil est distant, cette liaison entre l’outil et le service est faite à
travers un proxy et un wrapper qui se chargent d’adapter les fonctionnalités offertes par l’outil
aux fonctionnalités demandées par le service. La communication entre le proxy et le wrapper
est géré par la plate-forme Mélusine. Ainsi, le concepteur du logiciel n’a pas à gérer cette
communication ;

Les outils locaux : quand l’outil est local, et fait sur mesure, il n’a pas besoin d’intermédiaire
pour adapter ses fonctionnalités à celles demandées par le service.

L’avantage d’utiliser des adaptateurs est qu’on peut employer le même service dans plusieurs
adaptateurs, et qu’on peut modifier l’adaptateur facilement pour avoir une exécution
différente.

Mélusine permet de concevoir et d’exécuter des systèmes coordonnant plusieurs types

d’outils. C’est la différence entre Mélusine et les autres systèmes, comme les systèmes
d’orchestration, se limitant pour la plupart d’entre eux à la coordination de services web.

Mélusine permet la composition des domaines. Dans le cadre de la Figure 4 illustre

l’existence de deux domaines : le domaine des activités et le domaine des produits qui sont
composés intégrés au moment de l’exécution d’un procédé APEL, dans le domaine procède.

14
 Domain de la
composition

Domain des Domain des

activités produits

Figure 4. Composition de domaines Mélusine

Le domaine d’activités a l’outil APEL Editor, qui est l’éditeur graphique permettant de
réaliser graphiquement des modèles de activité dans le langage APEL. Pour le domaine de
Produits, est l’outil Product Domain Editor qui permet de créer et éditer les types de produits.
On construit le modèle d’activité (domaine d’activité) sans connaître la structure du produits.
Au moment de l’exécution, dans le domaine compuesto procède se fait la liaison entre les
noms des produits en le domaine activité et sa représentation dans le domaine produit. .

2.2 Services Web et Orchestration

Dans cette section nous allons présenter un étude sur services web, orchestration et
chorégraphie et les langages pour représenter ces concepts.

2.2.1 Services Web

Les services web sont des applications auto descriptives, modulaires et faiblement couplées
qui fournissent un modèle simple de programmation et de déploiement d’applications, basé
sur des normes s’exécutant à travers l’infrastructure web1. Ils sont définis par un ensemble de
standards qui permettent de décrire des interfaces logicielles et d’accéder aux fonctions
correspondantes sur un réseau utilisant des messages XML.

Des motivations pour conduire à la création des services web ont été variées, parmi ces
motivations : l’intégration d’applications « à gros grain » et la définition d’une unité
d’intégration (le service). L’apport principal des services web est la solution au problème
d’hétérogénéité par rapport aux plates-formes et langages des applications.

Les éléments qui constituent la mise en œuvre d’un service web sont :

• La description du service.
• Le protocole d’accès.
• L’annuaire des services.

1
Extrait de [KMV 03] Chapitre 1 : Introduction – 1.1 Caractéristiques techniques des services web

15
Description du Service

Le langage utilisé pour décrire un service web est le WSDL2 (en anglais, Web Services
Description Language) qui est la notation standard basée sur XML pour construire la
description de l’interface d’un service. Cette spécification définit une grammaire XML pour
décrire les services web comme des ensembles de points finaux de communication (ports) à
travers lesquels on effectue l’échange de messages. La description de ces messages et ces
opérations est faite d’une manière abstraite.

La structure d’un fichier WSDL est présentée ci-dessous (Figure 5).

Partie abstraite

<Types>

<Messages>

<Ports>

Partie concrète

<Binding>

<Service>

Figure 5. Structure d’un document WSDL

Un fichier WSDL contient donc 5 éléments.

Les <types> : fournissent la définition de type de données utilisées pour décrire les messages
échangés.

Les <messages> : représente une définition abstraite (noms et types) des données en cours de
transmission.

Les <portTypes> : décrit un ensemble d’opérations abstraites. Chaque opération a zéro ou un

message en entrée ; zéro ou plusieurs messages de sortie ou de fautes.

Le <binding> : Spécifie une liaison entre un <portType> et a un protocole concret (SOAP,

HTTP, MIME)3.

Le <service> : contient agréger un ensemble de ports. Chacun de ces ports a un type

<portType>

Protocole d’accès

Pour accéder aux services web l’architecture est basée sur le protocole SOAP (en anglais,
Simple Object Access Protocol). Le protocole SOAP est un standard qui permet la
communication entre applications pour l’accès aux services web. Il permet la normalisation
2
Plus d’informations dans [WSDL 01]
3
Plus d’informations dans [SOAP], [HTTP], [MIME] respectivement.

16
des échanges de données (décrits en XML) et les transferts de données en utilisant des
protocoles au niveau application (HTTP, FTP, SMTP).

Les éléments de SOAP sont présentés dans la Figure 6. [KRA 06]

Enveloppe (obligatoire)

En-tête (facultatif)

Corps (obligatoire)

Erreurs
(facultatif)

Figure 6. Éléments de SOAP

• Enveloppe (envelope): contient la spécification des espaces de désignation (namespace),

du codage de données (version du schéma XML-SOAP supporté), etc.

• En-tête (header): contient une signature pour la sécurité et des informations de

facturations. L’en-tête est utile surtout, quand le message doit être traité par plusieurs
intermédiaires.

• Corps (body): contient les éléments principaux du service : les méthodes et les paramètres
qui seront exécutés par le destinataire final.

• Erreurs (fault): réactions en cas d’erreur (ayant des causes différentes).

Un message SOAP voyage du SOAP sender au SOAP receiver, en passant par un groupe de
SOAP intermédiaires, définit comme une entité qui est capable de recevoir et transmettre les
messages SOAP. Les nœuds intermédiaires aussi bien que le SOAP receiver sont identifiés
par un URI (Uniform Resource Identifier).

Le protocole SOAP permet d’invoquer un objet distant en transmettant via HTTP les
informations nécessaires à l’appel (nom de la méthode et sa signature) dans un message au
format XML. La réponse à la demande est aussi renvoyée au format XML.

Après la mise en forme de la demande SOAP, elle est envoyée au serveur web. Le parseur
XML du serveur vérifie la cohérence du message avant de le transmettre sur http. De même,
le parseur XML du serveur destinataire vérifie la cohérence du message reçu et le refuse s’il
n’est pas valide. [KMV 03]

Annuaire des services

L’annuaire de services correspond au lieu où les services web sont enregistrés. L’architecture
utilise le standard UDDI4 (en anglais, Universal Description, Discovery and Integration) qui
représente le protocole pour l’enregistrement et la découverte des services web. Il est une

4
Plus d’informations dans [UDDI].

17
spécification basée sur des technologies standard afin de faciliter la collaboration entre
partenaires dans le cadre des échanges commerciaux. [KMV 03]

UDDI fonctionne à partir de pages :

• Blanches : informations sur les fournisseurs de services (par nom)

• Jaunes : informations sur les fournisseurs de services (par catégorie)
• Vertes (spécificité de UDDI) : définition des services fournis en WSDL.

Les entreprises publient les descriptions de leurs services web en UDDI, sous la forme de
fichiers WSDL. Ainsi, les clients peuvent plus facilement rechercher les services web dont ils
ont besoin en interrogeant le registre UDDI.

Lorsqu’un client trouve dans UDDI une description de service web qui lui convient, il
télécharge son fichier WSDL depuis le registre UDDI. Ensuite, à partir des informations
inscrites dans le fichier WSDL, notamment la référence vers le service web, le client peut
invoquer le service web et lui demander d’exécuter certaines de ses fonctionnalités.

La Figure 7 présente le schéma général du protocole UDDI. L’entreprise B a publié le service

web S et l’entreprise A est client de ce service.

Annuaire
UDDI

(2) Recherche des services: (1) Publication des services:

demande SOAP enregistrement des documents WSDL

(3) Téléchargement
des documents WSDL
Entreprise B
Entreprise A

(4) Demande SOAP

conforme au WSDL

(5)Réponse SOAP
conforme au WSDL

Figure 7. Schéma général de UDDI.

2.2.2. Orchestration et chorégraphie de services web

Dans l’industrie les termes workflow et document management systems sont utilisés pour
décrire comment les composants sont connectés pour construire des procédés métiers
complexes. Ils décrivent l’enchaînement du travail entre plusieurs logiciels d’une
organisation. Ces logiciels peuvent inclure des applications partenaires (legacy systems) des
logiciels locaux ou distants construits dans différentes technologies et même des personnes
devant réaliser certaines tâches.

Avec l’introduction des services web des termes tels que “web services composition” ou “web
services flow” [PEL 03] ont été utilisés pour décrire la composition de services web dans un
flux de procédé. Cela a relancé les travaux de recherche sur les problèmes d’interopérabilité
et coordination de services web. La solution proposée par la plupart de ces travaux consiste à
modéliser le logiciel par un procédé. Ce procédé gère la coordination des tâches et des

18
opérations de ce logiciel. Ces travaux de recherche autour de la coordination de services web
ont donné naissance à deux nouveaux termes : la Chorégraphie et l’Orchestration des services
web

Nous allons présenter dans cette section la définition de ces termes. Nous allons surtout nous
concentrer sur l’orchestration qui est la base de ce travail de recherche.

Chorégraphie

La chorégraphie modélise la séquence des échanges de messages entre services web et

conditions dans lesquelles ces messages sont échangés entre des clients, des fournisseurs et
des partenaires. La chorégraphie est typiquement associé à l’échange de messages publics
entre les services web, alors qu’un procédé métier est exécuté de manière centralisé.

Client Expédition

Fournisseur Fabricant

Figure 8. Vue globale de la chorégraphie

La Figure 8 présente une vue générale de la chorégraphie. Cet exemple illustre l'échange de
messages entre 4 partenaires : Client, Expédition, Fournisseur et Fabricant, ces partenaires
sont des services web.

Dans les travaux récents sur la chorégraphie, nous trouvons le langage WS-CDL (Web
Services Choreography Description Language) qui est un langage basé sur XML pour décrire
les collaborations pair à pair entre les participants et l’échange de messages entre ces
participants dans l’objectif d’accomplir un but commun dans la logique métier. 5

Orchestration

L’orchestration de services permet de définir l’enchaînement des services selon un canevas

prédéfini, et de les exécuter à travers des "scripts d’orchestration". Ces scripts sont souvent
représentés par des procédés métier ou des workflows inter/intra-entreprise. Ils décrivent les
interactions entre applications en identifiant les messages et en branchant la logique et les
séquences d’invocation [SAN 05].

L’orchestration décrit la manière dans laquelle les services web peuvent interagir ensemble au
niveau des messages, incluant la logique métier et l’ordre d’exécution des interactions. Ces
interactions peuvent couvrir des applications et/ou des organisations, et le résultat peut être un
modèle de procédé de longue durée, transactionnel, et multi-étapes. [PEL 03].

Une différence importante entre l’orchestration et la chorégraphie est que l’orchestration offre
une vision centralisée, c'est-à-dire que le procédé est toujours contrôle de la perspective d’un

5
Web Services Choreography Description Language Version 1.0 - http://www.w3.org/TR/2005/CR-ws-cdl-10-
20051109/

19
des partenaires métier. En revanche, la chorégraphie offre une vision globale et plus
collaborative de la coordination. Elle décrit le rôle qui joue chaque participant impliqué dans
l’application.

Un des langages pour représenter l’orchestration est BPEL4WS (Business Process Execution
Language For Web Services) duquel on parlera dans la section suivante.

2.2.3. Langages d’orchestration et chorégraphie de services web

Dans cette section nous allons présenter les langages suivants pour la coordination des
services web :

• WSCI: Web Services Choreography Interface.

• BPML: Business Process Modeling Language.
• WSCL: Web Services Conversation Language.
• BPEL4WS: Business Process Execution Language for Web services.

Ce travail de DEA utilise surtout le langage BPEL4WS. Pour cela, nous allons présenter plus
en détail les aspects principaux du BPEL4WS.

WSCI
WSCI 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 . WSCI décrit l’interface dynamique du service web participant
à un échange donné de message. Il décrit cette interface dynamique en réutilisant les
opérations définies dans l’interface statique.

La spécification a été proposée par Sun, SAP, BEA, et Intalio. WSCI offre une vision de la
collaboration, qui prend une forme de conversation entre plusieurs services web. La
collaboration se passe d’une manière décentralisée, sans utiliser un procédé principal, mais
plutôt plusieurs procédés distribués.

WSCI s’ajoute à WSDL et SOAP (standards sur lequel les services web sont construits), pour
donner description des types des messages, de leur ordre ainsi que de quelques autres attributs
afin de permettre aux applications d'agir e collaboration avec succès.

Nous présentons à dessous des caractéristiques des interfaces de chorégraphie en

WSCI: [WSC 02].

• Chorégraphie des messages : une interface de WSCI décrit l'ordre dans lequel des
messages peuvent être envoyés ou reçus dans un échange donné.

• Frontières et compensation de transaction : une interface de WSCI décrit les

opérations déployé de manière transactionnelle. Cette information est importante pour
les autres participants.

• Gestion de threads : l’interface WSCI décrit comment le service web contrôle les
conversations multiples avec le même partenaire ou avec différents partenaires.

20
 • Connecteurs: WSCI permet de tracer la consommation des opérations d'un service
web pour produire des opérations à partir d'un autre service web afin d'établir
clairement un modèle de l'échange global.

• Participation dynamique : l’interface de WSCI décrit comment l'identité du service

cible (target web service) est choisie dynamiquement.

BPML
BPML est un métalangage qui a été développé par l’organisation BPMI.org (Business Process
Management Initiative), une organisation indépendante comprenant Intalio, Sterling
Commerce, Sun, CSC, et d’autres.

Un processus métier BPML est un enchaînement d’activités simples, d’activités complexes et

de processus incluant une interaction entre participants dans le but de réaliser un objectif
métier.

BPMI a identifié trois aspects fondamentaux des possibilités de BPML au moment de créer la
spécification du langage6 :

• Le langage doit permettre de spécifier les transactions distribuées synchrones et

asynchrones et les compensations, car le langage peut être utilisé par applications de
mission critique ;

• Le langage doit offrir des mécanismes fiables de sécurité, car il modélise des logiques
métiers déployés sur Internet ;

• Il doit contenir des méthodes de gestion de projet, car il est fait pour être employé dans
les environnements intégrés de développement

Les éléments de définition d’un procédé sont :

• Les messages (l’unité d’interaction du procédé) ;

• les participants (des systèmes, des applications, des services web, des utilisateurs
humains, des partenaires commerciaux, et d’autres processus), on distingue les
participants statiques (où l’identité et le comportement sont connus à l’avance), et les
participants dynamiques (ajoutés au moment de l’exécution) ;
• les activités (l’unité d’exécution du procédé) ;
• les transactions (lorsque les activités sont exécutées dans un contexte transactionnel)
nous distinguons deux modèles de transactions coordonnées (pour les délais courts) et
étendues (pour les délais longs) ;
• les exceptions, pour les récupérations des erreurs.

WSCL
WSCL permet de décrire les conversations du niveau de la logique métier ou les processus
publics basse sur la définition d’un service web. Les définitions de conversation en WSCL

6
Business Process Modeling Language - http://searchsmb.techtarget.com/

21
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 [WSL 02].

La spécification WSCL est composée de quatre éléments principaux :

• Les schémas des documents XML, échangés au cours d’une conversation. Ces
schémas ne font pas partie du document de spécification WSCL, ce sont des
documents séparés que on référence par une URL (Uniform Resource Locator) dans la
spécification de la conversation ;

• Les interactions, modélisant les actions de la conversation comme des échanges de

documents entre deux participants. Il existe cinq types d’interactions dans WSCL :
o "Send" : émission d’un message,
o "Receive" : réception d’un message,
o "SendReceive" : émission puis réception d’un message,
o "ReceiveSend" : réception puis émission d’un message,
o "Empty" : ne contient pas de message à échanger, il est utilisé pour modéliser
le début et la fin d’une conversation,

• Les transitions, spécifiant l’ordonnancement les relations entre les interactions.

Chaque transition spécifie l’interaction source et l’interaction de destination, et
éventuellement le type de message de l’interaction source ;

• La conversation, donne la liste de toutes les interactions et les transitions composant la

conversation, ainsi que quelques informations additionnelles, comme le nom de la
conversation, et l’interaction qui démarre la conversation, et celle qui la termine.

WSCL peut être employé en même temps que d'autres langages de description de service
comme WSDL pour fournir des informations obligatoires de protocole pour les interfaces
abstraites, ou pour indiquer les interfaces abstraites implementées par un service concret.

BPEL
Le langage BPEL4WS, (Business Process Execution Language for Web Services) ou tout
simplement BPEL7, est une spécification de IBM, Microsoft, et BEA. Elle remplace les
précédentes spécifications XLANG de Microsoft, et WSFL (Web Services Flow Language)
d’IBM.

Le modèle de procédé BPEL forme une couche au-dessus de WSDL. Il définit la coordination
des interactions entre l’instance de procédé et ses partenaires. Les procédés dans BPEL
exportent et importent les fonctionnalités en utilisant des interfaces de services web
uniquement. BPEL contient les caractéristiques d’un langage structuré en blocs (block
structured language) du XLANG, ainsi que les caractéristiques d’un graphe direct de WSFL.
[ACD 03]

BPEL permet de modéliser deux types de procédé :

7
Dans tout le document nous allons utiliser BPEL pour faire référence BPEL4WS.

22
 • Le procédé abstrait : spécifie les échanges de messages entre les différentes parties,
sans spécifier le comportement interne de chacun d’eux.

• Le procédé exécutable : spécifie l’ordre d’exécution des activités constituant le

procédé, des partenaires impliqués dans le procédé, des messages échangés entre ces
partenaires, et le traitement de fautes et d’exceptions spécifiant le comportement dans
les cas d’erreurs ou d’exceptions.

Le grand avantage de BPEL est la possibilité de décrire les interactions entre les logiques
métiers des différentes entreprises à travers services web.

Les éléments du procédé BPEL sont : les liens de partenaires, les activités et les données.

1. Les liens de partenaires

Un lien de partenaire (partnerLink) correspond au service avec lequel le procédé échange des
informations. Le lien de partenaire représente la relation de conversation entre deux procédés
partenaires. Chaque lien de partenaire est typé par un partnerLinkType, il est chargé de
définir le rôle que joue chacun des deux partenaires dans une conversation.

2. Les activités
Le procédé dans BPEL est constitué d’activités liées par un flot de contrôle. Ces activités
peuvent être basiques ou structurées.

Les activités basiques sont :

• <invoke>, pour invoquer une opération dans un service web.
• <receive>, pour attendre un message d’une source externe.
• <reply>, pour répondre à une source externe.
• <wait>, pour attendre un certain temps.
• <assign>, pour copier les données d’une place à l’autre.
• <throw>, pour lancer une erreur d’exécution.
• <terminate>, pour terminer l’instance de service en entier.
• <empty>, qui ne fait rien (utile pour la synchronisation des activités parallèles).

Les activités structurées sont composées d’autres activités basiques et structurées. Les types
d’activités structurées sont :
• <sequence>, pour définir un ordre d’exécution.
• <switch>, pour l’acheminement conditionnel.
• <while>, pour les boucles.
• <pick>, pour attendre l’arrivée d’un événement
• <flow>, pour l’acheminement parallèle.
• <scope>, pour regrouper les activités afin qu’elles soient traitées par le même
gestionnaire d’erreur.
• <compensate> pour invoquer les activités de compensation par le gestionnaire
d’erreur, pour défaire l’exécution déjà complétée d’un regroupement d’activité.

3. Les données
Le procédé dans BPEL a un état, cet état est maintenu par des variables contenant des
données. Ces données sont combinées afin de contrôler le comportement du procédé. Elles
sont utilisées dans les expressions et les opérations d’affectation. Les expressions permettent

23
d’ajouter des conditions de transition ou de jointure au flot de contrôle. L’affectation
(assignment) permet de mettre à jour l’état du procédé, en copiant les données d’une variable
à une autre ou en introduisant de nouvelles données en utilisant les expressions.

Dans BPEL il n’y a pas de flot de données, BPEL se sert des variables pour passer une donnée
d’une activité à une autre, à l’aide de l’affectation.

La Figure 9 présente le méta-modèle du BPEL.

Figure 9. Le Méta-Modèle de BPEL8

La Figure 9 présent les 3 éléments basiques : des partenaires, des activités et des variables
(contenant les données). La Figure 9 présent également deux autres éléments :

• Process : regroupe une série d’activités de partenaires et d’éléments d’extensibilité.

• Partners : ils sont définit comme un ensemble de liens de partenaires (partnerLink).

Tous ces éléments sont combinés dans un fichier qui contient la définition du procédé. La
Figure 10 présente la structure de ce fichier.

8
[BHL 04]

24
 Attributs supérieurs

PartnerLinks

Variables

Orchestration

Figure 10. Structure de fichier BPEL

La Figure 10 présente les suivants éléments pour le fichier BPEL :

• Attributs supérieurs : cette section correspond à la définition des attributs de

description du fichier comme le nom et les espaces de noms à utiliser pour le procédé.

• PartnerLinks : cette section correspond à la description des tous les partenaires qui
participent dans le procédé.

• Variables : cette section correspond aux espaces de définition de variables utilisés

dans le procédé.

• Orchestration : dans cette section on trouve la définition du procédé en terme des

différents types d’activités qui offre BPEL.

L’objective dans la cadre de cette travail de DEA est définir les conditions pour créer un
fichier BPEL qui a une structure comme la présenté par la Figure 10 à partir d’un procédé
APEL.

Plusieurs implémentations industrielles de BPEL existent actuellement. Parmi ces

implémentations l’application BSOA Orchestra9 (Bull Service Oriented Architecture), qui est
actuellement dans sa version 2.3, est une plate-forme qui contient deux applications :

• L’application Zenflow qui est une application permettant de construire graphiquement,

de modifier et de visualiser des procédés BPEL, avec les différents types d’activités
qui présente la spécification. Zenflow fournit des interfaces pour faire la définition des
variables, partenaires et lier avec des fichiers WSDL, aussi.

• L’application BSOA Orchestra Console qui est une application pour faire le
monitoring au moment de l’exécution. BSOA Orchestra Console fonctionne sur le
serveur d’application JonAS et permet déployer et exécuter des procédés BPEL, ainsi
que permet de faire l’analyse de l’information dans l’état final d’un procédé qui a déjà
fini son exécution.

9
Plus d’information dans www.bull.com

25
Au moment de la création du procédé, Zenflow présenté : des interfaces dans laquelle on
remplit l’information pour les sections d’attributs supérieurs, de partenaires et de variables.
Pour la section d’orchestration, l’application fournit le formalisme graphique pour chaque
type d’activité et les interfaces pour remplir l’information demandé selon le type. La Figure
11 présente un exemple du formalisme graphique en utilisant l’application Zenflow.

Figure 11. Exemple d’un procédé BPEL dans Orchestra

La Figure 11 illustre un procédé imbriqué dans un type d’activité sequence. L’activité

OrderTrip correspond à un type d’activité receive qui attend un message afin de démarrer le
procédé ; les activités ReserveTickets et BookTickets correspondent aux types d’activités
invoke représentant l’invocation aux opérations dans un service web.

La version acceptée actuellement de la spécification BPEL est la version1.1 de 2003. Cette

version et a été présenté par BEA, IBM, Microsoft, Siebel Systems et SAP. A décembre 2005,
le groupe OASIS (Organization for the Advancement of Structured Information Standards)
coordonne le travail autour de la spécification BPEL 2.010. OASIS est un consortium global
qui conduit le développement, la convergence et l'adoption des normes pour e-bussines.

10
Plus d’information dans [BPEL 2.0]

26
 3. CONTRIBUTION

1.1 Introduction

L’objective de ce travail est de réaliser une analyse établissant les conditions initiales pour
pouvoir « traduire » les procédés décrits dans le langage APEL vers des procédés décrits en
BPEL, en gardant la même sémantique.

Cependant, il y a des difficultés à ce travail, car il n’est pas possible de traduire en BPEL tous
les procédés décrits en APEL. Ceci pour plusieurs raisons :

• La représentation de procédés en APEL est de haut niveau, elle offre une abstraction du
procédé permettant de modéliser facilement le procédé souhaité en utilisant uniquement
des activités et des liens entre ces activités. D’un autre coté, BPEL est un langage
ressemblant beaucoup à un langage de programmation, qui utilise des structures (types
d’activité) à sémantique prédéfinies. Ces types de structures ne se trouvent pas dans le
formalisme d'APEL, parce qu'ils ne sont pas requis ;

• Le formalisme BPEL est restreint, il ne permet de définir des flux de contrôle que dans un
seul sens. Pour contourner ce problème, il faut utiliser les types d’activité qui sont
prévues pour cette usage. Le formalisme APEL, quant à lui, permet beaucoup plus de
flexibilité. Il permet par exemple de faire la communication entre les différents ports
d’entrée et de sortie à l’aide des flots de donnés sans perdre le flux de contrôle du
procédé ;

• Pour spécifier un procédé dans BPEL il est nécessaire de connaître la description des
services web qui participent dans le procédé. Cette description est fournit par les fichiers
WSDL de chaque service web qui participe à l’exécution du procédé. Nous devons
trouver la manière dans laquelle, notre outil utilise l’information de ces fichiers au
moment de la transformation.

• Comme nous l’avons déjà dit, les deux formalismes sont différents. On ne peut pas
traduire une activité en APEL par une activité en BPEL (en suivant des relations un-à-un).
Pour que le procédé décrit en BPEL soit exécutable dans un moteur BPEL, il doit être
spécifié avec les types d’activités propres à BPEL. Par conséquent, il faut identifier les
patrons au niveau du formalisme APEL que nous pourrons traduire automatiquement en
activités BPEL ;

• Dans les procédés APEL on peut ajouter du code aux activités en utilisant la technologie
des aspects [SAN 05]. Ce code ajouté permet au moment de l’exécution d’un procédé de
capturer un événement ou un changement d’état d’une activité afin de lancer l’exécution
de certaines fonctionnalités BPEL support l'agrégation de code en utilisant éléments
d’extension et non avec les types d’activités communs, ce qui ajoute une difficulté à la
traduction APEL vers BPEL.

Un deuxième objectif de ce travail est de spécifier les modifications au niveau de l’éditeur

graphique d’APEL, afin que l’on soit capable de prendre le procédé APEL modélisé dans cet
éditeur graphique et de faire la transformation dans BPEL, en tenant compte du fait que le

27
procédé d’origine doit être exécuté dans le moteur APEL (le logiciel qui est capable
d’interpréter le modèle de procédé APEL et de réaliser des exécutions) et que la
transformation dans BPEL soit exécutable sur un moteur BPEL implémentant la spécification.

Dans ce chapitre nous présentons tout d’abord une étude sur l’appel à des opérations des
services web. Cette étude consiste à spécifier une opération simple et l’implémenter dans la
technologie des services web, puis effectuer l’appel de cette opération suivant trois scénarios
différents : le premier scénario se passe dans le contexte d’une application Java simple ; le
deuxième dans le contexte d’un procédé BPEL et le dernier dans le contexte d’un procédé
APEL.

Notre but est l’obtention des patrons dans APEL qui soient facilement traduisibles en BPEL.
Pour cela, nous présentons dans la deuxième section une comparaison entre les langages
APEL et BPEL en utilisant en premier temps des patrons de flux de contrôle puis des patrons
de communication. Nous présentons également dans cette section une comparaison entre ces
deux langages du point de vue de la modélisation des données.

Dans la dernière section de ce chapitre nous allons présenter les principes de transformation à
partir d’APEL vers BPEL. Nous allons expliquer les conditions, et restrictions pour que notre
outil puisse transformer sémantiquement les procédés vers la spécification BPEL.

3.2 Comparaison d’appel d’un service web

Dans cette section nous présentons la comparaison entre APEL et BPEL par rapport à
l’exécution des services web. Pour la construction de ce service web, nous utilisons AXIS11,
pour générer les classes Java qui implémentent l’opération souhaitée pour le service web.

Autre objective de cet étude est prendre la mesure du temps pendant l’exécution d’une activité
qui fait l’appel à une opération d’un service web, dans le domaine d’APEL. A la fin, nous
présentons un graphique qui montre les résultats. De la même façon, prendre une mesure
similaire depuis un procédé BPEL.

L’opération que nous avons créer, comme service web, est une opération simple qui consiste à
recevoir une donné entier comme paramètre, prendre sa valeur et lui ajouter l’entier un.
L’implémentation pour le test a été réalisé en premier lieu depuis une application Java qui
utilise les classes AXIS, ensuite depuis un procédé BPEL et finalement depuis un procédé
APEL.

3.2.1 Implémentation de l’appel en AXIS

Consiste à créer un projet Java qui appelle la méthode du service web. Dans ce cas, nous
implémentons une classe Java (Client) qui fait l’appel au service web en utilisant les classes
générées par AXIS. Pour avoir une meilleure mesure du temps nous ferons plusieurs
répétitions (100 répétitions) de l’appel, dans chaque exécution. C’est à dire pour chaque

11
Plus d’information dans [WSA 05].

28
exécution de la classe Java nous prenons le temps d'appeler 100 fois le service web. La
Figure 12 présente la méthode qui fait l’appel au service web.

Figure 12. Implémentation Java pour appeler un service web

La structure du code présente dans la Figure 12 est la suivante : nous prenons le temps au
début de l’exécution (lignes 22). Ensuite, nous faisons l’appel répétitif au service web (lignes
23-25). L’appel est représente par une variable nommé service qui représente le service web,
lequel contient une opération methode1. Finalement, nous prenons le temps final juste après
l’exécution de l’appel à la méthode.

3.2.2 Implémentation de l’appel en BPEL

Consiste à construire un procédé BPEL qui appelle la méthode du service web, en utilisant le
formalisme de types d’activités propres de ce langage. La Figure 13 présente la codification
BPEL qui implémente l’appel au service web du test.

Figure 13. Codification BPEL pour faire l’appel à un service web

La structure du code présente dans la Figure 13 est la suivante : nous prenons le temps au
début de l’exécution (lignes 2-6). Ensuite, nous faisons l’appel répétitif au service web (lignes

29
7-17). L’appel est représente par le type d’activité invoke avec ses paramètres d’entré et de
sortie (lignes 9-10). Finalement, nous prenons le temps final juste après l’exécution de l’appel
à la méthode.

3.2.3 Implémentation de l’appel en APEL :

Dans APEL, l’implémentation consiste en ajouter à une activité la codification Java

nécessaire pour faire l’appel au service web. Cette codification prend les mêmes classes
utilisées dans la première implémentation (clases AXIS). La Figure 14 illustre l’activité qui
fait l’appel.

Partie a.

Partie b.

Figure 14. Activité APEL pour le test appel à un service web

De la même manière nous faisons l’appel répétitif, c’est pour cela que l’activité de la Figure
14 correspond à un type d’activité while12. La partie b. de la figure (activité Corps) est à
l’intérieur de l’activité WhileWSCall (partie a. de la même figure). L’activité WhileWSCall
reçoit un produit a qui sera le paramètre pour l’opération du service web. A l’intérieur se
trouve une activité corps qui contient le code nécessaire pour, au moment de son exécution :
valider la condition du while et faire l’appel au méthode.

Le temps initial et final est pris au moment que l’activité WhileWSCall commence et termine
son exécution, respectivement.

12
Les nouveaux types d’activités APEL identifiés autour de ce travail de recherche seront présentés dans le
chapitre 4.

30
3.2.4 Comparaison des différentes méthodes :

Comme résultat final, la Figure 15 présente une comparaison entre les différents temps pris
pendant le test. La figure présente une relation entre le temps (mesuré dans millisecondes) et
le nombre des essais. Pour ce test nous avons réalisé 20 essais avec chaque implémentation.

Appel à service web depuis APEL, BPEL et Java

100

90

80

70
Temps en millisecondes

60
BPEL
50 Java-AXIS
APEL-AXIS
40

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Nom bre de essais

Figure 15. Résultats des appels à service web.

La différence de temps entre APEL et BPEL est située, car dans le côté APEL existe des
concepts comme la persistance et le contrôle, que sont des opérations qui ont un coût de temps
associé. La persistance permet, par exemple, reprendre l’exécution d’un procédé dans le point
où il a été interrompu. Et le contrôle permet de créer des nouvelles instances de procédés,
faire une liste des tâches et démarrer ou arrêter l’exécution des activités tout en utilisant des
interfaces graphiques pour une meilleur représentation.

Du côté BPEL il existe l’échange des messages chaque fois qui la méthode du service web est
appelé. Le temps qui se passe dans la construction, des messages SOAP tant pour envoyer
comme pour recevoir l'information, a une consommation de temps importante.

La différence de temps entre APEL et BPEL est située, car dans le côte APEL existe des
concepts comme la persistance et le contrôle, que sont des opérations qui ont un coût de temps
associé. Ces fonctionnalités permettent de garder les états de produits et des activités pour
contrôler les activités du procédé, ainsi que la représentation graphique qui le moteur APEL
construit au moment de l’exécution, pour contrôler visuellement l'exécution.

31
BPEL n’implémente ces caractéristiques, en conservant seulement des logs écrits au moment
de l'exécution. Du côté BPEL il existe l’échange des messages chaque fois qui la méthode du
service web est appelé. Le temps qui se passe dans la construction, des messages SOAP tant
pour envoyer comme pour recevoir l'information, a une consommation de temps importante.

L’appel depuis Java a un temps moyenne bas du au fait que elle n'a pas de coûts associé par
des fonctionnalités de valeur ajoutée comme représentations graphiques ou persistance des
données tant envoyés comme reçus.

Le dernier essai nous a été utile pour établir un premier point de comparaison entre APEL et
BPEL en vue de la construction de l'outil qui permettra transformé un procédé décrit en APEL
vers BPEL. Et dans ce test nous pouvons utiliser aussi les potentialités d'APEL avec
l’utilisation du code dans les activités au moment de l’exécution.

Dans les sections suivantes, nous allons présenter notre comparaison entre le langage APEL et
BPEL, du point de vue des patrons. En premier lieu les patrons pour le flux de contrôle, dont
l'objectif est d’établir un point de comparaison commun entre le deux langages. Ensuite, avec
les patrons pour la communication, de manière semblable, nous présentons les
implémentations de ces patrons dans le deux langages.

3.3 Patrons de flux de contrôle des workflows en APEL et BPEL

De manière générale, le Workflow est défini comme étant le procédé métier modélisant le
transfert des documents et/ou des tâches à réaliser. Aujourd’hui, le terme workflow continue à
être utilisé dans le domaine des application traditionnels, pour modéliser et coordonner les
procédés. Ils sont également utilisés maintenant dans des secteurs émergents comme dans le
domaine des canevas de composants et l’interaction business-to-business [AHK 00]

Les spécifications de workflow peuvent être vues par plusieurs perspectives :

• La perspective du flux de contrôle: Cette perspective décrit les activités et leurs

exécutions dirigées par différents constructeurs. Elle offre des flux d'exécution de
contrôle, comme les séquences, le parallélisme et la synchronisation. Dans la
perspective du flux de contrôle, les activités élémentaires sont des unités du travail et
les activités composées modélisent l’exécution ordonnée d’un ensemble d’activités
(composées ou élémentaires).

• La perspective des données : les données sont des documents métiers ou des objets
transférés entre les activités. Les données peuvent également être des variables locales
du procédé définissant les pré-conditions et les post-conditions pour l'exécution.

• La perspective des ressources : Cette perspective fournit au workflow une structure

organisationnelle sous la forme de rôles responsables de l'exécution des activités.

• La perspective opérationnelle : Cette perspective décrit les actions élémentaires

exécutées par les activités ainsi que les interfaces qui permettent la manipulation des
données dans des applications.

32
Dans ce travail de DEA, nous avons étudié les patrons de workflows du point de vue du flux
de contrôle [AHK 00, VdA patt]. Nous avons réalisé une étude pour déterminer comment sont
exprimé ces patrons dans APEL, et quelle est leur correspondance dans BPEL. De cette
manière, par la suite, utiliser certains patrons dans les procédés APEL qui soient facilement
traduisibles vers BPEL afin de pouvoir l’exécuter sur un moteur BPEL. Nous avons, par la
suite, réalisé un outil de transformation permettant de traduire automatiquement de procédés
dans le langage APEL vers du BPEL. Nous allons présenter les caractéristiques de cet outil de
transformation dans le chapitre 4.

Dans cette section nous allons présenter la description et la représentation des patrons de flux
de contrôle des workflows gérés dans APEL, et leurs correspondances dans BPEL.

Nous utilisons [AHK 00, VdA patt] comme référence pour les fondements théoriques. Pour
la représentation du flux de contrôle en BPEL, nous utilisons l’étude [WAD 04] sur ces
patrons en BPEL et l’application Zenflow BPEL Designer qui est le formalisme graphique de
la plate-forme BPEL Orchestra, pour faire la représentation graphique. Ce formalisme permet
de d’exprimer graphiquement le flux de contrôle, et génère automatiquement le code BPEL au
format XML correspondant à cette expression graphique. Pour la représentation du flux de
contrôle en APEL, nous utilisons APEL Editor, qui est l’éditeur graphique permettant de
réaliser graphiquement des modèles de procédé dans le langage APEL.

Les patrons de flux de contrôle des workflows :

Pour chaque patron, nous présentons la définition en terme des activités en liens entre eux,
une représentation graphique, l’expression en BPEL en utilisant son formalisme et finalement
l’expression en APEL.

3.3.1 Séquence (sequence)

L’activité de la séquence est disponible une fois que les activités précédentes de la séquence
soient terminés [AHK 00]. Le patron de la séquence est représenté dans la Figure 16.

A B C

Figure 16 : Le patron de la séquence

Dans cette séquence, l’activité B est disponible une fois que l’activité A ait terminé son
exécution. De la même manière, l’activité C est disponible une fois que l’activité B soit
terminée.

L’expression de la Séquence en BPEL :

BPEL contient un type d’activité s’appelant sequence. Ce type d’activité permet de définir
qu’un ensemble d’activités de BPEL sera exécuté séquentiellement. Les deux figures : Figure
17 représente un exemple de la séquence en BPEL.

33
 Figure 17 : exemple de la séquence en BPEL - représentation graphique et code BPEL correspondant

Dans l’exemple précédant, l’activité de type invoke (qui réalise l’opération B) est exécutée
après l’exécution de l’activité de type receive (qui réalise l’opération A) et la deuxième
activité de type invoke (réalisant l’opération C) est exécutée après celle qui réalise l’opération
B.

L’expression de la Séquence en APEL :

Figure 18 : L’expression de la séquence en APEL

La
Figure 18 présente la représentation du patron en APEL. Cette représentation est plus proche à
la définition du patron.

3.3.2 Parallélisme (parallel split)

Le parallélisme représente un point dans le procédé où un lien de contrôle simple est divisé en
plusieurs liens de contrôle s’exécutant en parallèle [AHK 00]. Le patron du parallélisme est
représenté dans la Figure 19.

34
 B

AND
A

Figure 19 : Le patron du Parallélisme

La Figure 19 présente le patron Parallélisme, au moment de terminer l’exécution de la activité

A, le lien de contrôle passe aux activités B et C.

L’expression du Parallélisme en BPEL :

Pour la représentation de ce patron, BPEL contient un type d’activité nommé flow. Ce type
d’activité permet de spécifier les activités qui seront exécutées de façon concurrente.

Figure 20 : L’expression du parallélisme en BPEL

La Figure 20 illustre un exemple du parallélisme en BPEL. Dans cet exemple nous

remarquons ne activité flow qui contient deux activités imbriquées invoke-1 (opération A) et
invoke-2 (opération B). Ces deux activités seront exécutées de manière concurrente, au
démarrage de l’activité flow, le flux de contrôle est divisé entre ces deux activités. La figure 6
présente le code BPEL pour cet exemple.

Figure 21 : L’expression du parallélisme en BPEL - code BPEL correspondant

Dans la Figure 21, on peut noter les deux types d’activités invoke qui sont imbriquées dans le
type flow.

35
L’expression du Parallélisme en APEL :

Figure 22 : L’expression du parallélisme en APEL

La Figure 22 présente le patron Parallélisme en APEL. Après l’exécution de l’activité A,le

lien de contrôle passe aux activités B et C. Ces activités seront exécutées de façon
concurrente.

3.3.3 Synchronisation (synchronization)

La synchronisation est un point dans le procédé où plusieurs flux de contrôle convergent et
fusionnent dans un seul flux de contrôle synchronisant tous ces liens [AHK 00]. Le patron d
la synchronisation est représenté dans la Figure 23.

AND
C

Figure 23 : Le patron de la Synchronisation

L’expression de la Synchronisation en BPEL :

BPEL réalise ce patron avec le même type d’activité présenté précédemment (flow).
L’activité flow permet de fusionne les liens pour de continuer l’exécution dans un seul flux de
procédé.

L’expression de la Synchronisation en APEL :

36
 Figure 24 : Le patron de la Synchronisation en APEL

La Figure 24 présente l’expression du patron Synchronisation en APEL. Une fois, les

activités B et C soient terminées l’activité D s’active.

3.3.4 Choix Exclusif (exclusive choice)

Le choix exclusif est un point dans le procédé où un chemin est choisi entre plusieurs, ce
choix est fait à l’aide d’une décision prise au moment de l’exécution, cette décision est basée
sur une information ou une donnée du procédé. Contrairement à Parallélisme, un seul lien
dans le flux de contrôle est activé [AHK 00]. Le patron du Choix Exclusif est représenté dans
la Figure 25.

B
XOR
A

décision

Figure 25 : Le patron de la Choix Exclusif

La Figure 25 représente le patron du choix exclusif. Une fois l’activité A devient terminé, il
existe une sélection pour le lien de contrôle pour savoir qui continue dans le contrôle : soit
l’activité A, soit l’activité B.

L’expression du Choix Exclusif en BPEL :

Figure 26 : L’expression du Choix Exclusif en BPEL

37
BPEL utilise le type d’activité switch pour permettre de réaliser le choix exclusif. Chaque
lien inclus dans ce choix exclusif est contenu dans un élément case. Au moment de
l’exécution du switch, chaque case contient la séquence d’activités qui sera exécutée si la
condition liée au case est vraie. Le switch utilise également un autre élément : le otherwise.
Cet élément est optionnel, il représente un lien qui sera choisi par défaut si aucun case ne
contient une condition vraie. Du fait que cet élément est optionnel, s’il n’existe pas
explicitement dans la définition de procédé, le moteur génèrera un lien otherwise avec un
type d’activité empty.

La nouvelle spécification de BPEL qui est en ce moment dans l’état d’avant-projet (draft)
fournira un type d’activité if permettant de réaliser un cas simple de l’activité switch.

L’expression du Choix Exclusif en APEL :

Figure 27 : L’expression du Choix Exclusif en APEL

Dans le langage APEL nous pouvons exprimer une activité CHOIX (Figure 27), qui pourrait
recevoir le flux de contrôle par le port begin et qui aurait deux (ou plusieurs) ports de sortie :
end1 et end2. C’est à l’intérieur de cette activité CHOIX que se fait la sélection du port qui
sera activé pour continuer dans le flux de contrôle du procédé (dans notre exemple illustré
dans la Figure 27, le choix se fait entre le port out1 et dans ce cas là c’est l’activité B qui est
activée, et le port out2 et dans ce cas là c’est l’activité C qui sera activée).

3.3.5 Fusion simple (simple merge)

La fusion simple est un point dans le procédé dans lequel une ou plusieurs branches du flux de
contrôle se joignent sans nécessité de synchronisation [AHK 00]. Le patron de la Fusion
Simple est représenté dans la Figure 28.

XOR
C

Figure 28 : Le patron de la Fusion simple

La Figure 28 représente le patron Fusion Simple. Au moment d’arriver la terminaison de A ou

de B ou des deux, le procédé continue avec l’activité C.

38
L’expression de la Fusion Simple en BPEL :

Ce patron est représenté dans BPEL par la fin d’une activité de type switch. Pour compléter
son exécution, ce type d’activité attend la terminaison de la branche activée (selon l’élément
case sélectionné) parmi les branches qui y sont connectées.

L’expression de la Fusion Simple en APEL :

Dans le langage APEL nous pouvons exprimer la Fusion Simple par une activité contenant
plusieurs ports d’entré (l’activité C dans l’exemple de la Figure 29). Cette activité de Fusion
Simple est exécutée lorsque l’un des deux ports begin ou begin2 est activé.

Figure 29 : L’expression de la Fusion Simple en APEL

La Figure 29 représenté le patron Fusion Simple en APEL..

3.3.6 Choix Multiple (multiple choice)

Le choix multiple est un point dans le procédé où plusieurs branches sont sélectionnées et
exécutées en parallèle. Ce choix est fait à l’aide d’une décision prise au moment de
l’exécution, cette décision est basée sur une information ou une donnée du procédé.[AHK 00].
Le patron de la Choix Multiple est représenté dans la Figure 30

Multi-
A choice

décision

Figure 30 : Le patron du Choix Multiple

La Figure 30 illustre le patron Choix Multiple. Contrairement au patron Choix Exclusif

(présenté dernièrement, Figure 25), dans le patron Choix Multiple plusieurs branches peuvent
être sélectionnées et non pas qu’une seule

39
L’expression du Choix Multiple en BPEL :

Pour représenter ce patron, BPEL utilise le type d’activité flow, l’activité empty et le concept
du link. Nous allons détailler la représentation de ce patron dans la section suivante, en même
temps que le patron suivant.

L’expression du Choix Multiple en APEL :

En utilisant, l’activité CHOIX présenté précédemment (Figure 27), nous pouvons représenter
le patron Choix Multiple dans APEL, comme l’illustre l’exemple de la Figure 31.

Figure 31 : L’expression du Choix Multiple en APEL

Dans cet exemple, et au moment de sortir de l’activité A, le flux de contrôle active les trois
instances de l’activité CHOIX. la vérification de la condition est alors effectuée dans chacune
de ces instances, afin que le flux de contrôle active l’activité B, l’activité C, ou le deux
ensemble.

3.3.7 Fusion Synchronisée (synchronizing merge)

La fusion synchronisée est un point dans le procédé où plusieurs flux de contrôle convergent
vers un seul. Si une seule branche du flux de contrôle est exécutée, l’activité suivante à la
fusion synchronisée est activée au moment où l’exécution de cette branche se termine. Sinon,
les branches qui se sont exécutées sont synchronisées avant de continuer [AHK 00]. Le patron
de la Fusion Synchronisée est représenté dans la Figure 32.

Multi- Sync-
A choice Merge D

Figure 32 : Le patron du Fusion Synchronisée

40
La Figure 32 représente le patron de la Fusion Synchronisée

L’expression de la Fusion Synchronisée en BPEL :

Pour représenter ce patron en BPEL, nous utilisons le type d’activité empty (défini
précédemment dans le patron Multiple choice). Nous utilisons également des liens permettant
d’établir la synchronisation. Ainsi, pareillement au patron Multiple choice, qui est représenté
au début de l’activité flow, définissant le commencement du parallélisme, le patron
Synchronizing Merge est représenté à la fin de cette activité flow définissant la fin de ce
parallélisme (comme l’illustre la Figure 33).

L2 L1

L2s L1s

Figure 33 : L’expression du Fusion Synchronisée en BPEL

La Figure 33 illustre la représentation du patron Fusion Synchronisée. Les liens utilisés pour
l’implémentation du patron son nommés L1, L2, L1s et L2s (noms utilisés en [AHK 00]).

Dans la Figure 34 le schéma illustré à gauche représente le même procédé que celui de la
Figure 33 édité dans BPEL Designer. La partie entourée en pointillé correspond au patron
Synchronizing Merge. La partie droite représente le code BPEL associé au schéma illustré à
gauche.

41
 A
Flow

Empty
L1, C1 L2, C2
B C
OR
L1s L2s
D

Figure 34 : L’expression du Fusion Synchronisée en BPEL

Au moment de l’exécution de ce procédé (Figure 34), trois cas de figures sont possibles :
1. Si l’une des deux conditions c1 (associée à l’activité B) ou c2 (associée à l’activité C)
est vrai, l’activité correspondante B ou C recevra le contrôle et sera exécutée.
2. Si la condition c1 (ou c2) est fausse, l’activité B (ou C) recevra une valeur négative et
ne sera donc pas exécuté. Cette valeur négative est propagée jusqu’au lien L1s (ou
L2s respectivement).
3. Si les deux conditions (c1 ou c2) sont évaluées à vrai, dans le cas là, les activités B et
C sont exécutés toutes les deux.
Dans tous les cas précédents l’attribut joinCondition de l’Activité D s’assure que D soit
toujours exécutée lorsque l’une des activités B ou C au moins est exécutée.

L’expression du Fusion Synchronisée en APEL :

42
 Figure 35 : L’expression du Fusion Synchronisée en APEL

Pour représenter ce patron en APEL, nous définissons une activité CHOIX avec deux ports
asynchrones : le premier indique que l’activité B sera exécutée, le deuxième indique que
l’activité C sera exécutée. Le troisième port de sortie de l’activité CHOIX (le port end) est un
port synchrone qu’indique la condition pour connaître sur quel port l’activité MERGE attend
la réponse. Finalement, le procédé continue avec l’activité D.

3.3.8 MI13 avec synchronisation (MI with synchronization)

Ce patron représente un point dans le procédé où un certain nombre d’instances d’une activité
sont exécutées et synchronisées avant de passer à la suite du procédé [AHK 00]. Il existe trois
variantes de ce patron :

a. MI avec la connaissance a priori au temps de conception :

(MI with a priori Design Time Knowledge), le nombre d’instances exécutées et
synchronisées est connu au moment de la conception.
b. MI avec la connaissance a priori au temps d'exécution :
(MI with a priori Runtime Knowledge) le nombre d’instances est connu au
moment de l’exécution du procédé, mais avant le démarrage des instances.
c. MI sans la connaissance a priori au temps d'exécution :
(MI without a priori Runtime Knowledge) le nombre d’instances n’est pas connu à
l’avance, cependant on peut créer des nouvelles instances à la demande.

Le patron du MI avec synchronisation est représenté dans la Figure 36.

ajoutez l'instance

A B C

Figure 36 : Le patron du MI avec synchronisation

La Figure 36 représente le patron MI avec synchronisation

L’expression du MI avec synchronisation en BPEL :

13
Instances multiples (Multiple Instances).

43
Nous avons vu dans le paragraphe précédant qu’il y a trois variantes pour ce patron.

Pour représenter en BPEL la première variante (a) ¸ une solution simple est d’instancier
l’activité autant de fois que nécessaire, et d’utiliser le type d’activité flow pour synchroniser
toutes ces instances.

Pour représenter en BPEL les deux autres variantes (b) et (c), la solution serait d’utiliser le
type d’activité pick (il est un type d’activité BPEL qui attends l’arrivée d’un événement pour
s’activer) et le type d’activité while (qui permet de définir une exécution répétitive
d’activités).

L’activité while définit l’exécution répétitive à travers de trois messages: le premier indique
qu’une nouvelle instance de l’activité B est demandé ; le deuxième indique qu’une instance
préalable a été finalisée ; et le dernier indique qu’il n’y a plus à créer d’autres instances. à la
réception de chacun de ces trois messages, une activité est déployée/invoquée dans chaque
itération de l’activité while.

La Figure 37 illustre la représentation de ces deux variantes en utilisant l’activité pick et

l’activité while. Néanmoins, cette solution est approximative, car la logique de ces deux
variantes (b et c) n’est pas directement capturée par un type d’activité spécifique BPEL.

Figure 37 : exemple du MI avec synchronisation - représentation graphique

La Figure 37 présente une représentation approximative pour le partie b et c du patron MI

avec synchronisation . Cette logique est codée à travers une boucle et un compteur : le
compteur est incrémenté à chaque fois qu'une nouvelle instance est créée, et il est décrémenté
à chaque fois qu'une instance est terminée. La boucle se termine lorsque la valeur du
compteur est à zéro et qu’il n’y a plus besoin de créer d’autres instances. La Figure 38
présente la codification BPEL associé à cet exemple.

44
 Figure 38 : exemple du MI avec synchronisation - code BPEL

La Figure 38 présente la codification BPEL associé au exemple de la Figure 37.

L’expression du MI avec synchronisation en APEL :

La Figure 39 illustre la représentation en APEL de la première variante (a) du patron. Du fait

que le nombre d’instances de l’activité est connu au moment de la conception, nous pouvons
alors créer autant d’instance de cette activité que nous avons besoin d’exécuter.

Figure 39 : L’expression du MI avec synchronisation en APEL

Dans l’exemple de la Figure 39, nous avons créé deux instances X1 et X2 de la même activité.

Pour représenter en APEL les deux autres variantes b et c, nous pouvons utiliser une
caractéristique du langage APEL qui permet de définir le nombre d’instances pendant
l’exécution du procédé. Par contre, pour la synchronisation c’est plus compliqué pour la
manière de exécution, car l’activité qui suit ces instances multiples est exécuté à chaque fois
qu’une des instances est terminé, et non pas quand toutes les instances sont terminées (ce qui
devrait se passer suivant le patron). C’est à dire est la mise en oeuvre est incomplète pour les
variantes b et c.

45
3.3.9 Choix Différé (deferred choice)
Ce patron représente un point dans le procédé dans lequel une branche est choisie parmi
plusieurs. Ce choix est basée sur une information ou une donnée qui n’est pas nécessairement
disponibles au moment où ce point du procédé est atteint. La sélection de la branche est alors
retardée jusqu’à ce que certains événements arrivent pour donner au procédé l’information
requise [AHK 00]. Le patron du Choix Différé est représenté dans la Figure 40.

Deferred
A Choice

Figure 40 : Le patron du Choix Différé

L’expression du Choix Différé en BPEL :

La Figure 41 présente une représentation en BPEL pour le patron Choix Différé.

Figure 41 : L’expression du Choix Différé en BPEL

Ce patron est représenté principalement par le type d’activité pick (Figure 41). Ce type
d’activité attend la réception d’un des messages et continue l’exécution en suivant la branche
correspondante au message qui a été reçu. La sélection de la branche est retardée jusqu'à ce
que cette activité reçoive un message. La codification BPEL pour cet exemple est présenté
dans la Figure 42.

Figure 42 : exemple du Choix Différé - code BPEL

46
L’expression du Choix Différé en APEL :

La Figure 43 illustre la représentation en APEL du patron Choix Différé.

Figure 43 : L’expression du Choix Différé en APEL

La Figure 43 représente le patron Choix Différé en APEL. Nous utilisons des ports
asynchrones dans l’activité qui doit prendre la décision. L’activité reçoit des produits à travers
ces ports asynchrones, ces produits lui permettront de choisir le port de sortie par lequel le
procédé continuera son exécution. C'est à dire, l'information pour faire la sélection du port,
pour continuer dans le flux provient du port asynchrone.

3.3.10 Activité d’annulation (cancel activity) et Cas d’annulation (cancel case)

L’activité cancel termine l’exécution d’une activité. Cependant, le patron cancel case
représente la terminaison de l’instance du procédé en entier [AHK 00]. Les deux patrons sont
représentés dans la
Figure 44.

Cancel
Activity

A B C

Cancel
Case

A B C

Figure 44 : Les patrons Activité d’annulation et Cas d’annulation

47
L’expression des patrons d’annulation en BPEL :

La représentation du patron cancel en BPEL est faite à l’aide des deux types d’activité fault et
compensation handlers, ces deux types d’activité spécifient les actions à exécuter dans le cas
d’une faute et dans le cas de l’annulation respectivement.

Dans l’exemple de la Figure 45, l’activité B a deux fault handlers contenant des éléments
catch (est une élément qui est définie pour arrêter un type spécifique de défaut), et un
compensation handler qui invoque l’activité D.

Activité B

Figure 45 : exemple du patron Activité d’annulation - représentation graphique BPEL et code

correspondant

La Figure 45 présente un exemple d’utilisation du patron Activité d’annulation et son code

correspondant en BPEL.

Pour représenter le patron Cas d’annulation (cancel case), BPEL utilise le type d’activité
terminate. Ce type d’activité est utilisé pour abandonner totalement l’exécution du procédé
dont l’activité fait partie. La Figure 46 présente un exemple d’utilisation de ce patron.

48
Figure 46 : exemple du patron Cas d’annulation - représentation graphique BPEL et code correspondant

La Figure 46 présente un exemple d’utilisation du patron Cas d’annulation et son

correspondant code en BPEL.

L’expression des patrons d’annulation en APEL :

Pour représenter le patron cancel activity, les activités en APEL peuvent passer de l’état
d’exécution a l’état d’échec (aborted) à la demande de l’utilisateur du procédé. De cette
manière, l’activité du procédé peut être annulée au moment souhaité.

Une activité dans APEL peut contenir des sous-activités, et ces sous-activités peuvent
contenir d’autres sous-activités (et cela de manière récursive). Lorsque l’activité composite
est annulée, toutes ses sous-activités sont également annulées.

De la même manière, les activités d’un procédé sont considérées comme des sous-activités
d’une activité englobante qui représente le procédé en entier. Ainsi, si cette activité
englobante est annulée, le procédé en entier est annulé. C’est ainsi que nous implémentons le
patron cancel case.

Dans cette section nous avons présenté une comparaison entre les langages APEL et BPEL du
point de vue des patrons pour le flux de contrôle. Dans ce comparaison nous avons illustré la
manière dans laquelle chaque langage fait la réalisation du patron en utilisant son formalisme
spécifique.

Comme conclusion, nous pouvons constater que tant en APEL comme en BPEL on peut
représenter des procédés avec un niveau d’abstraction qui permet de donner une exécution
ordonnée d’un ensemble d’activités, lesquelles représentent unités du travail qui, dans
l'ensemble, donnent un sens logique à un procédé.

Nous allons présenter dans la section suivante autre comparaison entre le deux langages.
Dans ce cas, du point de vue des patrons pour la communication. De manière similaire a ce
section, nous allons faire la représentation de comme APEL et BPEL pourraient mettre en
oeuvre ces patrons.

49
3.4 Patrons de communication en APEL et BPEL

Les activités forment la partie essentielle des patrons de contrôle de flux. Les activités sont
représentées dans APEL et dans BPEL avec un formalisme propre à chacun de ces deux
langages, comme nous l’avions vu précédemment. Les activité dans APEL et les instances de
types d’activités dans BPEL forment la structure du procédé que l’on veut représenter.

Dans cette section, nous allons étudier les patrons de communication afin d’analyser la
manière de laquelle les deux langages APEL et BPEL, gèrent ces patrons.

Dans APEL, la communication entre les activités du procédé est établie à travers les flux de
données. Chaque flux de données est connecté à deux activités par deux ports, un port de
sortie associé à l’une des deux activités et un port d’entré associé à l’autre activité. Les flux de
données spécifient comment les produits circulent entre les activités. Un produit est une pièce
d’information (représentant différents concepts) qui est produit, transformé et consommé par
les activités [EVL 03].

BPEL contient le concept de variables. Les variables maintiennent l’état d’un procédé métier.
L’état comporte des messages qui sont reçus et envoyés entre les instances des types
d’activités qui forment le procédé [ACD 03]. Les variables correspondent aux Messages
déclarés dans les fichiers WSDL, ces variables sont gérés dans le procédé BPEL par les
différents types d’activités (invoke, receive, reply, et d’autres).

Dans le contexte de notre travail, nous définissons la communication comme étant l’échange
de messages entre différents procédés, un échange explicitement modélisé par l’envoi et la
réception de messages.

Il existe deux types de communication :

• La communication synchrone que nous nommons également la coordination ;

• La communication asynchrone dans laquelle l’exécution peut continuer sans avoir besoin
de synchronisation.

Chacun de ces deux types de communication a ces propres patrons. Nous allons montrer la
représentation de ces patrons dans BPEL. Les trois premiers patrons que nous allons
présenter ci-dessous correspondent au type Synchrone, les autres patrons correspondent au
type Asynchrone.

Pour la représentation des patrons, les flèches indiquent le mouvement des messages entre les
participants de la communication. Nous utilisons l’étude [WAD 04] sur ces patrons en BPEL
et l’application BPEL Designer pour faire la représentation graphique. Nous utilisons APEL
Editor, qui est l’éditeur graphique permettant de réaliser graphiquement des modèles de
procédé dans le langage APEL

3.4.1 Demande/Réponse (request/reply)

Ce patron de communication est du type Synchrone. Dans ce patron, un expéditeur (sender)
envoie une requête à un récepteur (receiver) et attends une réponse avant de continuer dans le
procédé. Le patron du Demande/Réponse est représenté dans la Figure 47.

50
 requête
A B
(sender) (receiver)
réponse

Figure 47. Représentation du patron Demande/Réponse

Nous allons présenter le deuxième patron et après une représentation dans APEL et BPEL
pour les deux.

3.4.2 Unidirectionnel (one-way)

Dans ce patron de communication l’expéditeur envoie une requête au récepteur et attend en
réponse l’accuse de réception (acknowledge) de la part du récepteur. Ce patron est un cas
spécial du patron Demande/Réponse, il se différencie du patron Demande/Réponse
uniquement par le fait que le récepteur envoie sa réponse directement à la réception du
message de l’expéditeur. Le patron Unidirectionnel est représenté dans la Figure 48.
requête
A B
(sender) (Receiver)
réponse
(acknowledge)

Figure 48. Représentation du patron Unidirectionnel

L’expression du Demande/Réponse et Unidirectionnel en BPEL :

BPEL implémente ces deux patrons : Demande/Réponse du côté expéditeur et Unidirectionnel

du côté récepteur. Nous allons présenter en premier lieu la représentation pour
Demande/Réponse.

Pour représenter le patron Demande/Réponse, BPEL utilise le type d’activité invoke. Ce type
d’activité permet de représenter dans le procédé l’invocation d’une opération décrite dans le
fichier WSDL du service web correspondant (Figure 49). l’instance du type invoke dans le
procédé BPEL représente alors l’expéditeur et le fichier WSDL correspondant, représente le
récepteur.

51
 Figure 49. Exemple du patron Demande/Réponse en BPEL - représentation graphique et code BPEL
correspondant

Dans l’exemple illustré dans la Figure 49, l’instance du type nommée invoke-1 représente la
l’invocation de l’opération A qui a comme variable d’entré aRequest et comme variable de
sortie aResponse. L’opération A se trouve dans le port ejemDoc qui a comme « partner link »
le partnerLink. Rappelons que chaque port dans un fichier WSDL a un ou plusieurs
PartnerLinks ; chacun de ces PartnerLinks représente une partie avec laquelle le procédé
interagit.

Pour représenter le patron Unidirectionnel, BPEL utilise un couple d’activités du côté

récepteur, la première est du type receive et la seconde est de type reply. La Figure 50 illustre
un exemple de ce patron.

Figure 50. Exemple de Unidirectionnel en BPEL - code BPEL correspondant

La Figure 50 présente un exemple du patron Unidirectionnel en BPEL. Comme toujours, les

types d’activités représentent des opérations décrite dans le fichier WSDL correspondant.

L’expression du Demande/Réponse et Unidirectionnel en APEL :

52
Ce type de communication se fait au niveau des ports. Au moment de faire la conception, le
concepteur du procédé définis les flux de donnés qui lient les ports et transmettent les produits
entre les ports de sortie et les ports d’entré des activités. La Figure 51 illustre une
représentation en APEL du patron Demande/Reponse .

Figure 51. L’expression du Demande/Réponse en APEL

En tenant compte dont dans la Figure 51, l’activité B est une activité qui peut être représenter
comme un récepteur, la communication entre ces deux activités est établi avec l’aide des ports
asynchrones sur l’activité A (qu’on peut considérer comme l’expéditeur) . L’activité A envoi
le produit aRequest à l’activité B qui après donne le produit aResponse comme résultat de son
exécution.

Pour représenter le patron Unidirectionnel dans APEL on peut utiliser le même formalisme.
Dans ce cas, le produit aResponse est un produit qui ne contient rien et il sert seulement pour
indiquer que le premier produit a été reçu (aRequest).

3.4.3 Synchronous Polling

Ce patron représente une communication synchrone où un expéditeur envoie une requête à un
récepteur mais le procédé ne s’arrête pas pour attendre la réponse, il continue son exécution.
Après un certain intervalle de temps, l'expéditeur vérifie si il a reçu une réponse; si il détecte
une réponse, il la traite et arrête tout autre demande de réponse. Le patron Synchronous
Polling est représenté dans la Figure 52.

receiver
Synchrone

requête réponse

A
B C
(sender)

Figure 52. Représentation du patron Synchronous Polling

53
La Figure 52 illustre le patron Synchronous Polling. La communication synchrone est réalisé
sur l’activité A.

L’expression Synchronous Polling en BPEL :

Pour implémenter ce patron BPEL utilise 2 flux parallèles : un flux pour la réception de la
réponse prévue (activité Receive), et un deuxième flux pour la séquence des activités qui ne
dépendent pas de cette réponse (activité Sequence). La Figure 53 illustre un exemple de ce
patron.

Figure 53. Exemple de Synchronous Polling en BPEL

Pour démarrer le patron l’activité invoke A est utilisé pour commencer le procédé en envoyant
des données sans attendre une réponse. L’autre branche du flow reste en exécution et quand
un réponse pour l’invoke A arrive, l’activité receive A traite le message qui vient comme
réponse. De cet manière BPEL peut supporter ce patron. La codification BPEL est présenté
dans la Figure 54.

54
 Figure 54. Exemple de Synchronous Polling en BPEL - code BPEL correspondant

Dans la Figure 54, la variable de sortie (outputVariable) du premièr invoke n’est pas définie,
de cette manière au moment de l’exécution n’attend pas un réponse immédiate. La séquence
des activités qui ne dépendent pas de la réponse, sont imbriqués dans le type sequence à
l’intérieur du flow.

L’expression du Synchronous Polling en APEL :

La Figure 55 illustre la représentation du patron Synchronous Polling en APEL.

Figure 55. L’expression du Synchronous Polling en APEL

Au moment de l’exécution de l’activité A elle envoi pour un port asynchrone le produit

aRequest à une autre activité (Receiver) sans attendre une réponse. Le procédé continue pour
une branche sur les activités B et C et dans l’activité synchronous pour l’autre. Cette activité
attend le produit aResponse quand il sera donné pour l’activité Receiver. Le procédé a un
point de synchronisation dans le port begin de l’activité D. De cette manière APEL peut
implémenter le patron Synchronous Polling.

3.4.4 Message Passing

Ce patron est une communication asynchrone dans laquelle une demande est envoyée d’un
expéditeur à un récepteur. La différence entre ce patron et le patron Demande/Réponse est la
suivante : dans le patron Message Passing, lorsque l'expéditeur envoie sa demande, il ne s’en
occupe plus du tout (il oublie complètement qu'il a envoyé une demande) et il continue
l’exécution du procédé. Le patron Message Passing est représenté dans la Figure 56.

receiver
Asynchrone

requête réponse

A
(sender) B C

55
 Figure 56. Représentation du patron Message Passing

La Figure 56 illustre le patron Massage Passing. Dans le cas de la figure, la communication

asynchrone est menée à bien dans l’activité A.

L’expression du Message Passing en BPEL :

La représentation de ce patron en BPEL est la même que celle du patron Synchronous Polling
présentée dans la Figure 53 où la première instance du type invoke a seulement une variable
d’entré (inputVariable). Dans ce cas il n’existe pas l'attente à la réponse (synchronisation) et
il est par ceci pour représenter ce patron, on ne joindre pas l’activité receive. La Figure 57
présente la codification BPEL pour ce patron.

Figure 57. Code BPEL correspondant au patron Message Passing

Dans la figure on peut noter la définition du type invoke_1 seulement avec la définition d’une
variable d’entré. Et aussi, sans la définition de l’activité receive de la Figure 54 à l’intérieur
du flow.

L’expression du Message Passing en APEL

Il n’existe pas une représentation directe de ce patron en utilisant le langage APEL

3.4.5 Publication/Abonnement (publish/subscribe)

Dans ce patron de communication asynchrone une requête est envoyée par l’expéditeur, et le
récepteur est sélectionné par une déclaration d’intérêt inscrite par l’expéditeur dans la requête
envoyée. Le patron Publication/Abonnement est représenté dans la Figure 58.

56
 B
(receiver)

A Gestion des
(sender) Messages

C
(receiver)

Figure 58. Représentation du patron Publication/Abonnement

La Figure 58 illustre le patron Publication/Abonnement. L’expéditeur A envoi une requête

avec une déclaration d’intérêt. Le système de Gestion des Messages est chargé de trouver le
récepteur correspondant à la requête et gérer la réponse à l’expéditeur.

L’expression du Publication/Abonnement en BPEL :

Il n’est pas possible d’exprimer ce patron en utilisant le langage BPEL.

L’expression du Publication/Abonnement en APEL

Il n’existe pas une représentation directe de ce patron en utilisant le langage APEL

3.4.6 Diffusion (broadcast)

Dans ce patron-là, une requête est envoyée à tous les participants (tous les récepteurs) d’un
réseau. Chaque participant détermine si cette demande l'intéresse en examinant son contenu.
Le patron de Diffusion est représenté dans la Figure 59.

B
(receiver)
A
(sender)
C
(receiver)

D
(receiver)

Figure 59. Représentation du patron Diffusion

La Figure 59 illustre le patron Diffusion. L’expéditeur A envoi une requête est envoyée à
tous les récepteurs, dans le cas de la figure B, C et D

L’expression du Diffusion en BPEL :

Il n’est pas possible d’exprimer ce patron en utilisant le langage BPEL.

57
L’expression du Diffusion en APEL
Il n’existe pas une représentation directe de ce patron en utilisant le langage APEL

Dans cette section nous avons présenté les patrons pour la communication et nous avons fait
une analyse de la manière dans laquelle les deux langages APEL et BPEL gèrent ces patrons.
Nous avons vu que BPEL implémente quatre des six patrons avec son formalisme, sans
pouvoir exprimer les patrons : Publication/Abonnement et Diffusion.

D'autre part, en utilisant le langage APEL, n’existe pas une représentation directe pour les
patrons : Unidirectionnel, Synchronous Polling, Message Passing, Publication/Abonnement,
Diffusion. La représentation du patron Demande/Réponse sera utilise, para la suite comme la
base pour établir communications entre les activités APEL et des opérations de services web.

Nous allons présenter dans la section suivante autre comparaison entre ces deux langages.
Dans ce cas, nous allons présenter la manière dans laquelle APEL et BPEL font la
représentation des données. Nous allons présenter les caractéristiques et les concepts que
chaque langage utilise pour exprimer les liens entre les activités à travers données.

3.5 Modèle de données

Dans cette section, nous allons présenter une comparaison du point de vue des données. Les
données sont la représentation des objets transmis entre les activités. Dans APEL ces objets
correspondent aux produits et dans BPEL ils correspondent aux variables.

Pour comprendre le modèle de donnés de chacun de ces deux langages, nous présentons dans
ce qui suit une analyse des produits dans APEL, puis des variables de BPEL.

3.5.1 Modèle de données d’APEL

Dans les procédés APEL, les donnés sont appelées les "produits", ils se transmettent entre les
activités du procédé. Au moment de la modélisation d’un procédé APEL, l'existence d’un
produit n’est connue qu’à travers son nom. La définition du produit et de sa structure (ses
attributs) se trouvé dans autre domaine, le domaine des produits.

Le domaine des produits contient un éditeur : le Product Domain Editor, qui permet de créer
et éditer les types de produits. Chaque type de produits créé par cet éditeur est contenu dans
un fichier XML décrivant la structure de ce type.

Un type de produits est soit une Enumération soit une Structure :

- Un type de produit de la catégorie Enumération est constitué d’une liste de valeurs.
- Un type de produit de la catégorie Structure est constitué d’autres types (ce qui veut
dire que le type est complexe). Les types complexes peuvent contenir des éléments
simples (chaînes de texte), des éléments de type Enumération, des éléments de type
Structure, ou des référence à d’autre types (déjà définis).

58
Les attributs des types de produits ont les propriétés suivantes :
- versionable, pour indiquer le produit peut avoir plusieurs versions pendant
l’exécution. Cette propriété est très importante pour le procédé;
- isKey, si l’attribut est un identificateur du produit ;
- mandatory si l’attribut est obligatoire ;
- read-only si l’attribut est de lecture seule ; et
- isList si l’attribut correspond à une liste de valeurs.

La Figure 60 présente un exemple permettant de comprendre le concept d’attribut

versionable. Dans cet exemple, nous avons un produit inA entrant dans l’activité A. Cette
activité le transforme vers un nouveau produit outA contenant la propriété versionable. Ce
produit est envoyé ensuite vers les activités B et C.

Figure 60. Utilisation des produits APEL avec éléments versionables.

La propriété versionable permet de créer deux versions du produit, afin d’envoyer une version
par activité. Ainsi, si l’activité A (Figure 60) modifie sa version du produit, cette modification
n’affectera pas la version du produit contenue dans l’activité C.

Si l’attribut ne contient pas la propriété versionable, le produit outA est alors commun aux
deux activités. Les modifications que fera l’activité B sur le contenu de ce produit seront donc
faites également sur le produit de l’activité C, et inversement.

3.5.2 Modèle de données de BPEL

Pour maintenir l'état d'un procédé l'utilisation des variables d'état s’impose. Ces variables
d'état dans BPEL s'appellent tous simplement "les variables". Les variables contiennent les
messages (les donnés) constituant l'état du procédé BPEL. Les variables sont typées, les types
de variables peuvent être des types de message WSDL, des éléments ou des types simples de
XML Schema. [ACD 03].

Les variables peuvent être locales ou globales. Pour définir des variables locales dans BPEL
nous utilisons l’élément scope qui est un type d’activité BPEL permettant de définir des
variables dont la valeur est visible uniquement à l’intérieur du champ scope auquel ils
appartiennent (ainsi que dans les champs scopes imbriquées). Cependant, pour définir des
variables globales, il faut les déclarer au début du procédé. La Figure 61 illustre une
représentation graphique et textuelle du type d’activité scope.

59
 <scope name="scope" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<variables>
<variable name="x" type="xsd:int"/>
<variable name="y" type="xsd:string"/>
</variables>
<invoke name="A1"/> ...
<invoke name="A2"/> ...
</scope>

Figure 61. Activité et codification BPEL pour le type scope.

La Figure 61 présente un exemple d’utilisation du type scope. Ce type d’activité contient les
éléments :
- name pour définir le nom de l’instance de l’activité ;
- xmlns pour définir l’espace de noms d'où proviennent les définitions de variables ; et
- une balise variables, qui contient tous les variables déclarées dans le scope et
- l’ensemble des activités qui utiliseront ces variables.

Pour l’initialisation des variables, BPEL utilise le concept d’affectation à travers le type
d’activité assign. Ce type d’activité permet de copier la valeur d’une variable dans une autre,
ainsi que construire et insérer des nouvelles valeurs en utilisant des expressions. Pour qu'une
affectation soit valide, les données visées doivent être de types compatibles, les types
appartenant aux messages WSDL et aux éléments du XML schéma doivent donc être pris en
considération. La Figure 62 illustre une représentation graphique et textuelle du type
d’activité assign.

<assign name="assign-1">
<copy>
<from variable="input" part="payload"></from>
<to variable="output" part="payload"/>
</copy>
<copy>
<from expression="bpws:getVariableData('Y')"></from>
<to variable="X"/>
</copy>
</assign>

Figure 62. Activité et codification BPEL pour le type assign.

La Figure 62 illustre une affectation en utilisant le type d’activité assign. Ce type d’activité
contient les éléments :
- name, pour définir le nom de l’instance de l’activité et
- plusieurs élément copy, qui contient les éléments <from> et <to>

Le premier copy de l’exemple est une affectation entre deux variables qui du même type qui
sont dans ce cas-là des messages WSDL. Le deuxième copy présente une affectation à l’aide

60
d’une fonction (getVariableData) pour obtenir en premier temps la valeur de la variable Y
et l’affecter par la suite à la variable X.

Le traitement de données dans BPEL contient un autre élément important : les expressions.
BPEL utilise différents types d’expressions :

- les expressions de valeur booléenne (pour les conditions utilisées dans les types switch
et while) ;
- les fonctions (comme celle que nous avons présenté dans l’exemple de la figure 3) ; et
- les expressions Deadline-valued (fait référence aux types dateTime or date du XML
Schema) et Duration-valued (fait référence au type duration du XML Schema) [ACD
03].

Dans environnements de concurrence, les valeurs des variables dans BPEL restent
indépendants, similaire au cas qui a été présenté dans la Figure 60 pour APEL. La Figure 63
nous présentons une réalisation similaire dans BPEL.

Figure 63. Exemple d’affectation dans BPEL.

Dans le cas de la Figure 63, une activité assign est utilisée pour initialiser une variable. Au
moment de commencer le flow, la valeur de la variable est donnée à deux activités parallèles
qui modifient sa valeur (chacune de manière différente). la variable est ensuite récupérée en
entrée par l’activité invoke D. La valeur de cette variable est l’une des deux affectations ; si le
flux passe par le premier assign, c’est le résultat de son exécution qui représentera la valeur
récupérée par l’activité D, et pareillement si le flux de contrôle passe par le deuxième assign.
Cependant, les valeurs à l’intérieur de chaque assign restent indépendantes l’une de l’autre.

Si nous faisons la comparaison entre ce cas concernant BPEL (Figure 63) et le cas précédent
concernant APEL (Figure 60), nous pouvons conclure que BPEL implémente des copies des
variables dans les environnements de parallélisme pour obtenir une indépendance dans chaque
lien de contrôle. D'une autre part, APEL supporte, pas seulement ce type d’indépendance,
mais aussi l’utilisation du même produit si lui ne contient pas un attribut versionable.

Dans cette section nous avons présenté la manière de constituer une modélisation de donnés
en APEL et en BPEL.

Pour APEL, nous avons montré les propriétés qu’ont les types dans le domaine des produits.
Un produit dans APEL est une information qui est produite, transformée et consommée par
une activité d’un procédé. nous avons également présenté un cas d’utilisation pour les
attributs versionables.

61
Pour la partie BPEL, nous avons présenté la représentation des donnés dans ce langage en
utilisant le concept de variable. Nous avons présenté aussi, des exemples pour montrer
l’utilisation des autres concepts comme la portée et l’affectation.

3.6 Conditions au moment de transformer

Les activités dans le domaine d’APEL sont considérées comme une étape du procédé au cours
de laquelle une action est exécutée. Au moment de l’exécution d’un procédé, les activités
réunissent une partie de fonctionnalité de tout le procédé ensemble, elles peuvent représenter
des actions menées à bien soit pour les humains (révision ou correction des documents, par
exemple) ou soit par une application (qui consomme un produit et donne d’autre produit).
Dans APEL, tout le procédé est vu comme une grande activité composée qui s’appelle
ActivityROOT.

Du côté BPEL, les activités correspond à une type prédéfini. Par exemple types d’activités
comme invoke font référence à une appelle à un service web ; un type while indique la
répétition de certaines activités selon une condition, et ainsi suite. Par conséquent, dans BPEL
chaque type d’activité a son propre sémantique prédéfinie avec ses conditions et restrictions.

Trouver les correspondances entre un langage et l’autre n'est pas une tâche facile. On a
commencé pour faire une comparaison entre les deux langages avec l’aide des patrons : les
patrons de contrôle de flux et les patrons pour la communication dans langages de
Workflow14. Ensuite, avec l’analyse des différents fichiers de deux côtés : fichiers XML et
fichiers WSDL, ont été trouvés les correspondances pour, dans un premier approche,
représenter les attributs APEL dans BPEL.

Dans les pages suivantes, nous voulons présenter certaines points qui sont importants de tenir
compte pour une transformation vers BPEL. A partir de l’analyse fait entre les deux langages
avec l’aide des patrons et la comparaison du traitement des données, nous présentons ensuite
certaines conditions qui doivent avoir les procédés décrits en APEL et vouloir les transformer
comme un procédé BPEL. Ces conditions ont été prises en considération aussi pour le
développement de notre premier prototype qui fait cette transformation automatiquement.

Chaque point donne quelques restrictions et conditions pour avoir une transformation la plus
claire possible.

3.6.1 Pour les activités en général.

APEL est un langage dont le modèle de flux de contrôle est basé sur la sémantique des
graphes dirigés. Ce type de graphe et représente en nœuds et liens. APEL représente un nœud
comme une activité tandis qu’un lien correspond à un flot de données.

Avec cette prémisse, dans le modèle d’APEL, les flots de données d’une activité quelconque
peuvent communiquer avec d’autre activité sans restriction. Dans cette manière-là, un

14
Plus d’information sur [AHK 00]

62
procédé APEL peut générer des structures de boucles non-structurés. La Figure 64 présente
des exemples qui donnent une idée de cet avantage.

Partie a.

Partie b.

Figure 64. Exemples des scénarios possibles dans APEL.

La partie a de la Figure 64 présente un exemple d’un procédé qui permet au moment de

l’exécution de l’activité B avoir une décision par rapport auquel port, le procédé doit
continuer : soit le port end le procédé suivre avec l’activité C, soit le port end2 le procédé
revient sur l’activité A. La partie b présente un exemple avec une exécution un peu différent.
Dan ce cas, il y a un flot de donnée qui permet une fois l’activité A finisse, y revient sur elle-
même. Ce le lien entre le port de sortie end2 et le port d’entrée begin.

En revanche, du côté BPEL il existe des activités pour représenter des constructions
structurées dans ses procédés. Chaque type d’activité reçoit un message (avec ne structure
prédéfinit) le traite, selon la sémantique du type et le procédé continue avec le suivant type
décrit par le procédé. BPEL ne supporte pas le retour du flux de contrôle sur une activité qui a
terminé déjà son exécution ou sur elle-même. Sauf en utilisant types d’activités pré-définies
pour cet objective. La Figure 65 présente des exemples avec cet structurés.

Partie a.

Partie b.

Figure 65. Exemples des scénarios possibles dans BPEL.

Dans la partie a. de la Figure 65 se présente le cas dont une instance du type while contient
une exécution pour l’activités A en représentant une structure de boucle sur cette activité. La

63
exécution du procédé continue sur l’activité B, quand la exécution de while finisse. La partie
b. de la même figure présente une structure de décision para rapport à une condition. Le type
d’activité switch fournit des éléments <case> et <otherwise> qui permet structurer les
différents options pour continuer dans le procédé.
Selon les caractéristiques présentées dernièrement, au moment de faire une transformation
d’un procédé APEL vers un procédé BPEL, on doit tenir compte des restrictions suivantes.

Les activités du procédé APEL ne peuvent pas communiquer ses ports de sortie avec
ses ports d’entrée.

Les activités du procédé APEL ne peuvent pas retourner sur des activités que ont été
fini.

3.6.2 Pour les ports d’une activité.

Les activités dans APEL supportent plusieurs ports de sortie et d’entré. Chaque port reçoit les
produits d’un ou plusieurs flots de données. Quand un port contient tous les produits qui
attend il peut transmettre les produits vers le cible correspondant à travers les flots de
données. La Figure 66 présente des exemples d’utilisation de ports.

Partie a.

Partie b.

Figure 66. Exemples des ports dans activités APEL.

La partie a. de la Figure 66 présente le cas dont lequel une activité a plus d’un port d’entrée :
l’activité C reçoit par le port begin1 le produit outA et par le port begin2 le produit outB.
L’activité C s’active au moment qu’un de ses deux ports reçoit le produit correspondant.
Après son exécution se vérifie si il y a des produits dans l’autre port pour faire l’exécution
autre foi (s’il y a le produit), sinon le procédé continue avec l‘activité D. C'est-à-dire, si le
premier produit qui arrive est le produit outB (port begin2), l’activité C s’exécute, une fois
l’exécution a terminé, elle vérifié si il y a des produits dans le port begin1, avec l’objective de
s’exécuter à nouveau (la activité C).

64
La partie b. présente le cas dont lequel une activité a plus d’un port de sortie. Dans ce cas
l’activité B a deux ports de sortie : le port end1 et end2, en représentant une décision pour la
continuation du procédé. Selon le produit qui sorte de l’activité B, inC ou inD, le procédé
continue par l’activité C ou D, respectivement. C’est le cas du patron Choix Exclusif présenté
dans la section de patrons de contrôle.

Du côté BPEL, le flux de contrôle du procédé au moment de l’exécution passe une seule fois
par chaque activité, sauf dans le cas de répétition (type d’activité while). C'est-à-dire, les
messages passent par l’instance d’une activité, ils sont utilisés et après le flux de contrôle
continue avec l’activité suivant.

Selon ces caractéristiques au moment de transformer un procédé APEL vers BPEL, nous
trouvons la restriction suivante.

Les activités du procédé APEL doivent avoir un seul port d’entrée et un seul de sortie.

Nous présenterons dans la chapitre suivante qu’il existe des exceptions pour cette restrictions,
comme la représentation d’un patron que nous avons défini comme CallWebService lequel
sera présenté en détail dans le chapitre suivant.

3.6.3 Pour les flots de données.

Tant les ports d’entrée comme ceux de sortie peuvent recevoir ou donner, respectivement,
plusieurs flots de données. La Figure 67 présente un exemple pour un port d’entrée.

Figure 67. Exemples des flots de données sur des activités APEL.

Dans l’exemple de la Figure 67, l‘activité D reçoit trois produits : outA, outB et outDesktop
qui viennent depuis les ports de sortie des activités A et B et depuis le port Desktop,
respectivement. Pour pouvoir exécuter l’activité D tous les trois produits doivent être dans le
port d’entrée.

En BPEL on peut représenter un port d’entrée, similaire à celui de l’activité D, comme le

point pour localiser la fermeture d’une instance de type flow, comme nous l’avons présenté

65
dans la section de patrons de flux15. Cette instance représente une synchronisation entre les
différents flots de données qui convergent.

Le flot de donné qui vient du port Desktop (Figure 67), représente que l’activité D demande
ce produit pour réaliser son exécution. Dans BPEL, il n'est pas nécessaire de rendre explicite
cette demande car on assume que la valeur de cette variable (les produits d’APEL seront
transformé dans variables BPEL pour notre outil) est disponible pour son utilisation par une
autre activité qui est dans le même portée. Cette considération sera expliqué plus en détail
dans le chapitre suivante.

Selon cette caractéristique il existe la restriction suivant, considéré pour réaliser notre
première approximation de transformation entre APEL et BPEL.

Les activités du procédé APEL dans ses ports d’entrée ne peuvent pas recevoir un flot
de données d’une activité et au même temps un flot de donnée du port Desktop.

3.6.4 Pour les activités composites.

Toutes les activités dans APEL peuvent contenir d’autres activités imbriquées. Ces types
d’activités sont nommées composite et au moment de créer le fichier XML, qui décrit le
procédé, il existe un élément qui donne cet information. La Figure 68 présente un exemple de
ce type.

La partie a. de la Figure 68 présente un procédé depuis la vue plus haute : l’intérieur de

l’activité ActivityROOT. Ce procédé contient les activités A, B et C. La partie b. de la même
figure présente l’intérieur de l’activité A, qui contient imbriquées les activités A1, A2 et A3.
La partie c. présente le code XML pour l’activité A créé par APEL où on peut noter l’élément
type qui indique que cette activité est composite.

Dans BPEL seulement les types d’activités nommées composées (sequence, switch, while,
flow, scope) peuvent contenir des autres activités imbriquées. Tous le reste d’activités (invoke,
assign, entre autres) sont considérées comme des activités simples (qui ne contient d’autres
activités imbriquées).

Selon ces caractéristiques au moment de la transformation il existe la condition suivant pour

notre outil.

Au moment de produire la codification BPEL pour les activités composites du

procédé APEL, chaque activité de ce type génère une instance du type sequence de
la codification BPEL.

15
Patron de Synchronisation.

66
 Partie a.

Partie b.
<activity name="A" instances="1" type="composite" responsable="default">
<port name="begin" type="in-sync">
<dataflow to-activity="A" from-port="Desktop" to-port="begin"> </dataflow>
</port>
<port name="end" type="out-sync">
<dataflow from-activity="A" to-activity="B" from-port="end" to-port="begin">
</dataflow>
</port>
<subactivity name="A1"/> <subactivity name="A2"/> <subactivity name="A3"/>
</activity>

Partie c.

Figure 68. Activité composite dans APEL

3.6.5 Pour les produits

Les produits dans APEL son locaux. C’est à dire, la valeur qui prennent reste valable
seulement dans l’activité dans laquelle sont utilisés. La Figure 69 présente un exemple.

La partie a. de la Figure 69 illustre un procédé avec deux activités A et B. La partie b.

présente les activités qui sont contenues dans la activité A et les produits dans le port Desktop
de cette activité (inA, tempA, outA). De manière similaire, la partie c. présente les activités et
le Desktop du B. Au moment de l’exécution la activité A fait usage du produit tempA qui est
définit à l’intérieur de A pour produire, dans l'ensemble avec A1 et A2, le produit outA. Un
cas similaire se fait à l’intérieur de l’activité B, dont le produit tempB est utilisé pour l’activité
B1 pour donner finalement à outB.

67
 Partie a.

Partie b.

Partie c.

Figure 69. Produits d’une activité APEL

Dans le cas de l’exemple les produits tempA et tempB sont connues seulement par les activités
qui les contiennent . C’est à dire, l’activité B ne connaît pas l’existence du produit tempA et de
la même manière que l’activité A ne connaît pas le produit tempB.

Les variables, du côté BPEL, fournissent les moyens pour tenir les messages qui constituent
l'état d'un procédé. Elles peuvent avoir un contexte globale ou locale. Selon la définition du
procédé, la section des variables représente l’ensemble qui seront utilisées dans tout le
procédé. Il existe un type d’activité composée nommé scope16 qui permet de définir des
éléments, entre eux des variables, pour les activités qui contiennent. La Figure 70 présente un
exemple.

Figure 70. Exemple pour variables BPEL locales et globales

16
Plus d’information sur [ACD 03].

68
La Figure 70 présente un procédé d’exemple avec deux instances du type scope. On peut
noter que l’exemple a une sémantique similaire à ce qui on a présenté pour APEL (Figure 69).
Dans le cas BPEL, les variables qui restent globales à tout le procédé sont : inA, outA et outB
(sont utilisables pour toutes les activités du procédé). Les autres (tempA et tempB de notre
exemple) sont utilisables seulement pour les activités qui se trouvent à l’intérieur du chaque
scope.

De ce manière, on peut transformé les produits du port Desktop comme variables qui sont
disponibles à l’intérieur des scopes du côté BPEL.

Au moment de produire la codification BPEL les produits qui se trouvent dans le

Desktop des activités APEL, peuvent être transformé en variables au niveau des
types d’activité scope.

Pour résumer, le Tableau 2 présente les conditions exprimées dans les pages précédentes, pour
transformer un procédé APEL vers un procédé BPEL qui garde un comportement similaire.
Ces conditions ont été prises en considération aussi pour le développement de notre premier
prototype qui fait cette transformation automatiquement.

Les activités du procédé APEL ne peuvent pas communiquer ses ports de

sortie avec ses ports d’entré.

Les activités du procédé APEL ne peuvent pas retourner sur des activités
que ont été fini.

Les activités du procédé APEL doivent avoir un seul port d’entrée et un seul
de sortie.

Les activités du procédé APEL dans ses ports d’entrée ne peuvent pas
recevoir un flot de données d’une activité et au même temps un flot de
donnée du port Desktop.

Au moment de produire la codification BPEL, pour les activités composites

du procédé APEL, chaque activité de ce type génère une instance du type
sequence de la codification BPEL.

Au moment de produire la codification BPEL, les produits qui se trouvent

dans le Desktop des activités APEL, peuvent être transformé en variables au
niveau des types d’activité scope.

Tableau 2. Conditions pour transformé des procédé APEL vers BPEL

69
Comme nous avons présente au début de ce chapitre, dans le test sur l’exécution d’un service
web, en APEL on peut ajouter de codification aux activités qui permet au moment de
l’exécution de l’activité, inclure des fonctionnalités. Nous avons utilisé cette caractéristique
pour faire l’appel au service web à travers AXIS. Nous n’avons pas tenu compte de cette
caractéristique pour le développement de notre premier prototype. Pour l’instant nous ne
trouvons pas d’équivalence dans BPEL car il ne support pas l’agrégation de code aux types
d’activités basiques.

70
 4. REALISATION DES PROCEDES APEL EN BPEL

4.1 Introduction

BPEL est un langage qui définit un modèle et un formalisme pour décrire le comportement
d’un procédé métier basé sur des interactions entre ce procédé et ses partenaires [ACD 03].
L’interaction avec chaque partenaire se produit à travers interfaces des services web. De ce
point de vue, BPEL est un langage qui permet de réaliser des orchestrations entre services
web, nous rappelons que le terme orchestration fait référence à l’enchaînement des services,
son façon d’interagir ensemble (au niveau des messages) et l’ordre d’exécution de ces
interactions.

L’avantage principal de faire une transformation depuis le formalisme d'APEL vers la syntaxe
du BPEL, est utiliser le niveau d’abstraction d’APEL pour pouvoir exprimer une coordination
à haut niveau entre les différents éléments qui font une partie d’un procédé métier. APEL peut
coordonner toute sorte de logiciels, mais dans ce contexte là nous nous limitons aux contexte
de services web qui est sur lequel est fondé BPEL.

Pour pouvoir faire la traduction d’un procédé APEL vers un procédé BPEL, nous avons
besoin de trois éléments :

• Le modèle de procédé écrit en APEL, ce modèle de procédé doit contenir le Modèle des
Activités et le Modèle des Produits. Ces modèles sont décrits dans le format XML.

• Les fichiers WSDL décrivant les services web coordonnés par le procédé.

• Un modèle qu’indique comment s’initialisent les produits dans le desktop de chacune des
activités du modèle de procédé APEL, et aussi pour indiquer les conditions qui seront
évaluées dans les nouveaux types d'activité qui seraient créés pour supporter la
transformation17.

A partir de ces fichiers et en utilisant un ensemble de patrons (que nous allons présenter par la
suite dans ce chapitre), notre outil de transformation doit construire un fichier de type .bpel
contenant le procédé BPEL correspondant.

Nous allons présenter dans ce chapitre, la façon dans laquelle notre outil de transformation
produire le fichier .bpel. En premier lieu, une analyse pour obtenir des informations
nécessaires à partir des fichiers WSDL qui participant dans le procédé. Ensuite, nous
décrivons comment produire l’information pour les section générales du ce fichier.
Finalement, pour la section d’orchestration, quelles sont le patrons avec ses hypothèses
tenaient en compté pour cette première approximation de transformation.

17
Ce modèle est produit d'une analyse de demandes au moment d'effectuer la transformation entre des produits
APEL et variables BPEL. Il se trouve actuellement en phase de définition à l'intérieur de notre équipe.

71
4.2 Construction des wrappers pour des fichiers WSDL

Les fichiers WSDL contiennent une caractéristique importante pour l’expression du procédé
dans le langage BPEL, cette caractéristique est la définition des partnerLinkTypes.
Un partnerLinkType fournit une relation de conversation entre deux services à partir de la
définition des rôles et de la spécification du portType [ACD 03]. Cette information sera
utilisée pour construire la section <partnerLink> du fichier BPEL.

Cependant, le fichier WSDL peut ne pas contenir une définition des partnerLinkTypes. A ce
moment là, notre outil de transformation doit générer un fichier wrapper, qui contient la
définition de ce partnerLinkType. Cela nous évite de modifier le fichier WSDL original. Pour
réaliser ce fichier wrapper, notre outil doit effectuer une analyse de chaque fichier WSDL,
pour obtenir certaines informations qui seront introduites dans ce fichier. Un exemple du
fichier généré est présenté dans Code 1.

<?xml version="1.0" encoding="utf-8"?>

<definitions
targetNamespace="(1)"
xmlns:tns="(1)"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">

<import location="file:(3)"/>

<plnk:partnerLinkType name="(4)">
<plnk:role name="(5)">
<plnk:portType name="tns:(2)"/>
</plnk:role>
</plnk:partnerLinkType>
/

Code 1. Codification générée comme wrapper pour les fichiers WSDL

Les valeurs identifiées pour (1), (2) et (3) dans Code 1, sont recherchées dans le fichiers
WSDL de la manière suivante :

• la valeur de l’élément targetNamespace à partir de la balise <definitions> (valeur

introduite dans le fichier au numéro 1, Code 1) ;

• la valeur de l’élément name A partir de la balise <portType> (valeur introduite dans le

fichier au numéro 2, Code 1) ;

• l’adresse physique du fichier WSDL (introduite dans le fichier au numéro 3, Code 1).

A partir de l’information obtenue dans le point (2), notre outil produire l’information pour (4)
et (5), comme cet exemple : si notre outil obtient pour (2) la valeur « airline » alors
l’information dans (4) et (5) sera « airlineLinkType » et « airlineProvider » respectivement.
Ces suffixes sont utilisés dans la spécification [ACD 03].

Pour nommer ce nouveau fichier généré, nous utilisons le nom du fichier WSDL en ajoutant
le suffixe Wrapper, l’extension de ce fichier sera également la même : .wsdl (par exemple, si
le fichier WSDL se nomme airlineService.wsdl, le fichier généré s’appellera
airlineServiceWrapper.wsdl).

72
4.3 Sections générales du fichier BPEL

Nous avons vu dans le chapitre 2 (État de l’art) que le fichier BPEL contient quatre sections:
la section attributs supérieurs, la section partnerLinks, la section variables et la section
d’orchestration.

Nous allons présenter dans cette section comment notre outil de transformation obtient
l’information pour construire les trois premières sections.

4.3.1 La section des attributs supérieurs

Dans cette partie l’outil récupère des informations générales pour produire une codification
qui a la structure présentée dans Code 2

<process name="" targetNamespace="http://lsr-adele.fr/samples/"

suppressJoinFailure="yes"
queryLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"
expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:tns="http://lsr-adele.fr/samples/"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

Code 2. Codification pour la section des attributs supérieurs du fichier BPEL

Le Code 2 correspond aux attributs supérieurs du fichier BPEL qui notre outil produit. Tous
les éléments correspondent aux espaces de noms, sauf les éléments name, targetNamespace.
La définition de ces espaces de noms provient de la spécification BPEL [ACD 03]. La partie
name pour l’instant correspond au même nom du procédé APEL. Et pour targetNamespace
nous avons fixé une valeur constant (http://lsr-adele.fr/samples/).

4.3.2 La section des partnerLinks

Pour construire cette partie, l’outil récupère l’information correspondante au partnerLink de

chaque participant à partir du fichier WSDL, ou bien à partir du fichier wrapper créé au début
de la transformation lorsque le WSDL ne contient pas cette information.

Cette information est ensuite insérée dans le fichier BPEL que l’outil génère. Le Code 3
illustre la structure suivant laquelle l’information correspondante à un partnerLink sera
insérée dans ce fichier BPEL.

<partnerLink name="" partnerLinkType="ns:" partnerRole=""/>

Code 3. Codification pour la section des partnerLinks du fichier BPEL

Le Code 3 présente la codification pour la section des partnerLinks, qui l’outil produit.

73
4.3.3 La section des variables.

Chaque fichier WSDL qui participe dans le procédé génère un espace de noms XML (xmlns)
dans le fichier BPEL, la valeur pour ces espaces de noms provient de chaque fichier WSDL.
Cet information est joindre à la partie généré dans la section d’attributs supérieurs. De cette
manière là, la définition des attributs supérieurs est complète.

Il existe une correspondance des noms entre le modèle d’activités qui utilise les types décrits
dans le modèle de produits d’APEL et aussi entre ce modèle de produits et les messages et les
éléments XML Schema décrits dans le fichier WSDL. Dans la section suivante, nous
expliquons en détail, cette relation.

La codification à produire pour la section des variables doit être la structure qui illustre le
Code 4.

<variable name="" messageType="ns:"/>

<variable name="" element="ns:"/>

Code 4. Codification pour la section des partnerLinks du fichier BPEL

La valeur pour la partie "name" est obtenu, à partir du nom du produit dans le modèle APEL.
La partie "messageType" ou "element" correspond au type dans le modèle des produits
APEL.

Suivant la position, une variable pour le fichier BPEL peut être "messageType" ou
"element". Ce définition dépend de la localisation dans le fichier WSDL : soit dans la
section de <message> (dans ce cas on définie la variable BPEL avec messageType) soit dans
la section de <element> (dans ce cas on définie la variable avec element.

4.3.4 Synthèse et hypothèses

Nous avons présenté dans ce qui précède plusieurs élément du fichier BPEL généré par notre
outil. Ces éléments nous donnent un fichier BPEL avec la structure des attributs supérieurs,
partnetLinks et variables.

Pour obtenir ces résultats nous avons fait l’hypothèse d’avoir sous la main :

• Le fichier XML créé par APEL contenant le modèle du procédé ;

• Les fichiers WSDL décrivant les services web participants dans le procédé APEL ;
• les fichiers wrapper généré par notre outil lorsque les fichiers WSDL ne contiennent
pas la définition des partnerlinkType.

Nous avons également fait l’hypothèse qu’il y a une correspondance de noms entre les
produits utilisés dans le modèle d’activités APEL, les types des produits définis dans le
modèle de produits et le nom des messages et/ou des éléments XML Schema des fichiers

74
WSDL. Cette hypothèse a été fait pour la section des variables du BPEL. La Figure 71 illustre
cette relation.

Modèle d’activités.

Activités et liens entre eux.

Modèle des produits

Description des types des produits.

Fichier WSDL

Description des messages et éléments

Figure 71. Relation entre les Modèles d’Activités et de Produits et les fichiers WSDL

La relation présenté dans la Figure 71 indique que le même nom de message ou d’élément
(côté WSDL) doit être utilisé comme nom de type de produits (côté APEL). De cette manière
là, le modèle de produits APEL utilise ces types de produits qui décrivent à leur tour les types
présentés par le fichier WSDL.

Nous allons maintenant présenter la section d’orchestration du fichier BPEL. Pour cela, nous
avons identifié plusieurs correspondants à l’orchestration. Nous allons présenter chacun de
ces patrons ainsi que les hypothèses que nous avons fait pour réaliser ce patron.

4.4 Section d’orchestration du fichier BPEL

Pour présenter les patrons identifiés en la transformation de APEL vers BPEL, nous illustrons
la représentation du côté APEL, les hypothèses réalisées et finalement la codification BPEL
correspondant.

75
Avant d’introduire les patrons de représentation, nous définissons le concept de type d’activité
APEL qui sera utile pour identifier quelques patrons au moment de la transformation.

Un type d’activité APEL est un activité qui offre une formalisme graphique et une structure
de codification associé, avec l’objectif de produire une sémantique d’exécution différent que
pour le type d’activité actuel d’APEL. Les types identifiés pour l’instant son le type
CallWebService, le type If et le type While. Ces types correspondent aux patrons qui seront
présentés dans cette section.

4.4.1 Le patron CallWebService

Il permet d’avoir un type d’activité pour appeler une opération d’un service web. Il nous faut
deux activités : une qui sera nommé l’activité appelante et l’autre nommé l’activité appelée.
L’activité appelante est chargée de fournir les produits nécessaires pour que l’activité appelée
effectue l’appel de l’opération du service web correspondant. La Figure 72 présente un
exemple des activités appelante et appelée.

Activité appelante :
Ports synchrones d’entrée et de sortie.

Ports asynchrones d’entrée et de sortie

Activité appelée :
Il existe un fichier qui s’appelle airline.wsdl avec
une opération qui s’appelle checkAvailability.

Figure 72. Représentation APEL pour l’appel à services web

Les deux ports asynchrones de l’activité appelante communiquent avec les ports de l’activité
appelée qui représente l’opération du service web.

Les hypothèses que nous avons fait pour réaliser ce patron :

• L’activité appelante est une activité simple.
• Le nom du fichier WSDL doit correspondre au nom du rôle du responsable de l’activité
dans le modèle APEL. Dans l’exemple de la Figure 72 nous supposons qu’il existe un
fichier nommé airline.wsdl qui correspond au responsable de l’activité checkAvailability.
• Tous les noms des rôles du modèle APEL correspondent aux noms des fichiers qui
participent dans le procédé (sauf default qui est un cas particulier).
• Les noms des activités appelées doivent être les mêmes que les noms des opérations dans
le fichier WSDL correspondant. Dans l’exemple de la Figure 72 le fichier airline.wsdl
contient une opération nommée checkAvailability.
• Chaque activité peut faire des appels destinées uniquement vers une seule opération d’un
seul fichier WSDL.

En utilisant ces hypothèses, l’outil peut produire la codification BPEL pour les activités de ce
patron. Le Code 5 illustre la codification BPEL des activités de la Figure 72.

76
 <invoke name="tripOrder" partnerLink="partner" portType="ns0:airlinePort"
operation="checkAvailability" inputVariable="entryType" outputVariable="exitType"/>

Code 5. Codification BPEL pour le patron CallWebService d’APEL

4.4.2 Le patron While

Il permet d’avoir un type d’activité qui exécute des boucles structurées. C’est un type
d’activité composite avec un port d’entré nommé begin, et un port de sortie nommé end. A
l’intérieur de cette activité, il y a une activité nommé corps, qui contient les activités
exécutées en boucle. L’activité corps est un type d’activité composite fournissant les produits
nécessaires pour construire la boucle, elle a également deux ports : begin et end. La Figure 73
illustre la représentation de ce patron.

Partie a. Représentation
externe.
Partie b. L’intérieur
d’activité WhileVerifySeats.

Partie c. Les activités qui

font partie de la boucle

Figure 73. Représentation APEL pour le type While

Dans l’exemple de la Figure 73, l’instance du While démarre avec en entré les produits
itinerary et preferences et lorsqu’elle termine, elle doit produire en sortie le produit out (Partie
a. de la figure). A l’intérieur de cette instance nous voyons apparaître les produits qui entrent
dans l’activité par le port begin et qui seront déposés dans le desktop de cette activité de la
même manière les produits qui sortent; l’activité corps, contient les activités de la boucle
(partie b). Les activités faisant partie de la boucle dans l’exemple de la Figure 73 sont des
activités simples, elles prennent les produits du port desktop de l’activité corps.

Les hypothèses que nous avons fait pour réaliser ce patron :

• L’activité While a deux ports synchrones, nommés begin et end.
• Tous les produits dont l’activité While a besoin pour démarrer doivent être dans son port
begin au moment de commencer.

77
• Le nom de l’activité dans APEL n’e doit pas nécessairement être While. L’éditeur
d’APEL doit fournir dans son formalisme graphique une option permettant de représenter
ce type de patron. Ainsi, dans le fichier XML du procédé décrit en APEL, il y aurait un
nouvel élément patternType dans la balise activity,, pour indiquer le patron de l’activité
(While dans le cas de cet exemple).
• L’activité corps fournit le(s) produit(s) de sortie de l’activité du type While au port
desktop de cette activité (Figure 73, partie b). il y a ensuite un flot de données qui permet
porter ces produits au port end de l’activité While.
• La condition pour contrôler les itérations des activités se trouve dans un fichier .java qui
fait partie de l’ensemble de fichiers créés par APEL. La condition doit être fournie par le
concepteur (la personne qui construit le procédé) à partir d’une interface graphique au
moment de déposer l’instance de While dans l’espace de définition des procédés d’APEL.

En utilisant ces hypothèses, l’outil peut produire la codification BPEL pour les activités de ce
patron. Le Code 6 illustre la codification BPEL des activités de la Figure 73.

<while name="WhileVerifySeats"
condition="getVariableData(itinerary) < getVariableData (index)">
<sequence name="corps">
<receive name="VerifySeat"/>
<reply name="Agregation"/>
</sequence>
</while>

Code 6. Codification BPEL pour le patron While d’APEL

Lorsque notre outil trouve un patron While dans le fichier XML d’APEL, il produit un type
d’activité while dans le fichier BPEL avec une séquence nommée corps imbriquée dans cette
activité while. A l’intérieur de la séquence il mettra toutes les activités18 de la boucle et qui
seront exécutées tant que la condition est correcte (true). Pour la condition, il faut utiliser
une fonction propre à la spécification BPEL (getVariableData) pour accéder aux valeurs des
variables [ACD 03].

4.4.3 Le patron If

Le patron If définit un type d’activité ayant un comportement conditionnel dans un procédé.

Ce type d’activité se compose d’une activité simple avec un port d’entré, nommé begin et
deux ports de sortie nommés then et else. En temps d’exécution, le port de sortie choisi
dépend de la valeur de la condition, si celle-là est vraie (true) le procédé passe par le port de
sortie then pour continuer son exécution, sinon le procédé passe par le port de sortie else. La
Figure 74 illustre la représentation de ce patron.

18
L’instance du type while peut contenir un ou plusieurs activités de la spécification BPEL (invoke, reply,
receive, et d’autres).

78
 Figure 74. Représentation APEL pour le type If

Dans l’exemple de la Figure 74, l’activité ReserveTickets représente un type d’activité If.
Selon la condition sur le produit entrant trip, le flux de contrôle du procédé passe par le port
de sortie then et exécute l’activité BookTickets ou passe par le port de sortie else et exécute
l’activité CancelReserve.

Les hypothèses que nous avons fait pour réaliser ce patron :

• Les ports de l’activité If sont des ports synchrones.
• De manière similaire au patron While, dans le fichier XML du procédé décrit en APEL, il
nous faut l’élément patternType permettant d’indiquer le patron de l’activité (if dans le cas
de cet exemple).
La condition pour contrôler la décision se trouve dans un fichier .java (de manière similaire
au patron While). La condition doit être fournit par le concepteur (la personne qui construit le
procédé) à partir d’une interface graphique au moment de déposer l’instance If dans l’espace
de définition des procédés d’APEL.

En utilisant ces hypothèses, l’outil peut produire la codification BPEL pour les activités de ce
patron. Le Code 7 illustre la codification BPEL des activités de la Figure 74.

<switch name="ReserveTickets">
<case condition="getVariableData('trip') = 'check'"> <receive name="BookTickets"/>
</case>
<otherwise><receive name="CancelReserve"/></otherwise>
</switch>

Code 7. Codification BPEL pour le patron If d’APEL

Lorsque notre outil trouve un patron If dans le fichier XML d’APEL, il produit un type
d’activité switch dans le fichier BPEL contenant deux élément <case> et <otherwise>.
L’élément <case> représente le chemin à prendre lorsque la condition est vérifiée (true) ,
c’est à dire le chemin du port then dans le procédé APEL. Si la condition n’est pas verifiée
(false), le chemin emprunté est celui de l’élément <otherwise> qui correspond au port else
dans le procédé APEL. De manière similaire au patron While, pour la condition il faut utiliser
une fonction propre de la spécification BPEL (getVariableData) pour accéder aux valeur des
variables [ACD 03].

79
4.4.4 Le patron Sequence

Le patron Sequence permet de définir l’enchaînement séquentiel d’activités. La Figure 75

présente un exemple de ce patron.

Dans cet exemple, nous avons un enchaînement séquentiel des activités OrderTrip,
ReserveTickets et BookTickets. L’activité BookTickets s’exécute après l’exécution de l’activité
ReserveTickets, qui s’exécute après l’exécution de l’activité OrderTrip et ainsi
successivement.

Figure 75. Représentation APEL pour le patron Sequence

Les hypothèses que nous avons fait pour réaliser ce patron :

• Tous les activités ont deux ports synchrones : un port d’entré et un port de sortie.
• La communication ne se passe que dans un sens, les activités de la séquence ne peuvent
pas communiquer dans le sens inverse, Par exemple, dans la figure 4, nous ne pouvons pas
lier l’activité BookTickets par un flux de donnés à l’activité OrderTrip afin que celle-ci
s’execute de nouveau une fois que BookTickets est terminée.

En utilisant ces dernières hypothèses, l’outil peut produire la codification BPEL pour les
activités de ce patron. Le Code 8 illustre la codification BPEL des activités de la Figure 75.

<sequence name="ActivityROOT">
<receive name="OrderTrip"/> ...
<invoke name="ReserveTickets"/> ...
<invoke name="BookTickets"/> ...
</sequence>

Code 8. Codification BPEL pour le patron Sequence d’APEL

Dans le Code 8 représentant la séquence, nous remarquons que le nom de l’activité sequence
est le nom de l’activité d’APEL qui contient l’enchaînement des activités de la séquence.
Dans cet exemple-là nous supposons que les activités de la séquence sont contenues dans
l’activité ActivityROOT.

4.4.5 Le patron Parallèle

Ce patron permet de représenter les activités qui démarrent au même moment et qui
s’exécutent de manière concurrente. La Figure 76 présente un exemple de ce patron.

80
 Figure 76. Représentation APEL pour le type Parallèle

Dans cet exemple, les activités ReserveTickets et ReserveHotel démarrent au même moment
(lorsque l’exécution de l’activité OrderTrip se termine) et s’exécutent de manière
concurrente.

Les hypothèses que nous avons fait pour réaliser ce patron sont les même que celle que nous
avons faites pour le patron Séquence. Avec ces hypothèses, l’outil peut produire la
codification BPEL de ce patron. Le Code 9 présente la codification BPEL des activités de
l’exemple illustré dans la Figure 76.

Hypothèses
Les mêmes hypothèses que pour le patron Séquence

Avec ces hypothèses, l’outil peut produire la codification BPEL suivante pour les activités de
la Figure 76.

<receive name="OrderTrip"/> ...

<flow name="OrderTrip">
<secuence>
<invoke name="ReserveTickets"/> ... <invoke name="BookTickets"/> ...
</secuence>
<secuence>
<invoke name="ReserveHotel"/> ... <invoke name="PayRoom"/> ...
</secuence>
</flow>

Code 9. Codification BPEL pour le patron Parallèle d’APEL

Dans le Code 9 représentant le parallélisme, nous remarquons que le nom de l’activité flow
correspond au nom de l’activité qui spécifie le moment du démarrage des activités
concurrentes (qui est le moment où cette activité des termine). Dans le cas de l’exemple
illustré dans la Figure 76 et dans le Code 9 cette activité se nome OrderTrip.

4.5 Outil de transformation

Notre outil de transformation permet de « traduire » automatiquement de procédés réalisés

dans le formalisme APEL vers le formalisme BPEL.

81
L’objective de notre outil de transformation est de produire le fichier .bpel correspondant au
procédé APEL à partir des éléments décrits au début de ce chapitre. Pour cela, nous avons
divisé la transformation en deux parties :

1. Codification BPEL pour la section des éléments généraux.

2. Codification BPEL pour la section d’orchestration.

Nous allons présenter pour chaque section comment notre outil de transformation produit la
codification BPEL correspondant à partir d’un procédé APEL à partir des hypothèses des
sections .

4.5.1 Codification BPEL pour la section des éléments généraux

Comme nous l’avons présenté dans la section 4.3 le fichier BPEL (fichier avec l’extension
.bpel), contient trois parties dans la section des éléments généraux : les attributs supérieurs, les
partnerLinks et la section pour les variables. La Figure 77 illustre la façon de produire les
informations pour le fichier BPEL dans la section des éléments généraux.

Modèle d’activités.

Modèle d’activités – Fichier XML.

Outil de
transformation

Analyse pour Fichier

partnerLinks et BPEL
variables

Fichiers WSDL-Wrappers WSDL.

Outil de
transformation

Figure 77. Schéma de transformation APEL – BPEL Section des éléments généraux

Le processus de transformation commence avec la création des fichiers wrappers pour chaque
participant dans le procédé APEL, dans la section 4.2 nous présentons la structure de chaque
fichier wrapper. Ensuite avec le fichier XML créé par APEL Editor, au moment de la
représentation du modèle, l’outil de transformation fait une opération de parseur sur les deux
fichiers.

82
Nous rappelons que tant le fichier du modèle d’activités comme les wrappers WSDL sont de
fichiers XML. Après, cette opération et en utilisant la logique présenté dans la section 4.3,
notre outil faire l’analyse de transformation pour produire la premier partie du fichier BPEL.

4.5.2 Codification BPEL pour la section d’orchestration

A la codification BPEL généré dernièrement, nous ajoutons la codification BPEL pour la

section d’orchestration. Cette section est composée de la combinaison des types d’activités
propres du formalisme BPEL (invoke, sequence, et tous les autres). La Figure 78 illustre la
façon de produire les informations pour le fichier BPEL dans la section d’orchestration.

Modèle d’activité APEL.

Fichier BPEL

Modèle d’activités APEL – Fichier XML.

Outil de transformation

Représentation Analyse et Représentation

Parseur APEL identification BPEL
des patrons

Figure 78. Schéma de transformation APEL – BPEL Section des éléments d’orchestration

Dans cette partie le processus de transformation utilise le résultat de l’opération de parseur

réalisé dans la section précédente. Ensuite, notre outil de transformation fait une analyse de
chaque activité du modèle, pour identifier quel patron suivre et pouvoir construire la
représentation BPEL correspondant.

Cette opération est réalisée pour chaque activité qui présente le modèle du procédé APEL.

83
 5. CONCLUSION ET PERSPECTIVES
5.1 Conclusion

Nous avons vu que dans le domaine de l’implémentation de la coordination de services web,

le concept d’orchestration offre un canevas pour décrire comment plusieurs services
collaborent pour atteindre un objectif métier commun

Au niveau recherche, il existe des langages d’orchestration et des implémentations

commerciales de ces langages permettant d’exécuter des procédés basés sur le concept
d’orchestration. BPEL est une spécification qui représente un langage orienté à la
modélisation des procédés qui utilisent services web pour son implémentation. Néanmoins,
BPEL est un langage de bas niveau, proche des langages de programmation ce qui le rend
difficile à comprendre.

APEL est un langage qui avec son formalisme centré activités, permet de modéliser toute
sorte de procédés. Ce langage est le résultat de plusieurs années de recherche dans le domaine
du Génie Logiciel Industriel. Nous proposons d’utiliser APEL pour modéliser des procédés
au niveau conceptuel et profiter les avantages d’un moteur d’orchestration BPEL pour réaliser
son exécution.

Les modèles de procédé décrits en APEL sont beaucoup plus facile à comprendre que ceux
décrits en BPEL. La représentation en APEL est une représentation de haut niveau, et ne
contient que les éléments essentiels pour la description de la logique du procédé : les activités,
les liens entre ces activités, les données et le contrôle. En revanche, le formalisme BPEL
utilise beaucoup d’autres éléments qui sont de bas niveau mais qui ne font pas une partie de la
sémantique du procédé ; et son formalisme est plus proche au niveau de programmation.

Le principal apport de ce travail de recherche est l’analyse que nous avons effectuée et qui
établit les conditions initiales pour pouvoir transformer des procédés décrits dans le
formalisme d'APEL vers le formalisme de BPEL en gardant une sémantique équivalente. Ces
conditions se basent sur les restrictions qui doivent être prises en considération au moment de
"traduire" un procédé et sur les restrictions requises à cause des différences entre le
formalisme des deux langages.

Pour trouver ces conditions nous avons effectué une analyse comparative basée sur
l'utilisation de patrons de workflows, et plus particulièrement les patrons de contrôle de flux
et les patrons de communication [WAD 04]. À partir de cette étude, nous avons défini les
nouveaux types d'activités que nous devons inclure dans la future version d'APEL, pour que
notre langage soit capable de réaliser de l'orchestration de services à un niveau d'abstraction
plus haut que celui qu’offre la spécification actuelle de BPEL. En outre, nous avons établi
certains patrons de représentation en APEL qui nous permettent d'effectuer, d'une manière un
peu plus claire, la transformation vers BPEL.

Ce travail de recherche s’inscrit dans le cadre du projet S4all (Services-for-All) qui est un
projet ITEA (Information Technology for European Advancement), impliquant 18 partenaires,
appartenant à 5 pays européens. Plus précisément, notre travail fait partie du sous projet
« Orchestration, Chorégraphie et Agrégation de services ».

84
5.2 Perspectives

De nombreuses perspectives peuvent être envisagées comme suites à ce travail.

Tout d'abord, nous n'avons pu, par manque de temps, réaliser qu’une partie de notre outil de
transformation. Il est donc nécessaire de compléter l'implémentation de l’outil.

Dans le cadre du temps que nous avions, nous nous sommes surtout concentrés sur l’analyse
de la transformation, en trouvant des patrons de représentation dans APEL, pour mieux
générer la génération du code BPEL. Une perspective de ce travail consiste donc à trouver de
nouveaux patrons pour améliorer notre outil et couvrir davantage de représentations d’APEL
à traduire vers BPEL.

A court terme, nous sommes en train de travailler pour résoudre la difficulté de la

représentation de la condition pour les nouveaux type d'activités APEL (If et While). La
solution est trouver le patron qui nous permettre de prendre la condition (qui est exprimé en
termes des produits APEL) et de le transformer dans le formalisme de BPEL (qui doit être en
termes de valeurs des variables).

Cette solution est lié aussi à l'initialisation des variables BPEL avant de faire l'appel à un
service web, pour envoyer la valeur correcte. Nous sommes en train de analyser cet difficulté
avec l'utilisation des types d'activités BPEL.

Comme nous l’avons dit précédemment, ce travail de recherche s’inscrit dans le cadre du
projet S4all (Services-for-All). Une perspective à plus long terme, serait de poursuivre le
travail dans ce projet. Cette continuation consisterait tout d’abord à intégrer notre outil de
transformation dans le travail des autres personnes impliquées dans ce projet. Puis de
continuer la recherche autour de l’orchestration de service web afin d’offrir des facilités pour
gérer la coordination de services hétérogènes inter-opérants.

85
 6. BIBLIOGRAPHIE

[ACD 03] Andrews T., Curbera F., Dholakia H., Goland Y., Klein J., Leymann F., Liu K.,
Roller D., Smith D., Thatte S., Trickovic I., Weerawarana S., Business Process
Specification Language For Web Services. IBM specification. Version 1.1,
2003.

[AHK 00] Wil.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, et A.P. Barros.
Workflow Patterns. Eindhoven University of technology. Eindhoven, 2000.

[BE 87] Belkhatir N., Estublier J., Software management constraints and action
triggering in Adele program database. In 1st European Software
Engineering Conf., pages 47–57, Strasbourg, France, Sept. 1987.

[BHL 04] Bézivin J., Hammoudi S., Lopes D., Jouault, F. Applying MDA Approach to
B2B Applications: A Road Map. Workshop on Model Driven Development.
Oslo Juin 2004.

[BPEL 2.0] Business Process Execution Language Version 2.0. Disponible à

http://www.oasis-open.org/committees/download.php/16024/wsbpel-
specification-draft-Dec-22-2005.htm

[DLR 04] De La Rosa-Rosero, Ricardo. Découverte et Sélection de Services Web

pour une application Mélusine. Rapport Master Systèmes d'Information.
Université Joseph Fourier 2004.

[DON 02] Donsez, Didier. Description et Annuaire pour les Web Services WSDL &
UDDI. Université Joseph Fourier. 2002.

[EVL 03] Estublier J., Villalobos J., LE A., Sanlaville S., Vega G. An Approach and
Framework for Extensible Process Support System. LSR-IMAG. Grenoble,
France. 2003

[HTTP] Hypertext Transfer Protocol - HTTP/1.1, W3C, 1999

[KMV 03] Kadima H., Monfort V. Les Web Services, Techniques, démarches et outils
XML, WSDL, SOAP, UDDI, Rosetta, UML. Dunod. Paris 2003.

[KRA 06] Krakowiak, Sacha. Construction d'applications parallèles et réparties :

Composant Logiciels. Notes de cours Master 2 Recherche, Université Joseph
Fourier. 2005/2006.

[KZA 06] Karakostas B.,Zorgios Y., Alevizos C. Automatic derivation of BPEL4WS from
IDEF0 process models. Software & System Modeling. Springer-Verlag 2006

[MIME] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, N. Freed, N. Borenstein, November 1996.
http://www.rfc-editor.org/rfc/rfc2046.txt

86
[PED 05] Pedraza, Gabriel. CUMBIA Extensible Process Modeling: un modelo extensible
para la construcción de motores de Workflow y su validación mediante
representación de BPEL4WS, XDPL y JBPM. Universidad de los Andes,
Colombia 2005.

[PEL 03] Peltz, Chris. Web Services Orchestration: a review of emerging technologies,
tools, and Standards. Hewlett Packard, Co. Janvier 2003.

[SAN 05] Sanlaville, Sonia. Environnement de procédé extensible pour l’orchestration

Application aux services web. Thèse de doctorat, Université Joseph Fourier,
Décembre 2005.

[SK 03] Srivastava, B., Koehler, J. Web Service Composition - Current Solutions and
Open Problems. Proceedings of International Conference on Automated
Planning and Scheduling (ICAPS). 2003.

[SOAP] Simple Object Access Protocol (SOAP) 1.1, W3C Note, 24 June 2003
http://www.w3.org/TR/soap/

[UDDI] Industry Initiative "Universal Description, Discovery and Integration"

http://www.uddi.org/specification.html

[VdA PATT] Van der Aalst W.M.P., "workflow patterns page"

http://is.tm.tue.nl/research/patterns/

[VIL 03] Villalobos J., "Fédération de Composants : une Architecture Logicielle pour la
Composition par Coordination", Thèse de doctorat, Université Joseph Fourier,
juillet 2003.

[VIL 04] Villalobos, Jorge. APEL-light V1, spécification du moteur. Laboratoire LSR –
Equipe ADELE.

[WAD 04] Petia Wohed, Wil M.P. van der Aalst, Dumas Marlon, Arthur H.M. ter
Hofstede. Pattern Based Analysis of BPEL4WS. Technical Report FIT-TR-
2002-04, Queensland University of Technology.

[WPD 03] Wohed P., Perjons E., Dumas M., Hofstede A. Pattern based analysis of eai
languages – the case of the business modeling language. Proceedings of
International Conference on Enterprise Information System (ICEIS). Angers,
France 2003.

[WSA 05] Web Services –Axis. Axis User's Guide. Version 1.2. Disponible à:
http://ws.apache.org/axis/java/user-guide.html

[WSC 02] Web Service Choreography Interface (WSCI) 1.0 Disponible à:

http://www.w3.org/TR/wsci/

[WSDL 01] Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001.
http://www.w3.org/TR/wsdl

87
[WSL 02] Web Services Conversation Language (WSCL) 1.0 Disponible à:
http://www.w3.org/TR/wscl10/

88