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

Andrew

You said ...

>>>Can you clarify whether this [the notion of unbounbded participants]
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.<<<

The key issue here is whether all the participants involved need to exchange
messages with each other. For example, a classic example is conducting an
auction where the number and specific suppliers that the buyer invites to
take part varies from auction to auction.

In a "sealed bid" auction, then the buyer would want to keep the interaction
with each buyer separate this means that it can be considered as a series of
separate parallel choreographies (one with each supplier) that they buyer
coordinates through a private process. This means that there is no need for
a choreography with multiple variable participants.

However in an open auction, (e.g. as in eBay), each supplier would see each
bid made by every other supplier. This is more complex as:
* suppliers could join/leave the auction at will
* the same message would need to be sent to multiple supplliers by the buyer
to indicate that a new bid had been made.

You might be able to solve this by specifying the destination of a message
as being a "group" of endpoints rather than a single endpoint.

I'll write this up as a use case ...

David

David

-----Original Message-----
From: Andrew Berry [mailto:andyb@whyanbeel.net]
Sent: Wednesday, January 14, 2004 11:53 PM
To: Steve Ross-Talbot; public-ws-chor@w3.org
Subject: 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