>
> 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:
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
>
> Anish Karmarkar <> 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
>
>
