Return-Path: 
 <cxf-dev-return-1859-apmail-incubator-cxf-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org
Received: (qmail 42399 invoked from network); 11 Jan 2007 16:56:48 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 11 Jan 2007 16:56:48 -0000
Received: (qmail 41426 invoked by uid 500); 11 Jan 2007 16:56:53 -0000
Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org
Received: (qmail 41392 invoked by uid 500); 11 Jan 2007 16:56:53 -0000
Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-dev@incubator.apache.org>
List-Id: <cxf-dev.incubator.apache.org>
Reply-To: cxf-dev@incubator.apache.org
Delivered-To: mailing list cxf-dev@incubator.apache.org
Received: (qmail 41383 invoked by uid 99); 11 Jan 2007 16:56:53 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jan 2007 08:56:53 -0800
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [64.233.184.228] (HELO wr-out-0506.google.com) (64.233.184.228)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jan 2007 08:56:44 -0800
Received: by wr-out-0506.google.com with SMTP id i22so351288wra
        for <cxf-dev@incubator.apache.org>;
 Thu, 11 Jan 2007 08:56:23 -0800 (PST)
Received: by 10.90.100.2 with SMTP id x2mr1205552agb.1168534583763;
        Thu, 11 Jan 2007 08:56:23 -0800 (PST)
Received: by 10.90.63.13 with HTTP; Thu, 11 Jan 2007 08:56:23 -0800 (PST)
Message-ID: <7b774c950701110856g705a8f6cvdf939ac6edaf4a39@mail.gmail.com>
Date: Thu, 11 Jan 2007 11:56:23 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Identification of Partial Responses
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FB72@owa-emea.iona.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_23383_28311199.1168534583712"
References: <FA1787F64A095C4090E76EBAF8B183E071FB72@owa-emea.iona.com>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_23383_28311199.1168534583712
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_23383_28311199.1168534583712--