Современные стандарты описания и исполнения бизнес-процессов

Артамонов И.В., преподаватель БГУЭП

«Процессное направление» современной индустрии информационных технологий активно развивается. С начала 2000-х годов в отрасли появилось множество терминов и аббревиатур, так или иначе связанных с бизнес-процессами: BPM (Business Process Management), BPMS (Business Process Management System), BPMN (Business Process Model and  Notation), BPEL (Business Process Executable Language), BPML (Business Process Modeling Language), BPI (Business Process Integration), BPSS (Business Process Specification Schema), BI (Business Intelligence), BMM (Business Motivation Model), BPDM (Business Process Definition Metamodel),  BPMM (Business Process Maturity Model). За некоторыми аббревиатурами скрываются комплексы информационных систем поддержки бизнес-процессов, подходы к описанию, моделированию и исполнению бизнес-процессов, общепринятые и нишевые, активно использующиеся и возможно уже устаревшие (всего за несколько лет) стандарты.

На данный момент сформировались и используются несколько стандартов описания бизнес-процессов. Отметим, что из данного обзора намеренно исключены нотации описания бизнес-процессов, разработки которых были завершены до 2000 года, такие как, например, IDEF, DFD, EPC. Как отмечают многие специалисты, например Ю.Волков в [17], George Lawton в [18], или [19] диаграммы IDEF и EPC позволяют описывать бизнес-процессы, однако обладают низким уровнем выразительности, точности и однозначности, который не позволяет создавать объективные модели процессов организации и вынуждается аналитиков и разработчиков создавать дополнительные документы, описывающие те или иные особенности бизнес-процессов. Это положение негласно, но явно подтверждают крупнейшие разработчики современных CASE-средств (вообще вопрос принадлежности современных пакетов BPEL / BPM  к классу CASE требует отдельного обсуждения) для разработки и описания бизнес-процессов: диаграммы IDEF, DFD, ERD используются лишь для поддержки ранее собранных документов и преобразования их к современным стандартам.

Анализ литературы (например [2], [3], [4], [5], [6], [7], [11],  [8], [9], [10], [16]) и официальных каталогов стандартов (например [12], [13]) позволил выделить такие стандарты описания, реализации и взаимодействия бизнес-процессов как BPMN, UML, BPEL, XPDL, WS-CDL, JPDL, XLang, BPML, WSFL, WSCL, BPSS, WSCI.

Рекомендуем

Узнайте больше про ECM из вебинаров

Анализ стандартов

Приведем таблицу, предложенную М. Романовым [11], и дополним ее.

Эти стандарты стали разрабатываться в ответ на потребности рынка информационных технологий для бизнеса в начале 2000-х. В тот момент обострились проблемы интеграции разнородных приложений на одной технологической площадке, проблемы поддержки унаследованных приложений и данных, появилась концепция веб-служб, стали активно развиваться технологии управления бизнес-процессами (BPM), а вслед за этим появилась и парадигма сервис-ориентированной архитектуры (СОА). Эти и другие вызовы рынка заставили крупнейших поставщиков, развивая свои предложения, разрабатывать внутрикорпоративные стандарты поддержки бизнес-процессов для их описания, реализации  и исполнения в рамках своих программных систем. Было опубликовано множество спецификаций, таких как JPDL, XLang, BPML,  WSFL , WSCL, BPSS, WSCI, которые поддерживались отдельными конкурирующими продуктами. Часть этих стандартов наследовалась из workflow-языков 90-х [30], [34], часть – для поддержки работы отдельных приложений, часть – была разработана специально для поддержки веб-служб.

Развитие этих стандартов схоже с историей технологий распределенного компонентно-ориентированного программирования. Основной проблемой развития этого направления, как отмечает В.Кулямин [21], стали закрытые, нишевые стандарты, которые, ввиду постоянной конкуренции таких производителей как Microsoft и SUN, также постоянно изменялись и были слабо совместимы даже между ближайшими версиями. Такая скачкообразная и необоснованная эволюция, закрытость форматов данных и «сильная связанность» компонентов (и некоторые другие причины) привели к отрицанию мировой общественностью компонентной модели как надежного средства интеграции разнородных приложений и построения гибких распределенных систем. В связи с этим стала развиваться концепция веб-служб, в корне своем отвергающая недостатки компонентно-ориентированной разработки, веб-сервисы реализовывали бизнес-процессы, и те и другие описывались с помощью стандартов JPDL, XLang, BPML, WSFL, WSCL, BPSS, WSCI. В итоге, в начале 2000-х ситуация, приведшая к депопуляризации компонентно-ориентированной разработки, начала назревать и в средствах описания и реализации бизнес-процессов и веб-служб: на рынке существовало не менее десяти группировок, определяющих BP-* стандарты [47] и протоколы взаимодействия и описания веб-служб.

Однако привлечение опыта разработки открытых стандартов интернет-консорциума W3C и открытых стандартов веб-служб консорциумом OASIS позволило таким крупнейшим поставщикам как Microsoft, Intalio, SAP, IBM, Oracle, JBoss, Adobe, BEA собрать воедино опыт разработки стандартов и предложить единые спецификации описания служб и процессов, например, для создания BPEL [22]. Этой точки зрения придерживается, например, Ю.Волков в [17]: «Прошло то время, когда спецификации описания бизнес-процессов создавались для собственных нужд: сегодня такой роскоши (или такого убожества) не могут позволить себе даже IBM и Microsoft. Спецификации разрабатываются и открыто обсуждаются годами, причём этим уже не занимаются сами корпорации: для того, чтобы международное сообщество не похоронило эти "закрытые спецификации" только из-за их закрытости. Разработка глобальных спецификаций (открытых стандартов) - удел международных некоммерческих организаций (консорциумов), в которые входят представители всех заинтересованных сторон.» Таким образом, такие стандарты как JPDL, XLang, WSFL, WSCL, BPSS, WSCI, BPML были полностью или частично заменены [8] совместно разработанным языком BPEL. Причем BPML и WSCI также разрабатывался консорциумами крупных разработчиков, но как после «жарких» дискуссий в прессе в 2002-2005-х годах (например, в [23], [24], [25]), так и ввиду того, что BPEL поддерживался такими крупными корпорациями как IBM, Microsoft и BEA,  предпочтение, как показала практика, было отдано BPEL. Впрочем, это не мешает ему «почти» конкурировать со стандартом XPDL, поддерживаемым Workflow Management Coalition, куда входят такие крупные поставщики как Adobe Systems, Fujitsu, TIBCO Corporation, BEA Systems. Последняя в этом списке компания, BEA Systems, в 2008 году была приобретена компанией Oracle, а в конце 2009 Oracle выкупила Sun, крупного поставщика программных и аппаратных решений, поддерживающего развитие java-проектов (отметим, что на протяжении уже нескольких лет компания Oracle каждый месяц покупает компании конкуренты или нишевых поставщиков, усиливая линейки своих продуктов [26]). Такая тенденция слияний и поглощений, особенно в пост-кризисный период позволяет рассчитывать на дальнейшее объединение и унификацию стандартов. Подробнее о борьбе коалиций компаний за стандарты и историю их развития можно почитать у А. Михеева, М. Орлова в [33].

