Styjun

The system consists of 1 or more clients and a single server. Each client is added manually and provided with an identifier (client.id). Each client can send messages to the server. The server can send messages to each client. All messages can be divided into two groups: with an answer and without.

For example some signatures:

• CompletableFuture<Response> call(Request requestToServer)


• void execute(Data dataToSend)

where Response, Request, and Data are my POJO.

So, I need some sort of RMI for implementing message communication between the server and clients.

Requirements:

1. The server must be able to identify a client by its id client.id when processing a message, but the client, before sending that message, should not directly fill this identifier;


2. Messages should be POJO;


3. Ability to answer to a message with an exception;


4. Event-driven handlers (like @RabbitListener) - several handlers - spring bean per incoming message type, with or without return type. A handler should be resolved automatically, based on incoming message type;


5. Backed by RabbitMQ or ArtemisMQ;


6. Single service for sending messages from the server to clients: client id should be provided when sending a message. Example: void sendToClient(int clientId, Data dataToClient).

What I've tried to set up this method of communication:

1. Spring Integration
   My own gateway with completable future - great. Also, can enrich message headers with client.id - great. But I didn't find an appropriate way to handle an incoming message and being able to answer it. Tried to publish an ApplicationEvent, but all event handlers have a void return type. So, my idea here is to get correlationId and send back message, providing that correlationId - that doesn't look like a clear solution.



2. 
   

   RabbitListener/RabbitTemplate
   Cons:

   
   
   
   • A lot of code to setup RabbitTemplate to send and receive messages;
   
   
   • Need to manually setup request and reply queues and bindings;
   
   
   • problem with resolving client.id inside @RabbitHandler.
   
   


3. 
   

   AmqpProxyFactoryBean
   The closest result to my needs, but several problems, that I cannot solve:

   
   
   
   • Resolve client.id on message handler;
   
   
   • Single handler per service interface method.
   
   

So, I need a lightweight solution to build up communication between services, backed by a message queue. It should be easy to add additional message type - declare the class, add the handler to the consumer and create an object of that class and send it from the producer.

But maybe I'm completely wrong, about services communication? Maybe I should not use message queue for that purpose?

Well using a message queue or message broker like RabbitMQ is a perfectly valid solution. But you have to think whether it is what you actually need.

A message broker allows you to decouple the producers and consumers of messages. It also allows you to introduce a level of fault tolerance. If the consumer is not available temporarily the message is not lost. However, it also means that if a reply is expected the producer of the message might incorrectly think that the other end has processed its request and keep waiting for a reply. Message brokers also often offer some kind of guarantee, like once-and-only-once, or at-least-once, and also policies how to handle undeliverable messages (like dead letter queues), time-to-live, and various routing capabilities (like consistent hash based routing). In your case, you will probably have to route by some header value carrying your client.id if your server-originated messages are to reach one client only.

If you don't care about any of these features and just want a communications fabric, maybe going for something a bit different might make more sense. For example Akka offers actor-based distributed communication.

If what is bothering you is just the cleanliness of the solution, or the amount of boilerplate, maybe having a look at other implementations might help. You might want to have a look at the Reactive Streams API implementation for RabbitMQ, which should be a bit more abstract.