A few months back I left the ASP.NET MVC / Web API team to work more closely with the Windows Azure team. Today we released a new service in the Windows Azure family – mobile support. The idea is to provide functionality for client developers who may have a good experience in client-side programming may not have a lot of backend experience. Things such as cloud storage, authentication and push notifications typically require knowledge of a bunch of different components - SQL Azure or some other cloud DB for storage, with their own client libraries or REST-based APIs; Windows Live or other providers (usually oData-based) for authentication; Windows Notification Services (with their REST/XML-based API) or other notification services for other platforms… Windows Azure Mobile Services (WAMS) attempts to bridge this gap, with a unified service which provides that functionality for mobile application. WAMS is live on Windows Azure right now, and you can access it using a free trial, or with an active subscription. Currently the only supported client platform is Windows Store applications (formerly known as Windows 8 Metro Applications), but new client platforms (iPhone, Windows Phone, Android) are coming soon.

But why exactly do client applications need that? ScottGu’s blog about this release has a good overview of the service, so I won’t be repeating them. Here is what I personally like about those features.

Storage

The main functionality of WAMS. There are a couple of scenarios where WAMS helps app developers with their applications:

  • Distributed Storage: Most applications need to store data – points, contacts, appointments, etc. If all the application needs is local storage, then WAMS is not needed, but if you want the application to access shared data across multiple devices. The WAMS client programming model (fully asynchronous) is well suited for client applications - and coupled with things such as the async / await keywords in the managed library are quite straightforward to be used.
  • Authenticated Storage: With the authentication support, we can easily block any of the CRUD (Create, Read, Update, Delete) operations to non-authenticated users. One scenario would be to only allow authenticated operations which modify data (CUD), but allow unauthenticated reads to the data.
  • Dynamic Schema: Even though WAMS currently uses SQL Azure as a storage backend, the developers don’t need to know any SQL intricacies to store data. With the dynamic schema feature, we can just send objects with arbitrary (*) members to the service and WAMS takes care of inserting them into the tables, creating any columns as necessary. And of course, if you want to use SQL statements, you’re free to do so.
  • Scripts: If you just want to store and retrieve data, then you don’t need them, but often we want to execute some code while the CRUD operations are being executed. WAMS offers the ability to run scripts which can be easily set up on the portal itself, with no need for any IDEs.

(*) Of the types we currently support without needing any extension: Boolean, numbers, strings and dates.

Authentication

Authentication is often something hard to implement – dealing either with third-party authentication providers or implementing an authentication mechanism yourself (and this one comes with all the security pitfalls, such as not storing passwords, using appropriate hash / salt, etc.). Since in the first preview WAMS supports Windows 8 clients only, it supports the main authentication provider mechanism for that platform (Microsoft accounts, also known as Windows Live accounts). Using your Microsoft account you can log in with your WAMS application with a couple of commands from the client SDK. Also, filtering storage operations per user is also fairly simple, as shown in the Authorize Users in Scripts tutorial in the WAMS documentation.

Other authentication providers should be coming up next. I don’t know of the roadmap, but I’d guess that once non-Windows client platforms are added, other providers (such as Facebook, Twitter, or other OAuth providers should be added as well.

Push Notifications

Push notifications are a way for applications to receive notifications from the cloud, even when they’re not running. Those notifications can take form of “toasts” which appear on the user screen, or even updates to the tiles of the applications. For example, an e-mail client could be notified when a new message is available, a the user of a location-based app could be notified when one of their “friends” is nearby, and so on.

Dealing with push notifications for Windows 8 applications typically means using the REST API of the Windows Notification Service (WNS), which involves dealing with authentication tokens, properly formatting the requests (using a pre-defined XML schema), and so on. WAMS makes sending push notifications easier by providing a higher-level abstraction over the WNS API. The tutorial on the Windows Azure developer site shows  how to add push notification support using WAMS.

Coming Up

Over the next couple of weeks I’ll write a few posts showing some additional features of the service (and the client SDK). Try it out and let us know what you think!