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 8 of the 12 vendors in the top 3 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 yesterday’s 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. BPEL is BPEL and you have to support everything in the spec. The rest 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 in 2.0, 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 — 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 their 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 looked there without success for any sign 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.
I have been reading your blog for quite some time. This is one of your most illuminating, entertaining posts.
Fred Holahan
Adding BPMN into the fiery mix…
As expected, Bruce added BPMN into the mix. And rightly so – having a portable modeling notation that describes how drawn processes should be drawn as well as run is an important way to go. BPMN helps business analysts communicate consistently, both …..
Dear Bruce, I don’t understand why we need an explicit BPMN schema. If the BPMN metamodel (BPDM) is defined through MOF, XMI already provides a direct mapping of MOF metamodels to XML…
Giancarlo
Giancarlo,
Thanks for responding. From a computer science pespective, maybe it’s not needed. Apparently that’s OMG’s judgment. I’m just saying that the XML tools I use (Altova suite) regularly to create, manipulate, render, and validate XML documents generally require a schema. I’m saying I can’t understand the xmi, even though I consider myself xml-literate. There are a lot of existing BPMN diagrams saved in vendor-specific schemas which could be transformed to the BPDM one via xslt… if a schema for it existed. I’m saying it’s not even clear to me if there IS a single schema for BPMN, or if multiple ones would be valid using XMI. I’m saying BPDM does not provide a single example of an instance document for BPMN so someone who is not a computer scientist can get at least an idea of what a serialized BPMN model even looks like. I’m saying BPMI (and OMG, sort of) have been promising to deliver a schema for a few years now. Other than those, I guess no reason at all.
–Bruce
Bruce,
Thanks so much for the kind words. In many ways in this post, you have said what I wanted to say. In essence, one’s assessment of how well a standard conveys information depends precisely on what kind of information you want to convey. The goals of XPDL and BPEL are to convey different aspects of process, so naturally they are useful for different things. Different people will judge each as more or less successful depending upon their own goals. You managed to write this with a clarity that I have never quite achieved.
I am preparing a longer response about BPMN which I think you will find interesting. Mostly I agree, BPMN is probably the most important of these standards, but I think you are overestimating the completeness of BPMN. Let me get my thoughts together and respond on my blog in a couple days.
-Keith
I think xmi requirement is not to be human readable but machine readable since import/export functionalities should be automatically provided by MOF implementations like EMF. I still have to check BPDM specification so I cannot add more. Thanks for your explanation.
Giancarlo
Giancarlo,
Yes you can say the same about xsd, but tools like XMLSpy nevertheless create a graphical rendering that makes the schema definition crystal clear even to a non-CS type like me. I don’t want to use Eclipse to store a BPMN document. I want to know how to transform the proprietary BPMN I have now into the BPDM schema. It shouldn’t take a full developer environment to do that. The problem is OMG is living in a UML world not an XML world. thought I had the answer in a new Altova tool UModel that can import XMI to UML and then generate a schema from the UML. But UModel failed on the XMI import. It only supports XM! 2.1 and modeldriven.org has posted only XMI 2.0. So the frustration continues.
–Bruce
I would like to add that the very simple example used by Keith to illustrate his point is not a good one as it hides a key difference between BPMN (or XPDL for that matter) and BPEL. It is an example of a perfectly structured process model. Structured process models can be translated easily from BPMN (or XPDL) into BPEL, and we can even do round-tripping with this class of models. For such structured models, BPMN can be seen as a “skin” on top of BPEL.
However, this is a very specific case and people who deal with domain analysts know that they very often do not write structured process models. And if you try to explain them that their models should be block-structured because it’s easier for your tool to execute them, they will simply throw you and your tool out and go back to doing IDEF or EPCs like they did in the old days. If you want to engage with domain analysts, and you?re serious about business-IT alignment, you have to given them the freedom, among others, of writing their favourite unstructured models. You should then provide methods and tools so that system architects, designers and developers can turn these models into implementations, for example in BPEL, WWF, YAWL, etc.
On the other hand, if XPDL is positioned as an XML serialisation of BPMN, whatever leading edge it may have at present, will probably not last long. Even if vendors started adding XPDL import/export functions into their BPMN tools, it would be easy for these same vendors to also offer BPDM-XMI import/export whenever OMG decides to catch up. As for the fact that XMI serialisations are horrible, it seems that tool vendors have become used to this fact and they have learned to live with it.
But perhaps rather than discussing BPMN vs BPDM vs XPDL vs BPEL, shouldn’t we be discussing how to bring BPMN closer to the needs of business process modellers? How to capture richer representations of resources (e.g. people, equipment, systems, materials), how to capture richer representations of context and non-functional properties (e.g. time, cost, risks)? I see a lot of analysts coming from using EPCs, and being disappointed by how poorly BPMN captures these non-functional aspects, which to them is more than half of the story that a process model should tell.
I came across Keith’s and Bruce’s Blogs recently and read them with great interest. I have a question when researching the field. Is it possible to record a process definition, along with information about its instantiation (for one instance/enactment) and states, so that the various presentation tools and monitoring tools can use it as well as the engines. Am I completely off the track?
Marlon,
Thanks for your perceptive comment on a subtle aspect of BPMN. In my BPMN training, when I talk about using BPMN at Level 3 (executable design), I point out that the diagram may be further restricted by constraints of the underlying execution engine, e.g. as you say, block-structured languages like BPEL require parallel splits, event gateways, etc to rejoin, where plain BPMN does not. This is a fact of life, and we’re grateful to guys like you and eClarus for making the best of it.
But the key message in your comment, and in Keith’s fragment as well, is that BPMN itself needs to get better, in many ways — more complete as a modeling standard, more business-friendly, and probably better in the choreography notation as well.
When BPDM comes out — next week, I hear — I think there will be great relief that the metamodel and serialization is finally done, followed by loud grieving and gnashing of teeth once folks have a look at the spec. Those who remember that BPMN began as an antidote to UML will be left wondering what happened. But let’s let that process unfold to see what comes next. Clearly OMG is trying to make BPMN more architect-friendly than business-friendly, and I doubt that BPDM will be the last word on where BPMN goes from here.
cm119,
Not sure what you’re asking. All BPMSs can track and monitor instances, and many of them can display that information layered on the process diagram. But each in its own proprietary way. If you’re asking about standards for this, there is an effort in OMG called BPRI (runtime interface) — or that’s what it was called when it started — that is trying to standardize access to runtime information. Not sure of its current status.
[…] The Diagram IS the Meaning Posted March 25, 2007 Bruce Silver put together a summary of The Real Issues with XPDL, BPEL, and BPMN where he explained better than I could that the aspect of portability that is more valuable depends on what you?re trying to do. He correctly points out that “XPDL captures the diagram, while BPEL captures the process semantics.” […]
Comment #9 from Marlon: yes you are absolutely right, I chose a process which can successfully be translated to BPEL because it maps to a block structured implementation. Naturally, there are many BPMN drawings that do not map so well.
Comment #9 from cm119: We have discussed an “XPIL” for XML Process Instance Language, which would be process definition along with instance information, but there is nothing past an early proposal on this. I believe what is needed is an “monitoring event” definition which would allow any process engine to send events in a standard to a Process Intelligence product.
[…] My comment on Keith Swenson’s XPDL-BPEL apples-and-oranges post and the failure of XPDL to fill the vacuum left by OMG in the BPMN specification stirred up an interesting response from Keith that reinvigorates the discussion and helps clear the air. But he still frames the discussion in terms of portability of executable designs rather than portability of models (i.e. abstracted from implementation details). In the XPDL vs BPEL discussion, this is appropriate, but in the discussion of BPMN portability it misses a fundamental point. […]
Bruce,
How about you take a look at the BPMN Schema developed by Intalio and contributed to the Eclipse Foundation? It is available at the following URL:
http://www.eclipse.org/stp/bpmn/model/index.php
Also, it is fully supported by the Open Source BPMN modeler we have donated to Eclipse, as well as by the Intalio|Designer process designer.
Best regards
-Ismael
Get Your BPMN Schema Today…
In a recent article published by Intelligent Enterprise, my friend Bruce Silver laments that BPDM is essentially useless, and that the BPM industry badly needs an XML schema for BPMN. I could not agree more with him, and I am happy to report that Intal…
[…] I am not the only to criticize, you can read here in The Real Issues with XPDL, BPEL, and BPMN where Bruce Silver explains the issues with poortability that I have also covered. Keith Swenson […]