Azure Service Bus – Topics (Using the CloudFx Framework)

Azure Service Bus – Topics (Using the CloudFx Framework)

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.


The Approach

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.





Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email


  1. ValeryM July 28, 2012 at 11:36 pm - Reply


    Thanks a lot for investing your time and blogging on this. This post is a kick-ass outline of what one can do with CloudFx and Service Bus. Well done!

  2. Heretix January 16, 2014 at 5:30 am - Reply

    Hi Vineet,
    This was a very helpful example. I tried to recreate your sample code above to two separate solutions: one for creating a topic and publishing to it and the other with the Observer to subscribe to the topic.
    I’ve noticed that when I run each solution separately, they each independently create its own topic. I was expecting only one topic to be created for both to communicate with. I have triple checked that the topic and namespaces are the same in both solutions.
    I was curious if you might have come across this situation and know how to avoid it?


    • Heretix January 16, 2014 at 5:52 am - Reply

      correction – I mistakenly indicated to note that each console creates its own topic. What I meant to say is its unique subscription. As a result, each is subscribed to its own subscription but not to each other. Is there a timing factor where the subscriber should be run first, then the sender application?
      Please note that when I have the publish and subscribe code within one solution, the console works just fine. My code is pretty much bare bones where I’m not wrapping it within a try/catch block, nor a using statement, e.g.

      using (var pubSubChannel = new ServiceBusPublishSubscribeChannel(defaultTopic))

      thanks in advance for any pointers.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.