Another advantage of NMR is that you can easily create camel routes unit test without OSGI container (more info here camel.apache.org/nmr.html)
On Wed, Oct 12, 2011 at 11:08 AM, Charles Moulliard <cmoulli...@gmail.com> wrote: > 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 >> >
