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: Understanding Partial Responses [Re: Identification of Partial Responses]
Date Wed, 10 Jan 2007 17:25:07 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 10 January 2007 16:13
> To: cxf-dev@incubator.apache.org
> Subject: Re: Understanding Partial Responses [Re: 
> Identification of Partial Responses]
> 
> OK, thanks Eoghan, I missed that before.
> 
> My point in bringing this up is that if its a proprietary 
> feature in CXF, 

I wouldn't call it a "proprietary" feature.

Essentially we took a view on how to plug a hole in the WS-RM spec. We
did this in a way that other RM implementors (and contributors to the
WS-RX spec) also had in mind. This approach happens to go against the
chapter and verse of the WS-I Basic Profile (R2714), but it has been
argued that BP was in error on this point.

I don't have time now to go trawl thru' the WS-RX mail archives to
provide references to all the relevant discussion, but you can get a
flavour from:

http://lists.oasis-open.org/archives/ws-rx/200507/msg00085.html

and

http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0107.ht
ml

where, if I understand correctly, the IBM WS-RX rep is arguing for
piggy-backing the ACKs on a non-empty 202 response to a oneway, which is
basically what we call a partial response. 

> we could just add an Action header if we 
> wanted to make it clear what the message is.
>
> As far as I know, other implementations get around this by 
> having a polling feature. This has now been formalized as the 
> MakeConnection operation in the WS-RX spec. 

Sure, this is in the latest 200608 draft for the WS-RX TC, but we've
been implementing the final WS-RM 1.0 spec, and not following the
evolving WS-RX spec.

Once the WS-RX work is finalized, I think we should move towards
supporting it.

Also, although I don't have hard data on this point, I'd suspect that
the extant implementations of WS-RM 1.0 out-number those of 1.1. So I'm
not sure its accurate to state that the other RM implementations use the
MakeConnection feature.

> In essence it 
> involves making a connection to the server from the client 
> for the exclusive purpose of sending back the acknowledgments.
> Microsoft implemented something similar to this for earlier 
> versions of the spec, but it was never formalized.
> 
> Also, if this is a proprietary feature for earlier versions 
> of the spec, and if the world is moving toward the 
> MakeConnection type of operations, why don't we just 
> implement a similar thing for the old version of the spec?

I don't think it would be a good idea to support a hodge-podge of WS-RM
1.0 and 1.1, for a number of reasons  ... the 1.1 namespaces are all
different, 1.1 is based on a different version of WS-A, and 1.1 removes
some features we support (e.g. the LastMessage marker).

So I think we'd be much better off waiting for 1.1 to be finalized, then
going for it in one fell swoop.

Cheers,
Eoghan 

> Performance wouldn't be bad and it would be a lot easier to implement.
> 
> - Dan
> 
> On 1/10/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > Dan,
> >
> > Partial responses have *nothing* to do with performance.
> >
> > Rather they are a way of acknowledging incoming messages in 
> scenarios 
> > where ACKs either:
> >
> > 1. cannot be sent in any other way, or
> >
> > 2. are unlikely to be sent in a timely fashion (so as to avoid 
> > spurious
> > resends)
> >
> > To quote from a mail I sent earlier on a related thread:
> >
> > <quote>
> > "lets consider the fundamental question as to why we 
> originally came 
> > to the conclusion that partial responses are needed by RM.
> >
> > Its basically to allow timely ACKs to be sent in two 
> specific scenarios.
> > Where the client's source sequence has an anonymous acksTo (so that 
> > ACKs must be piggy-backed on responses rather than being sent 
> > standalone), and either:
> >
> > A) the client invokes a series of exclusively oneway operations, so 
> > that there are no application-level responses ever sent 
> back), hence 
> > no opportunity to piggy-back ACKs
> >
> > or:
> >
> > B) the client invokes a series of non-interleaved twoway 
> operations, 
> > but the implementor up-calls are sufficiently long-lived so that a 
> > response will only become available *after* the client's 
> > retransmission interval has expired, so that the client has already 
> > resent the message before the server gets a chance to 
> acknowledge the first message instance.
> >
> > Note that partial responses are only required when the acksTo is 
> > anonymous"
> > </quote>
> >
> > In the case of your example of an "application consisted 
> solely of one 
> > way messages" (i.e. my case A above), partial responses are sent if 
> > (and
> > *only* if) the acksTo address is anonymous. This means the 
> destination 
> > cannot "only acknowledge every so often", in the sense of 
> sending ACKs 
> > out-of-band from the stream of incoming oneway requests. 
> The ackTos is 
> > anonymous, so the *only* conduit on which a ACK can be sent is the 
> > back-channel of the incoming client->server connection. But 
> since the 
> > incoming requests are all oneway, and thus never attract a full 
> > response, the ACKs *must* be sent as a partial response.
> >
> > I can't explain it any clearer, short of repeating myself endlessly.
> >
> > The reason your google search for "partial response" showed 
> up nothing 
> > is that we invented the phrase. I don't know precisely what 
> other RM 
> > implementations do to account for cases A) and B) above, 
> but I would 
> > guess that they either do not fully support anonymous acksTo or do 
> > something similar to what we do. We should do some more interop 
> > testing to find out definitively.
> >
> > /Eoghan
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 10 January 2007 15:16
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Understanding Partial Responses [Re: Identification of 
> > > Partial Responses]
> > >
> > > Been trying to educate myself some more on this issue, and I'm 
> > > remaining stumped. I don't see any mentions of such a 
> feature in the 
> > > 2005/02 spec or even in the latest WS-RX draft. Searching the web 
> > > didn't reveal anything really besides CXF/Celtix artifacts.
> > >
> > > So I have another question in addition to my one below - 
> what is the 
> > > benefit of partial responses? I remember someone citing 
> performance 
> > > benefits to me.
> > > However this seems rather unlikely as SequenceAcknowledgment 
> > > piggybacking will be possible in most scenarios.
> > >
> > > Even if your application consisted solely of one way 
> messages, the 
> > > only way to do RM with decent performance is to only acknowledge 
> > > every so often. An HTTP connection back to the message sender is 
> > > unlikely to be the performance bottleneck. Especially when you 
> > > factor in the sizes of the messages.
> > > Acknowledgments are about as small as a message gets, and I would 
> > > guess that typically the application messages will be 
> larger. Since 
> > > XML parsing is where the bottleneck is (HTTP introduces 
> some latency 
> > > which isn't an issue for seqacks and represents maybe 20% 
> of the raw 
> > > time), doing a partial response seems unlikely to have any net 
> > > benefit.
> > >
> > > What am I missing here?
> > >
> > > - 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
> > >
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message