A en croire la majorité des éditeurs, il est temps de mettre en œuvre BPEL… D’ailleurs, les offres foisonnent et les besoins d’orchestration des premiers web services s’expriment plus massivement par les entreprises.

Chacun comprend l’intérêt de disposer d’un moteur d’orchestration respectueux des standards web services (WSDL, SOAP…). Cependant, quels sont les contraintes et les points de vigilance en termes de maturité ? Comment juger le respect du standard par les éditeurs alors que BPEL s’adosse à d’autres standards non stabilisés comme la gestion de contexte (WS-Context) et la gestion de transaction (WS-TXM) ?

Pour aider à une meilleure compréhension des apports et contraintes actuelles de BPEL, cet article effectue un tour d’horizon du sujet : mode d’invocation des web services, gestion des sous-processus, calcul des routes, mode d’usage du moteur, interaction avec l’utilisateur, qualité de services, modélisation, UDDI.

Le mode d’invocation des web services en BPEL reste figé car il s’appuie sur une déclaration formelle en XML : on nomme les WSDL (portType ou endpoint) avec lesquels le processus interagit… C’est donc une décision prise au moment du développement qui n’est plus révisable lors du passage en exploitation.

Le processus BPEL ne sait pas introspecter automatiquement un annuaire de services, par exemple UDDI, pour dynamiquement choisir la bonne version d’un web service selon le contexte d’exécution du processus…

Pour remédier à cette rigidité, on implémente les web services orchestrés par BPEL sous la forme de simple façade dont le rôle est d’invoquer une factory qui renvoie, selon le contexte d’exécution, la bonne version de l’implémentation du web service (le endpoint).

Cette factory est intégrée au sein du moteur BPEL, afin d’offrir des fonctionnalités packagées (on conseille d’être attentif sur ce point lors de la sélection d’un moteur).

Si le moteur BPEL accepte des points d’extensions par Aspects (au sens de l’Aspect Oriented Programming), il est possible de le surcharger sans modifier le code, par simple paramétrage. Par exemple, il est intéressant d’ajouter des classes techniques pour le traitement des transformations de format entre deux invocations de web services ; de même, il est utile d’ajouter des services techniques de métrologie (BAM), de suivi du SLA…

Ces points d’extension sont situés, a minima, en before et after des activités BPEL (Invoke, Receive…) et à chaque modification des variables logées dans le contexte de données du processus (Assign, Copy).

L’architecture par Factory et Aspect offre un haut niveau de flexibilité qui permet d’aller au-delà de l’intention d’agilité que la grammaire BPEL seule ne peut pas offrir. En adossant à cette architecture un outillage fonctionnel de gestion des données de référence (paramétrage de la factory et des aspects), il devient alors possible d’agir de manière sécurisée sur le comportement des processus sans se contraindre à un passage systématique par un cycle d’ingénierie : plus besoin de recompiler, d’arrêter et de relancer le moteur BPEL…

La version actuelle de BPEL ne permet pas de modéliser des sous-processus et encore moins de les assembler… Donc, l’orchestration s’opère uniquement sur le grain le plus fin des web services, ce qui est très gênant (et même rédhibitoire) à une échelle industrielle. En effet, la réutilisation d’une partie des processus est caduque.

Bien sûr, on peut toujours admettre qu’un sous-processus est un web service sollicité par une activité Invoke d’un processus plus large… mais malheureusement dans ce cas, on obtient l’exécution de deux instances de processus qui sont incapables de se partager un contexte de données (exécution orthogonale des deux processus…).

Récemment (septembre 2005), IBM et SAP ont proposé WS-BPEL SPE (Sub Processes) qui vise à remédier à cette contrainte… Il faudra sans doute attendre quelques mois pour sa prise en compte dans les travaux de l’OASIS et encore quelques mois supplémentaires pour son implémentation par les éditeurs. Ainsi, la grammaire BPEL s’étend du mot clef subprocess…

BPEL ne définit pas de grammaire pour le calcul des routes ; selon les moteurs BPEL; on peut opter pour différentes stratégies avec Xpath, Schematron… mais aussi directement du code java embarqué dans la définition XML de BPEL (pas forcément recommandé pour la portabilité…).

Dans la pratique (encore peu répandu compte tenu du niveau faible de pénétration de BPEL), on privilégie la démarche suivante :
- Routage technique réalisé en Schematron (voir aussi RuleML, xlinkit..).
- Calcul des routes métiers sous la forme d’une invocation à un web service frontal d’un Business Rules Engine (BRE). L’objectif est d’évacuer les règles métier de la grammaire BPEL afin de favoriser la maintenance et la réutilisabilité des paquets de règles.

Néanmoins, dans le cas où le calcul des routes métiers est suffisamment simple, on peut faire l’économie d’un BRE et s’appuyer exclusivement sur Schematron.

On peut aussi mettre en place un proxy (AOP) en after (post-condition) des activités Receive BPEL afin de déclencher automatiquement l’invocation du BRE sans qu’elle soit modélisée dans le processus. Une façade de paramétrage permet de confirmer l’invocation du BRE ou non selon les besoins de configuration du processus : par exemple, en fonction que le processus s’exécute pour un partenaire ou en interne, le BRE est sollicité ou non.

Ce principe permet d’alléger la modélisation du processus et peut s’étendre à toutes les pré- et post-conditions des activités Invoke et Receive BPEL. L’utilisation d’un outil de paramétrage des invocations par activité BPEL est indispensable afin de garder le contrôle sur les configurations.

Il faut penser à la mise en place d’une solution de Master Data Management qui permettra d’organiser les configurations sous la forme d’un arbre d’héritage : une configuration racine (par défaut) du processus BPEL, puis des spécialisations successives et hiérarchiques par type de consommateur (filiale, partenaires, internes…), type de canaux (internet, extranet, intranet…), type de produit (classique, meduim, gold…)…

Il faut aussi prendre en compte le besoin ou non d’une publication vers les Consommateurs de tout ou partie des règles de calcul de routes. Dans le cas où la publication est nécessaire, il peut être intéressant de s’appuyer sur un langage XML standard (ou en devenir de standard…) comme Schematron.