Hi Christian, Of course I will use it in case if i call java functionality from Camel. But in my use case I have namely some Camel routes deployed in different bundles (and implemented by different parties) that have to communicate one with another.
Regards, Andrei. -----Original Message----- From: Christian Schneider [mailto:ch...@die-schneider.net] Sent: 23 September 2011 12:41 To: users@camel.apache.org Subject: Re: Best practices to communicate between Camel Contexts in different OSGi bundles Hi Andrei, how about using simple OSGi services? You can create a service reference in your spring context and call it as a bean in a camel route. This has the advantage that the communication is not tied to camel. So the bundle implementing the service does not have to know about camel. Christian Am 23.09.2011 09:46, schrieb Andrei Shakirin: > Hi, > > I would like to ask what is the best practice to establish communication > between two Camel contexts deployed in a different bundles in OSGi > environment. > > Actually I see the following ways: > > A) VM component. > Declare and deploy different contexts and provide communication using > "vm:" > Disadvantage: VM designed for async communication and creates new threads > for consuming messages that not always desired. Addition settings for VM is > necessary to get synchronious response. > > B) JMS component. > The same as (A) but uses JMS component > Disadvantage: JMS produces overhead that is not always desired. > > C) Share Camel Context as OSGi Service and provide communication using > "direct:" > Expose Camel Context as OSGi service, get it in other bundles and add > the routes. Use "direct:" for communication. > Disadvantage: have no idea how use this approach with Spring > routes configuration > > D) Expose routes as OSGi services > Each route is exposed as OSGi service and uses the producerTemplate to > kick off the route when another bundle invokes on the service. > Disadvantage: requires additional code to expose and invoke the > routes > > E) Share Spring context via "<import resource>" > One bundle exports spring configuration as resource, another one > imports it in Spring configuration. Spring and Camel context are shared. > Disadvantage: import resources is not the best OSGi practice, > bundles are staying coupled > > Do you prefer one of proposed ways or there is a different one? > > Regards, > Andrei. > -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
