1

UFR Informatique & Mathématiques Appliquées

LSR - ADELE

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

2

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

3

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

4

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

5

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

6

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

7

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 ;

8

- 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.

9

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.

10

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.

11

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.

12

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

Role

Activités

Ports Asynchrones

Ports Synchrones

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].

13

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.

Application 1 Application 2

l'Univers Commun concepts communs aux deux applications

Figure 3. Concept Univers commun - Mélusine

14

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.

15

Domain de la composition

Domain des activités

Domain des 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

16

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 concrète

<Binding>

<Service>

Partie abstraite

<Types>

<Messages>

<Ports>

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.

17

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)

Corps (obligatoire)

Erreurs (facultatif)

En-tête (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].

18

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: demande SOAP

(3) Téléchargement des documents WSDL

(4) Demande SOAP conforme au WSDL

(5)Réponse SOAP conforme au WSDL

Entreprise B

(1) Publication des services: enregistrement des documents WSDL

Entreprise A

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

19

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

FabricantFournisseur

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/

20

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.

21

• 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/

22

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.

23

• 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

24

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]

25

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

26

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]

27

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

28

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].

29

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

30

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.

31

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

0

10

20

30

40

50

60

70

80

90

100

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

Nombre de essais

Tem

ps e

n m

illis

econ

des

BPEL

Java-AXIS

APEL-AXIS

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.

32

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.

33

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.

34

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.

35

A

B

C

AND

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.

36

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.

C

A

B

AND

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 :

37

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.

A

B

C

XOR

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

38

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.

C

A

B

XOR

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.

39

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

A

B

C

Multi-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

40

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.

A

B

C

Multi-choice

D

Sync-Merge

Figure 32 : Le patron du Fusion Synchronisée

41

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).

L1L2

L1sL2s

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.

42

OR L2s L1s

L2, C2 L1, C1

Flow

A

Empty

C B

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 :

43

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.

A

B

C

ajoutez l'instance

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).

44

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.

45

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.

46

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.

A

B

C

Deferred 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

47

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.

A

B

C

Cancel Activity

A

B

C

Cancel Case

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

48

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.

49

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.

50

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.

51

A

(sender) B

(receiver)

requête

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.

A

(sender) B

(Receiver)

requête

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.

52

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 :

53

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.

Synchrone

A (sender) B C

receiver

requête réponse

Figure 52. Représentation du patron Synchronous Polling

54

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.

55

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.

A (sender) B C

receiver

requête réponse

Asynchrone

56

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.

57

A (sender)

Gestion des Messages

C (receiver)

B (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.

A (sender)

C (receiver)

B (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.

58

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).

59

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.

60

<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

61

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.

62

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]

63

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

64

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).

65

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é

66

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 flotde 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.

15 Patron de Synchronisation.

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.

67

Partie a.

Partie b.

Partie c.

<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>

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.

68

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].

69

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. 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

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.

70

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.

71

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.

72

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).

73

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.

74

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

75

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.

76

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.

77

<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 c. Les activités qui font partie de la boucle

Partie b. L’intérieur d’activité WhileVerifySeats.

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.

78

• 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).

79

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].

80

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.

81

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.

82

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.

Fichiers WSDL-Wrappers WSDL.

Outil de transformation

Outil de transformation

Analyse pour partnerLinks et variables

Fichier BPEL

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.

83

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.

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

Outil de transformation

Fichier BPEL

Parseur Analyse et identification des patrons

Représentation BPEL

Représentation APEL

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.

84

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 ».

85

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.

86

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

87

[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

88

[WSL 02] Web Services Conversation Language (WSCL) 1.0 Disponible à:

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