RE: pi-calculus ...

+1

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
> Sent: Tuesday, May 20, 2003 10:25 AM
> To: 'Ricky Ho'
> Cc: public-ws-chor@w3.org
> Subject: RE: pi-calculus ...
>
>
>
> 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
> > >
> > >
> > >
> > >
>
>

Received on Friday, 23 May 2003 13:04:47 UTC