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
