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

Received on Thursday, 15 May 2003 12:21:12 UTC