Использование 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) Алгоритм обновления токена

Push-уведомления

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

Push-уведомления подразделяются на два типа:

XML-обновления, содержащие обновленные тайлы или бейджи. Могут быть интерпретированы Windows.

Бинарные, или raw-уведомления, содержащие любые данные, которые необходимо послать – эти уведомления не могут быть обработаны Windows, так как неизвестна логика их обработки – логика должна быть реализована в клиентском приложении.

(рис 14.6) Механизм рассылки Push-уведомлений

Оба типа Push-уведомлений, как уже было сказано ранее, могут быть выполнены с помощью PushNotificationChannel. При этом для взаимодействия, например, с Windows Notification Service (WNS, сервис, обеспечивающий работу с уведомлениями и каналами), необходимо выполнить следующие шаги:

Зарегистрировать приложение в Магазине Windows (Windows Store).

Получить SID и Client Secret, значения которых будут использоваться для аутентификации в WNS.

Во время выполнения приложения запросить URL канала WNS. Серверу WNS необходимо знать информацию о получателе или получателях – это может уникальное устройство либо уникальный пользователь. Устройство (device) может быть использовано большим количеством пользователям, пользователи могут использовать несколько устройств. Эта идентификационная информация используется URL канала. Приложение должно получить URL канала у Windows API, который будет использоваться далее для коммуникаций с конкретными пользователями или устройствами. Рекомендуемым способом сохранения идентификационной информации (например, GUID устройства) является ее сохранение при первом запуске приложения в локальном хранилище и проверка при каждом последующем. При каждом запуске может происходить запрос нового URL канала (несмотря на то, что URL канала имеет срок "жизни", равный 30 дням, операция запроса нового URL достаточно легковесна и может быть использована вместо реализации логики обновления) и аутентификация пользователя.

Скрипты на стороне сервера конфигурируются с помощью портала управления либо Visual Studio (в новых версиях) и используют в качестве собственного бэкенда виртуальную машину с процессом Node.js – разработчик может использовать модули, например:

Request – для работы с HTTP-запросами

Push.* - для инкапсуляции всей работы с Push-нотификациями со всеми популярными сервисами APNS, GCM, WNS, MPNS

Console – для логирования

MSSQL – для выполнения собственных T-SQL запросов и выполнения хранимых процедур

statusCodes – возврат HTTP-кодов

Azure – для получения доступа к другим сервисам Azure - Windows Azure Storage, Service Bus и др.

Sendgrid – для посылки почты

Twilio – посылка SMS-сообщений и Voice Mail

Функциональной обвязкой для REST API является автоматически генерируемый набор скриптов, перехватывающий запросы к таблице 4-х основных типов. Так как мобильные сервисы работают на базе Node.js, то и скрипты пишутся на Node.js. По умолчанию эти скрипты работают в режиме Pass-through, то есть перехватывают запрос и переводят его в источник данных (SQL Azure Databases) в том же виде, в каком он пришел на сервер. Это поведение является настраиваемым – от самой простой логики, например, валидации пришедших в запросе данных, до более сложной, включающей, например, работу с источником данных.

Одной из новых функций стала внедренная летом 2013 года интеграция Git-based систем контроля версий для серверных скриптов. Эта интеграция предоставляет возможность локального редактирования скриптов (например, в Visual Studio) – изменения попадают в локальный репозиторий Git, который синхронизирует свое состояние с сервером.

Подробная информация про скрипты на стороне сервера находится на MSDN: http://msdn.microsoft.com/en-us/library/windowsazure/jj554226.aspx

(рис 14.7) Скрипт-перехватчик операции Insert

Планировщик задач

В сервисе Windows Azure Mobile Services есть собственный планировщик задач, полезный в тех сценариях, когда необходимо определить код на стороне сервера, который должен выполняться по расписанию, определенному разработчиком. Помимо других предложений планировщиков задач (например, реализации планировщика задач с помощью Cloud Services или Cloud Based CRON Scheduler), Windows Azure Mobile Services Scheduler является интегрированным в платформу средством, с помощью которого можно реализовывать такие задачи, как, например, периодическое обновление и сохранение данных из внешних и внутренних сервисов.

