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.
He says:
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.
In the first sentence above, replace “an executable process” with “a process model.” And there you have the essential problem, because I would say BPMN is able to capture the semantics adequately, but BPMN tools simply do not adhere to the spec, and users don’t know how to create diagrams correctly. The tool vendors’ own sample diagrams violate the spec time after time, something I’ve blogged about repeatedly in the past, and — more important — the tools (the ones I’ve looked at, at least) do not adequately validate the diagrams against the rules defined in the spec.
In trying to prove his point that the semantics required for model portability are missing from BPMN diagrams, Keith unwittingly proves mine instead, that the problem is diagrams often violate the spec and the tools don’t seem to care. He says:
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:
Now, imagine the Vulcans had followed BPMN best practices and applied user-meaningul labels to the various activities, sequence flows, gateways, and events, so it would be clearer the conditions under which the process followed one path versus another. (In BPMN modeling it is actually these labels, not the attributes — those are mostly for BPEL generation — that clarify the process semantics.) That would go a long way toward clarifying what those Vulcans had in their melded minds. To the extent it’s still unclear, it’s because this diagram, which even a guy as smart as Keith says is perfectly good BPMN, contains at least 3 errors.
1. You have 2 sequence flows coming into Casino from potentially concurrent paths. You need an OR-merge there, or else you potentially have 2 tokens going through the Casino activity for one process instance. Not absolutely forbidden by BPMN, but best practice to avoid this. It will break virtually any simulation engine or process engine, and probably not what the user had in mind.
2. Casino, having no sequence flow out, is what the spec calls an end activity. If start events are used in the diagram (they are here), an end activity must have a sequence flow to an end event.
3. Casino has a Compensation intermediate event with a sequence flow coming out of it. That’s invalid. A Compensation intermediate event has an association to a single compensation activity, not a sequence flow.
If I can spot these things easily, why didn’t Keith’s BPMN tool?
For the past few weeks I have been grading exercises submitted by students in my Process Modeling with BPMN training. My decision to include hands-on with a tool and exercises submitted for grading turned out to be a good one — students say the exercises really drive home how to use BPMN in a way that the lecture material simply can’t. And what I’ve learned from the grading is that students frequently make diagram errors that could, in principle, be caught by a BPMN validator. The tool I use, Process Modeler for Visio from itp commerce, has a modest amount of BPMN validation – just enough to make sure the simulation engine can follow the process — and a stricter validation (overly so I think) of diagrams with BPEL export, reflecting more the constraints of BPEL’s block orientation than anything about BPMN. But almost all the errors I find are allowed by the tool. If I can see them, surely a validation routine should be able to spot them as well. This would change the nature of my training, perhaps, but… that’s another subject.
Finally we get to the real reason for this post, which is the long-awaited BPDM — the official metamodel for BPMN from OMG. You can see it, if you want to, at modeldriven.org. I was looking for a schema, but instead it’s this funky XMI thing. It’s not even schema-valid XMI (that’s ironic, isn’t it?). It fails XMI import as published on modeldriven.org, but if you patch it up with the right root elements — thanks to Marlon Dumas for doing that — you can at least import it into a UML tool. Yes that’s right, UML. The schemas that Marlon was able to generate don’t shed much light on what the structure of a BPMN serialization would look like, and that bugged me last week.
But I think Keith’s post here crystalized the thing that is really bothering me. It’s not portability of models between tools. I suppose whether they have to use Eclipse or whatever, the tool vendors will figure out that piece. What I realize I was actually looking for in BPDM was a more precise statement of the rules of BPMN, so they could be reflected in tool-based validation. I had the feeling that those rules were somehow buried in the XMI, which I can’t decode, unlike schema, which I can. But on further consideration, I see that it’s highly unlikely that a schema could possibly represent all the rules, such as if you have this kind of flow object over here, that constrains what is allowed for this other flow object over there. Of course, if you had a schema you could write XSLT that would do the validation based on rules extracted from the narrative of the metamodel. But that’s a story for another day.
Bruce,
I didn’t use a BPMN modeling tool because I was purposefully trying to create a nonsense diagram. I would not be at all surprised if you found things in the drawing that violated rules. I am not an expecte in the BPMN edge cases, and from what I can gather you have a pretty detailed understanding. The spec is 200 pages long, and there are a lot of rules, and I have only a limited time to make the blog entry.
But strangely enough, I am not sure that I agree with the three “violations” that you found:
1. Actually the spec specifically states in section 4.5.2 that the gateway is not required, see figures 21 and 22 being states as equivalent.
2. I will take your word for this, but I would read this as the flow continues when the message is received.
3. That is not a sequence flow coming out of the compensation. Look at it closer, it is an association. Probably my fault for not making the dotted line distinct enough.
I completely agree with you that vendors have in general not taken enough care to conform to the rules. I want to talk about this a bit in my next post. But this experience here points that even an expert can find it difficult to be unambiguous. But lets set this aside — I was trying to make a meaningless diagram, and we can agree that at the very least I have accomplished that.
The main point I was trying to make, and I don’t think you have disagreed with, is that this diagram, regardless of how meaningful or meaningless, can be serialized to XPDL, and recovered from XPDL completely, and with all semantics (if there were any) intact. I will stick with the story that this is the right thing to serialize.
This post, however, wanders into the subject of “why can’t we all write BPMN diagrams that conform to the rules”. There is a deeper reason, which I hope to explore in my next post.
On the 3 violations:
1. Your references don’t match with mine (OMG Feb 2001 version of the spec), but I think I know what you’re saying. In the Feb 01 spec p118 fig 10.31 , representing Prof. van der Aalst’s “multiple merge” pattern, is technicallly allowed by BPMN. But usually it’s drawn by mistake, since, as I said, you get 2 instances of each activity downstream to this merge for just 1 process instance. I believe this will break process engines and simulation engines. In my training I advise students to avoid this, but you are correct in that it is “technically” allowed.
2. From the spec p40 “If an End Event is used, then there MUST NOT be other flow elements that do not have any outgoing Sequence Flow?all other Flow Objects MUST be a source of at least one Sequence Flow.” Perhaps this is ambiguous as well, since you could argue that there is an outgoing sequence flow from the event. But my interpretation is that means outgoing from the activity, i.e. a normal flow.
3. Well even if my eyesight were better and I could see the dotted line, an association to a compensation activity does not work like a sequence flow. The compensation activiity is not a normal process activity; it has the little rewind thingy and it has no sequence flows in or out.
But my real point is that BPMN does carry portable semantics if it is used in strict conformance with the spec (plus, admittedly, some best practicese about ambiguous patterns to avoid). And that the rules could be checked in BPMN tools… but they’re not.
OK, my example was a disaster, and obviously served only to distract us from the point. Sorry, let me try again.
Let me ask a simple question: assuming that a product uses BPMN correctly, do you believe that the BPMN diagram (the BPMN visual element, as well as the BPMN-defined attributes) carries the meaning that the author put into it?
If there is additional meaning that is not in the diagram itself (including the attributes), how did it get there?
Is there a distinction between the “meaning” of a process that the author of a diagram intends, and the “semantics” of the process?
Keith,
That’s 3 questions. I’ll give you my answers. Othere’ may vary.
1. yes, correctly meaning a combination of following the spec plus best practices like meaningful labels. In fact, you shouldn’t have to look at the attributes that are not expressed in the diagram. But the meaning has zero to do with whether the sequence flow comes out of the top side of the activity or the right side, or whether the diagram uses off-page connectors, or whether swimlanes go horizontal or vertical. Those are diagram things that carry no process semantics.
2. that information should support some purpose beyond simple modeling, such as simulation or execution.
3. from a modeling perspective, no.
I think where we are having trouble speaking with one voice comes from the fact that 2 BPMN tools may interpret the exact same diagram differently — usually one of them uses the notation incorrectly, i.e. not according the the spec. Or, more commonly, they may support different subsets of diagram elements. When I say interpret differently I mean from a modeling (implementation-agnostic) standpoint, not execution. .
That’s the essential difference from BPEL. BPEL 2.0 has a set of activities and a syntax, and if you’re compliant you just have to support it all. What it doesn’t have is a diagram, because, really who cares? All the BPEL tools I have seen that have a one-to-one mapping between graphical nodes and BPEL activities look different in fine detail but are more or less the same. If you understand a diagram in one of them, you’ll understand the same diagram in another. And the semantics are the same, guaranteed. So BPEL has the necessary rigor to be protable, it’s just incomplete from a modeling perspective (human tasks, subprocesses, etc) and its enforced block orientation is not business-friendly.
You don’t have that rigor with BPMN today, but you could — if BPMN tool vendors adopted the same attitude. With pure modeling tools it’s not such a problem, but with BPMS vendors using BPMN as a front end for design it is. I suspect those vendors like BPMN (and XPDL) precisely because it lets them check off the standards box while retaining the freedom to support only the parts of it that are convenient.
Again you could say this is OMG’s issue not WfMC’s. But my original point was that providing more discipline around must-support features of BPMN, along with diagram validation rules, was in fact XPDL’s opportunity to make a real difference. Or possibly still is.
Hi Bruce (and Keith).
I’m very glad to read posts as this one! I’m a PhD student in CS at Università degli Studi dell’Insubria (Italy). I work from a couple of years on BPMN and more in general on BPM-related standards and technologies.
I and my group are aiming to develop an XML-Schema for BPMN, which could integrate either XPDL and BPEL characteristics and features. A sort of join between them. This Schema is based on a new data model we have developed (because the lack of a more formal model, before BPDM has come out). We called this model BPeX, stands for Business Process eXtensions.
It is possible to see our work on our project site (http://bpex.sourceforge.net) or on our new blog (http://bpex.blogspot.com)
I wish to thank you very much for all you are doing!
Any comment would be appreciated.
Hi,
” …thanks to Marlon Dumas for doing that ? you can at least import it into a UML tool. Yes that?s right, UML…. ”
Can someone help me in getting the valid schema which can be imported in UML 2.0 or even UML 1.x…?
Thanks.