Так, к 2008-му году список развивающихся и поддерживаемых стандартов сократился до BPMN, UML, BPEL с расширениями,  XPDL, WS-CDL, ebXML.

Причем пара BPMN и UML (в основном диаграммы деятельности) предназначена для графического описания процессов, XPDL и BPEL для описания оркестровки процессов, а WS-CDL и ebXML для описания хореографии. Хотя опыт практического применения показал, что некоторые распространенные стандарты волей вендоров неплохо справляются и со смежными областями [37], поддержка крупнейшими производителями практически сдвигает непопулярные стандарты в ниши или в «опциональные» свойства продукта, и поэтому этот список можно сократить до BPMN, XPDL, BPEL.

Business Process Executable Language

Представленная русскоязычная литература о BPEL носит несколько устаревший характер. Пик публикаций о BPEL пришелся на 2004-2005 года, за несколько лет до утверждения спецификации WS-BPEL 2.0. Этот стандарт описан в соответствующем разделе официального сайта консорциума OASIS [29]. Отличия BPEL 1.1 от WS-BPEL 2.0 описаны в третьей части техническом обзоре WS-BPEL 2.0 от OASIS [40]. Или в описании стандарта BPEL на сайте Oracle [41].

BPEL – это XML-подобный язык описания поведения бизнес-процессов и последовательности их вызовов. Немного более развернутое и интересное определение дает Ю. Волков [42]: «BPEL определяет модель и грамматику для описания поведения бизнес-процессов, основанных на web-сервисах, в терминах длительных, обладающих состоянием взаимодействий (состоящих из обмена сообщениями) между процессом и его партнёрами». Процессы могут не только вызывать веб-службы для реализации определенных функций, но и сами представляться в виде веб-служб. Такую возможность отобразить процессы и потоки работ на совокупность веб-служб Д. Рапоза  назвал [43] главным преимуществом BPEL. Наряду с элементами, которые BPEL вобрал в себя из моделей workflow (ветвление и объединение процессов, параллелизм и под-процессы), в нем поднимаются вопросы асинхронного взаимодействия, поведения на случай возможных ошибок. BPEL иcпользует WSDL для описания интерфейсов веб-служб, что позволяет легко интегрировать их с другими приложениями и процессами и, как обычный язык программирования, процесс может быть описан на нем и выполнен вручную, но чаще всего автоматически генерируется из workflow-диаграмм.

Введем понятия оркестровки и хореографии бизнес-процессов.

Оркестровка - это описание внутреннего бизнес-процесса предприятия в виде потока взаимодействия между внутренними и внешними для организации веб-сервисами [48]. При оркестровке существует некий центральный процесс, который управляет вызванными веб-службами и операциями. Вызванные веб-службы не знают, что они были вызваны как часть от бизнес-процесса более высокого уровня. Оркестровка отличается явными описаниями операций и порядком вызова служб.

Хореография - это определение последовательности условий, при соблюдении которых несколько независимых участников обмениваются сообщениями с целью выполнения некоторой общей бизнес-задачи [48]. Здесь нет центрального координатора, наоборот, каждая веб-служба, вовлеченная в хореографию, знает точно, когда и с кем нужно взаимодействовать. Каждый участник хореографии должен знать о всех выполняемых бизнес-процессах, операциях, сообщениях и настройках для их обмена.

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

В BPEL бизнес-процессы можно описать двумя способами:

1. Описав детально бизнес-процесс. Такой процесс будет исполняемым и будет отвечать принципам оркестровки. Он определяет четкие алгоритмы работы, задает набор выполняемых служб и определяет входящие / исходящие сообщения. Этот процесс выполняется в BPEL-движке.

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

В общем случае BPEL-скрипт включает:

●   Корневой тег <Process>

●   Блок импорта WSDL или другой схемы для определения типа данных и интерфейса служб.

●   Ссылки на участников процесса, которые позволяют определить роли и взаимодействующие процессы.

●   Переменные, используемые процессом, описанные в терминах WSDL или используемой XML-схемы.

●   Обработчики ошибок и событий

●   Последовательности действий (activities)

Команды BPEL называют  activities (букв. с англ. «действия»). Их можно разделить на 4 типа:

1.     Коммуникации, например:

●   Вызов операции веб-службы (<invoke>)

●   Ожидание внешнего сообщения  (<receive>)

2.     Управление, например:

●   Разветвление с использованием «case» (<switch>)

●   Цикл (<while>)

●   Показывает, что потоки должны быть выполнены параллельно (<flow>)

●   Ожидание (<wait>)

●   Определить последовательность шагов для выполнения в специфическом порядке (<sequence>)

●   Выполнить один из несколько альтернативных путей (<pick>)

3.     Ошибки, например:

●   Индикация о произошедшей ошибке или когда что-то пошло не так (<throw>)

4.     Другое, например:

●   Копирование данных (<assign>)

●   Генерация ответа для входа / выхода (<reply>)

●   Уничтожить экземпляр службы (<terminate>)

●   Ничего не делать (<empty>)

Подробнее о семантике BPEL можно узнать в официальной спецификации стандарта в [22], в дальнейшем в статье будет более подробно рассмотрена его роль через взаимосвязь с другими стандартами.

XML Process Definition Language

Текущая версия XPDL – 2.1а, представленная на сайте Workflow Management Coalition [49]. XPDL (XML Process Description Language) – XML-ориентированный формат проектирования процессов и обмена информацией о них между различными утилитами моделирования и исполнения бизнес-процессов. XPDL основан на языке WPDL (Workflow Process Definition Language, кр), который WfMC разрабатывала с начала 90-х для поддержки workflow-систем.

XPDL  определяет XML-схему, которая используется для спецификации декларативной части процесса. В отличие от BPEL, XPDL – это не исполняемый язык, XPDL – это формат, определяющий синтаксис для хранения моделей и графической информации бизнес-процессов.  Поэтому основным назначением XPDL является поддержка хранения диаграмм процессов между программными инструментами, один из которых может быть предназначен для моделирования процесса, другой для чтения и редактирования, третий для исполнения процесса и  т.д. [2]. Стоит отметить также возможность двустороннего преобразования процессов из BPMN в XPDL и обратно, в отличие от BPMN в BPEL, где это преобразованием одностороннее. Официальная спецификация XPDL, сравнивая его с BPMN, говорит о том, что и BPMN, и XPDL решают один и тот же комплекс проблем моделирования процессов, но разными путями. XPDL – это обмен моделями между инструментами, BPMN – обмен графическими представлениями о процессах между пользователями, бизнес-аналитиками и техническими специалистами. 

