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

Re: Co-ordination protocol and BPEL

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 23 May 2003 11:28:32 -0700
Message-ID: <3ECE6850.3020707@intalio.com>
To: "Monica J. Martin" <monica.martin@sun.com>
CC: Mark Little <mark.little@arjuna.com>, Ricky Ho <riho@cisco.com>, public-ws-chor@w3.org

Monica J. Martin wrote:

>>> <<Mark Little: Actually that's not strictly true. WS-Tx doesn't 
>>> mention how contexts are
>>> propagated at all at the application level (which is a bad thing for
>>> interoperability and I'm certain will be changed in a new revision). 
>>> So, you
>>> an implementation is allowed to propagate a context back on replies 
>>> in the
>>> same way traditional TP systems do (e.g., the OTS).
>> Arkin (I think): Although this is not written in the spec my 
>> assumption is that you do always propagate the context back in 
>> replies. But all you propagate in the context is the context 
>> identifir and the registration service.
>> In order to send back any other information about the participant 
>> (i.e. it's state) you need to use a separate header, which based 
>> solely on WSDL you can. But I'm afraid that unless an example is 
>> given in the spec on how to do it, most systems will simply not do 
>> it, which would create an interoperability problem. This can be fixed 
>> simply by adding another paragraph and one short example where the 
>> reply contains some state headed, like completed or failed.>>
> On the last point and with respect to some recent discussion, I 
> suggest we consider what implications exist if we assume that we trade 
> state rather than it being understood at a global view.

This is why this discussion is actually interesting to this group. The 
state we are talking about is completed/exited/failed and relates to the 
coordination protocol. From the perspective of the choreography it is 
considered out-of-band. It does not indicate that an order has been 
fulfilled, or that the order has been rejected, but rather tells the 
coordinator how to proceed.

Of course it can be abused. For example, I can decide to send a WS-TX 
failed message instead of communicating an error. This tells the 
coordinator interesting information but doesn't explain anything to the 
business process (what is the nature of the error? can I do something 
about it and do some other operation?) I can decide to send a WS-TX 
completed message instead of communicating that I will fulfill the 
order. This also is of no use to the business process which can't really 
determine what has been completed, doesn't have a clue if/when products 
will be delivered, or even how to track fulfillment.

So one of our responsibilities would be to write clear guidelines 
specifying what the choreography should define as explicit messages, 
regardless of which coordination protocol it ends up using, if at all. 
At the same time we should allow it to use a coordination protocol which 
gives the non-business part of the infrastructure some way to determine 
what is going on.


> Thanks.
Received on Friday, 30 May 2003 02:43:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC