activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [CAMEL] camel-cxf
Date Thu, 05 Apr 2007 17:25:49 GMT
On 4/5/07, William Tam <> wrote:
> On 4/5/07, James Strachan <> wrote:
> > On 4/5/07, Tam, William <> wrote:
> > > I attached a patch to
> > > the camel-cxf component which has a lot of "TODOs" but hopefully I can
> > start
> > > contributing. J
> >
> > Great! :) BTW I seemed to have trouble applying the patch locally; am
> > not sure why so I ended up applying a fair bit of the diffs by hand.
> > It could be an effect of the fair bit of refactoring thats taken place
> > lately on the core APIs of Camel - its now settled down finally.
> >
> > I'll apply shortly - just need a bit of feedback...
> >
> >
> > >   BTW, I am not sure we need to deal with Destination and
> > > Conduit (transport) directly.   I think we can use custom message
> > observer
> > > and interceptors in CXF to obtain messages at various phases of
> > processing.
> >
> > Sounds cool.
> >
> > I'm still trying to grok your patches; it seems the producer side
> > assumes that the message contains a method name & a List of parameters
> > to invoke. One of the reasons for going with the LocalTransport was to
> > try work at the messaging layer (rather than object invocation layer),
> > so that a message could be a byte[] or Document or Source which then
> > goes through the CXF SOAP binding before being turned into a method
> > invocation etc.
> >
> > e.g. to be able to do things like, poll a file, turn the file into an
> > XML Source then fire it into some CXF endpoint to deal with the XML
> > data binding or SOAP handling etc.
> I agree.   I've added a TODO for it. :-)


> Basically, we can skip those CXF interceptors that marshal an invocation
> into
> a XML doc and leaving the transport layer intact.  CXF picks the right
> transport
> based on the transport address URL.  To do that, we can create a custom CXF
> client.  The custom client will accept a XML source or inputstream, set the
> input in
> a CXF Message, initialize an outgoing interceptor chain, and fire off the
> chain.

Ah OK. So maybe we need a CXF client which just takes a CXF
Exchange/Message? Then we can populate those from the Camel
Exchange/Message and let the client figure out how to do the binding?
Though we do have some nice type-conversion stuff in Camel which it'd
be nice to use though :). It could end up being easier to do the
transform/routing from an arbitrary XML document to a CXF
invoke-endpoint in Camel maybe.

> Likewise, on the consumer side, we may need to customize the in interceptor
> chain that skips the unmarshalling in order to obtain XML source.  E.g. A
> Camel
> consumer might want to transform/process the message received from a CXF
> endpoint as a XML doc and send it to another endpoint.


> Though I see the merit in being able to just include a kinda
> > invocation inside the message body then use CXF as a general purpose
> > reflection type service.
> >
> > I'm wondering, should we have multiple CXF components & endpoints? Or
> > maybe one CXF component which creates different kinds of endpoints
> > based on the URI or something. As sometimes we'll be sending around
> > chunks of XML; other times we'll be sending a List of arguments and a
> > method name? So maybe we need different endpoints for 'method
> > invocation-style' versus 'message endpoints'
> Yeah, I think it makes sense to have multiple endpoints based on URI scheme.
> (cxf-xxx ?).

Yeah! I couldn't think of a good name - so for now I've committed your
patch as cxf-invoke: URIs and used the prefix
CxfInvoke[Component|Endpoint|Producer|Consumer]. Am sure we can come
up with a much better naming convention than that & maybe unify the
code a bit more etc.

I had to do some manual application of your patch, so could you double
check that I didn't miss any code please? It should all now be in svn.
The CxfInvokeTest case doesn't pass yet mind you, so its still
disabled in pom.xml :)

Keep up the good work! :)

> We also have to come up with a URI format for endpoints that
> assocated with a WSDL (and to specify the service and port, etc).

Agreed! I started a thread on the CXF list about URI formats to see if
CXF could come up with a standard URI format we could reuse.

> In terms of use cases; I'd like to be able to take Camel messages and
> > bind them with CXF services; plus I'd also ultimately love to use CXF
> > as a JAX-WS client on top of Camel message exchanges. So as well as
> > having a Camel Component for CXF I see the need for a CXF transport
> > using Camel (for embedding Camel inside CXF).
> >
> > --
> Way cool!


What do you think is the best way of writing a CXF transport using
Camel; I started trying to port the JMS one but ended up getting very
confused; so am wondering if the Local transport might be better
starting point?



View raw message