Workflows, Orchestration, BPM, BPEL and Cie
Inspiré du Cours de Michel Riveill
Virginie Legrand
Virginie.legrand@inria.fr
Master 2 MIAGE NTDP
Plan
Workflows : définition
BPM
BPEL
Wikipedia ? Qu’est ce qu’un workflow ?
Un workflow est un flux d'informations au sein d'une organisation,
comme par exemple la transmission automatique de documents entre des personnes.
On appelle « workflow » (traduisez littéralement « flux de travail ») la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier (aussi appelé processus opérationnel ou bien procédure d'entreprise). Le terme de « workflow » pourrait donc être traduit en
français par « gestion électronique des processus métier ».
De façon plus pratique, le workflow décrit le circuit de validation, les tâches à accomplir entre les différents acteurs d'un processus, les délais, les modes de validation, et fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche. Pour un
processus de publication en ligne par exemple, il s'agit de la modélisation des tâches de l'ensemble de la chaîne éditoriale.
Il permet généralement un suivi et identifie les acteurs en précisant leur rôle et la manière de le remplir au mieux.
Le moteur de workflow est le dispositif logiciel permettant d'exécuter une ou plusieurs définitions de workflow.
Wikipedia ? Qu’est ce que le BPM ?
business process management / pilotage de procédure d'entreprise
Définition [1] : « Une procédure d’entreprise est une procédure qui systématise l’organisation et la politique d’une entreprise dans le but d’atteindre certains des objectifs de cette entreprise. »
On peut envisager une procédure d'entreprise au sein d'une entreprise étendue : commande sur un site web marchand, puis suivi de cette commande chez le fournisseur. On parlera dans ce cas de « processus d'affaires ».
La procédure d'entreprise peut être un résultat issu de la modélisation de procédure
d'entreprise ou de l'optimisation de procédure d'entreprise (« business process reengineering
»).
« business process modeling », soit modélisation de procédure d'entreprise
modélisation de procédure d'entreprise ou modélisation de processus métier ou modélisation de processus désigne la création d'un modèle mathématique d'une procédure d'entreprise. BPM est le sigle utilisé, en référence à l'anglais « Business Process Modeling ».
Ce terme renvoie aux techniques et activités de la discipline de pilotage de procédure d'entreprise (ici BPM pour « Business Process Management »).
La distinction fondamentale entre ces deux notions de BPM réside dans le fait que pour la seconde, on s'intéresse à donner à l'Entreprise les moyens de piloter et de maîtriser ses processus-métiers, tandis que la première ne consiste qu'à les modéliser (toujours avec un objectif venant de l'extérieur : optimisation de chaîne de production, expression de besoins fonctionnels pour un développement logiciel, réorganisation suite à un rapprochement entre deux filiales d'une entreprise, par exemple).
La modélisation de processus est utilisée en gestion de la qualité pour représenter des processus, mais également pour les procédures d'entreprise et workflows avec :
le langage de modélisation de procédures (« Business Process Modeling Language » ou BPML),
la notation de modèles de procédures (« Business Process Modeling Notation
» ou BPM
Le workflow dans le detail
Un workflow est un ensemble d’activités
Coordonne les personnes des logiciels ou des composants
Matérialise un état dans un cadre très large (au delà de l’EAI et du workflow humain)
EAI
Enterprise Application Integration / Intégration d'applications d'entreprise
Architecture intergicielle permettant à des applications hétérogènes de gérer leurs échanges
Il met en relation différents participants: personnes, rôles
Il peut être flexible, dynamique
Il peut manipuler des données déstructurées comme des documents
Permet l’intégration et la coopération des logiciels
Types de workflows (1)
Types de Workflows (2)
Ex: Applications métier, supply chain
Ex: Notes de frais, tableaux de bord management Ex: approbation de
document, Demande de congés
Ex: E-mail, messageries
instantanées, liste de taches
personnelle
Participants: applis, services
Flow style: prescriptif, protocoles
Données: structurées et transactionnelles
Fixe Systeme tres
structure Humain,
Semi-structure Individuel
Ad-hoc
Workflow humain Workflow Systeme
Objectifs (1)
Intégrer des applications qui s’exécute sur des plateformes hétérogènes
Interconnections point à point entre les applications
Liaisons encodées en dur évolutions difficiles
Coordonner les exécutions
Pas facile à mettre en œuvre si pas de coordinateur, ou si absence de description de la coordination
Objectifs (2)
Intégration à base de service
Liaisons réalisées à l’exécution
Standards indépendants des plates-formes configuration flexible
Présence d’un coordonnateur
Un rappel ? Principes de la SOA ?
Selon Don Box (grand gourou… des SOAs)
Frontières explicites
Échanges de messages au lieu d’appels de méthode
Implantation invisible en dehors des limites du service
Autonomie
Topologie des services toujours en mouvement
Exposés pour être utilisés (build it and they will come)
Mise en commun de contrats, pas de classe
Interfaces structurelle et comportementale exposées séparément
Validation / vérification automatiques nécessaires
Compatibilité fondée sur des règles
Validation de la compatibilité structurelle automatisable
compatibilité sémantique exprimée par des règles (fonctions
requises / offertes)
Etude de cas
Un client désire acheter 120 potiches à Perfact Glass Inc.
Etude de cas (2)
les services concernés dans PG Inc.
Ventes
Gestion des commandes Faire devis
commande
Traiter commande
commande
Annuler commande
commande
Vérifier disponibilité
vérification stock Ordonner livraison
ordre de livraison Ordonner facturation
ordre de facturation Entrepôts & Logistique
Vérification disponibilité
vérification stock
Gestion des entrepôts
Sortir du stock
ordre de livraison Livrer
livraison
Services financiers
Gestion clientèle
Faire la facture
facturation
les services concernés chez le client
Demander devis
commande
Envoyer commande
commande
Annuler commande
commande
Etude de cas (3)
Raffinement des interactions : définition des rôles
Vocabulaire
Interface :
décrit les opérations offertes par un service
aspects structurels (par ex. WSDL)
Orchestration :
modèle privé des actions internes et des interactions d’un service
aspects comportementaux (pax ex. BPEL)
Chorégraphie :
modèle global des interactions entre des
services (deux ou plus)
Interface
Interface structurelle
Décrit les aspects structurels d’un service
Les messages reçus et envoyés
Le contenu et la structure de ces messages
Le sens (entrant / sortant) et le type de message
Peut exprimer des règles de sécurité et/ou des propriétés extra fonctionnelles
Cache les détails de l’implantation
Ne décrit pas la manière d’utiliser le service
Exemple : SGF
Create
Open
Read
Write
Close
Delete
Interfaces Structurelles
La description des messages peut parfois
suffire à comprendre le fonctionnement
Interface Comportementale
Le processus public
Décrit comment interagir avec le service
Inclut les tâches de communication entre le client et le fournisseur du service
Exprime les règles de dépendance entre les tâches
Peut exprimer des règles de gestion et/ou des propriétés extra-fonctionnelles
Peut être utilisée pour la vérification des
messages entrant et sortant
Interface comportementale du service
Ventes
Orchestration
Décrit un processus
Décrit comment le service est réalisé
Tâches de transformation
Manipulation de données
Transformation de données
Tâches internes
Appel à des applications internes
Tâches de communication avec d’autre services
Peut exprimer des règles de sécurité et/ou des propriétés extra-fonctionnelles
Intégration de composants exprimes sous la
forme de service
Orchestration du service vente
On complète l’interface
Comportementale du service
Par des actions internes
Choregraphie
Point de vue plus global
On ne s’intéresse plus à une orchestration mais à un ensemble d’orchestration liées
Description des interactions entre les services (chacun associé à un rôle)
Inclut les tâches de communication des services concernés
Exprime les règles de dépendance entre les tâches
Peut exprimer des règles de gestion et/ou des propriétés extra-fonctionnelles
outil de modélisation de collaborations
B2B
La choregraphie de l’etude de cas
Synthese
Des outils pour la conception/execution d’orchestration
Apache ODE / Eclipse
ActiveVOS ActiveBPEL + ActiveVOS Designer
BEA WebLogic Studio,
IBM WebSphere Studio,
Microsoft BizTalk 2004 / Windows workflow foundation
SAP Composite Application Framework,
Oracle BPEL Process Manager
eInsight (SeeBeyond),
Etc …
Business Process Modeling Notation
Une norme pour la représentation graphique des workflows
Plug-in eclipse : http://www.eclipse.org/stp/bpmn/
Que dit Wikipedia ?
Business Process Modeling Notation (BPMN) est une notation
graphique standardisée pour modéliser des procédures d'entreprise dans un workflow.
Business Process Modeling Notation a été développée par la Business Process Management Initiative (BPMI), et est maintenant maintenue par l'Object Management Group (OMG) depuis leur fusion en 2005.
Le but principal de BPMN est de fournir une notation qui soit réellement compréhensible par tous les utilisateurs de
l'entreprise, depuis les analystes métier qui créent les ébauches initiales des procédures, jusqu'aux développeurs responsables de mettre en place la technologie qui va exécuter ces procédures, et finalement, jusqu'aux utilisateurs de l'entreprise qui vont gérer et monitorer ces procédures.
Ainsi, BPMN crée un pont standardisé pour combler le vide entre la modélisation des procédures d'entreprise et la mise en place des
procédures. Actuellement, il y a des dizaines d'outils de modélisation et de méthodologies pour les procédures d'entreprise. BPMN améliorera les
possibilités des notations traditionnelles des procédures d'entreprise en gérant par nature les concepts de procédures B2B, comme les procédures publiques et privées et les chorégraphies, ainsi que des concepts de
modélisation avancée, comme la gestion des exceptions et la compensation des transactions
BPMN en details
BPMN
http://www.bpmn.org
Normalisé par l’OMG
BPMN fournit
des diagrammes de processus métier
Business Process Diagram (BPD)
des mécanismes formels pour la transformation dans un langage XML d’exécution de processus métier
exemple : BPEL4WS.
BPMN a été conçu uniquement pour supporter les concepts de modélisation applicable aux processus métier
Les autres types de modélisation :
règles métiers
modèles de données
structures organisationnelles,
. . . ne sont pas pris en compte par BPMN
Utilisation
BPMN a été conçu pour supporter différents types de modélisation et autorise la création de bout en bout de processus métier.
Il existe trois types basiques de modèle :
Les processus métier privés :
Ils sont internes à une organisation spécifique.
Ils sont généralement appelé workflows. Cela peut par exemple correspondre à un processus WS-BPEL.
les processus métier abstrait :
Ils représentent les interactions entre un processus métier privé et un autre processus ou participant.
les processus de collaboration :
Ils décrivent les interactions entre deux ou plusieurs
entités métier. Ces interactions sont définies comme des
séquences d’activités représentant les patrons d’échange
de message
Notation
Un BPD n’est pas conçu pour représenter graphiquement toutes les informations nécessaires à l’exécution. C’est pour cela que les éléments graphiques sont associés à un ensemble d’attributs pour ajouter des informations supplémentaires.
Afin de gérer à la fois des diagrammes faciles à comprendre et la complexité inhérente aux processus métier, les aspects
graphiques de la notation ont été regroupés en catégories facilement reconnaissables.
À l’intérieur de chaque catégorie, des éléments d’informations supplémentaires peuvent être ajoutés pour supporter la
complexité sans agrandir la représentation graphique. Les quatres catégories de bases pour la description d’un processus sont :
Les objets de gestion de flux (flow objects) ;
Les objets de connexion (Connecting objects) ;
Les objets de regroupements (Swimlane) ;
Les Artefacts (Artifacts).
Exemple
Processus de sélection des dossiers étudiants postulant à un master.
Processus instancié sur événement (réception d’un dossier)
Première activité atomique : récupérer le dossier.
En séquence, seconde activité : vérification du dossier
Ensemble de pièces nécessaires, études antérieures compatible
En séquence, trois possibilités exclusive (XOR)
Exemple
trois possibilités exclusive (XOR)
la candidature est invalide.
Dans ce cas, une lettre est rédigée expliquant le refus du dossier ;
le dossier est incomplet.
Cette activité est un sous-processus car elle comporte un certain nombre d’activités comme par exemple l’envois d’une lettre
demandant les pièces manquantes, le traitement des documents, . . . ;
le dossier est complet.
Cette activité est un sous-processus au cours duquel le dossier du candidat sera évalué par plusieurs enseignants avant de
déterminer si le candidat sera retenu sur liste principale ou complémentaire.
Ces trois cas sont ensuite réunis de manière exclusive (XOR Join).
Cela générera un envoi d’événement représentant la fin du
processus
Les objets de gestion de flux
Principaux éléments pour définir le comportement d’un
processus métier
3 types d’objets :
Les événements (Events) : début, fin par exemple
Les activités (Activity) : atomique ou composée
Les jonctions (Gateway).
Les différents éléments sont reliés entre eux par
des liaisons représentant le flux de travail, i.e.,
l’ordre d’exécution des activités.
Les evenements
Représente quelque chose qui survient au cours d’un processus
Vont affecter le déroulement d’un processus
3 trois catégories d’événements :
Départ
représentent le point d’entrée et donc le déclenchement d’un processus
Exemple : arrivée d’un « Message », activation d’une « règle ».
Intermédiaires
se produisent lors de l’exécution d’un processus
Exemple : déclenchement d’une exception
Fin
fin d’un processus et le cas échéant la manière de le terminer
Exemple : envoi de message
Représenté par un cercle, dont le style du trait définit sa catégorie (début, intermédiaire, fin).
Un symbole dans le cercle matérialise le type d’événement
Exemple : un « Message »est symbolisé par une enveloppe.
Representation des evenements
Les activites
Représentent les différentes tâches à réaliser au cours du processus métier
2 catégories :
Atomique
Représente directement une tâche
Composée
Cas des sous-processus.
Exemple : l’activité "dossier incomplet" correspond à un processus spécifique dans lequel nous allons par exemple demander à l’étudiant d’envoyer les pièces manquantes.
Les activités peuvent se répéter, comme dans le cas de boucle for ou while.
une flèche circulaire est ajoutée sur la représentation de l’activité.
les attributs associés à la représentation permettent d’indiquer les conditions de la boucle.
Possibilité d’instancier de multiples instances d’une activité.
Possibilité de créer des activités de compensation,
Activités appelé en cas de problème pour revenir dans l’état antérieur.
Representation des activites
Enchainement des activités
A l’aide de points de jonction (gateway) qui permettent d’exprimer :
Divergences (split)
Convergences (joint)
Dessinés sous la forme d’un losange
Le dessin interne au losange permet de spécialiser la jonction
OU exclusif (XOR)
Choix unique parmi au moins deux chemins possible dans le processus.
Les conditions de chaque chemin sont évaluées une à une jusqu’au moment où une condition se révèle vraie, alors les autres conditions ne sont pas évaluées
Possible de prévoir un chemin par défaut au cas où toutes les conditions se révèlent fausse.
OU inclusif (OR)
Activation de toute les activités pour lesquelles la condition est vraies
La convergence (merge) est évalué à vrai lorsque toutes les branches activées seront terminées
Et Parallèle (AND)
Permet de créer des flux parallèle
Autorise la formulation d’un ensemble de contraintes qui se révélerait difficile à exprimer avec les autres types de jonction.
Exemple : pour le merge, fin du traitement parallèle quand 3 activités sur 5 sont terminées.
Représentation des enchainements
Exemples
Les objets de connexion
Objets de connexions (connecting objects)
Permettent de relier les éléments de gestion de flux
3 moyens
Flot séquentiel (Sequence Flow)
Détermine l’ordre d’exécution des différentes activités d’un processus
3 types de flot séquentiel :
les liaisons normales
relient directement deux éléments les liaisons conditionnelles
contiennent une condition qui doit être évalué à "vrai" pour que la sortie soit activé peuvent remplacer les jonctions XOR et OR
les liaisons par défaut
représentent un chemin dans le cas d’une jonction XOR lorsque tous les autres chemins ne sont pas accessibles
Flot de message (Message Flow)
Représente les différents messages échangés entre deux entités
Exemple : échange de messages entre deux participants Association (Association)
Permet d’ajouter des informations et des artéfacts aux différents élément de gestion de flux
Exemple : des associations entre les points de jonction et un texte descriptif.
Representation des objets de connexion
Autres éléments : artefacts
Utilisés pour fournir des informations supplémentaires sur les processus
Exemple
Objets de données (Data objects)
Décrivent l’utilisation des différentes données (électronique ou non) utilisées
Généralement associés avec les objets de flux
Groupes (Group)
Fournissent un moyen de regrouper virtuellement des éléments d’un processus
Permettent de mettre en avant certaines section du BPD
Annotations (Annotation)
mécanisme qui permet au logiciel de modélisation d’ajouter des informations supplémentaires pour les lecteurs des
BPD
Autres éléments : groupe
2 manières de regrouper les éléments primaires de modélisation
Groupements (Pools)
Représente un participant dans un processus.
Voies (Lanes)
Permet de subdiviser un groupement afin
d’organiser et de
catégoriser les activités au sein d’un groupement.
Exemple : processus de candidature
Composés de 2 groupements
Étudiant
Université
composé de deux voies secrétariat
enseignant
WS BPEL
Un langage ‘ a la XML ‘
pour la programmation des workflows
Plug-in eclipse : http://www.eclipse.org/bpel/
Wikipedia (1)
Business Process Execution Language (BPEL), est un langage de description des procédures d'entreprise qui est issu des langages WSLF (Web Services Flow
Language) et XLANG. Il est sérialisé en XML et vise à rendre possible
lebprogramming in the large. Les concepts de programming in the large et programming in the small distinguent deux aspects de l'écriture de procédures
asynchrones à long terme qu'on voit généralement dans les procédures d'entreprise.
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.
History
IBM and Microsoft had each defined their own, fairly similar, 'programming in the large' languages, WSFL and XLANG, respectively. IBM and Microsoft decided to combine these
languages into a new language, BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft, SAP and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web
Services BPEL Technical Committee.
Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL technical committee voted on 14 September 2004 to name their spec WS-BPEL 2.0.
This change in name was done to align BPEL with other Web Service standard naming conventions which start with WS- and accounts for the significant enhancements between BPEL4WS 1.1 and WS-BPEL 2.0. If you are not discussing a specific version, BPEL is sufficient.
In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People and WS-HumanTask specifications, which describe how human
interaction in BPEL processes can be implemented.
Wikipedia (2)
Relationship of BPEL to BPMN
There is no standard graphical notation for WS-BPEL, as the OASIS technical committee decided this was out of scope. Some vendors have invented their own notations. These notations take advantage of the fact that most constructs in BPEL are block-structured (e.g. sequence, while, pick, scope, etc.) This feature enables a direct visual representation of BPEL process descriptions in the form of structograms, in a style reminiscent of a Nassi-Shneiderman diagram.
Others have proposed to use a substantially different business process modeling language, namely Business Process Modeling Notation (BPMN), as a graphical
frontend to capture BPEL process descriptions. As an illustration of the feasibility of this approach, the BPMN specification includes an informal and partial mapping from BPMN to BPEL 1.1. A more detailed mapping of BPMN to BPEL has been implemented in a number of tools, including an open-source tool known as BPMN2BPEL. However, the development of these tools has exposed fundamental differences between BPMN and BPEL, which make it very difficult, and in some cases impossible, to generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-to-BPEL round-trip engineering: generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated BPEL code synchronized, in the sense that any modification to one is propagated to the other.
Historique
WSFL, May 2001 (IBM)
The Web Services Flow Language
XLANG, May 2001 (Microsoft)
Despite being all-caps, the name is not an acronym.
BPEL 1.0, July 2002 (BEA, IBM, Microsoft)
A merger of WSFL and XLANG.
BPEL4WS 1.1, March 2003 (BEA, IBM, Microsoft, SAP, Siebel)
The specification submitted to OASIS.
WS-BPEL 2.0, March 2007 (OASIS; 39 companies as members of the technical committee)
The first version of the "standard" blessed by a
standards organization.
BPEL en détail (1)
Business Process Execution Language
Initiative soumise à l’OASIS
Spécification d’un langage XML qui permet de décrire l’enchaînement de Web services entre plusieurs participants
Exploite et étend l’usage des documents WSDL
Chaque processus BPEL est exposé sous la forme d’un document WSDL
Il devient alors possible de construire des processus sous une forme déclarative.
En complément WS-Choreography
Spécifiée par le W3C
Permet de modéliser les interactions entre plusieurs opérations de Web services
Cette modélisation se place du point de vue « broker » c'est-à-dire au centre des
échanges entre les opérations à la différence de BPEL qui se positionne d’un point de vue d’un des participants.
BPEL s’appuie sur de nombreuses spécifications XML
XML Schema 1.0
modèle de données XPath 1.0
Support pour la manipulation des données.
WSDL 1.1
Représentation des ressources et des partenaires externes comme des services web WS-Addressing
BPEL en détails (2)
Langage de programmation impérative
séquence, alternative, itération
variable, affectation, portée des variables
gestion des exceptions
Conçu pour d´écrire l’interface comportementale et l’orchestration
processus privé exécutable (orchestration)
processus abstrait des échanges de messages avec les partenaires (interface comportementale)
Processus BPEL
Définition réutilisable
Déploiement de différentes manières
Déploiement dans différents scénarios
Comportement uniforme quelque soit la plate-forme de déploiement
Description du déploiement d’un processus BPEL est en dehors de l’objectif de la spécification.
BPEL en détails (3)
Répond aux besoins spécifiques des services Web
variables de type XML, manipulées avec Xpath/Xquery/XSLT
primitives de réception et d’envoi de messages (références dynamiques)
exécution parallèle et synchronisation de flôts
gestion d’événements
transactions imbriquées et compensation
S’appuie sur WSDL
chaque processus est exposé comme un service web (interface structurelle décrite en WSDL)
des références WSDL spécifient les appels aux services partenaires
les types WSDL décrivent les variables
indépendant de l’implantation fixée en WSDL (liaisons et
services)
BPEL permet de décrire
Tâches de communication
Envoi de messages
Réception de message
Tâches internes
Transformation / manipulation de données
Appel à des applications (services)
Règles de dépendance entre les tâches
Séquences
Choix
Synchronisation
Etc.
Boucle
8 activités en tout
Premier exemple (1)
L’interface du service BPEL en Java like
Un service BPEL est un service web
Il fournit le service bonjourBPEL
public string bonjourBPEL (string s)
Il sera décrit par un document WSDL
Généralement ce document est généré par le container qui exécute le service web
La mise en oeuvre du service BPEL
Le processus BPEL Le service WEB appelé
Premier exemple (2)
Le service web utilisé
Écrit en C#
<%@ WebService language="C#" class="Hello" %>
using System;
using System.Web.Services;
using System.Xml.Serialization;
public class Hello { [WebMethod]
public string HelloWorld (String owner) { return "Hello " + owner;
}
}
Premier example (3)
La description du processus BPEL en Java like {
receive (request) owner := request
invoke (ws, owner, helloResponse) response := retour
reply (response) }
La description BPEL est un service web particulier
Ecrit en XML
Reçoit en entrée une chaine de caractère
La transmet à un service web
Machine : http://localhost:8085
Service : Hello
Opération : HelloWorld
Reçoit en réponse une chaine de caractère qu’il transmet à l’appelant
Le service web appelé est une boite noire dont on ne connaît que l’interface
Interface = description WSDL
Vis-à-vis d’un client le service BPEL est aussi une boite noire
Qui est un service web
Qui possède donc sa propre description WSDL
Principe de fonctionnement (1)
Lecture
Service Web Hello
Interpreteur BPEL
Fichier BPEL
Hello.wsdl import
requete
Principe de fonctionnement (2)
Interpreteur
BPEL Service 1
Service 2
Service 3 wsdl1
wsdl2
wsdl3 Lecture
Requête
Concepts fondamentaux (1)
Un processus BPEL est constitué d’étapes.
= ACTIVITES
BPEL prend en charge des activités de
base et des activités structurées
Concepts fondamentaux (2)
Activités de base = briques élémentaires
Invocation de services web : <invoke>
Attente que le client invoque le processus par l’envoi d’un message : <receive> (reception d’une requete.
Génération de réponse pour les opérations synchrones :
<reply>
Manipulation des données de variables : <assign>
Signal de fautes et d’exception : <fault>
Attente pour une durée déterminée : <wait>
Arrêt du processus entier : <terminate>
Concepts fondamentaux (3)
Activités structurées pour assembler les activités de base
Séquence <sequence>
Définir un ensemble d’activités qui seront exécutées les unes a la suite des autres
Le flux <flow>
Définir un ensemble d’activités qui seront exécutées en parallèle
Aiguillage <switch>
Implémenter des embranchements
Le tant-que <while>
Pour définir des boucles
La possibilité de choisir un chemin parmi d’autres :
<pick>
Initiation du processus
La définition d’un processus BPEL est un document XML utilisant l’élément racine
<process>
On trouve en général un élément de haut niveau <sequence>
On attend le message entrant qui va
démarrer le process : <receive>
Processus synchrone ou asynchrone
Un processus modélise en BPEL est expose en service web.
Le processus BPEL peut etre synchrone ou asynchrone
Pour renvoyer un résultat, un processus
asynchrone ne bloque pas son client mais utilise un callback pour le notifier de la réponse
La plupart des processus BPEL sont de longue durée de forme asynchrone !
Un processus synchrone utilisera la balise
<reply> pour envoyer la reponse a son client
Un processus asynchrone utilisera la balise
invoke pour invoquer une opération de rappel sur
le client.
Les liens vers les partenaires
Toutes les parties avec lesquelles BPEL interagit sont appelées liens vers les partenaires = PARTNERS LINKS
Peuvent etre les liens vers les services web utilises dans le processus
Mais aussi les clients qui appellent le processus
Ou des services jouant les 2 roles
<partnerLinks>
<partnerLink name="client"
partnerLinkType="trv:travel LT" myRole="travelService"
partnerRole="travelServiceC ustomer"/>
<partnerLink
name="employeeTravelStatus"
partnerLinkType="emp:employeeLT"
partnerRole="employeeTravelStatus Service"/>
</partnerLinks>
Paramètres:
Name : Sert de références pour les interactions par ce lien
partnerLinkType: Définit le type de lien
MyRole: Indique le rôle du processus BPEL lui même
PartnerRole: Indique le rôle du partenaire
On ne définit les deux rôle que si le PLT ne le spécifie.
Les types de liens vers les partenaires
Un type de lien vers un partenaire décrit comment deux parties interagissent et ce que chacune d’entre elle offre.
Modélisation de la relation avec les PL comme une tierce partie.
Définit les rôles du partenaire
myRole: Indique le rôle du process
partnerRole : Indique le rôle du partenaire
<plnk:partnerLinkType name="employeeLT">
<plnk:role name="employeeTravelStatusService">
<plnk:portType
name="tns:EmployeeTravelStatusPT" />
</plnk:role>
</plnk:partnerLinkType>
Les variables
Les variables sont utilisées pour stocker les messages échanges entre les
partenaires du processus ou pour conserver des données relatives a l’état du
processus.
Attributs :
messageType : Variable
pouvant contenir un message WSDL
Element: Variable pouvant contenir un élément XML schema
Type: Variable pouvant
contenir un type simple XML schema
Portée globale ou locale
<variables>
<variable name=“a”
messageType=“aType” />
<variable name=“b”
element=“bDescription: />
<variable name=“c”
type=“xs:string” />
</variables>
Réception d’un message <receive>
Attente d’un message entrant
Attributs :
Createinstance :
Gestion du cycle de vie du processus
Indique a BPEL qu’il doit créer une nouvelle instance.
<receive
partnerLink=“client”
portType= “clientPT”
operation=“myOperation”
variable=“myVariable”
createInstance=“yes”
/>
Invocation d’un service web <invoke>
Peut être inclus dans une séquence, un flow
…
Attributs:
InputVariable : Le paramètre qui sera envoyé au partenaire
OutputVariable: La réponse du partenaire.
<invoke
partnerLink=“serviceB”
portType=“myns:MyServi cePT”
operation=“serviceOper ation”
inputVariable=“in”
outputVariable=“out”
/>
Renvoyer une reponse <reply>
Utilise pour renvoyer une réponse dans les processus BPEL
synchrones.
Message de réponse
Message de faute
Attributs:
Variable: le nom de la variable dans laquelle la réponse va être stockée
<reply
partnerLink=“client”
portType=“servicePT”
operation=“serviceOp”
variable=“replyVar”
/>
Les assignation <assign>
Les variables d’un
processus gardent et maintiennent les
données.
Peuvent être de 3 types
Message WSDL
Elément XML schema
Primitive XML schema
<assign>
<copy>
<from variable=“a” />
<to variable=“b” />
</copy>
</assign>
Invocation de services Web asynchrones
On peut invoquer deux types d’opérations:
Synchrones ou asynchrones
Dans le cas d’une invocation synchrone, le processus attendra la reponse
Pas nécessaire d’avoir une construction particulière pour recevoir la réponse
Operations asynchrone
<invoke> ne prend en charge que la première partie de l’opération
On utilise un <receive>, indiquant que le
processus attend un message entrant
Méthode de conception d’un processus
1. Inventorier les Services Web disponibles
2. Définir l’interface (WSDL) du BPEL
3. Définir les types des partners links et les variables
4. Créer le processus
Comment developper (1)
Comment developper (2)
Comment developper (3)
Comment developper (4)
Comment developper (5)
Comment developper (6)
Autres approches
Il est impossible d’écrire directement du BPEL
Utilisation d’un IDE
Eclipse (plugin BPEL)
Microsoft (Visual Studio 05)
Oracle (Suite SOA)
Programmation d’un processus BPEL dans un autre language
BPELJ
Permet de simplifier une bonne partie de l’écriture du processus BPEL
Les actions internes sont écrites en Java (Java Snippets) Expression Java
Liaison variable Java / variable BPEL Possibilité d’appel sur des objets Java
Existe pour d’autres langages
