Some issues related to distributed choice

MessageHi

On re-reading the latest draft of the spec, it appears that the choice construct does not have any restrictions. Therefore, at the moment, it is possible to define a choice statement containing interactions for different relationships, and different directions. The section (2.5.1.3) only describes an example that is restricted to a single relationship, with the same directionality (and fromRole/toRole) - however the spec does not indicate that this is a mandatory restriction.

If there are to be restrictions on what a choice activity can represent, we need to make sure they are clearly stated.

However, even if such a restriction is placed on the choice statement (as described in the example), I can still see a case where a distributed choice could occur. For example,

<choice>
    <interaction from="service1" to="service2" operation="foo" />
    <noaction/>
</choice>
<interaction from="service2" to="service1" operation="bar" />

In the description of the choice statement, it says that if an activity (inside the choice) is not a workunit (with a guard), then it is assumed that the selection criteria for the activities are non-observable. Therefore, in the case above, the choice represents the fact that we could optionally get an operation 'foo' from service1 to service2, followed by operation 'bar' in the opposite direction, or we could simply get operation 'bar'.

As these interactions are in different directions, we again get the situation of a potential race condition due to a distributed choice.

Suggestions:

1) I think we need to clarify what restrictions are to be placed on activities such as choice

2) A choice should probably only support two trigger types - one being a workunit, where the choice represents an if/else construct, and the other being for interactions - and all of the activities within a choice statement must use a consistent type of trigger (e.g. all workunits, or all interaction based triggers).

3) We need a way to represent logic that is conditional upon a non-observable condition. I thought workunit would allow this, but the current version of the spec implies that if the condition is not specified, then it would operate like a sequence - which begs the question, why have two constructs that represent the same semantics?


This also suggests that the solution I proposed for bi-directional interactions in a choice construct, to overcome the distributed choice problem, may need to be widened to cater for interactions that are subject to a race condition but are not necessarily contained within a choice statement. Potentially this could be solved by directly annotating the interactions to indicate priority levels. On validation of a CDL specification, if the validator detects that a race condition could occur, and a clear distinction between priorities has not been specified, then it will flag an error? This means that it does not matter where the interactions are defined - inside or outside of a choice or other conditional construct.


Regards
Gary