ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-tx] Issue 30 - One-way message replies
- From: Doug Davis <dug@us.ibm.com>
- To: ws-tx@lists.oasis-open.org
- Date: Tue, 4 Apr 2006 09:33:06 -0600
+1
-Doug
Mark Little <mark.little@jboss.com>
04/04/2006 11:20 AM
|
To
| Ian Robinson <ian_robinson@uk.ibm.com>
|
cc
| Doug Davis/Raleigh/IBM@IBMUS,
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]