6.3.5. Соотношение языков.

В 2000 г. появилась коалиция BPMI, которая достаточно быстро разработала основанный на технологии Web-сервисов язык определения бизнес-процессов BPML и начала создание других полезных стандартов (не совместимых со стандартами WfMC). Через некоторое время коалиция BPMI подготовила стандарт графических диаграмм, описывающих WF-процесс - BPMN. Язык также содержал правила автоматического перевода графических диаграмм BPMN в язык BPML [117].

Однако вслед за объединением IBM, Microsoft и BEA и созданием новой коалицией другого WF-языка, также основанного на технологии Web-сервисов (BPEL4WS), в рядах коалиции BPMI началась паника. Прогнозы абсолютного большинства экспертов говорили о том, что IBM, Microsoft и BEA “продавят” свою спецификацию и именно BPEL4WS станет стандартом де-факто в качестве языка определения бизнес-процессов. Был период, когда BPMI позиционировало язык графических нотаций BPMN как графическую оболочку для BPEL4WS. Однако в настоящее время коалиция реанимировала BPML и предлагает экспорт из BPMN как в BPML, так и в BPEL4WS [117].

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

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

Идеологически языки BPEL4WS и BPML очень похожи. Нам кажется, что BPML проще и удобнее, чем BPEL4WS, однако за BPEL4WS стоят такие корпорации-гиганты, как IBM, Microsoft, BEA, SAP и Siebel, и вполне возможно, что благодаря “маркетинговой мощи” этих компаний язык BPML будет полностью вытеснен языком BPEL4WS.

Ситуация с BPMN оказалась тоже далеко не безоблачной. OMG-группа разработала диаграмму Activity в языке UML 2.0, эта диаграмма - в некотором смысле альтернатива языку BPMN, а по графической выразительной силе эти нотации примерно одинаковы. Мы считаем, что для описания бизнес-процессов в настоящее время BPMN все же удобнее, чем Activity-диаграмма языка UML 2.0, однако вполне можно ожидать, что в следующей версии языка UML Activity-диаграмма вберет в себя все текущие преимущества BPMN и за счет маркетингового веса OMG именно диаграмма Activity UML, а не BPMN может стать фактическим стандартом графической нотации.

