[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
Isn't this related to http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00091.html ? And in which case, there's already a proposal on the table: define our own endpoint type instead of wsa:ReplyTo and use that in this situation. That's pretty much what we agreed at the f2f meeting (hence the issue). Mark. Doug Davis wrote: > > Alastair, > Why not an option "C" - just define a new EPR (like 'i' from option > "A") and just let the normal WS-Addr rules apply for everything else. > That's very close to option "B", which , as you say, lines up with > WS-Addr but doesn't overload wsa:ReplyTo - Tx defines its own EPR. I > really don't think Tx needs to do anything other than define a new > EPR. If Tx believes that the WS-Addr headers need to be contrained > for, what appears to me to be, normal message flows then something is > really wrong with WS-Addr because then all specs will need to do the > same thing. But I don't think that's the case. > thanks, > -Doug > > > > *Alastair Green <alastair.green@choreology.com>* > > 04/03/2006 03:26 PM > > > To > Alastair Green <alastair.green@choreology.com> > cc > Bob Freund-Hitachi <bob.freund@hitachisoftware.com>, Doug > Davis/Raleigh/IBM@IBMUS, Mark Little <mark.little@jboss.com>, > ws-tx@lists.oasis-open.org > Subject > Re: [ws-tx] Issue 30 - One-way message replies > > > > > > > > > > In preparation for Thursday's meeting, I wanted to formulate a > concrete change proposal along the lines of my last message (quoted > below), but on checking it over, I believe I am mistaken on one key > point. I say below: > > '[reply endpoint] cannot be set to "none" (that will blitz all > responses)' > > I think that is wrong. If the [reply endpoint] is set to "none", it is > still possible to have a [fault endpoint]. If the only kind of "reply" > in the full WS-Addressing sense is a fault, then faults will not be > thrown away, they will be sent using to the fault endpoint using > [relationship] (message id etc). > > This would enable the use of a special [ws-tx conversation endpoint] > instead of [reply endpoint], the difference being that use of the > [ws-tx conversation endpoint] doesn't imply use of [relationship]. > > However, given the necessary presence of [fault endpoint] and [message > id] for fault processing it does beg the question: "why not use the > WS-Addressing reply-processing model?" In other words, always specify > [reply endpoint] and [message id] on /all/ messages, and then use that > EPR for normal replies, amnesia cases, faults. > > To facilitate a clear discussion, I'd like to suggest two alternative > resolutions of Issue 30: > * > Option A.* > > Retain status quo, with following qualifications/clarifications: > > i) use extension property [ws-tx conversation endpoint] (or [source > endpoint]) instead of [reply endpoint] on non-terminal notification > messages. > ii) Set [reply endpoint] on all notification messages to "none" to > avoid dragging in "anon" default. > iii) Make clear that [fault endpoint] and [message id] must always be > present (for terminal and non-terminal messages), and that WS-A > predefined faults and WS-TX faults are sent, using [relationship] to > the [fault endpoint] supplied on the message being responded to. > iv) Retain MAY rule with respect to use of [ws-tx conversation > endpoint] (or [source endpoint]). > * > Option B.* > > i) Specify a non-none ("physical address") value for [reply endpoint] > for all messages, along with [message id]. > ii) omit [fault endpoint] > ii) Send responses, if any (whether normal "conversational", WS-A > predefined faults, WS-TX faults), to that EPR using [relationship], > following MUST rule of WS-Addressing reply processing model. > > Option B has the advantage that it lines up WS-AT/BA messages with > WS-C messages (one size fits all). It also leverages WS-Addressing in > a straightforward way. > > Neither proposal is a "no-change" from the status quo. > > Alastair > > Alastair Green wrote: > Bob, > > That's a useful summary. > > It seems that the impact for WS-TX (which explicitly eschews use of > anonymous endpoints) is therefore: > > 1. Abolish the distinction between "request-response" and "one-way". > None of our messages are best-attempt throwaways, and we would want to > communicate predefined WS-A faults. > > 2. If we are going to have the apparatus in place for sending fault > replies to a non-anon EPR then we might as well use that for WS-TX > level faults (i.e. preserve that part of the status quo). > > 3. We might as well use the [reply endpoint] for all messages, so that > ordinary and fault responses always have somewhere to go. > > 4. Therefore, we are indeed using the WS-A "reply processing model", > for all messages. > > Background clarification/reasoning for the above: > > A. You didn't comment on the defaulting of the [reply endpoint] to > anonymous. Am I right that it will /always/ default to "anonymous" if > not specified, when using the XML infoset? > > B. If answer to A. is yes, then my summary is that WS-A recognizes > three message exchange patterns: > > i) A message which will never be replied to at all ([reply endpoint] = > none), which will not return standard faults (the destination is a > sink or black hole) > > ii) Messages which will receive some kind of response, at minimum > standard predefined faults, which specify (explicitly or by default) > that [reply endpoint] = anonymous, and which can therefore omit > message id. Delivery of the response is at some level synchronized: it > holds a transport request-reply exchange open while a response is > formulated. > > iii) Messages which will receive some kind of response, at minimum > standard predefined faults, which specify either [reply endpoint] = > "real address", or [fault endpoint] = "real address", and which have > message ids. The underlying transport exchange concludes asap on > receipt (just an ack); the response (ordinary or fault) uses a new > transport-level exchange. > > B. iii) is a difficult beast, unless you use [reply endpoint]. I say > that because [reply endpoint] cannot be set to "none" (that will blitz > all responses); if it is not set to a "real address" then it defaults > to "anonymous". If that is not what is required, then it must be set > to a "real address". Ergo, B.iii) messages are extremely unlikely to > exist unless [reply endpoint] is set. Which is the premise of my > proposed actions for WS-TX in items 1 to 4 at the start of this mail. > > Alastair > > Bob Freund-Hitachi wrote: > It is assumed that even a “one way” message when there is the > potential of faults (nearly always I think), is in reality a > request-response message with a potentially null response. > The purpose of faultTo is to provide an address other than replyTo > should the implementer decide that faults should go to a different place. > > Specialized (non general use cases) exist where responses are ALWAYS > expected to be on a back-channel, thus the defaulting mechanism that > is specified in WS-A and a somewhat grudging optional on messageid > since in this case correlation may be preformed implicitly. > In general, when messages may be sent and received asynchronously with > respect to the lifetime of an underlying protocol specific > backchannel, ReplyTo will be explicitly set to the desired value. > In order to support either deployment scenario, then it is required to > specify both replyTo as well as messageid in the sent messages so that > returned replies, even if they are only fault messages, may be > correlated through relatesTo. > > I don’t think that I have seen any one-way messages in the wild other > than possibly of non-reliable logging-type messages where there is no > particular concern about its receipt or faults it may produce > Cheers > -bob > > > > ------------------------------------------------------------------------ > > *From:* Alastair Green [_mailto:alastair.green@choreology.com_] * > Sent:* Tuesday, March 21, 2006 7:59 AM* > To:* Doug Davis* > Cc:* Mark Little; _ws-tx@lists.oasis-open.org_ > <mailto:ws-tx@lists.oasis-open.org>* > Subject:* Re: [ws-tx] Issue 30 - One-way message replies > > Mark, Doug: > > I don't think that the section I quoted, tho' it appears in 3.4, is > limited to the "reply processing model". It references section 3.2: > /wsa:ReplyTo > > This OPTIONAL element (of type wsa:EndpointReferenceType) provides the > value for the [reply endpoint] property. If this element is NOT > present then the value of the [address] property of the [reply > endpoint] EPR is _"http://www.w3.org/2005/08/addressing/anonymous"_ > <http://www.w3.org/2005/08/addressing/anonymous>. > This seems to me to unambiguously enforce a default of anonymous when > using the XML infoset. > > Section 3.4 simply reminds the reader that this rule exists and will > apply (also) in the reply processing model (which I agree and > understand we may not want to use -- that's why I raised this whole > discussion in the first place). > > As for the question of where a fault goes to -- you raise an > interesting dimension, Doug. :As I understand it there are two kinds > of fault we could be talking about here: > > 1) An application-defined fault which the application contract > determines should go to the fault-to EPR of a prior and related > inbound message > 2) A standard WS-Addressing fault, predefined in the WS-A SOAP binding > spec > > Properties are provided by WS-Addressing to assist in delivering fault > type 1). If you choose not to use them, then that's fine. The > direction we seem to be heading in here is to define a WS-TX "fault" > as "yet another WS-TX coordination protocol message with WS-TX-defined > semantics, that happens to be generated when an inbound message causes > a state machine to take an alternative path (generate a different > message than it would when pursuing the normal, happy path)". > > However, the standard WS-Addressing faults do need to use the > apparatus defined in WS-Addressing. > > Section 6 ("Faults") of the WS-A SOAP binding spec > (_http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html_ > <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html>) > reads, in part: > 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_/ > <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html#WSADDR-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 > So, to allow correct WS-Addressing predefined fault processing, all > WS-A applications/implementations must specify message ids and at > least a fault-to EPR. Arguably, if the [reply endpoint] is allowed to > default to anonymous then the absence of a message id would not > prevent the delivery of the fault (no correlation needed). > > However, it does appear that WS-A SOAP binding fault processing > expects use of the whole "reply processing model" apparatus /with > respect to standard faults/. This would militate against omission of > fault-to and reply-to, an omission which I think you view as "normal" > for one-ways. > > Therefore: we can properly avoid use of [reply endpoint], but it is > far from clear that we can escape [fault endpoint] so easily. > > And, if we have to drag [fault endpoint], [message id] and > [relationship] back in for this purpose, then it would appear that the > difference between one-way and the full-scale "reply processing model" > is more apparent than real. Are we coming full circle? > > If we default reply-to to anonymous (by omission), and live with the > fact that faults must now travel on the anonymous back-channel, then I > guess you could just about get away with ignoring the reply processing > model. But that requires some heroic assumptions. > > The statement: > > "Fault messages are correlated as replies using the [relationship] > property as defined in Web Services Addressing 1.0 - > Core[/_WS-Addressing-Core_/ > <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html#WSADDR-CORE>]." > > seems, on the face of it, to be normative. The qualifications in the > following sentences about "impacting" the ability to deliver faults > could be seen to weaken the force of that statement, but once again, I > get that queasy feeling that one is in danger of bending and dodging > the design intent of WS-Addressing. > > Alastair > > > Doug Davis wrote: > > I don't think you want to do that because in the absence of a > wsa:FaultTo, setting > wsa:ReplyTo to "none" prevents you from getting back any fault > messages - not > Tx,non-related, faults, but other ones. These are just normal > one-ways which > people normally leave replyTo/faultTo blank - I see no reason to make > them > anything special but including a 'none' replyTo. > -Doug > > *Alastair Green **_<alastair.green@choreology.com>_* > <mailto:alastair.green@choreology.com> > > 03/21/2006 06:46 AM > > > To > Mark Little _<mark.little@jboss.com>_ <mailto:mark.little@jboss.com> > cc > _ws-tx@lists.oasis-open.org_ <mailto:ws-tx@lists.oasis-open.org> > Subject > Re: [ws-tx] Issue 30 - One-way message replies > > > > > > > > > > > > > Mark, > > My point is that the WS-Addressing spec mandates that an absent > reply-to causes the receiver to infer an anonymous response: > > Section 3.4 of the latest draft: > > *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"_ > <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>. > > > My understanding of this note, and of section 3.2, is that this > inference MUST be drawn by a receiver, irrespective of any extension > property like wsc:Response. Hence my proposal that we explicitly set > wsa:ReplyTo to "none". > > Alastair > > > > Mark Little wrote: > The discussion during the f2f concluded that we are indeed using > wsa:ReplyTo in a way that, although probably legal, is not the way it > was meant to be used and can lead to confusion (as we've seen here). > So the first step in the process of removing that confusion, is to > remove wsa:ReplyTo, which was my proposal. What we replace it with, > and what the rules are around it, are the central points of the issue. > > Alastair Green wrote: > Mark, > > Taking off from a comment in the last paragraph of my written > contribution on this area during the F2F > > _http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00088.html_ > > > I think we need to address, in resolving this issue, the question of > the [reply endpoint] value being defaulted to anonymous. > > The issue is about replacing wsa:ReplyTo in the case of "one ways that > may ultimately have a response but aren't really request-response > based messages" (to paraphrase). So in that case, we would be defining > the rules around wsc:ReplyTo (just a name I've picked for this email > so I can easily refer to it as being different to wsa:ReplyTo). As > such, anonymous may not even play in that space. Why would we want an > anonymous default? The current uses of wsa:ReplyTo really all assume > that it was present on the message. I'd prefer a binary approach for > wsc:ReplyTo. > > > An absent [reply endpoint] property in the XML infoset representation > becomes a receiver-inferred value of "anonymous" (actually, the URI > that means anon). > > It seems preferable that we explicitly specify the value of "none" > (again, a URI in truth). > > I would have expected us to be more specific: if there's a wsc:ReplyTo > present, then this is the destination that MAY/SHOULD/MUST be used for > sending a response. The absence means that no response is needed - no > default. > > > This is explicit, intuitively what one would expect for a one-way in > terms of HTTP handling, and avoids any ambiguity/under-specification > if a different representation is used at some future point. > > The current wording banning use of anonymous reply-to addresses would > then be replaced. > > I think we also need to ban use of message ids, and ban use of > fault-to, i.e. make it clear (by omission or by explicit statement) > that none of these aspects of the reply-processing rules and apparatus > are being put to use. ("Ban" in this context could mean "make it clear > that these properties, if present, will be ignored".) > > We had discussed at the f2f that wsa:FaultTo is really meant just for > comms faults and "application faults" would be treated as messages. > I'm not sure if that made it into the minutes. > > > I think use of wsa:From tends to detract from the clarity obtained by > defining an extension property for our special use. > > Mark. > > > Yours, > > Alastair > > > Mark Little wrote: > Line 472 and 480. > > Mark. > > > Ram Jeyaraman wrote: > > Mark, > > > > Could you please provide the PDF line numbers in the referred document > that are relevant to this issue. Thanks. > > > > ------------------------------------------------------------------------ > > *From:* Ram Jeyaraman [_mailto:Ram.Jeyaraman@microsoft.com_] > *Sent:* Friday, March 17, 2006 2:48 PM > *To:* _ws-tx@lists.oasis-open.org_ <mailto:ws-tx@lists.oasis-open.org> > *Subject:* [ws-tx] Issue 30 - One-way message replies > > > > This is identified as WS-TX issue 30. > > > > Please ensure follow-ups have a subject line starting "Issue 30 -" > (after any Re:, [ws-tx] etc.) > > > > =================================== > > > > Issue name: One-way message replies > > > > Issue type: spec > > > > Owner: Mark Little (_mark.little@jboss.com_ > <mailto:mark.little@jboss.com>) > > Reference documents: > > WS-AT specification: _ > __http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf_ > <http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http:/www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf> > _<http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http:/www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf>_ > > > Description: > > Currently we use wsa:ReplyTo for one-way messages in a way which > although legal in terms of the latest CR draft of WS-Addressing, has > led to confusion on a number of occasions. As an example, one use of > wsa:ReplyTo is on Prepare->Prepared, where Prepare has a wsa:ReplyTo > but the Prepared message is a separate (not response) message, because > it could be sent autonomously and not actually in response to Prepare. > The issue is that as far as WS-Addressing is concerned, wsa:ReplyTo > should really only be used in the case of the request-response MEP, > which is clearly not the case here. > > Proposed Resolution: > > The rules for where and when wsa:ReplyTo should be included and used > within WS-AT are well defined, and particularly in respect to the > interoperability scenarios. I propose that we replace wsa:ReplyTo with > something specific to WS-TX (perhaps wsc:ReplyTo, wsc:OnewayTo, or > somesuch). > > Addendum: > > Max suggested at the Raleigh f2f another potential resolution: that we > use wsa:From. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]