What are the advantages/disadvantages for distributing multi stage tasks via JMS or JavaSpaces?

Question

When trying to distribute work that requires a multiple stage processing pipeline what are the communication, synchronization and throughput costs limitations in JMS vs JavaSpaces?

Answer 1

JMS is API, not product. It cannot have any "communication, synchronization and throughput costs". Specific implementation of JMS (Weblogic, JBoss, Tibco, ...) can.

There are no synchronization functions in JMS, btw -- queue is queue, you cannot make one message (in one queue) wait for another message (in another queue).

Answer 2

If you want SEDA, sending messages from stage to stage, then JMS implementations are typically much faster and more scalable, since MOMs are designed to not require locks so they can be highly asynchronous and concurrent. With JMS you can setup a consumer on startup and the message broker will typically push messages to your application ASAP so that there are many in-memory objects available at any time to be processed as soon as your application can process them - avoiding any network round trips or locking etc. See for example how prefetch works with ActiveMQ

Using JavaSpaces for messaging tends to be less efficient as they are generally implemented using a more database-centric approach of using locks with read/writes to entries etc. So you tend to query for objects then process them with JavaSpaces which tends to be a bit more chatty and less efficient for messaging.

The big win of the JavaSpaces approach though is if you want shared state; you can use a JavaSpace as a kinda database. Though maybe if you really want a database, you could use a relational database with JMS; but JavaSpace folks like to use a single system for shared state and messaging.

FWIW there's often no silver bullit with middleware; sometimes in memory SEDA is all you need, sometimes JMS, sometimes a relational database, sometimes files in a directory. It totally depends on your requirements, scalability, throughput, reliability and so forth. I tend to recommend to folks to hide middleware APIs from their code so that they can switch to whatever middleware they want easily via a simple one line config change such as with using Apache Camel

Answer 3

One other point to consider, JMS queues don't provide the ability to block based on size so a pure SEDA implementaion has a hard time working with pure JMS queues as it relies on the queues 'filling up' and applying back pressure on upstream stages.