NMR is an in memory bus that you can use to send sync/async objects without the cost of the serialization. Endpoints (producers/consumers) are registered in the bus when Camel routes are started and are available for all the bundles ! Thread pools can be configured.
NMR is not persistent compare to JMS On Wed, Oct 12, 2011 at 10:59 AM, Guillaume Nodet <gno...@gmail.com> wrote: > 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 >
