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

David,

I think there might be some value in raising the level of abstraction
used in the description.  I'll try to illustrate with comments in-line.

AndyB

On Thu, 15 Jan 2004 15:22:15 -0800, "Burdett, David"
<david.burdett@commerceone.com> said:
> 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.

While the implementation certainly needs messages to pass between
participants, the semantic issue for the choreography is whether the
participants need to be aware of other participants and what actions by
other participants are significant.  The required awareness could be
achieved by direct
messaging, multicast, messaging via a broker etc.  The realisation is an
implementation issue.  Unless I misunderstand the charter of this group,
we probably shouldn't define the implementation.

> 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.

[...]

> 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.

My approach to this problem has been to define roles with cardinality
(multiplicity) constraints.  Choreography behaviour is defined in terms
of those roles, not the endpoints.  Endpoints are bound to roles when
instantiating the choreography (or by dynamically adding endpoints if
supported) subject to the role cardinality constraints.  For example, a
bidder role in an auction choreography might have (1..*) cardinality. 
Behaviour associated with a role having multiple endpoints effectively
defines your "group" messaging above.

A group abstraction adds another dimension of expressiveness to
specifications but also adds a new set of problems.  Role behaviour can
be quite difficult to specify accurately, in particular, it can be
difficult to distinguish between behaviour of all endpoints in the role
(e.g. all bidders receiving a bid notification), behaviour of a subset of
the endpoints (e.g. all 'active' bidders receiving a bid notification)
and behaviour of an individual in the role (e.g. bidder making a bid). 
It becomes more complex when there is causally dependent behaviour
leading from subset or individual behaviour (e.g. only bidders who
received a bid notification can make a counter-bid).  These issues have
to be dealt with if you want to specify group behaviour, regardless of
the abstraction chosen.

As discussed in my previous email on this topic, maintaining accurate
group membership is a major issue if dynamic addition of endpoints is
allowed.  You can simplify the problem by not allowing group membership
to change after instantiation, but this restriction might not be
acceptable.

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

Yes, I think it's a good one.  I'll try to look over it in more detail in
the near term.

Ciao,

AndyB

Received on Thursday, 15 January 2004 21:53:23 UTC