This article is Day #17 in a series called 31 Days of Mango, and was written by guest author Michael Collier.  Michael can be reached on Twitter at @michaelcollier.

Windows Phone + Windows Azure = Better Together

Some of the most interesting Windows Phone applications will utilize services of some type. Those services could be web services to provide access to business logic, just like we would for traditional ASP.NET applications. Those services could be data services to provide access to our data, both structure and unstructured data. Those services could also be identity management services, providing a way to handle authentication for our application.

Traditional Way

Typically we stand up one or more servers and then deploy our services and data to those servers. Doing so can be an expensive process – in time and money. We need to take the time to build, configure and secure the servers. We also need to maintain those servers (hardware failures, system patches, etc.). Predicting how many and what size servers we need in order to support our application is also a challenge. Buy too much and we’ve wasted somebody’s money. Buy too little and users (and bosses) are going to be upset. All of this forces us as application developers to worry about infrastructure, when all we want to do is build a killer mobile application.

Modern Way

One of the prevailing trends now is to leverage services (notice “services” and not “servers”) provided by a cloud platform. The Windows Azure platform provides compute services that allow for the deployment of our web service applications. We write the application and deploy it – and let Windows Azure handle the rest. Windows Azure also offers access to highly available and scalable storage services in the form of tables, blobs, and queues.

• Tables are a semi-structured storage mechanism that is capable of storing massive data very efficiently (think NoSQL, not a relational database).
• Blobs essentially act like a giant file system for storing whatever content you want (pictures, movies, documents, etc.).
• Queues serve as a lightweight messaging mechanism for passing data between disconnected systems.

Additionally Windows Azure offers an identity management service, Access Control Services (ACS), that provides an easy way to authenticate users via multitude of identity providers. ACS comes preconfigured to support major social networks such as Facebook, Yahoo!, Windows Live ID, and Google. ACS can also tap into an enterprise for identity management via Active Directory Federation Services (ADFSv2). ACS is especially great for mobile applications as users likely already have a social profile of some type. In fact, Windows Phone users already have a Windows Live ID.

There are numerous benefits for leveraging a platform such as Windows Azure when creating your Windows Phone applications. For starters, it is quick! You can use Visual Studio to write both your Windows Phone and Windows Azure powered services. Once the code is written, the service can be available on the internet in a matter of minutes. Using Windows Azure can also be very cheap. You can store as much data as you want starting for just $0.14/GB per month. Since nearly all development can be done locally on your development machine, you don’t even need to start paying until you start running your service in the cloud. All of this allows us to focus on creating a great Windows Phone application and the services that make it light up, and not the underlying infrastructure.

Let’s Do It

Let’s take a quick walkthrough of building a very simple Windows Phone application that is powered by services available on the Windows Azure platform.

Some of the key aspects to this architecture and data flow include:

1. The need to authenticate users of the Windows Phone application. Major social networks such as Facebook, Windows Live, Yahoo! and Google seem like logic choices. We’ll let Windows Azure Access Control Services (ACS) handle that work (more details below).
2. A WCF REST service will serve as the primary holder of business logic and provide secure access to our data.

One thing to point out here is how the phone is accessing the table and blob data in Windows Azure. The native API for Windows Azure is a REST API. This includes accessing storage such as tables and blobs. One of the security aspects of Windows Azure storage is that all access is protected by access keys. The access key needs to be sent in each request (part of the REST call) to Windows Azure. These keys should be kept secret. Since we need to keep our secrets a secret, we do not want to put the actual access keys on the phone. Doing so would let our secret information out into the wild, and that could be bad for us. It is possible to change the access keys (e.g. if the keys become compromised), and if changed, we’d need to update the application to have the new key. To be safe, we create a proxy web service by which all requests to storage will be funneled. This keeps our secret information a secret, and allows us to develop a service in a very SOA manner.

There are two basic ways in which we can create this web service proxy. The excellent folks at Microsoft have created the Windows Azure Toolkit for Windows Phone which provides a wealth of resources and samples for writing Windows Phone applications that leverage Windows Azure services. Included in this toolkit are project templates which jump start the process for working with ACS, storage (tables, blobs, and queues), and even recipes for push notifications.

