Hosting a Silverlight app in Azure

A quick introduction to how you can get up and running with Microsoft Azure – It is a hands-on guide into creating a silverlight application that uses a REST api to manage SQL data in the cloud.

Who should read this:

This article assumes that:

• You know (and love!!) the SOLID programming principles
• You know what WCF is and how to host and consume such services through IIS
• You have some knowledge of the Entity Framework ORM
• You want to get something out on windows Azure, but you’re not quite sure how to

The concept

I am writing an inventorizer application. The idea is to keep track of my movies and to know where in my house they are supposed to be. This way, I know where to put a stray movie, as well as check that all movies that are supposed to be in a specific shelf actually are there.

Later, I will extend the application to access my movie list from mobile devices, so it’s going to require a REST api right from the start.

Entities and storage

To get started, I defined 3 basic entities for my application:

Using Entity Framework, I started by creating a model from a blank database:

I’ve explicitly given the entities the prefix “Db” in order to separate the objects from my C# domain objects.  Automapper does the conversion for me – pretty straightforward. I keep my domain objects clean, and clear of the Sql Server, as you should too.

SQL Azure

To work with SQL Azure, you need to have a valid Azure account and you also need to have created a database for the purpose. I won’t go into the details of the database creation process; basically, you follow a database creation wizard that does what you expect it to.

Once created, you want to connect your Visual Studio Server explorer to this newly created database. To do that, you first allow yourself through SQL Azures firewall, which is fairly simple, flip to the Firewall Settings tab and click on the button “Add Rule” which brings up this:

Complete the firewall rule by setting your IP number then click OK and flip back to the databases tab to get a connection string:

The connection string does not have your password in it. You’ll have to edit that in after you put it in your settings file. If you need help in pushing your model to Azure SQL, just drop me a line, and I’ll help you out.

Setting up the REST service

Setting up the REST service is a mattter of

1. Defining your service interface
2. Implementing the service in some class
3. Setting up the service endpoint configuration in your service configuration file

Important note:
In order to implement REST and use WebGet and such, you need to include a reference to System.ServiceModel.Web. Make sure in your project properties that you’ve selected the full .Net Framework 4.0 and not the .Net Framework 4.0 Client profile as your target framework, or System.ServiceModel.Web won’t be visible for you to reference.

Defining the service interface

Not much hassle here, the special consideration is the REST way of making the endpoints accessible:

Implementing the service

Since we started with the EF model, implementing the service simply means creating a repository interface (for convenience) and then implementing it with the generated context class

Setting up the service endpoint configuration

To roll out a successful REST service that serves both POX (plain old xml) and JSON data, I had to actually create two different binding configurations even though they’re equal in configuration.

Second, set up a couple of behaviors, differenciating only in the default response format:

Finally, set up the endpoints you need:

Since we are hosting this in Azure, we do not specify any addresses.

Creating the client

Now that both the database and REST API is up and running, you only need to create a regular silverlight client, point it to the service, and you’re in business. I actually created a SOAP endpoint in addition to the POX and JSON addresses since I do not need to box data between .Net clients, thus my Silverlight client config has the following service reference:

Notice the relative address, since I’m hositing the Silverlight client from the same location as the service, I use the relative address to avoid cross-domain issues. This took me some time to figure out. I usually start out with a basicHttpBinding and then swap over to TCP/IP once everything is up and ok.

If you need more details on how to write a silverlight client, just drop me a message.

Azure considerations

So, having completed, tested, and debugged the project here on earth, it was time to deploy the pacakge to Azure. There was one last remaining thing to do, and that is to put a checkmark on your Sql Azure configuration screen in order to allow your services to connect to the database:

This is definetely another one of those “easy to forget, hard to figure out” things…

Integration Testing

I wanted to have a set of integration tests that directly referenced the SQL Azure database without destroying any data, so I opted for the transaction approach where you basically begin a transaction before each test, and then roll back all changes after running it. This led me to the following base class:

The base class basically implements the TestInitialize and TestCleanup methods to begin a transaction before each test, and roll it back (Dispose()) after each test has run. Any test that throws an exception will then automatically roll back the database.

TIP:
If you use the TestInitialize or TestCleanup in a base class, your derived test class won’t be able to use those attributes. This is why I added the virtual Given() function so that I can do my test setup there, should I need to.

An example of use:

The testclass above creates an instance of the class StorageRepositorySql and the test that is run is then packaged inside a transaction scope and rolled back so to not disturb my SQL server data. If you want more details on the base class, just let me know.

Running these tests is surprisingly fast, on my 2Mbit internet line, most of my tests run for less than 50ms each, which is pretty amazing, considering the transactions and that I’m in Norway while the Azure store probably is in Ireland!

Conclusion

Microsoft promises that “going Azure” should be pretty straightforward, and not much different from what you’re already used to. I tend to agree, it has been surprisingly easy to get something up there and running. Most of the challenges were actually in configuring the REST endpoints and figuring out how to allow the WCF services to access the SQL database, but other than that, the rest is straightforward.

At the end of this article, I’ve prepared a short Silverlight application that simply lists the locations in my SQL Server. It should be available through the following URL:

http://digitaldias.cloudapp.net

However, since this is work in progress, you may see a more advanced thing on this page as my application progresses, or something completely different, or, perhaps nothing at all – I make no guarantees, other than that it should be there if this article isn’t too old  

P.