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 Tuesday, 20 May 2003 13:24:50 UTC