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