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