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

Martin
 
See comments in line.
 
David

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Monday, June 09, 2003 2:29 PM
To: Burdett, David; 'Assaf Arkin'
Cc: 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor Public'
Subject: RE: Relationship cardinalities (was ... RE: Requirements: Decisio n
Po ints Requirement Proposals


David,
 
In my view it is a party (participant, instance etc) that takes part in a
choreography.[David Burdett]   They do so by taking on one (or more ) of the
defined roles.  
[David Burdett] Agreed. 
There is no formal relationship between roles in different choreographies,
otherwise they would be part of (the same) choreography definition.
[David Burdett] Not sure. For example if you design four different
choreographies that are alternative ways of doing the same thing (e.g.
placing an order), wouldn't the role stay the same?
At most the relationship between choreographies will be akin to a type
library that gets used in multiple progams.
[David Burdett] Agreed. 
 
Martin.
 
 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]On
Behalf Of Burdett, David
Sent: Monday, June 09, 2003 1:35 PM
To: 'Assaf Arkin'; Burdett, David
Cc: 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor Public'
Subject: 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 <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