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

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

> 
> Frankly, I think that the BP1.x is broken in regards to the 
> oneway MEP not 
> permitting a SOAP
> envelope in the HTTP response message. I argued at the time 
> that it would 
> be problematic
> for certain advanced WS-* specs, and now the chickens have 
> come home to 
> roost.
> 
> As for the intermediary case, if a request is made and no 
> HTTP response 
> message is received,
> it is as if the request never happened because there is no 
> way that the 
> client can know whether
> the request message ever made it to the server. While it is 
> true that an 
> intermediary can close
> a connection at any time, it is not a good idea to do so because the 
> client will think that the
> request failed as far as HTTP is concerned.

Chris, we are talking about the intermediary sending back a http 202
response and then close the connection.  Client does know the message
has arrived at the server.

Lei

> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 
> 07/13/2005 02:12:26 
> AM:
> 
> > 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.
> > 
> > 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?
> > 
> > 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
> 
>