Tagged: SignalR Azure Cloud AbbFabric

That title sums up what this blog post will summarize and explain; how to get data instantly from the cloud – in this case, the Azure cloud platform – all the way down to an HTML 5.0 browser. The point of this exercise is to take a slightly deeper dive into using SignalR. Secondary to the SignalR deep dive, this article will explain how to use the Azure Service Bus.

Azure and AppFabric can seem like huge, daunting problems. I was shocked how simple both were to use and admit that, like many technologies, the problem isn’t in their difficulty but in my willfulness to just learn how it works. Once I dove in I had a queue up and working in about 5 minutes on the first try. Mike Diiorio gave a great introduction into how AppFabric works at the Richmond Code Camp. Some of the code in this blog was inspired by the code he presented there. He really made the Azure service bus seem quite easy and made my adoption of it a lot more rapid. I’d highly recommend you check out his talk if the opportunity arises.

Service Bus Namespace Authentication

To make authentication seamless from both the publication and subscription ends of the Azure Service Bus conversation, one class will be used to persist the authentication information. The CredentialDetail class below serves to represent the service bus and the namespace under which it resides in the Azure cloud.

To give this some context, the corresponding service bus is shown below in the Azure management site. Note the red boxes; that string matches the string property Namespace in the credential class we’ll be sharing for all clients of this service bus. The IssuedKey and Issuer properties can be obtained from clicking the View button in the Azure management site.

Sending Messages to Azure

This application is a regular, boring old Console application, but you could send messages into Azure Service Bus from pretty much anything or you could host a WCF service or MVC site in Azure to publish messages to it from the Internet. Whatever the case may be, message transmission into Azure isn’t verify difficult; if you’ve done any message-based coding in the past it should appear relatively familiar in structure. The application first makes a connection to the Azure service bus using the data stored in the CredentialDetail class from earlier in this article.

Next, the Sender class connects to the Azure namespace. Then it either connects to or creates an Azure queue.

Next, the Sender class gets user input at the console and transmits that data into Azure via the queue client.

When the sender application runs, the output should be relatively obvious and simple. It just lets us enter some messages and send them into the Azure queue, then confirms the transmission was completed.

A Service Bus-Aware SignalR Hub

From the title it should be obvious we’re not going to stop by just being able to send messages into the queue. This sample will receive messages from the queue, too, and then notify all connected HTML 5.0 clients instantaneously when messages are pulled from the Azure service bus and processed.

The first step in completing this is a service that will listen for messages. The interface contract for the IQueueReceiver interface is below.

The first implementation for the IQueueReceiver interface will be expecting to get a string message. The StringQueueReceiver service watches the Azure service bus and, when messages arrive, it fires the Received event to notify any of its observers that it has a message for them.

The observer, in this case, is going to be a SignalR Hub. Since SignalR Hubs do the heavy lifting of pushing data from the server to the client browser, a custom Hub is a perfect candidate; the Hub will receive the data coming from the Azure bus, then hand it off to all the HTML clients. The ServiceBusListenerHub will depend on the StringQueueReceiver so it’ll be passed in via constructor injection.

This is where a deeper dive into how SignalR can use your favorite IoC container comes into play. Since Hubs are transient, and the nature of listening to a queue indefinitely is a more permanent type of thing, we’re going to inject the listener service into our SignalR Hub. My favorite IoC container is Unity, so I’ve rolled my very own Unity startup implementation per the specs from the SignalR team and using the WebActivator NuGet package.

Once the Unity container is set up, the service can be added.

The Hub will have one method, Initialize, that HTML clients will call at page ready. This call clears any previously bound event handlers on the IQueueReceiver.Received event, then binds to it to make sure that incoming messages are then passed to the HTML clients.

Client Code

The client code is quite simplistic. Just a few lines of JavaScript files to set SignalR and to get everything wired up.

Then a few more lines to initiate communication with the Hub.

Once that’s finished the client should start to receive messages as they’re being sent in from the service bus.

Summary

This article introduced the idea of creating an Azure Service Bus implementation (which was what I’d planned on learning through the exercise, so I met my personal goal). The messages are taken from the bus, thrown into a SignalR Hub, which then transmits those messages directly to HTML 5 browser clients. Hopefully this will inspire you to create a few Azure bus or SignalR toys yourself. The possibilities are pretty staggering!