Повышение эффективности процессов в организациях основано на преодолении в них организационной и технологической разрозненности. В сочетании с постоянным мониторингом и реинжинирингом эти меры образуют основу методологии BPM. Однако реализовать эту методологию не всегда удается даже опытным специалистам по причине инфраструктурной неготовности самих организаций, что и объясняет ограниченный успех внедрения BPM. SOA позволяет в полной мере реализовать потенциал BPM.

Организационная разрозненность естественным образом сопутствует любой сервис-ориентированной архитектуре (service-oriented architecture): четкое разделение границ, в том числе административных, является базовым и определяющим постулатом SOA. Любое множество систем, «обитающих» в сервис-ориентированной среде, каждая из которых при этом находится в разном подчинении, может быть объединено в рамках того или иного бизнес-процесса без предварительного выполнения очередного интеграционного проекта. Для этого достаточно соблюдать некоторые правила, среди которых: декомпозиция систем до уровня контекстно-независимых сервисов, стандартизация контрактов таких сервисов и доступность информации об экземплярах сервисов для их потенциальных потребителей. Практическая реализация этих правил в каждой организации, конечно, выражается по-разному.

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

Модульность, издавна считавшаяся ключом к гибкости и многократности использования программных активов, благодаря SOA получила новую форму и новые качества, многократно увеличивающие ее эффективность, вследствие расширения сферы применения за рамки отдельных информационных систем. В результате интеграция приложений все чаще основывается на подходах SOA и технологиях Web-сервисов, что и не удивительно, учитывая преимущества предоставления бизнес-функциональности через слабосвязанные, общедоступные по сети сервисы. По этой причине SOA может стать мощным катализатором развития BPM: непрерывное совершенствование процессов, независимо от систем, поддерживающих их исполнение, подразумевает наличие гибкой инфраструктуры, способной обеспечить как интеграцию приложений, так и широкие возможности адаптации. Архитектурный стиль SOA основан на модульности и композиции, ввиду чего его, безусловно, можно считать подходящей основой для такой инфраструктуры. Если BPM преследует целью обеспечение эффективности процессов, то SOA — их адаптивности.

SOA и BPM не только методологически дополняют друг друга, а соприкасаются и напрямую. Чтобы убедиться в этом, достаточно рассмотреть структуру сервиса. Сервисы учетных систем предоставляют функции сохранения-выборки информации. Такие сервисы называют «мелкозернистыми» (fine-grained) из-за их низкого уровня абстракции и высокой детальности. Из них можно формировать «крупнозернистые» (coarse-grained) сервисы, которые, в свою очередь, могут компоноваться в бизнес-сервисы более высокого уровня. Конечно, вовсе не обязательно, чтобы сервисы были организованы в строго разграниченные слои — на практике это нередко не только не возможно (системы от различных разработчиков могут быть построены с разным уровнем гранулярности сервисов), но и не оптимально. Важен сам принцип обобщения — от специфических функций определенных систем к композитным сервисам уровня бизнес-архитектуры. Именно наличие слабосвязанных сервисов на разных уровнях позволяет гарантировать гибкость — за счет реорганизации связей. Композитные сервисы с практической точки зрения неотличимы от бизнес-процессов, за исключением наличия у них собственных интерфейсов, обеспечивающих поддержку интеграции процессов и очередного уровня композиции.

Рекурсивная композиционность сервисов позволяет также решить и непростую организационную проблему, из-за которой внедрение BPM часто не достигает желаемого результата. Инструменты BPM представляют бизнес-процессы в виде диаграмм, состоящих из последовательностей действий, к каждому из которых бизнес-аналитики привязывают те или иные операционные эквиваленты из ИТ-окружения. Такими операционными эквивалентами, конечно, могут быть и сервисы. Некоторые из этих сервисов могут быть самостоятельными бизнес-процессами, вследствие чего бизнес-аналитики могут специализироваться на отдельных предметных областях компании. Это позволяет экспертам накапливать знания, а не поверхностно заниматься «функцией BPM» во всех областях. Отсутствие специализации такого рода нередко приводит к некачественному описанию бизнес-процесса — например, такому, каким он некогда был или каким бы он мог быть, но так и не стал, а не к искомому описанию бизнес-процесса в том виде, в котором он фактически является или будет являться на самом деле.

