Intelligent Enterprise

Keith Swenson is one of the true superheroes of BPM, and a pioneer in the development of interoperability standards. Known for his stalwart defense of XPDL, he periodically feels called upon to insist that XPDL does not compete with BPEL… then usually adding that XPDL is actually better. But I've always felt that Keith obscures the real difference between XPDL and BPEL and their relationships to the "real" BPM standard, which is BPMN.

The latest fracas started a couple days ago when Keith claimed victory in the non-war from the fact that eight of the 12 vendors in the top-three Quadrants of the Gartner MQ support XPDL. Even though a number of those vendors also support BPEL, at least as an interchange format for automated fragments of the process, it is fair to say that vendor support for XPDL is probably more widespread than vendor support for BPEL. So let's stipulate that - no problem.

An anonymous commenter to that post said, paraphrasing, "Yeah I work for one of those vendors on your list, and for us, XPDL is a checkoff item and actually BPEL is more important as a standard." Well, that fried one of Keith's circuit boards and led to his apples-and-oranges post, where he once again tries to explain why XPDL is orthogonal to BPEL (but still sort of better).

It's true that XPDL and BPEL do different things, and Keith does describe the essential difference, but he couches it in language that slants the implications to users. His example is a reasonable one, a BPMN diagram of a simple split and join. Keith describes the BPEL representation, which conveys the process semantics of the concurrency and join, as "lossy" and "one-way" because it does not capture — as XPDL does — the precise shapes of the BPMN activities, gateways and events, the bends in the arrows, etc.

In other words, XPDL captures the diagram while BPEL captures the process semantics. Keith dismisses the latter as just the information an "execution engine" would need to know. Technically that's true of BPEL, I suppose. But which of these best represents the process model? The part that Keith glosses over is a process diagram is not the same as a process model. The argument over whether BPEL or XPDL is more "portable" is based on different interpretations of what portable means. If you mean the same process semantics can be executed on two different engines, then BPEL is more portable. If you mean that the same diagram can be created in two different tools, then XPDL — especially if you allow the target tool to ignore the graphical details that don't carry over.

Which aspect of portability is more valuable? It depends on what you're trying to do. If you're just trying to glue together tool A and tool B, XPDL has more flexibility. The freedom to ignore the parts that don't map exactly is implicit. Of course, you would need a side agreement between vendor A and vendor B to make the thing work, but let's not talk about such details.

With BPEL you don't have the freedom to ignore elements you don't support. Those are called proprietary extensions. They live in their own namespaces, and a valid criticism of BPEL 1.1 is that real processes need too many of them. It's a bit better in BPEL 2.0, but human tasks, subprocesses and other basics still require extensions, such as the nearly mythical BPEL4People.

So let's get to the real question. BPMN is a modeling notation — more than just a diagram, since each element has defined process semantics, abstracted from implementation details — but BPMN has no official XML schema, i.e. no interchange format. XPDL 2.0 was explicitly created to capture all the elements of BPMN 1.0 for interchange, but — here's the part that Keith omits — that's from a diagram portability perspective, not a model portability perspective. That's because OMG (actually this dates back to BPMI) never defined which BPMN elements and attributes, and associated process semantics, have to be supported by a "compliant" tool. Intermediate events? Compensation? Workflow engines traditionally didn't support those, so they are conveniently left out of BPMN tools from many vendors. I'm not sure what they do when they import XPDL that has such elements. Maybe drop them on the floor, with apologies.

My view is that preserving BPMN shapes, colors and line bends, while ignoring process semantics that don't fit in the other tool, is not a particularly useful accomplishment. Each tool usually has its own graphical representation of model elements anyway, so I can't imagine the graphical details are really preserved in reality.

Bottom line is that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models — not diagrams, models — that is independent of implementation architecture. OMG is supposedly developing that based on BPDM, its formal metamodel for BPMN, now nearing finalization. I said last spring at OMG Think Tank that in BPDM's absence, XPDL had a window of opportunity to become the de facto serialization standard for BPMN.
But by focusing on diagrams not models, and positioning itself versus BPEL not BPDM, XPDL has let that window close. They might argue that adding BPMN compliance rules and semantics to XPDL is not their job but OMG's. But that was in fact the opportunity, soon to disappear.

Here's the puzzling part. I've actually seen a draft of BPDM and see no signs of a BPMN schema. Actually I found the thing near-incomprehensible; there was something about MOF and XMI but not a schema. It made me wonder whether BPDM would actually include a schema for BPMN, or just some kind of production rules that ensure conformance to the BPDM metamodel. If you know the answer to this question, please comment to this post.

If OMG does not publish a BPMN schema, I see more consternation in BPM-Land and a second chance for XPDL to get it right. If BPDM produces a schema and a list of must-support BPMN semantics, then I predict next year Keith will forget about BPEL. He'll be writing about why XPDL is different from BPMN… but sort of better.