Debate: The Future of WS-BPEL
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.
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.
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.
The good and bad of BPEL
The advantage? The ability to visually map out business processes in a form that will be executed. The fact that there is a standard model for designing processes that can be shared with the business process owners graphically is absolutely the #1 benefit of BPEL.
The disadvantage? The fact its almost impossible to write BPEL without a tool. We've seen many technologies fail because they were too complex to submit to a text editor. EJB<3.0 are a prime example of a technology that is too painful to handle without good tool support. I love tools, but having to download >100Mb of code to get started with BPEL is a big inhibitor to many developers.
What will sway it? I think the key for many organizations is how well they implement the lower layers - in an organization with many available services, BPEL will succeed. If a company has to first go and implement many many services before they have critical mass to start choreography, then thats going to be a significant inhibitor.
Quick recap of what's new in WS-BPEL 2.0
The WS-BPEL 2.0 specification is in Public Review until November 9th. We would love to see some constructive feedback on the spec. You can submit your feedback on the spec here.
Issues identified during the Public Review process are updated on a weekly basis.
For anyone who has not yet read the WS-BPEL 2.0 spec it is available in PDF, DOC and XHTML formats.
A RDDL document is also available that includes links to all relevant resources (including the WS-BPEL 2.0 schemas).
Re: The good and bad of BPEL
But you got it right about folks needing to get their services in order. The biggest challenges to the BPEL projects I do are: 1) service interfaces in flux; and 2) folks don't understand their own process requirements, even when simply accessing or replacing existing (often mainframe) logic.
BPEL is definitely most useful to folks who already have their act together. As usual, the rich get richer...
Re: The good and bad of BPEL
I hate to tell you that there is no visual stereotype associated with BPEL. On the one hand, if it just consisted of sequence/flow, etc., then it would look like a flowchart, but event handlers, various forms of iteration, and links make faithful and all-encompassing visual representation difficult. Moreover, any visual notation for BPEL is proprietary and useful visual sugar that the editor adds is unlikely to be present in BPEL files from other sources.
Notations that "compile" to BPEL, e.g., BPMN are the way to go, and I think that with WS-BPEL 2.0 on its way out the door, you'll see a usable, non-XML notation pop up sooner or later. (BPEL is no worse than WSDL, XML Schema, DocBook, or other XML dialects; an editor just has to have the right kind of sugar to get cross-references and sub-syntaxes (like XPath) right.
Interesting follow-up regarding Oracle's BPM offerings
Ruslan Meshenberg Sep 21, 2014