RE: Some issues related to distributed choice

Dear Gary and others,
 
To the extent that I understand, I think I agree with what you say below.  I
think one issue that we need to clarify is:
 
is there just one instance of a choreography description that governs the
outworking of the entire distributed set of participants - in which case the
distributed choice problem you pose below probably is not such a problem
 
or is there a separate instance of the choreography description at each
participants - in which case the distributed choice problem certainly is a
problem (in my current understanding).
 
On the choice construct I thought the rules were:
If there are no guards on any of the possible choices then it acts as
non-deterministic choice - any of the choices can happen and it is not
stated how the decision will be made - could be by testing random number
generator or be some data - but any such mechanism is hidden in the
description.
 
If there are guards then each one is evaluated in order and the first one to
evaluate to true is taken - this is were there is sequence in the choosing
of which choice to take, but not the same as the sequence construct as only
one choice happens in the choice construct whereas in the sequence construct
all of them happen in the sequence stated (barring something interrupting of
course).  There is some subtleties about an attribute flag (block= I think
it is with look it up properly) which determines whether you wait for all
the variables in the guard expression to have a value, or whether you move
on if any value is not available or the expression evaluates to false.
 
I agree that the rules should be clarified if this is correct but not clear
at present - and even more so if what I say is not correct!
 
 
Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com <http://www.choreology.com/> 
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   Fax: +44 (0) 870 7390077  Mobile: +44 (0) 7801
948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Gary Brown
Sent: 27 August 2004 14:07
To: public-ws-chor@w3.org
Subject: Some issues related to distributed choice


Hi
 
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