Debate: The Future of WS-BPEL

Posted by Stefan Tilkov on Sep 28, 2006

Sections

Enterprise Architecture

Topics

Orchestration ,

SOA

Tags

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.

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.

1. Back to top

   The good and bad of BPEL

   by Paul Fremantle

   While I admit I haven't caught up with all the details of BPEL 1.1 vs 2.0 (hint: maybe a good topic for an InfoQ article?!), I think there is clearly one significant advantage and one significant failure 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.

   Reply

2. Back to top

   Quick recap of what's new in WS-BPEL 2.0

   by John Evdemon

   A presentation (PowerPoint format) summarizing the changes from BPEL4WS 1.1 to WS-BPEL 2.0 is available. Some of this information is also available in the TC wiki. This presentation is one of the resources developed to support the non-normative Primer for 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).
   
   Thanks!
   
   John

   Reply

3. Back to top

   Re: The good and bad of BPEL

   by Steve Hoffman

   Paul, I don't think it's a big deal to download and install a tool. In fact, I think most users welcome tools over using text editors and command-line shells. And the availability of excellent tools that free makes it a moot point -- not to mention the pending availability of open source tools.
   
   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...

   Reply

4. Back to top

   Re: The good and bad of BPEL

   by Paul Brown

   @PaulF:
   
   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.

   Reply

5. Back to top

   Interesting follow-up regarding Oracle's BPM offerings

   by Stefan Tilkov

   Bruce Silver has an interesting follow-up in which he describes how Oracle bridges the business analyst/application designer gap.

   Reply

• Older >