Re: Issues summary (possibly to discuss on the call)

Some followup comments on the issue summary in-line.

Ciao,

AndyB
--

> Bug 342: The issue is that the choreography working group needs to  
> resolve the notion of turing
> completeness.
> 
> The issue revolves around two things.
> 
> Firstly is it possible to describe the external observable behaviour  
> for all choreographies without
> the need to use any conditional logic?

I would answer this with an example.  Let's say the business-level
agreement specified that if an account wasn't paid within 30 days, then a
recovery process is begun (the details of which are specified in the
choreography).  Definitely conditional logic, whether expressed as an
exception or otherwise in the choreography.  It is also behaviour that
must be observable by the parties involved: part of their business-level
agreement.  If you agree with those two assertions, then I think we need
conditional logic in choreographies.

> Bug 317: Do all participants need to be known in advance?
> 
> related to issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=312
> 
> Is there a notion of unbounbded participants e.g. a choreography asks n
> suppliers to place bids.
> 
> Discussed at the June F2F
> http://www.w3.org/2002/ws/chor/3/06/JuneF2FMinutes.html

Can you clarify whether this means unbounded at specification time or
unbounded at run time?  Unbounded at run time opens a whole new set of
issues, as noted on the next point below.  Unbounded at specification
time is much easier to deal with.

> Bug 312: Can actual partipants in a choreography change during the  
> lifetime of a choreography
> 
> taken from 6th May telecon
> http://www.w3.org/2002/ws/chor/3/05/06-minutes.html
> 
> could be solved by allow participants to leave and join a choreography  
> during its lifetime.
> 
> What mechanism() are required to support this dynamic feature?

If a consistent view of the participants is required, then you need a
reliable, distributed group membership protocol.  These are hard.  I can
dig up some research papers on the subject if desired.  Ken Birman did
considerable work in this area with Isis in the 80s and early 90s.  The
key problem is that your execution semantics will usually require that
all (distributed) actions are serialised relative to the membership
change.  In other words, all visible behaviour occurs either before or
after the membership change.  This requires synchronisation across all
participants and is very expensive for large numbers of participants.  It
can also lead to unbounded blocking if any participant has died or their
network connection is down.  Note that if your language operational
semantics approximates true concurrency with interleaved concurrency,
then you won't see this problem unless you know what you're looking for
[sorry, couldn't resist a dig at process calculi :-)].

If you can define a semantic model that doesn't require a consistent view
of the participants, then the implementation difficulties go away. 
Consider the following problem, however: there's an auction and the
choreography says that all bidders must be notified of a new bid.  What
does "all" mean?  In this case we can define that "all" is the view of
the "auctioneer" participant at the time of receiving the bid (i.e. a
single point of reference).  If there is no single point of reference and
no consistent view of participants, then there is no consistent
definition of "all".  Most people find this hard to work with.

The simple solution is to require a broker and have a single definitive
'state' for the choreography held by the broker.  I assume that's not in
the list of acceptable options, and I personally don't favour it anyway.

In my work, I considered the dynamic addition of a participant to require
re-binding (i.e. a new instantiation of the choreography), which is
equivalent to serialisation.  Note that such re-binding can be automated
with a set of rules for dealing with participants that are inaccessible
(e.g. exclude them), and defining the state that must be carried through
to the new binding and new participants.  The dynamic re-binding
semantics didn't make it into my operational semantics, so I don't have a
formally-defined solution.  I was also inclined to make the rules for
re-binding programmable in a meta-model but that was something left for
future work.

Ciao,

AndyB

Received on Thursday, 15 January 2004 02:52:35 UTC