Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Stefan Tilkov on Sep 28, 2006
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.
Free $40 SOA Demystified Book Offer
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
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.
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
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...
@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.
Bruce Silver has an interesting follow-up in which he describes how Oracle bridges the business analyst/application designer gap.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply