WS-Addressing: no essential difference 2004, CR, 2006 on [reply endpoint]

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

In regard to the action item on reviewing use of WS-Addressing so that we can reference the latest version.

I think it is wrong to say that perceived issues with the use of WS-Addressing [reply endpoint] in WS-TX are caused by the "change from 2004 [submission] to W3C." I also doubt the statement that W3C is more "lenient" than 2004 with respect to presence of message id accompanying relates-to.

The change to WS-A from 2004 to W3C does not change anything essentially for WS-TX, with respect to the use of [reply endpoint]. (This does not mean there are no changes in other respects, nor does it obviate need to review use WS-Addressing.)

2004-08, the CR (2005-08) and the latest working draft (en route to PR) all specify an identical set of rules to follow if the application contract deems a message to be a "reply". The rules become clearer in each successive draft, but they are the same rules. It's a bit like the lawyer saying "What my client meant to say ...".

For each of these three versions, the rules are quoted at the bottom of this mail. In 2004 it's section 3.2 and prior statements in Section 3 describing properties; in 2005 they are grouped into section 3.3, in the latest version this has become sections 3.3 and 3.4.

In all three versions if the message is deemed a reply (not a one-way) you:

• MUST use message id when using reply-to, i.e.must fault if no message id is present,
• correlate reply with relates-to,
• MUST target reply on the received reply-to EPR
• follow the rules on using fault-to and reply-to for fault messages

In all three versions, if the message is deemed not to be a reply (is a one-way) you

• don't have to use a message id,
• don't have to correlate reply with relates-to,
• don't have to reply to reply-to EPR
• don't have to follow any rules on fault-to and reply-to for "faults"

The WS-Addressing WG (e.g. Marc Hadley's response to my posting, Bob's comments yesterday at the TC) seem happy that you can have something that is a direct response to a prior message which is logically related, part of a conversation etc but which is deemed not to be a "reply" in the special sense that triggers the rules for formulating a reply (Sections 3.3 and 3.4 in latest version).

This is in line with the original statements by Max and Ian on the March 9th call: "these messages are not replies in the WS-Addressing sense". In which case: it looks like they never needed to have message ids, and never needed to use reply fault processing rules. If we are now going to change the design, then we should be clear that is what we are doing, and be equally clear that use of W3C WS-Addressing does not compel us to make any change. (If you believe WS-Addressing has increased in leniency, then there is all the less reason to make changes.)

The course of minimum change is:

Least change approach to use of WS-Addressing: change the spec, not the interop scenarios, and change less in the implementations

1. Explicitly state for clarity: "These one-way messages, despite their use of wsa:ReplyTo, are not replies in the special sense of WS-Addressing, i.e. the rules stated in section 3.4 of W3C WS-Addressing ("Formulating a Reply Message") do not apply." I think this is the kind of explicit statement Monica was suggesting.

2. Add into the old Section 9 of WS-AT rules, which now appear in both WS-AT and WS-BA, the statement that message id is required alongside the reply-to bringing spec in line with reality of all preceding implementations and the interop scenarios.

3. Leave the fault correlation rules in place (send to fault-to, cite message id in relates-to). (No change to the specs).

That is: we can codify the decision of the input authors to write their own special rules for using reply-to and message ids (send the stuff, ignore it for replies that are not faults, copy the WS-A rules for replies that are not faults). Message id will be sent, but not used, except for faults.

If we do that then we will restrict change in implementations to namespace changes and the like.

Note that this type of special behaviour is not tested by the WS-Addressing interop scenarios, so presumably everyone's WS-Addressing implmentations will handle this kind of special behaviour just fine ;-) . Joking aside, I think they will handle it properly, because it would require some serious conscious effort to enforce use of replies (in the strict section Section 3.4 sense), as opposed to facilitate their use.

Do not favour least change in this case

Having said that, I think that using the [reply endpoint] in this special way is misleading and unnecessary. It grabs a property defined as the cornerstone of a set of well-defined behaviours, designed to be available for a wide variety of applications where logically-related messages bounce back and forth in a conversation, and then puts it to use as the cornerstone of another set of behaviours for one specific application, for seemingly very similar purposes. It's like adultery: it may be legal, but it feels wrong.

If we are going to change the spec (e.g. to remove the use of message id) then we should go the whole hog, and create a new extension property, as Marc Hadley suggested we could do:

