camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Sharing a CamelContext across several bundles
Date Tue, 22 Dec 2009 10:46:46 GMT
2009/12/22 TheWinch <>:
> What's the difference between using an optimized in-vm JMS endpoint and a NMR
> endpoint, apart from the required infrastructure (having a JMS factory on
> one side and the NMR bundles on the other) ?
> Do they use different thread-management strategies, or do they have
> limitations? I don't want to start a troll here, just I want to understand
> the difference between them. I'm used to working with JMS and JBI but I
> don't clearly see where the NMR stands. Can I pass objects with the NMR
> (which for me is one of the big feature-and-limitation-at-the-same-time of
> JBI) ?

The NMR doesn't support persistence or flow control (which JMS does by
default) - the NMR is more in-memory SEDA stuff which works nicely
across class loaders. The main difference is the semantics really; JMS
uses queues or topics which are names with specific load balancing
characteristics; JBI/NMR uses the WSDL message routing semantics, so
you can route via interface name, service name and/or endpoint name.
If the message broker is local, there's not a huge difference to an
end user between in-vm JMS endpoints with queues and NMR to be honest
unless you need load balancing, persistence or flow control.

JBI mandates XML payloads; though the NMR endpoints can support
objects - though you have to be super careful with objects and class
loaders when using OSGi - you might not be able to cast the message
body's to anything useful in another class loader.


Open Source Integration

View raw message