Наличие поддержки XPDL в BPM-связных системах существенно облегчает возможность интеграции этих систем между собой. При этом можно, например, использовать уже разработанные в одном средстве диаграммы моделей, чтобы исполнять их на новом «BPM-движке». Некоторые (сравнительно немногие, если верить официальным данным WfMC)  BPM-движки могут обрабатывать XPDL напрямую, некоторым же необходимо преобразовать поток процесса в BPEL или в более низкоуровневый язык, Java, C#,Ruby, и пр.  Таким образом, пользователи BPM-систем в зависимости от реализованного функционала: во-первых, или они «рисуют» диаграммы с помощью BPMN, сохраняют в XPDL в процессе разработки, и преобразуют в BPEL для исполнения в BPM-движках, или, во-вторых, используют цепочку трансформации BPMN=>BPEL=>[Специфический язык исполнения BPM] (особо для поддержки оркестровки бизнес-процессов, что хорошо поддерживает BPEL), или, в-третьих, пользуются цепочкой BPMN=>XPDL=>[Специфический язык исполнения BPM] (если необходима поддержка возможностей, отсутствующих в BPEL). Хотя, возможно, органичная комбинация BPEL, BPMN, XPDL в рамках одной системы или предприятия позволит избежать жесткой привязки к определенному поставщику [57].

Одним из важнейших свойств XPDL Кейт Свенсон (Keith Swenson), считает возможность его расширения [2]. Язык поддерживает возможность введения дополнительных атрибутов, которые производитель ПО может вводить для своих целей. Например, одна утилита может вводить определенные требования на диаграмме, сохраняя их через расширенные атрибуты. Другая утилита, естественно, эти расширения распознать и адекватно обработать не сможет, но может их сохранить в модели, и, в случае необходимости, вернуть обратно. С другой стороны, возможности расширения и поддержки элементов и атрибутов именно для исполнения процессов некоторые аналитики считают недостаточными, выходящими за рамки возможностей XPDL 2.1 [53].

По данным консорциума WfMC [50] список продуктов разных производителей, поддерживающих XPDL тем или иным образом достаточно широк. XPDL используется для хранения диаграмм или в качестве формата для импорта / экспорта. Так, Кейт Свенсон называет XPDL «форматом поддержки диаграмм бизнес-процессов на долгие годы, так как его поддерживают множество вендоров, а WfMC обеспечит полную совместимость следующих версий XPDL с более старыми». Однако это утверждение легко оспаривается другими аналитиками: среди этих производителей нет ведущих вендоров BPM или нет их ведущих продуктов [53]. Измаеля Халими [52]  отмечает, что в XPDL-код, который генерирует большая часть утилит, вкладывается лишь малая часть от семантики, необходимой для выполнения процесса. При портировании диаграмм с одного инструмента в другой нередко бизнес-аналитики должны исправлять или дополнять модели, таких недостатков лишен, например, BPEL, один и тот же код которого успешно выполняется на разных BPM-платформах. Поэтому, отмечают Халими и  Скотт, при выборе определенного продукта, нацеливаясь на поддержку стандартов и множества различных поставщиков, стоит убедиться, что выбранные продукты действительно поддерживают заявленный или необходимый уровень переносимости процессов через XPDL.  Себастьян Штайн (Sebastian Stein) показывает два неудобства при использовании XPDL [51]: в-первую очередь, это слишком большой объем официальной спецификации, часть которой не описывает XPDL напрямую, а во-вторых, несмотря на то, что именно форматы XPDL и BPMN чаще всего вынуждены работать «в паре», они поддерживаются разными консорциумами, которые почти не взаимодействуют друг с другом, вернее консорциум OMG, работая с BPMN, не взаимодействуюет с WfMC [61], но WfMC  приходится ориентироваться на работы при разработке XPDL: Кейт Свенсон, как всегда, аргументируя в поддержку XPDL [54], заявляет, что при подготовке спецификации XPDL 2.1 стандарт BPMN был детально проанализирован для поддержки в новом формате XPDL  и утверждает в [55], что XPDL описывает все, что может быть «нарисовано» в BPMN.  И сейчас вероятность того, что XPDL станет предпочтительным форматом хранения для BPMN 2.0, по словам Скотта Френсиса (Scott Francis), достаточно низка.

Некоторые аналитики считают XPDL и BPEL (например в [11], [4]) прямыми конкурентами, но ошибочность этого утверждения не раз доказывалась на страницах авторитетных изданий. Например, официальный сайт консорциума Workflow Management Coalition (разработчик XPDL) в [27] определяет BPEL и XPDL как «всецело и совершенно различные стандарты». Кейт Свенсон в [2] сравнивает два стандарта, выделяя важные отличия: BPEL – исполняемый язык (это, кстати, явно следует из названия). Это язык программирования с переменными и операторами. XPDL – формат проектирования процессов, отвечающий за хранение и прорисовку описания процесса. Цель BPEL – предоставить описание для оркестрации веб-служб, в основе которой лежит последовательность операций, потоки данных от точки к точке. Цель XPDL – хранение и обмен диаграммами процессов. Он позволяет в одном инструменте создать диаграмму, в другом ее прочитать, и изображения будут практически идентичными. 

Кейт Свенсон показывает отличия на диаграмме (см. рис. 1) . На верхнем уровне расположены различные инструменты проектирования. В нижней части диаграммы – различные среды исполнения. XPDL используется для переноса проекта процесса между инструментами. XPDL, BPEL или другой специфический язык может использоваться для связи выполняемого процесса и «движка» выполнения.

рис. 1 Взаимоотношения двух BPM-систем с точки зрения обмена описаниями процессов

В общем случае любой инструмент описания процесса требует перевода описания в формат, определяемом движком и исполняемый код от одной утилиты не будет работать в движке другого производителя.  XPDL поддерживает двустороннее преобразование с BPMN, BPEL же не гарантируется схожести кода в процессе преобразования BPMN - > BPEL -> BPMN. Брюс Сильвер в [38] выступил с уточнением логики Кейта Свенсона [39] и указал на ряд недоговоренностей, намеренно допущенных автором в целях рекламы стандарта XPDL. XPDL охватывает диаграммы процесса, BPEL – его семантику.  По словами Б. Сильвера К. Свенсон намеренно умолчал об отличиях между диаграммой и моделью процесса и о возможности отображения языками BPEL и XPDL именно процессной модели. Именно поэтому сравнение о переносимости формата XPDL по сравнению с BPEL данное в [2], [39] не совсем верно. BPEL более переносим между движками BPM, когда нужно сохранить семантику процесса. XPDL необходим для работы с одной и той же диаграммой в различных инструментах проектирования. XPDL хранит и описывает диаграмму процесса, а не его модель.  Сэнди Кимсли (Sandy Kemsley), независимый системный аналитик и BPM-архитектор, в [37] обсуждает сравнение двух языков от Workflow Management Coalition [27] и отмечает, что на практике очень мало производителей используют BPEL как язык исполнения процессов в чистом виде. Они используют его и как формат обмена данными, что вызывает ряд споров о конкуренции XPDL и BPEL. XPDL, в свою очередь, поддерживая графическое представление процессов также хорошо, как информацию о исполнении, способен описывать все, что разрабатывается силами BPMN.  Поэтому XPDL и BPEL несравнимы в том смысле, что один не может заменить другой, однако вполне сравнимы как форматы обмена информацией о процессах, только разными способами и в разных инструментах.

