cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Proposal for Decoupling and Issues with CXFServlet
Date Wed, 03 Jan 2007 14:08:24 GMT


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 02 January 2007 17:14
> To: cxf-dev@incubator.apache.org
> Cc: Fang, Yue (Freeman)
> Subject: Re: Proposal for Decoupling and Issues with CXFServlet
> 
> I'm saying rather than spend our time refatoring common code 
> for getBackChannel(), lets go straight to what the root of 
> the issue is - namely the points in my previous email I bring 
> up. By addressing #1, we effectively address #2 as well for 
> the getBackChannel case.  

Nope, by addressing #1 we'd at best *partially* address #2.

The point I was stressing in my previous mail is that there's a bunch of
*other* logic duplicated between the servlet and core HTTP transports,
that's totally unrelated to the decoupled case (e.g. the manipulation of
headers and setting properties on received messages).

We should eliminate *all* this duplication, which would not be achieved
by #1.

So we disagree on what the root issue actually is.

> I'm in total agreement that we need 
> to fix these others issues as well that you bring up. But I 
> still don't understand what your objection is to redoing the 
> getBackChannel().

I wouldn't object to redoing the getBackChannel() API, if the
expectation of the pay-off was realistic.

However, I don't think this is either necessary or sufficient to address
the root issue of duplication.

Remember that the creation/sending of the partial response and the
rebase on the decoupled response endpoint is already driven from within
the WS-A layer. No matter how we slice the dice the API used to achieve
this, we still need to interact with the transport, either by necessity
(e.g. as only the transport knows that the partial response should have
a "202 Accepted" status in the HTTP case), or for convenience (e.g. as
the transport knows what ConduitInitiator to use to create the decoupled
backchannel conduit, whereas WS-A would need to do some figuring to
relate a HTTP Destination to a HTTP ConduitInitiator).

/Eoghan

