Azure SQL как основа мобильной службы Azure

Данная статья открывает серию материалов, посвященных проектированию мобильных служб, с акцентом на Microsoft Azure. Мы подробно рассмотрим структуру мобильных служб Azure, а также технологии, используемые при построении кросс-платформенных мобильных решений.

Эти статьи будут полезны ИТ-специалистам, архитекторам и разработчикам. В первой статье серии рассматривается процесс принятия решений, который должен предшествовать построению мобильной службы Azure, различные платформы, доступные для выбора, и полный вид окончательного решения.

Мобильные службы Azure начинаются на серверной стороне

Подготовка решения для мобильной службы Azure начинается с проектирования серверного компонента. Нажмите New, Compute, Mobile Service, Create, чтобы увидеть внутреннюю службу, настроенную для запуска Windows Azure. Это фундамент вашего проекта (см. экран 1).

Экран 1. Создание службы

Затем требуется сделать следующее (см. экран 2):

• идентифицировать и указать местоположение «облачной» службы [1];
• определить, следует задействовать новую базу данных, существующую или же совершенно новый экземпляр Azure SQL [2];
• решить, какая подписка Azure будет использоваться для выставления счетов [3];
• указать местонахождение центра обработки данных, где будут предоставлены эти элементы (более подробно об этом рассказано ниже) [4];
• определить, следует ли строить серверный компонент с использованием инфраструктуры. NET или JavaScript [5];
• решить, нужно ли настроить дополнительные параметры для push-уведомлений, если вы предпочтете воспользоваться ими [6].

Экран 2. Задание настроек службы

В этой статье мы в основном уделим внимание элементам 2 и 4, хотя в конце все они будут сведены в единую картину.

Рассмотрим, как ваши решения отразятся на базе данных. Одно из первых следствий показано на экране 3.

Экран 3. Новые варианты баз данных

Это три варианта, предоставляемые вам при подготовке базы данных. Первый выглядит неплохо — по крайней мере, он бесплатный. Проблема в том, что сделать этот выбор можно лишь однажды, так как вы получаете только одну бесплатную базу данных на 20 Мбайт для подписки (см. экран 4).

Экран 4. Параметры варианта 1

Но если я сделаю иной выбор, как показано на экране 5, то получу другой результат. Обратите внимание, что предупреждение исчезло.

Экран 5. Параметры варианта 2

Это ограничение можно обойти, используя несколько идентификаторов Live ID (адресов электронной почты) и оформив заявку на несколько бесплатных пробных попыток.

Таким образом я прихожу к двум другим вариантам: можно использовать существующую базу данных или создать новый экземпляр базы данных SQL на имеющемся сервере.

Однако есть еще одна проблема, относящаяся к местоположению мобильной службы. Если вы намерены задействовать существующую базу данных, необходимо согласовать ваш выбор с ее местоположением (см. экран 6).

Экран 6. Выбор местоположения базы данных

В зависимости от вашего выбора и перечисленных выше факторов Azure выдаст предупреждение (см. экран 7).

Экран 7. Предупреждение о разных местах расположения

Итак, даже прежде чем подготовить наши мобильные службы Azure, мы обнаружили некоторые ограничения в выборе. Тому есть веские причины: мы хотим сохранить нашу базу данных и «облачную» службу, которая в конечном итоге будет обмениваться с ней данными в одном центре обработки данных. Таким образом, если позднее мы придем к выводу о необходимости масштабирования (еще одна тема для обсуждения), то сможем правильно выстроить архитектуру. В итоге я сделал выбор, показанный на экране 8, так как хотел ограничить демонстрационную лабораторию одним регионом и одной подпиской.

Экран 8. Настройка выбранного варианта

Я выбрал существующий экземпляр SQL Server и привязал мобильную службу к соответствующему региону, так что мне нужно выбрать для использования эту базу данных. Обратите внимание, я выбираю базу данных с именем FabianPlayPenDB на сервере, который по очевидным причинам затушеван. Кроме того, нужно указать имя для входа пользователя и пароль (см. экран 9).

Экран 9. Указание учетных данных

При создании SQL Azure Database Server необходимо предоставить имя учетной записи и пароль с правами пользователя-владельца базы данных (DBO) и системного администратора. Вы можете — и должны — придумать другие имена входа для доступа к разнообразным базам данных, которые будет создавать.

Что же это означает в случае мобильной службы Azure и, в частности, данного примера? Это означает, что пример проекта, созданный для вас в качестве начального, должен иметь возможность построить таблицу в базе данных SQL Azure. Это будет таблица, состоящая из элементов списка To Do (неотложных дел). Начальный проект и все его ресурсы и зависимости создаются для вас независимо от шаблона или платформы, выбранных для создания мобильной службы Azure.

Важно отметить, что структура мобильной службы Azure, а также ваш способ взаимодействия с порталом, зависят от выбора, сделанного на экране 10.

Экран 10. Выбор языка взаимодействия

