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


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