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.
The main functionality of WAMS. There are a couple of scenarios where WAMS helps app developers with their applications:
(*) Of the types we currently support without needing any extension: Boolean, numbers, strings and dates.
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 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.
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!