Azure Websites is an excellent platform to deploy and manage the Web API, Microsoft Azure provides, however, another alternative in the form of Azure Mobile Services, which targets mobile application developers. In this article by Nikhil Sachdeva, coauthor of the book Building Web Services with Microsoft Azure, we delve into the capabilities of Azure Mobile Services and how it provides a quick and easy development ecosystem to develop Web APIs that support mobile apps.

(For more resources related to this topic, see here.)

Creating a Web API using Mobile Services

In this section, we will create a Mobile Services-enabled Web API using Visual Studio 2013. For our fictitious scenario, we will create an Uber-like service but for medical emergencies. In the case of a medical emergency, users will have the option to send a request using their mobile device. Additionally, third-party applications and services can integrate with the Web API to display doctor availability. All requests sent to the Web API will follow the following process flow:

1. The request will be persisted to a data store.
2. An algorithm will find a doctor that matches the incoming request based on availability and proximity.
3. Push Notifications will be sent to update the physician and patient.

Creating the project

Mobile Services provides two options to create a project:

• Using the Management portal, we can create a new Mobile Service and download a preassembled package that contains the Web API as well as the targeted mobile platform project
• Using Visual Studio templates

The Management portal approach is easier to implement and does give a jumpstart by creating and configuring the project. However, for the scope of this article, we will use the Visual Studio template approach. For more information on creating a Mobile Services Web API using the Azure Management Portal, please refer to http://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-windows-store-dotnet-get-started/.

Azure Mobile Services provides a Visual Studio 2013 template to create a .NET Web API, we will use this template for our scenario.

Note that the Azure Mobile Services template is only available from Visual Studio 2013 update 2 and onward.

Creating a Mobile Service in Visual Studio 2013 requires the following steps:

1. Create a new Azure Mobile Service project and assign it a Name, Location, and Solution. Click OK.
2. In the next tab, we have a familiar ASP.NET project type dialog. However, we notice a few differences from the traditional ASP.NET dialog, which are as follows:
   •    The Web API option is enabled by default and is the only choice available
   •    The Authentication tab is disabled by default
   •    The Test project option is disabled
   •    The Host in the cloud option automatically suggests Mobile Services and is currently the only choice

     

3. Select the default settings and click on OK.

   Visual Studio 2013 prompts developers to enter their Azure credentials in case they are not already logged in:

   

   For more information on Azure tools for Visual Studio, please refer visit https://msdn.microsoft.com/en-us/library/azure/ee405484.aspx.

   Since we are building a new Mobile Service, the next screen gathers information about how to configure the service. We can specify the existing Azure resources in our subscription or create new from within Visual Studio. Select the appropriate options and click on Create:

   

The options are described here:

Option	Description
Subscription	This lists the name of the Azure subscription where the service will be deployed. Select from the dropdown if multiple subscriptions are available.
Name	This is the name of the Mobile Services deployment, this will eventually become the root DNS URL for the mobile service unless a custom domain is specified. (For example, contoso.azure-mobile.net).
Runtime	This allows selection of runtime. Note that as of writing this book, only the .NET framework was supported in Visual Studio, so this option is currently prepopulated and disabled.
Region	Select the Azure data center where the Web API will be deployed. As of writing this book, Mobile Services is available in the following regions: West US, East US, North Europe, East Asia, and West Japan. For details on latest regional availability, please refer to http://azure.microsoft.com/en-us/regions/#services.
Database	By default, a SQL Azure database gets associated with every Mobile Services deployment. It comes in handy if SQL is being used as the data store. However, in scenarios where different data stores such as the table storage or Mongo DB may be used, we still create this SQL database. We can select from a free 20 MB SQL database or an existing paid standard SQL database. For more information about SQL tiers, please visit http://azure.microsoft.com/en-us/pricing/details/sql-database.
Server user name	Provide the server name for the Azure SQL database.
Server password	Provide a password for the Azure SQL database.

This process creates the required entities in the configured Azure subscription. Once completed, we have a new Web API project in the Visual Studio solution.

The following screenshot is the representation of a new Mobile Service project:

