The cloud means many things. It means Facebook, LinkedIn, Twitter, Google, Bing and - oh yes - Windows Azure! Windows Azure, as you know, is Microsoft’s cloud operating system. It consists of many parts, but at a high level you can say it includes Compute (web and worker roles, plus storage), SQL Azure and AppFabric. AppFabric, in turn, consists of AppFabric Access Control, ServiceBus, and Cache. This article concerns ServiceBus, and its integration with SharePoint 2010 and Office 365.

What is Azure Service Bus (also known as Azure AppFabric Service Bus)?

“All applications will move to the cloud.” Isn’t that the mantra these days?

No, they won’t! Developers have spent more than 30 years writing software. Things are not moving to the cloud overnight. In fact, some applications will perhaps never move to the cloud. There are many reasons for that, and some that technology alone won’t be able to solve. Organizations are nervous about putting their sensitive data in the cloud due to lack of confidence or legal reasons. Perhaps the applications that the data depends on are not cloud ready yet. Or maybe the extra latency that the cloud introduces is not ideal for a certain category of applications.

But there is certainly an undeniable advantage that the cloud offers for certain kinds of applications. Just look at your smartphone. The apps on it depend on services in the cloud. Wouldn’t it be nice if your smartphone could securely pull information from on-premises applications without offering a million security prompts or VPN issues? Most smartphones that do support conventional VPN break the VPN connection as soon as the screen turns off and the phone goes into battery save mode. Traditional solutions are not the solution here.

This is where AppFabric ServiceBus helps. It allows you to bridge on-premises applications with cloud applications, cloud applications with on-premises applications, and cloud applications with other cloud applications, or on-premises applications with other on-premises applications (perhaps on someone else’s premises) easily, securely, without any major firewall reconfigurations. It does so by making outbound TCP or HTTP calls to a namespace hosted in Azure.

Perhaps the best part about AppFabric is the rather intuitive way you can use it. If you have used WCF, you may be familiar with netTcpBinding and webHttpBinding. Well, AppFabric contains netTcpRelayBinding and webHttpRelayBinding that are rough equivalents of what you are used to in WCF, except they work with an intermediary broker - which is your Azure AppFabric ServiceBus namespace. In addition, AppFabric ServiceBus also provides you with programming paradigms such as queues and topics that go above and beyond the simple WCF programming model.

AppFabric ServiceBus queues are exactly what the name implies: first in first out. But it is important to understand that AppFabric ServiceBus queues are not the same as Azure storage queues. AppFabric ServiceBus queues can be roughly thought of as MSMQ for the cloud. It gives you a reliable, durable storage mechanism with a listener and a sender. In fact, you can have many listeners and many senders on a queue. This enables some really interesting scenarios that AppFabric ServiceBus queues can solve. For instance:

  • Queues can perform load leveling - if your input traffic is unpredictable in nature, a queue acts as a shock absorber, and effectively queues up requests to be processed until the listener(s) catch up to the load.
  • You can use AppFabric ServiceBus queues as a load balancing mechanism; many listeners can listen on a queue. Very similar to MSMQ, AppFabric ServiceBus queues also have transactional session-full message semantics, thereby ensuring that a message isn’t dequeued until it is properly processed.
  • Queues can offer decoupling - the sender and receiver do not have to be online at the same time.
  • Queues offer the equivalent of transactions for distributed systems, where semantics such as peek/lock and de-duplication offer you graceful recovery scenarios when various components of a distributed system might fail unpredictably.

As amazing as AppFabric ServiceBus queues are, something even more amazing than queues are topics. Topics are just like queues, except they have a concept of rich messages laden with metadata on which you can create subscriptions. You can think of subscriptions as virtual queues. A listener creates a subscription using a SQL-92 syntax. This allows for newer interesting scenarios such as a logging subscription, fanning out messages to various listeners, etc.

What makes me really excited about Azure, in general, is that almost everything is exposed over a REST-based API. This truly makes Azure extremely programmable from every single platform, including JavaScript.

While AppFabric ServiceBus is a pretty big topic in itself, in this article, I will demonstrate its integration with SharePoint using webHttpRelayBinding.

Creating an AppFabric ServiceBus REST Application

Developers can use ServiceBus in many ways. One of the most straightforward ways is to simply use it as a WCF service. In this article, I will demonstrate how to use a special binding called webHttpRelayBinding to expose an on-premise REST API binding over the Service Bus. The end effect of this exercise will be that you can run a simple service on your desktop and without configuring the firewall or your router, you will be able to expose a REST-based service to the world. I am not joking; this is the magic of Service Bus.

In order to achieve this, there are two things you need to do:

  • Create a Service Bus namespace
  • Create a WCF service and client that will communicate over this namespace.

Creating the Service Bus Namespace

In order to create yourself a Service Bus namespace, you will need an Azure subscription. You can sign up for a free trial and set yourself a zero dollar spending limit, so there is really no reason to not try it. Once you have such a subscription set up for yourself, go to https://windows.azure.com and login using your credentials. In the management portal, click “Service Bus, Access Control & Caching” as shown in Figure 1.

Figure 1: The Service Bus, Access Control & Caching link

When you are inside the Service Bus, Access Control & Caching area, click New in the toolbar and create yourself a namespace. You can go ahead and create a namespace for Access Control and Cache as well - but in this article I will talk only about Service Bus (Figure 2).

Figure 2: Creating an AppFabric namespace

