Hi
JBI is, but it's not the case for NMR, NMR isn't bind to XML payload,
nor need a WSDL to describe the NMR endpoint interface, this is the
big difference with JBI
Freeman
On 2011-9-23, at 下午4:17, Andrei Shakirin wrote:
Hi Freeman,
yep, it is also the possibility.
However JBI & NMR uses the WSDL routing semantics and mandates XML
payloads, that is not always desired.
Regards,
Andrei.
-----Original Message-----
From: Freeman Fang [mailto:[email protected]]
Sent: 23 September 2011 09:56
To: [email protected]
Subject: Re: Best practices to communicate between Camel Contexts in
different OSGi bundles
Hi,
Another solution is use camel-nmr(camel nmr component is from Apache
Servicemix) endpoint, you may need take a look at[1] to get more
details.
[1]http://camel.apache.org/nmr.html
Freeman
On 2011-9-23, at 下午3:46, Andrei Shakirin wrote:
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.
---------------------------------------------
Freeman Fang
FuseSource
Email:[email protected]
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
---------------------------------------------
Freeman Fang
FuseSource
Email:[email protected]
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
