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.”

Bruce brings BPMN into the discussion as potentially the standard that is possibly the most important. There have been a number of discussions recently of the relation of these three standards, including Jason Stamper in Computer Business Review and Jon Pyke in EBizQ.

Before going any further, there is one thing that must be straightened out. XPDL 2.0 captures every aspect of any BPMN diagram. It is a complete representation of all element and all attributes of BPMN. A couple of the people were involved in both BPMN and XPDL specifications, and single guiding principle for the 2.0 release is that there should be a well defined way to store every property mentioned by the BPMN specification. My descriptions of XPDL often focus on the X & Y coordinates, and the shape of the lines, because this is an obvious differentiator from BPEL, but it does not stop there. XPDL also represents the attributes that specify a web service call, or the event definitions, and every other attribute mentioned in the BPMN specification. XPDL also extends this with additional ability to express process semantics that was developed over the years in WPDL and XPDL 1.0 by the collection of workflow/BPM vendors attempting to define exactly the important semantics to exchange.

XPDL is a strict superset of BPMN. This means that everything and anything that can be expressed in BPMN, can be captured by XPDL. The complete process diagram, including any and all process semantics expressed by that diagram.

Bruce has criticized XPDL for inability to take an executable process from one vendor product, and bring it to another vendor product, and guarantee is it understood. He is right. There is no guarantee that a process drawn in one product, saved in XPDL, will be immediately executable in another product. This is not because XPDL fails to capture the semantics, but instead a failure to (1) be able to unambiguously capture those semantics in standard BPMN, as well as (2) a failure of the receiving tool to understand the same semantics that the sending tool transmitted.

To the extent that BPMN can represent the complete process design, XPDL can transfer that complete process definition, including all the semantics of that process. To the extent that BPMN is ambiguous and misunderstood by another tool, XPDL is similarly likly to fail. This is because the XPDL is essentially a one-to-one representation of the BPMN.

Let me use an analogy again. Another standard that is very important is the Unicode standard of characters and character encoding. I can write English all day long and be completely assured that every expression is 100% captured and stored in a Unicode file (let’s ignore markup for the moment). I would say that Unicode is a great success at allowing people to communicate, and it carries the complete semantics of every expression. Others would point out the obvious flaw in my thinking: only 1 person in 10 speaks English, and thus 90% of the world can not read my posts (well, there are probably another 30 to 40% that could muddle by enough to make sense of it, but you get what I mean…). A French person can use Unicode as well, and be completely assured that their expression will be preserved with Unicode, including all the semantics. Zut alors! While Unicode guarantees that the expression is completely preserved, it does not guarantee that all readers will be able to understand the expression.

BPMN gives us a vocabulary to describe business processes, in the same way that a dictionary gives us words. But please note: the underlying meaning is not in the words, but in how those words are put together. There are a number of different dialects of BPMN out there. Two tools that use the same dialect of BPMN, can easily exchange processes via XPDL.

Let me give you an example. Lets say there was a product called “Vulcan Mind-Meld” which used BPMN to express the diagrams that have meaning to this product. BPMN defines what each of the symbols mean, but the real meaning, the real semantics comes from the way that the symbols are composed together. Mind-Meld would guide you as you draw this diagram, making sure that you do not put anything together in a way that is nonsensical. The author of this diagram is making an expression that has meaning in Mind-Meld. Here is a possible diagram which is consistent with the BPMN specification:

What does this mean? I frankly don’t know. I tried hard to make an ambiguous diagram that still obeyed all the BPMN rules. This is not to imply that there is any flaw in BPMN, but simply that with any language you can follow the rules, and make something that is meaningless to some readers. But stick with me for the moment.

We can argue about whether Mind-Meld should allow this expression, the main point I want to make here is that Mind-Meld can save this diagram to XPDL and read it back in again with complete fidelity. All the attributes of the elements are preserved. None of the semantics would be lost. Another product called “Klingon Kommand & Kontrol” would be able to read that XPDL file. It would have all the nodes, and all the attributes of those nodes. It could reproduce the diagram. Its ability to understand the meaning of the diagram depends upon it interpreting the combinations of BPMN symbols in the same way that Mind-Meld did.

This is the essence of Bruce’s concern: he would like Mind-Meld product to interpret the BPMN expression into a “universal process meaning”, and then communicate that meaning to the Komand & Kontrol product in such a way that it can not be misunderstood. That is kind of the Holy Grail of process modeling, there is only one problem: this is very very very difficult.

We could wish for the same thing in the Unicode analogy: that the English expression could be somehow digested, understood, and represented in a language independent way, such that any reader would be guaranteed to receive the meaning. Thus I would write an expression in English, it would be digested and decoded, and then would be displayed in French to the French reader, German to the German readers, and surfer-lingo in parts of Santa Cruz. This, of course, is very very difficult.

But if you think about it, why would you save and exchange anything other than the diagram that the author composed? The original diagram is the expression of the author. How that expression be converted into anything that carries more meaning than the original diagram? If the meaning in BPMN is unambiguous, then every tool that reads it will interpret it in the same way.

If I was to write in English, why would I store and exchange anything other than the English that I wrote? If a French reader wants a translation, it can be translated from English to French at that time. If there was an intermediate structure that could represent the meaning of the English, it is not clear that it would be better than the English that was written originally.

It works the same with BPMN/XPDL. If you want to transfer a process definition from one product to another product, it makes the most sense to transfer the original diagram that the designer drew. This contains the best representation of what the designer intended. Then, if a translation is needed from one dialect to another, it can be done at that time.

This was a conscious choice in the design of XPDL. XPDL represents the process diagram in a one-to-one manner, more or less directly what the process designer drew, and not an abstraction of it. This does not mean that the semantics are dropped on the floor — they are there in the diagram just as the designer put them there. Each product, however, must interpret the BPMN to get the meaning from it.

Back to the Vulcan Mind-Meld example: can this diagram be represented using BPEL and read back in again? Most likely not. Again, this is not a flaw of BPEL. The strength of BPEL is that all of its elements are rigorously defined. This increases the liklihood that it is understood by all readers. But it also decreases the flexibility. I might be wrong: if someone would like to post the BPEL representation of the Mind-Meld process, I think we all would be very much interested in seeing it. The XPDL, on the otherhand is easy to make.

BPDM, the future metamodel from OMG, promises to be the “universal process meaning” for process products that can represent any process, including Vulcan Mind-Meld. Every product will interpret the BPMN diagram, and express the meaning of that diagram in BPDM. This would be a huge benefit to us all. We don’t know how well this works since it is not available yet. But in any case, it is not clear to me that this representation would be more faithful than the original BPMN diagram. It seems that the OMG folks expect different products to interpret the BPMN in different ways! With this assumption, then how are we humans supposed to know what a BPMN diagram means by looking at it? The whole point of BPMN is that it should be an unambiguous representation of the process, so that when people see it, they interpret the meaning, and when products read it, they get the same meaning from it. I am with Bruce on this: BPMN is the most important standard for unification. That is the goal of BPMN, we are not there today, but we have a path that may lead there.

Until the advent of XPDL 2.0, there has not been a way to transfer BPMN diagrams from product to product. Each product was isolated and developed dialects of BPMN the way that isolated people developed different spoken languages. Now that we have a way to transfer these diagrams, it is very likely that groups of products that work similarly will tend to use BPMN in the same way, and that shared dialects will emerge.

This trend is enabled because XPDL can represent any BPMN diagram.

Why can’t all products interpret the BPMN in the same way? This is another of Bruce’s concerns. Why can’t there be a single dialect of BPMN? Please stay tuned for my next post.