Min istère de l’enseignement Supérieur, de la Recherche scientifique et de la Technologie
Université Virtuelle de Tunis
Développement Orienté Services
Orchestration (composition) des services web
avec BPEL4WS
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
1. Introduction
1. Définition
Le Business Process Execution Langage (BPEL) ou langage d'exécution des processus métier
qui permet la composition et l'orchestration de web services (WS).
BPEL permet d'écrire des programmes qui utilisent des WS et qui sont des WS. Un standard
était nécessaire pour assurer les liens entre plusieurs WS, au sein d'une application. BPEL a
donc été conçu pour intégrer un grand nombre d'applications, publiées sous forme de service,
sans dépendance de plate-forme ou de langage, le tout de manière automatique. Cette
spécification n'est pas la seule visant à créer une infrastructure d'orchestration pour services
Web, mais c'est la plus en vue, car soumise à l'organisme Oasis par de grands acteurs: IBM,
Microsoft, BEA, SAP et Siebel.
BPEL consiste en un langage XML conçu pour définir et gérer les orchestrations de
processus. Dans ce contexte, une orchestration est une collaboration entre deux ou plusieurs
services, mise en place et/ou gérée (orchestré) par un tiers - en l'occurrence, BPEL. Ce dernier
prend en charge la séquence complète d'invocations des divers services, ou "collaborateurs".
Un processus BPEL dispose donc d'une logique d'invocation, celle-ci pouvant être synchrone
ou asynchrone. BPEL fait fortement usage des autres standards liés aux services Web, à
commencer par WSDL et SOAP. Chaque processus BPEL étant un service Web à part
entière, il dispose donc de son propre WSDL.
2. Historique
Initialement BPEL était connu sous le nom de BPEL4WS: « Business Process Execution
Langage for Web Services ». Comme c'était absolument imprononçable, l'appellation fut
modifiée en WS-BPEL.
BPEL est issu des langages WSLF (Web Services Flow Language) et XLANG. Ce langage a
été défini dans sa version 2.0 par une spécification du consortium OASIS à la fin du mois de
mars 2007.
2. BPEL : Le langage
1. BPEL : Principe
Dans la plupart des cas, BPEL est utilisé comme un serveur. C'est à dire que BPEL sert de
proxy à d'autres systèmes. Dans ce cas, l'enchainement des évènements est le suivant:
Requête du WS client, provenant soit d'un browser, soit d'un autre WS.
Réception de la requête par le serveur BPEL.
La requête client est identifiée comme une nouvelle requête, et un nouveau
processus BPEL est utilisé pour servir ce client.
Publicité
Le client continue à interagir avec le processus BPEL, faisant des requêtes, jusqu'à
ce que l'interaction soit achevée.
Le processus BPEL disparaît.
Cette manière de créer une instance d'un processus BPEL en réponse à la requête d'un client
est appelée « Création à la demande » (« Create on demand »).
D'autres applications ont un fonctionnement différent. Par exemple des programmes de test
peuvent être programmés en BPEL, et l'enchainement des évènements est alors différent.
L'exécution est lancée par le « user », qui observe ensuite les logs. (Voir par exemple:
http://www.eclipse.org/tptp/platform/documents/design/choreography_html/). Il n'y a pas de «
Création à la demande » du processus.
2. Exemple d’un scénario
Inscription d’un étudiant à un institut universitaire
1
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
Chercher un logement à la cité universitaire (CU)
S’abonner au transport de bus
institut et le logement
1ère solution : l’utilisateur se rend sur chaque site de l’administration concernée
2ème solution : l’utilisateur n’utilise que le site web de l’institut qui comporte un workflow
complet
2
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
3. PBEL : les bases
BPEL est un langage de programmation XML. Comme tous les langages de programmation,
il a 23 composants de base :
Des operateursProgramming logic
Des Types de Données: XSD (« XML Shema Definition »)
Des Entrées/Sorties (I/O) :WSDL (« Web Services Description Language »)
4. BPEL : les outils
Deux catégories d’outils sont à distinguer :
- Editeur graphique de processus BPEL
- Moteur BPEL intégré dans la majorité des serveurs d’application
A noter que les solutions BPEL proposées par les éditeurs de logiciels fournissent à la fois
l’éditeur et le serveur. Les éditeurs graphiques sont généralement intégrables dans les
environnements de développement (Eclipse, Netbeans, Visual Studio, …)
Voici les outils les plus connus :
- OpenESB (via Glassfish 2.1) et Netbeans 6.7.1 : https://open-esb.dev.java.net/
- Apache ODE et Eclipse BPEL Editor : http://ode.apache.org/ et
http://www.eclipse.org/bpel/
- JBoss jBPM (uniquement le moteur BPEL) : http://www.jboss.com/products/jbpm/
- Oracle BPEL Process Manager (Weblogic + JDeveloper) :
http://www.oracle.com/technology/bpel
Publicité
- Orchestra : http://orchestra.ow2.org
- IBM (Weblogic + Workshop) : BPEL for Windows Workflow Foundation (Visual
Studio et Biztalk)
5. BPEL : le projet
Un projet BPEL se compose de trois catégories de fichiers :
- les fichiers de description des processus (*.bpel)
- les fichiers de description des Services Web (.wsdl et .xsd)
- les fichiers de déploiement (*.xml) dont la structure dépend fortement du moteur
BPEL utilisé.
3
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
Partie statique
La partie statique d’un processus est définie par un document WSDL qui permet de :
- décrire les points d’entrées et de sorties du processus
- définir les types des données (XML Schema) et les messages utilisés pour décrire
l’état du processus
- décrire les opérations qui sont autorisées et qui permettent d’invoquer le processus
Partie dynamique
La partie dynamique du processus est décrite par le fichier BPEL. Ce document BPEL
permet de décrire :
- l’ordonnancement des différentes sous étapes du processus
- l’invocation vers les opérations des Services Web partenaires
- la logique et l’état du processus
6. Structure d’un fichier BPEL
3. BPEL par l’exemple : HelloWorld
Pour introduire la présentation du langage BPEL nous construisons un processus HelloWorld.
Le processus BPEL est décrit par le Service Web suivant : une opération makeHello qui prend
en paramètre une chaîne de caractère et retourne une chaîne de caractère. Le processus BPEL
traite le Workflow suivant :
4
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
- Récupération du message envoyé par le client (chaîne de caractères)
- Invocation d’un Service Web externe (partenaire) avec comme paramètre la chaîne
de caractères reçue par le processus
- Retourner au client le message récupéré de l’invocation précédente
1. Fichier BPEL complet
5
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
6
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
2. Partner links
Du point de vue des clients le processus BPEL est un Service Web. Deux façons d’interagir
entre un processus BPEL et des Web Services externes :
- Un processus BPEL invoque des opérations issues d’autres Web Services (dit
Publicité
Partenaires): lien de partenaire (PartenerLink) de type invocation
Un processus BPEL reçoit des invocations issues de clients : lien de partenaire
(PartenerLink) de type client
Pour résumer, un lien de partenaire désigne les relations entre des partenaires / clients et le
processus BPEL.
Un lien de partenaire est représenté dans le fichier BPEL par un élément partnerLink. Il
contient les attributs suivants :
- name : nom donné au partnerLink
- myRole : spécifie le rôle du processus BPEL
- partnerRole : spécifie le rôle du partenaire ou du client
- partnerLinkType : type de partnerLink défini dans la description WSDL
Si l’attribut myRole est uniquement utilisé (sans partnerRole), seules les interactions vers le
processus sont autorisées. Si l’attribut partnerRole est uniquement utilisé (sans myRole)
seules les interactions vers les partenaires et les clients sont autorisés. Les deux rôles peuvent
être utilisés en même temps.
3. Partner Link Types
Un PartnerLinkType décrit la relation entre deux services en détaillant le rôle que chaque
service implémente. Chaque rôle spécifie un PortType (issu du WSDL) qui doit être
implémenté par le service qui implémente ce rôle.
7
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
4. Variables
Les messages sont envoyés et reçus vers et de partenaires, il est donc nécessaire de les
sauvegarder pour être utilisés par le processus BPEL. Ce dernier définit la notion de variables
qui permet de manipuler les messages des interactions entre les partenaires. Ainsi, une
variable est définie par des types et des messages déclarés dans un WSDL. Chaque variable
est définie par les attributs suivant :
- name : nom de la variable
- type : typée via un type XML Schema par exemple Ou
- messageType : typée via un message
8
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
5. Activités
Un processus BPEL est décrit par un ensemble d’étapes. Chaque étape est appelée une
activité (activity). Deux catégories d’activité sont à distinguer :
Receive
L’activité Receive est utilisée pour la mise en attente du processus tant qu’un message n’est
pas envoyé par un partenaire. Elle est utilisée généralement pour instancier le processus BPEL
(première activité du processus). Elle est définie par la balise <receive> dont les principaux
attributs de cette activité sont :
- name : nom de l’activité
- partnerLink : lien partenaire utilisé pour identifier le partenaire qui doit déclencher le
processus
- operation : identifiant de l’opération que le processus doit implémenter
- variable : où stocker le message envoyé par le partenaire
9
Publicité
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
Reply
L’activité Reply permet d’envoyer une réponse au message envoyé à l’activité Receive. Le
couple Reply / Receive décrit une opération de type requête / réponse. Elle est définie par la
balise <reply> dont les principaux attributs de cette activité sont :
- name : nom de l’activité
- partnerLink : identifiant du lien partenaire utilisé pour identifier le partenaire qui doit
recevoir le message de réponse
- operation : identifiant de l’opération que le processus a implémenté
- variable : message contenant le message à retourner
Assign
L’activité Assign peut être utilisée pour copier des données d’une variable vers une autre. Il
est possibile d’utiliser des expressions complexes pour modifier le contenu des variables
(XPath, transformations XSL).
L’activité Assign est définie par la balise <assign> qui peut contenir un ensemble de sous
balises <copy> qui contient à son tour des sous balises <from> et <to> pour exprimer la copie
d’un contenu vers un autre. La structure XML de la balise <assign> est la suivante :
L’activité Invoke est utilisée pour déclencher l’appel à une opération sur un portType défini
par un lien de partenaire. Seules les opérations suivant le modèle One-way et
Request/Response peuvent être invoquées par un BPEL. L’invocation d’opération nécessite
l’utilisation de variables en entrée et en sortie pour initialiser la requête et la réponse.
L’activité Invoke est définie par la balise <invoke> et possède les attributs suivants :
- name : nom de l’activité
- partnerLink : identifiant du lien partenaire
- operation : l’opération à invoquer
- portType : le portType pour de l’opération
- inputVariable : informations à transmettre à la requête
- ouputVariable : utilisées pour récupérer les données de la réponse
10
Université Virtuelle de Tunis Développement Orienté Services
BPEL4WS
L’activité Invoke ne permet de déclencher que des opérations issues d’un Service Web étendu
(via WSDL). Les travaux de standardisation s’intéressent actuellement à la possibilité
d’invoquer différents services de technologies différentes (Service Web de type REST).
Toutefois, il est actuellement possible d’invoquer des services sous condition de définir un
adaptateur WSDL.
Activités Sequence, Flow, While, Pick,…
L’ordonnancement des activités est défini par des activités complexes.
L’activité Sequence permet d’exprimer que des activités soient déclenchées dans un ordre
donné.
L’activité Flow permet de définir qu’une ou plusieurs activités soient déclenchées de manière
concurrente.
L’activité While permet de définir qu’une activité peut être répétée plusieurs fois.
L’activité Pick permet de mettre en attente une activité jusqu’à l’arrivée d’un message.
…
11