cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject CXF and ServiceMix
Date Mon, 20 Nov 2006 21:19:43 GMT
I'm looking at CXF to enhance the soap support in ServiceMix and run
in several problems. First, let me state how I'd like to use CXF.

I'd like to reuse CXF to perform Soap processing (and WS-* stuff) on the
binding component side to send a JBI exchange which would conform to
the WSDL 1.1 / WSDL 2.0 abstract description of the service.  For services
that use WSDL 1.1, there can be multiple parts in the message, so JBI
defines a wrapper to wrap these parts and soap headers that are part of
the message (this is not needed in WSDL 2.0).

On the binding side, I need to be able to override the  SoapBindingFactory
with another implementation, because no marshaling phase should occur
at this point.  Unfortunately,  this is not easy because I'd like to reuse
some of the existing soap interceptors, and the existing SoapBindingFactory
is registered automatically and I found no way to override it without rewriting
the full bus configuration using spring.
Another point (and I guess this is a bug) is that I need an asynchronous
service invocation because the response will be send back by JBI at a later
time and being synchronous is unnecessary here.  The problem is that the
current interceptor chain has been designed only around synchronous service
invocation.  I said this is a bug, because the jaxws spec requires the
to be able to accept an Executor for service invocations, and given the code,
I doubt it will work if the default SimpleExecutor (which executes in
the same thread
in a blocking manner) is overriden.

The second step is to reuse CXF JAX-WS support in a soap agnostic way.
Writing a new binding may be the easiest way to go, maybe with an annotation
like @JBIBinding and all the needed stuff.
On the service side, I think we could write a SE which would support jax-ws
with a JBI binding which would unwrap the jbi wrapper and unmarshal the xml,
invoke the service and marshal the response back to xml.
What do you think of writing this new JBIBinding and allow the tooling to use
it.  I'd like to be able to leverage the java2wsdl and wsdl2java to only support
the abstract wsdl definition for that (I don't think this is currently
possible, but I
haven't looked at it yet).

Thoughts ?

Guillaume Nodet

View raw message