OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-rx] NEW ISSUE: anonymous AcksTo

In general, the concern that is being articulated is where a node knows
that an HTTP message carrying a SOAP body is a one-way MEP, and the
introduction of ackTo anonymous effectively converts that MEP into a
two-way MEP.

Other Comments inline

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Monday, July 11, 2005 1:24 PM
> To: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] NEW ISSUE: anonymous AcksTo

> >
> > I think that is not a good idea.  First of all, we are saying that
> > if my application message is one way (or asynchronous), I might
> > receive something back on the http response(the WS-RX ack).  Nothing
> > really precludes this usage, but we are introducing unnecessary
> > dependency between WS-RX (acknowledgement messages) and
> I don't understand your suggestion of a dependency.

It's pretty clear that a WS-A ReplyTo of non-anonymous means that the
reply should go to the ReplyTo value, not the backchannel.  One of the
advantages of WS-A ReplyTo is to enable one-way/fire-and-forget

> > (normal MEP).  For example, if I have an intermediary on the server
> > that takes an incoming message, looks at the reply-to address (or
> > message MEP), and decides to close http connection if it's a oneway
> How can you have an intermediary (it would have to be an HTTP proxy if
> anonymous URI is used for AcksTo) that is compliant with the HTTP
> specification
> if it closes the connection with the client before the HTTP response
> received?

How about it closes the connection after it gets the 2xx?  That's what
you'd expect from a one-way MEP.  Especially if it's the 202 that is
blessed by WS-I BP for one-ways.

> > asynchronous message, everything works fine.  Now, with WS-RX, it
has to
> > know that "hmm, maybe I shouldn't close that connection if WS-RX is
> > involved and synchronous ack is used".
> One would assume that an endpoint that specified the anonymous URI for
> AcksTo EPR would know what it was doing and would in fact be expecting
> that
> the acks would be transferred on the HTTP response messages.

Lei's example is for an intermediary that knows about the MEP but won't
work correctly unless it adds knowledge of WS-RX.  

> >
> > Secondly, the paragraph below quoted from WS-Addressing spec says
> > anonymous IRI shouldn't be used as the destination in any other
> > circumstances other than the destination for reply messages.  I
> > see acknowledgements as reply messages.
> What makes you think that an ack is not in some way considered a

Various protocols have different definitions of "Reply".  The very fact
that WS-A uses "ReplyTo" for "responses" and "FaultTo" for "faults"
shows that WS-A treats responses as Replies and faults as faults.  

I've always been troubled by the looseness of what can be considered a
Reply vs a "Response" and the relationship to MEPs.  The reason the
relationship to MEPs is important is that it may be important for a
request-response binding to know whether a response is allowed,
required, or not allowed.

> >
> > WS-Addressing defines the following well-known IRI for use by
> > that cannot have a stable, resolvable IRI:
> > "http://www.w3.org/2005/03/addressing/role/anonymous";  Requests
> > [reply endpoint], [source endpoint] and/or [fault endpoint] use this
> > address MUST provide some out-of-band mechanism for delivering
> > or faults (e.g. returning the reply on the same transport
> > This mechanism may be a simple request/reply transport protocol
> > HTTP GET or POST). This IRI MAY be used as the [destination] for
> > messages and SHOULD NOT be used as the [destination] in other
> > circumstances.
> >
> > Proposal 1:
> >
> > Specifically call out that the AcksTo EPR should not use the
> > IRI.
> I disagree. In fact, I think that there are compelling use cases where
> the only viable approach to receive acks is on the HTTP response
> >
> > -- One reason to use an anonymous IRI is so that the acknowledgement
> > reach sending endpoints that may be sitting behind a NAT or
> > But we have to deal with the same problem with asynchronous response
> > messages anyway.
> Actually, __we__ don't have to deal with that at all. It is out of
> of this
> TC to deal with such matters. This would be the purview of some other
> such as the WS-Addressing WG or the XMLP WG.
> >
> > Proposal 2:
> >
> > Specifically call out that an anonymous IRI in the AcksTo EPR would
> > indicate acknowledgement message will only be sent back in response
> > ack request messages where the ack request message should be a
> > standalone synchronous invoke.
> Why? How is this different than flowing acks on the HTTP response
> for any other message? Frankly, I don't believe that there is an issue
> here.

This solves the problem, that the MEP isn't transformed from a one-way
into a two-way.

Personally, I think the anonymous IRI is actually inappropriate for this
case.  The WS-Addressing working group is probably (or has?) added
another special name for "not allowed".  Imagine that a ReplyTo has
"not-allowed" value which really clearly says it's a one-way mep, and
then there's an anonymous ackTo.

I'd suggest a friendly mod to Proposal 2 to say call out a "not allowed"
IRI in the AcksTo.  It might also need a bit more to say that
"anonymous" IRI is not allowed when MEP is one-way.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]