- From: Assaf Arkin <arkin@intalio.com>
- Date: Fri, 23 May 2003 11:28:32 -0700
- 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. arkin > > Thanks. > >
Received on Friday, 30 May 2003 02:43:12 UTC