RE: [ebxml-bp] Difference between Fork and Decision

["Moberg Dale" <dmoberg@axway.com>]

 

 

 

Difference between Fork and Decision

The ebBP standard states (on page 63):
An XOR Fork may be designed to operate like a Decision, but a Decision cannot be an XOR Fork.

For me the difference between Fork and Decision seems to boil down to the point that a Fork may be used for modeling non-determinism while Decision cannot, because a decision selects only one of the possible transitions, and the other(s) is/are automatically disabled.(page 63).

Is that correct?
If not, what actually is the difference between an XOR Fork and a Decision?
If so, shouldn't a ConditionGuard be obligatory for a Decision.ToLink? In all examples found, every Decision.ToLink has a ConditionGuard.

 

 

The Decision construct is best used when there are transitions possible from an initial state to a different state, or yet some third other state. For this situation, the CE value in the “FromLink”  is omitted, and the CE value in one of the ToLinks should be the negation of the CE value in the other ToLink. There does appear to be a questionable value in the schema for Decision, because the FromLinks are allowed to be unbounded. The TC should discuss whether that was intended.

 

The only attributes on the “gateway” transition constructs (fork, decision, join) that have much impact on logic are the “type” on fork (with XOR or OR as the types) and the waitForAll on Joins.

 

In the waitForAll case, the transition is not taken until all the CEs on any FromLinks or ToLink are true.

 

In the Fork case, Or marks that all or some or none of the transitions may be taken. For XOR, I think none or exactly one can be taken (so the CEs must be consistent with this semantics).

 

In the Decision case, the CEs should also be consistent with the constraint that exactly one transition is taken. For this to be true, however, the CE on the FromLink really needs to be true.  For example, if you put a ConditionGuard language value of “Success” on the FromLink into a Decision, then it seems to me, that if the “from” BTA state failed,then the Decision would not be taken. So it would behave as an XOR in that case.

 

So I think we probably need to have some review on the point you raise, because the schema might be a bit out of line with what we need to have in place for Decision to make the specification and schema fit.

 

Also I think the “automatic disablement” remark probably needs some discussion. I will attempt to locate TC members who can discuss these issues further.

 

On the face of it, the schema currently permits Decision and an XOR join to work about the same for an actual set of CEs on the Links. So we need to decide how to enforce the semantics that is indicated in the text with some WF rules. I will check more carefully, but I do not think the necessary WF rules are in place for this. Thanks for your observation.

 

For the moment, the modeler will have to be careful to make certain that the CEs used on Links enforce the correct behavior with respect to gateway semantics. This area seems to be a good candidate for some clarifications in our errata, and eventually some improvements in our specification.