Перспективы BPEL

Эрик Р. Пизковски

Новая версия спецификации BPEL (Business Process Execution Language) позволяет «переносить» бизнес-процессы, т. е исполнять их в системах, базирующихся на BPEL-механизмах разных разработчиков.

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

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

Несмотря на это, переход на версию 2.0 не будет безболезненным. Старая и новая версии имеют существенные синтаксические и семантические различия.

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

История развития BPEL

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

Первоначальный вариант спецификации, разработанный компаниями BEA Systems, IBM и Microsoft, получил широкую поддержку в отрасли. Однако, когда другие разработчики начали строить продукты на базе этой спецификации, проявились ее неоднозначности и пробелы. Для устранения этих недостатков поставщики, реализовавшие исполняющие механизмы BPEL (BPEL engines), разрабатывали соответствующие расширения. Для продолжения успешного развития BPEL, содействия его широкому признанию и включения в него (в качестве открытых стандартов) расширений, предложенных сторонними разработчиками, BEA, IBM и Microsoft в мае 2003 г. предоставили спецификацию в организацию OASIS (Organization for the Advancement of Structured Information Standards). В соответствии со своими правилами OASIS присвоила спецификации наименование WS-BPEL. В результате спецификация BPEL уже тогда на один шаг отдалилась от статуса открытого стандарта. В ИТ-сообществе в связи с этой спецификацией существуют различные ожидания. Хо-тя спецификация WS-BPEL 2.0 в сравнении с BPEL4WS 1.1 предлагает новые возможности и усовершенствования, сфера ее действия остается неизменной.

Принцип работы BPEL

Уникальные языковые конструкции, присущие BPEL, позволяют поместить соответствующую спецификацию на вершину иерархии Web-сервисов OASIS и делают ее хорошим средством для организации взаимодействия сервисов, которая получила название «оркестровка». Значение BPEL возросло вместе с широким распространением сервис-ориентированной архитектуры SOA (Service-Oriented Architecture), поскольку она требует оркестровки. Последняя позволяет организациям определять и переопределять бизнес-процессы в режиме реального времени, создает так необходимую организациям гибкость и является ключевой ценностью SOA.

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

Усовершенствования версии BPEL 2.0

Спецификация WS-BPEL 2.0 содержит новые действия и улучшает почти все уже существующие; кроме того, некоторые существующие действия в ней переименованы. Благодаря вводу новых и усовершенствованию ряда существовавших ранее механизмов расширения WS-BPEL 2.0 имеет очень хорошие перспективы. Фирменные усовершенствования или расширения, реализованные в исполнительном механизме BPEL одного разработчика, при попытке экспорта в другие BPEL-механизмы будут игнорироваться. Разработчики обычно предлагают расширения с целью преодоления недостатков спецификации. Хотя многие из этих расширений могут быть внесены в BPEL только к выпуску следующей версии, механизмы расширения позволяют разработчикам реализовать «будущую функциональность» уже сегодня, не рискуя при этом стабильностью стандарта. Ведь даже если в дальнейшем такое расширение и становится стандартом, OASIS, скорее всего, не будет использовать его в оригинальном виде, а предварительно попытается переработать.

Кроме того, новые стандарты, например стандарты для функций взаимодействия между людьми и для поддержки субпроцессов, могут интегрироваться в BPEL без модификации ядра спецификации, благодаря чему этот процесс происходит гораздо быстрее. WS-BPEL 2.0 улучшает существующие механизмы расширения и делает их работоспособными не только в теории, но и на практике. WS-BPEL 2.0 также улучшает возможности языка по оперированию данными. Спецификация вводит модель данных с целью представления BPEL-переменных и определяет правила для привязки к этой модели различных языков, таких, как XPATH 1.0.

Трудности перехода на новую версию

Существенные различия между BPEL4WS 1.1 к WS-BPEL 2.0, о которых шла речь выше, сильно усложняют переход на новый стандарт, а главное — версия WS-BPEL 2.0 не является обратно совместимой с BPEL4WS 1.1. К тому же WS-BPEL 2.0 не хватает некоторых важных качеств: в ней не будет поддержки принципа модульности, повторного использования кода и уже упомянутых выше механизмов взаимодействия между людьми и поддержки субпроцессов. Можно ожидать появления расширений, решающих эти проблемы, но сама версия WS-BPEL 2.0 перечисленные концепции не поддерживает.

Есть мнение, что отсутствие поддержки взаимодействия между людьми и субпроцессов — это огромный недостаток, поскольку язык оркестровки без этой поддержки является неполным. И действительно, такая поддержка необходима для того, чтобы BPEL обрабатывал модели любых процессов стандартным образом. Эти недостатки, однако, не отпугивают клиентов от BPEL, поскольку данные функции часто предлагаются в фирменных решениях поставщиков.

Для поддержки взаимодействия между людьми компании IBM и SAP предложили свое расширение BPEL — BPEL4People. Задачи, связанные с взаимодействием между людьми, существенно отличаются от работы с сервисами. В процессе исполнения они имеют определенные статусы («готова к исполнению», «выполняется», «завершена», «завершена неудачно» и т. д.) и в каждый данный момент времени задача имеет только одного пользователя. Обращения к сервисам в процессе своего исполнения не меняют статуса, поскольку сервису и им все равно, сколько людей пользуются им в данный момент. По причине этих фундаментальных различий любая реализация описанной выше функциональности должна формулироваться как расширение, а не как часть базовой спецификации. К сожалению, в настоящее время в большинстве механизмов BPEL эта функциональность реализуется только через фирменные расширения. Ситуация не изменится и в новой версии спецификации.

В большинстве случаев использование фирменных расширений затрудняет переход от BPEL-механизма одного разработчика к аналогичному механизму другого разработчика. Так же обстоит дело и с субпроцессами. Язык BPEL в настоящее время не поддерживает явного объявления субпроцессов. Как в BPEL4WS 1.1, так и в WS-BPEL 2.0 можно лишь единственным образом имитировать субпроцесс — определив целый бизнес-процесс как независимый сервис и вызвать его при помощи действия «вызов» (invoke activity). Это конечно, до некоторой степени паллиатив, поскольку субпроцесс получается полностью скрытым от своего родительского процесса и отсутствует возможность координации субпроцесса с родительским процессом на всем их жизненном цикле.

Для решения этих проблем компании IBM и SAP предложили свое решение — совокупность расширений для субпроцессов BPEL-SPE (Extensions for Sub-Processes). Эта заявка на стандарт (но уже для следующей спецификации BPEL), подразумевающая явное объявление субпроцессов, предусматривает повторное их использование, жесткую увязку жизненных циклов субпроцесса и его родительского процесса и возможность обращения субпроцесса к данным своего родительского процесса.

Версия WS-BPEL 2.0 есть свидетельство того, что работа над спецификацией продолжается. Усовершенствования, которые она в себе несет, показывают, какими большими возможностями в деле совершенствования спецификаций располагают такие органы стандартизации, как OASIS, и демонстрируют хорошее усвоение уроков, полученных в результате работы с предыдущими версиями. Удобства, предлагаемые новой версией BPEL, могут быть полезны пользователям языка, но с переносом существующих BPEL-процессов из старой версии в новую будут возникать трудности. Прямые и скорые выгоды от применения WS-BPEL 2.0 смогут извлечь разработчики, поскольку они наверняка будут пользоваться преимуществами механизмов расширения, которые предлагаются новой версией спецификации..