Использование Windows Azure Mobile Services

Использование Windows Azure Mobile Services в качестве бэкенда для мобильных приложений и приложений Магазина Windows

Сервис Windows Azure Mobile Services предлагает облачную инфраструктуру для популярных мобильных платформ: Windows 8, Windows Phone, iOS и Android. На основе сервиса Windows Azure Mobile Services можно построить облачный бэкенд, на который будут перенесены задачи по хранению данных, аутентификации и Push-уведомлений.

Сервис Windows Azure Mobile Services не является конструктором – с помощью Windows Azure Mobile Services нельзя создать готовое приложение. Windows Azure Mobile Services - это набор функциональности, которая дополняет уже готовое (или новое, если приложение только разрабатывается) приложение возможностью, например, аутентифицировать пользователей с помощью Facebook. В приложении нет необходимости реализовывать логику непосредственно процесса аутентификации – достаточно использовать уже готовое API Windows Azure Mobile Services и перевести пользователя на страницу входа в систему Facebook. Таким образом, сервис Windows Azure Mobile Services предоставляет набор функциональности, который могут быть использованы для дополнения, но не создания приложения. С помощью Mobile Services Windows Azure значительно упрощается выполнение стандартных задач разработки, таких, как интеграция push-уведомлений и настройка аутентификации пользователя.

Сценарии использования Mobile Services

Сохранение данных в облаке

Windows Azure Mobile Services предоставляет возможность хранения структурированных данных в облаке. Такой сценарий возникает, когда необходимо хранить простые данные, но разворачивать для этой задачи дополнительный сервер может быть слишком затратно (например, известно, что данных будет немного). На каждую из операций из набора CRUD можно ассоциировать соответствующее действие на стороне сервера – например, на операцию Insert, пришедшую со стороны клиента, можно ответить Push-уведомлением клиента о том, что операция прошла успешно. По умолчанию в хранилище Windows Azure Mobile Services включена динамическая схема, позволяющая расширять схему таблицы в любой момент – так, если добавляется сущность с полем, которого не было в таблице, это поле добавляется в таблицу, схема расширяется, все же сущности, у которых не было ранее этого поля, получают значение 0. Динамическую схему рекомендуется отключать при окончании процесса тестирования приложения.

увеличить изображение
Рис. 14.1. Хранилище Windows Azure Mobile Services

После создания таблицы разработчик может импортировать ее в приложение и далее взаимодействовать с ней с помощью LINQ. В качестве общего механизма для обеспечения структурированного хранилища Windows Azure Mobile Services может быть использована новая или уже существующая база данных Windows Azure SQL Database. Для доступа к базе данных из скриптов на стороне сервера в Windows Azure Mobile Services внедрен специальный объект mssql, использующийся для выполнения запросов T-SQL к базе данных:

Mssql.query('select top 10 * from intuittable', {
Success: function(results) {
Console.log(results);
}
});

Однако бывают ситуации, когда использование объекта mssql в его исходном виде может быть осложнено – например, для аналогичной хранимой процедуре реализации. Используемый mssql T-SQL синтаксис дает возможность выполнить хранимую процедуру в базе данных:

function updateEntity(parameter)
{ var parameter = [parameter];
Var sql = "exec intuitdb.StoredProcedureForUpdate ?";
Mssql.query(sql, parameter,
{
Success: function(results) {
... .
}}}

увеличить изображение
Рис. 14.2. Создание Mobile Service

Любая база данных, таким образом, может использоваться в мультитенатном режиме – например, несколько созданных сервисов Windows Azure Mobile Services могут использовать одну базу данных SQL.

Аутентификация

С помощью сервиса Windows Azure Mobile Services разработчик может интегрировать в свое приложение аутентификацию с использованием как популярных провайдеров аутентификации, так и настраиваемых. Таким образом разработчик абстрагируется от низлежащих деталей реализации взаимодействия с провайдерами аутентификации – всем процессом по обмену аутентификационными данными и непосредственно самим процессом управляет Windows Azure Mobile Services.

Рис. 14.3. Доступные для конфигурации провайдеры аутентификации

Подсервис аутентификации может быть интегрирован с подсервисом хранилища – так, разработчик может назначить одну из опций на каждую из операций с хранилищем. Доступны следующие опции аутентификации каждого из запросов на операцию:

• Everyone: данная опция означает, что запрос на операцию будет одобрен от любого источника. Любой клиент сможет модифицировать хранящиеся в Windows Azure Mobile Services данные.
• Anybody with the Application Key: запрос на операцию будет одобрен только для того клиента, у которого есть корректный ключ.
• Only Authenticated Users: запрос на операцию будет одобрен только для аутентифицировавшихся клиентом.
• Only Scripts and Admins: запрос на операцию будет одобрен только для выполняющихся на стороне сервера скриптов и администраторов мобильного сервиса.

Рис. 14.4. Права на операции с таблицами

Как уже говорилось ранее, весь процесс коммуникаций с провайдером аутентификации берет на себя движок мобильных сервисов. В процессе коммуникаций мобильный сервис получает специальный пакет, который называется токеном безопасности – этот пакет отдается провайдером в результате успешной аутентификации клиента, и содержит в себе набор информации, специфичный для каждого провайдера – например, идентификатор пользователя, E-Mail и т.д. Данный токен безопасности действует в течение некоторого времени. Разработчик может кэшировать этот токен, сохраняя его данные в хранилище, изолированном для конкретного экземпляра приложения (для WinRT это, например, PasswordVault), и использовать закэшированный токен для того, чтобы при следующем запуске автоматически определить аутентифицировавшегося ранее пользователя, и не спрашивать учетные данные снова. Разумеется, учитывая период жизни токена, его необходимо периодически обновлять – для этого надо постоянно проверять, что возвращается мобильным сервисом в ответ на посылаемые запросы – в том случае, если мобильный сервис возвращает код ответа 401 Unauthorized, необходимо снова предложить пользователю аутентифицироваться и повторить процедуру кэширования токена.

Рис. 14.5. Алгоритм обновления токена