RE: Proposal for Decoupling and Issues with CXFServlet

["Glynn, Eoghan" <eo...@iona.com>]

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 <eo...@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
> 

Re: Proposal for Decoupling and Issues with CXFServlet

[Dan Diephouse <da...@envoisolutions.com>]

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.  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().

On 1/2/07, Glynn, Eoghan <eo...@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 <eo...@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