Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Posted by Stefan Tilkov on Sep 28, 2006 01:32 AM
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.
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Scaling a Massively Multi-player Server Casestudy: Terracotta on SmartFoxServer
Introducing Project Zero: Building RESTful services for your Web application
Create a photo album application with Project Zero and REST design principles
Rainmaking - IBM's software virtualization strategy (Jerry Cuomo CTO blog)
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.
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
5 comments
Reply