If you can use asynchronous messaging, then messaging is typically much faster (especially when you start to use transaction batching) as you're not sat blocking waiting on RPC calls. e.g. on the consumer side, the message broker will asynchronously stream messages into your process space so there's no RPC required to get a message to consume; its already in RAM in an object. On the sending side you can do lots of tricks from a completely asynchronous send to batching many messages together into a transaction, so there's only 1 blocking wait at the end when you do the commit.
Though not every application can easily be developed in an asynchronous way though. On 23 November 2011 02:19, KingAndrew <andrew.b...@bbtech.net> wrote: > Hi All, > I have a client that has an RMI/Corba/IIOP SOA application. For > scaleablity I plan on them using Camel/ActiveMQ. Scaling is good but it > must be as performant as the current RMI implementations. > > So my question is: Is RMI inherently faster than JMS? I was thinking that > since we won't have to export corba objects or do any Corba lookup it might > be faster. > > Thanks in advance, > > Andrew > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Is-RMS-faster-than-JMS-tp5015296p5015296.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
