activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: [CAMEL] camel-cxf
Date Thu, 05 Apr 2007 14:56:08 GMT
On 4/5/07, Tam, William <WTAM@iona.com> 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.

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'


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

-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message