Выполнение кода возможно по следующим временным промежуткам:

Раз в X минут

Раз в Y часов

Раз в M дней

Раз в N месяцев

Где переменная может быть равна тем значениям, которые заданы для каждого промежутка, например, для месяцев это могут быть значения 1, 2 и 3.

(рис 14.8) Создание задачи в планировщике

Примеры использования планировщика Windows Azure Mobile Services:

Удаление устаревших данных из хранилища

Получение данных из внешних источников

Обработка файлов, например, изображений

Отправка Push-уведомлений по расписанию

Диагностика мобильных сервисов

Перед тем, как начинать анализировать возникающие проблемы с любым из сервисов Windows Azure, необходимо узнать, нет ли глобальных проблем с этими сервисами. Платформа предоставляет сервисную панель http://www.windowsazure.com/en-us/support/service-dashboard/, на которой в исторической перспективе можно увидеть состояние и "здоровье" сервисов. Windows Azure Mobile Services не являются исключением – отправной точкой для диагностики должна быть именно эта панель.

(рис 14.9) Часть Windows Azure Dashboard

Для каждого из мобильных сервисов также доступна собственная диагностическая оснастка, которая показывает, сколько было вызовов API, сколько процессорного времени они заняли, а также сколько было исходящего трафика. Разработчик может логировать действия с помощью объекта console, например, console.error() или console.log(). Неоценимую помощь в диагностике оказывают такие средства, как NetMon (Microsoft Network Monitor), WireShark и Fiddler. Для эффективной диагностики необходимо понимать основы архитектуры разрабатываемой с использованием Windows Azure Mobile Services системы – так, в любой архитектуре будет наличествовать два слоя – серверная логика (мобильный сервис) и клиентская (приложение-клиент). После создания мобильного сервиса клиенту становится доступна точка входа HTTPS, на которую клиент может отправлять запрос одного из пяти типов (аутентификация и четыре запроса на взаимодействие с данными). Поэтому, рассматривая проходящий трафик с помощью одной из вспомогательных утилит, необходимо обращать внимание на HTTP-коды, приходящие с сервера. Так, если с сервера приходит код 401, это означает, что запрос имел проблему с аутентификацией – в этом случае необходимо проверить, есть ли соответствующие разрешения на таблице, к которой осуществляется доступ. Если данные были успешно возвращены, то проблема может располагаться на клиентской стороне – необходимо проверить, что происходит с пришедшими данными, каким образом приводятся типы и т.д.

Рассмотрим на примере использование Fiddler.

Создадим таблицу в уже готовом мобильном сервисе.

(рис 14.10) Панель управления Windows Azure Mobile Services

Скопируем URL мобильного сервиса с панели Dashboard. С помощью тестового приложения в таблицу были добавлены несколько записей.

(рис 14.11) Информация о мобильном сервисе

Запустим Fiddler и нажмем F12 для выключения постоянной "прослушки" траффика. Введем URL мобильного сервиса в поле адреса и нажмем Execute. Обратим внимание, что сервер возвратил код 401, то есть ошибку аутентификации.

(рис 14.12) Запрос к сервису с помощью Fiddler

Изменим права доступа к таблице TodoItem. Для этого перейдем на вкладку Data и, нажав на имя таблицы, изменим права доступа на операцию чтения на Everyone.

(рис 14.13) Права на операции к таблице todoitem

Вернемся в Fiddler и выполним еще раз ту же операцию.

(рис 14.14) Запрос к сервису с помощью Fiddler

Собственный код (Custom API)

