RE: Approaches to Web Services Choreography [was Same model for both Public and Private process ??]

>>> [JJ] Yes but in WSCI you need to express two API choreographies + a
>>> global model to achieve a collaboration choreography definition. So
yes
>>> they all fit logically in a document, but that sounds like a lot
more
>>> work compared to a BPSS specification.
>>
>>I think you are confusing choreography with process or interface. The
>>choreography is described by the global model. Just like a BPSS
>>collaboration can include multiple transactions a WSCI choreography
could
>>include multiple processes/interfaces by referencing them.
>>
[JJ] If you look at figure 5-3 of the WSCI spec, you can see clearly
that each "side" of the collaboration has its own (and independent)
"choreography" specification, then they are all tied together via the
global model. Maybe I am missing something.

>>
>>> [JJ] In my opinion, the mobility of Pi-calculus translates in the
B2B
>>> world into the capability of a given business partner to conduct
>>> business with the same choreography specification regardless of the
>>> business partners it is physically working with. Something that BPSS
can
>>> do without problem.
>>
>>Are you sure?
>>
>>I understand why you would want to claim that BPSS emodies the
concepts of
>>process calculus and mobility. But let's be careful when making
sweeping
>>statements like the above.
[JJ] Honestly, I don't want to claim anything about BPSS as it is not a
spec that aims to be adopted as is by ws-chor like WSCI is attempting to
do.

>>It appears to me that all the objections to WSCI, BPEL4WS and BPML are
>>based
>>on the ground that these specifications are rooted in the WSDL model.
You
>>would rather see a choreography, I assume also execution, language
that is
>>based on CPP/CPA, or a similar model.
[JJ] Again, this is irrelevant to the discussion, all I am advocating is
that ws-chor adopts a neutral concept is layered above WSDL upon which a
choreography can be expressed. This approach will remove the need to
either:
a) do like BPEL, use a single sided view of the collaboration as seen by
a partial internal business process to actually define a collaboration
between parties
b) do like WSCI, forces people to model the choreography of all sides of
the collaboration and then stitch them together (again this is what is
shown on figure 5-3 quite eloquently) 

If this approach is chosen nothing precludes us to bind it to WSDL or a
CPP/CPA mechanism. Choreography and Technical binding MUST be
orthogonal, by expressing choreographies of WSDL entities you cannot
achieve this desirable decoupling.

I repeat, the only difference between the approaches is to consider WSDL
either as an end point or a starting point. Nobody says to get rid of
WSDL. It is only a question of layering. 

JJ-

Received on Tuesday, 11 February 2003 13:42:46 UTC