[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
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]