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.

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

Received on Monday, 17 March 2003 11:31:50 UTC