Цель лекции: Ознакомление с разработки облачных приложений для Windows Azure средствами Visual Studio.NET 2010.
Презентацию к данной лекции Вы можете скачать здесь.
Разработка облачных приложений, по сравнению с разработкой обычного консольного или Windows-приложения, является нетривиальной задачей, ввиду сложности архитектуры приложения и всей облачной системы Windows Azure. Приложение фактически представляет собой Web-сервис, который должен быть опубликован и развернут в облаке.
Разработчикам Visual Studio 2010, тем не менее, удалось обеспечить столь удобную поддержку разработки облачных приложений, что она по сложности почти не отличается от разработки обычных приложений. Всю техническую работу по генерации большого объема рутинного кода и конфигурационных файлов, перекачке файлов на сайты облака и т.д. Visual Studio берет на себя.
Следует иметь в виду, что, в отличие от использования Windows Azure (которое может быть осуществлено с любого компьютера с Web-браузером), разработка приложений для Windows Azure предъявляет весьма высокие требования к компьютеру, операционной системе и рабочему окружению разработчика. Например, разработка облачного приложения для более ранних версий Windows, чем Windows Vista, в настоящее время (осень 2011 г.) невозможна. Даже к Windows Vista для этого необходимо установить Service Pack 1. Наиболее предпочтительна разработка облачного приложения на компьютере с Windows 7, которая и рассмотрена в лекции в качестве примера. Кроме ОС, для разработки необходимо инсталлировать на компьютер разработчика значительный объем программного обеспечения, точная спецификация которого опубликована на сайте windows.azure.com.
Итак, для разработки облачного приложения необходимо запустить Visual Studio 2010, причем в специальном режиме – от имени администратора (рис. 10.1).
(рис 10.1) Запуск Visual Studio 2010 от имени администратора
Следующий шаг – правильный выбор типа проекта. В Visual Studio 2010 предусмотрен специальный тип проекта – Windows Azure Project, который и следует выбрать (рис. 10.2).
(рис 10.2) Создание проекта типа Windows Azure Project
Теперь необходимо выбрать Web-роль для разрабатываемого облачного приложения, т.е. определить, чем именно будет (какую роль будет играть) новое облачное приложение. Выбираем роль Cервис с пользовательским Web-интерфейсом (рис. 10.3).
(рис 10.3) Выбор ASP.NET Web-роли
Разработаем основную ASP.NET – страницу нашего приложения, используя готовый шаблон ее кода (рис. 10.4). Напомним (см. лекцию 4), что в .NET Web-сервис представляется ASP.NET – страницей, файл которой имеет расширение .aspx. В ASP.NET – странице указывается ее заголовок, язык, на котором она разработана, а также ссылка на так называемый Code-behind – файл кода на языке реализации C#, содержащий методы обработки событий, связанных с ASP.NET – страницей. Такое разделение на файл спецификации пользовательского интерфейса страницы и на файл его реализации удобно и соответствует принципам модульного программирования. Назначение этой простой ASP.NET - страницы в том, что она выдает заданный текст –
(рис 10.4) Редактирование основной страницы облачного приложения
После набора и редактирования исходного кода ASP.NET – страницы в VS 2010, необходимо выполнить сборку (build) проекта. Рекомендуемый авторами Azure способ сборки в данном случае – выбор пункта Debug / Start without debugging (рис. 10.5).
(рис 10.5) Сборка облачного приложения в Visual Studio 2010
После сборки облачного приложения, в целях его отладки, рекомендуется, до публикации его в облаке, запустить его локально на компьютере разработчика. Поскольку при этом не используется и вообще недоступно реальное облако, оно эмулируется на локальной машине. По времени все это происходит достаточно долго (несколько минут), поэтому не удивляйтесь. При этом будут выдаваться интересные сообщения о загрузке и запуске эмулятора, и.т.д. Следите за событиями на экране.
В результате данной фазы разработки создается Web-страница на локальной машине (IP-адрес которой, как известно, равер условному значению 127.0.0.1), и данная Web-страница интерпретируется браузером, визуализируя текст нашего сообщения
(рис 10.6) Запуск облачного приложения на машине разработчика, с эмуляцией облака
Теперь, для того, чтобы облачное приложение можно было вызывать извне (через Web), по URL-адресу, который был бы автоматически присвоен приложению интегрированной средой VS 2010 и (или) средствами Windows Azure, - приложение должно быть опубликовано в облаке как общедоступный Web-сервис. Публикация информации о разработанном приложении производится в особых форматах, детали которых, однако, разработчику знать не требуется, так как файлы для представления пакета в облаке автоматически генерируются средой VS 2010. Разработчик должен помнить только имя своего проекта (решения – solution) Visual Studio и место его расположения на локальных дисках. Причем последнее подсказывает ему среда: после сборки проекта среда Visual Studio выводит на экран директорию, где она разместила пользовательский проект, и рекомендует пользователю (разработчику приложения) эту директорию запомнить. На рис. 10.7 представлен этап publish (публикация), на котором разработчик приложения выбирает и сообщает среде VS 2010 директорию, где находится его проект WindowsAzureProject3, и выбирает пункт контекстного меню Publish (опубликовать). Вот и все, что требуется от разработчика, чтобы выполнить сложнейшие действия по публикации разработанного им приложения в облаке! Не могу удержаться от комментария, что это уже похоже на магические действия волшебника, который запускает в небо новую планету. Или на запуск спутника или космического корабля. Поэтому подобные возможности доставляют ценителям программных архитектур и сред, включая автора, истинное наслаждение. Так запустите же Вашу звездочку на небо – разработайте свое облачное приложение и опубликуйте его в Azure!
(рис 10.7) Публикация приложения в облаке средствами Visual Studio
Следующий этап разработки – развертывание (deployment) приложения в облаке. В простейшем варианте, как в рассматриваемом примере, развертывание – это создание пакета специального формата, в который упаковывается информация о приложении. Данный случай рекомендуется выбирать путем выбора пункта Create Service Package Only в окне "Deploy Windows Azure Project" (рис. 10.8).
(рис 10.8) Развертывание приложения в облаке
При развертывании необходимо указать, из какой директории (расположенной на локальной машине) фактически происходит развертывание сервиса (рис. 10.9). Фактически развертывание означает, что теперь разработанное облачное приложение (как сервис) доступно в Web. Вот истинное воплощение принципа Software as a Service (SaaS)!
(рис 10.9) Поиск и указание директории, из которой происходит развертывание
Работоспособность развернутого в облаке приложения можно проверить средствами Azure AppFabric, выбрав пункт Работоспособность развернутого приложения. Выдается информация о типе развертывания и состоянии развернутого приложения (рис. 10.10). Выдаются также важные для пользователя предупреждения, например, о том (как в данном примере), что на каждую роль имеется только по одному экземпляру приложения. Говорится также о том, что надежность сервиса – не стопроцентная, поэтому рекомендовано дублировать функции, т.е. иметь на каждое необходимое приложение как минимум по две роли. Напомним, что роль – это ¬процесс, в котором исполняется приложение. Не будем забывать о том, что это – серверный код, и число запросов к сервису может быть очень велико, т.е. возможны отказы. Чтобы уменьшить риск отказов, и рекомендуется иметь как минимум две роли на каждое (серверное) приложение.
(рис 10.10) Отслеживание развернутого приложения в облаке с помощью Azure AppFabric
Если не хватает ресурсов текущей подписки, приходится удалять второе развернутое приложение (в данном примере – приложение safonov-test2, рис. 10.11).
(рис 10.11) Удаление предыдущего развернутого приложения (при нехватке ресурсов)
Затем при необходимости, после освобождения ресурсов, облачное приложение можно развернуть повторно (рис. 10.12).
(рис 10.12) Повторное развертывание приложения в облаке
При (повторном) развертывании необходимо выбрать область (регион) – см. рис. 10.13.
(рис 10.13) Выбор области для развертывания
После этого создаем новый размещенный сервис (рис. 10.14), указав его имя, которое станет частью его уникального URL-адреса.
(рис 10.14) Создание URL-адреса облачного сервиса
Как и в предыдущем примере, теперь публикуем в облаке сервис safonov-test3 (рис. 10.15).
(рис 10.15) Скачивание сервиса в облако с локальной клиентской машины
Задаем имя развернутого приложения, которое становится частью его URL-адреса (рис. 10.16).
(рис 10.16) Указание имени развернутого приложения
Теперь активизируем Web-роль (т.е. процесс для обслуживания) развернутого, разработанного нами Web-сервиса (рис. 10.17). Состояние занято указывает, что в текущий момент еще происходит перекачивание сервиса в облако.
(рис 10.17) Активизация Web-роли для развернутого приложения
Теперь, когда сервис развернут, необходимо найти его URL-адрес для запуска через браузер, как любой другой Web-страницы. Обращаемся к пункту Размещенные службы Azure AppFabric. URL-адрес указывается в правой части визуализируемой страницы.Копируем его обычным образом, через механизм copy / paste (рис. 10.18).
(рис 10.18) Поиск URL-адреса развернутого приложения
Запускаем новый, развернутый в облаке Web-сервис и видим привычное изображение активизированной страницы с нашим сообщением (рис. 10.19). Однако теперь мы достигли качественно иного этапа: это наше (первое) облачное приложение, которое можно использовать как часть доступных в облаче Azure сервисов.
(рис 10.19) Запуск приложения из облака по URL-адресу
Копирование URL-адреса нашего сервиса выполняем через AppFabric, через пункт контекстного меню copy (рис. 10.20).
(рис 10.20) Копирование URL-адреса из облака в браузер
Запускаем браузер и выполняем paste в его строку URL-адреса. Работает! (рис. 10.21).
(рис 10.21) Запуск приложения по его URL-адресу, взятому из облака
Отслеживаем запущенное облачное приложение через AppFabric (рис. 10.22).
Наш пример завершен.
(рис 10.22) Отслеживание запущенного облачного приложения
Мы подробно рассмотрели в данной лекции, каким образом может быть разработано простое облачное приложение, каким образом оно публикуется в облаке и затем используется.
Если бы подобный пример рассматривался лет 20-25 назад, слушатели сочли бы это за научную фантастику.
Желаю Вам успеха в разработке, публикации и распространении Ваших облачных приложений в Windows Azure!
Проект – единица разработки программ в Visual Studio.
Сборка (build) – компиляция проекта в бинарный код.
Публикация проекта – создание конфигурационных файлов для его последующего развертывания в облаке.
Развертывание сервиса – перекачивание информации о нем на компьютеры облачного ЦОД.
Visual Studio 2010 – основной инструмент разработки облачного ПО для Azure. Для разработки требуется инсталляция большого объема инструментов на компьтере разработчика. Основные этапы разработки: создание проекта типа Azure service; сборка проекта; публикация проекта; локальная отладка сервиса на машине разработчика; развертывание сервиса; исполнение сервиса.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.