> -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: 18 January 2007 16:49 > To: [email protected] > Subject: Re: Proposal for Decoupling and Issues with CXFServlet > > On Thursday 18 January 2007 09:08, Glynn, Eoghan wrote: > > > (FWIW, I don't think it would be all that worthwhile to add a > > > special interface at this point as the only case we would > need it is > > > the two way partial response. Seems much simpler to just put in a > > > message.put(RESPONSE_CODE, > > > 202) in RM like we do in SOAP for the time being. If we > had another > > > transport which required special syntax we could add extension > > > points at that time.) > > > > Ok we're just going to have to agree to disagree on this. > > > > I really don't like setting the response code from outside the > > transport. > > I'm WAY WAY behind on this thread, but I really need to jump > in on this point...... > > > I COMPLETELY disagree with you on this one. There is > NOTHING in the HTTP > spec that says "RM partial responses are 202" or "SOAP faults > are 500", > etc.... Our HTTP transport should NOT have any of that > stuff coded into > it.
My whole point running through this entire thread is that we are not talking about "RM partial responses" .. Instead we are talking about "202 HTTP responses" that happen to be used to carry a SOAP envelope containing some WS-RM & WS-A headers (and possibly other headers that any other interceptor feels like adding to payload). Does the fact that we use HTTP GET ...?wsdl to do a WSDL query suddenly make GETs specific to WSDL? Before the REST support was added, WSDL query was probably the only use of GET in the code. But I don't recall anyone suggesting that GETs were WSDL-specific. > The mapping of SOAP faults to response code 500 is part of > the SOAP spec. > Thus, the SOAP layer should be setting that. The whole SOAP fault thing is tangential to the main discussion here. DanD brought it up I guess to demonstrate that its OK to set the HTTP response code outside the transport. However this is not comparing like with like. SOAP has a HTTP binding. WS-RM does not (see below). > The RM response code mappings are part of the RM spec. The > RM layer should > be specifying that. Nope, 202 isn't mentioned in the RM spec. In fact there are no "response code mappings" in the RM spec, or indeed anything HTTP-specific. The RM spec is transport independent. Its up to the implementation to figure out how to map RM onto a real transport like HTTP. In practice this mapping is mostly self-evident. However its not self-evident for two particular scenarios which I described in an earlier mail which I'll quote yet again: "Put HTTP (or any other specific transport) out of your mind for a moment, and 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." So to handle these scenarios, we came up with the partial response idea. 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. That's how the idea of "partial responses" was born. It is NOT in the RM spec. It's a de facto work-around for some short-comings in the spec, used by ourselves and at least some other RM implementations. > There should not be any RM logic burned into the transports. As I pointed many times on this thread, I don't consider the ability to send a partial response as "RM logic". > That's bad. > I'm OK with possibly adding a couple methods to help make the > RM capabilities > easier, but burning the logic into the transports is bad. > Making the > transports very complex to write is also bad. Again frankly I don't see the Destination.getBackChannel() semantics as being so difficult to understand. And certainly IMO this API doesn't make transports very complex to write. /Eoghan > Anyway, I don't know all the details (I'm way behind on the > discussion > threads), but that point just jumped out as "not good." (IMO) > > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] >
