Введение в Windows Server AppFabric. Hosting Services вместе с BizTalk и Service Bus

Это третья и заключительная часть статей на тему сервисов Windows Server AppFabric. Вы можете найти две другие статьи по следующим ссылкам:

• Введение в Windows Server AppFabric. Сервис Caching Services
• Введение в Windows Server AppFabric. Сервис Hosting Services, хостинг и масштабирование сервисов

Сценарий: подключение сервиса на базе рабочих потоков к существующему приложению с помощью BizTalk Server

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

В мире Microsoft интеграция такого типа обычно обрабатывается с помощью BizTalk Server. На рисунке 1 показано как сервис на базе рабочих потоков, AppFabric Hosting Services и BizTalk Server могут работать друг с другом.


Рис.1. Интеграция сервиса и сервера BizTalk

Как показано на рисунке, активность в сервисе может создать запрос на сервер BizTalk. Это может быть сделано с помощью веб-сервиса или как-то еще, для этой цели BizTalk предлагает механизм адаптеров для разных типов коммуникаций. После старта запроса, он может быть обработан бизнес-логикой запущенной на сервере BizTalk. Эта логика реализована в качестве дирижера, она знает как именно поддержать следующий шаг в этом процессе. Здесь, к примеру, дирижер использует другой адаптер BizTalk для взаимодействия с приложением ERP напрямую. Любой ответ может быть отправлен назад через те же самые компоненты.

С чисто технической точки зрения, сервис на базе рабочих потоков запущенный на AppFabric Hosting Services может выглядеть точно так же как дирижер запущенный на сервере BizTalk. Оба они представляют собой рабочие потоки, оба могут быть созданы в графических редакторах, Microsoft даже предлагает WCF-адаптеры, которые могут быть использованы и сервисом и дирижером. Тем не менее, не стоит обманываться, эти две технологии решают разные задачи.

Сервис на базе рабочего потока запущенны на AppFabric Hosting Services спроектирован для реализации бизнес-логики — это приложение. Дирижер запущенный на BizTalk, в отличии, сфокусирован только на интеграции. Интеграции — это особенная проблема, которая требует особенных инструментов и технологий, и BizTalk именно такой инструмент. В большинстве случаев, выбор между двумя технологиями просто: используйте AppFabric Hosting Services для создания приложений и BizTalk для решения проблем интеграции.

Хотя существует техническая возможность реализовать функционал BizTalk с помощью AppFabric Hosting Services и WF, делать этого не имеет смысла по финансовым причинам. Общая стоимость построения и обслуживания собственного интеграционного сервера скорее всего превысить стоимость лицензии на BizTalk Server. В реальности, лучше будет считать AppFabric Hosting Services и BizTalk партнерам, чем конкурентами. Каждый из механизмов играет свою роль в создании и подключении приложений.

Сценарий: подключение к удаленному сервису посредством Service Bus

Другой проблемой, которая может встать при работе с сервисами — это предоставление доступа к ним из интернета. Представьте себе, что WCF-сервис запущенный внутри организации необходимо предоставить клиентам за пределами организации, через каналы интернет. Вне зависимости от того, используете вы или нет WF, в таком случае возникают некоторые препятствия. Например, как клиент сможет взаимодействовать с сервисом через файрвол? И, зная о том, что большинство организаций используют динамические адреса и NAT, как нашему сервису предложить фиксированный IP для его клиентов?

Service Bus — это часть платформы Windows Azure, была создана для решения этой проблемы. На рисунке 2 показана схема работы:

Рис.2. Работа Service Bus

Для начала, сервис WCF регистрирует свою конечную точку в Service Bus, предоставляя для этого уникальное имя (шаг 1). После этого Service Bus сам предоставляет эту конечную точку с тем же самым интерфейсом (шаг 2). Используя уникальное имя, клиент может получить доступ к конечной точке Service Bus (шаг 3). Так как клиенту знакома интерфейс, он может оперировать с конечной точкой в Service Bus (шаг 4). Для каждой операции, которую вызывает клиент, Service Bus вызывает соответствующую операцию в сервисе на стороне инфраструктуры предприятия (шаг 5).