Помимо собственно описания бизнес-процессов, для реализации BPM необходимо также иметь возможность точно представлять эти описания в виде ИТ-активов, а также развивать их по мере изменения бизнес-процесса. При этом путь от изменения процесса к изменению кода должен быть минимальным и прослеживаемым. Поэтому оркестрация является одним из наиболее многообещающих подходов, который заключается в исполнении специальным контейнером логики связывания сервисов, содержащейся непосредственно в описании бизнес-процесса. Для этого контейнер должен отвечать требованиям, характерным для интеграционных брокеров и мониторов транзакций, а интерпретируемые им процессы должны состоять из предварительно определенных алгоритмических и коммуникационных примитивов. С учетом этих соображений был создан язык BPEL (Business Process Execution Language), нацеленный на формирование сервисов путем рекурсивной композиции и совмещения модели процесса времени проектирования с моделью времени исполнения в едином описании.

Сегодня наиболее широко применяется спецификация BPEL4WS 1.1, опубликованная в марте 2003 года консорциумом компаний в составе BEA Systemms, IBM, Microsoft, SAP и Siebel. В ближайшие месяцы ожидается выпуск версии BPEL 2.0, имеющей статус стандарта OASIS.

Модель BPEL

Модель процесса в BPEL является прямым расширением сервисной модели WSDL (Web Services Description Language). У процесса, как и у любого сервиса, с которым он контактирует, должен быть описанный на языке WSDL интерфейс. BPEL следует принципу разделения описания сервисов на абстрактную часть и зависимую от внедрения. Так, модель процесса оперирует конструкциями типа: и , но не и , которые относятся к фактическим экземплярам сервисов, используемым процессом во время исполнения.

Зависимость BPEL от WSDL, вопреки расхожему мнению, отнюдь не ограничивает выбор протоколов, по которым можно контактировать с процессом и с используемыми им сервисами. Как язык описания интерфейсов сервисов WSDL не привязан к какому-либо протоколу, хотя зачастую протоколом доступа к сервису становится SOAP. Различие более очевидно, если учесть, что SOAP, в свою очередь, вовсе не подразумевает наличия WSDL. Более того, WSDL и не позволяет полностью описать модель передачи сообщений SOAP (SOAP Messaging Framework). BPEL компенсирует это в части своего расширения WSDL, путем предоставления модели специфицирования высокоуровневого протокола обмена сообщениями между сервисами.

Элементы и в WSDL не несут функциональной нагрузки с точки зрения типизации интерфейса процесса, хотя информация о фактических используемых протоколах и адресах, безусловно, необходима во время исполнения. Эти элементы, как правило, добавляются в генерируемый WSDL контейнером, в который загружена реализация сервиса на основании специфицированной пользователем конфигурации (в том числе протоколов и адресов). Управление передачей сообщений в ряде реализаций вынесено в отдельные [I]сверхконтейнеры[$], на которые ложатся функции адресации и маршрутизации, переключения протоколов, преобразования сообщений, применения бизнес-правил и управления соединениями. Сверхконтейнеры могут принимать различные формы, в том числе интегрированной ESB (например, реализация разработчика Cape Clear) или расширяемой компонентной архитектуры на базе JBI (Java Business Integration; например, проекты с открытым кодом servicemix и Mule).

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































































Партнеры предоставляют сервисы с интерфейсами BuyerPT и SellerPT. Для крупнозернистых сервисов, таких как обработка заказов, типична ориентация на передачу целых документов, а не RPC-подобных вызовов с множеством именованных параметров. Новый элемент специфицирует связь, имеющую место между партнерами в рамках взаимодействия. Таким образом, BPEL расширяет понятие контракта, ограниченное в WSDL стороной провайдера. Это объясняет, почему этот элемент присутствует именно в элементе исходного WSDL. Партнерская связь Ordering специфицирует две роли, которые в данном случае являются как провайдером, так и потребителем друг для друга. Если бы ролей было больше, то элемент помог бы нам не запутаться, какие роли непосредственно контактируют друг с другом.

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

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

С точки зрения технологий реализации, теоретически может быть использован любой язык программирования и любая платформа, поддерживающая модель программирования BPEL. Практически же, такой язык сейчас только один — это сам BPEL, с его переносимым XML-словарем на базе XML Schema. Выбор контейнеров, поддерживающих «исполняемый» BPEL, очень широк и включает как коммерческие реализации (в том числе от всех ведущих разработчиков платформ), так и некоммерческие с открытым исходным кодом (ActiveBPEL, FiveSight PXE, Twister, известный в инкубаторе Apache Software Foundation под названием Agila BPEL).