It will take a few minutes for your namespace to get provisioned. Meanwhile, go get yourself a coffee or two. Once provisioned, it should look like Figure 3.

Figure 3: Your newly created namespace.

Now, with the namespace selected as shown above, click on the “Default Key” section on the right-hand side in the Azure Management Portal. This will show you your owner and key name. Note these down as you will need them shortly.

Creating the REST Application

ServiceBus relay bindings require https. You could set this up in IIS, but for development purposes, it is way easier to do so in a console application serving as a host. When we use Visual Studio to develop web applications, we use a tiny little Web server hosted in the system tray. This Web server, named Cassini, is extremely convenient. Cassini, unfortunately cannot do HTTPS. So, we’ll use a .NET 4.0 console application.

Therefore, create a .NET 4.0 console application called AppFabricREST and add the following references to it:

  • C:\Program Files\Windows Azure AppFabric SDK\V1.5\Assemblies\NET4.0\Microsoft.ServiceBus.dll
  • System.ServiceModel
  • System.ServiceModel.Web

Now, in this project, add two classes - HelloWorld.cs and IHelloWorld.cs. As you might have guessed, one of these is the contract and the other is the implementation. Listing 1 shows the code for both classes.

Note from Listing 1 that this is the same old WCF you love and use. Nothing new here. The same WebGet attribute, the same serialization formats. The magic next happens in the Program.cs and the App.config. Next, we need to write the code in Program.cs to host this service. We will use a special class part of WCF called WebServiceHost. You can use this class to host http-based services easily in console applications. Again this is pure WCF, nothing specific to AppFabric yet. You can see the code for Program.cs in Listing 2.

Well I lied. There is one minor difference between a plain WCF application and Listing 2, and that is the ServiceBusEnvironment.CreateServiceUri line. That is what registers your service URL in your serviceNamespace. Also, note that we are using https since transport-level security is required. ServiceBus also supports message-level security if that is what you desire. Using REST APIs you can use OAUTH, and using socket-oriented communication you can use numerous other message-level security protocols.

Next, to finish up the application, edit the App.Config of the AppFabricREST application to look like Listing 3.

As you can see from this App.config, I am using a special binding called webHttpRelayBinding. For simplicity sake, I am not using any kind of security, but note that you could have forwarded client identities as well. Also, there is the owner and key - you need to add the owner and key you noted down earlier in the article. With this web.config in place, go ahead and run your service. You will see the service running as shown in Figure 4.

Figure 4: Your REST service running on Service Bus.

Now, call your mom, and ask her to visit this URL. Note that your namespace may be different. You will be delighted to see that your Mom can see an output as shown in Figure 5 over the Internet.

Figure 5: Output of your REST API service.

No firewall configurations at all! Incredible! Isn’t it? Now if your mom can see your service running, I would bet we can make SharePoint see it as well.

Integrating Service Bus with SharePoint 2010 and Office 365

I threw in Office 365 for a good measure because Office 365 custom code puts an additional restriction on us - all the code has to be a sandbox solution. This may feel restrictive, but do not underestimate the power of pure client-side code. I will demonstrate how you can integrate the above REST call using pure JavaScript code.

Calling REST URLs using JavaScript is incredibly easy using jQuery. You can use a simple method such as $.get or $.getJSON or $.ajax. Unfortunately that won’t work, at least not in such a straightforward manner. This is because, technically speaking, the call to your Service Bus URL will be a cross-domain call. Not only cross domain, but you are probably transitioning from http to https, or one https to another https. This will cause an ugly warning on the client side, even if you are using an older version of jQuery or hands-down Ajax code without using jQuery. You can read more about cross-domain calls and jQuery at http://blah.winsmarts.com/2012-1-jQuery_and_Crossdomain.aspx.

There are, however, mechanisms you can use to write cross-domain jQuery calls. But they generally require a server-side handler or a cross-domain policy, etc. One mechanism to do so is to write a server-side handler in Azure. That, unfortunately, is also not a great solution because even though you may be able to solve cross-domain issues using a cross-domain policy file on your Azure web role, you will not be able to affect Office 365.

Office 365 needs a purely client-side solution in pure JavaScript. Thankfully there is help. You can use the developer version of Yahoo Pipes, referred to as YQL or Yahoo Query Language, to integrate with Service Bus using pure JavaScript code. You can see this using the script shown in Listing 4.

As you can see from Listing 4, I have piggybacked on YQLs ability to make a query to my Service Bus URL. This, in turns, negotiates all firewall issues and is able to call my service and present the information in an Office 365 page purely using JavaScript. You may also note that once I get the results, I am putting those results in a div called results, the output of which can be seen in Figure 6.

Figure 6: Your service being consumed in SharePoint.

Summary

Azure AppFabric ServiceBus is an invaluable arrow in your quiver. Do you have users who wish they could easily access on-premise data on their iPhones or other mobile platforms? Do you have endless meetings with security-minded IT infrastructure people who just don’t care about your deadlines? Do you have an existing rich investment in WCF that you wished was available across the Internet to other applications you care about? ServiceBus is your friend.

In this article, I introduced you to the basic concepts of Service Bus. Service Bus, like anything else, is a topic you can go much deeper into, which I strongly encourage you to try. I briefly mentioned queues and topics, which are also available on a REST-based API. You can also integrate them with sandbox solutions using the approach I demonstrated.

In later articles I will continue to push the boundaries of what is possible with technologies that are available today.

Until then, Happy SharePointing and Jolly Azuring!