With the recently released public review draft of the WS-BPEL 2.0 specification, an interesting debate has started about the relative merits of BPEL in general and issues surrounding portability, interoperability, and compatibility.
Dave Linthicum started the debate with a blog post on WS-BPEL's lack of backward compatibility. He does not have kind words for BPEL 1.1:
Let's face it, BPEL 1.1 was a bad standard that left so much out that many end users and vendors found it useless. In response, the vendors put a ton of proprietary extensions in their BPEL 1.1 - based products, thus diluting its value to the point of "why bother."
Active Endpoints co-founder Fred Honahan replied in a commment:
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.
Bruce Silver chimed in by citing both this post and David's response, and questioned the future role of BPEL for BPM:
If you look at why BPEL 1.1 isn’t portable for BPM, it comes down to three basic limitations in the language: no support for human tasks, no support for subprocesses, and pitiful data manipulation. BPEL 2.0 mostly fixes the data manipulation part, but not human tasks and subprocesses. So how can you use an orchestration language without support for human tasks and subprocesses? For creating business services! You get more than Fred’s “knowledge-portability.” You get actual runtime portability, and a choice of engines at a commodity price. So it has real value there.
Paul Brown, creator of the open source PXE BPEL engine (now part of Intalio) and Steve Hoffman jump in to defend BPEL against what Paul claims is FUD.
BPEL as a solution to orchestration of services is a feature that is requested almost everywhere. It remains to be seen whether BPEL will share the fate of many other check box features or will assume a key role in successful SOA deployments.