CODEWITHSUNDEEP
queuerabbitmqnservicebus
Shahin Gasanov
Shahin Gasanov

Reputation: 31

Incoming/outgoing message queues on client/server

My system has one server and many clients of 2 types. First type of client sends events to server. Second type receives notifications from server on these events. I'm currently testing RabbitMQ and NServiceBus to build message queue with the following requirements:

  1. First type of client should have incoming queue for events (physically running on it) to prevent data loss on server disconnection.
  2. Server should have outgoing queue for notifications (physically running on it) to prevent data loss on second type client disconnection.

[Client Type 1 + queue] -> [Server + queue] -> [Client Type 2]

Can this be achieved with one of specified components (or both of them)? If yes how?

Upvotes: 1

Views: 1009

Answers (1)

tom redfern
tom redfern

Reputation: 31800

I am not very familiar with rabbit, so I'll answer the question with nservicebus (NSB) in mind.

My system has one server and many clients of 2 types

OK, first thing, NSB does not have equivalent concepts of client and server. In NSB, all participating applications are called endpoints or services. Some endpoints are publishers, some are subscribers, some are senders, some are receivers. Some are any combination of the above.

First type of client sends events to server.

By convention, there are two types of message in NSB, commands and events. Commands are sent, events are published. So in this scenario, the type 1 clients would send commands to the server. In this scenario, a type 1 client would be a sender endpoint. The server is therefore a receiver endpoint.

Second type receives notifications from server on these events

So in this scenario, the server is a publisher endpoint, and a type 2 client is a subscriber endpoint. The server will publish an event which all subscribers would receive.

First type of client should have incoming queue for events (physically running on it) to prevent data loss on server disconnection

I am assuming that you mean the type 1 client needs to receive the data which it needs to send to the server from somewhere.

Well, in NSB, every endpoint has a queue, called the input queue. This is the means by which the endpoint receives messages.

In NSB the queue transport is abstracted, but out of the box the default is MSMQ (NSB also has support for Rabbit as the queue transport).

This provides a store-and-forward messaging pattern, which guarantees reliability. What this means is that if the server is unavailable, the queuing transport would wait until it was available again before transmitting the message.

So you could send a message onto the type 1 client input queue, which would then be converted into a command and sent to the server.

Server should have outgoing queue for notifications (physically running on it) to prevent data loss on second type client disconnection.

Similarly, when the server publishes the event (on receipt of the command from the type 1 client), the queuing transport would guarantee delivery of the event to all the subscribing type 2 clients.

A point of note: this would not be based on the server having an "outgoing queue", but rather the queuing transport would deliver the messages to the input queues of all subscribing endpoints.

So all your scenarios would be satisfied by using NServiceBus as part of your approach.

Upvotes: 1

Related Questions