On 1/11/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> but I don't think Microsoft or Axis does (I couldn't > find any info on the later, so I could be wrong there). In the Axis2 case, I believe Sandesha2 has moved to the 1.1 MakeConnection approach.
That leaves us and Systinet as the only people doing one way anonymous back chanel acknowledgements - aka partial responses. (OWABCA anyone? No that won't do... :-))
I did some tests with Systinet and here is what their > "partial response" > looks like: > > HTTP/1.0 200 OK > Date: Wed, 10 Jan 2007 22:35:46 GMT > Connection: close > Server: Systinet Server for Java/6.5.4 (Java/1.5.0_10; > Windows Vista/6.0; build SSJ-6.5.4-20060829-1824) > SOAPAction: " > http://schemas.xmlsoap.org/ws/2005/02/rm/SequenceAcknowledgement"; > Content-Type: text/xml; charset=UTF-8 > > <?xml version="1.0" encoding="UTF-8"?> > <e:Envelope > xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"; xmlns:e=" > http://schemas.xmlsoap.org/soap/envelope/";> > <e:Header> > <wsrm:SequenceAcknowledgement e:mustUnderstand="1"> > > <wsrm:Identifier>req:e9bfc950-a0fa-11db-961c-e9bf7b31961c</wsr > m:Identifier> > <wsrm:AcknowledgementRange Upper="1" Lower="1"/> > </wsrm:SequenceAcknowledgement> > </e:Header> > <e:Body/> > </e:Envelope> > > A couple thoughts. First, there is no 202, so I don't think > we should be using that as a trigger. Interesting, is the test invocation a oneway or twoway?
If the former, then I suppose they could justify using a "200 OK"
response code.
It is indeed a response to a one way operation.
> And there obviously > isn't an action, so that is right out. It doesn't have a > RelatesTo. The lack of a RelatesTo is what I've been advocating as the distinguishing feature for partial versus full responses.
I would argue that its not the lack of RelatesTo that distinguishes it. Its the presence of a <SequenceAcknowledgement> on a response to a one way message. *snip bad idea #357 from dan* OK, so I forgot that Conduits are used for multiple connections. Not sure what I was thinking there. Still I think we can clean things up a bit (in addition to the changes I've outlined in the other thread to remove automatic decoupling in the transport layer): 1. Remove isPartialResposne from HTTPConduit - this logic isn't right as it depends on a certain HTTP response code. I think the best way to test to see if we have a response message is to just check and see if the contentType is null. If it isn't, there is a message. If it is null, then there is no message. 2. RM logic shouldn't need anything special now, just recognition of a <SequenceAcknowledgement> in response to a one way message. 3. Remove isPartialResposne from ClientImpl. This call is really superflous as we are going to return as soon as the one way message is sent anyway - we aren't blocking for a response since we check for isOneWay on line 160. We should also change our logic so that we only look for response objects if the call is one way. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
