Avoiding serialization is the most important one I think. On Wed, Oct 12, 2011 at 10:01, Christian Müller <christian.muel...@gmail.com > wrote:
> 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 > > > > > > > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
