Today, I am going to introduce working with Azure Service Bus Topics using the CloudFx Framework published by Microsoft which makes building enterprise class, truly scalable applications much simpler over the existing Azure infrastructure. If you are serious on Azure, there are many things you could do with the new framework, I mean even if not, trust me you will want to keep playing with it and surely you will fall in love with it.
I truly believe the framework will come out shining in the near future with a lot many more production quality artifacts (not to understate the plethora of features it currently boasts). Ok, now to the very basic scenario that I am describing today: How do you write a simple disconnected application with multiple subscribers using the CloudFx framework.
Service Bus Topics
Service bus Topics provide you with a quality infrastructure on Azure which allows you to build disconnected/scalable applications. For more references to the Service Bus Topics, please follow the great links below:
Ofcourse, Clemens Vasters (@clemensv) and Valery M (@TheCATerminator) have got a huge number of amazing articles out there which you can read through.
We will be building a publisher, and multi-receiver application. Assume that you (Application A) have to send a message to multiple applications somewhere in the world, but you aren’t sure when the other applications come alive to consume your message and you want these applications to receive and consume only those messages that they might be interested on. That is the most simplistic description I could give while explaining Service bus Topics and Subscriptions.
Here is a visual, taken from the Azure Training kit slides. The publisher or sender sends the message to a Topic, which is backed by a durable store and there can be multiple subscriptions hanging off the topic. This is where it gets interesting, and is different from a queue. In a queue, there is just one copy of a message, and whoever comes first gets that copy of the message.
When it comes to Topics, the message is delivered eventually to a Topic, which qualifies for the criteria based on certain properties specified on the message itself. The subscription identifies them through a list of filter conditions specified while defining the subscription. In the below scenario, there are 2 subscriptions, the first one receives messages only marked for the President, the second one receives the messages marked for the entire nation. It means if a message is sent for the President, it will be received by the 1st and if a message is sent for the nation it will be received by the 2nd subscription.
Application A simply posts the message to a Topic and goes back to doing some other good things in life. The receiver applications then wake up and read the messages from their respective subscriptions. For years, this has been a very simple way to decouple applications. Of course durability is just one feature we see from here, but the Azure Service Bus infrastructure provides us many other capabilities ( session, transactions, duplicate detection) which we will see as we go along.
Let’s build this, to make things easier I would use 3 Console applications and a Topic (MessageCollector) on Service Bus. So, this is how my current structure looks like:
First and foremost, we need to get the support for the CloudFx Framework, so we import the NuGet package by right clicking the references and adding the following :
After adding this, your console project will be magically enhanced, and it will have ALL the super powers to interact with the Service Bus infrastructure. If you look at the overwhelming app.config of the project now, one of the sections will be as below. Isn’t it great to be able to simply put all the end-points in the config !!. We only need to interact with Topics, but adding a Relay or Queue endpoint is just the same J
Once done, in the Sender application, we add the following code to send a message to the Topic. Now the point once again is SIMPLICITY. If you ever have written code against the service bus infrastructure, you have dealt with TokenProvider, ServiceBusEnvironment, NamespaceManager and TopicDescription atleast to create the Topic !!!.
Okay, so how is it different using the framework, let’s see. The first step is feeding the config, to create the Topic with the credentials. In the Sender App.config, we have the following settings to create our Topic Endpoint.
Once you are done, you need to worry about sending a message, so in the Sender first we add the support for different kinds of messages, best is to use a Class library project. We define 2 classes, with message structure
Let’s analyze line by line
a.) Get the Service Bus Config from the app.config
b.) Get the Default Topic Details from the config settings
c.) Create the Pub-Sub channel with the endpoint info of the Topic
d.) Publish the message J. Beauty isn’t it.
If you notice above, all the plumbing work is done by the framework, (Creating a subscription, mapping it to the type of the message that is being received.). If I run the 3 applications ( Sender, and 2 receivers, here is what I see ). To summarize, using the new framework makes it simpler to create a Pub-Sub application without worrying too much about other things. I will start describing things in more detail about the framework in my next blog posts.