[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 29 - wsa:MessageID should be explicitly requiredfor WS-AT non-terminal notification message
It would appear that there is scope for confusion around the definition of reply. Is it: (i) a reply is any message sent in response to a previous message (aka a request message). This could imply a request-response MEP. The definition of a reply here can be thought of more like a traditional RPC reply. or (ii) a reply is a message that is directed to a receiver in response to one or more messages and which may be related to those messages in some application specific manner. This may be more accurately termed a response message. It does not imply a request-response MEP. The definition of a reply here is effectively set at the "application" level, as in some way it requires semantic information from higher levels to determine when (and where) to send the message. ? Now (ii) can be subdivided in to: (iia) a reply is targeted as a response to one of the series of messages that were received (e.g., "do this, this and this and then get back to me with the response", where the "response" is targeted at the "then get back to me" request). or (iib) a reply is targeted at some endpoint that may or may not have been determined by data in the header or body of one of the input message (e.g., "do this, this and this and then send an application message to Fred"), where "Fred" may not have sent any of the initial messages. Apologies in advance if this cut-and-paste from the spec duplicates other cut-and-pastes that have gone before, but I think for clarity it is necessary to include this text again. So firstly, in section 3 of the current Candidate recommendation of WS-A, we have: "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-response" 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 response). A response in this case can be either an application message, a fault, or any other message. Note, however, that reply messages may be sent as part of other message exchanges as well, and are not restricted to the usual single Request, single Response pattern, or to a particular WSDL transmission primitive or MEP. The contract between the interacting parties may specify that multiple or even a variable number of replies be delivered." so it is clear to me from this (and discussions that have gone on during the lifetime of the WS-A working group), that we're not talking about a reply definition that limits us to (i), but encompasses both (i) and (iia) patterns. It doesn't (and shouldn't) say anything about (iib) in my opinion, because that's only something that can be dealt with at a higher level. Furthermore, in Section 3.3 in the spec (Formulating a Reply Message), it is also clear that any reply at the level of WS-A MUST be targeted at a previous incoming message: "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." where [reply endpoint] is wsa:ReplyTo. (Ignoring the anonymous default for wsa:ReplyTo for the sake of this discussion). So this again narrows down the definition of reply to type (i) and (iia). Plus: "In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault." Where does this leave us? It seems to me that if any of the messages in WS-C/WS-AT/WS-BA fall into either of these categories then we have no choice but to follow the rules set down within the WS-A specification. If we believe that our response messages are somehow in the (iib) category, then we have more leeway for defining what constitutes a reply and how that reply should look (e.g., with or without wsa:MessageID). Mark. Alastair Green wrote: > 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* > <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-core.html?rev=1.51&content-type=text/html;%20charset=iso-8859-1#msgaddrpropsinfoset>.' > > 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 >>> >>> >>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]