Re: [ws-tx] Issue 30 - One-way message replies

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

Doug, Mark:

The reason for my proposed options A and B was to ensure that we deal explicitly with all of the questions raised by this whole discussion, and to underline  how close we are (perforce, in my view) to option B anyway. (Option B is the one that Ian enumerated as proposal 4, which he considers to be too radical a departure from the input specs).

If I look at the minutes of the F2F (which I know accurately capture day one, that I attended), then we see a recurrent theme (particularly from Ian and Max): that [message id] and [relationship] are not mandatory, that their presence cannot be relied upon. (See end of this posting for some representative statements from the minutes that capture this theme.)

I contend that this is unlikely to be true. Here's why (Section 6 of WS-Addressing, SOAP Binding):

"Endpoints compliant with this specification MUST include the required message addressing properties serialized as SOAP headers in generated fault messages. Fault messages are correlated as replies using the [relationship] property as defined in Web Services Addressing 1.0 - Core[WS-Addressing-Core]. Note that omission of the [message id] property in an input message may impact the ability of a fault message receiver to correlate the fault message to the message that caused the fault message to be generated. Omission of the [fault endpoint] or [reply endpoint] properties in input messages may impact the delivery of a generated fault message."

Three questions on this aspect:

1. Are we agreed that we must be prepared to send/process WS-Addressing predefined faults?

2. Are we agreed that WS-TX faults are to be sent as fault replies, in accordance with Section 3.4 of WS-Addressing Core, or are they to become "yet another application message" (as Max suggested they might)?

3. Do we agree that Section 6 of the WS-Addressing SOAP Binding effectively mandates use of [fault endpoint]/[reply endpoint], [message id] and [relationship] properties to correctly handle fault processing?

Bob Freund's comment at the F2F is germane:

Bob: [...] If you have a one-way only message, and don't expect to receive either a reply or fault to that message, you don't need to use replyTo.

A further question on a secondary topic that was discussed to some degree at the F2F:

4. Does the default setting of [reply endpoint] to "anon" have any impact on processing of messages that are deemed, by application contract, to not be subject to reply processing rules? In other words is it relevant or irrelevant to consider setting this to "none", if the [reply endpoint] is not going to be used?

Given the lack of clarity on this whole area, I would strongly favour a resolution (and therefore text in the specs) that clearly states what must be present by way of WS-A properties, and when they are to be used. I.e. we need to write the application contract down in an explicit and full fashion, and not rely on "defaulting to WS-Addressing", which allows considerable flexibility (aka rope to hang oneself).

Alastair


F2F minutes: Representative statements on the need for message ids and relate-to:

E.g., on day one:

"Joe Fialli: The WS-AT spec, talking about WS-A, does not explicitly state that a message-ID is sent.  It is not clear.  It should have stated that messageID is mandatory.

Ian: It's not mandatory.

...

Bob: The concept of ReplyTo and use of messageId with it is intended to help correlate messages.  In WS-A, we don't specify how that is to be accomplished.  If WS-TX wants to use them for correlation, that is okay, or even not using them is okay.

Ian: A question: The new WS-A does not require messageId, so we may be able to change our implementation.

Max: We need to address fault messages, line 476 in WS-AT.

Eric: Remove line 476-477, Addressing does not require that.

Max: Is there such a thing as a one-way fault?  We could think of them as one-way application messages which are not replies.

Alastair: Lines 485-488 need to be considered.

Max: We should remove that."

And on day two, discussing interop scenarios:

"Max: The actual message-ID relatesTo may not be there in every case, you can't rely on them. 

Bob: It provides no useful information that you can rely on in an interoperable fashion.  Should we put a normative MUST NOT with relatesTo?

Ian: We don't need to consider ReplyTo if it's modeled as one-way messages.

Ian: Agreement seems general that this is the case.

Joe: I disagree."

And further on day two, still discussing interop scenarios:

Bob: [...] If you have a one-way only message, and don't expect to receive either a reply or fault to that message, you don't need to use replyTo.

Max: We would not require messageId.  Using messageId relatesTo makes it confusing.

Doug: What values does it add?  In one-way messages, it does not add value.