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 > >
