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
- Fanout which acts like a pub sub exchange where every message on the exchange goes to every listeners worker queue. In this case you would tend not to specify a routing key
- Direct is used in a routing scenario where the routing key is specified and then a listener declared a subscription to its worker queue based on a match on the entire routing key
- Topic is a type of exchange where wild cards can be used against the routing key
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
- .net API
- WCF
- REST
- Java
- PHP
- Node.js
|
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:
- Ruby
- .net
- Java
- Python
- Stomp protocol
|
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:
Click Here
|
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:
Click Here |
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 |
|
|
|