RE: General Choreography and Bi-lateral Choreography

<ro>
Let me rephrase my previous e-mail and say we should define a special case
of choreography called "bi-lateral choreography" by add some restriction
around the generic choreography model.  The purpose is to avoid the
following complexities inherited in the generic multi-party choreography
1) Because message exchange is always bi-lateral.  Therefore, it is
complicated to synchronize the "public state" with all the parties.  Of
course, we can have a 2-phase handshaking protocol similar to
WS-Coordination to achieve that, but this leads to more complication.
</ro>

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

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

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.

arkin

Received on Sunday, 16 March 2003 16:32:19 UTC