Business Process Model and  Notation

BPMN – графическая нотация для моделирования бизнес-процессов. BPMN изначально был разработан консорциумом BPMI, а на сегодняшний день поддерживается OMG после того, как эти две организации объединились.

Основная цель BPMN – поддержка нотации, которая одинаково будет пониматься всеми участниками бизнеса, от бизнес-аналитиков, которые разрабатывают эскизы процессов, разработчиков, которые реализуются технологию для выполнения этих процессов, и до бизнесменов, менеджеров, которые будут управлять и наблюдать за процессами. Таким образом, отмечает официальная спецификация, BPMN – это «мост» между этапами разработки и реализации бизнес-процессов. В отличие от многих других спецификаций, BPMN разрабатывался исключительно для описания бизнес-процессов и поэтому, по сути, поддерживает лишь один тип диаграмм – диаграммы бизнес-процессов.  К.Е. Самуйлов в [48] подчеркивает, что BPMN, являясь графической нотацией «третьей волны» моделирования бизнес-процессов, во многих отношениях превосходит традиционные нотации. Он позволяет моделировать взаимодействие внешние и внутренние бизнес-процессы компании, поддерживает механизмы моделирования передачи сообщений и обработки исключительных ситуаций. Другой не менее важной целью является поддержка визуализации в бизнес-нотации XML-языков, ориентированных на выполнение бизнес-процессов (например, BPEL).

OMG позиционирует стандарт как вобравший в себя все лучшие идеи, концепции и опыт других нотаций моделирования процессов, таких как ML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains.

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

●   Flow Objects (объекты схемы, объекты потока управления) – основные графические элементы, которые описывают поведение бизнес-процесса. Включают три элемента:

●   Event (Событие) означает нечто, которое «происходит»  по время процесса. События изображаются окружностью с рисунком в центре для выделения отдельных подтипов.

В процессе можно выделить:

●   начальные (start) события – указывают на начало процесса

●   промежуточные (intermediate) события – указывают, что что-то произошло где-то между началом и окончанием процесса.

●   завершающие (end) события – указывают на завершение процесса.

В стандарте BPMN 1.2 события делили также на две группы: события генерации и обработки. События обработки реагируют на определенный триггер, к таким событиям относятся все начальные и некоторые промежуточные. События обработки возвращают некий результат, к таким событиям относятся все завершающие и некоторые промежуточные события. В BPMN 2.0 группировка усложнилась, начальные и промежуточные события стали разделять для разных типов процессов и прерываний.

Activity (Действие) – это работа, которая выполняется в бизнес-процессе. Это исполняемый элемент BPMN-диаграммы. Действие может быть атомарным или составным. Отображается прямоугольником с закругленными углами.  Определено 3 типа действий:

●   Задача (task) это атомарное действие в потоке процесса. Задача используется тогда, когда процессе не может быть более детализован. В общем случае задачи выполняет пользователь или приложение. Отдельно стоит выделить задачи, решаемые с привлечением людей. BPMN выделяет два типа таких задач: ручные (manual task) и пользовательские (user task). Пользовательская задача исполняется и управляется в среде бизнес-процесса, например, это некоторое действие пользователя для реализации БП с помощью ПО, а ручная задача не контролируется системами управления бизнес-процессами. Это может быть, например, установка техническим персоналом телефона для клиента. Задача изображается прямоугольником со скругленными краями.

●   Под-процесс (sub-process) – действие, которое может быть детализировано на другие действия, события, логические операторы и потоки управления. В старых версиях BPMN вместо под-процесса выделяли Транзакцию (transaction), однако сейчас она рассматривается как специализированный тип под-процесса. Задачи и подпроцессы могут быть снабжены определенными маркерами, указывающими некоторые характеристики их выполнения.

●   Транзакция – это набор логически связанных действий. В случае отмены транзакции происходит отмена всех действий транзакции в обратном порядке их выполнения. В случае сбоя транзакции она прерывается без компенсации и обработка ошибки переходит к соответствующему событию. Транзакция изображается прямоугольником со скругленными краями и двойными границами.

Вызывающее действие (call activity) позволяет включать повторно используемые глобальные задачи и процессы в диаграмму и идентифицируют точку их входа в процесс. Изображается прямоугольником со скругленными краями и толстой линией границы.

Gateways (Логические операторы) необходимы для контроля над объединением и разветвлением потоков управления процессами. Прямой перевод слова как «ворота, шлюз» предполагает наличие некоего шлюзового механизма, который разрешает или не разрешает потоку управления проходить через себя, при этом поток может быть как разделен на альтернативные ветви, так и альтернативные ветви могут объединиться. Логические операторы определяют все типы поведения потока с условиями включения, исключения, сложными условиями, объединениями и разветвлениями. Логический оператор изображается «алмазом», внутри которого изображается тип операции.

●   Исключающий логический оператор (exclusive gateway, оператор исключающего «ИЛИ») применяется для создания альтернативных потоков процесса или для их объединения. Это базовый способ разделения / объединения потока процесса. При разделении может быть выбрана только одна ветвь, при объединении оператор ожидает завершения любой их входящих ветвей. Этот оператор может помечаться знаком «Х» в центре «алмаза». В случае, если ни одно из условий оператора не находится в состоянии «истина», выполнение может быть передано по ветви, определенной разработчиком «по умолчанию».

●   Включающий логический оператор (inclusive gateway, оператор включающего «ИЛИ») применяется для создания одного или нескольких альтернативных параллельных путей в потоке процесса. В отличие от исключающего оператора, все условия входа в оператор должны быть выполнены (все входящие ветви должны быть завершены). Изображается знаком окружности «О» в центре «алмаза». Ветвь по умолчанию создается для аналогичных с исключающим оператором условий.

●   Параллельный логический оператор (оператор «И») используется для синхронизации и создания альтернативных потоков. Изображается знаком «+». Параллельные потоки создаются без какой-либо проверки условий. При объединении потоков оператор ожидает завершения всех входящих ветвей перед тем как активировать исходящую.

●   Сложный логический оператор (complex gateway) используется для моделирования сложных ситуаций синхронизации. Например, для активации исходящего потока оператор может потребовать завершения трех из пяти входящих ветвей. Использование этого оператора нежелательно, так как оно затрудняет понимание диаграммы.

