On 8/7/07, Willem Jiang <[EMAIL PROTECTED]> wrote: > Hi All, > > I'd like to do some work of CXF and Camel integration.
Awesome! > After talked with > James , I got two typical user scenario here: > > I. Using the Camel as a mediation, CXF endpoints and Camel router are > in the separated JVMs > * Camel message -> CXF server > The message flow could be: > Camel consumer [Camel message] -> (processors ...) ->CXF producer (CXF > conduit) -> CXF server > > > * CXF client -> Camel message -> CXF server > The message flow could be: > CXF client -> Camel consumer [Camel message] -> (processors ...) ->CXF > producer(CXF conduit) ->CXF server > > II. Camel is embedded into CXF as a transport implementor, CXF and Camel > are in the same JVM > It looks like Camel will take the charge of other camel endpoints life > cycle. > > * For the CXF client which use the Camel transport > The message flow could be > CXF client [CXF message]-> Camel transport [Camel message]-> Camel router > The Router part message flow could be > Camel consumer [Camel message] -> (processors ...) -> Camel Services > or other Camel Producer > > * For the CXF Server which use the Camel transport > CXF Service (create destination message observer) -> Camel transport -> > Camel router > The Router part message flow could be > Camel consumer [Camel message] -> (processors ...) -> Camel producer > -> CXF message observer [CXF message] > > Any thoughts? That sounds about right to me. From a high level there are lots of permuations for how Camel and CXF can work together; i) CXF is the client, Camel is the server (using CXF to send messages into some Camel component) ii) Camel is the client, CXF is the server (i.e. binding camel messages to CXF endpoints) iii) Camel is inside CXF as a Transport (e.g. using Camel's XMPP, IRC or email transport etc iv) Camel is a mediation router inside CXF Actually iii and iv are kinda the same; CXF client -> Camel processors -> CXF endpoint I think you've captured the various possible flows correctly. The next challenge is implementing them :) In terms of the code thats there in camel-cxf; the transport implementation is kinda bogus; I tried basically porting the jms transport of CXF to camel without much clue what I was doing, so you might wanna trash that and start again :) The other components; we kinda have 2 right now which is maybe not ideal; one was an attempt at doing a direct POJO invocation (e.g. if the message payload contains POJOs rather than InputStream) while the other was trying to do a more usual InputStream/transport type invocation. I guess Camel could work at various CXF injection points (before marshalling, maybe during marshalling, after marshalling etc) - so we might find we do need some flexibility in how a Camel message binds to CXF and vice versa. Please do experiment and see what you think; I'm not yet sure how the Camel-CXF stuff should look, so I'm hoping we can keep experimenting until we find we're close to what we really need -- James ------- http://macstrac.blogspot.com/
