camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Moulliard <cmoulli...@gmail.com>
Subject Re: Best practices to communicate between Camel Contexts in different OSGi bundles
Date Wed, 12 Oct 2011 09:09:35 GMT
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
<cmoulliard@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 <gnodet@gmail.com> wrote:
>> Avoiding serialization is the most important one I think.
>>
>> On Wed, Oct 12, 2011 at 10:01, Christian Müller <christian.mueller@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 <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  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
>>
>

Mime
View raw message