OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ws-rx] NEW ISSUE: anonymous AcksTo


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 

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?



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]