Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of cmoulliard@gmail.com designates
 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEQV+EGf1r0i7zKNsVKsHyEw1mrFEg2QXa23c6g4fuhV5djz8Q@mail.gmail.com>
References: <D225CD69196F3F4A9F4174B2FCA06F88556D70@S10BE002.SH10.lan>
	<4E7C6224.70808@die-schneider.net>
	<CABioS8Qxv7Hcj7YjtUBt-NR4tH6XK=qcw_UgdWXFaFFesqDtZA@mail.gmail.com>
	<CALvzYd-aV44C6Qb5OA0NHZrwOeuoEqhLiMWMUeXUe_fknry1qg@mail.gmail.com>
	<CAEQV+EGf1r0i7zKNsVKsHyEw1mrFEg2QXa23c6g4fuhV5djz8Q@mail.gmail.com>
Date: Wed, 12 Oct 2011 11:08:03 +0200
Message-ID: 
 <CABioS8TBBSxdgA_Vi52r+YRjYNzKVzf5TkTwZU75XRX_W_n_Gw@mail.gmail.com>
Subject: Re: Best practices to communicate between Camel Contexts in different
 OSGi bundles
From: Charles Moulliard <cmoulliard@gmail.com>
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <gnodet@gmail.com> wrote:
> Avoiding serialization is the most important one I think.
>
> On Wed, Oct 12, 2011 at 10:01, Christian M=FCller <christian.mueller@gmai=
l.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 <cmoulliard@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
>> > <chris@die-schneider.net> wrote:
>> > > Hi =A0Andrei,
>> > >
>> > > 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
>> > >
>> > >
>> > > =A0Am 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.
>> > >> =A0 =A0 Declare and deploy different contexts and provide communica=
tion
>> > using
>> > >> "vm:"
>> > >> =A0 =A0Disadvantage: VM designed for async communication and create=
s new
>> > >> threads for consuming messages that not always desired. Addition
>> > settings
>> > >> for VM is necessary to get synchronious response.
>> > >>
>> > >> B) JMS component.
>> > >> =A0 =A0 The same as (A) but uses JMS component
>> > >> =A0 =A0Disadvantage: JMS produces overhead that is not always desir=
ed.
>> > >>
>> > >> C) Share Camel Context as OSGi Service and provide communication us=
ing
>> > >> "direct:"
>> > >> =A0 =A0 =A0Expose Camel Context as OSGi service, get it in other bu=
ndles and
>> > add
>> > >> the routes. Use "direct:" for communication.
>> > >> =A0 =A0 =A0Disadvantage: have no idea how use this approach with Sp=
ring
>> routes
>> > >> configuration
>> > >>
>> > >> D) Expose routes as OSGi services
>> > >> =A0 =A0 =A0 Each route is exposed as OSGi service and uses the
>> > producerTemplate
>> > >> to kick off the route when another bundle invokes on the service.
>> > >> =A0 =A0 =A0Disadvantage: requires additional code to expose and inv=
oke the
>> > >> routes
>> > >>
>> > >> E) Share Spring context via "<import resource>"
>> > >> =A0 =A0 =A0 One bundle exports spring configuration as resource, an=
other one
>> > >> imports it in Spring configuration. Spring and Camel context are
>> shared.
>> > >> =A0 =A0 =A0Disadvantage: import resources is not the best OSGi prac=
tice,
>> > 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
>