On 4/5/07, James Strachan <[EMAIL PROTECTED]> wrote:
On 4/5/07, Tam, William <[EMAIL PROTECTED]> 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 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. 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 ?). 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! James
------- http://radio.weblogs.com/0112098/
