We use the camel jms/activemq component for this. @Charles: Could you please share the advantges of camel nmr over camel jms/activemq with us!?
Best, Christian On Wed, Oct 12, 2011 at 8:36 AM, Charles Moulliard <cmoulli...@gmail.com>wrote: > Hi, > > On Karaf/Servicemix, the recommended approach to communicate between > camel routes deployed in separate bundles is to use camel-nmr > component > > Regards, > > Charles > > > > On Fri, Sep 23, 2011 at 12:40 PM, Christian Schneider > <ch...@die-schneider.net> wrote: > > 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 > > > > >
