cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Identification of Partial Responses
Date Thu, 11 Jan 2007 11:00:50 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 10 January 2007 23:02
> To: cxf-dev@incubator.apache.org
> Subject: Re: Identification of Partial Responses
> 
> I did some research into seeing who supports partial 
> responses and systinet was the only one I found. Artix may as well

Artix doesn't use partial responses, AFAIK it just skips around the
issue by not supporting the problematic scenarios.

> 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.
 
> 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. 

But if its a twoway, then the use of 200 seems wrong to me, as its
premature at this stage to deem the status of the invocation to be "OK".


Rather it has simply been accepted for processing by the server-side
stack, and the eventual outcome may well be a nasty 500.

> 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.

> Oddly enough it has a SOAPAction - which seems 
> absolutely silly to me given the fact that we're already 
> using RM and RM has a dependency on WS-A.

Agreed.
 
> Here's how I'd like to propose watching for the partial 
> response. I think the RM layer should add its own listener 
> for the message instead of letting the Client handle it. So 
> in the RM code we would have:
> 
> if (isOneWay && conduit.isAsync()) {
>  conduit.setMessageObserver(new PartialResponseObserver()); }

Remember that at any given time, there may only be *one* MessageObserver
per Conduit. That's the way the Observable API works currently. Now if
we were to extend this to support multiple Observers (e.g. replace
setMessageObserver() with say registerMessageObserver()), we'd still
have the problem that Conduit wouldn't be capable of distinguishing
between say one observer for full responses and another for partial, as
it can't definitively tell the difference ... simply relying on the 202
isn't sufficient, as you point out.

So I guess RM would need to "save and restore" the original
general-purpose MessageObserver ... i.e. the ClientImpl calls
conduit.setMessageObserver(this) initially, during the dispatch the RM
layer replaces this with a PartialResponseObserver but keeps a reference
to the old one (we'd need to extend Observable.setMessageObserver() to
return the old observer if set), and then restores the general-purpose
observer (i.e. the ClientImpl itself) once the partial response has been
received.

But this approach would be susceptible to a nasty race condition ... As
we we've seen before, for short-lived implementor up-calls, its possible
that the full response may actually overtake the partial response. (Cast
your mind back to the "Map tests still failing" thread from late Oct /
early Nov last).

So I don't think the above approach is a runner.
 
Cheers,
Eoghan.

> The PartialResponseObserver would then be responsible for 
> setting up a message chain which parsed the partial 
> responses. We might need an additional check in there to see 
> if the conduit is synchronous, as I'm not sure that it would 
> work with anything that does two way async, but I think the 
> idea is sound. This could be done by exposing an isAsync() 
> method on the transport. HTTP would return true. Most others 
> would return false.
> 
> I could be mistaken but this has the following advantages:
> 
>    1. No isPartialResponse in the client
>    2. No isPartialResponse in the HTTPConduit
>    3. It works a lot more robustly as it doesn't depend on 
> whether or not
>    the HTTP status code is 202 is used and doesn't depend on 
> the message being
>    empty without a relatesTo header.
> 
> Thoughts?
> 
> - Dan
> 
> On 1/9/07, Dan Diephouse <dan@envoisolutions.com> wrote:
> >
> > So there aren't any distinguishing characteristics of a 
> partial response?
> > Are partial responses documented anywhere?
> >
> > Also, what other vendors are doing partial response?
> >
> > On 1/9/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
> > >
> > > Dan Diephouse wrote:
> > >
> > > > Quick question regarding #2 - Do other RM 
> implementations include 
> > > > a RelatesTo header in partial responses?
> > > >
> > > > Also, could we determine if its a partial response by 
> checking to 
> > > > see if the Action is a SequenceAcknowledgement?
> > >
> > > No, partial responses do not have the action set.
> > > A message with action SequenceAcknowledgement indicates that the 
> > > underlying message is a oneway, and was issued by an RMSource 
> > > out-of-band (e.g. when a timer signals as opposed to when 
> the client 
> > > makes an invocation/the server sends a response). It also has an 
> > > empty body (info is carried in the 
> SequenceAcknowledgement header).
> > > When SequenceAcknowledgemens are piggybacked on an application 
> > > message (
> > >
> > > in case of anonymous AcksTo on  partial responses, in case of 
> > > acksTo== replyTo on full responses), the action is that of the 
> > > underlying application message (null in case of partial 
> responses).
> > >
> > > Andrea.
> > >
> > > >
> > > > - Dan
> > > >
> > > > On 1/9/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> > > >
> > > >>
> > > >>
> > > >> OK, back to the drawing board on this one :(
> > > >>
> > > >> A quick google on this question suggests that, notwithstanding 
> > > >> some confusion, an empty SOAP body is actually kosher 
> in certain 
> > > >> circumstances ... see for example [1].
> > > >>
> > > >> So off the top of my head, I think we'd have to do 
> something like 
> > > >> the following to make the partial/full response 
> distinction more
> > > >> bullet-proof:
> > > >>
> > > >> 1. Stop sending the wsa:RelatesTo in the partial 
> response (this 
> > > >> is potentially misleading in any case) 2. Set something like a 
> > > >> Message.IS_RESPONSE property to false in the WS-A layer if the 
> > > >> wsa:RelatesTo header is not present 3. Replace the 
> > > >> ClientImpl.isPartialResponse() logic with
> > > >> Boolean.FALSE.equals(inMessage.get(Message.IS_RESPONSE))
> > > >>
> > > >> Checking via Boolean.FALSE.equals() would ensure that the 
> > > >> ClientImpl logic would be valid even if WS-A layer was 
> absent (in 
> > > >> which case the
> > >
> > > >> IS_RESPONSE property would be null, but we can assume that a 
> > > >> partial response would never be received, as this may 
> only occur 
> > > >> if WS-A
> > > headers
> > > >> were present in the corresponding request).
> > > >>
> > > >> Cheers,
> > > >> Eoghan
> > > >>
> > > >> [1]
> > > >> 
> http://lists.jboss.org/pipermail/jbossws-issues/2006-October/0000
> > > >> 22.html
> > >
> > > >>
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> > > >> > Sent: 09 January 2007 09:58
> > > >> > To: cxf-dev@incubator.apache.org
> > > >> > Subject: Identification of Partial Responses
> > > >> >
> > > >> > Further to the dicussions on the 
> > > >> > "JaxwsInterceptorRemoverInterceptor and RM" subject on the 
> > > >> > different ways to identify a partial response I came 
> accross an 
> > > >> > example of application messages with empty soap bodies.
> > > >> > This is in the
> > > >> > org.apache.cxf.systest.basicDOCBare.DOCBareClientServerTest
> > > >> > system test, where the response to the putLastTradedPrice 
> > > >> > invocation is a soap message with an empty body.
> > > >> > Addressing is not involved.
> > > >> > First off, is the empty ssoap body OK and to be expected?
> > > >> > Secondly, if it is, what should I expect if this 
> client-server 
> > > >> > setup uses addressing and non-anonymous ReplyTo? It seems we

> > > >> > can distinguish the partial response from the real 
> response not 
> > > >> > by checking for an empty body (regardless if this results in

> > > >> > empty of no list content in the
> > > >> > message) but need to look also at the addressing headers ...
> > > >> > Any ideas?
> > > >> >
> > > >> > Andrea.
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message