image by Bill Ward
I spent the better part of my day yesterday researching and learning about Windows Azure Service Bus. I'm more familiar using frameworks like MassTransit and EasyNetQ, but since my current project is going into Azure, I thought utilizing the environment would be a better choice. What did I learn?
Three Methods Of Communication
Surprisingly, Service Bus is made up of three different varieties of communication: Relay, Queue, and Topics and Subscriptions. These are first class citizens in the implementation of the Service Bus. While these concepts are available in the libraries I am familiar with, they are not baked directly into the underlying product RabbitMQ. I'll try to break down what each one of these communication methods means and how you would utilize them.
This method of communication allows you to talk from one service to another utilizing the Service Bus as a proxy. Imagine you have a in-house service that needs to talk to Azure. From Azure, you put a message into the Service Bus, and then the on-premise service would receive that message. To be honest, this is the least intriguing feature of Service Bus since I am building an all Azure application.
A queue is perfect for load balancing your workload. Items go into your queue, then are picked up by workers. If you are familiar with any other queueing system, then this will be what you are familiar with. Queues are perfect for delegating work and handling spikes in traffic.
Topics and Subscriptions
Topics and subscriptions are the most interesting. Topics are similar to queues but allow you to subscribe to different types of messages coming in using subscriptions. A topic holds all the subscriptions in a parent/child relationship. Subscriptions then have filters on them to match incoming messages. An example of a filter might be "membership=Gold". Each subscription is a queue of its own, and if messages match the particular subscription's filter, then they are placed into that subscription's queue. From my point of view, this feature of Service Bus is perfect for eventing. For example, I have an order come in and I want to notify the shipping, payment processing, and other departments that an order has happened; I can now do that using one message sent from a single source. I really like this feature, but I have to worry about utilizing it correctly.
Azure Service Bus seems like a pretty good queueing service but there were three things that smelled.
- Configuration Hell: A lot of configuration before getting to code.
- Verbose Code: Lots of code to write a message to the queue.
- Security was confusing as all get out
The verbosity of the code samples may have just been due to the fact that they were all inclusive samples; Authentication, writing, and reading were all done in the same place. In a real application, you would likely have these snippets separated.
I'm excited to leverage Azure Service Bus, and I think it will be a good tool in my upcoming application. The ability to queue tasks and have them execute out of process will be a huge win and I'm hoping that Azure Service Bus works as well as RabbitMQ has for me in the past. If anyone has used Azure Service Bus and know of any caveats or advice to a newbie it would be appreciated.