activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Tam" <>
Subject Re: [CAMEL] camel-cxf
Date Thu, 05 Apr 2007 16:08:29 GMT
On 4/5/07, James Strachan <> wrote:

> On 4/5/07, Tam, William <> wrote:
> > I've been looking at the Camel.  It's pretty cool.
> Thanks! :)
> > 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
a XML doc and leaving the transport layer intact.  CXF picks the right
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

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

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!

> -------

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message