Le langage de processus BPEL

Le langage BPEL est un langage XML pour implémenter les processus d’affaires. Les processus ainsi implémentés sont exécutés dans des moteurs d’exécution BPEL et exposés comme des services Web. Dans ce cas, le processus est dit exécutable. Il est aussi possible d’écrire un processus BPEL abstrait, c’est-à-dire un processus qui a des activités dont les détails d’implémentation sont omis.

Un processus BPEL est constitué d’activités qui sont l’unité élémentaire d’exécu-tion. Les activités de base sont les opérations pour communiquer avec les services Web : l’activité receive qui permet de recevoir le message d’un service, l’activité

reply qui permet de répondre à une activité receive précédemment exécutée et l’activité invoke qui permet de faire un appel à un service Web. Avec ces activités, un processus BPEL peut être à la fois client et fournisseur de services Web. Le langage fournit aussi des constructions plus complexes telles les boucles et les activités condi-tionnelles. Il comporte aussi l’instruction flow qui permet l’exécution de plusieurs activités en parallèle tout en autorisant des points de synchronisation.

Le langage BPEL résulte des travaux de l’OASIS7, une organisation rassemblant de grands constructeurs logiciels tels que IBM, Microsoft et SAP. Il existe de nom-breux moteurs d’exécution du langage. Chacun d’entre eux couvre tout ou partie

1.5. Le langage de processus BPEL

de la norme du langage et les implémentations peuvent varier8 [28, 29]. De plus, ils proposent des extensions telles que l’utilisation de langages tiers (par exemple Java, Javascript) ou encore la génération d’identifiants uniques globaux (Globally Unique IDentifier (GUID) en anglais). Le moteur ODE d’exécution BPEL est implémenté par la fondation Apache. Il est conforme à la version 2.0 du langage BPEL9. Il peut exécuter des processus BPEL en mémoire ou encore les sauvegarder dans un système de gestion de base de données avant de les exécuter. Il permet le développement flexible des processus en autorisant, entre autres, le déploiement et la désinstallation des paquetages de processus BPEL à chaud.

1.5.1 Interface d’un processus BPEL

Le langage BPEL repose sur la norme WSDL pour les contrats. Cela signifie qu’un processus déployé est exposé comme un service Web classique. BPEL utilise la no-tion de lien de partenaire pour représenter, à l’intérieur du processus, soit le point d’accès d’un client au processus, soit le client d’un autre service. La figure 1.10 re-présente l’interface d’un processus BPEL qui s’occupe de vente de biens multimédia. À gauche, selling est le lien de partenaire qui représente le client qui utilise les opérations GetCatalog, Order et Pay du processus. Ce lien de partenaire est de type Library PT (type de port Library). À droite dans la figure 1.10, le processus BPEL est le client de services Web pour l’expédition (Shipper) et pour les opéra-tions d’une banque (Bank). Le processus peut ainsi utiliser des opéraopéra-tions disponibles à travers les types de port des liens partenaire ainsi déclarés.

1.5.2 Activités du langage BPEL

Comme le langage BPEL a été créé pour la définition de processus d’affaires, ses constructions sont des activités, plutôt que des instructions. L’activité receive (res-pectivement reply et invoke) permet de recevoir un message d’un client (respec-tivement répondre à une requête d’un client et appeler en tant que client un service Web). Chacune de ces activités de communication précise dans ses paramètres quel

8. Comparaison de moteurs BPEL : code.google.com/p/bpel-g/wiki/BPELComparison 9. Version 2.0 de la norme BPEL : docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

GetCatalog Order Pay Library PT PartnerLink selling Ship Schedule Shipper PT PartnerLink shipping Credit Debit Bank PT PartnerLink banking

Figure 1.10 – Exemple d’un processus BPEL

est le partenaire client ou fournisseur, quelle opération l’initie et quelle variable est lue ou modifiée. Il existe deux versions plus complexes de l’activité receive : les ac-tivités onMessage et onEvent. L’activité onMessage permet à la fois de recevoir une requête et de choisir une branche de traitement appropriée à la requête reçue. Elle fait partie en réalité de l’activité pick qui offre la possibilité de choisir parmi plusieurs possibilités une branche de traitement en fonction de la requête reçue. L’acti-vité onEvent permet de traiter des requêtes en parallèle de l’exécution d’une actiL’acti-vité principale. Elle est souvent employée pour obtenir de l’information sur l’état du dé-roulement d’un traitement en cours ou même demander son annulation. Dans le pro-gramme 1.7, l’instruction onMessage à la ligne 2 (respectivement 11) active l’attente des requêtes AuthorizationRequest (respectivement des requêtes Rollback). La ligne 2 (respectivement 11) spécifie aussi que les requêtes sont attendues du lien de partenaire FilterPtrLnk et, une fois celles-ci reçues, leur contenu est stocké dans la variable ARIn (respectivement RollbackIn). En cas d’occurrence d’une requête AuthorizationRequest(respectivement Rollback), le traitement du processus

1.5. Le langage de processus BPEL

1 <pick name="PickShopIsOpen">

2 <onMessage partnerLink="FilterPtrLnk" operation="AuthorizationRequest" portType="fw:FilterPortType" variable="ARIn">