Как уже говорилось ранее, мобильный сервис автоматически генерирует REST API, состоящее из четырех обработчиков основных операций, для каждой таблицы в хранилище. Однако подобный подход накладывает серьезное ограничение на гибкость создаваемого решения – если разработчику необходимо переложить логику на серверную сторону, но эта логика не относится ни к одной из таблиц в хранилище, то использование автоматически генерируемых REST API приведет к лишним операциям с хранилищем. Летом 2013 года была анонсирована новая возможность, которая позволяет решить эту проблему – Custom Code, или собственный код. Собственный код также является автоматически генерируемым REST API для четырех основных операций, однако не привязан к конкретной таблицей, являя собой, таким образом, часть системы, на которую можно переложить некоторую логику, не задействуя при этом таблицы в хранилище мобильного сервиса. Программирование собственного кода аналогично программированию серверных скриптов для REST API, автоматически генерируемого для таблиц хранилища мобильного сервиса.

Поддержка Git и новые инструменты Visual Studio 2013

В Visual Studio 2013 появилась прямая интеграция Server Explorer с мобильными сервисами и другими сервисами Windows Azure. Подобная интеграция позволяет использовать инструменты IDE для редактирования и управления серверными скриптами мобильного сервиса.

(рис 14.15) Редактирование скриптов в Visual Studio 2013

Вторым вариантом локального редактирования серверных скриптов является помещение скриптов в репозиторий Git, производящий синхронизацию локальной копии скриптов с их состоянием в мобильном сервисе.

Масштабирование мобильного сервиса

Масштабирование мобильного сервиса осуществляется на портале управления Windows Azure на вкладке Scale мобильного сервиса. Разработчик может производить масштабирование для вычислительных ресурсов и хранилища базы данных.

Так, для вычислительных ресурсов мобильного сервиса доступно три уровня использования:

Free. На данном уровне разработчик имеет 10 мобильных сервисов бесплатно, но ограничен малым количеством вызовов API (до 500 000), количеством задач планировщика (в час может быть выполнена только одна задача), а также количеством активных подключенных устройств. Также на уровне Free недоступны опции масштабирования.

Standard. На данном уровне разработчик оплачивает каждый из мобильных сервисов, но доступное количество вызовов API увеличено до 1.5 млн. на мобильный сервис, количество задач планировщика увеличено до 10 единиц, в час может быть выполнено 50 тысяч раз. Мобильный сервис уровня Standard может быть масштабирован до 6 единиц.

Premium. На данном уровне разработчик оплачивает каждый из мобильных сервисов, доступное количество вызовов API увеличено до 15 млн., количество задач равно 10 единицам, в час может быть выполнено 500 тысяч раз. Мобильный сервис уровня Premium может быть масштабирован до 10 единиц.

Переход на другой уровень осуществляется на панели управления мобильным сервисом. На уровнях Standard и Premium доступны дополнительные опции, такие как автомасштабирование согласно нагрузке, и ручное изменение количества экземпляров, выполняющих мобильный сервис. Также мобильный сервис интегрирован с сервисом Windows Azure SQL Databases, что означает возможность изменения уровня базы данных с облегченной версии Web на Business с соответствующим увеличением максимального размера базы данных (до 150 гб).

(рис 14.16) Маштабирование мобильного сервиса

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

(рис 14.17) Конфигурация сервисов Push-уведомлений для различных платформ

На панели управления мобильным сервисом также доступны тестовые приложения под все поддерживаемые платформы, уже преднастроенные для использования хранилища Windows Azure Mobile Services.

(рис 14.18) Панель управления мобильным сервисом – тестовые приложения

Заключение

Сервис Windows Azure Mobile Services предоставляет единый бекэнд для приложений, работающих на всех мобильных платформах (плюс Windows 8), состоящий из четырех функциональных механизмов: аутентификации, хранилища данных, планировщика задач и уведомлений. Разработчику достаточно настроить мобильный сервис и, при необходимости, интегрировать его с соответствующими сервисами Google и Apple (например, для обеспечения Push-уведомлений). Windows Azure Mobile Services являются сервисом, способным осуществлять автоматическое и ручное масштабирование.

Страницы: