Копаем глубже: Создание Windows Azure приложений

| Понедельник, 12 августа, 2013

Метки: Windows Azure Комментарии: 0

Понимание Windows Azure требует знаний базовых механизмов платформы, а также видения типичных сценариев, для которых эти базовые механизмы могут быть применены. Конечно технология намного глубже, чем кажется. Поэтому рассмотрим более тщательно некоторые интересные аспекты в разработке для Windows Azure.

Для разработчиков, построение Windows Azure приложений похоже на построение обычных Windows приложений. Так как платформа поддерживает .NET приложения и приложения с неуправляемым кодом, то разработчик волен выбрать то, что наиболее подходит решению его проблем. И чтобы сделать жизнь проще, Visual Studio предоставляет шаблоны проектов для создания Windows Azure приложений. А также можно напрямую загружать готовые приложения из Visual Studio в Windows Azure

Еще одно очевидное различие между облачным и миром физических серверов состоит в том, что приложения Windows Azure не выполняются локально. Это различие потенциально усложняет разработку. Для устранения этих сложностей, Microsoft предлагает специальную среду development fabric, которая является версией среды Windows Azure, и эта система запускается на локальном компьютере.

Development fabric может запускаться и на машине разработчика и на сервере. Эта система эмулирует функциональность Windows Azure в облаке, выполняет Web-роли, Worker-роли, VM-роли и все три вида хранилищ. Разработчик может построить Windows приложение, развернуть его в development fabric, и запустить приложение также, как и в реальной системе. Он может определить сколько экземпляров каждой роли нужно запустить, или например, использовать очереди для взаимодействия нескольких экземпляров, ну то есть можно делать все, что и на самом Windows Azure. После того как приложение разработано и протестировано локально, разработчик может загрузить код и конфигурационную информацию на Windows Azure и запустить приложение там.

Однако, даже если все выше перечисленное сделано, приложение в Windows Azure становиться доступным в облаке через процесс, состоящий из двух шагов. Разработчик загружает приложение сначала в установочную область платформы (staging area). Затем как только разработчик решает дать приложению «жизнь в миру», то через портал Windows Azure он делает запрос запустить приложение в работу. Это переключение между установочной областью (staging area) и областью выполнения рабочего приложения (production) происходит без выключения системы или перезагрузки, это дает обновлять работающие приложения на новые версии без помех для пользователей.

Установочное приложение в staging area имеет DNS имя в форме .windowazure.com, где - это глобально уникальный идентификатор который был присвоен системой Windows Azure. Для рабочей области разработчик выбирает имя DNS в том же самом домене, типа myazureservice.azurewebsites.net. Для создания другого доменного имени, отличного от Microsoft azurewebsites.net, владелец приложения может создать DNS alias, используя страндартный CNAME.

Как только приложения стало доступно извне (со всего мира), то пользователям нужен способ идентифицировать себя. Для этого Windows Azure позволяет разработчикам использовать механизм аутентификации через HTTP. Приложения ASP.NET могут использовать провайдер управления учетными записями (membership provider) для хранения данных пользователей и параметров их входа (имя, пароль). Но можно использовать и другие методы, такой как сервис Microsoft Windows Live ID. Windows Azure приложения также свободны в использовании Windows Identity Foundation (WIF) для реализации идентификации на основе заявок. Выбор полностью зависит от разработчика.