Re: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal 2

[Alastair Green <alastair.green@choreology.com>]

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:

      http://docs.oasis-open.org/ws-tx/wscoor/2006/03/fault

as does WS-AT:

     http://docs.oasis-open.org/ws-tx/wsat/2006/03/fault

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:

There has been a lot of discussion and some good comments suggesting
refinement of "Proposal 2" for issue 30. Specifically:
  Alastair's point that the WS-C spec defines the Coodination faults as
  "reply messages" but the WS-AT spec defines AT faults as "notification
  messages". The refined proposal clarifies that the specific messages
  exchange patterns apply to the protocol rather than to individual
  messages and that protocol fault messages are constructed according to
  the rules of the protocol in which they are used.
  Bob's objection to the use of phrases like ' "one way" pattern as
  defined in WS-Addressing '. The proposal replaces this with ' The
  protocols defined in WS-AtomicTransaction use a "one way" message
  exchange pattern consisting of a sequence of notification messages
  between a Coordinator and a Participant. '
  Joe's observation of the inconsistency in specificity between references
  to WS-A from Coordination on the one hand and AT on the other. These are
  now uniformly precise. Also the proposed text now refer to the abstract
  message addressing properties rather than to soap header elements.

Max and I have updated our proposal to address these concerns.
 

I am confused by the proposal.

Both the proposal for ws-coor and ws-at include a beginning section about faults include text
regarding soap faults.  Are some of the "message types" defined in these specs going
to be mapped onto soap fault messages?.

I believe strongly that any message which is mapped onto a soap fault should be treated as a ws-addressing fault,
and should use the ws-addressing replyTo address and have a relatesTo in its header.

Is that the intent of this proposal?

Tom Rutt

(See attached file: Issue30_Proposal_2_WSBA.doc)(See attached file:
Issue30_Proposal_2_WSAT_updated.doc)(See attached file:
Issue30_Proposal_WSCOOR_updated.doc)

In accrodance with the decision of the TC on the last telecon, the text
remains silent on the handling of non-TX fault messages.

We have been discussing this issue for a month now, and we have other work
queued up. Could I suggest that any further refinements or
counter-proposals be written in terms of concrete spec language that the TC
would be able to vote upon on the next telecon.


Regards,
Ian