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

[Doug Davis <dug@us.ibm.com>]

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>

03/21/2006 06:46 AM

To	Mark Little <mark.little@jboss.com>
cc	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" - see section 3.2 XML Infoset Representation of Message Addressing Properties.

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
*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)

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>

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.