Difference Between MSMQ and RabbitMQ
MQ stands for Message Queue, which is a middleware (software class) that enables communication between applications. It is a concept where a program places the content to be passed to another application in the form of messages into a queue to be transported in an asynchronous way by the queue service provider.
Under this general framework, there are several variants, grouped under various categories based on,
- Communication methodology went to one, one to many and many to many.
- The way the message shipping takes place between sending and receiving applications.
Major players in the Message queue arena are:
- Rabbit MQ by Rabbit Technologies
- Microsoft MQ
- IBM MQ
- Apache Kafka (Open Sourced)
- Amazon MQ
- Google cloud pub/sub
Head to Head Comparison Between MSMQ and RabbitMQ (Infographics)
Below are the top 10 differences between MSMQ vs RabbitMQ:
Key Differences
Let us look at the key differences between MSMQ vs RabbitMQ as below:
- MSMQ has its own queue, and this queue manages the messages till it is transferred to the receiver. RabbitMQ delegates the entire work to an external system called Exchange. The exchange manages the messages posted by the sender and transmits them to the receiver.
- Rabbit MQ can transmit a message to many receivers in the publish/subscribe model through the exchange system whereas MSMQ has limited options of multicasting.
- RabbitMQ has other sophisticated methods of transmitting a message to a group of other servers based on a topic.
- MSMQ has an inbuilt option of tracking expired messages (dead lettering) and deleting them. In RabbitMQ, the sender system needs to instruct exchange to delete such old messages.
- MSMQ has an inbuilt facility to manage distributed brokers, whereas RabbitMQ manages this functionality through external plugins.
- From the developer’s perspective, creating queue and exchange in the software are simple in RabbitMQ, whereas in MSMQ, queues are hard configured, and it remains till it is deleted.
- MSMQ is a proprietary product of Microsoft, and it works in only under the Windows environment. RabbitMQ is an open-sourced product and works in any OS.
- Rabbit MQ uses a standard protocol called AMQP, whereas MSMQ uses multiple proprietary protocols.
Comparison Table between MSMQ vs RabbitMQ
Some of the comparisons of MSMQ vs RabbitMQ are highlighted below:
| Basis of Comparison | RabbitMQ | MSMQ |
| Platform | Open Source Platform. Available free for all. Supported by the community. | Proprietary platform by Microsoft. Supported by Microsoft. |
| Operating System | Works in multiple OS (Linux, Mac, Windows). | It works only in Windows OS. |
| Protocol | Communication between applications takes place through a platform-agnostic wire-level protocol named Advanced Message Queuing Protocol (AMQP). | It uses multi various Proprietary protocols, and there is no standard one. |
| Functionality | A sender cannot directly communicate with the receiver, and messages are communicated to the receiver through a central exchange server. The exchange manages message queues. It operates in a centralized queuing method. | Sending applications manage the messaging queue in their machine, and the data to be communicated is placed in the queue and the receiver pulls the data from this queue. It operates in a decentralized mode. |
| How does It work? | The sending application submits the message to exchange and forgets it. Like the post office, the exchange sends it to the receivers queue exchange from where the receiver pulls the information. Exchange does not store any messages in it. RabbitMQ thrives on the exchange model. | MSMQ is a default feature in windows, and it should be enabled on both the sender and receiver side. Sending machine to have full control over the messages placed in the queue and messages remain in queue till the receiver machine becomes active. Messages are retrieved by the receiver as and when required by it. Exchange is a new concept in MSMQ. |
| Specializations | Exchange enables sending the same message to multiple receivers simultaneously, and it supports the publish/subscribe model as an out of the box solution. It manages to send the messages to multiple queues and exchanges through bindings and routings. Exchange is configured to handle different types of communications. 1. Direct: One to one based on the routing key. 2. Fanout: One too many. Broadcasting model. 3. Topic: Messages to a group of receivers. 4. Headers: Instead of routing key, it relies on headers. |
MSMQ specializes in sending the incoming message to a receiver queue. MSMQ supports multicasting in its latest 3.0 version. There are few limitations in managing transactional messages in multicast resulting in data loss affecting delivery. Limited options like multicasting are only available in this MQ. |
| Queue Characteristics | Queue Characteristics cannot be changed post its creation. Each queue has 2 major attributes: lifetime (Durability) and Auto delete. Since the sender does not manage the queues, messages expiry is managed by instructing the exchange to purge (dead lettering) messages in the exchange server. Normally dead lettering taking place under the following circumstances. a. Upon reaching the expiry limit b. Rejected by receiver c. The queue limit is exceeded |
Queue characteristics are fully under the control of the Sender application. MSMQ has an inbuilt facility for managing Dead lettering queues. It tracks the expired, un-retrieved and rejected messages and removes them periodically to save disk space. |
| Policy | Queue characteristics cannot be changed once created, but they can be changed through policies. One needs to create the policies first and apply them to all queues wherever applicable. If there are multiple policies applied over a queue, the highest priority policy will be applied. | Since the respective applications manage the queues, it is simpler to manage the policy on queues. |
| Distributed Brokers | Normally it operates in a single broker environment where multiple hosts are connected to it. Managing multiple brokers in RabbitMQ is a little complicated, and this facility is not available as out of a box solution. It is managed by using Federation and Shower as plugins to RabbitMQ. Federation is a one-way exchange connecting queues and exchanges. Shovel moves messages from one system to another system. | The distributed broker’s functionality is inbuilt in MSMQ and will not be visible to its users as a separate facility. It is managed by simply changing the receiver address in the queue manager in the local servers. Queues in MSMQ stores the messages until they are delivered to the receiver system. If the receiving system or network is down, the queue keeps on trying until the attempt is successful. |
| Development Aspects | Creating a queue is just a declaration, and it is automatically created if it is not there, and the programmer needs not to check for its existence before declaring. The same things apply to exchange also. This has a message acknowledgement mechanism (ack – acknowledge, nack – Issues –negative) to track the status of the message sent to the broker through the network. Bindings can be short-circuited by declaring the destination in the routing key. A mandatory flag can be enabled to prevent an important message from getting lost. | In MSMQ, the queue in respective applications needs to be set up by a configuration process, and it resides there permanently till deleted. MSMQ tracks the messages through its local services not applicable. |
Conclusion
The above comparison brings out the fact that RabbitMQ scores over MSMQ in the performance, Queue
administration and other sophisticated features.
Recommended Articles
This is a guide to MSMQ vs RabbitMQ. Here we discuss the MSMQ vs RabbitMQ key differences with infographics and comparison table. You can also go through our other suggested articles to learn more –
