[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal 2
Tom, If I understand correctly, SOAP faults are primarily a predefined means of structuring information relating to faulty behaviour, which includes an open-ended ability to define application-level faults and present them in a standardized format. There are some cases in e.g. the HTTP binding where the way in which a SOAP-defined SOAP fault has to be delivered are specified (e.g. for violation of must understand and malformations), but there is nothing to prevent use of the SOAP fault structure by the application layer as being merely a style of formatting for the internal contents of an application message. Given this: 1) WS-TX (as a SOAP application) could have chosen to reinvent the wheel and used a different schema for protocol fault information, but has chosen to use the SOAP fault approach (one fault element in the SOAP body, of predefined format). WS-TX in doing this has adopted exactly the same approach as WS-Addressing (which is another SOAP application). 2) WS-Addressing SOAP Binding defines its predefined faults, for its layer, in exactly the same style as WS-TX does in defining protocol faults for its layer. WS-Addressing specifies an [action] property value for its own layer faults: <wsa:Action>http://www.w3.org/2005/08/addressing/fault</wsa:Action>WS-Coordination specifies an [action] property value for its subset of the WS-TX layer faults: as does WS-AT: Each states the rules for filling in the values needed for a SOAP fault element. 3) WS-Addressing in addition specifies rules for the formulation and processing of its own, predefined, faults, which ensure that the receiver can correlate a fault with a prior message that it sent (use of [relationship], which requires presence of [message id] and [reply|fault endpoint]). 4) WS-Coordination utilizes (incorporates) those same rules for delivery of its own faults, because it chooses to use the WS-Addressing correlation mechanism for delivery of all responses (good or faulty) to initial messages. 5) WS-AT and BA, possessing a different means for correlation (stateful conversations based on exchange of EPRs), do not need to use [message id] and [relationship] to ensure delivery of faults which will be understood (correlated) correctly by the fault receiver (original sender). Under proposal 2 WS-AT/BA (in this respect, like WS-Coordination) uses a common mechanism to deliver all "responses" (good or bad) to the original sender. But it uses a different mechanism than WS-Coordination (and WS-Addressing). 6) The use of a common mechanism for delivery of normal and fault protocol messages was a goal that Max first raised, and I think it is a good architectural principle. The input specs said: WS-AT/BA normal messages are delivered in one way, but the abnormal messages are delivered using WS-Addressing rules (which is an unnecessary overhead). I think the authors of Proposal 2 are seeking to straighten out that anomaly. I see no compelling reason to force use of the WS-Addressing fault processing model onto WS-AT/BA. WS-AT/BA have borrowed (or share) the formatting approach (the binding of app-layer faults to the SOAP fault structure) of WS-Addressing. It is now proposed that they do not borrow its targetting/correlation approach, because they have their own approach to these tasks (for good cause). Alastair Tom Rutt wrote: Ian Robinson wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]