cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject RE: Proposal for Decoupling and Issues with CXFServlet
Date Thu, 18 Jan 2007 22:25:13 GMT
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:dan@envoisolutions.com] 
> Sent: Thursday, January 18, 2007 4:39 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Proposal for Decoupling and Issues with CXFServlet
> 
> 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
View raw message