|
On montre ici deux cas d'usage de BPEL : le premier reste assez théorique compte tenu de la maturité de certains standards ; le second permet d'envisager une solution plus opérationnelle qui tient compte des besoins d'agilité pour l'invocation de services et réduit l'adhérence avec les standards immatures.
1) Un usage théorique de BPEL
Sur cette figure, on montre l’usage nominal de BPEL.
Les principes à noter sont les suivants :
- L’affectation des messages d’entrée des web services est sous le contrôle de BPEL via l’affectation de variables stockées au niveau du contexte BPEL (Assign, Copy).
- Le calcul des routes est également sous le contrôle de BPEL via l’usage d’une grammaire XML de règles comme par exemple Schematron.
Les inconvénients de ce scénario sont les suivants :
- L’implémentation de la gestion du contexte s’appuie sur le standard WS-Context qui n’est pas entièrement stabilisé aujourd’hui. Les éditeurs comblent ce manque par des implémentations techniques propriétaires. On rappelle que WS-Context est une partie de l’appareillage WS-CAF (Composite Application Framework) dont l’objectif est de gérer une démarcation transactionnelle au niveau du contexte (transaction distribuée compte tenu de l’aspect distribué des web services…donc sujet très complexe).
WS-Context est en Committee Draft 1.0 au 24 Octobre 2005 (voir site de l’OASIS). La partie transactionnelle de CAF, c'est-à-dire WS-TXM est encore en draft. De plus, il n’est pas certain que WS-Context remporte la bataille des standards puisqu’il est challengé par WS-Resource Framework issue de la Globus Alliance. WS-Resource Framework intègre des mécanismes intéressants de gestion de contexte qui se base sur WS-Addressing (on procède par get / put sur des propriétés attachées à un endpoint reference) alors que WS-Context ne tire pas profit de WS-Addressing, ce qui est ennuyeux dans la distance.
On rappelle aussi que WS-Addressing est le standard pivot et reconnu par toute la communauté (OASIS, W3C, Globus Alliance, Microsoft…) pour l’adressage de services, utilisé notamment dans l’EDA (Event Driven Architecture) avec WS-Eventing. Certaines études visent aussi à mettre en avant une complémentarité entre WS-Context et WS-RF…
Nous sommes ici sur une courbe de maturité qui nous conduit à 2010.
- A noter aussi l’ambiguïté sur la nature persistante ou non du contexte.
- L’invocation des web services est figée dans la définition du processus. Le changement d’un web service par un autre nécessite l’arrêt du moteur BPEL.
2) Un usage pratique de BPEL
Sur cette figure, on décide de modifier l’usage théorique de BPEL vue précédemment en apportant les ajustements suivants :
- On supprime la gestion de contexte au profit d’un passage complet des données d’un web service à l’autre. Plus les formats de réponse (messages out) sont proches des formats d’entrée (messages in) plus la propagation des données entre les web services est simplifiée. Cette proximité des structures de données milite pour la mise en place de formats pivots XML.
- Les calculs de route sont expulsés de BPEL au profit d’un proxy (au sens AOP) qui déclenche des traitements ad hoc (notamment via une Factory) au moment du after sur l’activité Invoke BPEL. C’est à ce niveau que l’invocation d’un moteur de règles est prévue.
- Le proxy et la factory permettent de changer dynamiquement l’invocation du web service déclenché (par exemple des versions différentes) selon un paramétrage non intrusif sur le code.
L’intérêt de ce mode de fonctionnement est la simplicité d’usage du moteur BPEL et donc l’augmentation de la robustesse d’exécution. A noter aussi que l’on peut parfaitement mettre en place un moteur de séquencement spécifique sans embarquer une technologie BPEL ; c’est la raison pour laquelle sur cette figure le point d’entrée ‘Bpel Compute’ est représenté en pointillé.
| |
|
"BPEL ne permet pas de gérer les interactions humaines"
|
| |
Néanmoins, les inconvénients de cette solution sont les suivants :
- Pas de gestion de contexte et donc pas de possibilité de gérer une démarcation transactionnelle. Il faut alors prévoir des compensations applicatives pour défaire des mises à jour qui deviennent invalides en cours d’exécution du processus. De toute façon, comme nous l’avons vu précédemment, BPEL est incapable de le prendre en charge de manière automatique et standard puisque WS-CAF n’est pas stabilisé à ce jour.
- Il n’est pas toujours possible (ni souhaitable) de prévoir le design des web services de telle sorte que le flux de données du processus puisse être communiqué simplement entre les web services. Néanmoins, on simplifie l’exécution des processus en bâtissant un système de telle sorte que cette propagation de données entre les web services supprime la gestion de contexte : on arrive alors à un principe de web services véritablement lego (mode de fonctionnement plug and play).
- Pas de modélisation graphique de l’ensemble du comportement métier du processus puisque les règles sont expulsées à l’extérieur de la grammaire BPEL. C’est un inconvénient majeur ; il faut que le modeleur graphique permette la jonction avec le moteur de règles, au moins pour déclarer le paquet de règles invoqué au moment de l’After et les données véhiculées vers le moteur.
Interaction avec l’utilisateur
Si vous aviez des doutes… BPEL ne permet pas de gérer les interactions humaines. Evidemment, l’orchestration va au-delà du séquencement programmatique des web services ; elle englobe aussi les interactions avec les utilisateurs : définition des droits sur les processus ; prise de décision sur une route ; alimentation des corbeilles de tâches ; gestion des dépassements de délai ; affichage de l’interface utilisateur pour une tâche ; etc.
Une initiative récente de SAP et IBM (comme pour les sous-processus cités plus haut) tente d’apporter un complément à la grammaire BPEL afin d’introduire un type supplémentaire d’activité nommée « people activity » : le moteur BPEL crée une tâche et la poste dans les corbeilles éligibles ; c’est donc un comportement différent du classique « invoke activity ».
Il faudra plusieurs mois avant que l’OASIS intègre (ou pas…) cette initiative et plusieurs mois supplémentaires avant que les éditeurs ne l’implémente. Ici également, nous sommes face à un cycle de maturité BPEL qui nous amène jusqu’en 2010. Il faudrait aussi prendre en compte XPDL de la Workflow management coalition…
| |
|
"Qualité de services : il y a peu d'éléments stables sur ce point"
|
| |
Qualité de services
Il y a peu d’éléments stables sur ce point à ma connaissance, l’effort de standardisation se fixant d’abord, et c’est bien normal, sur le management de chaque web service pris de manière isolée (voir WS-DM). Evidemment, les besoins vont au-delà de la définition d’un correlation set partagé entre les web services d’une même instance de processus.
Il faut être capable de définir des SLA différenciés sur chaque web service dans le contexte particulier de l’exécution d’un processus ; fixer des exigences de SLA directement au niveau du processus et vérifier leurs cohérences avec celles prévues au niveau de chaque web services orchestrés…
A ce jour, il faut se contenter d’un développement spécifique qui s’appuie sur une grammaire XML propriétaire (plus ou moins…) afin de déclarer les comportements de SLA du processus et des web services qui le compose. Puis, on prévoit un Aspect de monitoring (au sens du proxy AOP sur le moteur BPEL tel que présenté plus haut dans ce papier) pour piloter l’ensemble ou co-piloter avec un outil WS-DM : il s’agit d’un appareillage complexe qu’il convient de spécifier en limitant le niveau d’ambition.
Progressivement, les outils de management des web services combleront le vide actuel ; c’est aussi une courbe de maturité jusqu’à 2010.
Modélisation
C’est un sujet déterminant… mais aujourd’hui très instable. Evidemment, il est impossible de développer à la main une grammaire BPEL à une échelle industrielle. Donc, XML doit être masqué par une modélisation graphique adaptée.
Plusieurs scénarios sont possibles :
- Un modeleur propriétaire : souvent puissant mais pas standard…
- UML avec le Diagramme d’activités.
- BPMN (Business Process Modelling Notation) du Bpmi.
- DSL (Domain Specific Langage) de Microsoft.
Les critères suivants d’aide à la décision sont souvent mis en avant :
- Peu (pas) d’intérêts à générer du BPEL à partir d’une vision métier de haut niveau modélisée en BPMN sauf s’il s’agit d’utiliser un moteur BPEL dans l’optique d’exécuter des simulations de comportement. Nous ne connaissons pas de tels outils à ce jour.
- UML reste le standard pour la modélisation de processus ayant une vocation à l’implémentation informatique pour la production (et pas seulement la métrologique au sens BPMN) ; la difficulté réside dans le choix du profile UML associé à BPEL. A ce jour, nous n’avons pas vu de profile UML – BPEL standard proposé par l’OMG. Il faut donc se contenter de profiles propriétaires peu satisfaisants car ils verrouillent les modèles dans chaque outil de modélisation. A notre connaissance, IBM est le plus avancé dans la définition du profile UML pour BPEL.
- Microsoft avec DSL se pose en concurrent d’UML et s’engouffre dans l’ingénierie des modèles pour contrer la vague stratégique du MDA (Model Driven Architecture) de l’OMG. Il s’agit d’un enjeu bien plus général que celui de la modélisation des processus et de la production de BPEL. Nous avons eu l’occasion de publier plusieurs papiers sur le thème de la formation à l’ingénierie des modèles qui constitue l’enjeu stratégique du SOA sur la période 2005-2010.
- Enfin, l’acceptation d’un modeleur propriétaire peut être tactique, mais pas un choix sur le long terme. Dans un domaine parallèle de la modélisation des processus, on constate par exemple le déplacement des outils de modélisation propriétaire XML vers la prise en compte des diagrammes de classes UML (voir par exemple la société Altova et sont produit vedette XMLSpy).
UDDI
Il existe une technical note (TC) de l’OASIS en date du 25 Juillet 2004 (pas très récente) qui définit la projection des concepts BPEL dans ceux d’UDDI. Il faut donc rester attentif sur le niveau de support proposé par les éditeurs de solution UDDI.
Il est vrai que UDDI est peu utilisé par les entreprises ; mais le mouvement vers UDDI pourrait s’accélérer fortement en 2006 car il s’agit de se doter de registry qui couvre non seulement WSDL, BPEL mais aussi et surtout… les nombreux schémas de données (XSD) qui d’ailleurs devraient plutôt s’appuyer sur les registries compatibles ebXML et tirer profit du standard Iso 11179 de documentation de la donnée : encore un chantier SOA important ; celui de la registry unifiée (UDDI+ebXMLr+ISO 11179).
|
Pierre Bonnet