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.

The classic parable of the blind men and the elephant applies to some recent proclamations about BPEL and BPMN (and about BPM and SOA, for that matter) being at odds, and there is long line of blind men waiting to take their crack at sizing-up the BPM elephant. I started out believe that the elephant is defined by its back end, the execution aspects, and that's where FiveSight developed a specialty. Nonetheless, customers (who wanted to ride on the elephant) educated me about its other properties, and combined with the expectation that standards would help define the parts of the BPM animal, the breadth of customer expectations is one of the things that drove our specialization. In 2003, we set out to build the “best back-end in the business”, gave it the code name “JLo”, and took an OEM stance. (Note to any entrepreneurs in the audience — Either you are an elephant vendor or your customers are the elephant vendors. The middle ground is not populated by successful businesses.)

I still recall a customer encounter (probably from 2002) for FiveSight's BPM-ish product that predated our BPEL effort. A customer was interested in an email widget to mass-mail customers. (Never mind that mass emailing requires more than a bit of art in dealing uniformly with bounces, proper MIME enveloping for correct viewing by different clients, delivery throttling by large email account providers, etc.) We built one more or less blind that wrapped up some of the usual JavaMail functionality and took a string as input for the body. We showed it to the customer, including a sidebar about how easy it was to implement the widget complete with a code sample (“Even your IT staff could do it, Ms. Customer!” <wink wink>). The business analyst spoke up and asked “Can it do RTF editing? We'd like to have consistent branding with a logo and specific fonts.” Ummm, yeah...

Aside: Once upon a time, on a trip to Japan, I met someone whose title was actually “Business Analyst”. I was tempted to frame his card.

The point of the story is that there are modeling aspects and execution aspects to a process, and they are closely related but not equivalent. BPMN is a modeling notation for describing processes in business terms. BPEL is a service orchestration language for combining services that was designed specifically for a WSDL-based SOA. It is possible, by design but not without effort, to generate orchestration language artifacts from modeling notation artifacts. One could observe that if nothing below the model mattered, then the orchestration language is irrelevant, and that would be true if the processes lived in a closed, black box. But that's so BPM 0.9 — vendors should know better than to imagine that they can shoehorn their customers into an architectural stovepipe when there are other alternatives available.

Agility requires degrees of freedom, and the combination of BPMN and BPEL to bind the higher-level modeling aspects of BPM onto SOA provides two important degrees of freedom. First, the modeling tool is decoupled from the execution environment. (Note that a good backmapping from the BPEL to BPMN is important, but that's a property of the mapping used.) Second, the processes are first-class citizens of a service-oriented architecture, fueling use and reuse outside of the context of the modeling environment.

Via Charles Dietzel and others, the upcoming Java Studio Enterprise contains BPMN tooling and integration with PXE! The getting started guide for BPEL functionality has some nice screen shots and a walkthrough of a classic travel reservation example process.