Sending Messages to Azure AppFabric Service Bus Topics From Iron Foundry

I recently took a look at Iron Foundry and liked what I found.  Let’s take a bit of a deeper look into how to deploy Iron Foundry .NET solutions that reference additional components.  Specifically, I’ll show you how to use the new Windows Azure AppFabric brokered messaging to reliably send messages from Iron Foundry to an on-premises application.

The Azure AppFabric v1.5 release contains useful Service Bus capabilities for durable messaging communication through the use of Queues and Topics. The Service Bus still has the Relay Service which is great for invoking services through a cloud relay, but the asynchronous communication through the Relay Service isn’t durable.  Queues and Topics now let you send messages to one or many subscribers and have stronger guarantees of delivery.

An Iron Foundry application is just a standard .NET web application.  So, I’ll start with a blank ASP.NET web application and use old-school Web Forms instead of MVC. We need a reference to the Microsoft.ServiceBus.dll that comes with Azure AppFabric v1.5.  With that reference added, I added a new Web Form and included the necessary “using” statements.

I then built a very simple UI on the Web Form that takes in a handful of values that will be sent to the on-premises subscriber(s) through the Service Bus. Before creating the code that sends a message to a Topic, I defined an “Order” object that represents the data being sent to the topic. This object sits in a shared assembly used by this application that sends the message, and another application that receives a message.

[DataContract]
    public class Order
    {
        [DataMember]
        public string Id { get; set; }
        [DataMember]
        public string ProdId { get; set; }
        [DataMember]
        public string Quantity { get; set; }
        [DataMember]
        public string Category { get; set; }
        [DataMember]
        public string CustomerId { get; set; }
    }

The “submit” button on the Web Form triggers a click event that contains a flurry of activities.  At the beginning of that click handler, I defined some variables that will be used throughout.

//define my personal namespace
string sbNamespace = "richardseroter";
//issuer name and key
string issuer = "MY ISSUER";
string key = "MY PRIVATE KEY";

//set the name of the Topic to post to
string topicName = "OrderTopic";
//define a variable that holds messages for the user
string outputMessage = "result: ";

Next I defined a TokenProvider (to authenticate to my Topic) and a NamespaceManager (which drives most of the activities with the Service Bus).

//create namespace manager
TokenProvider tp = TokenProvider.CreateSharedSecretTokenProvider(issuer, key);
Uri sbUri = ServiceBusEnvironment.CreateServiceUri("sb", sbNamespace, string.Empty);
NamespaceManager nsm = new NamespaceManager(sbUri, tp);

Now we’re ready to either create a Topic or reference an existing one. If the Topic does NOT exist, then I went ahead and created it, along with two subscriptions.

//create or retrieve topic
bool doesExist = nsm.TopicExists(topicName);

if (doesExist == false)
   {
      //topic doesn't exist yet, so create it
      nsm.CreateTopic(topicName);

      //create two subscriptions

      //create subscription for just messages for Electronics
      SqlFilter eFilter = new SqlFilter("ProductCategory = 'Electronics'");
      nsm.CreateSubscription(topicName, "ElecFilter", eFilter);

      //create subscription for just messages for Clothing
      SqlFilter eFilter2 = new SqlFilter("ProductCategory = 'Clothing'");
      nsm.CreateSubscription(topicName, "ClothingFilter", eFilter2);

      outputMessage += "Topic/subscription does not exist and was created; ";
    }

At this point we either know that a topic exists, or we created one.  Next, I created a MessageSender which will actually send a message to the Topic.

//create objects needed to send message to topic
 MessagingFactory factory = MessagingFactory.Create(sbUri, tp);
 MessageSender orderSender = factory.CreateMessageSender(topicName);

We’re now ready to create the actual data object that we send to the Topic.  Here I referenced the Order object we created earlier.  Then I wrapped that Order in the BrokeredMessage object.  This object has a property bag that is used for routing.  I’ve added a property called “ProductCategory” that our Topic subscription uses to make decisions on whether to deliver the message to the subscriber or not.

//create order
Order o = new Order();
o.Id = txtOrderId.Text;
o.ProdId = txtProdId.Text;
o.CustomerId = txtCustomerId.Text;
o.Category = txtCategory.Text;
o.Quantity = txtQuantity.Text;

//create brokered message object
BrokeredMessage msg = new BrokeredMessage(o);
//add properties used for routing
msg.Properties["ProductCategory"] = o.Category;

Finally, I send the message and write out the data to the screen for the user.

//send it
orderSender.Send(msg);

outputMessage += "Message sent; ";
lblOutput.Text = outputMessage;

I decided to use the command line (Ruby-based) vmc tool to deploy this app to Iron Foundry.  So, I first published my website to a directory on the file system.  Then, I manually copied the Microsoft.ServiceBus.dll to the bin directory of the published site.  Let’s deploy! After logging into my production Iron Foundry account by targeting the api.gofoundry.net management endpoint, I executed a push command and instantly saw my web application move up to the cloud. It takes like 8 seconds from start to finish.

My site is now online and I can visit it and submit a new order [note that this site isn’t online now, so don’t try and flood my machine with messages!].  When I click the submit button, I can see that a new Topic was created by this application and a message was sent.

Let’s confirm that we really have a new Topic with subscriptions. I can first confirm this through the Windows Azure Management Console.

To see more details, I can use the Service Bus Explorer tool which allows us to browse our Service Bus configuration.  When I launch it, I can see that I have a Topic with a pair of subscriptions and even what Filter I applied.

I previously built a WinForm application that pulls data from an Azure AppFabric Service Bus Topic. When I click the “Receive Message” button, I pull a message from the Topic and we can see that it has the same Order ID as the message submitted from the website.

If I submit another message from the website, I see a different message because my Topic already exists and I’m simply reusing it.

Summary

So what did we see here?  First, I proved that an ASP.NET web application that you want to deploy to the Iron Foundry (onsite or offsite) cloud looks just like any other ASP.NET web application.  I didn’t have to build it differently or do anything special. Secondly, we saw that I can easily use the Windows Azure AppFabric Service Bus to reliably share data between a cloud-hosted application and an on-premises application.