W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

Re: Relationship cardinalities (was ... RE: Requirements: Decision Po ints Requirement Proposals

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 09 Jun 2003 12:18:21 -0700
Message-ID: <3EE4DD7D.3030901@intalio.com>
To: "Burdett, David" <david.burdett@commerceone.com>
CC: "'Jean-Jacques Dubray'" <jjd@eigner.com>, "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>

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

Burdett, David wrote:

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

Received on Monday, 9 June 2003 15:19:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:59 UTC