Re: [ws-tx] Issue 30 - One-way message replies

[Mark Little <mark.little@jboss.com>]

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.
>>>
>>>