However, for the purposes of this example we’re going to create a simple WCF REST service that we can easily consume from our Windows Phone application. The WCF service will not only serve as a proxy for accessing Windows Azure storage, but will also contain our business logic. If we wanted, we could extend the WCF service for other purposes as well – such as powering an ASP.NET web application or even applications for other mobile platforms. We’ll not dive too much into various aspects of Windows Azure storage here, as that is covered in depth in the Windows Azure Platform Training Kit (see the Exploring Windows Azure Storage module).

Table Storage

To start with, we will need a basic entity that we will storage in Windows Azure table storage.

   1: public sealed class Car : TableServiceEntity

   2:     {

   3:         /*

   4:          * PartitionKey = make

   5:          * RowKey = current date/time in UTC

   6:          */

   7:  

   8:         public Car()

   9:         {}

  10:  

  11:         public Car(string make, string model, int year, string description, string imageUrl)

  12:         {

  13:             PartitionKey = make;

  14:             RowKey = DateTime.UtcNow.Ticks.ToString();

  15:  

  16:             Make = make;

  17:             Model = model;

  18:             Year = year;

  19:             Description = description;

  20:             ImageUrl = imageUrl;

  21:         }

  22:  

  23:         public string Make { get; set; }

  24:         public string Model { get; set; }

  25:         public int Year { get; set; }

  26:         public string Description { get; set; }

  27:         public string ImageUrl { get; set; }

  28:     }

At this point we can create a simple method as part of our WCF service that can handle some business logic (perhaps validating an application key of some sort) and save the entity to table storage. (Note: The CarDataSource class is a simple wrapper class created to simplify some of the code – view the entire class in the solution download at the end of this post.)

   1: public class CarService : ICarService

   2: {

   3:     public void AddCar(Car car)

   4:     {

   5:         try

   6:         {

   7:             var key = ValidateApplicationKey();

   8:             if (key)

   9:             {

  10:                 var carDataSource = new CarDataSource();

  11:                 carDataSource.CreateCar(car);

  12:             }

  13:         }

  14:         catch (Exception)

  15:         {

  16:             throw new WebFaultException<string>("Failed to create a new car.", HttpStatusCode.InternalServerError);

  17:         }

  18:     }

  19: }

With the service in place, we can call the service from our Windows Phone application just like we would call any other RESTful web service. Download the full code package to view that code.

Blob Storage

As mentioned earlier, Windows Azure blob storage provides a means for storing content such as PDF documents, images, movies or really any file you may have. Each file is considered a “blob”, and blobs reside in container. Containers (and thus the residing blobs) are by default accessible only to those who have the appropriate storage access key (the same key used by table storage). With the access key, we can do any operation we want (read, create, delete, etc.). It is possible to change the permissions for a container to allow anonymous read access, which can be great when, for example, we need anybody to view pictures from Windows Phone application.

What are we to do if we want to allow someone to have access to the container for only a specific period of time, and to only have a specific set of permissions during that time? The answer is to use a Shared Access Signature (SAS). A Shared Access Signature is a specially crafted URL query string that contains the granted permissions (only create, only delete, create and delete, etc.) and the timeframe in which those permissions are valid. We can create a SAS and then provide that to whoever we want to allow that access to blob storage. In our example, we can request a Shared Access Signature from the WCF service, and then use the SAS URL to save pictures directly from our phone into Windows Azure blob storage.

The process to create a Shared Access Signature we be as follows:

   1: public Uri CreateCarImageSharedAccessSignature()

   2: {

   3:     Uri signatureUri = null;

   4:  

   5:     var key = ValidateApplicationKey();

   6:     if (key)

   7:     {

   8:         try

   9:         {

  10:             CloudBlobContainer container = CreateContainer("cars");

  11:  

  12:             // Set permissions on the container.

  13:             var sas = container.GetSharedAccessSignature(

  14:                    new SharedAccessPolicy

  15:                        {

  16:                            Permissions =

  17:                                SharedAccessPermissions.Write |

  18:                                SharedAccessPermissions.List,

  19:                            SharedAccessStartTime = DateTime.UtcNow,

  20:                            SharedAccessExpiryTime = DateTime.UtcNow + TimeSpan.FromMinutes(5)

  21:                        });

  22:  

  23:                // Trim the leading '?' to prevent there from being two in the resulting URI.

  24:                var uriBuilder = new UriBuilder(container.Uri) {Query = sas.TrimStart('?')};

  25:                signatureUri = uriBuilder.Uri;

  26:            }

  27:            catch (Exception ex)

  28:            {

  29:                throw new WebFaultException<string>(ex.Message, HttpStatusCode.InternalServerError);

  30:            }

  31:     }

  32:     return signatureUri;

  33: }

