RE: pi-calculus ...

Ricky

You said ...

>>>Or do we define 1 choreography (for A/B/C) and then apply a filter to
extract another choreography for C/B ?<<<

Although you could do this, I am wondering what the benefit would be?

For example there might be several different ways in which C&B could
exchange messages to realize the same end goal. "A" should not know about
this unless there is a real need - i.e. it affects, in some way, A's
behavior.

If A's behavior is not affected, then it means that any change to the B/C
choreography should result in A being informed since he has the complete
A/B/C choreography.

If on the other hand A does need to know, then you can might want to think
of the A/B/C choreography as an *extension* of the B/C choreography. I
always think that extension is better than subsetting or filtering as it
promotes reuse and is, I think, actually easier to do.

David



-----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, 16 May 2003 14:19:54 UTC