●   Событийный логический оператор (event-based gateway) используется для ветвления потока процесса на основе «срабатывания» определенных событий, в отличие от вычисления условных выражений с использованием данных процесса (как в вышеописанных операторах). Например, компания может ожидать ответа заказчика. Если он скажет «Да» - нужно будет провести один комплекс действий, а в случае «Нет» - совершенно другой. Ответ заказчика и идентификация сообщения определяют путь процесса, поэтому прием сообщения может быть смоделирован при помощи промежуточного события-сообщения. Вдобавок, определенный набор действий можно инициировать здесь по таймеру, если, например, клиент не ответил вовремя. Этот оператор обязан включать  два и более исходящих потоков и не должен содержать условий перехода: исходящие потоки указывают на события, которые являются частью событийного оператора или на обработчики сообщений. Поток управления передается на то событие, что произошло раньше. Этот оператор изображается как составное промежуточное событие.  Существуют еще и исключающий и параллельный событийные логические операторы, которые используются для создания и запуска отдельных экземпляров процесса.

●   Исключающий событийный логический оператор (exclusive event-based gateway) создает экземпляр процесса, если наступает каждое из следующих за ним событий. Такой процесс или не должен иметь начального событий, а логический оператор не должен иметь входящего потока управления, или входящий поток управления приходит от обычного начального события. Изображается как составное начальное событие.

●   Параллельный событийный логический оператор (parallel event-based gateway)  создает экземпляр процесса при наступлении всех последующих событий. При этом первое событие инициирует процесс, но наступление остальных событий также необходимо для нормального завершения процесса.  Оператор изображается как параллельное составное начальное событие.

Data (Данные) предоставляют процессу объекты, которые могут создаваться, использоваться и обрабатываться в ходе выполнения процесса.

●   Data Objects (Объекты данных) предоставляют информацию, которая обрабатывается или производиться действиями. Объекты данных могут быть представлены как единичными экземплярами, так и коллекциями. Изображаются в виде пустого листка или листка с тремя чертами для коллекций.

●   Data inputs (Входные данные) предоставляют данные, подающиеся на вход процесса. Изображается в виде листочка с неокрашенной стрелкой.

●   Data outputs (Выходные данные) представляют собой результат выполнения процесса. Изображаются в виде листочка с окрашенной стрелкой.

●   Data Stores (Хранилища данных) предоставляют механизм получения и добавления данных, которые будут храниться вне зависимости от жизни процесса. Изображаются значком базы данных (жесткого диска). 

●   Properties (Свойства) определяют некоторые признаки элементов потока управления: процессов, действий, событий. Не видны на диаграмме.

Connecting Objects (Соединяющие объекты) определяют четыре способа взаимодействия объектов потоков друг с другом и с другими элементами:

●   Sequence Flow  (Поток управления) показывает порядок работы объектов в бизнес процессе или в процессе хореографии. Каждый поток управления имеет только один источник и только одну цель. Источником и целью могут выступать только: события, действия, действия хореографии, логические операторы. Изображается сплошной линией с закрашенной стрелкой на конце. Кроме того, для потока управления может быть определено условие, показывающее, что поток будет выполнен, если будет выполнено определенное условие. Условие обычно используется, когда источник поток – логическое оператор или какое-либо действие. Поток управления с условием, исходящий из действия, обязан начинаться со значка «алмаза», при этом действие должно содержать как минимум еще один безусловный исходящий поток управления. Поток управления с условием, исходящий из логического оператора, значка «алмаза» не содержит, а логический оператор не должен быть параллельным или событийным. Поток управления может быть определенным «по умолчанию» для включающих, исключающих, сложных логических операторов или действий. Он имеет значок «слэш» в начале стрелки.

●   Message Flow (Поток сообщений) используется для передачи сообщений между двумя участниками. Поток сообщений соединяет два различных пула. Он должен касаться границы пула или объекта потока управления в пуле. Он не может объединять два объекта одного пула. Изображается в виде пунктирной линией, которая начинается с пустого кружка и заканчивается пустой стрелкой.

●   Association (Ассоциация) используется для ассоциации информации и артефактов с объектами потока управления. Информация может быть представлена текстом или графическими объектами. Кроме того, ассоциация может указывать на то, используется ли действие для компенсации. Ассоциация отображается одиночной точечной линией .

●   Data Association (Ассоциация данных) используются для перемещения объектов данных, свойств и входящей/исходящей информации действий, процессов и глобальных заданий. Результаты ассоциаций данных не оказывают прямого влияния на поток процесса. Ассоциация данных изображается пунктирной тонкой стрелкой. Ассоциация данных всегда имеет источник, цель и возможную информацию о трансформации данных. При выполнении ассоциации данных, данные копируются из источника к цели.

Swimlanes (букв. «Плавательные дорожки», иначе говоря «Разделительные дорожки») позволяют группировать элементы модели по пулам и дорожкам, распределяя между ними обязанности.

●   Pool (пул) выступает как контейнер для потока управления между действиями или как определенный участник бизнес-процесса. Процесс полностью содержится в пуле. Поток управления может пересекать дорожки (lanes) пула, но не может пересекать границы пула. Взаимодействие между пулами осуществляется через потоки сообщений. Каждый пул может выступать как «черным», так и «белым» ящиком, детализируя или скрывая свою внутреннюю структуру. В случае «черного ящика» поток сообщений соединяет границы пула, в случае «белого ящика» - его определенные действия. Любое взаимодействие (Collaboration) имеет хотя бы два пула (т.е. участника). Каждый пул отображается прямоугольником, в левой (верхней) части которого пишется имя пула. Обычно прямоугольник проходит через всю диаграмму по вертикали или по горизонтали. Если в диаграмме выделен главный пул – он может не обрамляться границами.

●   Lane (дорожка) является составной частью пула. Служит для группировки и организации действий в пуле. Изображает горизонтальным или вертикальным поименованным прямоугольником длинной как и весь процесс. BPMN строго не определяет назначение линий. Они могут использоваться для отображения внутренних ролей (например Менеджер), систем (например, информационная система), или отдел организации и т.д.

