RabitMq Vs Azure service Bus
Architecture
| Area | Microsoft Service Bus | RabbitMQ |
| Concepts | ||
| Namespaces | Namespaces are used to create a sandbox area for messaging. Namespaces also support authentication and authorization around this sandbox | Rabbit does not have a namespaces concept but there is a lot of similarity with the rabbit virtual host. The virtual host supports the similar security controls around the virtual host as SB would support around a namespace. |
| Exchanges | The usage of the “Topic” object in SB is very similar to “Exchange” object in Rabbit | The exchange is the messaging object which messages are sent to. |
| Queues | The queue concept in both areas is the same
|
|
| Topics | In SB the Topic object is conceptually equivalent to the Exchange object in RabbitMQ. | In RabbitMQ a topic is viewed as a specialized type of exchange which then has a certain type of subscription sitting applied to it. A topic is an exchange where wild cards can be used in a subscription based on the routing key. The wild cards are relatively limited. |
| Subscriptions | Subscriptions in SB are done over the message property key value pairs. There is a SQL type syntax which supports a lot of advanced capability to support subscriptions.
The SB subscription model seems to be more advanced than Rabbit. |
Subscriptions in Rabbit are based on the routing key. When you put a message onto an exchange you specify a routing key which is then used in different ways depending on the type of exchange you declare. There are three types of exchange
There is also mention of a headers based subscription type but there doesn’t seem to be any samples around this.
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-January/010939.html
|
| Routing Key | SB has a filter type called the Correlation Filter which offers similar features to the routing key in RabbitMQ | The routing key is used to drive a lot of the subscription based activity in Rabbit. The routing key would seem to be a bit of a limitation in that it can not be longer than 255 characters, I believe this may be an AMQP thing however. |
| Sandboxing | SB uses the namespace entity to deliver the equivalent features to the virtual host. Both of these create a sandbox for your queue/topic/exchange type entities | RabbitMQ includes the concept of a Virtual Host within the RabbitMQ server which allows you to have a container for your exchanges and queues. The security settings can be configured within the virtual host which allows separation and isolation of messaging. |
| Durable Queues | All queues are durable with SQL Server used for persistence | When declaring a queue it can easily be made durable by setting the is durable property to true |
| Non Durable Queues | SB does not offer an in memory only queue at this stage, all messages are durable. Similar functionality can be sort of achieved through the message TTL property but this is not really intended as an equivalent to a non-durable queue.
|
When declaring a queue it can easily be made non-durable by setting the “is durable” property to false. This means the queue is only in memory and would not survive a server failure. |
| Federated Messaging | There is not currently a bridge between servers or server and cloud in the stack which offers similar functionality to shovel. I am told the service bus team are working on a sample demonstrating this capability using the auto-forwarding feature.
|
There are a couple of different ways Rabbit can support federated messaging scenarios via some of the Rabbit plug-ins. There is the shovel plug in which will ship all messages from one queue to an exchange on another Rabbit broker
There is a federation plugin for Rabbit which is intended to support copying messages with intermittent connectivity across a WAN. It is also possible to use this to support something similar to Azure SB by hosting rabbit in AWS and using federation to copy messages from a local queue to an exchange in the cloud. |
| Poison messages | Service Bus Server offers the same deal letter queue capability as the Service Bus in the cloud.
When retries are expired the message is moved to a dead letter queue. |
In the extensions there is support for a dead letter exchange by setting the “x-dead-letter-exchange” and optional “x-dead-letter-routing-key” properties when declaring a queue.
Need to investigate how this works because without a retry policy it seems that this could have some limitations. |
| Dynamic Configuration of queue and topic | Queues and Topics can be managed dynamically through the management API.
There are also some security features within a namespace so you would need to have permissions to manage the namespace to do this. |
In Rabbit queues and exchanges can be dynamically configured through the API at runtime or through the management plug ins.
There are security settings which determine if a connection would be able to create a queue or exchange. |
| Duplicate Detection | Service Bus Server has the same duplicate detection features that Service Bus in the cloud has.
You would need to configure a time window that Service bus would look for duplicates within. |
I do not believe RabbitMQ supports this feature. |
| Retries | The brokered message has a retry property which is incremented with each attempt to collect the message from the queue.
An administrator can set the MaxDeliveryCount setting to limit the number of retries for a message and hence a message blocking up a queue creating a backlog. |
There doesn’t seem to be any retry count or max retries capability and this would need to be handled by the developer. |
| Message Delivery Delay | This is supported by the scheduled message feature which is available both in the cloud and also on premise | There doesn’t seem to be any message delay capabilities and this would need to be developed by a developer. |
| Message Expires | This can be implemented using the messages Time To Live property. | There is an extension property on a queue when it is declared which allows you to specify the time to live for any messages on that queue. You would set the property “x-message-ttl”
This has some limitations as the server really only knows how long the messages should be allowed to be on the queue where as messages from different clients may have to be handled differently. |
| MSMQ Bridge | There is a sample with the Service Bus demonstrating a Service Bus to MSMQ bridge. | Yes there is a plug in for this which will push messages from an exchange to MSMQ. I haven’t looked into the details of this but the capability is listed in the plug ins for Rabbit |
| Interoperability | ||
| AMQP Support | AMQP is not supported at present for Service Bus on premise or in the cloud however there is a webcast explaining Microsoft’s position on AMQP and it sounds like an important feature to expect in a future release.
http://www.infoq.com/presentations/AMQP-and-Windows-Azure-Service-Bus
|
AMQP is the default protocol for RabbitMQ. There are some extensions to support other protocols but these are usually in wrappers.
Rabbit is often mentioned as one of the most mature AMQP messaging servers and often considered the benchmark |
| Languages | The SB will support the same connectivity as Cloud SB
|
There is support for Rabbit in many languages and many frameworks. Most of it is documented here:
http://www.rabbitmq.com/devtools.html
Rabbit has libraries which support:
|
| Interop Samples | I haven’t reviewed any interop samples. I would like to see samples which showed senders and recievers in different technologies. | There are samples showing how different technologies can put or pull from a queue but not how they should communicate with each other. |
| Supported Protocol | HTTP/HTTPS
NetTcp |
AMQP
Others via plugins or client libraries |
| Message Exchange Patterns | ||
| MEP – Simple One-way Messaging | The simple one way pattern is easy to use with SB. It is as simple as sending a message to a queue and having a listener. This is a straightforward sample on SB. | Rabbit is simple enough to support the one way queued messaging pattern. There are a couple of samples available on line but all of the Rabbit provided samples are in Java or Python |
| MEP – Load Balanced Queue Processing | This scenario is supported using the multiple competing consumers pattern which is fairly standard with Service Bus. | Once you have a simple messaging pattern going we found it very easy to convert the sample to work in a load balanced scenario. You had to change each listener to have the “quality of service” set to only pick one message at a time. This meant to get good throughput you would need to have many listeners within your server side process |
| MEP – RPC | The RPC sample seems similar to the sample in Rabbit where the sender would create a dynamic queue in SB for the response.
The on premise implementation for SB is the same as the cloud for this MEP. |
In the RPC pattern you would send your message typically to the default exchange with the routing key specified to send the message to the appropriate worker queue that you want to process the message. Before this you would create a dynamic queue for your response. The server side would see in the reply to header that you have specified a response queue and the server would pop a response here. |
| MEP – Scatter Gather | Alan Smith has blogged about this a while ago on Windows Azure Service Bus and the implementation is pretty much the same on Service Bus for Windows Server. This is blogged on the following link:
|
In Rabbit there is no documentation about the scatter gather pattern but I was able to make this work very simply.
By sending my message to a topic exchange I was able to allow multiple subscribers to optionally pick up these messages and then respond to my reply queue. This is like a combination of the Topic MEP sample and the RPC MEP sample. There was a little extra logic in the client side to determine how long to wait for replies but otherwise this worked very well. This post is on the following link: |
| MEP – Topics | I think this is one of the key differences between the products in that the SB topic routing is based on a more advanced subscription model than the Rabbit one. The SB pattern uses message properties which offers powerful where-as the Rabbit pattern is based off the routing key and regular expressions from that key. | In RabbitMQ the topic pattern is really easy to implement but it is based on the routing key for subscription and makes assumptions about the other of those
There is a possible Rabbit pattern using Exchange Headers but I have struggled to find a good sample or documentation about this. |
| MEP – Queues | The queue patterns in SB and Rabbit are very similar except that SB does not have in memory only queues but otherwise they implement this in the same way.
|
The queue pattern is easy to implement with RabbitMQ you would push a message to the default exchange with the routing key specified which would then put the message to the right worker queue. The routing key is the name of the queue you want it to go to |
| MEP – Routing | You can implement this pattern using the correlation filter which acts the same as a routing key in Rabbit MQ. | The routing sample is very similar to the queues sample except you would be sending the message to a custom exchange with the type set to direct. Multiple listeners could then subscribe and the entire routing key would be used in the subscription with no wild cards to determine which listener got the message. |
| MEP – Header Subscriptions? | This is really just the same as how all SB subscriptions work | There is mention in the community of header based exchange routing being possible but this isn’t mentioned in any Rabbit samples |
| Ordered Delivery | Ordered delivery can be achieved by using sessions within the listener component processing messages from the queue.
|
To achieve ordered delivery you would have a single listener pulling one message at a time from the queue. You would achieve this by having the QOS attributes set to 1 like in the load balanced scenario but you would only have one listener at a time. You would probably create an active passive setup with your listening process. |
| Guidance | ||
| Enterprise Guidance | Service Bus on premise is only in beta so the guidance around it is only starting to emerge.
I would however expect that a strong set of guidance and community content will emerge over time as often does with Microsoft things like BizTalk and Azure Service Bus. I would love to see a reference architecture showing interop between different types of applications. EG a java app and a .net app able to talk to each other via service bus messaging where there is clear message flow and transformation and an abstracted concept of message definition that each end of the process then implements. |
In my opinion there is little guidance on how to create an enterprise messaging framework using Rabbit. All of the samples talk about simple message types and treat it like a simple distributed queue framework for sending simple strings. Even when you bring in the Spring AMQP project this is the first time it starts to consider message formats and transfer and introduces a JSON message converter. It does not go into any great detail about how it works or how it should be used |
| Security | ||
| Connecting to Service Bus | AuthN/AuthZ. Windows tokens or self-signed tokens | Connection is made to rabbit via a username and password
|
| Access Control and Authorization | Define authorization at the level of namespace (manage) or specific entities (manage, send, receive) | There are some command line utilities to control access to queues and exchanges. These seem a little fiddly to use |
| Extended authentication | There is also support for a Rabbit plugin which supports LDAP but this is suggested on their forums to be quite chatty so would query the vendor more before using it | |
Notes:
One of the key differences between the two products is the different view on what a topic is and how this subsequently affects how the messaging works internally. In Rabbit everything is sent to an exchange where as in SB a message can be sent to a queue or a Topic as separate objects. As result of this Rabbit has the routing key which supports different functionality for each type of exchange. SB doesn’t really need a routing key.
Development
| Area | Microsoft | RabbitMQ |
| Setting up a development machine | Installation and setup very simple. All covered by standard developer licensing which most companies would already have.
Supported on Windows 7 & 2008R2 although Windows 7 64 bit is not supported in production.
Windows XP and Windows 2003 are not supported.
|
The rabbit developer machine was very easy to setup it required the installation of a few prerequisites but that was straightforward.
Rabbit is supported on Linux and Windows |
| Getting started with samples | I found the samples easy to get working based on the information with the beta release and I also found that when I was involved in the TAP programme this was also the case. | The rabbit samples for .net are poor to it involved me building my own based on the java samples online
I also had problems learning how to configure the queues and topics and security. This was made a lot easier when I realized that my problems were because I configured security wrong and once this was fixed I was able to progress quickly because of the dynamics queues |
| API – Usage | The API for the on premise and cloud offerings is the same and the learning curve from one to the other was small.
I found it much quicker to get up and running with SB than I did with RabbitMQ |
The API usage was quite awkward to begin with because the samples are not in .net and the library for java and python is slightly different. Once I got up and going though the client library was very simple to use. |
| API – Documentation | SB on premise is still in a beta release so you would expect documentation to still be a work in progress but what has been produced so far is good. | The API documentation for Rabbit is passable and the community if fairly vibrant so there is lots of places to find things out.
The one lacking thing is in the .net space for samples and documentation. |
| WCF Support | The WCF support seems to be targeted the same as for the cloud offering. Context properties are even supported through the binding which is powerful and was one of the blockers to what I saw in the RabbitMQ wcf capability | There is a WCF binding for Rabbit on the client and server side. We think there are some limitations in the ability to use the WCF binding with different MEP because of the inability to access the routing key property or to set the exchange. |
| Configuration Requirements | The configuration requirements seem very simple | The configuration requirements seem very simple |
Operations and Quality of Service
| Area | Microsoft | RabbitMQ |
| High Availability | The HA and DR capabilities are not a core part of the first beta release so we expect these to evolve as the product goes through the beta cycle.
I would expect though that because of its dependency on SQL Server the HA and DR stories will inherit a lot of the SQL Server capabilities. |
|
| Disaster Recovery | The DR scenario for Rabbit is not really clear from the documentation I can find. I would assume you have options around san replication if you had a shared disk and an active passive setup for for the active active with mirrored queues Im not sure if this is the same or not.
I suppose there would also be options to use Shovel or one of the federated scenarios to support DR somehow to help with DR but im not clear on this. |
|
| Monitoring | Management portal will be available post RTM in the meantime the SB Explorer sample has been modified to work with this product in the short term.
SB supports performance counters, event log etc as you would expect from most Microsoft products.
You will be able to use the SQL Server SCOM management pack to monitor the SQL Server which your SB instance uses. There will also be a SCOM pack for Service Bus for Windows Server expected in the RTM timescale for the product. |
There is a 3rd party plugin which supports some monitoring capabilities for Rabbit
http://blog.scoutapp.com/articles/2010/03/08/rabbitmq-monitoring-plugins
There is a REST based management API plugin for Rabbit http://www.rabbitmq.com/management.html
Its possible to plug SCOM into the Rabbit management API via powershell which would allow you to monitor RabbitMQ with SCOM. Its very fiddly but sounds like it would work. http://serverfault.com/questions/355129/monitor-message-queues
All of these management options are not out of the box configured and require some work to setup. |
| Administration | The main ways to admin SB are
For scripting of the service bus
To provide an administration utility for service bus
We expect there will be a management portal in due course |
There are three main ways you can administer the rabbit server.
The command line tools The Web Dashboard Plugin The HTTP Rest API in the management plug in |
| Where is my message? | Most organisations are likely to implement the audit queue pattern to help track messages received.
|
The web management console plug in offers some features to be able to find and see messages. Also the audit queue pattern is also an option here. |
| Server Install (Advanced) | The advanced installation seems a lot simpler than integration people from the BizTalk arena would be used to. There are a few prerequsites but otherwise it seems nice with a software install and then just joining or creating a new farm. | The server install has gotten a lot simpler since the introduction or mirrored queues. Previous to this you needed a number of additional components to achieve a well set up highly available server. These components included Pace Maker and a couple of other things. This was initially a concern to us because its just more stuff to learn however the Mirrored queues seem to have simplified this a lot. |
| Backups | I think there will be more information in due course in this area too the same as for the HA and DR capabilities but I expect that they will inherit SQL Server features for this. | There isn’t much detail about backups for RabbitMQ. I assume that it is just a case of ensuring the servers and any disk allocated for persistent message storage are backed up |
Other
Some other factors you may wish to consider are below
| Area | Microsoft | RabbitMQ |
| Cost | Service Bus for Windows Server is expected to be free.
You will however need a SQL Server to point it to but for some scenarios such as development SQL Express would be usable.
|
RabbitMQ is free
|
| Open Source | Service Bus for Windows Server is not open source | RabbitMQ is open source
In the usual open source fashion, additional services such as support and consultancy can be purchased at a cost.
|
Summary Analysis
In trying to pull together some of the information from the above capabilities the below matrix tries to compare the products.
| Area | Microsoft | RabbitMQ |
| Strengths |
|
|
| Weaknesses |
|
|
| Opportunities |
|
Leave a Reply