RE: General Choreography and Bi-lateral Choreography

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Monica J. Martin
> Sent: Monday, March 17, 2003 8:23 AM
> To: Assaf Arkin
> Cc: Ricky Ho; Burdett, David; public-ws-chor@w3.org
> Subject: Re: General Choreography and Bi-lateral Choreography
>
>
>
>
>
> > <aa>
>
> > Multi-party choreography (or multi-party collaboration as
> proposed for BPSS)
> > does not say you need to always synchronize the state with all possible
> > parties. It allows you to synchronize different states with different
> > parties. So seller talks to buyer discussing what is important
> for seller
> > and buyer to agree on and there's no reason for them to also involve the
> > carrier until the point in which it becomes valuable for the
> carrier to know
> > something. And the carrier only needs to know what relates to
> the carrier,
> > so you don't update everything for the carrier. There's a clear
> separation
> > of constraints which fits quite nicely.
>
> </aa>
>
> <mm> The state synchronization should be maintained if possible.
> Otherwise, the
> terms and conditions of the business collaboration may not be met.

Agreed. This is an example where all terms and conditions are met without
synchronizing everything. The terms and conditions between the buyer,
supplier and carrier are fully met without having the carrier know
everything about the purchase order (e.g. the quoted price, the line items,
the billing address) but only some details (e.g. the weight, delivery date,
who pays for the shipment).

Arbitrarily updating anyone about everything is the easier way
technologically speaking, and it may meet the goal of simplicity but in fact
it violates a key business goal of security: information should be
disseminated only to those parties who need them to meet the business goal.

So, in fact, by specifying what information is communicated between which
parties we can in fact express:

1. What information is shared to allow some business conditions to be met

2. What information is not shared to allow other business conditions to be
met

And a combination of both is one of the compelling reasons for multi-party
choreographies.

>
> > <ro>
>
> > 2) Dynamic binding between roles and business entities can
> happen after the
> > choreography instance is created.  This introduce additional
> complexity such
> > as an extra protocol among existing parties to control the
> rebind, as well
> > as how to reach a consensus about the rebind.
> > </ro>
> > <aa>
> > I don't see why a separate protocol is required. All you need
> to do is be
> > able to communicate end-points, which is the beauty and
> simplicitly of the
> > mobile process calculus model. And communicating end-points is
> simple, just
> > send someone the WSDL service definition of the service you want them to
> > talk to. UDDI works that way. In fact the Web works that way.
> > I guess I just don't see the complexity here.
>
> <aa>
>
> <mm>
> On the dynamic rebind if the terms changed, this may not meet the
> contractual
> requirements for a business collaboration and particular business
> rules may
> apply.  This potentially a more complex issue than the scenario
> for which you
> decompose it.

I am making an assumption that the choreography is defined to meet the
business goals and not that the choreography is defined with the hope that
given enough runs it will meet some business goal.

So if the business goal is one which dictates a requirement that all parties
be known upfront, I would assume that the author of the choreography (or a
tool that is used to meet these restrictions) would not allow such usage. On
the other hand, I can came up with more than one scenario where the business
goal is written such that not all parties are needed to be known upfront, in
which case I would like to be able to write a choreography that supports
this business goal.

arkin

Received on Monday, 17 March 2003 15:30:34 UTC