Access Control

Now that we have a the basics in place for accessing the storage services of Windows Azure, let’s add in a way to authenticate users of our application. Earlier we briefly discussed Windows Azure’s Access Control Services (ACS). ACS provides a federated, claims-based identity management solution. This allows us to authenticate users against Facebook, Yahoo!, Windows Live ID, or Google without having to write the code for each of those! Once authenticated, we’ll get a series of claims back that contain information about the user (typically their name and email address). We can then use that data to personalize the application or handle some form of user registration (ask the user for more information). The choice on which identity provider to use is entirely ours, and it is all done via configuration.

ACS is a very powerful, yet simple to use, service. To learn more about ACS, please visit http://www.microsoft.com/windowsazure/learn/control-access/#introductory.

It is very easy to add ACS support to an existing Windows Phone application. Microsoft recently released a NuGet package that makes the process quite simple. The NuGet package is great in that it allows for a very flexible solution – we can simply choose to add ACS to our application and do so in a way that is quick and introduces minimal dependencies. You can find the NuGet package by searching for “Access Control Service” in Visual Studio’s Manage NuGet Packages tool.

Or you can install the package from the NuGet package management console.

PM> Install-Package Phone.Identity.AccessControl.BasePage

Either way will set up the necessary controls and placeholders in your Windows Phone application for using ACS. Once configured, you will want to follow the provided instructions for configuring your Windows Phone application to use your ACS configuration. Using the NuGet package to add ACS support to your Windows Phone application is considered a somewhat advanced process, as it still leaves the ACS configuration up to us. There are detailed instructions here which provide an excellent step-by-step walkthrough of creating a new ACS namespace and any necessary configuration. Task 2 in that walkthrough is probably a good starting point, but the entire walkthrough is an excellent read as well.

Push Notifications

If we wanted, it is also very easy to add push notification support to our solution. There is a new NuGet package that makes adding the necessary settings very easy – much like what we saw with adding support for Access Control Services. The process for doing that is nicely demonstrated in a video over on Channel 9.

The NuGet packages for supporting Push Notifications are pretty straight forward as well.

PM> Install-Package Phone.Notifications.BasePage (client/phone side – sets up registration/registration with the Push Notification cloud service)

PM> Install-Package CloudServices.Notifications (server side –works with Microsoft Push Notification Service)

Microsoft has recently released several NuGet packages that make working with Windows Azure from our Windows Phone applications a breeze. There are packages for ACS, push notifications, and membership (traditional username/password). Be sure to check these packages out as they’ll allow you to easily mix and match the features needed for your application.

Wrap It Up

We should now be complete with our cloud powered Windows Phone application! Here we have seen how easy it can be to leverage several of the services available on the Windows Azure platform. We can easily create a web service that will provide access to our business logic and serve as a proxy to Windows Azure storage services. It is also quite easy to add Facebook, Yahoo!, Windows Live ID, or Google authentication to an existing application thanks to the new NuGet packages. Download the full example below.

Don’t forget to enter the “Go Mango” contest at http://bit.ly/MangoOffer, promo code “MCOLL”.

You can enter to win a new Samsung Series 7 slate and also free advertising for your Windows Phone application! If you use Windows Azure to power your mobile application, you will earn an bonus entry!

To download a full sample application that uses the code from the example above, please click the Download Code button below:

To get started with Windows Azure sign up for a free, 90-day trial at http://www.microsoft.com/windowsazure/free-trial/.

Resources

• Windows Azure
• Windows Azure SDK
• Windows Azure Platform Training Kit
• Windows Azure Toolkit for Windows Phone 7
• NuGet Packages for Windows Azure and Windows Phone
• Windows Azure Access Control Services
• How to Create a Windows Azure Storage Account
• Scenarios for Using Windows Azure with your Mobile Applications
• Windows Azure architecture icons courtesy of David Pallmann.

Tomorrow, we are going to discuss using sample data, and how we can use Expression Blend to make this incredibly easy for us.  See you then!