camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: Proposal for the CXF and Camel integration
Date Wed, 08 Aug 2007 02:14:44 GMT

In the single jvm we could use local transport to send/receive the Camel 
message, but we just need other transport the send/receive the Camel 
message for separate jvms communication .

I have same idea we should just wrap the transport factory in the CXF, 
and Camel not need to touch it. I am also working on it to make a simple 
demo work.

For the CXFEndpoint part, I don't think the orginal design of CXF 
endpointInfo with adress is enough,
It should hold enough information which we need to setup a CXF server or 
client, such as sei class name , wsdl url etc.
The URI could be 

But I don't think we can hold so many information in a single URI 
string. eg. we just want to pass a service implementor's reference to 
the ServiceFactoryBean.
James: Is there a way to use spring to wire up the endpoint information 
for CXF?
In CXF we could use a jaxws syntax to setup the CXF server and client

  <jaxws:server id="inlineSoapBinding"
      <bean ref="#helloworld"/>
      <soap:soapBinding mtomEnabled="true" version="1.2"/>
 <jaxws:client id="wsdlLocation"

As you know CXF has two front end that we could use , one is simple 
front end and the other is jaxws front end.
May be we need to do some work to auto discover which front end we need 
to create the right CXF server or client.

BTW , we still need to set up the CXF interceptors for the CXF consumer 
and CXF producer, which we can handler different message mode such as 
POJO mode, Payload mode and Message mode :)
Now I am not clear about howto configure it :( and I don't think we can 
do it in endpoint's URL.


William Tam wrote:
> 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 <> wrote:
>> On 8/7/07, Willem Jiang <> 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
>> -------

View raw message