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

>>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.
>
>>or 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.[...]
>>
mm1: Whether or not the suppliers in an auction have visibility is often 
driven by a business-level agreement. Choreography is the technical not 
the business-level agreement. How the technical contract becomes aware 
of these constraints is another discussion.

>>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.
>>    
>>
mm1: David, price and branding are competitive advantage. Auctions may 
be more often closed than open to all suppliers. Which is the most 
prominent I cannot say.  See previous point about business-level agreements.

>>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.
>
mm1: This, I believe touches on Tony Fletcher's point at the F2F 
regarding role and role type, and the associated continuing discussion.

Received on Tuesday, 20 January 2004 15:42:52 UTC