"I'd also note that if WS-TX needs an EPR but [reply endpoint] doesn't quite fit the bill then its entirely OK to define a new EPR typed property that does."

Clean break proposal: stop using reply-to, message ids, fault rules altogether

This takes off from Max's point that faults can be viewed just as "yet another notification message".

1. Define an extension property called [alternative endpoint] (or any better name you can dream up) which MAY be used to route a response, which is only present on non-terminal notification messages. Or put an element with this semantic up in the body of the message if you don't want to make this a WS-A level artefact. This replaces the use of [reply endpoint].

2. Make it clear that faults and terminal messages do not use this extension property.

3. State that message ids should be ignored if present (don't ban them, but don't require them). Or ban them.


In either approach (least change or clean break) WS-A implementations will simply pass the message to the receiving application (WS-TX endpoint), which will apply the special rules defined by WS-TX for coordination protocol terminal, non-terminal and fault response messages.

Finally, there is an open question in my mind as to whether we should be requiring the [reply endpoint] to have a "none" URI rather than omitting the [reply endpoint], which leads to defaulting by the receiver to an inferred "anonymous" URI value. This would be relevant for terminal messages in the "least change" case, and for all notification messages in the "clean break" proposal.

Alastair


The rules in the three versions (2004, 2005, 2006):

2004-08 (Submission)

http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/

3. Message Information Headers

This section defines the model and syntax of a message information header.

The message information headers collectively augment a message with the following abstract properties. These properties enable the identification and location of the endpoints involved in an interaction. The basic interaction pattern from which all others are composed is "one way". In this pattern a source sends a message to a destination without any further definition of the interaction.

"Request Reply" is a common interaction pattern that consists of an initial message sent by a source endpoint (the request) and a subsequent message sent from the destination of the request back to the source (the reply). A reply can be either an application message, a fault, or any other message.

The properties below support one way, request reply, and any other interaction pattern: [My emphasis, AG]

[...]

[reply endpoint] : endpoint reference (0..1)

An endpoint reference that identifies the intended receiver for replies to this message. If a reply is expected, a message MUST contain a [reply endpoint]. The sender MUST use the contents of the [reply endpoint] to formulate the reply message as defined in Section 3.2. If the [reply endpoint] is absent, the contents of the [source endpoint] may be used to formulate a message to the source. This property MAY be absent if the message has no meaningful reply. If this property is present, the [message id] property is REQUIRED. [My emphasis, AG]

[fault endpoint] : endpoint reference (0..1)

An endpoint reference that identifies the intended receiver for faults related to this message. When formulating a fault message as defined in Section 3.2 and 4, the sender MUST use the contents of the [fault endpoint] of the message being replied to to formulate the fault message. If the [fault endpoint] is absent, the sender MAY use the contents of the [reply endpoint] to formulate the fault message. If both the [fault endpoint] and [reply endpoint] are absent, the sender MAY use the contents of the [source endpoint] to formulate the fault message. This property may be absent if the sender cannot receive fault messages (e.g., is a one-way application message). If this property is present, the [message id] property is REQUIRED. [My emphasis, AG]

[...]

3.2 Formulating a Reply Message

The reply to a WS-Addressing compliant request message MUST be compliant to WS-Addressing and be constructed according to the rules defined in this section.

The following example illustrates a request message using message information header blocks in a SOAP 1.2 message:

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
  xmlns:f123="http://www.fabrikam123.example/svc53">
  <S:Header> 
  <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff
    </wsa:MessageID>
    <wsa:ReplyTo> 
    <wsa:Address>http://business456.example/client1</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To S:mustUnderstand="1">mailto:joe@fabrikam123.example</wsa:To>
    <wsa:Action>http://fabrikam123.example/mail/Delete</wsa:Action>
  </S:Header>
  <S:Body>
    <f123:Delete>     
       <maxCount>42</maxCount>
    </f123:Delete>
  </S:Body>
</S:Envelope>

This message would have the following property values:

[destination] The URI mailto:joe@fabrikam123.example

[reply endpoint] The endpoint with [address] http://business456.example/client1

[action] http://fabrikam123.example/mail/Delete

[message id] uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff

The following example illustrates a reply message using message information header blocks in a SOAP 1.2 message:

<S:Envelope
  xmlns:S="http://www.w3.org/2003/05/soap-envelope" 
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
  xmlns:f123="http://www.fabrikam123.example/svc53">
  <S:Header>
    <wsa:MessageID>
      uuid:aaaabbbb-cccc-dddd-eeee-wwwwwwwwwww
    </wsa:MessageID>
    <wsa:RelatesTo>
      uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff
    </wsa:RelatesTo>
    <wsa:To S:mustUnderstand="1">
      http://business456.example/client1
    </wsa:To>
    <wsa:Action>http://fabrikam123.example/mail/DeleteAck</wsa:Action>
  </S:Header>
  <S:Body>
    <f123:DeleteAck/>
  </S:Body>
</S:Envelope>

This message would have the following property values:

[destination] http://business456.example/client1

[action] http://fabrikam123.example/mail/DeleteAck

[message id] uuid:aaaabbbb-cccc-dddd-eeee-wwwwwwwww

[relationship] (wsa:Reply, uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff)

Candidate Recommendation (2005-08)

http://www.w3.org/TR/ws-addr-core/

3.3 Formulating a Reply Message

This section specifies the WS-Addressing-specific rules for creating a reply or fault message related to another message.

1. Select the appropriate EPR:

   • If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property. If none is present, the processor MUST fault.

     Note:

     When using the XML Infoset representation, in the absence of a wsa:ReplyTo element the value of the [reply endpoint] message addressing property defaults to an EPR with an [address] property of "http://www.w3.org/2005/08/addressing/anonymous" - see section 3.2 XML Infoset Representation of Message Addressing Properties.

   • Otherwise, if the reply is a fault message and the related message's [fault endpoint] message addressing property is not empty, select the EPR from that property. If the [fault endpoint] property is empty, select the EPR from the related message's [reply endpoint] message addressing property. Otherwise, if the [reply endpoint] property is empty, the behavior of the recipient of the related message is unconstrained by this specification.

   • In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault.

2. If the selected EPR's [address] property is "http://www.w3.org/2005/08/addressing/none" the reply message is discarded, if not then populate the reply message's message addressing properties:

   • [destination]: this property takes the value of the selected EPR's [address] property.

   • [relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the predefined reply URI "http://www.w3.org/2005/08/addressing/reply" and the related message's identifier is the [message id] property value from the message being replied to; other relationships MAY be expressed in this property

   • [reference parameters]: this property takes the value of the selected EPR's [reference parameters] property

Latest editors' working draft (March 2006)

http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html?rev=1.51&content-type=text/html;%20charset=iso-8859-1#N67432

3.3 Sending a Message to an EPR

This section describes the process of constructing a message in accordance to an EPR.

1. If the EPR's [address] property is "http://www.w3.org/2005/08/addressing/none" the message is discarded, if not then populate the message's message addressing properties:

   • [action]: this property is required, but is not populated from the EPR.

   • [destination]: this property takes the value of the EPR's [address] property.

   • [reference parameters]: this property takes the value of the selected EPR's [reference parameters] property

3.4 Formulating a Reply Message

This section specifies the WS-Addressing-specific rules for creating a reply or fault message related to another message.

1. Select the appropriate EPR:

   • If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property.

     Note:

     The [reply endpoint] message addressing property will always be present when using the XML Infoset representation since, in the absence of a wsa:ReplyTo element, the value of the [reply endpoint] message addressing property defaults to an EPR with an [address] property of "http://www.w3.org/2005/08/addressing/anonymous" - see section 3.2 XML Infoset Representation of Message Addressing Properties.

     If the [reply endpoint] message addressing property is not present the processor MUST fault. This could only occur when using an alternate representation of message addressing properties.

   • Otherwise, if the reply is a fault message and the related message's [fault endpoint] message addressing property is not empty, select the EPR from that property. If the [fault endpoint] property is empty, select the EPR from the related message's [reply endpoint] message addressing property. Otherwise, if the [reply endpoint] property is empty, the behavior of the recipient of the related message is unconstrained by this specification.

   • In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault. [my emphasis: AG]
     

2. Send the message according to the previous section, but also including:

   • [relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the predefined reply URI "http://www.w3.org/2005/08/addressing/reply" and the related message's identifier is the [message id] property value from the message being replied to; other relationships MAY be expressed in this property