Artifacts (Артефакты) используются для предоставления дополнительной информации о процессах. Существуют два стандартных артефакта (Group (Группа), Text Annotation (Аннотация), однако для своих нужд разработчики могут создавать любые другие. Текстовая аннотация служит для дополнительного описания элемента диаграммы. Изображается половинкой прямоугольника. Группа служит для группировки элементов диаграммы. Изображается прямоугольником с закругленными углами в пунктирную через точку линию.  Артефакты не могут выступать как элементы потока управления, не могут соединяться потоками управления или сообщения, на них не накладываются ограничения пулов и дорожек. Таким образом, например, группа может пересекать границы пула для объединения элементов диаграммы.

Отдельно следует выделить особый элемент BPMN, который не отображается отдельным графическим элементом, но присутствует или предполагается на любой диаграмме – это участник (participant). Под участником может пониматься некая сущность – бизнес-партнер (например, компания-поставщик) или роль процесса (например, покупатель), участвующая в процессах взаимодействия. Именно участника отображают пулы BPMN. С понятием участника тесно связаны диаграммы взаимодействия (совместные диаграммы) BPMN. В ранних спецификациях эти диаграммы выделяли в отдельный тип и называли глобальными (Collaboration (global)). На диаграмме взаимодействия показаны несколько пулов и потоки сообщений между ними.

В BPMN 2.0 определены два основных типа процессов процессы хореографии и процессы оркестровки. Процессы оркестровки представляют собой набор действий или взаимодействие внутри компании. С этими процессами наиболее часто работают бизнес-аналитики. В BPMN к ним относят частные (внутренние) и абстрактные (открытые) процессы.

●   Частный (public) бизнес-процесс выполняется внутри организации. Этот тип бизнес-процесса часто называют workflow или BPM-процесс. В области СОА этот процесс часто связывают с оркестровкой служб. Частный процесс подразделяется на два вида: исполняемые и неисполняемые. Исполняемый процесс создается и моделируется для выполнения, неисполняемый служит лишь для оценки поведения процесса на определенном уровне детализации бизнес-процессов компании.

●   Абстрактный (abstract, это название взято еще из BPMN 1.2) (public) бизнес-процесс необходим для демонстрации взаимодействия между частными бизнес-процессом и другим процессом или участником процесса. Абстрактным процессом можно назвать тот, в котором есть действия по коммуникации с другими участниками процесса. Все остальные внутренние действия частного процесса не показываются на схеме абстрактного. Так, с помощью открытого процесса можно показать последовательность обмена сообщениями между процессами.

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

Основным элементом диаграмм хореографии стало действие хореографии (Choreography Activity) – некий этап взаимодействия между двумя сторонами. Единое, неделимое действие, задача хореографии описывает процесс обмена сообщениями между двумя участниками. Название процесса и имена участников подписываются на графическом элементе задачи хореографии – скругленном прямоугольнике с тремя областями. Соединяются задачи потоками управления, которые могут проходить через шлюзы. Существуют несколько специфических типов потоков управления и особенностей их использования в диаграммах этого типа. Диаграммы хореографии могут быть как детализированы с помощью диаграмм взаимодействия, так и присутствовать на них. 

Процессы хореографии поддерживались в BPMN 1.2 в виде диаграмм взаимодействия, однако специалисты находили в этом подходе ряд существенных недостатков, например, Геро Декер в [63] говорит о ненужной избыточности, несоответствии потоков управления и  событий запуска процессов. Введение элементов хореографии устранила часть этих проблем, но и породило свои, например, проблемы очередности взаимодействия между множеством участников.

Подробнее об элементах BPMN можно прочесть в официальной спецификации BPMN [12].  На сегодняшний день поддержка BPMN реализована в программном обеспечении большого количества производителей [48], например, таких как Oracle, IBM и др.

Взаимосвязь BPEL, XPDL, BPMN

Вопросы о необходимости наличия стандартов описания, исполнения и взаимодействия процессов, а также вопросы их способности адекватно описывать предметную область неоднократно поднимались и обсуждались в прессе (например, в [2], [35], [1], [33], [7], [36]).  Tom Baeyens, ведущий разработчик платформы JBoss jBPM, утверждая в [1], что описывать бизнес-процессы можно с использованием множества нотаций, не ограничиваясь набором из тех, что поддерживаются производителями. Пьер Вигнерас (Pierre Vigneras) проанализировав ряд статей в [36] и сравнил процедуры и результаты преобразования между BPMN и BPEL и показал, что, несмотря на все успехи развития оболочек программирования и проектирования программистам BPEL приходиться напрямую работать с этим языком, а для бизнес-аналитиков язык очень сложен – сложен, чтобы учить и читать, сложен для реализации, и, что самое важное для обеспечения прозрачности, – сложен для скрытия реализации. Кроме того, BPEL при преобразовании из BPMN привносит много мелочей в модель процесса, о которых бизнес-аналитик может и не знать: это разнообразная техническая и программная информация. Таким образом, такое преобразование достаточно сложно совершить, а результат, если он и получится, будет сложно даже прочитать.

Кейт Свенсон, ссылаясь на Пьера Вигнераса, показывает в [35], что BPEL совсем не нужен для реализации процесса, достаточно лишь спецификации BPMN. С другой стороны, наличие стандарта все же лучше, чем его отсутствие, подчеркивает он в [46]. Исмаель Халими (Ismael Ghalimi), вступая в эту дискуссию напрямую, приводит несколько положений в [7], доказывая права существование языка BPEL и BMPN:

1. Корректность. Использование стандартов выполнения процессов, которые описаны нотациями типа BPMN, предполагает определенные, четкие пути проверки корректности выполняемых моделей.

2. Предсказуемость. Использование стандартов выполнения процессов дает возможность предсказать поведение исполняемых моделей процесса.

3. Переносимость. Использование стандартов выполнения процессов дает возможность переноса исполняемых процессов между исполняющими системами, предоставленными различными вендорами.  Тем более, как отмечает Ю. Волков в [42], нотации BPEL и BPMN приняты крупнейшими поставщиками как стандарты де-факто и совместимы между различными реализациями.

4. Тестирование производительности. Использование стандартов выполнения процессов позволяет объективно тестировать производительность систем различных вендоров на основе одной и той же модели процессов.

5. Прогресс. Принятие единого стандарта выполнения процессов позволит индустрии быстрее развиваться, занимаясь разработкой «высоких» пожеланий клиентов, не решая каждый раз концептуальные проблемы взаимодействия и описания процессов.

Ю. Волков в [42] добавляет к преимуществам строгость, минимализм и высокую распространенность BPMN и BPEL. Кроме того, Исмаель Халими, отвечая на слова Пьера Вигнераса и Кейта Свенсона о сложности BPEL [44], говорит, что никто и никогда не должен писать код на BPEL вручную. BPEL также сложен и точен, как и мощен, он специально разрабатывался для автоматического создания генераторами кода. А если возникла потребность писать код BPEL вручную, то стоит воспользоваться более простыми вариантами, например, SimPEL или jPDL.  Отвечая на предложения избежать кодирования BPMN в BPEL, он говорит, что исполняемых нотаций BPMN не существует. А если кто-то и выполняет диаграммы BPMN напрямую, то он, скорей всего, заново изобрел BPEL 2.0 или что-то похожее. Так, сочетание BPMN и BPEL – это все, что необходимо для того, чтобы сделать процесс исполняемым, но стоит их разъединить и вся система рухнет.  Брюс Сильвер (Bruce Silver) в [45] рассматривает доводы Вигнерса и Халими и отмечает, что BPMN обладает возможностью проводить такие действия, на которые BPEL накладывает серьезные ограничения. Это означает, что не все BPMN диаграммы транслируются в BPEL (таких проблем, например, не испытывает XPDL, при разработке которого учитывали совместимость с последним стандартом BPMN). Вендорам приходится накладывать ограничения на BPMN дизайнеры для поддержки BPEL.  С другой стороны, BPMN проигрывает BPEL в стандартизации семантики. Каждый вендор самостоятельно решает, что из стандарта он поддерживает, а что нет. С BPEL все строже, вендор может добавлять в него свою функциональность, но если его программное обеспечение не поддерживает базовую семантику  нотации – то нельзя говорить о поддержке BPEL. Рассматривая слова Халими об исполняемых нотациях BPMN,  Брюс отмечает, что SAP и Oracle уже поддерживают прямое исполнение диаграмм в своих BPM-движках, оставляя BPEL роль только в процессах интеграции и СОА.

Итак, было показано, что к началу 2010 года в отрасли автоматизации бизнес-процессов, особенно в зарубежной практике, сформировалось устойчивое понимание основных концепций языков описания и исполнения бизнес-процессов. Несмотря на предваряющие эти соглашения дискуссии и открытую конкуренцию между крупнейшими производителями программного обеспечения и поставщиками средств автоматизации в первом десятилетии 2000-х, консорциумы разработчиков, созданные еще в 90-х для проектирования и внедрения стандартов веб-технологий (например, W3C) и компонентно-ориентированной разработки ПО (например, OMG), по большей части смогли предупредить возможные проблемы параллельного развития в отрасли множества протоколов и стандартов, описывающих одну и ту же предметную область. И отрасль сосредоточилась вокруг трех дисциплин: BPMN, XPDL и BPEL. Однако это не помешало консорциумам по некоторым вопросам [61] вступить в негласную конфронтацию друг с другом, что привело, во-первых, к практически полному игнорированию в некоторых случаях одной нотации другой, а, следовательно, и, во-вторых, к очевидным сложностям интерпретации одной и той же модели бизнес-процесса в рамках различных стандартов. Конечно, предметные области каждого из трех стандартов примерно схожи, а цели и задачи каждого из них, на первый взгляд, предельно различны: BPMN – графическая интерпретация модели, XPDL – семантика ее хранения и промежуточное звено между другими стандартами, а BPEL – это уровень высокоуровнего языка описания взаимодействия процессо. Но детальное рассмотрение и анализ стандартов, и, особенно, дискуссии, развернувшиеся среди самих разработчиков нотаций, не позволяют с уверенностью это утверждать. Скорее, можно объяснить так: для каждой пары стандартов, для BPMN – XPDL, XPDL – BPEL, BPMN – BPEL существуют свои особенные проблемы. Это могут быть проблемы взаимоинтерпретации, сохранения целостности и адекватности модели, пересечения множеств решаемых в рамках стандартов задач и многое другое. В любом случае на данный момент решение этих проблем переложено на плечи поставщиков средств автоматизации, а конечный потребитель поставлен перед самостоятельным выбором оценки необходимости поддержки этих моделей в своей повседневной деятельности, и, следовательно, перед выбором конкретного поставщика. Активная работа над стандартами, совместное их обсуждение всеми заинтересованными группами позволяют предполагать, что сложившаяся в отрасли ситуация в скором времени измениться в лучшую сторону.

Список используемой литературы

1. Tom Baeyens. 3 Approaches To Transform Analysis Diagrams Into Executable Processes. 2008 / [электронный ресурс] // https://processdevelopments.blogspot.com/2008/10/3-approaches-to-transform-analysis.html
2. The BPMN-XPDL-BPEL value chain [электронный ресурс] / Keith Swenson, 2006 // https://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/
3. BPM Think Tank Day 2: Panel on Business Value of Process Standards [электронный ресурс]/ Sandy Kemsley, 2006 // https://www.ebizq.net/blogs/column2/2006/05/bpm_think_tank_7.php
4. Стандарты BPM [электронный ресурс]  // https://bpms.ru/library/standards/index.html
5. Михеев А., Орлов М. Война стандартов в мире workflow. 2007 / [электронный ресурс]  // https://www.ecm-journal.ru/docs/Vojjna-standartov-v-mire-workflow.aspx
6. Standards and Web services. / [электронный ресурс] // https://www.ibm.com/developerworks/webservices/standards/
7. Why Standards Matter [электронный ресурс]/ Ismael Ghalimi, 2008  // https://www.bpmlab.org/2008/11/02/why-standards-matter/
8. Matjaz B. J. Business Process Exexution Language for WebServices, Second Edition. / Matjaz B. Juric. – Birmingham, UK: Packt Publishing Ltd., 2006. – 353 стр.
9. Harish Gaur. BPEL Cookbook. Best Practices for SOA-based integration and composite applications development / под ред. Harish Gaur, под ред.  Markus Zirn. – Birmingham, UK: Packt Publishing Ltd., 2006. – 185 стр.
10. Eben H. Java SOA Cookbook / Eben Hewitt. – Sebastopol, USA: O’Reilly Media, Inc., 2009 – 742 стр.
11. Некоторые, наиболее известные стандарты описания бизнес-процессов / [электронный ресурс]/ Романов М., 2009  //  https://www.ecm-journal.ru/blog/post/Nekotorye-naibolee-izvestnye-standarty-opisanija-biznes-processov.aspx
12. Business Process Management Initiative. / [электронный ресурс]  //   https://www.bpmn.org/
13. Catalog of OMG Business Strategy, Business Rules and  Business Process Management Specifications / [электронный ресурс]  //  https://www.omg.org/technology/documents/br_pm_spec_catalog.htm
14. Catalog of OMG Modeling and Metadata Specifications / [электронный ресурс]  // https://www.omg.org/technology/documents/modeling_spec_catalog.htm
15. Unified Modeling Language, версия 2.0 / [электронный ресурс] / Брэн Селик, 2005  // https://www.ibm.com/developerworks/ru/rational/library/321_uml/index.html
16. Ньюкомер Э. Веб-Сервисы. Для профессионалов / Эрин Ньюкомер. – СПб.: Питер, 2003. – 256 с.: ил.
17. Диаграммы для описания бизнес-процессов. [электронный ресурс]/ Волков Ю.О., 2006  // https://yurivolkov.com/articles/Diagrams_for_business_processes_ru.html
18. George Lawton. Co-evolution of BPMN and BPEL drives BPM in SOA settings. 2009 / [электронный ресурс]  // https://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1353870,00.html
19. BPMN vs IDEF3: 11:5 в пользу BPMN. 2009 / [электронный ресурс]  // https://chevalry.livejournal.com/115586.html
20. jBPM Process Definition Language (JPDL) / [электронный ресурс]  // https://docs.jboss.org/jbpm/v3/userguide/jpdl.html
21. Кулямин В.В. Технологии программирования. Компонентный подход – М.: БИНОМ, 2006. – 464с.
22. Web Services Business Process Execution Language Version 2.0. 2007 / [электронный ресурс]  // https://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
23. Оркестровка и хореография Web-сервисов/ [электронный ресурс]  // https://www.osp.ru/os/2004/11/184785/
24. Will BPEL and WSCI Come Together? [электронный ресурс]/ Thor Olavsrud, 2003  // https://www.internetnews.com/infra/article.php/2211121
25. Robert Shapiro. A Comparison of XPDL, BPML and BPEL4WS/ Shapiro R.,   17 стр. // Cape Visions, 2002 
26. Oracle Magazine - Русское Издание [электронный ресурс]  // https://www.oracle.com/global/ru/oramag/index.html
27. XPDL Support and Resources [электронный ресурс]  // https://www.wfmc.org/xpdl.html
28. OASIS ebXML Business Process TC [электронный ресурс]  // https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp
29. OASIS Web Services Business Process Execution Language (WSBPEL) TC  [электронный ресурс]  // https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
30. WS-BPEL Extension for People (BPEL4People) [электронный ресурс]  / Ashish Agrawal, Mike Amend, Manoj Das [и др.] // https://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/BPEL4People_v1.pdf
31. BPML specification [электронный ресурс]  // https://www.ebpml.org/bpml.htm
32. Web Services Choreography Description Language Version 1.0 [электронный ресурс] / Nickolas Kavantzas, David Burdett [и др.] // https://www.w3.org/TR/ws-cdl-10/
33. Война стандартов в мире workflow [электронный ресурс]/ Михеев А., Орлов М.   // https://wf.runa.ru/images/c/ce/Stat_ya2.pdf
34. Business processes and workflow in the Web services world [электронный ресурс]  / Margie Virdell // https://www.ibm.com/developerworks/webservices/library/ws-work.html
35. Directly Executing BPMN [электронный ресурс] / Keith Swenson, 2009   // https://kswenson.wordpress.com/2008/10/29/directly-executing-bpmn/
36. Why BPEL is not the holy grail for BPM [электронный ресурс] / Pierre Vigneras, 2008   // https://www.infoq.com/articles/bpelbpm
37. XPDL and BPEL [электронный ресурс] / Sandy Kemsley, 2007  // https://www.ebizq.net/blogs/column2/2007/03/xpdl_and_bpel.php
38. The Real Issues with XPDL, BPEL, and BPMN [электронный ресурс] / Bruce Silver, 2007  // https://www.bpmenterprise.com/blog/archive/the_real_issues_with_xpdl_bpel_and_bpmn.html
39. Are Apples more useful than Oranges? [электронный ресурс]/ Keith Swenson, 2007     // https://kswenson.wordpress.com/2007/03/20/are-apples-more-useful-than-oranges/
40. Technical Overview of WS-BPEL 2.0 [электронный ресурс]/ Dieter Koenig, 2007  // https://bpel.xml.org/presentation-tech-overview
41. Business Process Management and WS-BPEL 2.0. What’s next for SOA Orchestration? -  An Oracle White Paper, 2006 / Manoj Das [электронный ресурс]  // https://www.oracle.com/technology/tech/standards/pdf/bpel.pdf
42. Волков Ю.О. Что дают предприятию новые стандарты описания бизнес-процессов [электронный ресурс]/ Волков Ю.О.   // https://www.yurivolkov.com/articles/NewBpmStandardsForTheEnterprise_ru.html
43. Куда движется BPM. [электронный ресурс]/ Джим Рапоза, 2007  // https://www.pcweek.ru/themes/detail.php?ID=82525&phrase_id=309871
44. Why BPEL Matters. [электронный ресурс] /  Ismael Ghalimi, 2008  // https://itredux.com/2008/09/28/why-bpel/
45. BPMN-BPEL in Perspective [электронный ресурс]/ Bruce Silver, 2008  // https://www.brsilver.com/wordpress/2008/10/25/bpmn-bpel-in-perspective/
46. BPEL-Grail. [электронный ресурс]/ Keith Swenson, 2008  // https://kswenson.wordpress.com/2008/10/24/bpel-grail/
47. Is XPDL the Silent Workhorse of BPM? [электронный ресурс]  // https://www.ebizq.net/topics/bpm/features/7852.html
48. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными компаниями / К.Е. Самуйлов, А.В. Чукарин, Н.В. Яркина. – М.: Альпина Паблишерз, 2009. – 442 стр.
49. Workflow Management Coalition Workflow Standard.  Process Definition Interface - XML Process Definition Language [электронный ресурс]/ Workflow Management Coalition, 2008 // https://www.wfmc.org/index.php?option=com_docman&task=doc_download&Itemid=72&gid=132
50. XPDL Implementations  [электронный ресурс]  // https://www.wfmc.org/xpdl-implementations.html
51. BPMN and XPDL [электронный ресурс]/ Dr. Sebastian Stein, 2008  // https://www.ariscommunity.com/users/sstein/2008-05-21-bpmn-and-xpdl
52. Why XPDL is Essentially Useless [электронный ресурс] / Ismael Ghalimi, 2008  // https://itredux.com/2008/11/21/why-xpdl-is-essentially-useless/
53. Is XPDL Going to Become a Dominant Process Standard? [электронный ресурс] / Scott Francis, 2009  // https://www.bp-3.com/blogs/2009/04/is-xpdl-going-to-become-a-dominant-process-standard/
54. Searching for BPMN / XPDL Incompatibility [электронный ресурс]/ Keith Swenson, 2009    // https://kswenson.wordpress.com/2009/04/20/searching-for-bpmn-xpdl-incompatibility/
55. The Diagram IS the Meaning  [электронный ресурс] / Keith Swenson, 2007 // https://kswenson.wordpress.com/2007/03/25/the-diagram-is-the-meaning/
56. BPEL, XPDL and BPMN [электронный ресурс]  // https://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/thread/b8692bd8-5c32-47e8-96f8-46c33210ee99/
57. On BPMN, BPEL and XPDL – Part II [электронный ресурс]  // https://www.primatek.ca/blog/2008/11/24/on-bpmn-bpel-and-xpdl-–-part-ii/
58. Майкл Хаммер. Реинжиниринг корпорации. Манифест революции в бизнесе. / Майкл Хаммер, Джеймс Чампи. ­­– М. : Манн, Иванов и Фербер, 2007 г. – 288 стр.
59. Белайчук А. Зачет по BPM / А. Белайчук // Открытые системы. 2006. Вып. 1. с. 19-20
60. The Role of Business Process Management in SOA [электронный ресурс] / Sandy Carter, 2007  // https://www.information-management.com/issues/20070501/1082553-1.html
61. Model Portability in BPMN 2.0 [электронный ресурс]/ Bruce Silver, 2009    // https://www.brsilver.com/wordpress/2009/03/04/model-portability-in-bpmn-20-2/
62. Business Process Model and Notation (BPMN). FTF Beta 1 for Version 2.0 [электронный ресурс]  // https://www.omg.org/cgi-bin/doc?dtc/09-08-14
63. BPMN 2.0 takes dancing lessons – do we need choreographies? [электронный ресурс] / Gero Decker, 2008 // https://www.bpmn.info/2008/10/15/bpmn-20-takes-dancing-lessons-do-we-need-choreographies/