BPEL
Подход к интеграции автоматизированных систем и автоматизации корпоративного управления, основанный на предварительном описании бизнес-процессов, включающих в себя сервисы (услуги) предприятия и его партнеров, и последующем их исполнении и контроле с помощью автоматизированной системы, завоевывает сегодня все большую популярность. Однако для его успешного применения необходимо по-новому взглянуть на описания бизнес-процессов (регламенты, технологические схемы, сценарии и т. д.), которые традиционно составляются в текстовом виде и понятны их владельцам (т. е. руководителям и представителям компаний). Причем этот новый взгляд нужен как самим владельцам процессов, являющимся авторами описаний, так и разработчикам (техническим специалистам), реализующим эти описания в автоматизированной системе.
Слова о бизнес-процессах предприятия, объединяющих людей, документы, оборудование и т. п. в единый работающий организм, кочуют из одной публикации в другую. Мы в очередной раз читаем о том, что их (бизнес-процессы) нужно автоматизировать в рамках единой системы, которая становится активной по отношению к внешнему миру и в том числе к людям, участвующим в этих процессах. В результате система становится управляющей, а мы - владельцы процессов, сидя наверху, контролируем их исполнение и управляем как самими бизнес-процессами, так и участвующими в них людьми. В итоге же мы управляем предприятием (учреждением, корпорацией, отраслью и т. п.) в целом.
Однако затем обсуждение данной темы обычно переходит в русло технических деталей, и читатель, если он не специалист в информационных технологиях, понимает, что дальнейшее изложение к нему уже не относится. Даже если его внимание пытаются привлечь словами о том, что современные чудесные средства описания бизнес-процессов предназначены для их владельцев, он все равно в это не верит (и я склонен с ним согласиться).
Обычно владелец процесса просто пишет в текстовом редакторе своеобразный рассказ (называемый регламентом, технологической схемой, сценарием и т. п.), согласовывает его в установленном порядке и передает данный текст (возможно, с картинками) разработчику. А уже разработчик переводит это описание бизнес-процесса на язык системы.
А в чем проблема?
Проблема, как говорится, стара как мир: владелец процесса видит одно описание бизнес-процесса, а реально работает (исполняется системой) совсем другое (исполняемое описание бизнес-процесса). Насколько они соответствуют друг другу, понять принципиально сложно, потому что фактически эти описания изложены на разных языках! Как в такой ситуации управлять процессом - непонятно. Ведь успешно управлять можно только тем, что понимаешь, а делать это через "переводчика" очень непросто...
Совершенно искренне желая составить такое описание бизнес-процесса, которое было бы ориентировано на исполнение системой, его владелец сталкивается со следующими проблемами.
- Прежде всего неизвестно, какие слова (абстракции) нужно использовать для описания бизнес-процессов и как из этих слов складывать понятные системе фразы. А те абстракции, которые берутся из естественного человеческого языка, определены недостаточно строго. Главное, нет понимания того, с какой же точки смотреть на все это. Например, при взгляде изнутри организации на ее взаимодействие с партнером получится одно описание, а при взгляде "со стороны" на это же взаимодействие - другое. В результате описания получаются слишком упрощенными, так что их просто недостаточно для реализации бизнес-процессов в автоматизированной системе. (Мы имеем в виду реальные, взятые из жизни процессы!)
- Логика управления бизнес-процессом перемешана с остальной частью приложений (со сложными алгоритмами, интерфейсом пользователя и т. д.). Интуитивно понятно, что где-то граница между ними должна быть проведена, что нам следует управлять процессом на высоком уровне, не углубляясь в излишние детали. Но у каждого человека могут быть свои представления о месте этой границы.
- Существует разрыв между владельцами процессов и разработчиками, который препятствует созданию систем процессного управления. Поскольку разработчики смотрят на процесс со своих позиций и создают его описание другим способом, нежели владельцы (т. е. отвечающим особенностям механизма исполнения процессов в системе), то обеспечить эффективное взаимодействие этих двух групп специалистов в рамках проекта бывает очень сложно. Поэтому зачастую и нет понятного владельцам процесса соответствия между поведением работающей системы и тем, что написано в техническом задании на нее.
Что делать
Предлагается решать эти проблемы непосредственно в том текстовом описании бизнес-процесса, которое создается его владельцем (а также его помощниками - аналитиками, консультантами и др.) и которое должно быть ему понятно настолько, чтобы он мог поставить под ним свою подпись.
При этом необходимо сформировать определенный, достаточно строгий и одинаково понимаемый всеми заинтересованными лицами взгляд на то, что такое бизнес-процесс, из чего он состоит и каков его жизненный цикл. (Тут я уже немного забегаю вперед: еще нужно определить, что такое жизненный цикл бизнес-процесса.) Такой подход требует и новых терминов (абстракций), позволяющих описать бизнес-процесс как в статике (структура), так и в динамике (поведение).
Во всем остальном составленное описание - это обычный рассказ, повествование, построенное по правилам естественного (например, русского) языка, а не языка программирования.
Данное предложение по сути направлено на формализацию "рассказов", описывающих требования к системе. В этом смысле оно дополняет рекомендации А. Коберна по описанию требований в виде текстовых вариантов использования (use case) [].
Что касается графических описаний бизнес-процессов (рисунков, диаграмм и т. п.), то для владельца процесса они являются менее строгими и полными и служат для облегчения восприятия текста. Обсуждение подобных описаний, а также специальных инструментов моделирования выходит за рамки данной статьи.
Новый взгляд
И вот мы наконец подошли к конкретному вопросу: откуда же взять этот новый взгляд на описание бизнес-процессов? Очень хочется, чтобы он уже был достаточно проработан, популярен и открыт, т. е. не привязан ни к каким частным правам.
А ведь такой взгляд действительно есть, и изложен он в спецификации языка исполнения бизнес-процессов BPEL (Business Process Execution Language [])! Эта открытая спецификация создана совместными усилиями мировых лидеров разработки программного обеспечения и в настоящее время является стандартом де-факто. Дальнейшее ее развитие осуществляет международная некоммерческая организация OASIS [].
Уже существуют и появляются новые механизмы (engines - "движки") исполнения бизнес-процессов. После загрузки в любой такой "движок" описания бизнес-процесса, соответствующего спецификации BPEL, механизмы различных производителей автоматически и единообразно исполнят его.
Но постойте, скажет читатель, а разве BPEL - это не язык программирования?
На это можно ответить следующим образом. Данная спецификация в первую очередь содержит искомое нами детальное определение того, что такое бизнес-процесс и какие слова применяются при его описании. А уже вслед за смысловой частью идут описания конструкций языка в формате XML, которые нам (владельцам бизнес-процессов) не нужны, но которые гарантируют, что система понимает используемые там слова и выражения так же, как и мы.
Другое дело, что данная спецификация не предназначена для того, чтобы ее читали владельцы процессов, - она слишком строга для неспециалиста в сфере информационных технологий. Чтобы владелец мог использовать спецификацию BPEL, описывая бизнес-процесс в текстовом документе на естественном языке, необходим специально адаптированный комментарий к данной спецификации, где в качестве примеров будут приведены не фрагменты XML-файлов, а понятные ему образцы фраз. Думаю, такие комментарии будут появляться по мере расширения практического применения BPEL.
И еще: эта спецификация конечно же требует высококачественного перевода на русский язык. (В связи с этим замечу, что русскоязычная терминология в переводе книги [], коротко говоря, плохая.)
Но что конкретно?
Сразу оговорюсь: в рамках данной статьи невозможно в полной мере объяснить метамодель бизнес-процесса, содержащуюся в спецификации BPEL. Моя задача сейчас - только показать читателям, что она действительно существует.
В качестве примера представьте себе интернет-услугу резервирования номеров в отелях, которую Турфирма оказывает Покупателю, выступая в качестве посредника между Покупателем и Отелем (с заглавной буквы - названия ролей участников процесса). В ходе процесса Покупатель запрашивает у Турфирмы список отелей и информацию о них, сведения о наличии номеров и ценах на определенный период, а потом заказывает номера в выбранном отеле. После этого Турфирма передает запрос на резервирование номеров Отелю. Получив подтверждение, что номера зарезервированы, Покупатель оформляет в Турфирме их оплату. (Подробнее аналогичный пример рассмотрен в [].)
Используя подход BPEL, уточним приведенное выше текстовое описание. Мы говорим о том, что в данный момент составляется описание бизнес-процесса под названием "Резервирование номеров в отелях" для Турфирмы, т. е. мы описываем бизнес-процесс, исполняемый в Турфирме. Это - уточнение взгляда на процесс. (На самом деле для того, чтобы указанная интернет-услуга работала, у Отеля тоже должен исполняться процесс резервирования номеров, соответствующий процессу Турфирмы и взаимодействующий с ним.) Мы говорим о том, что у Турфирмы есть несколько сервисов (service), которые обмениваются сообщениями (message) с сервисами партнеров (partner). Сервисы - это некие (элементарные) действия, которые могут быть выполнены тем или иным приложением. А кроме того, другие автоматизированные системы могут исполнять предписанные бизнес-процессы, вызывая эти сервисы в определенной последовательности. Партнерами в данном случае являются Покупатель и Отель.
Далее мы указываем на то, что процесс длительный и обладает состоянием (state). Последнее означает, что процесс, например, "помнит" о том, что вполне определенный Покупатель ожидает подтверждения резервирования. И если он обратится к Турфирме с вопросом, подтверждено ли это резервирование (отправив соответствующее сообщение), то процесс его "узнает", поскольку хранит информацию о предыдущих действиях данного Покупателя, т. е. хранит текущее состояние процесса.
Затем мы уточняем, что система Турфирмы одновременно взаимодействует с множеством Покупателей, т. е. для каждой операции резервирования создается свой экземпляр (instance) процесса "Резервирование номеров в отелях". И каждый из них сохраняет состояние - ведь у различных экземпляров свои Покупатели, а кроме того, процессы резервирования находятся на разных этапах: один Покупатель только просматривает предложения, а другой ожидает подтверждения резервирования.
И так далее... Я надеюсь, что основная идея понятна. И хотя освоить подобный подход к описанию бизнес-процесса будет непросто, главное, что он вполне доступен владельцам процессов.
Выводы
Итак, описание, основанное на спецификации BPEL, помогает их владельцу развертывать автоматизированные бизнес-процессы, которыми он действительно может управлять:
- мы имеем продуманный и цельный подход к описанию бизнес-процессов и четко зафиксированные абстракции (слова), которые при этом используются;
- набор средств для детализации описаний бизнес-процессов ограничен спецификацией BPEL []. Если же с ее помощью нельзя описать какую-то сложную логику, значит, эта логика должна быть вынесена за рамки описания бизнес-процесса и реализована в виде сервиса, к которому будет обращаться наш бизнес-процесс. И это - не недостаток данной спецификации, а осознанное решение ее создателей ограничить сложность описания бизнес-процессов, провести границу между тем, что делает владелец процесса, а что - разработчик;
- ставя в более строгие рамки автора описания бизнес-процесса, мы вынуждаем его сосредоточиться на бизнес-стороне задачи и ориентироваться на уже действующие механизмы исполнения бизнес-процессов, а не изобретать свой собственный.
В результате мы получаем документ, понятный гораздо более широкой аудитории, в том числе и разработчику системы. Теперь он не создает описание бизнес-процесса "с нуля", а только уточняет существующее, полученное от владельца процесса, а затем излагает его в строгой форме, полностью соответствующей спецификации BPEL, используя необходимые инструментальные средства моделирования. Поэтому и результат - описание исполняемого процесса - остается понятным его владельцу. Спецификация BPEL выступает в качестве соглашения между владельцем процесса и разработчиком системы и потому в случае разногласий или взаимного непонимания может играть роль справочника.
Литература
1. Коберн А. Современные методы описания функциональных требований к системам. М.: Лори, 2002. См. также домашнюю страницу А. Коберна в Интернете: http://alistair.cockburn.us/.
2. Спецификация языка BPEL версии 1.1, www.ibm.com/deve-loperworks/webservices/library/ ws-bpel/.
3. Рабочие документы спецификации языка WS-BPEL версии 2.0 - на сайте OASIS: www. oasis-open.org/committees/documents.php?wg_abbrev=wsbpel.
4. Clune Jim. BPEL in Service-Oriented Architecture". - www. sys-con.com/story/7storyid=47 666 &DE-1.
С автором, ведущим аналитиком отделения системного анализа департамента интеграционных решений IBS, можно связаться по адресу: YVolkov@IBS.RU.
