Андрей Колесов

Одно из главных направлений развития современных информационных систем масштаба предприятия связано с концепцией сервис-ориентированной архитектуры (services-oriented architecture, SOA). Отметим, что сама по себе идея компонентного построения распределенных компьютерных систем, в которых можно было бы использовать те или иные вычислительные и информационные ресурсы по мере их реальной необходимости, совсем не нова. По большому счету, таков изначально был один из основополагающих принципов применения ИТ с момента создания первых ЭВМ, еще 50 лет назад.

Если вспомнить о диалектическом развитии истории по спирали, то качественно новым элементом идеи SOA стала ориентация на применение появившихся относительно недавно технологий, позволяющих создавать распределенные системы на базе Web-сервисов. В несколько упрощенном виде новизна Web Services заключается в использовании Интернет-технологий на базе открытых отраслевых стандартов, что, в свою очередь, позволяет создавать гетерогенные (платформно независимые), масштабируемые (от локальных до глобальных) решения.

Набор технологий Web Services

Web Services вполне допустимо назвать технологиями XXI века - за точку отсчета их истории, хотя и с некоторой долей условности, можно принять 2000 г. Именно тогда в специализированной прессе стали появляться названия первых WS-стандартов: SOAP (Simple Object Access Protocol) для обмена данными между приложениями, WSDL (Web Services Description Language) для описания программных интерфейсов сервисов и UDDI (Universal Description Discovery & Integration) для хранения и получения WSDL-описаний. Этих стандартов вполне хватает для создания несложных распределенных решений, но явно недостаточно для построения корпоративных систем. Именно потому наряду с модернизацией базовых стандартов стали появляться специализированные технологии для решения таких задач, как гарантированная доставка сообщений, шифрование и обеспечение безопасности, управление транзакциями и т. п. Все они реализованы на основе XML.

