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