BPEL is a work in progress. Like any of its predecessor standards (SQL, XML, etc.), industry gadflys and naysayers will bash BPEL right up to the point where it's pervasively adopted, then they'll jump on the bandwagon and claim they played a major role in shaping BPEL's success.

BPEL 1.1, while certainly imperfect, provides a rich grammar for expressing a broad range of service orchestrations. BPEL 1.1 (with or without vendor extensions) has been used as the cornerstone of many deployed SOA applications. Thus, assertions about BPEL's limited value as an execution language are now being laid to waste by real world anecdotes. Like it or not, BPEL is rapidly achieving "de facto standard" status. And BPEL 2.0 represents a meaningful step forward, adding important constructs and resolving prior ambiguities.

The thesis that BPEL's primary value lies in process portability (or even more absurd, interoperability through abstract processes) flies directly in the face of other successful standards. The real value of any standard is KNOWLEDGE portability. SQL is a case in point. Oracle's PL/SQL and Sybase's Stored Procedures are proprietary, non-portable extensions to the SQL standard. Yet millions of IT professionals know SQL syntax and semantics, and enjoy the enormous leverage resulting from that portable KNOWLEDGE. While it's true that standards enable interoperability and (in theory) reduced switching costs, portability of KNOWLEDGE is really where the rubber meets the road. BPEL is directly analogous to SQL in this regard.

With regard to transitions from BPEL 1.1 to 2.0, the level of rework will depend on how the 1.1 processes were constructed. Our 1.1 users have generally been mindful of the reality that they're building orchestrations based on an evolving standard, and they've factored some rework effort into their plans. That said, our BPEL 2.0 products are 100% backward compatible with 1.1. So ActiveBPEL users can simultaneously execute both 1.1 and 2.0 orchestrations in the same server, allowing them to migrate from 1.1 to 2.0 on timetables that suit their individual needs.

Fred Holahan
Active Endpoints, Inc.

The idea of a well implemented BPEL 2.0 is that many of the things people complain are missing, are quite easy to implement in the language as a sub-process, for example, human task workflow. However, this depends on a good implementation. Languages such as BPEL are not designed to be used only to expose services of existing technologies. BPEL needs an engine. This is called a process virtual machine. Good BPMS products include a process virtuall machine, and great design tools. For example, a tool can be used to design a workflow process, which can then be re-used within any other process. A process virtual machine is therefore a superset of typical workflow engines, allowing the whole process to be mapped, including sophisticated integration paths, data processing etc. This is not apparent from reading the BPEL spec. Only through an implementation can the value of a BPMS be seen. Having said all that, I'm not a great fan of BPEL myself. I preferred BPML. It was formally complete and rigorous in ways BPEL is not. But BPMS vendors were forced to adopt BPEL because the big boys in our industry appeared not to want to, or could not, implement BPML. So debates on BPEL are tied up with past debates over BPEL versus BPML. The ironic thing is, a good BPMS can use either, for the process virtual machine is what is complete and rigorous. Ultimately, BPEL, or BPML, is only an external syntax for the engine's execution semantics. Also, be aware that BPEL only specifies one participant's execution. A BPMS process engine must exectute across independently executing BPEL threads. These "end to end processes" are where the power of a BPMS lies. The BPMS can expose and reuse processes wherever they lie, in old code or new. (ex co-chair BPMI.org)

On the topic of standards and portability, I have been wondering if we could ever expect certification for WS-BPEL engines? Given that the specification (1.1) semantics are loosely defined is this possible?

If not, the portability of protocol and knowledge cannot be assured.