BEA et le support de BPEL

Ces derniers temps, BEA semble être sur la défensive dès que l'on aborde le sujet de BPEL. Selon des propos rapportés dans cet article de InfoWorld, Bill Roth, l'un des vice-présidents de BEA semble jouer sur le fait que la spécification BPEL 1.1, soumise à l'OASIS en 2003, n'est pas encore un standard et n'est donc pas digne de considération par les éditeurs et les clients :

"I think our position is that frankly, Oracle's making too much of BPEL. Sure, it?s a useful way of orchestration. [But] the fact of the matter is that BPEL has been approved by absolutely no standards body."

"The important thing is [BPEL is] not done yet and while we look at BPEL as a promising development, Oracle users are taking a huge risk by developing on BPEL 1.1 and getting locked into something that they think is standard but isn't."

La standardisation de BPEL par l'OASIS est en cours (voir les travaux du comité technique dédié) et le standard devrait être publié avant la fin de l'année 2005. Mais comme le rappelle Edwin Khodabakchian, ex-CEO de Collaxa (le créateur du produit BPEL Manager, devenu depuis Oracle BPEL Process Manager), dans ce commentaire relatif à un article de Mark Carges, il y a peu de différences entre la version soumise à l'OASIS (BPEL 1.1) et le futur standard OASIS (WS-BPEL 2.0, parfois aussi appelé BPEL 2.0).

Par ailleurs, il faut toujours se méfier de l'expression "supporte BPEL". En général, cela signifie que le produit en question n'implémente pas nativement la spécification BPEL et qu'il est simplement capable (au mieux) d'importer et d'exporter des scripts BPEL, très souvent au prix de grosses difficultés de transposition d'une sémantique syntaxique vers l'autre. Ce problème limite fortement la portabilité des scripts BPEL entre plates-formes techniques hétérogènes. Rappelons au passage que BPEL est la seule de toutes les spécifications de la pile WS-* pour laquelle la portabilité est aussi importante que l'interopérabilité.

Au sujet de ces difficultés, la consultation de ce document relatif à l'outil d'importation de WLI 8.1 est instructive (voir le § intitulé "Known Limitations and Issues") :

"This section details some known limitations and issues of the BPEL Import tool. The majority of these issues exist because of the inherent differences between the JPD and BPEL languages."

La consultation de cet autre document relatif à l'outil d'exportation de WLI 8.1 est également intéressante (voir le § intitulé "Known Limitations and Issues").

Comme Edwin Khodabakchian, on peut voir dans ces propos de Bill Roth une forme de FUD de la part de BEA, manifestement gêné dans la transformation de ses produits WebLogic Integration et Workflow en solutions implémentant nativement BPEL et non pas un équivalent propriétaire Java (aka JSR-207 - Process Definition for Java - PD4J) comme à l'heure actuelle.

Aujourd'hui, quel est le meilleur choix : un produit qui supporte très mal la version BPEL 1.1 et dont les scripts de processus devront être en bonne partie réécrits ou un produit qui supporte bien BPEL 1.1 et dont les scripts de processus devront faire l'objet d'ajustements mineurs pour s'adapter au standard BPEL 2.0 ?

D'une manière plus générale, de nombreux éditeurs de produits Java (dont BEA) ne semblent pas avoir intégré le fait que, dans les architectures WSOA, les artefacts XML (descriptions WSDL, schémas de messages XML, descriptions de stratégies, ...) sont passés au premier plan et que les artefacts Java (composants EJB, POJOs, ...) doivent s'effacer au second plan.

Ainsi, la perle BPELJ spécifiée par BEA et IBM est un exemple de la tentation permanente qui vise à réintroduire des éléments technologiques propriétaires (Java en l'occurence) dans des éléments descriptifs XML normalisés (ou en voie de l'être).