Получение данных в приложение через сервисы становится все более популярным. На Windows это чаще всего означает реализацию таких сервисов на базе Windows Communication Foundation (WCF). А в связи с тем, что логика таких сервисов очень часто может быть представлена в виде рабочих потоков, существует возможность реализовывать WCF-сервисы с помощью Windows Workflow Foundation (WF).
Но возникает вопрос, где все эти сервисы должны запускаться? Ни WCF ни WF не требуют наличие определенного хост-процесса, так что разработчики могут использовать их так как посчитают нужным. Однако, создание эффективного и управляемого хоста не такая простая задача. Было бы гораздо легче, если бы Windows Server предлагал больше поддержки для и управления этими сервисами.
И это именно то, что предлагает сервис AppFabric Hosting Services. Для того, чтобы лучше понимать эту часть Windows Server AppFabric было бы полезным сначала быстро пробежаться по базовым технологиям WCF и WF.
Основы технологии
WCF предлагает общий путь для создания и потребления сервисов. WF предлагает поддержку создания бизнес-логики в виде рабочих потоков. Так как рабочие потоки WF обычно используют сервисы для взаимодействия с внешним миром, мы начнем именно с WCF для описания этих двух технологий.
Создание сервисов: Windows Communication Foundation
WCF позволяет разработчику создавать и использовать различные типы сервисов — SOAP, RESTful и другие — через общую программную модель. Рисунок 1 показывает основы:
Рис.1. Схема WCF-сервисов
С помощью Visual Studio (или другого инструмента) разработчик может реализовать сервис, который способен предложить любой функционал. Такой сервис становится доступным для клиентов через одну или более конечных точек (endpoints), каждая из которых предоставляет определенный интерфейс (так же известный как контракт).
Сервис обычно разделяет свои функции на некоторое число операций, каждая из которых отвечает за тот или иной аспект бизнес-логики. Например, сервис реализующий приложение для электронной коммерции может иметь операции для создания корзины, добавления предмета в корзину, удаление предмета, оплаты покупки и так далее. Клиент этого сервиса вызывает каждую из операций по мере надобности.
Создание рабочих потоков: Windows Workflow Foundation
Как разработчикам следует реализовать сервис? В некоторых случаях операции сервиса могут быть независимы друг от друга, например в сервисе, который предлагает доступ к разным типам наборов данных. В других случаях, операции сервиса могут следовать друг за другом в виде процесса, что означает что они должны быть вызваны в определенном порядке в течении некоторого периода времени.
Например, подумайте о том, как разработчик может реализовать сервис корзины веб-магазина со всеми необходимыми операциями: создания корзины, добавления товара, удаления, оплаты. Первый вызов, который выполнит клиент — это создание корзины — совершенно недопустимо сделать что-то другое с товаром до этого. Далее, клиент обычно вызывает операцию добавления товара в корзину — вызов удаления в пустой корзине не имеет смысла — а затем может вызвать и функцию удаления, если это потребуется. Когда же вызвана функция оплаты уже недопустимо вызывать операции добавления или удаления товаров.
Потенциально, все это может занять большое количество времени. Представьте, например, что пользователь создал корзину, добавил пару товаров, а затем приостановил работу с сервисом на какое-то время. Он может вернуться через несколько часов или дней и будет ожидать, что его корзина и товары все еще ждут его.
Как логика такого рода должна быть реализована? На самом деле это серия шагов с правилами определяющими порядок в котором эти шаги должны быть выполнены. Реализация так же должна поддерживать состояние — корзину — на протяжении всего процесса, который может занимать часы, дни или даже больше. Особенно в тех случаях, когда целью становится построение масштабируемого приложения, реализация такой логики в виде рабочих процессов построенных на базе WF будет наиболее предпочтительной. Рабочие потоки WF спроектированы так, чтобы упростить создание процессов и они могут стать хорошим выбором при разработке некоторых типов сервисов.
WF состоит из простых базовых частей: дизайнера для построения блоков бизнес-логики и среды исполнения для реализации логики на базе рабочих потоков. Рисунок 2 иллюстрирует работу WF:
Рис.2. WF – основа для создания процессоориентированной бизнес-логики
Каждый рабочий поток WF создается на основе активностей, каждая из которых реализует некоторую част бизнес-логики процесса. WF предлагает стандартную библиотеку Base Activity Library (BAL) с набором активностей реализующих базовые функции такие как if или While. Разработчики могут свободно создавать свои собственные активности для удовлетворения нужд своей бизнес-логики. Для того чтобы создать рабочий поток разработчик может использовать дизайнер рабочих потоков WF, который является частью Visual Studio, для того чтобы распределить активности. Вне зависимости от того какие будут использованы активности, все они исполняются с помощью среды исполнения WF runtime.
Рабочий процесс предлагает набор полезных вещей разработчику, который реализует процесс. Например, когда рабочий процесс ожидает ввод, такой как запрос на добавление или удаление элемента корзины, среда исполнения WF может автоматически сохранить состояние рабочего потока и выгрузить его из памяти. Когда будет получен новый запрос, среда перезагружает состояние и запускает рабочий поток для обработки запроса. Это позволяет упростить разработку масштабируемых приложений, так как рабочие потоки не потребляют память, системные потоки или другие ресурсы, в моменты когда они не исполняются. Среда исполнения может сохранить запись каждого исполнения рабочего потока, известную как трекинг, позволяя разработчику видеть разные полезные вещи, например когда в рабочем потоке включаются и выключаются каждая из активностей.
Создание сервиса на базе рабочего потока
Рабочие потоки WF могут быть использованы для реализации довольно большого числа разнообразных типов бизнес-процессов — они не ограничены только созданием сервисов. Тем не менее WCF-сервис, логика которого была создана на базе WF, заслуживает собственного имени — сервис на базе рабочего потока. Рисунок 3 демонстрирует такой подход:
Рис.3. Сервис на базе рабочих потоков
Представьте себе разработчика, который создает сервис на базе рабочих потоков либо простой WCF-сервис, который не использует WF. Ни WCF ни WF не определяют явно хост процесса, в котором сервис должен быть запущен. Хорошее в этом то, что разработчик свободен в выборе того, какой процесс он будет использовать — WCF и WF не ограничивают его в этом. Это особенно важно для промышленной разработки, когда основной целью является создание бизнес-логики, а построение хост-процесса для сервиса является лишней работой. В конце концов, этот процесс является частью инфраструктуры, а вопросы инфраструктуры — это ответственность Windows Server. Решение всех запросов сервисов в инфраструктуре и есть то, чем помогает AppFabric Hosting Services.
Введение в AppFabric Hosting Services
AppFabric Hosting Services (кодовое имя "Dublin") не предназначен для создания какой-то совершенно новой инфраструктуры. Наоборот, он построен на том, что уже предлагается сервером IIS и механизмом Windows Process Activation Service (WAS). Основываясь на этом фундаменте, AppFabric Hosting Services добавляет новые возможности для запуска и управления WCF-сервисами, включая сервисы на базе рабочих потоков. Рисунок 4 иллюстрирует это:
Рис.4. AppFabric Hosting Services упрощает запуск и управление сервисами
Как показано на рисунке, WCF-сервисы и сервисы на базе рабочих потоков запускаются в рабочих процессах, обслуживаемых IIS — это означает, что AppFabric Hosting Services не создает каких-то собственных процессов. Эта технология так же использует возможности WAS, которые позволяют запускать сервис в момент получения сообщения по HTTP или другому протоколу. AppFabric Hosting Services построен на существующей инфраструктуре, добавляя возможности запуска определенных сервисов сразу после размещения, без ожидания получения сообщений. Это позволяет сервису быть более отзывчивым для клиентов, которые первыми обращаются к нему, так как им не приходится ожидать когда сервис запустится.
Как показано на рисунке 4, AppFabric Hosting Services так же расширяет IIS Manager новыми инструментами управления сервисами. Используя эти расширения администратор может управлять конфигурацией WCF, запускать или останавливать сервисы, исследовать конечные точки сервисов, приостанавливать, возобновлять или прекращать работу определенных экземпляров сервисов на базе рабочих процессов. Вместе с этим AppFabric Hosting Services предлагает набор командлетов PowerShell для управления сервисами, позволяя администраторам создавать свои собственные скрипты.
Для того чтобы упростить жизнь разработчикам, Visual Studio предлагает встроенные шаблоны проектов для создания и WCF- и WF-сервисов. Сервисы созданные на базе этих шаблонов могут быть немедленно размещены в AppFabric Hosting Services — разработчикам не нужно делать ничего лишнего. И после того, как сервис развернут, он может быть доступен для потребления множеством разных способов. Рассмотрим их на сценариях.
Сценарий: хостинг сервиса на базе рабочих потоков
Хотя AppFabric Hosting Services может быть использован для работы с любым WCF-сервисом, он предлагает дополнительную поддержку для запуска и управления сервисам на базе рабочих потоков. Рисунок 5 показывает некоторые из самых важных таких возможностей:
Рис.5. AppFabric Hosting Services содержит дополнительные инструменты
Как указывалось ранее, среда исполнения WF автоматически сохраняет состояние рабочего потока, который ожидает ввода данных, а затем восстанавливает его когда данные поступают. Но где состояние сохраняется? Если использовать WF как отдельный механизм, разработчику приходится самостоятельно создать и конфигурировать БД для сохранения состояния. Тем не менее, как показано на рисунке 5, AppFabric Hosting Services предлагает преднастроенное хранилище состояний. WF так же позволяет отслеживать исполнение рабочего потока, автоматически позволяя разработчику получать детальную информацию о исполнении. И опять, WF сам по себе не определяет где именно хранить информацию слежения. Как показано на рисунке 5, AppFabric Hosting Services предлагают встроенную БД для мониторинга. Нужно пояснить, что хранилище состояний и БД мониторинга отделены от любой из баз данных приложения, которые могут быть использованы рабочим потоком.
Как и для любого другого WCF-сервиса, для рабочих потоков существуют механизмы мониторинга и управления. Наравне с описанными ранее элементами управления сервисами, AppFabric расширяет IIS Manager дополнительными функциями, применимыми только к сервисам на базе рабочих потоков. Для примера, взгляните на одно из расширений под названием AppFabric Dashboard изображенное на рисунке 6.
Рис.6. Панель управления AppFabric Dashboard
Как показано на рисунке, AppFabric Dashboard предлагает панель управления AppFabric Hosting Services. Сверху вы можете видеть статус текущих WF-сервисов, в котором отображается число находящихся в разных состояниях сервисов. Чуть ниже в окне отображается история последних вызовов, исключений и так далее. Microsoft также предлагает дополнительный пакет Management pack for System Center Operations Manager, который позволяет отслеживать события AppFabric Hosting Services с помощью стандартных средств управления Windows. Целью этих инструментов является предоставление ясной информации о том, что происходит в окружении сервисов в текущий момент времени.
Сценарий: делаем сервисы рабочих потоков более масштабируемыми
Способность WF автоматически сохранять и восстанавливать состояние рабочих потоков позволяет разработчикам создавать масштабируемую бизнес-логику. AppFabric Hosting Services позволяет разработчикам создавать сервисы на базе рабочих потоков даже еще более масштабируемыми. Рисунок 7 демонстрирует это:
Рис.7. Масштабируемая архитектура сервисов на основе рабочих потоков
В этом сценарии три веб-сервера запускают копии одного и того же приложения ASP.NET с балансировкой нагрузки. ASP.NET используется только для генерации пользовательского интерфейса. Бизнес-логика приложения, может быть это корзина магазина, реализована в виде сервиса на базе рабочих потоков (и чтобы не было путаницы: хоть это и не показано на рисунке, как правило, каждый сервис на базе рабочего потока запускается в виде рабочего процесса IIS).
Первый запрос пользователя отправлен верхнему веб-серверу (шаг 1). Страница ASP.NET получившая этот запрос вызывает первую операцию в сервисе на базе рабочего потока, например, создание корзины. Это запрос отправляется к экземпляру сервиса запущенного на отдельном сервере (шаг 2). Как только операция выполняется и результат возвращается, среда исполнения WF автоматически записывает состояние сервиса в хранилище, поставляемое AppFabric Hosting Services (шаг 3).
Следующий запрос пользователя отправлен балансировщиком нагрузки на другой веб-сервер (шаг 4). В этот раз страница ASP.NET, которая обрабатывает запрос, например на добавление элемента в корзину, отправляет запрос к сервису, который запущен на отличном от первого сервере (шаг 5). Несмотря на то, что этот второй запрос исполняется сервисом на другом сервере, среда исполнения WF позволяет загрузит ь состояние экземпляра рабочего потока из хранилища и обработать запрос (рисунок 6).
Как показано на примере, AppFabric Hosting Services позволяет одним и тем же сервисам на базе рабочих потоков исполняться в разное время на различных физических серверах. Это делает сервисы более масштабируемыми, так как теперь мы можем размещать множество промежуточных серверов для обработки любого числа запросов. Так же как приложение ASP.NET может масштабироваться простым добавлением веб-серверов, так же и бизнес-логика реализованная в виде рабочих потоков может масштабироваться с помощью дополнительных серверов.
Смотрите начало по этому адресу, продолжение, окончание следует.
Автор: XaocCPS
