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

RE: pi-calculus ...

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 13 May 2003 09:54:50 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1ABE@C1plenaexm07.commerceone.com>
To: "'jdart@tibco.com'" <jdart@tibco.com>, Assaf Arkin <arkin@intalio.com>
Cc: "Burdett, David" <david.burdett@commerceone.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>, "'Nickolas Kavantzas'" <nickolas.kavantzas@oracle.com>, "'Steve Ross-Talbot'" <steve@enigmatec.net>, public-ws-chor@w3.org


I agree. I think that publication SHOULD be on a "need to know" basis. If
your internal business process involves carrying out choreographies with
roles that other roles have no need to know about then they should be
defined as separate choreographies that are under the overall control of
your internal business process.

Really though I think this is primarily a question of good choreography
design rather than a constraint on what our choreography spec should allow. 


-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Tuesday, May 13, 2003 9:45 AM
To: Assaf Arkin
Cc: Burdett David; 'Jean-Jacques Dubray'; 'Nickolas Kavantzas'; 'Steve
Ross-Talbot'; public-ws-chor@w3.org
Subject: Re: pi-calculus ...

The only caveat I'd make here is related to the earlier discussion about 
visibility. In a B2B scenario, I may not want to publish to all 
participants a definition that includes "all the behaviors of all the 


Assaf Arkin wrote:
> Burdett, David wrote:
>> So how about as a requirement ...
>> "The choreography specification must provide a method of defining the 
>> rules and sequence for exchanging messages between two or more roles 
>> (e.g. buyer, seller, etc) that:
>> a) Provides a single choreography definition that covers all the 
>> behaviors of all of the roles
>> b) Treats each role equally
>> c) Specifies messages in an abstract way, i.e. independent of the 
>> precise data structures and transport binding."
>> David
> Of course I would say +1 to this, since it defines the problem we're 
> trying to solve and provides a good pattern for any solution.
> arkin
Received on Tuesday, 13 May 2003 12:54:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:04 UTC