При этом сама спецификация BPMN не определяет формата файла, в котором можно сохранять описание и которым можно обмениваться, однако уже есть как минимум одна спецификация, описывающая этот формат - это XPDL. В спецификации XPDL v.2.00 [http://yurivolkov.com/ articles/Diagrams_for_business_ processes_ru.html#_Ref4] явно указано, что одно из её назначений - служить описанием формата файла для нотации BPMN. Т.е. XPDL позволяет хранить не только логику процесса (как и BPEL, другая спецификация формата описания бизнес-процесса, понимаемого машиной), но и его графическое BPMN-представление. Таким образом, формат файла BPMN уже существует, что позволяет "понимать друг друга" различным инструментальным средствам моделирования.

При этом шум, создаваемый в основном усилиями Microsoft, IBM и Oracle, привел к тому, что BPEL воспринимается как если не единственный, то основной стандарт в области систем менеджмента бизнес-процессов. В связи с этим представляют интерес две недавние заметки в ebizq.net.

Первая принадлежит Sandy Kemsley, известному аналитику в области BPM: «Assorted thoughts on BPEL» («Избранные мысли о BPEL»). Отмечая, что BPEL не продвинулся ни на шаг с 2005 г. и так остался в состоянии whitepaper, а также тот факт, что сложность BPEL не допускает использования его аналитиками, Sandy приходит к следующему выводу: «BPEL становится скорее формальным пунктом в опросном листе, чем реальным требованием – большинство организаций-заказчиков слабо представляют себе для чего он им нужен.» С другой стороны, тем, кто разрабатывает сложные сценарии взаимодействия веб-сервисов, возможностей BPEL не хватает и они возлагают надежды на зарождающийся стандарт WS-CDL: Web Services Choreography Description Language [http://www.ebizq.net/blogs /column2/2007/03/assorted_though.php].

Во второй заметке с красноречивым названием  «Is XPDL the Silent Workhorse of BPM?» («XPDL – рабочая лошадка BPM?») обосновываются следующие тезисы [http://www.ebizq.net/topics/human_centric_bpm/features/ 7852.html]:

• Из 10 стандартов, работа над которыми велась в 2003 г., сегодня, в результате прекращения работы над одними и консолидации других, осталось три: BPMN, XPDL, BPEL. Вопреки распространенному мнению, эти стандарты не конкурируют друг с другом. Явно отдельное положение занимает BPMN: это система условных обозначений и правил рисования диаграмм, доступная для понимания всех заинтересованных лиц – и бизнес-аналитиков, и менеджеров, и технических специалистов.

• Разница между BPEL и XPDL не столь очевидна, но тоже существенна. BPEL – это своего рода «машинный код», исполняемый язык, при помощи которого программируется последовательность вызова веб-сервисов. В конечном счете, BPEL манипулирует битами и байтами, пересылаемыми из одной точки в другую.

• XPDL был разработан WfMC для хранения и обмена диаграммами процессов между программными инструментами, один из которых предназначен для моделирования процесса, другой для чтения и редактирования, третий для исполнения процесса внутри BPM-«движка» и т.д. Примечательное отличие XPDL от BPEL в том, что он обеспечивает взаимно-однозначное представление для BPMN-диаграмм. Преобразование же из BPMN в BPEL является односторонним, аналогично компиляции из языка высокого уровня в машинный код.

• Иногда высказываемое мнение о том, что XPDL мертв или не относится к делу, свидетельствует только о плохой информированности. На сегодня XPDL поддерживает около 50 вендоров, включая таких энтузиастов BPEL, как IBM и Oracle, и 8 из 11 лидеров рынка BPMS по версии Gartner'2006. XPDL является стабильным стандартом на протяжении многих лет, и вы можете быть уверены, что XPDL V.3, когда бы он не появился, и инструментарий, который с ним будет работать, сможет прочесть те схемы, которые вы создаете при помощи XPDL сегодня. К тому же он общедоступен, не будучи связан никакими лицензионными ограничениями.

Не получая такой же шумной рекламы, как «некоторые другие стандарты», заключает автор Jon Pyke, XPDL молча делает то, что ему положено.

Сравненивая же BPML и XPDL, специалисты говорят следующее (см., например, [115]).

Язык BPML существенно “легче” языка XPDL. В нем не надо описывать внешние приложения (Applications в XPDL). Эти функции “перекладываются” на технологию Web-сервисов. Не надо определять и “присоединять к Activities” переходы. Архитектура связей определяется вложенностью тегов, соответствующих элементам Activity. В BPML нет понятия Transition. Не надо в рамках языка специально определять описание участника бизнес-процесса. Все участники - это Web-сервисы. Следовательно, соответствующие описания отвечают спецификации Web-сервисов.

Кроме того, для работы с бизнес-процессами, написанными на XPDL, требуются дополнительные спецификации. В частности, они указывают, каким образом можно “сообщить” определенной Activity, что она выполнена и управление может двигаться дальше, и т. д. В соответствии с идеологией языка XPDL среда, в которой выполняется бизнес-процесс, не является активной; активными должны быть внешние участники, а среда выполнения процесса только реагирует на их действия.

“Идеология” языка BPML скорее противоположна - в ней бизнес-процесс может быть активным и давать задания участникам-исполнителям. Исполнители, являясь Web-сервисами, могут “ничего не знать” о бизнес-процессе, в котором они участвуют.

Однако отказ от понятия Transition и замена его вложенностью тегов приводят к тому, что граф, соответствующий бизнес-процессу, в BPML не может быть графом произвольной структуры, например, он не может содержать сложные циклы. Вследствие этого в BPML невозможно реализовать WF-паттерн “Произвольный цикл”. Для того чтобы выполнять повторяющиеся последовательности шагов, в BPML введено несколько типов Activity-циклов, однако в этом случае циклически повторяться может только содержащаяся внутри данной Activity последовательность узлов. Отсутствию произвольных циклов в бизнес-процессе можно поставить в соответствие аналогию программирования “без goto”.

В BPML параллельно выполняющиеся ветви процесса могут дополнительно обмениваться сигналами, производя, таким образом, синхронизацию. Трудно сказать, облегчает это понимание бизнес-процесса или, наоборот, затрудняет. В силу того, что язык BPML основан на тегах, в нем легко организовать генерацию и обработку исключений. А не будучи явно основанным на теории графов, он позволяет реализовать WF-паттерн “отложенный выбор”. В BPML поддерживаются такие концепции, как транзакции и расписания. В нем можно устанавливать задержки и deadlines.

Недавно и в XPDL появились понятия TimeOuts и Exceptions, однако функциональность их заметно ниже соответствующих конструкций BPML.