[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]