mult.ifario.us

Over on InfoWorld, David Linthicum has some misdirected and FUD-filled comments (original and follow-up) on the impending release of the WS-BPEL 2.0 standard by OASIS. Bruce Silver, Steve Hoffman, and Fred Holahan are quicker on the draw in responding on the topic, but I'll come out of semi-retirement as a BPEL wonk to comment. (I could never quite get off my kiester to go after David Chappelle when he blogs about BPEL, partially because he has the clever defensive tactic of a broken blog that makes it impossible to link directly to entries...)

First off, if there are any genuine issues with the consistency of the specification, behavioral, semantic, or otherwise, then those should get presented to the OASIS BPEL TC promptly for consideration. I doubt it. The TC discussed literally thousands of issues — at length and sometimes ad nauseum. Of the 308 of those that were worthy of issue status, all have been resolved with the input of several dozen smart folks (and a few dumb ones).

As far as BPEL4WS 1.1 goes, finding a reasonable profile for the language isn't that onerous. (In fact, it's easier to figure out a behavior profile than to decipher the combined licensing terms from the specification's "owners".) Make a choice about variable declarations and fault-handlers, think hard about event-handlers, etc., and you can work it out. Someone else might make different choices, but c'est la vie. Row-level locking works differently in every SQL database, and no one's crying about it. The PXE engine offered side-by-side execution of a working profile for BPEL4WS 1.1 and a spec-tracking version of WS-BPEL 2.0 starting back in 2003 (and was the first engine to do so), with the ability to apply management, deployment, and debugging functionality equally to both 1.1 and 2.0 processes within the same runtime container. (PXE is now part of the ODE project under incubation at Apache and part of Intalio's open-source BPMS.) This was purposeful, up-front future-proof design; there was no planned or inadvertent obsolescence, no subterfuge. Side-by-side support should be the baseline customer expectation.

Before banging on a drum about portability, what would portability mean for an orchestrated process? No one should expect that vendor-specific goodies are portable. I can't run PL/SQL in DB2, and I'm cool with that. Does portability mean demonstrable behavior equivalence, up to non-determinism? A reasonable definition would be that a process written in vanilla WS-BPEL 2.0 should run in any engine that claims to be compliant, up to fussing with deployment descriptors. (Neither the 1.1 nor 2.0 versions of the specification address the way that BPEL ports are bound to concrete ports, so this is different across the various vendors.) For what it's worth, we had reasonable luck taking BPEL4WS 1.1 processes created with other tools and running them, with a modicum of fiddling.

I said it in 2004, Assaf said it recently in a long guest post over on IT|Redux, and it's still true: BPEL is an orchestration execution language, in a role analogous to assembly language. To quote myself:

And that's all you should expect it to be. Diagramming tools? Not in there — I'd recommend taking a look at BPMN. Workflow add-ons? Not in there — check out BPEL4People or just (gasp) model your workflow components as services.