[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
Thank you Mark. I understand you have a proposal. We will inevitably
discuss the other proposals too on the call on Thursday. I tried to
enumerate the proposals that have been made so far as there has been a lot
of mail on this issue. I like to think that may have been helpful but I've
been wrong before. I guess we'll soon find out.
Regards,
Ian
Mark Little
<mark.little@jbos
s.com> To
Ian Robinson/UK/IBM@IBMGB
04/04/2006 16: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
So the issue I references has a proposal: let's remove the use of
wsa:ReplyTo and replace it with wsc:ReplyTo and add in associated usage
rules, such as when and where it is expected and what to do if it's
required and isn't present (fault I reckon).
Mark.
Ian Robinson wrote:
>
>
> 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]