The third post in the Solving Real-world Problems with Windows Azure Web Sites blog series I’ll demonstrate one manner in which a web site can be connected to an on-premises enterprise. A common use-case for a web site is to collect data for storage in a database in an enterprise environment. Likewise, the first thing most customers want to move into the cloud is their web site. Ironically, the idea of moving a whole enterprise architecture into the cloud can appear to be a daunting task. So, if one wants to host their site in the cloud but keep their data in their enterprise, what’s the solution? This post will address that question and point out how the Windows Azure Service Bus between a Windows Azure Web Site and an on-premises database can be a great glue between your web site and your enterprise.

We have this application that’d be great as a cloud-based web application, but we’re not ready to move the database into the cloud. We have a few other applications that talk to the database into which our web application will need to save data, but we’re not ready to move everything yet. Is there any way we could get the site running in Windows Azure Web Sites but have it save data back to our enterprise? Or do we have to move everything or nothing works?

I get this question quite frequently when showing off Windows Azure Web Sites. People know the depth of what’s possible with Windows Azure,  but they don’t want to have to know everything there is to know about Windows Azure just to have a web site online. More importantly, most of these folks have learned that Windows Azure Web Sites makes it dirt simple to get their ASP.NET, PHP, Node.js, or Python web site hosted into Windows Azure. Windows Azure Web Sites provides a great starting point for most web applications, but the block on adoption comes when the first few options are laid out, similar to these:

  • It is costing us increased money and time to manage our web sites so we’re considering moving them into Windows Azure Web Sites
  • It will it cost us a lot of money to move our database into the cloud
  • We don’t have the money to rework all the applications that use that database if moving it to the cloud means those applications have to change.
  • We can’t lose any data, and the enterprise data must be as secure as it already was, at the very least.
  • Our web sites need to scale and we can’t get them what we need unless we go to Windows Azure Web Sites.

This is a common plight and question whenever I attend conferences. So, I chose to take one of these conversations as a starting point. I invented a customer situation, but one that emulates the above problem statement and prioritizations associated with the project we have on the table.

Solving the Problem using Windows Azure Service Bus

The first thing I needed to think about when I was brought this problem would be the sample scenario. I needed to come up with something realistic, a problem I had seen customers already experiencing. Here’s a high-level diagram of the idea in place. There’s not much to it, really, just a few simple steps.


In this diagram I point out how my web site will send data over to the Service Bus. Below the service bus layer is a Console EXE application that subscribes to the Service Bus Topic the web application will be publishing into the enterprise for persistence. That console EXE will then use Entity Framework to persist the incoming objects – Customer class instances, in fact – into a SQL Server database.

The subscription internal process is also exploded in this diagram. The Console EXE waits for any instance of a customer being thrown in, and it wakes up any process that’s supposed to handle the incoming instance of that object.

The Console EXE that runs allows the program to subscribe to the Service Bus Topic. When customers land on the topics from other applications, the app wakes up and knows what to do to process those customers. In this first case, the handler component basically persists the data to a SQL Server installation on their enterprise.

Code Summary and Walk-through

This example code consists of three projects, and is all available for your perusal as a GitHub.com repository. The first of these projects is a simple MVC web site, the second is console application. The final project is a core project that gives these two projects a common language via a domain object and a few helper classes. Realistically, the solution could be divided into 4 projects; the core project could be divided into 2 projects, one being the service bus utilities and the other being the on-premises data access code. For the purposes of this demonstration, though, the common core project approach was good enough. The diagram below shows how these projects are organized and how they depend on one another.


The overall idea is simple -  build a web site that collects customer information in a form hosted in a Windows Azure Web Site, then ship that data off to the on-premises database via the Windows Azure Service Bus for storage. The first thing I created was a domain object to represent the customers the site will need to save. This domain object serves as a contract between both sides of the application, and will be used by an Entity Framework context class structure in the on-premises environment to save data to a SQL Server database.

With the domain language represented by the Customer class I’ll need some Entity Framework classes running in my enterprise to save customer instances to the SQL database. The classes that perform this functionality are below. They’re not too rich in terms of functionality or business logic implementation, they’re just in the application’s architecture to perform CRUD operations via Entity Framework, given a particular domain object (the Customer class, in this case).

This next class is sort of the most complicated spot in the application if you’ve never done much with the Windows Azure Service Bus. The good thing is, if you don’t want to learn how to do a lot with the internals of Service Bus, this class could be reused in your own application code to provide a quick-and-dirty first step towards using Service Bus.

The ServiceBusHelper class below basically provides a utilitarian method of allowing for both the publishing and subscribing features of Service Bus. I’ll use this class on the web site side to publish Customer instances into the Service Bus, and I’ll also use it in my enterprise application code to subscribe to and read messages from the Service Bus whenever they come in. The code in this utility class is far from perfect, but it should give me a good starting point for publishing and subscribing to the Service Bus to connect the dots.

Now that the Service Bus helper is there to deal with both ends of the conversation I can tie the two ends together pretty easily. The web site’s code won’t be too complicated. I’ll create a view that site users can use to input their customer data. Obviously, this is a short form for demonstration purposes, but it could be any shape or size you want (within reason, of course, but you’ve got ample room if you’re just working with serialized objects).

