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