> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 10 January 2007 16:13 > To: [email protected] > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > Sent: 10 January 2007 15:16 > > > To: [email protected] > > > 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > >> > Sent: 09 January 2007 09:58 > > > > > >> > To: [email protected] > > > > > >> > 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 >
