[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
Ian, I wasn't saying your post was not helpful. Was just trying to get my head around the original proposal and how it related to the original issue. Mark. Ian Robinson wrote: > > > Thank you Mark. I understand you have a proposal. We will inevitably > discuss the other proposals too on the call on Thursday. I tried to > enumerate the proposals that have been made so far as there has been a lot > of mail on this issue. I like to think that may have been helpful but I've > been wrong before. I guess we'll soon find out. > > Regards, > Ian > > > > > Mark Little > <mark.little@jbos > s.com> To > Ian Robinson/UK/IBM@IBMGB > 04/04/2006 16: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 > > > > > > > > > > > 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]