В результате к сегодняшнему моменту сложилась целая система WS-стандартов (один из вариантов ее структуры представлен на рис. 1). Анализ этих стандартов, которых уже сейчас насчитывается несколько десятков, не входит в задачу настоящей статьи. (Подробный обзор WS-стандартов можно найти в PC Week/RE NN 27-35/2004 http://www.pcweek.ru.) Отметим только, что подавляющее большинство этих стандартов существуют лишь на бумаге и пока не поддерживаются в программных продуктах. Более того, здесь наблюдается неприятная тенденция - создание конкурирующих между собой спецификаций, подготовкой которых занимаются две группировки ИТ-компаний: одна во главе с IBM и Microsoft и другая, возглавляемая Sun Microsystems и Oracle.

 

Рис. 1. Структура стандартов и спецификаций Web Services.

Как видно из рис. 1, основу структуры WS-технологий составляет все та же базовая тройка - SOAP, WSDL, UDDI, которой пока, к счастью, не коснулась конкурентная борьба ИТ-вендоров. Над ними располагаются слои "Безопасность", "Обмен сообщениями", "Управление контекстом", "Координация", "Управление транзакциями". Выше находятся еще два слоя - "Оркестровка" (Orchestration) и "Хореография" (Choreography). Первый из них стали использовать в лексиконе WS-технологий еще 4-5 лет назад для обозначения задач управления бизнес-процессами. Второй появился относительно недавно и также относится к проблематике автоматизации процессов, но акцент при этом делается на интеграцию разнородных приложений.

Для решения задач "оркестровки" и "хореографии" также разработан целый набор стандартов. На лидирующие позиции в этой сфере сейчас претендует в первую очередь Business Process Execution Language for Web Services (язык исполнения бизнес-процессов для Web-сервисов), обозначаемый как BPEL4WS, или просто BPEL. Разработкой этого стандарта занимались специалисты группы ИТ-компаний, ведущую роль в которой играли IBM и Microsoft. Более того, BPEL фактически стал прямым наследником ранее созданных спецификаций IBM WSFL и Microsoft XLANG. В нем используются сразу несколько XML-спецификаций - WSDL 1.1, XML Schema 1.0, XPath 1.0.

Первый вариант BPEL был представлен два года назад и в марте 2003 г. был утвержден OASIS (Organization for the Advancement of Structured Information Standards, организация по продвижению стандартов в области структурированной информации). Весной 2004 г. появилась версия BPEL 1.1. Эта спецификация была впервые реализована в продуктах IBM WebSphere Business Integration Server Foundation 5.1 и Microsoft BizTalk Server 2004. Кроме того, поддержка BPEL обеспечивается в ряде ведущих платформ исполнения приложений и сервисов (например, SAP NetWeaver и BEA WebLogic).

Говоря о BPEL, нужно упомянуть и о еще двух стандартах, также разработанных совместными усилиями IBM и Microsoft, - WS-Coordination и WS-Transaction. Данные спецификации дополняют возможности BPEL при автоматизации сложных и длительных по времени бизнес-транзакций.

Для многих разработчиков стандарт BPEL - это пока "темная комната", в которой скрываются загадочные возможности создания и использования каких-то качественно новых приложений. Хотя из самого названия понятно, что BPEL позволяет делать нечто для автоматизации бизнеса на базе Web-сервисов, до сих пор среди программистов бытует мнение, что данная технология доступна только профессионалам-гуру.

На самом же деле BPEL - это достаточно простой в изучении, но вполне мощный язык, реализованный на базе XML, позволяющий определить последовательность выполнения функционала Web-сервисов в ходе различных потоков операций (транзакций). И здесь наиболее важен тот факт, что BPEL поддерживают ведущие поставщики ПО, предлагающие BPEL-совместимые продукты. И пусть число пользователей этих продуктов пока не слишком велико, но можно ожидать, что оно будет очень быстро расти.

В то же время нужно подчеркнуть, что, решая задачи интеграции разнородных приложений в общей цепочке выполнения бизнес-процессов, BPEL совершенно не учитывает, как Web-сервисы выполняют порученные им функции, занимаясь исключительно координацией их работы ("оркестровкой" или даже "хореографией" отдельных исполнителей) в ходе делового потока.

Примеры применения BPEL

Для иллюстрации возможностей BPEL рассмотрим пару простых примеров.

Предположим, что есть некоторый онлайновый продавец антиквариата. Когда он через свой Web-сайт получает запрос на покупку, ему необходимо запустить процессы для автоматического определения кредитоспособности клиента и поиска у оптовых торговцев нужного товара по наименьшей цене. Для этого программа должна отправить запрос в соответствующую учетную систему и в целый ряд профильных электронных магазинов, например, в Amazon и eBay, у которых есть общедоступные интерфейсы Web-сервисов. После получения ответной информации выбирается вариант с наименьшей ценой. Диаграмма этого бизнес-процесса определения стоимости товара приведена на рис. 2. Разумеется, за ним может следовать автоматическое продолжение - заказ товара, отправка его покупателю и т. д.

Рис. 2. Простой пример процесса показывает возможности внутреннего и внешнего использования Web-сервисов.

Анализируя эту схему, нужно обратить внимание на то, что она показывает общую логику процесса, передачу запросов и ответов, никак не детализируя функционирование самих удаленных Web-сервисов. На BPEL нужно только описать последовательность обращений и способы обработки получаемой информации. Для написания соответствующей программы можно использовать один из многих BPEL-инструментов, которые на основе такой визуальной диаграммы автоматически сгенерируют код на языке BPEL, создав таким образом простейшее приложение класса SOA.

Каждая операция (invoke), представленная на диаграмме прямоугольным блоком, описывается простой BPEL-структурой, которая включает элементы, соответствующие таким действиям, как отправка запроса, ожидание, получение ответа и т. д. Например, операция запроса о кредитоспособности (которая может выполняться в синхронном или асинхронном режимах - переход к последующим действиям с ожиданием или без ожидания ответа) может описываться примерно следующим образом:

<!-примергенерациикода BPEL--> <invoke name="invoke-1"     partnerLink="AccountingDept"   portType="services:CreditRatingService"   operation="process" inputVariable="crIn"   outputVariable="crOut"> </invoke>

Как видно, этот код реализован на базе синтаксиса XML. Более того, BPEL может работать с различными другими XML-средствами, такими, как XSLT, XQuery and XPath. Полный вариант BPEL-файла для процесса определения цены должен, конечно, содержать также соответствующие блоки взаимодействия с Web-сервисами торговых партнеров и код логики выполнения переходов и простейших вычислительных операций (например, выбора наименьшей цены). Дополненный WSDL-файлами (для описания внешних Web-сервисов), он будет представлять собой законченную программу "оркестровки" Web-сервисами.

Рассмотрим еще один пример использования BPEL при решении довольно обычной задачи: транспортное агентство получает от клиента запрос на приобретение билетов по некоторому маршруту, заказывает билеты в авиакомпании и получает их от нее (для упрощения примера мы не рассматриваем последующие действия - оплату билетов, доставку их клиенту и т. д.). Потоковая диаграмма действий такого бизнес-процесса представлена на рис. 3, а в листинге содержится соответствующий программный код, демонстрирующий основные элементы BPEL.

Рис. 3. Бизнес-процесс заказа авиабилетов.

Программа начинается с описания бизнес-процесса, названного ticketOrder (тег ). Далее идет блок описания партнеров, участвующих в этом процессе (ограниченный тегом ). В данном случае их два - клиент (customer) и авиакомпания (airline). Для подключения партнеров к процессу служит двусторонний указатель, называемый service link type и содержащий две коллекции Web-сервисов, ссылки на которые выполняются с помощью ролей. В частности, указатель buyerLink включает две роли, в каждой из которых имеется описание соответствующего порта:

<serviceLinkType name="buyerLink">   <role name="ticketRequester">     <portType name="itineraryPT"/>   </role>   <role name="ticketService">     <portType name="ticketOrderPT"/>   </role> </serviceLinkType>

Соответственно партнер airline, который использует описание buyerLink, указывает две роли: для владельца процесса (myRole) и внешнего партнера (partnerRole).

Описание WSDL-сообщений, отправляемых между Web-сервисами, приведено в блоке, ограниченном тегами

<containers>.

Эта информация будет использоваться в последующем коде.

Логика самого бизнес-процесса, который состоит из операций, называемых действиями (activity), заключена внутри тегов

<flow>.

В начале этого блока находятся конструкции, называемые links, которые указывают направления связей при выполнении последующих операций.

Далее приведен код самих операций, которых в данном случае три. В этом примере мы используем две наиболее часто встречающихся операции activity -

<receive> и <invoke>.

Первая, receive - это просто ожидание получения сообщения от партнера. Как видно из листинга, выполнение процесса начинается с ожидания получения запроса от клиента, при этом используется сообщение типа itineraryMessage, приведенное в контейнере itinerary. Более мощный вариант такого действия может быть представлен тегом

<pick>,

который позволяет принимать целый набор сообщений от нескольких партнеров.

Действие invoke может применяться в синхронном режиме для выполнения операции "отправить-принять". В нашем случае invoke работает только на отправку запроса на приобретение билета, для получения заказа служит последующее действие receive.

BPEL-описание бизнес-процесса приобретения авиабилета <process name="ticketOrder">   <partners>     <partner name="customer"        serviceLinkType="agentLink"        myRole="agentService"/>     <partner name="airline"        serviceLinkType="buyerLink"        myRole="ticketRequester"        partnerRole="ticketService"/>   </partners>   <containers>      <container name="itinerary"       messageType="itineraryMessage"/>      <container name="tickets"       messageType="ticketsMessage"/>   </containers>   <flow>     <links>       <link name="order-to-airline"/>       <link name="airline-to-agent"/>     </links>     <receive partner="customer"       portType="itineraryPT"       operation="sendItinerary"       container="itinerary"       <source         linkName"order-to-airline"/>     </receive>     <invoke partner="airline"       portType="ticketOrderPT"       operation="requestTickets"       inputContainer="itinerary"       <target        linkName"order-to-airline"/>       <source        linkName"airline-to-agent"/>     </invoke>     <receive  partner="airline"       portType="itineraryPT"       operation="sendTickets"       container="tickets"       <target        linkName"airline-to-agent"/>     </receive>   </flow> </process>

Создание BPEL-решений

Разумеется, приведенные выше примеры BPEL-программ очень далеки от реальных бизнес-приложений и служат здесь только иллюстрацией основных идей, заложенных в этот стандарт. BPEL позволяет применять условные ветвления, организовывать потоки параллельных вычислений, описывать правила соединения потоков, обмениваться данными между потоками, применять синхронные и асинхронные режимы взаимодействия, обрабатывать исключительные ситуации и т. п. При этом BPEL использует традиционную, центрическую модель исполнения: любые внешние сообщения из внешнего мира ожидаются только в том случае, если они ожидаются по ходу процесса.

Создаваемые с помощью BPEL приложения относятся к категории "процессно-ориентированных" (process-based applications). Фактически они состоят из двух отдельных слоев исполнения. Верхний слой описывает бизнес-логику процесса, представленную на языке BPEL, нижний слой выполняет собственно все функциональные операции с помощью различных Web-сервисов. BPEL-приложение может выполняться на любом сервере приложений, имеющем механизм исполнения BPEL.

Развитые инструменты позволяют визуально проектировать полнофункциональные BPEL-приложения, не требуя написания кода вручную. Эти средства, кроме того, включают функции автономного тестирования программы. Однако для работы в реальных условиях под управлением BPEL-сервера требуются правильные установки для всех используемых Web-сервисов в WSDL-файлах, а также конфигурирование необходимых коммуникационных протоколов (например, Java Message Service или HTTP).

Отдельно стоит упомянуть о возможности преобразования моделей UML (Unified Modeling Language) в наборы BPEL и WSDL-файлов. Такие инструменты уже появились на рынке; в качестве примера можно привести средство Emerging Technologies Toolkit 1.1 корпорации IBM.