Search code examples
javarabbitmqactivemq-classiczeromq

Java: Better client/server message exchange approach?

I have a Java application which consists two kind of long running processes, let's say Server and Client, and usually the number of Clients is greater than 10.

Some of the application behavior are:

  • Server asks Client to perform some tasks by sending command to it
  • Server pulls the task status/result from Client
  • Client sends some heartbeat messages to Server
  • Server querys some process status from Client

Now I implement this just by transporting serialized object over TCP/IP socket. But I soon discovered that's too much details (e.g. reliability, workload monitoring) I have to deal with. So I'm looking for the various options to implement something like this. I'm currently considering message brokers like ActiveMQ, RabbitMQ or even ZeroMQ.

Any advice and suggestions will be greatly appreciated.

ps. Speed is not a concern for me

Solution

  • Try first to identify and sort your key design priorities in a Top/Down List and assign the correct priorities:

    1. Server-side scaleability of the solution approach
    2. Client [worker]-side performance scaleability of the solution architecture
    3. Serialisation overheads
    4. Transport reliability
    5. Need for many transport-classes { TCP | ipc | inproc } working at the same time
    6. Transport capacity / traffic-flow-management for respective transport-classes
    7. Transport-wide / transport-class load-balancing
    8. Deserialisation overheads
    9. Heterogenous implementation languages for various nodes / roles participating in solution
    10. Limited time-budget for analysis/design/testing
    11. Resilience to unstable problem definitions

    You may have already found, that ZeroMQ is a broker-less solution. That is important for performance scale-ability and for designing a fail-safe architecture ( one may design so that a single element failure does not stop the properly designed architecture ).

    ZeroMQ has fabulous capabilities, once you can deploy the Scaleable Formal Communication Patterns for your problem you win a lot of power by re-use of the well-thought framework.