If I’ve got an MVC view, chances are I’ll need an MVC action method to drive that view. The code for the HomeController class is below. Note, the Index action is repeated – one to display the form to the user, the second to handle the form’s posting. The data is collected via the second Index action method, and then passed into the Service Bus.

The final piece of code to get this all working is to write the console application that runs in my enterprise environment. The code below is all that’s needed to do this; when the application starts up it subscribes to the Service Bus topic and starts listening for incoming objects. Whenever they come in, the code then makes use of the Entity Framework classes to persist the Customer instance to the SQL Server database.

Now that the code’s all written, I’ll walk you through the process of creating your Service Bus topic using the Windows Azure portal. A few configuration changes will need to be made to the web site and the on-premise console application, too, but the hard part is definitely over.

Create the Service Bus Topic

Creating a Service Bus topic using the Windows Azure portal is relatively painless. The first step is to use the New menu in the portal to create the actual Service Bus topic. The screen shot below, from the portal, demonstrates the single step I need to take to create my own namespace in the Windows Azure Service Bus.


Once I click the Create a New Topic button, the Windows Azure portal will run off and create my very own area within the Service Bus. The process won’t take long, but while the Service Bus namespace is being created, the portal will make sure I know it hasn’t forgotten about me.

service- bus-getting-created

After a few seconds, the namespace will be visible in the Windows Azure portal. If I select the new namespace and click the button at the bottom of the portal labeled Access Key, a dialog will open that shows me the connection string I’ll need to use to connect to the Service Bus.


I’ll copy that connection string out of the dialog. Then, I’ll paste that connection string into the appropriate place in the Web.config file of the web application. The screen shot below shows the Web.config file from the project, with the appropriate appSettings node highlighted.


A similar node also needs to be configured in the console application’s App.config file, as shown below.


In all, there are only two *.config files that need to be edited in the solution to get this working – the console application’s App.config file and the web application’s Web.config file. Both of these files are highlighted in the solution explorer view of the solution included with this blog post.


With the applications configured properly and the service bus namespace created, I can now run the application to see how things work.

Running the Code

Since I’ll be using Entity Framework to scaffold the SQL Server database on the fly, all I’ll need to do to set up my local enterprise environment is to create a new database. The screen shot below shows my new SQL database before running the console application on my machine. Note, there are no tables or objects in the database yet.


The first thing I’ll do to get running is to debug the console application in Visual Studio. I could just hit F5, but I’ll be running the web application in debug mode next. The idea here is to go ahead and fire up the console application so that it can create the database objects and prepare my enterprise for incoming messages.


The  console application will open up, but will display no messages until it begins processing Customer objects that land on the Service Bus. To send it some messages, I’ll now debug the web application, while leaving the console application running locally.


When the web site fires up and opens in my web browser, I’ll be presented the simple form used to collect customer data. If I fill out that form and click the Save button, the data will be sent into the Service Bus.


By leaving the console application running as I submit the form, I can see the data coming into my enterprise environment.


Going back into SQL Server Management Studio and refreshing the list of tables I can see that the Entity Framework migrations ran  perfectly, and created the table into which the data will be saved. If I select the data out of that table using a SQL query, I can verify that indeed, the data was persisted into my on-premises database.


At this point, I’ve successfully pushed data from my Windows Azure Web Site up into the Service Bus, and then back down again into my local enterprise database.


One of the big questions I’ve gotten from the community since the introduction of Windows Azure Web Sites to the Windows Azure platform is on how to connect these sites to an enterprise environment. Many customers aren’t ready to move their whole enterprise into Windows Azure, but they want to take some steps towards getting their applications into the cloud. This sort of hybrid cloud setup is one that’s perfect for Service Bus. As you’ve seen in this demonstration, the process of connecting a Windows Azure Web Site to your on-premises enterprise isn’t difficult, and it allows you the option of moving individual pieces as you’re ready. Getting started is easy, cheap, and will allow for infinite scaling opportunities. Find out how easy Windows Azure can be for Web Sites, mobile applications, or hybrid situations such as this by getting a free trial account today. I’m sure you’ll see that pretty much anything’s possible with Windows Azure.


Comment by shailendra

my question is if we using service bus relay in this case where we host our wcf service and how it communicate with our application

Comment by brady gaster

You can host your WCF service wherever you want. The only thing up in Service Bus is the endpoint. Your WCF service reaches out to the SB to let it know it's alive and where it is, then SB relays all inbound requests to SB *to* your WCF endpoint.

Hope that helps!

brady gaster
Comment by Khurram

Hi there, I was wondering how would you handle the situation the other way around. Say you want to update your cloud store whenever an update happens on premise. Would you use a service running in the azure cloud that polls for messages on the service bus topic and updates the cloud store when a new message arrives? The console app in this case would get called when a new update happens on the on premise resource and then place the message on the service bus for the cloud service to pick up? Is there a simpler way?

Comment by Brady Gaster

Khurram - you could use Service Bus Relays to send messages up to the cloud, or to send them down to your client. Relays can work in either direction.

Comment by Kirk Liemohn

Three questions come to mind:
1) Since this post is now over 2 years old, is this still the recommended approach given the conditions you outlined?
2) Does the service bus encrypt the messages? Are SSL certificates required to make that happen?
3) Does this approach work well for real-time requests? Say the Azure web site needs to show query results the user requests. Can this approach serve up the data quickly (assuming the on-prem environment has a fast Internet connection)?

Kirk Liemohn