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:
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