When we create a Mobile Service Web API project, the following NuGet packages are referenced in addition to the default ASP.NET Web API NuGet packages:

Package	Description
WindowsAzure MobileServices Backend	This package enables developers to build scalable and secure .NET mobile backend hosted in Microsoft Azure. We can also incorporate structured storage, user authentication, and push notifications. Assembly: Microsoft.WindowsAzure.Mobile.Service
Microsoft Azure Mobile Services .NET Backend Tables	This package contains the common infrastructure needed when exposing structured storage as part of the .NET mobile backend hosted in Microsoft Azure. Assembly: Microsoft.WindowsAzure.Mobile.Service.Tables
Microsoft Azure Mobile Services .NET Backend Entity Framework Extension	This package contains all types necessary to surface structured storage (using Entity Framework) as part of the .NET mobile backend hosted in Microsoft Azure. Assembly: Microsoft.WindowsAzure.Mobile.Service.Entity

Additionally, the following third-party packages are installed:

Package	Description
EntityFramework	Since Mobile Services provides a default SQL database, it leverages Entity Framework to provide an abstraction for the data entities.
AutoMapper	AutoMapper is a convention based object-to-object mapper. It is used to map legacy custom entities to DTO objects in Mobile Services.
OWIN Server and related assemblies	Mobile Services uses OWIN as the default hosting mechanism. The current template also adds: Microsoft OWIN Katana packages to run the solution in IIS Owin security packages for Google, Azure AD, Twitter, Facebook
Autofac	This is the favorite Inversion of Control (IoC) framework.
Azure Service Bus	Microsoft Azure Service Bus provides Notification Hub functionality.

We now have our Mobile Services Web API project created. The default project added by Visual Studio is not an empty project but a sample implementation of a Mobile Service-enabled Web API. In fact, a controller and Entity Data Model are already defined in the project. If we hit F5 now, we can see a running sample in the local Dev environment:

Note that Mobile Services modifies the WebApiConfig file under the App_Start folder to accommodate some initialization and configuration changes:

{
   ConfigOptions options = new ConfigOptions();
 
   HttpConfiguration config = ServiceConfig.Initialize     (new ConfigBuilder(options));
}

In the preceding code, the ServiceConfig.Initialize method defined in the Microsoft.WindowsAzure.Mobile.Service assembly is called to load the hosting provider for our mobile service. It loads all assemblies from the current application domain and searches for types with HostConfigProviderAttribute. If it finds one, the custom host provider is loaded, or else the default host provider is used.

Let’s extend the project to develop our scenario.

Defining the data model

We now create the required entities and data model. Note that while the entities have been kept simple for this article, in the real-world application, it is recommended to define a data architecture before creating any data entities.

For our scenario, we create two entities that inherit from Entity Data. These are described here.

Record

Record is an entity that represents data for the medical emergency. We use the Record entity when invoking CRUD operations using our controller. We also use this entity to update doctor allocation and status of the request as shown:

namespace Contoso.Hospital.Entities
{
  
   /// <summary>
   /// Emergency Record for the hospital
   /// </summary>
public class Record : EntityData
   {
       public string PatientId { get; set; }
 
       public string InsuranceId { get; set; }
 
       public string DoctorId { get; set; }
 
       public string Emergency { get; set; }
 
       public string Description { get; set; }
 
       public string Location { get; set; }
 
       public string Status { get; set; }
      
   }
}

Doctor

The Doctor entity represents the doctors that are registered practitioners in the area, the service will search for the availability of a doctor based on the properties of this entity. We will also assign the primary DoctorId to the Record type when a doctor is assigned to an emergency. The schema for the Doctor entity is as follows:

amespace Contoso.Hospital.Entities
{
   public class Doctor: EntityData
   {
       public string Speciality{ get; set; }
 
       public string Location { get; set; }
      
       public bool Availability{ get; set; }
      
   }
}

Summary

In this article, we looked at a solution for developing a Web API that targets mobile developers.

Resources for Article:

---

Further resources on this subject:

• Security in Microsoft Azure [article]
• Azure Storage [article]
• High Availability, Protection, and Recovery using Microsoft Azure [article]

---