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

["Paul Cotton" <Paul.Cotton@microsoft.com>]

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