[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
So the issue I references has a proposal: let's remove the use of wsa:ReplyTo and replace it with wsc:ReplyTo and add in associated usage rules, such as when and where it is expected and what to do if it's required and isn't present (fault I reckon). Mark. Ian Robinson wrote: > > > I should have included an option (0) which is "close with no change". The > #1 and #2 below are suggested in the URL you reference. I simply observe > there have been other proposals as well. This *is* the issue of using > wsa:ReplyTo. > > Regards, > Ian Robinson > STSM, WebSphere Messaging and Transactions Architect > IBM Hursley Lab, UK > ian_robinson@uk.ibm.com > > > > Mark Little > <mark.little@jbos > s.com> To > Ian Robinson/UK/IBM@IBMGB > 04/04/2006 15:20 cc > Doug Davis <dug@us.ibm.com>, Paul > Cotton <Paul.Cotton@microsoft.com>, > ws-tx@lists.oasis-open.org > Subject > Re: [ws-tx] Issue 30 - One-way > message replies > > > > > > > > > > > IMO I think addressing the issue of using wsa:ReplyTo ( > http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00091.html > ) first, may make anything else (like this) easier to approach and reason > about. > > Mark. > > > > > Ian Robinson wrote: > >> Having gone back round this thread again. I believe there have been 4 >> distinct proposals, These are (in the order in which they were proposed) >> 1. Use a new TX-defined protocol service endpoint. as the endpoint to >> > which > >> protocol messages may be sent if we have forgotten the "registered" >> > partner > >> EPR. This is proposed in the original issue. >> 2. Use wsa:From as a protocol service endpoint to which protocol >> > messages > >> may be sent if we have forgotten the "registered" partner EPR. This is >> proposed as an alternative to #1 above in the original issue. >> 3. Alastair's "Option A" which builds on either #1 or #2 above but adds >> normative constraints for how fault messages should be handled. >> 4. Alastair's "Option B" which proposes targetting all TX protocol >> > messages > >> at any [reply endpoint] and requiring the using or a [relationship] >> property. >> >> #4 is a significant departure from the current drafts and suggests that >> > the > >> "registered" EPR is relegated to be used only for those circumstances >> > where > >> there is no [reply endpoint] - for example on the first non-terminal >> protocol message or following recovery. Moreover, this goes back over >> ground we have discussed before and implies that 2PC protocol messages >> > are > >> "replies". They are not. To restate the example used prevoiusly, >> "wsat:Aborted" is a notification message. It may initiate 2PC from the >> Participant. Or it may follow a wsat:Prepare message. In either case, it >> should be directed at the [endpoint] that was registered during the >> Register/RegisterResponse exchange. >> >> I propose we eliminate #4 and look at the first 3. >> >> Regards, >> Ian Robinson >> >> >> >> >> > > >> Mark Little >> > > >> <mark.little@jbos >> > > >> s.com> >> > To > >> Paul Cotton >> > > >> 04/04/2006 13:36 <Paul.Cotton@microsoft.com> >> > > > cc > >> Doug Davis <dug@us.ibm.com>, >> > > >> ws-tx@lists.oasis-open.org >> > > > 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]