Proposal for Decoupling and Issues with CXFServlet

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

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