cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Proposal for Decoupling and Issues with CXFServlet
Date Thu, 18 Jan 2007 21:39:20 GMT
On 1/18/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:daniel.kulp@iona.com]
> > Sent: 18 January 2007 16:49
> > To: cxf-dev@incubator.apache.org
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message