3 <correlations><correlation set="CorrSetPId" initiate="no"/></correlations> 4 <sequence name="SequenceAR">

5 ...

6 <invoke name="InvokeE" partnerLink="ASTDPtrLnk" operation="Execute" portType="aw:ASTDPortType" inputVariable="EIn" outputVariable="EOut"/>

7 ...

8 <reply name="ReplyAR" partnerLink="FilterPtrLnk" operation="AuthorizationRequest"

portType="fw:FilterPortType" variable="AROut"/> 9 </sequence>

10 </onMessage>

11 <onMessage partnerLink="FilterPtrLnk" operation="Rollback" portType="fw:FilterPortType" variable="RollbackIn">

12 <correlations><correlation set="CorrSetPId" initiate="no"/></correlations> 13 <sequence>

14 ...

15 <reply name="ReplyRollback" partnerLink="FilterPtrLnk" operation="Rollback" portType="fw:FilterPortType" variable="RollbackOut"/>

16 </sequence> 17 </onMessage> 18 </pick>

Programme 1.7 – Activités de communication BPEL

se poursuit à l’activité sequence des lignes 4 à 9 (respectivement des lignes 13 à 16). Dans le programme 1.7, les activités receive, reply et invoke sont illustrées avec des valeurs pour l’attribut partnerLink. Par exemple à la ligne 6, l’activité invoke appelle à son exécution l’opération Execute du service Web accessible par le lien de partenaire ASTDPtrLnk avec la requête SOAP EIn (attribut inputVariable) et la réponse SOAP EOut (attribut outputVariable).

Le langage BPEL offre des activités complexes de contrôle du fil d’exécution. L’ac-tivité if permet l’exécution conditionnelle d’une sous-acL’ac-tivité. Sa version étendue permet de conditionner l’exécution de plusieurs activités mutuellement exclusives à la if ... then ... else if ... else .... Il est possible de répéter l’exécution d’une acti-vité avec les actiacti-vités de boucle telles que while, repeatUntil et forEach. Les activités while et repeatUntil exécutent leur sous-activité en boucle — de fa-çon séquentielle — suivant la valeur d’une expression booléenne. L’activité forEach opère de façon différente en permettant l’exécution en parallèle de plusieurs branches de la même sous-activité suivant les valeurs d’un compteur entier.

BPEL emprunte des fonctionnalités à des langages modernes comme Java. La prin-cipale est la gestion des exceptions avec les activités throw et rethrow pour res-pectivement déclencher et renvoyer le traitement d’une exception. Puisque le langage peut considérer des processus de longue durée, il offre un mécanisme complexe pour la gestion des erreurs appelé compensation. Ce dernier peut être considéré comme un moyen d’annuler l’effet d’activités faisant partie d’un processus qui échoue en cours de traitement. Les activités qui permettent de mettre en œuvre la compensation sont

compensate et compensateScope. Elles déclenchent le mécanisme de compen-sation pour des activités qui implémentent un gestionnaire de compencompen-sation.

Le langage BPEL est orienté vers la réception et l’envoi de messages et l’expres-sion de structures de contrôle du flot de traitement, plutôt que vers la manipulation des données. Les variables et les messages reçus ou échangés ont des types de base (par exemple entier, chaîne de caractères) ou des éléments XML. L’activité assign du langage permet la modification des variables. Cependant cette activité est limitée dans ses possibilités. Par exemple, il n’est pas possible d’ajouter un élément XML à un document XML qui est une valeur d’une variable. Concrètement considérons l’exemple d’une commande de produits écrite en XML. L’ajout d’une ligne de pro-duit à cette commande est impossible avec seulement des éléments du langage BPEL. En pratique, la norme BPEL offre la possibilité d’utiliser un processeur XSLT qui effectue la transformation de documents XML en fonction des paramètres d’entrée (document à transformer et feuille de style XSL). Pour utiliser cette fonctionnalité du langage, il faut avoir recours à la fonction doXslTransform, comme le montre le programme 1.8 aux lignes 6 à 11. La feuille de style XSL GetSpecification.xsl et la variable XML SpecificationRequest sont passées en paramètres au pro-cesseur XSLT utilisé par le moteur d’exécution du processus. Le résultat de la trans-formation du document en format XML par la feuille de style est stocké dans la variable Specification à la ligne 10. Le programme 1.8 montre aussi à la ligne 3 l’utilisation d’une fonction du langage XPath pour extraire une chaîne de caractères du contenu XML de la variable InitIn.

1.6. Conclusion 1 <assign> 2 <copy> 3 <from>substring($InitIn.payload/cx:PId, 1, 4)</from> 4 <to variable="SpecificationRequest"/> 5 </copy> 6 <copy> 7 <from> 8 bpws:doXslTransform("GetSpecification.xsl", $SpecificationRequest) 9 </from> 10 <to variable="Specification"/> 11 </copy> 12 <copy> 13 <from> 14 <literal> 15 <tx:ExecuteRequestType> 16 � 17 </tx:ExecuteRequestType> 18 </literal> 19 </from> 20 <to variable="EIn" part="payload"/> 21 </copy> 22 <copy> 23 <from>false()</from> 24 <to variable="RepeatAR"/> 25 </copy> 26 </assign>