If any layer but the transport layer is setting up the decoupled response does that mean the layer responsible needs to have separate logic for every possible transport? So for example, if the WS-A layer sets up the decoupled response does it need to have special logic for HTTP and special logic for JMS and special logic for AMQP....?
One other, perhaps simple minded, question: If the response code, 202 Accepted in the HTTP case, is specific to the transport does this mean that the WS-RM stuff needs special logic to set the response code for each transport also? >From my admittedly simple view of this, it looks like that if the above is true then the transport logic stays simple at the expense of making the WS-A and WS-RM layers a massive burden to maintain... Every transport that is added, and may want to use the features, will result in additional complexity for both the WS-RM and WS-A layers. It would seem to make more sense to put the burden on the transport layer, but not mandate the implementation of decoupled response logic if the transport does not support it or need it. Is it not possible to supply stub implementations for the added interfaces? > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 18, 2007 4:39 PM > To: [email protected] > Subject: Re: Proposal for Decoupling and Issues with CXFServlet > > On 1/18/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > > > > > > > -----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? > > > > OK, so we want to use 202s on decoupled response pretty much > all the time, right? Not just when there is a partial > response. Just looked at the WS-A testcases and they seem to > indicate yes - in addition to the common sense logic involved. :-) > > Part of the confusion is because of this logic: > > if (partialResponse != null) { > partialResponse.put(Message.RESPONSE_CODE, > HttpURLConnection.HTTP_ACCEPTED); > > So technically this is only activated when we call it when > we're doing a partial response - which isn't the only case > where we need to do this. Or maybe we're always creating a > partial response so the logic always gets called. Its not > really clear to me. > > (Oddly enough I found out there is a very short spec that > details what to do in these scenarios, although its pretty > weakly worded - > http://www.w3.org/TR/2006/NOTE-soap11-ror-httpbinding-20060321/) > > If anything then its WS-A that should drive this and the > setting up of the decoupled transports. This is not a > transport concern. WS-A gets the information, it should drive > it. It simplifies the APIs and doesn't place any burden on the user. > > 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 difference is ?wsdl doesn't affect our APIs at all. > > > > 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. > > > I've spoken to several people who have worked on writing > transports and they (and myself) think otherwise. > > - Dan > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