> On 1/2/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > Dan,
> >
> > Just back after the holidays and catching up with my mail 
> backlog, so 
> > apologies for the delay in responding.
> >
> > OK, we're agreed on the JAX-WS entanglement of the servlet 
> transport. 
> > I assume from the lack of other replies that there was no 
> good reason 
> > for this, other than expediency of the implementation, and 
> there's no 
> > particular impediment to making the servlet transport 
> > frontend-independent.
> >
> > On the HTTP/decoupling front though, I think you're conflating a 
> > couple of different issues:
> >
> > 1. Whether the decoupling logic should be primarily encapsulated in 
> > the WS-A layer or the transports.
> >
> > 2. Whether our multiple HTTP transport should duplicate or share 
> > common logic.
> 
> 
> 
> The observations in my initial mail related to point #2. Quite apart
> > from the decoupled logic, it clearly its not good for 
> > ServletDestination to just duplicate a snapshot of the other logic 
> > from the {Abstract|Jetty}HTTPDestination classes, such as 
> the header 
> > manipulation code. Conversely ServletDestination is missing 
> a bunch of 
> > stuff that was added after it was forked, such as setting the 
> > CONTENT_TYPE or BASE_PATH properties on the incoming 
> message. Also the 
> > ServletDestination doesn't seem to take the 
> HTTPDestinationConfigBean into account at all.
> >
> > No matter how many HTTP transports we end up with, or how the 
> > decoupled logic is driven, the common HTTP logic should be 
> shared in a 
> > set of abstract base classes. That way we wouldn't have some 
> > functionality just arbitrarily missing from one HTTP transport, or 
> > mods/fixes applied to one but not the other. Each additional HTTP 
> > Destination implementation should only be concerned with the 
> > particulars of the HTTP engine its based on, say the differences 
> > between the Jetty HTTPRequest versus the HttpServletRequest 
> provided by the servlet API.
> >
> 
> /Eoghan
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 23 December 2006 02:31
> > > To: cxf-dev@incubator.apache.org
> > > Cc: Fang, Yue (Freeman)
> > > Subject: Proposal for Decoupling and Issues with CXFServlet
> > >
> > > Re: Why is the servlet in the jax-ws frontend - I believe this is 
> > > because it supports exposing JAX-WS endpoints via an XML 
> > > configuration file. This could be moved into the HTTP 
> module and we 
> > > could add some publisher class which is used via 
> reflection. I think 
> > > it hasn't been high enough on anyone's priority list to 
> care about 
> > > yet.
> > >
> > > Regarding the decoupled case - It does seem the code is wrong. 
> > > However, seeing that we will have 4 different HTTP 
> transports in the 
> > > end (jetty, asyncweb, servlet, geronimo), can't we please please 
> > > please just move this decoupling logic into WS-A and add a method 
> > > which allows the layer above to see if its policy compatible?
> > >
> > > As I've outlined before I think this is a better approach as:
> > > 1. Policy is enforced by the layer using the transport, 
> not by the 
> > > transport itself. So this approach would be more semantically 
> > > correct.
> > > 2. The current getBackChannel() method is really performing two 
> > > different functions. AFAIK there isn't a case where you 
> have both a 
> > > non null in message and partial response in the same invocation.
> > > 3. It is really confusing for transport writers currently (It is 
> > > very hard to explain this method to users who are not 
> familiar with 
> > > RM) 4. It builds in RM semantics into our transport layer. Our 
> > > transport layer should be flexible enough that RM can use 
> it without 
> > > special allowances.
> > > 5. There is less code duplication
> > >
> > > Proposals:
> > > 1. Add "boolean isEncrypted()" to Conduit interface. Pros:
> > > simplest possible thing to support our current needs. Cons:
> > > It could be pretty worthless encryption, so that doesn't say much.
> > >
> > > 2. Create a list of things we would need to know about a 
> transport 
> > > (is it encrypted, encryption type, etc) and add a
> > > Conduit.getProtection() which returns this information.
> > >
> > > Thoughts?
> > >
> > > - Dan
> > >
> > > On 12/22/06, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> > > >
> > > >
> > > > Folks,
> > > >
> > > > I've been looking into an issue with the CXFServlet not 
> working as 
> > > > expected when a decoupled response endpoint is specified in the 
> > > > wsa:ReplyTo.
> > > >
> > > > At first I thought it was simply a case of code being 
> copied from 
> > > > JettyHTTPDestination to ServletDestination, and then not
> > > being kept up
> > > > to date as the JettyHTTPDestination code evolved. 
> Clearly it would 
> > > > have been better to abstract out the common logic into 
> an abstract 
> > > > base class to avoid this, but in any case it turns out the
> > > issue is a
> > > > bit more deep-seated. As it happens the servlet transport is 
> > > > incomplete, in the sense that it uses a null
> > > ConduitInitiator and thus
> > > > cannot possibly participate in a decoupled MEP.
> > > >
> > > > Now I don't want to compound the original issue by 
> duplicating the 
> > > > rt-transports-http ConduitInitiator logic in the 
> rt-frontend-jaxws 
> > > > module. Neither does it seem very clean to make 
> rt-frontend-jaxws 
> > > > depend on rt-transports-http so as to use the HTTP 
> > > > ConduitInitiator implementation directly (not least 
> because this 
> > > > is
> > > entangled with the
> > > > HTTP DestinationFactory).
> > > >
> > > > Anyway this got me thinking as to why the CXFServlet 
> lives in the 
> > > > JAX-WS frontend in the first place. Surely the choice 
> of frontend 
> > > > should be independent of the use of the servlet transport, e.g.
> > > > shouldn't it be possible to say deploy in tomcat using the
> > > rt-frontend-simple instead?
> > > >
> > > > So I'm thinking the Servlet transport should ideally 
> live in the 
> > > > rt-transport-http module instead. A cursory grep thru the
> > > servlet code
> > > > suggests the only real dependency on JAX-WS is the
> > > hardcoding of the
> > > > instantiation of org.apache.cxf.jaxws.EndpointImpl and the
> > > publish()
> > > > call. But surely this could be done via reflection, with
> > > the class to
> > > > instantiate and the publish method configured in the
> > > cxf-servlet.xml
> > > > instead?
> > > >
> > > > Can anyone who's familiar with the motivation for 
> entangling the 
> > > > servlet transport and JAX-WS comment on this?
> > > >
> > > > Cheers,
> > > > Eoghan
> > > >
> > >
> > >
> > >
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message