> -----Original Message-----
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: 18 January 2007 21:39
> 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. :-)
Currently we always send back a partial response when there's a
decoupled wsa:ReplyTo in the incoming request.
However, I was thinking of changing this logic so that a partial
response body is only sent if there are non-WS-A headers contributed by
some other interceptor in the outgoing chain, as a body containing only
WS-A headers doesn't serve any useful purpose.
In those cases, we'd send back a "empty partial response", i.e. a 202
without any entity body in the HTTP case.
> 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.
As I pointed out above we always currently send a partial response in
the decoupled case.
The (partialResponse != null) logic is to distinguish between the
initial call to Destination.getBackChannel() to retrieve the "built-in"
back-channel used to the send the partial response, and the subsequent
call to this API to retrieve the decoupled back-channel used to send the
full response.
> (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.
What do you mean by WS-A driving this?
Maybe something like WS-A:
- checks if the request is oneway or has a decoupled replyTo
- creates the partial response message if required
- gets the inbuilt backchannel from the HTTP Destination
- sets up the interceptor chain for the outgoing partial response
- takes take care of initiating outgoing dispatch
Well, have a look at
org.apache.cxf.ws.addressing.ContentUtils.rebaseResponse(), and you'll
see that WS-A already does all of the above!!
The only substantive actions not undertaken by WS-A are:
1. Setting the response code to 202
2. Getting the HTTPConduit from the HTTP ConduitInitiator for the
outgoing full response
And I'm blue in the face explaining my position that these two steps are
best done by the HTTP layer.
> 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.
No, you're missing the point.
GET is a feature of HTTP. Previously, we used it only to retrieve WSDL.
So what though, that didn't make GET specific to WSDL.
Similarly 202 is a feature of HTTP. We only use it to make WS-RM work,
but again that doesn't make 202 specific to WS-RM.
The "affect our APIs" difference is irrelevant ... the lack of
API-impact arises from a questionable implementation decision to stick
the ?wsdl handling logic right in the HTTP Destination code, and then
duplicate it across our multiple variants of this. In fact, this is due
to factored out to a separate WSDLQueryHandler API or some-such to avoid
this duplication.
> > 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.
Well I ain't a lawyer :), but hearsay proves nothing ... so if these
transport writers want to contribute to the debate, let them speak up
for themselves and demonstrate their locus standi.
/Eoghan
