Re: [ws-rx] AnonURI and Offer and WS-Addressing

[Paul Fremantle <paul@wso2.com>]

Marc

I recently re-read the latest WSA drafts and I agree with you in your 
reading of the WSA spec.


Paul

Marc Goodner wrote:
>
> I would point out that the definition of anonymous uri is:
>
> “Some endpoints cannot be located with a meaningful IRI; this URI is 
> used to allow such endpoints to send and receive messages. The precise 
> meaning of this URI is defined by the binding of Addressing to a 
> specific protocol and/or the context in which the EPR is used.”
>
> The section you quote below is from section 5.1 Use of Anonymous 
> Address in SOAP Response Endpoints. The SOAP 1.2 binding text you 
> quote does not cover RM, rather it covers a vanilla SOAP 1.2 endpoint 
> only. WS-A leaves us the flexibility to clarify any points on its use 
> when RM is in use.
>
> I’m still surprised to see suggestions to the effect that anon can not 
> be used with RM followed by suggestions that amount to defining our 
> own anon uri (essential anonymous uri redux). I think it makes far 
> more sense to clarify any points on the use of anon when the RM 
> protocol is being used rather than forbid its use as it seems the WS-A 
> WG left us the latitude to do so. So I disagree with your points 1, 2 
> and 5 below.
>
> On point 3 I see that as being different only if you’ve only been 
> looking at this from a point of view of 1 way messages exclusively. If 
> you get an ack for a request you sent without the corresponding 
> response you obviously still have the request available for 
> retransmitting. I don’t see the difficulty. I don’t see how out only 
> applies in this discussion though.
>
> On point 4 you seem to have an async response in mind. In a 
> synchronous req/resp MEP the ack for the request message would be on 
> the response message. The thing we’re discussing is what to do when 
> that response message is lost and the ack is detected in a ack range 
> on a subsequent response message to the client. It helps to think of 
> this without complications. Imagine that the request comes in and the 
> response (with the ack) is lost. The client hasn’t sent any other 
> requests. What does it do? Why it resends the request. The service 
> should be prepared for this as it never got an ack for the response 
> either. Just extend that model and it is easy to see that when the 
> client sees an ack on a response to another message that contains an 
> ack for a request it never got a response from it can resend the 
> request to get the unacknowledged response. What is the problem?
>
> Finally I’d like to point out that this and many other recent posts 
> conflates i090 and i089 together. I don’t understand why so much 
> emphasis is being placed on the use of anonymous with an Offered 
> sequence to simultaneously justify removing Offer and prove that 
> anonymous should be forbidden when using WS-RM because of perceived 
> problems when used with Offer.
>
> Marc Goodner
>
> Technical Diplomat
>
> Microsoft Corporation
>
> Tel: (425) 703-1903
>
> Blog: http://spaces.msn.com/mrgoodner/
>
> ------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Monday, March 13, 2006 6:03 AM
> *To:* ws-rx@lists.oasis-open.org
> *Subject:* Re: [ws-rx] AnonURI and Offer and WS-Addressing
>
>
> Paul,
> please see: 
> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#anonaddress 
>
> which is the latest editor's copy of WSA, and in particular:
> When "http://www.w3.org/2005/08/addressing/anonymous"; is specified for 
> the response endpoint and the message is the 
> http://www.w3.org/2003/05/soap/mep/InboundMessage property of a SOAP 
> request-response MEP [/SOAP 1.2 Part 2: Adjuncts/ 
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2>], 
> then any response MUST be the 
> http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the 
> same instance of the SOAP request-response MEP [/SOAP 1.2 Part 2: 
> Adjuncts/ 
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2>]. 
>
>
> They've added quite a bit of clarifying text since the submitted 
> version. I think the "same instance" part makes it clear that the 
> response MUST flow over the same http connection as the request.
>
> Perhaps it would help if we summarized the list of options:
>
> 1 - prohibit anon replyTo if the response is expected to be sent using RM
> 2 - prohibit the use of RM when the wsa:To is anonymous - or said 
> another way, when replyTo is anon the response is not sent using RM
> 3 - resend request until response is delivered/acked even if the 
> request is acked
> 4 - don't ack a request until the response is sent
> 5 - define a new URI that allows a polling flow like Paul described in 
> his previous note
>
> Here are some comments on each:
> 1 and 2 might actually be the same thing but my intention was to say 
> that in '1' you can't use anon replyTo if the response is sent 
> reliably - so perhaps a Fault is generated. In '2', if the replyTo is 
> anon then no matter what the wsdl/policy... says, RM needs to be 
> turned off for the response - it can still be sent but just not as 
> part of an RM sequence. Slightly different.
> '3' is a change to what I believe is most people current view of the 
> RM processing model because we'll resend ACKed messages. It also will 
> only work for one-req/one-res MEPs. Out-only, or 
> single-req/multiple-res may have issues.
> '4' is a change to the RM processing model because the RMD will not 
> ACK a message even if it is received. Depending on how you view things 
> this could mean that the RMD needs to lie about what it has and could 
> cause messages to be resent because the RMD is waiting for a response 
> before it will ACK the request. Now, since the RMD gets to choose when 
> it ACKs (meaning is it simply 'I got it' or something else it up to 
> it), so to some this may not be lying but just a change to the ACK 
> model of that RMD.
> '5' doesn't require a change to the RM processing model but heads in 
> the direction of ws-polling and can work w/o a change to the RM 
> processing model and can work for all MEPs. Even if we did pick this 
> option we'd still need to say something in the RM spec about what 
> should happen when anon replyTo is used (I'm guessing 1 or 2).
>
> Are there any other options people think we need to add to the list? 
> Having all of the known choices in front of us might help focus the 
> discussions.
>
> thanks,
> -Doug
>
>
>
> *Paul Fremantle <paul@wso2.com>*
>
> 03/12/2006 04:43 AM
>
> 	
>
> To
>
> 	
>
> Bob Freund-Hitachi <bob.freund@hitachisoftware.com>
>
> cc
>
> 	
>
> Doug Davis/Raleigh/IBM@IBMUS, wsrx <ws-rx@lists.oasis-open.org>
>
> Subject
>
> 	
>
> [ws-rx] AnonURI and Offer and WS-Addressing
>
> 	
>
>
>
>
> Bob et al.
>
> I've attached a document that outlines the flow and shows message 
> exchanges for a given interaction. The key question is whether the 
> interaction:
>
> RMD.AckRequested_EmptyBody -> EchoResponse_World_ackSeq_1_2_3
>
> breaks the WS-Addressing spec.
>
> Paul
>
> Bob Freund-Hitachi wrote:
> Just another log for the fire…
> In reading HTTP 1.1, I do not see anything that specifies that the 
> response entity cannot be interpreted prior to its completion. In 
> principle, it seems to me that both ack and response could be sent on 
> the same connection backchannel provided that it was not closed 
> prematurely. Is this how the implementations that work do it?
> Thanks
> -bob
>
> ------------------------------------------------------------------------
>
>
> *From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Friday, March 10, 2006 1:36 AM*
> To:* Paul Fremantle*
> Cc:* wsrx*
> Subject:* Re: [ws-rx] An alternative approach to make anon reply-to 
> and sync rm work
>
>
> Paul,
>
> I think there are some problems with this - I still think this 
> violates WSA. There's a reason anon replyTo means, in essence, the 
> http response flow of the request message. The connection becomes the 
> correlator between the request and the response - meaning if several 
> anon requests come in the only way the server knows which client gets 
> which response is thru the http connection. In your scenario if there 
> are two anon requests sent to the server using the same sequence and 
> no responses sent, when the third connection is made (to carry the 
> ackReq) how does the server know which client is initiating the 
> request. It can not simply assume that just because they shared the 
> same sequence that they also share WSA state and that any response can 
> be sent to any client. The correlation is now lost.
>
> thanks,
> -Doug
>
> *Paul Fremantle **<paul@wso2.com>* <mailto:paul@wso2.com>
>
> 03/09/2006 06:53 PM
>
> 	
>
> To
>
> 	
>
> wsrx <ws-rx@lists.oasis-open.org> <mailto:ws-rx@lists.oasis-open.org>
>
> cc
>
> 	
>
> Subject
>
> 	
>
> [ws-rx] An alternative approach to make anon reply-to and sync rm work
>
>
> 	
>
>
>
>
>
> The biggest issue with the two way reliable HTTP + anonURI case is the
> requirement to replay request messages to get responses.
>
> Why is this a problem? Because it means that the client has to store
> requests (if and only if the interaction is two-way) beyond getting an 
> ack
> for that request.
>
> This means that the RMS has to "know" if this particular message
> interaction is one-way or two way. This means that for example, a dumb
> gateway can't do it without looking at WSDLs etc.
>
> Why do we need to do this: because WSA states:
>
> "For instance, the SOAP 1.2
> HTTP binding puts the reply message in the HTTP response."
>
> So I agree we should not put an application reply to message A in an
> HTTP response to application message B.
>
> However, if we added the following text to our spec:
>
> "In the case where an offered sequence is used, the RMS may send an
> <wsrm:AckRequested> header together with an empty SOAP body. A valid
> response to this message MAY either contain an empty SOAP body, or MAY
> contain a message for the *offered* sequence".
>
> The result of this would be that the response message on the HTTP reply
> would be a valid reply to the request message and therefore would not 
> break the
> WS-Addressing text above. Effectively WSRM would be defining what
> the SOAP request/reply would be, and therefore "making it right"
> with respect to the HTTP binding.
>
> So, when things are going well the HTTP reply to any given request 
> message would be the
> correct response message. But in the case that this message got lost or
> delayed, the RMS would have a choice. If it still had the message, and it
> "knew" that the MEP was two-way, it could choose to resend the
> original request OR it could send an empty body with an ackRequested
> header.
>
> This also gives the offered sequence a message onto which to
> piggyback Close and TerminateSequence requests, solving another problem.
>
> More importantly it removes the need for
> the RMS to "know" the MEP, because by the repeated application of 
> empty-body ackRequests,
> the RMS can get the offered sequence into a decent state.
>
> The only compulsory implementation change I see is that the RMD would
> have to be coded to know what this empty body + ackrequest means.
>
> From the RMS I see this as optional. It is completely up to the RMS
> whether it initiates a CS with Offer+AnonURI. So if an implementation 
> doesn't support this,
> it will never initiate such a channel. And if the RMS does initiate such
> a channel, it will "know" it is in this mode, that it needs to send
> occasional empty ackrequests until it can close down the offered sequence.
>
> In addition we would have to remove the words that say Offer is simply 
> an optimization,
> because this usage makes a specific correlation between a sequence and 
> offered sequence.
>
> Paul
>
> -- 
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> _
> _http://feeds.feedburner.com/bloglines/pzf_
> _paul@wso2.com <mailto:paul@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com 
> <http://www.wso2.com/>
>
>
> -- 
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://feeds.feedburner.com/bloglines/pzf
> paul@wso2.com <mailto:paul@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com 
> <http://www.wso2.com/>_[attachment "AnonURI+Offer.doc" deleted by Doug 
> Davis/Raleigh/IBM] _
>

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com