[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
Ignore this ;-) You're right, there's the possibility of using wsa:From instead. However, I still don't see the reason for a new proposal from Alastair in this space if it is to address the same requirement: the overuse of wsa:ReplyTo by our specifications in cases where it is not appropriate. Let's debate the use of wsa:From or wsc:ReplyTo (remember, the name's just a placeholder) first and foremost. Mark. Mark Little wrote: > Since when? Last I recall on the subject was at the f2f, where we > agreed to raise the issue in the first place. Maybe I'm just getting > too old for this ;-) > > Mark. > > > Paul Cotton wrote: >> Actually if you read the issue it says there are two different proposals >> on the table. >> >> Paul Cotton, Microsoft Canada >> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 >> Tel: (613) 225-5445 Fax: (425) 936-7329 >> mailto:Paul.Cotton@microsoft.com >> >> >> >> >> >> >>> -----Original Message----- >>> From: Mark Little [mailto:mark.little@jboss.com] >>> Sent: April 4, 2006 5:20 AM >>> To: Doug Davis >>> Cc: ws-tx@lists.oasis-open.org >>> 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]