[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] NEW ISSUE: anonymous AcksTo
I am not sure it is a dependency on WS-Addressing but rather an explicit admission by that specification that should the source endpoint use anonymous IRI, it is the responsibility of the transport binding or the specification that defines that transport binding to provide a channel for acks. In case of HTTP, it happens to be the reply to an HTTP Get/Put, but it could be different for other transport say SMTP. Regardless that clarification could be made explicit in WS-Rx, I think. Vikas -----Original Message----- From: Lei Jin [mailto:ljin@bea.com] Sent: Monday, July 11, 2005 12:19 PM To: ws-rx@lists.oasis-open.org Subject: [ws-rx] NEW ISSUE: anonymous AcksTo I have the impression after talking to a few people that there is the implicit assumption (though not specifically called out) in the spec that if the AcksTo EPR is set to use the anonymous IRI, then all subsequent acknowledgements for that reliable sequence will be sent back synchronously on the http response path of either the application message or an ack request message. 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 (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 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". 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. 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. -- 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. 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. Flames? Lei
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]