Тем не менее авторами BPEL предполагалось, что не каждый захочет учить новый язык, и некоторые пользователи с готовностью пожертвуют переносимостью ради оптимизации, более широкой функциональности, доступа к унаследованным системам и использования накопленных навыков и наработанного кода. Пока же появление контейнеров, поддерживающих модель программирования BPEL на базе традиционных языков программирования (см., например, JSR 207, BPELJ и Microsoft WWF), сдерживается недостаточной стабильностью стандарта BPEL 2.0, четко разграничивающего часть языка, которая относится к «интерфейсу» процесса и часть, касающуюся его имплементации. На данный момент достаточно иметь в виду, что привязка языка программирования оркестраций BPEL к одноименной концептуальной модели не является эксклюзивной.

Предположим, что покупатель хочет создать вспомогательный сервис для внутреннего пользования, который будет выполнять функцию передачи заказа поставщику. Для адресации поставщика система-потребитель этого сервиса будет предоставлять внутренний идентификатор, а фактический адрес взаимодействия и протокол содержится в реестре UDDI (Universal Description, Discovery and Integration), в котором торговые партнеры покупателя обязаны регистрировать свои сервисы (и, соответственно, самостоятельно обновлять по мере изменения). Поскольку наш вспомогательный сервис является всего лишь посредником и логику диалога между покупателем и продавцом не модифицирует, вполне можно использовать уже имеющийся WSDL для описания процесса, но нам также понадобится элемент реестра.

Синхронное исполнение

Теперь можно приступить к реализации самого процесса:

  • order (действие ): получение заказа от внутренней системы покупателя, инициализация нового экземпляра процесса;
  • init-find_business (действие ): инициализация запроса на поиск контрагента-получателя заказа;
  • find_business (действие ): поиск контрагента в реестре;
  • init-find_service (действие ): инициализация запроса на поиск сервиса приема заказов контрагента;
  • find_service (действие ): поиск сервиса в реестре;
  • init-find_binding (действие ): инициализация запроса на поиск соответствующего интерфейса (API) нужного сервиса;
  • find_binding (действие ): поиск интерфейса в реестре;
  • set-endpointReference (действие ): присваивание адреса найденного интерфейса партнерской связи seller;
  • relay-order (действие ): передача заказа продавцу.

Рассмотрим отдельные части этого процесса.

Декларативная часть процесса предшествует элементу , в котором и содержатся действия. Сначала декларируются партнерские связи, в которых участвует процесс. Для этого используются ссылки на доступные элементы , определенные ранее в WSDL. Сам этот процесс играет роль Buyer и, соответственно, имплементирует BuyerPT:



...











...

Следом идут переменные, типизация которых может быть основана на определенных в WSDL сообщениях, элементах доступных XML-схем и простых типах XML Schema. Мы декларируем переменные для всех необходимых нам сообщений (входящих и исходящих) и переменную ссылки на сервис partnerReference. Для адресации сервисов в BPEL используется спецификация WS-Addressing 1.0, текущая на момент публикации BPEL4WS 1.1. Также нам пригодится вспомогательная переменная accessPoint для приведения типа адреса сервиса из схемы UDDI V2 (в ней содержится ненужный нам атрибут) к типу xsd:anyURI, используемому в WS-Addressing:





















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





...

Тип сообщения, принимаемого , должен совпадать с типом сообщения для соответствующей операции, декларированным в WSDL (в данном случае это tns:OrderMessage). Наш процесс ничего не передает вызывающей стороне. Если бы это было нужно, то мы использовали бы действие , которым бы завершали . В этом случае тип возвращаемого сообщения должен был бы совпадать с декларированным в WSDL типом сообщения для исполняемой операции.

Следом за идет первое действие , инициализирующее первый запрос к реестру:































В нем производится несколько операций присваивания в отношении декларированных выше переменных. Для выборки и адресации в манипуляциях над данными используется язык XPath. В BPEL существуют разные формы присваиваний, и процесс Ordering использует несколько их них. Значение tModelKey, содержащееся в запросе find_business, соответствует типу идентификатора, который содержится в данных о контрагентах, опубликованных в реестре. В следующих ниже запросах find_service и find_binding также присутствует tModelKey, но это уже ссылка на тип опубликованного в реестре интерфейса приема заказов.

Три последовательных обращения к реестру приводят к получению искомого адреса. Изюминка процесса содержится в последних двух действиях, когда адрес присваивается партнеру (set-partnerReference) и заказ передается продавцу (relay-order), на чем процесс завершается:

...





