[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]