RE: Relationship cardinalities (was ... RE: Requirements: Decisio n Po ints Requirement Proposals

Assaf

I always tend to think that one role can take part in multiple
choreographies, for example a buyer could take part in:
1. Several different choreographies each of which resulted in the placement
of an order
2. A separate order status choreography that could work with any of the
different choreographies.

I also recognize that the same choreography and roles could be invented
multiple times. For example, the shoe industry could invent a choreography
for placing orders that was identical to one developed by the wine industry
but they give the choroegraphies different identifiers (URIs) for
choreography itself and each of its roles.

This is really a broader standardization issue that will only be solved when
there is choreography instance standardization. For example the UBL
initiative is developing standard representations and semantics for order
documents using XML schema. We really need standard order placement
choreographies to be developed using WS-Chor ... but we need WS-Chor first.

David


-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, June 09, 2003 12:18 PM
To: Burdett, David
Cc: 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor Public'
Subject: Re: Relationship cardinalities (was ... RE: Requirements:
Decision Po ints Requirement Proposals


For brevity sake, two comments and +1 on everything else.

Burdett, David wrote:

>CHOREOGRAPHY RELATED
>1. A role may take part in one or more choreographies
>For example a buyer there are several different ways of placing orders that
>involve different sequences of messages. However the basic role stays the
>same.
>  
>
That depends on how you define a role. You can define a role as being a 
component of the choreography in which case a role participants in one 
choreography. That does not restrict an entity from being multiple roles 
in multiple choreographies. You can define roles that participate in any 
number of choreographies, but I'm not sure what it buys you, and if 
you're having problems reaching agreements you probably would have a 
problem agreeing to use the same role in multiple choreographies. 
(Again, won't restrict the same entity ...)

I accept that as a party intending to buy products I would assume the 
role 'buyer' in one choreography, 'procurer' in another, and 'sucker' in 
a third one. On the other hand, I may be expected to operate in the same 
way in all three choreographies, i.e. implement the same interface, but 
that brings us back to the role=interface equality, mobile process model 
and all other undesirable solutions.

>4. A choreography specifies the sequence, conditions and dependencies of
>sending one or more messages
>This is really the core of what choreographies are all about. The only
>question I would have is whether this is compatible with the ideas of
>pi-calculus, and if it isn't does it matter?
>  
>
Yes it does. And if it doesn't then pi-calculus wouldn't be relevent to 
our work.


arkin