My previous post on Reframing the BPEL vs BPMN Debate triggered a lively comment thread that somehow got wrapped up in the distinction between semantics and metamodels. It’s mostly over my head. But in the midst of it, Marlon Dumas, one of a handful of BPM academics worth listening to, pushed one of my buttons when he repeated the familiar charge that the semantics of BPMN are “vague”. He specifically referenced the OR-gateway used as a join. Now the semantics of that construct never seemed vague to me, so I asked him to elaborate.
He pointed me to this paper, and specifically the diagram shown below.
I am the first to admit that this diagram is a bit strange, and what I would call in my BPMessentials training bad BPMN practice. Looping back into the middle of a parallel split/join block is not a good idea. I wouldn’t object if the BPMN spec said it was illegal to do so or even advised against it. But “vague”? No, it is not vague.
The behavior of the OR-gateway on the initial pass is clear. It waits for both parallel paths to complete. The issue is the possible iterated pass if the loopback occurs. Should the OR-gateway “wait” for the other path? Of course not. No one would think that it should. So in my view the execution semantics are not vague at all. That is to say there is no dispute over the intended behavior. The issue is how to translate it into executable code. The point of the paper, in my simplistic view, is that writing that code is tricky. It can’t just translate a BPMN OR-gateway shape into some bit of code, but needs to consider the diagram as a whole. That’s fair, and you could say the same about other parts of BPMN as well. This is why BPMN-BPEL roundtripping is so hard.
Will a UML-based metamodel in BPMN 2.0 make the semantics here any clearer? No, but they were never unclear to begin with. Will they make the executable code generator easier to write? I can’t answer that.
Bruce , I agree that it is precise but I don’t think it should hard to code this particular example. see for more
David
Bruce, good post, good explanation of your p.o.v. I agree that BPMN semantics are not vague (though, like most specs, reading them takes a bit of mental discipline as the concepts they are describing in words only are not all simple.
I don’t know if anyone will cop to the “hard to code” defense, but whenever something is hard to code, but also provides a lot of general/generic value, I hate to hear that excuse. To me, that’s precisely when you want to spend the effort to code something – its hard, and has a lot of value if you get it right (where, in this case, value == applicable to a lot of different problems)…
Well, the problem is the clash between the research and practitioner camp. Let me tell you a story. I was last year at a scientific conference meeting very smart guys. Some presented new approaches how to formalise and transform certain process constructs like the one you show in this post. I talked to one of them during lunch and told him that a huge amount of process models is not even meant for automated process execution. The guy, a serious researcher, said he was not aware of that. First I thought he was kidding, but he really meant every process model is created to be executed on a process engine.
If you operate in such a “research” environment, it is normal that you focus on the formal aspects, because that’s where the fun is (at least for mathematicians). For a formal guy the process you show is vague. However, for a practitioner looking at the diagram, it is fine and self explanatory.
Today, many tools are able to transform process models (EPC, BPMN, UML activity diagrams) into executable descriptions (BPEL, XPDL or direct execution). Sometimes, this is only possible by restricting the notations a little bit, but it is not really a challenge anymore to write such a transformation. From a scientific point of view such transformations might not be perfect, but from a practitioners point of view it just does the job.
Sebastian,
Your story is funny and not so funny. I deal with that sentiment every day on the BPMN 2.0 team calls. Since you are also on the team, you should dial in now and then, so I won’t feel so lonely. ;-}
I love this example, and I agree 100%: anyone who looks at this diagram can agree with what was intended. The discussion of the precise semantics of the Inclusive OR node was a heated and messy debate, even if you ignore completely difficulties of implementation. The Inclusive OR node should block until all “activities before it” in the process have completed. The difficulty comes in define what is means by all “activities before it” in certain very convoluted diagrams. The diagram you chose above, this seems very clear, and there should be no disagreement. To be honest, I can’t think of any reasonable diagrams where it is not clear, but when implementing a system with precise formal semantics, you need to be sure that all the unreasonable cases are handled in the same way.
What you have made so clear in this post, fit so well with my current discussion of “Model Strategy”. A lot of the debate around Inclusive OR came from people who found it difficult to implement this interpretation because they wanted to throw away the original BPMN model. Without retaining that model, it hard to check and see if any “activities before it” are still active. So, thanks for making this clear — and for giving me an idea for another blog post.
I agree with your point that the execution semantics of this example are not vague, but I also do find the 1.1 spec to be “vague”. There are two parts where the spec is vague in my opinion: reusable vs. reference sub-processes and merge/join/synchronisation differences between gateways. I’ll stick to the gateways for now:
On a split, the difference between an exclusive and inclusive gateway is very clear, but what is the difference between the two when they are used for merging two or more flows? There is no condition possible for an outgoing flow in either(p73), so that’s not it. Can you please explain to me what the difference is between picture 9.20(, 9.21) and 9.27 from the specification?
This is how I read it:
9.20 (exclusive merge, also called controlled flow) vs 9.21 (uncontrolled flow) first: (A) When, in 9.20, one token arrives it is passed on. (B) When two tokens arrive at the same time they are synchronised (=only one token comes out). Is this correct or are the tokens sent out after each other? If that is the case what is the difference with 9.21? (C) When two tokens arrive one after the other, are they both sent on, without considering synchronisation. (p77) What is exclusive about this gateway for merge?
9.20 (exclusive merge) vs. 9.27 (inclusive merge): on p81 it is explained that “When the Inclusive Gateway is used as a Merge, it will synchronize all Tokens that have been produced upstream, but at
most one for each incoming Sequence Flow. Note: Tokens with a loop are upstream of every node in the loop. It requires
that Tokens for all Sequence Flow that were actually produced by an upstream (by an Inclusive situation, for example) be
synchronized. If an upstream Inclusive produces two out of a possible three Tokens, then a downstream Inclusive will
synchronize those two Tokens and not wait for another Token, even though there are three incoming Sequence Flow”
How can all tokens produced upstream be synchronised if it doesn’t wait for them like a parallel gateway?
All this sounds to me like the gateways know exactly how many tokens they will receive, making them dependant on the upstream part of the model. So the execution semantics of a gateway can not be defined for 9.20 or 9.27 on its own, without the rest of the model they are used in? If that is so, then not mentioning that is in my opinion very “vague” indeed and needs to be made clear.
I agree with your point that the execution semantics of this example are not vague, but I also do find the 1.1 spec to be “vague”. There are two parts where the spec is vague in my opinion: reusable vs. reference sub-processes and merge/join/synchronisation differences between gateways. I’ll stick to the gateways for now:
On a split, the difference between an exclusive and inclusive gateway is very clear, but what is the difference between the two when they are used for merging two or more flows? There is no condition possible for an outgoing flow in either(p73), so that’s not it. Can you please explain to me what the difference is between picture 9.20(, 9.21) and 9.27 from the specification?
This is how I read it:
9.20 (exclusive merge, also called controlled flow) vs 9.21 (uncontrolled flow) first: (A) When, in 9.20, one token arrives it is passed on. (B) When two tokens arrive at the same time they are synchronised (=only one token comes out). Is this correct or are the tokens sent out after each other? If that is the case what is the difference with 9.21? (C) When two tokens arrive one after the other, are they both sent on, without considering synchronisation. (p77) What is exclusive about this gateway for merge?
9.20 (exclusive merge) vs. 9.27 (inclusive merge): on p81 it is explained that “When the Inclusive Gateway is used as a Merge, it will synchronize all Tokens that have been produced upstream, but at
most one for each incoming Sequence Flow. Note: Tokens with a loop are upstream of every node in the loop. It requires
that Tokens for all Sequence Flow that were actually produced by an upstream (by an Inclusive situation, for example) be
synchronized. If an upstream Inclusive produces two out of a possible three Tokens, then a downstream Inclusive will
synchronize those two Tokens and not wait for another Token, even though there are three incoming Sequence Flow”
How can all tokens produced upstream be synchronised if it doesn’t wait for them like a parallel gateway?
All this sounds to me like the gateways know exactly how many tokens they will receive, making them dependant on the upstream part of the model. So the execution semantics of a gateway can not be defined for 9.20 or 9.27 on its own, without the rest of the model they are used in? If that is so, then not mentioning that is in my opinion very “vague” indeed and needs to be made clear.
Regards,
Jordy Voesten
Jordy,
Thank you for contributing. I am too far enmeshed in BPMN 2.0 to try to add semantics after the fact to BPMN 1.1, so my answer reflects how it will be clarified in 2.0. The figures you reference, for those without the spec handy, are an exclusive merge gateway (9.20) and uncontrolled merge – multiple incoming sequence flows with no gateway (9.21). In BPMN 2.0, the exclusive gateway used as a merge is a passthrough. It passes all tokens, so there is no difference from 9.21. In my current BPMessentials training, I say that using exclusive merge when the paths are parallel is an error, but this is not the case (at least in BPMN 2.0). In my new training, based on BPMN 2.0, I will say it is technically allowed, just like “multi-merge” (9.21), but I recommend modelers to avoid it at all cost. Interesting that it is specifically disallowed in the BPEL compliance portion of BPMN 2.0, since multi-merge will “break” almost any runtime engine.
Inclusive merge is very different. It is a synchronizing join. I agree the join has to know how many tokens to wait for. If a path is conditional and not enabled for this instance, the join will not wait for it. A complicating factor is when there is a loopback, and some topologies may give problems in specifying the join.
–Bruce
Overall, I agree with Jordy. With respect to the semantics of the Inclusive merge pf parallel paths I think of it as follows:
How does the merger know how many tokens to wait for? Well, the 1.2 spec doesn’t say. So, I think of the splitting gateway as generating “dummy tokens” on the paths where the condition is not met, and when these dummy tokens reach the merger they are consumed (as opposed to synchronised). This way the merger has received tokens on all paths and can proceed.
I believe that’s how they’ve defined the operational semantics of BPEL.
(I’m new to BPMN/BPEL so if I’m wrong, please correct me.)
Best regards,
Ebbe
I should remember to thank Thomas Hildebrandt for making me aware of the previous idea with dummy tokens.
Moreover, wrt. Reference Sub-Processes and Reusable Sub-Processes, the BPMN 1.2 (one point two) spec clarifies, as far as I understand, that a Reference SP is just a special case of a Reusable SP, where the attributes are set as follows: DiagramRef = Null, InputMaps = 0, OutputMaps = 0. So, the difference is that Reusable SPs can refer to other BPDs and have I/O maps defined. (See p. 61 in the spec.)
Best regards,
Ebbe
Of course, when the token goes upstream again the inclusive gateway would then lack a dummy token from the Abstract Variability path and stall. It’s a nasty example. Luckily, such examples are not legal in the BPEL semantics.
I am very interested in obtaining clarity on this subject so if anyone can confirm or correct me it would be much appreciated (although I realise that this thread is old). For example, Thomas explained the idea with dummy tokens to me, but I may not have done his — undoubtedly correct — explanation justice here.
Best regards,
Ebbe