[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] NEW ISSUE: anonymous AcksTo
Christopher B Ferris wrote: >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. > > This is sort of irrelevant. The fact is that the basic profile exists and I would have a hard time not taking it into account. >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. > > > Also, I don't think this was the scenario. >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]