I basically agree with one comment. I am not sure single vs seperated jvm will be much of an implementation difference if we let CXF choose the right transport factory based on the address. I would change the LocalTransportFactory in CxfComponent and let CXF to solve to a factory for us. For example, if the endpoint URI is cxf:http://host:28080/test, the http transport factory will be picked (by CXF). Or if the URI is cxf:local://test, we will end up using the local transport factory. I think that can be applied to both consumer and provider. I am doing some experiment ...
- William On 8/7/07, James Strachan <[EMAIL PROTECTED]> wrote: > > 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/ >
