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

["Lei Jin" <ljin@bea.com>]

Comments inline.

> Lei,
> 
> Per WS-Addr, except in the case of WSDL req-res MEP when used
> with the 
> HTTP-binding, anonymous reply-to means that there is some out-of-band 
> mechanism to deliver the message. In case of WSDL req-res and 
> HTTP-binding, anon reply-to means the http-response message.
> 
> In you example, it is a one-way MEP, so the anon URI does not
> mean that 
> it is the HTTP-response message back-channel. In fact for one-way MEP 
> over HTTP, at least when using SOAP 1.1 with WS-I Basic 
> Profile 1.x (and 
> there isn't a standard SOAP 1.2 one-way MEP, yet) the service 
> must not 
> send a SOAP response as the HTTP entity-body in the HTTP response 
> message. Therefore, for the one-way MEP case, with or without 
> intermediaries, the anon ackTo implies that there is some out-of-band 
> mechanism established for the acks or the acks are sent in 
> response to 
> the request-for-ack synchronous (req-res MEP message). So why 
> would the 
> intermediaries have to keep the connection open? Furthermore, it is 
> difficult to talk about intermediaries (at least in my mind) when 
> talking about the WSDL description (and the MEPs described 
> therein) as 
> WSDL does not deal with intermediaries at all. The 
> description is from 
> the point of view of the service.
> 
> But I think it is certainly worthwhile to discuss what 'out-of-band'
> means, if anything, for anon acksTo in the case of one-way 
> MEP and HTTP 
> binding (and other bindings). This could very well result in 
> an interop 
> problem.

Agreed.  If you look at my original mail for raising the issue, I 
mentioned that there is an implicit assumption that "sending back 
on http response channel" is this out-of-band mechanism for 
communicating acks.  That is what I am objecting.

 
> I hope I got the scenario right. If not, apologies.
> 
> BTW, I did not understand what you meant by:
> "... Thus, the introduction of an anonymous AcksTo is now a
> backwards-incompatible change. ..."
> Can you pl. elaborate? Backwards-incompatible change to what?
> 

Perhaps backwards-incompatible is not the right word here.  What I'm 
referring to is that the introduction of anonymous AcksTo makes WS-RX
unable to work with intermediaries that are pre WS-RX (thus not
backwards compatible)

Lei

> Thx!
> 
> -Anish
> --
> 
> Lei Jin wrote:
> > Doug:
> >  
> >>  w.r.t. your intermediary examining the wsa:ReplyTo - be a bit 
> >> careful
> > here.
> >>  The presence of a wsa:ReplyTo does not imply anything 
> about the MEP
> > (sadly :-(.
> >> There are cases where a wsa:ReplyTo could be present even for a 
> >> one-way
> >>  message.  And the presence of an anonymous wsa:ReplyTo 
> does not guarantee 
> >> that anything will flow back on the http response flow.   
> > 
> > Let me try to clarify myself.  What's important here is not 
> the fact I
> > examine wsa:ReplyTo to figure out what MEP this is.  Let's 
> say there is 
> > an intermediary that is aware that the MEP is one way 
> (perhaps through 
> > the WSDL, etc).  And this intermediary is not WS-RX aware.  So it 
> > decides to send back a 202 and close the http connection before 
> > forwarding on the message.  This will cause the WS-RX 
> protocol to fail 
> > since no synchronous ack can be sent back.  Thus, the 
> introduction of an 
> > anonymous AcksTo is now a backwards-incompatible change.  
> In order for 
> > things to work, all intermediaries will need to be WS-RX 
> aware and keep 
> > connections open in case synchronous acks need to be sent back.
> >  
> > Lei
>