W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

Re: General Choreography and Bi-lateral Choreography

From: Monica J. Martin <monica.martin@sun.com>
Date: Mon, 17 Mar 2003 09:23:15 -0700
Message-ID: <3E75F673.A886A9BE@sun.com>
To: Assaf Arkin <arkin@intalio.com>
Cc: Ricky Ho <riho@cisco.com>, "Burdett, David" <david.burdett@commerceone.com>, public-ws-chor@w3.org



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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:06 GMT