Данная статья открывает серию материалов, посвященных проектированию мобильных служб, с акцентом на 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).

 

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

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

 

Параметры варианта 2
Экран 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-адрес.

 

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

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

 

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

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

Купить номер с этой статьей в PDF