Как будет показано далее, я остановился на серверном компоненте. NET. Мой выбор объясняется тем, что я знаю язык C# значительно лучше, чем JavaScript, а кроме того JavaScript относится к клиентской стороне. В итоге в портале вы получаете инструменты, которые можно запускать в браузере, что напрямую влияет на мобильную службу Azure. С другой стороны, в силу специфики моего выбора мне потребуется использовать интегрированную среду разработки и скомпилированный управляемый код.

Наконец, выбрав свои варианты, вы сможете передать их Azure, после чего для вас будет создана мобильная служба Azure (см. экран 11).

Экран 11. Создание мобильной службы

Вы сразу же заметите (см. экран 12), что идет процесс подготовки службы. Портал сообщает о ходе выполнения работы, а после завершения служба занимает свое место среди прочих в вашей подписке.

Экран 12. Процесс подготовки службы

После того как вы создали мобильную службу, появится экран 13.

Экран 13. Начало работы с мобильной службой

Теперь нам нужно научиться взаимодействовать со службой. Начнем действовать в соответствии с номерами шагов на экране 13.

1. После того, как создана мобильная служба Azure, отображаемое имя является частью универсального кода ресурса (URI) для «облачной» службы, размещенной на Azure, который указывает на этот экземпляр.
2. Существуют настраиваемые и отчетные области; подробнее о каждой из них будет рассказано позже. Пока достаточно отметить, что вы сможете сразу увидеть всю информацию через панели мониторинга; планировщик позволяет создавать задания, выполняемые в мобильной службе, которые могут влиять на сохранение данных в базе данных или представляют собой просто логические проверки; можно отправлять push-уведомления через Push; можно разрешить только авторизованные номера входа через вкладку Identity из Social Applications и Windows Azure Active Directory; можно дополнительно настраивать, масштабировать и управлять входом в мобильные службы из трех других вкладок на панели инструментов.
3. Как отмечалось выше, вы можете выбрать платформу: Windows, iOS, Android, HTML/JavaScript или Xamarin. В этой серии статей мы остановимся на Xamarin.
4. В разделе Get Started («Начало работы») можно:

a) создать новое приложение согласно выбору, сделанному на шаге 3;

b) подключиться к существующему приложению, выбранному на шаге 3.

Мы располагаем, в сущности, очень простым приложением списка неотложных дел, но на самом деле в нем есть все, что нужно знать, и содержится большое количество полезных конструкций и образцового кода. Если вы нажмете клавишу F5 в среде Visual Studio, то сразу же получите функциональное приложение. Невозможно переоценить, сколько это позволяет сэкономить усилий, которые необходимо затратить на освоение мобильных служб Azure.

Доверяй, но проверяй

Теперь, как отмечалось выше, серверным компонентом будет база данных SQL в SQL Azure. Проверить это можно двумя способами. Во-первых, убедиться в существовании базы данных, во-вторых — воспользоваться порталом Azure для взаимодействия с базой данных (см. экран 14).

Экран 14. Взаимодействие с базой данных в портале

Таким образом, мы получили базу данных FabianPlayPenDB в регионе East U.S. с именем сервера, которое затушевано, с использованием выпуска Basic и максимальной информационной емкостью 2 Гбайт. На данном этапе портал Azure обеспечивает средства для взаимодействия и управления этой базой данных из браузера (см. экран 15). Все, что нужно сделать для доступа к ней — предоставить учетную запись с необходимыми правами; затем вы сможете выполнить любую задачу RDMS по своему желанию. Можно, как я делаю время от времени, расширить пример, добавив к схеме базы данных столбцы, помимо двух имеющихся в примере To Do. Или создать собственные таблицы (см. экран 16).

Экран 15. Взаимодействие в браузере

Экран 16. Создание таблиц

Как показано выше, из этого портала открывается доступ ко многим возможностям. Однако, если вы, как и я, привыкли использовать среду Management Studio, обеспечиваемую SQL Server, то ее можно задействовать для доступа к базе данных Azure SQL. Но соблюдайте осторожность: при наличии экземпляра SQL Azure доступ ограничивается правилами брандмауэра.

При попытке доступа к SQL Azure из браузера или из среды SQL Management Studio, как показано на экране 17, необходимо иметь действующее правило брандмауэра; если оно отсутствует, от системы будет получено предупреждение. Если вы имеете доступ и зарегистрированы в портале Azure, то получите запрос для создания правила брандмауэра. Достаточно нажать Yes, и система добавит ваш IP-адрес.

Экран 17. Доступ из среды SQL Management Studio

Важно, что в этой базе данных вы не увидите упоминаний о таблице To Do для данного экземпляра Azure Mobile. Она создается при первом запуске мобильного приложения благодаря программному коду для заполнения базы данных. Он выглядит примерно так, как показано на экране 18.

Экран 18. Пример программного кода для заполнения базы данных

В следующей статье мы рассмотрим весь процесс формирования приложений от начала до конца.