[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] NEW ISSUE: anonymous AcksTo
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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]