Bruce Silver continues the valuable discussion on BPMN semantics and challenges a perception that BPMN has vague semantics.
In the example chosen,
- having flows from downstream activities BPMN is not best practice (in that it can lead to misunderstanding by the casual reader who may more be familiar with basic flowcharts)
- there is only one reasonable interpretation of the required execution of the BPMN and therefore it is not an example of "vagueness".
Looking at the definition of the Inclusive Gateway in BPMN 1.2 , I might accept a criticism that it is hard to read in English and may benefit from formalising.
9.5.3.2 Sequence Flow Connections
This section extends the basic Gateway Sequence Flow connection rules as defined in “Common Gateway Sequence Flow Connections” on page 72. See Section 8.4.1, “Sequence Flow Rules,” on page 30 for the entire set of objects and how they may be source or targets of Sequence Flow.
- To define the inclusive nature of this Gateway’s behavior for converging Sequence Flow:
- Process flow SHALL continue when the signals (Tokens) arrive from all of the incoming Sequence Flow that are expecting a signal based on the upstream structure of the Process (e.g., an upstream Inclusive Decision).
- Some of the incoming Sequence Flow will not have signals and the pattern of which Sequence Flow will have signals may change for different instantiations of the Process.
However it is clear from the phrase "... expecting a signal based on the upstream..." and the note in the section above that the inclusive gateway in the example has no (merge) function in the event that a sequence flow from the downstream exclusive gateway is processed. The token from the loop back is the only one that can be 'expected' at the inclusive gateway.
It will only be hard to code, if the developers have started from a point of view that each node (activity or gateway) can be transformed into an executable form (or executed directly) in isolation. The developer must consider the source of the signals (Tokens) and the structure of the process as a whole.
2 comments:
Dave,
The note in the BPMN spec about downstream gateways being treated "differently" from upstream ones sounds French to me. And note I'm not saying this in reference to your surname...
The spec. doesn't precisely say how "differently downstream tokens should be treated from upstream ones, it just says that these downstream sequence flows form a different set (sic) Here is where either formalisation or compliance tests would be useful, to ensure everyone understands the same thing.
As for the hard to code, I think Bruce meant that the inclusive merge does not have a local semantics, as other gateways have, which is what you emphasis as well. Hard to code is perhaps not the right term, but Bruce was referring to claims made by tools that claim to implement BPMN-to-BPEL transformations.
marlon
Thanks, Marlon
I think we all agree. My irritation is with the BPM product people who justify their incomplete implementation of BPMN by imagined difficulties of coding in BPEL (or whatever) or by saying that the execution semantics are not clear. It may be possible to produce examples of BPMN diagrams where the execution requires is not clear but I have not come across a real life example.
David
Post a Comment