cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Identification of Partial Responses
Date Thu, 11 Jan 2007 16:56:23 GMT
On 1/11/07, Glynn, Eoghan <eoghan.glynn@iona.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message