[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 > <snip/> > > > > > I think that is not a good idea. First of all, we are saying that even > > if my application message is one way (or asynchronous), I might still > > 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 WS-Addressing > > 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 scenarios. > > (normal MEP). For example, if I have an intermediary on the server side > > 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 or > > How can you have an intermediary (it would have to be an HTTP proxy if the > 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 is > 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 the > > 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 the > > anonymous IRI shouldn't be used as the destination in any other > > circumstances other than the destination for reply messages. I don't > > see acknowledgements as reply messages. > > What makes you think that an ack is not in some way considered a reply? > 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 endpoints > > that cannot have a stable, resolvable IRI: > > "http://www.w3.org/2005/03/addressing/role/anonymous" Requests whose > > [reply endpoint], [source endpoint] and/or [fault endpoint] use this > > address MUST provide some out-of-band mechanism for delivering replies > > or faults (e.g. returning the reply on the same transport connection). > > This mechanism may be a simple request/reply transport protocol (e.g., > > HTTP GET or POST). This IRI MAY be used as the [destination] for reply > > 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 anonymous > > 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 message. > > > > > -- One reason to use an anonymous IRI is so that the acknowledgement may > > reach sending endpoints that may be sitting behind a NAT or firewall. > > 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 scope > of this > TC to deal with such matters. This would be the purview of some other WG > 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 to > > 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 message > 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. Cheers, Dave
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]