Re: [ws-tx] Issue 29 - wsa:MessageID should be explicitly requiredfor WS-AT non-terminal notification message

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

I'm still puzzling over this request-reply business. Probably misunderstanding something, but some further thoughts. This is further to my posting to the WS-Addressing list, which I copied to this list.

I checked the latest editors' working draft of WS-A

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

which has a new section 3.3, and then 3.4 (old 3.3) which has been altered for clarity.

These are excerpted below:

'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.'

When I read these two sections in conjunction, I come to the conclusion that

a) you can say "I don't want a reply" (i.e. "I am operating purely one-way") by setting the wsa:ReplyTo EPR [address] property to  "http://www.w3.org/2005/08/addressing/none", and that will cause any attempt to send a reply to cause a message discard.

b) if you omit the wsa:ReplyTo then the [reply endpoint] [address] property value will be understood to be "anonymous".

but if we look at WS-AT Section 9 it says:

WS-AT, original working draft: ll. 454-456:

'All messages are delivered using connections initiated by the sender. Endpoint References MUST contain physical addresses and MUST NOT use well-known "anonymous" endpoint defined in WS Addressing.'

So, then I think: well, I need to make sure that ReplyTo: is set, so that we won't default to anonymous. Which means, that it is not possible to indicate non-terminal by absence of ReplyTo, because WS-A wants me to set ReplyTo [address] property to "none" which seems to effectively mean "no reply".

By setting ReplyTo to "none" it seems I can escape the need to supply message ids etc, because no reply is sent.

So, it seems that there is a potential issue with terminal messages on top of the original issue of use of wsa:ReplyTo without message ids. It appears that the non-terminals may need a reply-to value of none, not a null reply-to.

Alastair

Alastair Green wrote:

I'm not convinced 2005-08 CR removes this requirement if the message sent back to the original sender is considered to be a "reply", as Mark Little pointed out in an earlier post.

In my mind, this hinges on one central question: does the presence of wsa:ReplyTo define the message as a request, to which replies must be formulated in the manner described in WS-Addressing 3.3 "Formulating a reply message"?

If the answer is yes then we either do all of the following:

1) add message ids to all the messages

2) replies must cite the message ids as their RelatesTo value.

3) the replier MUST use the ReplyTo value to address the reply

Or, we stop using wsa:ReplyTo and use a WS-TX-defined element to convey the semantic intended.

Alastair


Ram Jeyaraman wrote:

 

This is identified as WS-TX issue 29.

 

Please ensure follow-ups have a subject line starting "Issue 29 -" (after any Re:, [ws-tx] etc.)

 

===================================

 

Issue name: wsa:MessageID should be explicitly required for WS-AT non-terminal notification message

 

Issue type: spec

 

Owner: Joseph Fialli (Joseph.Fialli@Sun.COM)

 

Reference documents:

 

WS-AT specification:

http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/wstx-wsat-1.1-spec-wd-03.pdf

 

PDF Line numbers: 475-477, 481-482

 

Description:

 

Summary:

Under Section 9 "Use of WS-Addressing Headers", non-terminal

notification messages MUST have

a wsa:ReplyTo but is silent on wsa:MessageID. 2004 WS-Addressing

specification requires wsa:MessageID when wsa:ReplyTo exists.

 

Resolution:

Add bullet "MUST include a wsa:ReplyTo header" to Non-terminal

notification messages. (line 481-482)

 

Details:

Request messages MUST have wsa:MessageID and wsa:ReplyTo (line 475-477).

Non-terminal notification message MUST have wsa:ReplyTo (line 481-482).

The absence of MUST have wsa:MessageID implies it is optional for

non-terminal notification message.

 

Supporting data that non-terminal message MUST have a wsa:MessageID

 

1. 2004 WS-Addressing

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

states that if wsa:ReplyTo exists then wsa:MessageID MUST exist.

 

Extracted from Section 3: Message Information Headers

> 

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

>     <deleted> If this property is present, the [message id] property

>     is REQUIRED

> 

Note that the W3C WS-Addressing spec no longer states the above constraint.

Proposed resolution could be reconsidered when updating to that

specification.

 

2.  The WS-Atomic Transaction interop document does reflect,

non-normatively, that the intent is element wsa:MessageID is mandatory

on non-terminal notification messages. (Conforming to 2004 WS-Addressing

specification)

 

Non-normative reference:

 

wsa:MessageID is specified Mandatory for following non-terminal

notification messages

in tables in Section 8" Message Snapshots" of WS-Atomic Transaction

Interop Scenarios,

ftp://www6.software.ibm.com/software/developer/library/ws-wsatscenario.doc

 

> WS-AtomicTransaction Messages, Completion Protocol

> Message Completion::Commit

> Message Completion::Rollback

> 

> WS-AtomicTransaction Messages, 2PC Protocols

> Messages for Volatile and Durable 2PC protocols are identical, this

> paragraph contains Durable2PC messages.

> Message Durable2PC::Prepare

> Message Durable2PC::Replay

> Message Durable2PC::Commit

> Message Durable2PC::Rollback