What's a good Java-based Master-Slave communication mechanism?

Question

I'm creating a Java application that requires master-slave communication between JVMs, possibly residing on the same physical machine. There will be a "master" server running inside a Java EE application server (i.e. JBoss) that will have "slave" clients connect to it and dynamically register itself for communication (that is the master will not know the IP addresses/ports of the slaves so cannot be configured in advance). The master server acts as a controller that will dole work out to the slaves and the slaves will periodically respond with notifications, so there would be bi-directional communication.

I was originally thinking of RPC-based systems where each side would be a server, but it could get complicated, so I'd prefer a mechanism where there's an open socket and they talk back and forth.

I'm looking for a communication mechanism that would be low-latency where the messages would be mostly primitive types, so no serious serialization is necessary. Here's what I've looked at:

• RMI
• JMS: Built-in to Java, the "slave" clients would connect to the existing ConnectionFactory in the application server.
• JAX-WS/RS: Both master and slave would be servers exposing an RPC interface for bi-directional communication.
• JGroups/Hazelcast: Use shared distributed data structures to facilitate communication.
• Memcached/MongoDB: Use these as "queues" to facilitate communication, though the clients would have to poll so there would be some latency.
• Thrift: This does seem to keep a persistent connection, but not sure how to integrate/embed a Thrift server into JBoss
• WebSocket/Raw Socket: This would work, but require a lot more custom code than I'd like.

Is there any technology I'm missing?

Edit: Also looked at:

• JMX: Have the client connect to JBoss' JMX server and receive JMX notifications for bidirectional comms.

Answer 1

Well, I suggest JMS if you are looking for something which is based on Java. It has all the features that you are looking for plus a strong application server such as JBoss. However, another option which is not completely java based and is not using Queues would be using using HTTP protocol and JAXB (RESTful Web services). This is a very light way of communicating between two sides. Your objects would be transformed to XML by using JAXB, and would be transferred to the other side, and then you cast it back to object once you receive it.

Answer 2

Honestly, I would just stick with JMS. You have one queue your slaves can take messages out of, and one queue that they put them back into. You can set properties about who processed each message (for accounting) right on the envelope. You get persistence with many J2EE providers (glassfish, jboss).

Plus, you can easily move to multiple-server distributed JVM with it with no extra programming.

However, it may not fit the definition of "low-latency" in some cases.