Чтобы понять почему это работает, важно понимать что на шаге 1, когда сервис регистрирует свою конечную точку в Service Bus, устанавливается TCP-соединение с облачным посредником. После этого соединение остается открытым, позволяя Service Bus вызывать операции сервиса без блокировки файрволом предприятия. Так как файрвол рассматривает такой трафик как ответы в соединении от клиента вне предприятия, он пропускает такие пакеты. Поддерживание соединения открытым позволяет иметь WCF-сервису постоянный IP-адрес, не зависящий от NAT, позволяя Service Bus гибко вызывать операции сервиса. Ну и так как Service Bus всегда имеет определенные IP-адреса, клиенты могут легко его обнаружить.

Сценарий: создание композитного приложения с сервисом на базе рабочих потоков

С ростом приложений, которые предоставляют свою функциональность через сервисы разработчики имеют все больше возможностей строить разные приложения, которые эти сервисы потребляют. Композитные приложения такого типа могут быть очень полезны в разных ситуациях. Например, вместо того, чтобы напрямую изменять существующее ERP-приложение, будет легче и дешевле создать композитное приложение, которое использует сервисы ERP и другие сервисы от сторонних приложения для создания нового функционала. На рисунке 3 показано как сервис на базе рабочего потока запущенный с помощью AppFabric Hosting Services может предложить способ создания такого типа приложений.

Рис.3. Схема композитного приложения

В этом примере, сервис на базе рабочего потока взаимодействует с другими приложениями с помощью нескольких подходов:

• Используя Service Bus для вызова операций в приложении партнера расположенного в интернете
• Создавая прямые запросы в CRM-приложение, используя SOAP-сервисы
• Полагаясь на BizTalk для взаимодействия с ERP-приложением

В растущем сервисо-ориентированном мире большую роль играет простота создания логики по работе с этими сервисами. AppFabric Hosting Services поддерживает это движение предлагая сервисную архитектуру для запуска ваших приложений.

Совмещая части в целое

Две части Windows Server AppFabric — AppFabric Caching Services и AppFabric Hosting Services могут быть использованы раздельно друг от друга. Но часто имеет смысл использовать их вместе. Например, представьте, что организация собирается создать приложение, которое будет способно обрабатывать очень большое число одновременных запросов от пользователей. Рисунок 4 показывает как два компонента Windows Server AppFabric могут быть объединены для достижения этой цели.

Рис.4. Использование сервисов AppFabric вместе

Как обычно, запрос от пользователя может быть обработан балансировщиком нагрузки для распределения между множеством веб-серверов с копией бизнес-логики — в виде страницы ASP.NET — на каждом. Если эта логика часто использует одну и туже информацию, например, каталог данных описывающих что именно организация продает, то такая информация может быть доступна через кластер кэша реализованный с помощью AppFabric Caching Services. А в связи с тем, что торговая корзина приложения реализована с помощью сервиса на базе рабочих потоков, который запущен в AppFabric Hosting Services, запросы из веб-сервера могут быть распределены между несколькими промежуточными серверами. Кстати, хоть это и не показано на рисунке, рабочие потоки тоже могут получать доступ к данным кэша для получения необходимой информации. В сценарии наподобие этого, комбинирование обеих частей Windows Server AppFabric несет большую пользу, упрощая жизнь разработчикам, которым необходимо создавать высоко масштабируемые системы.

Заключение

Медленные приложения нельзя назвать хорошими. Так же по-настоящему хорошие приложения должны быть управляемыми. Предлагая инфраструктуру для улучшения производительности, масштабирования и управляемости Windows-приложений, сервисы Windows Server AppFabric могут помочь разработчикам сделать их приложения лучше.

Как и все программные инфраструктуры, эти технологии являются инструментами. Но инструменты являются основой для комфортной жизни. Точно так же целью Windows Server AppFabric является предложить основу для создания более эффективных Windows-приложений. Для всех будет лучше, если разработчики будут проводить больше времени над бизнес-логикой и меньше над построением инфраструктуры.

Автор: XaocCPS