Пока процесс исключительно прост, так как содержит только два типа действий ( и , не считая изначального ), все вызовы синхронные, отсутствуют ветвление и циклы, как и генерация и обработка исключений, которые вполне могут возникнуть при работе с реестром. Каждый запрос UDDI V2 предполагает возможность исключения (см. WSDL стандарта UDDI V2), в этом случае исполнение нашего процесса будет прервано. Если бы мы хотели уведомить отправителя об ошибке, то могли бы сделать это в рамках процедуры обработки исключения, которая нами пока не предусмотрена. Такая процедура может заключаться, например, в вызове другого сервиса для журналирования ошибки или в генерации исключения процессом, чтобы передать его обработку инициировавшей процесс системе.

Асинхронные процессы

Реальные бизнес-процессы по своей природе, как правило, асинхронны. Это особенно характерно для взаимодействия административно независимых сторон (и систем), как в случае отношений покупатель-продавец. Например, если продолжить процесс Ordering получением подтверждения/отклонения от продавца, то очевидно, что он становится асинхронным, так как ответ от продавца приходит не в том же вызове, что и запрос от покупателя, а отдельным сообщением. Для этого потребуются некоторые технические изменения в WSDL и в декларативной части BPEL, а визуально процесс обретет форму.

Чтобы понять смысл добавленной части, необходимо рассмотреть соответствующий ей код:













































Действие позволяет приостановить исполнение процесса до возникновения одного из событий, описываемых элементами . В процессе Ordering такими событиями являются подтверждение или отклонение заказа, которые будут просто пересылаться системе-инициатору процесса. В случае если ни одно из событий не происходит за установленный лимит времени, исполнение процесса будет продолжено в потоке , который в данном случае содержит только BPEL-аналог «no-op».

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

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

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





...

















...

Для каждого из трех сообщений определен источник значений для свойств buyerID и orderNumber. Они служат основой для формирования правил корреляции, определяемых в теле процесса. Хотя в данном случае мы использовали XPath для привязки свойств сообщений, спецификация BPEL не исключает и применение других языков выборки. Например, возможны реализации, допускающие выборку значений свойств из двоичных файлов или из «плоского» EDI. Механизм корреляции — очень мощный инструмент в умелых руках. Правила корреляции могут быть произвольно сложными, включающими огромное количество свойств, а также пересекающихся и вложенных участков их применения. Для наших же целей достаточно всего одного правила корреляции, которое мы добавляем в модель процесса и в действие , приводящее к созданию нового экземпляра:





...



















...

В данном случае декларируется группа корреляции orderCorrelation, состоящая из свойств buyerID и orderNumber. Эти свойства инициализируются при диспетчеризации сообщения действию, в котором указана эта группа через элемент со значением «yes» атрибута initiate. Инициализации любой группы корреляции может быть осуществлена только один раз, остальные ссылки на эту группу корреляции могут служить только для сверки ее значения со значением аналогичных свойств сообщения. Любое число корреляций, как инициализируемых, так и сверяемых, может быть ассоциировано с каждым действием отправления или получения сообщений.

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

Предположим, что наш теперь уже асинхронный процесс используется по ночам, когда компания анализирует расход складских запасов за сутки и формирует множество заказов различным поставщикам. При этом для отправления каждого заказа создается новый экземпляр процесса Ordering. Число экземпляров процесса будет уменьшаться по мере получения ответов от поставщиков. Ответы будут поступать в заблокированные в ожидание их экземпляры, вследствие чего исполнение будет продолжено вплоть до завершения.

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

Даниил Фейгин (feygin@unitspace.com) — директор по технологиям компании UnitSpace (Москва), возглавляет отдел исследований и разработки и представляет компанию в международном консорциуме OASIS.

Полезные ссылки

xml.coverpages.org/BPELv11-May052003Final.pdf — спецификация BPEL4WS 1.1

xml.coverpages.org/WSBPEL-SpecDraftV181.pdf — рабочая версия спецификации BPEL 2.0

www.w3.org/TR/wsdl — спецификация WSDL

www.uddi.org — секция UDDI в OASIS

www.w3.org/Submission/ ws-addressing/ — спецификация WS-Addressing

www.jcp.org/en/jsr/detail?id=207 — описание процессов в Java, Java Specification Request 207

ftpna2.bea.com/pub/downloads/ws-bpelj.pdf — спецификация BPELJ

msdn.microsoft.com/windowsvista/building/ workflow/default.aspx — Windows Workflow Foundation

www.w3.org/TR/soap12-part1 — спецификация SOAP Messaging Framework