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

Re: pi-calculus ...

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Tue, 20 May 2003 20:42:49 +0100
Cc: "'Ricky Ho'" <riho@cisco.com>, public-ws-chor@w3.org
To: "Burdett, David" <david.burdett@commerceone.com>
Message-Id: <3CBC3F92-8AFB-11D7-AD56-000393AD2AA6@enigmatec.net>

A somewhat inane comment but ... what has this got to do with the 
pi-calculus?

Cheers

Steve T

On Tuesday, May 20, 2003, at 06:24  pm, Burdett, David wrote:

>
> Ricky
>
> Segmentation is useful if one organization (say A) has designed an 
> "uber"
> business process involving many organizations because:
> 1. "A" can check the complete business process for completeness and 
> accuracy
> much more easily as the whole definition is in one place
> 2. "A" can then automatically (?) split the choreography into segments 
> to
> give to the other participants (e.g. "C") to implement.
>
> Basically "A" is in control and "A" is designing their own internal 
> process.
>
> Looking at it from "C"'s perspective produces the following
> 1. "C" realizes that it told to develop a choreography that involves 
> "A",
> and "A" is telling "C" exactly what that choreography must be
> 2. "C" also realizes that in order to implement the choreography it 
> must
> also involve "D" which "A" knows nothing about.
> 3. Therefore "C" has to include the already existing choreography that 
> "A"
> has developed into its's interaction wtih "D".
>
> So really segementation is the same as inclusion. It all depends on 
> your
> perspective
>
> Davidxd
>
>
> -----Original Message-----
> From: Ricky Ho [mailto:riho@cisco.com]
> Sent: Thursday, May 15, 2003 9:04 AM
> To: Burdett, David
> Cc: public-ws-chor@w3.org
> Subject: RE: pi-calculus ...
>
>
> Lets say there are 3 roles A, B, C in a choreography.  A and B need to 
> know
> the detail of every other role but C only need to know about B.
>
> Do we need to define 2 choreographies (one for A/B/C, and the other for
> C/B) and verify their conformance ?
> If the answer is "yes", then I agree that this is a question of good 
> design
> practice.  Otherwise ...
>
> Or do we define 1 choreography (for A/B/C) and then apply a filter to
> extract another choreography for C/B ?
> If the answer is "yes", then we need to support the "segmentation" 
> concept
> in our choreography model.  Then Jon's concern is very valid.
>
> Rgds, Ricky
>
>
> At 09:54 AM 5/13/2003 -0700, Burdett, David wrote:
>
>> Jon
>>
>> 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.
>>
>> David
>>
>> -----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
>> roles".
>>
>> --Jon
>>
>> 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
>>>
>>>
>>>
>>>
>
> This email is confidential and may be protected by legal privilege. If 
> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> Whilst we run antivirus software on all internet emails we are not 
> liable for any loss or damage. The recipient is advised to run their 
> own antivirus software.
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.
Received on Tuesday, 20 May 2003 15:43:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT