Война стандартов в мире workflow

Андрей Михеев, Михаил Орлов

Любое предприятие можно представить в виде набора бизнес-процессов.

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

Задача WF-системы - автоматизация бизнес-процессов предприятия.

WF-система должна выполнять две основные роли:

●     формировать единый язык описания бизнес-процессов для управленцев предприятия, создавая библиотеку бизнес-процессов предприятия;

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

Математические основы языков описания бизнес-процессов

Процессный подход к управлению предприятием не подразумевает наличия WF-системы. Можно провести аналогию с бухгалтерией. Бухгалтерский учет на предприятии вести необходимо, для этого совершенно необходим грамотный бухгалтер, владеющий знаниями и навыками ведения бухгалтерского учета. При этом все можно делать и без использования автоматизированных средств - на бумаге. Аналогично бизнес-процессы предприятия можно описать и изменять без использования WF-системы. Главное, чтобы на предприятии был консультант и/или менеджеры, которые разбираются в методологии процессного подхода к управлению предприятием. Но, как и в случае с бухгалтерским учетом, использование WF-системы позволит осуществлять процессное управление на принципиально ином уровне.

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

На этом этапе встает вопрос о формальных языках описания бизнес-процессов, которые позволяют перенести их в WF-систему.

Существует два типа WF-языков:

●     WF-язык, разработанный для конкретной WF-системы;

●     WF-язык, разработанный некой группой как стандарт для реализации в целом классе WF-систем.

В данной статье речь пойдет о втором типе WF-языков.

В основе большинства WF-языков (как стартовая точка разработки концепции языка) лежит одна  из двух хорошо известных математических теорий:

●     теория сетей Петри [1 , 2];

●     «Pi calculus»-концепция [3].

Теория сетей Петри

Эта математическая теория, основанная на классической теории графов, является расширением теории конечных автоматов. Она возникла в 60-х годах ХХ века и с тех пор постоянно развивается. На основе одного из вариантов сетей Петри (High-level Petri Nets) в настоящее время создается международный  стандарт ISO/IEC 15909 [4]. Теория сетей Петри - сложная, очень хорошо разработанная теория, в ней строго определены такие понятия, как состояния, условия, переходы и т. п. Также теория включает графическую нотацию (систему графических обозначений, на основе которых можно рисовать соответствующие графы). Сети Петри хорошо исследованы математиками - установлены многие их свойства, доказано большое количество теорем.

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

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

Наследниками теории сетей Петри стали первые WF-языки (например, WPDL и XPDL коалиции WfMC). Они основаны на теории графов и концептуально  включают в себя многие понятия, концепции сетей Петри: узлы, переходы, условия и т. д., однако в отличие от сетей Петри эти WF-языки не являются строгими - в ряде случаев можно составить такие предложения языка, которые будут синтаксически допустимыми, однако поведение порожденного бизнес-процесса не будет определено однозначно.

W. M. P. van der Aalst и A. H. M. ter Hofstede предложили расширение концепции сетей Петри для WF-систем, введя в нее дополнительные базовые элементы. Этот подход привел к появлению нового строгого WF-языка - YAWL (Yet Another Workflow Language, «еще один workflow язык») [5]. К сожалению, он оказался очень сложным, его графические диаграммы также непонятны интуитивно и, скорее всего, использоваться он будет исключительно в теоретических целях.

Ограниченность WF-языков, основанных на теории сетей Петри

Эта ограниченность - следствие того, что концепция сетей Петри основана на теории графов. В последнее время в программировании предложены понятия, не укладывающиеся в рамки теории графов, например такое понятие, как исключения (exceptions). Эти новые «программистские» понятия были применены при разработке некоторых WF-языков (в частности, BPML - BPMN) и оказались очень полезными. Таким образом, роль теории сетей Петри в мире WF-языков неоднозначна: с одной стороны, эту теорию можно использовать для исследования WF-процессов некоторых видов, с другой - с ее помощью нельзя описать все WF-процессы. Кроме того, диаграммы сетей Петри  очень громоздкие, в случае сложных процессов соответствующие им сети Петри содержат огромное количество элементов, и разобраться в них очень трудно.

Концепция Pi  calculus

Концепция Pi calculus (π-исчисление) была разработана в конце 80-х годов ХХ века Робином Милнером и основана на алгебре параллельных процессов. В отличие от сетей Петри, математическими объектами - π-исчисления являются не графы, а выражения над элементами специальных множеств и преобразования над этими  выражениями. В настоящее время π-исчисление является перспективной, но еще очень молодой и развивающейся теорией, в ней еще очень много открытых вопросов и нерешенных проблем.

Разработчики двух из наиболее интересных в настоящее время WF-языков - BPML и BPEL4WS - утверждают, что эти языки обладают очень высокой выразительной мощностью, так как в основе этих языков лежит солидная математическая  теория - π-исчисление. Однако немало и скептиков, считающих, что связь этих языков с  концепцией Pi calculus не очевидна, и предполагающих, что это скорее маркетинговый ход, чем реальное использование сложной математической теории для построения WF-языка для промышленных систем масштаба предприятия [6].

«Война» стандартов, касающихся WF-систем

Workflow-направление сегодня активно развивается. Многие WF-системы не совместимы между собой. Их описания нередко даны в разной терминологии, из-за чего эти системы трудно сравнивать. В этих условиях жизнь сильно облегчили бы единые стандарты для WF-систем.

Зачем вообще нужны стандарты для WF-систем?

Стандарты полезны разработчику, поскольку позволяют:

●     сосредоточиться на эффективном решении технических вопросов реализации. Не надо решать общие концептуальные проблемы;

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

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

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

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

Конечно, всем было бы удобно, если бы существовал общепринятый промышленный стандарт для WF-систем. Однако в настоящее время ситуация со стандартами  сложная: проблема в том, что различных WF-стандартов слишком много.  Идет «война» стандартов: различными международными сообществами разработано множество конкурирующих спецификаций и количество их  постоянно возрастает. Если в 1995 г. WF-стандартами занималась только коалиция WfMC, то в 2003-м было уже 10 групп, разрабатывающих стандарты, относящиеся к WF-системам, и только для описания бизнес-процесса они предложили 7 различных стандартов [7].

В таблице приведен список наиболее известных международных коалиций, разрабатывающих спецификации, относящиеся к WF-системам.

История стандартов WfMC

Коалиция WfMC (Workflow Management Coalition) образована в 1993 г. и была первой группой, предложившей спецификации для WF-систем, которые впоследствии  несколько раз переписывались на основе различных ИT-концепций. Разработки коалиции WfMC не являются абсолютно открытыми. Часть документов доступна только для членов коалиции, т. е. для того, чтобы их получить, надо в том или ином виде стать членом коалиции (коалиция допускает много видов членства) и, разумеется, уплатить членские взносы.

Одним из явных достижений WfMC следует считать создание словаря Terminology & Glossary [15], где определяются основные термины, относящиеся к WF-системам. Многие из этих терминов на сегодняшний день признаны как стандарт де-факто для описания элементов бизнес-процесса.

В спецификации Workflow reference model предлагается следующая общая  архитектура для WF-системы  [8]:

●     распределенное ядро системы, которое содержит набор выполняемых экземпляров бизнес-процессов;

●     редактор определений бизнес-процессов;

●     клиентское приложение, при помощи которого ядро взаимодействует с пользователями;

●     внешние приложения, вызываемые WF-системой;

●     административное приложение.

Стандарт предполагает, что все компоненты взаимодействуют не напрямую друг с другом, а только с распределенным ядром системы. Стандарт не оговаривает детально, как должны быть устроены компоненты. В основном в нем описываются интерфейсы взаимодействия этих компонентов с ядром системы. В «Workflow Reference Model» интерфейсы описаны неформально - практически в терминах предметной области. В дополнительных документах интерфейсы определены более строго. Всего предлагается пять  интерфейсов:

●     первый описывает взаимодействие ядра системы с редактором  определений бизнес-процессов;

●     второй -  взаимодействие ядра с клиентским приложением;

●     третий - взаимодействие ядра с внешними приложениями;

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

●     пятый - взаимодействию ядра с административным приложением.

Разработанный коалицией WfMC в 1999 г. язык определения бизнес-процессов  WPDL был  основан на формулах Бэкуса - Наура. В рамках Workflow reference model язык определения бизнес-процесса соответствует первому интерфейсу. В 2002 г. язык WPDL был переписан. Его новая версия - XPDL - уже была основана на XML.

В дополнительных документах WfMC  достаточно подробно и строго описаны и другие интерфейсы (см. например [16]). Интерфейсы взаимодействия в [16] не объектно ориентированы, а соответствуют процедурному подходу. В приложениях к документу [16] сделана попытка перейти от процедурного подхода к объектному (в рамках уже несколько устаревших к настоящему времени концепций OLE и CORBA): процедурные спецификации преобразованы в OLE- и IDL-спецификации, которые, однако, по мнению экспертов, сохранили в себе наследие процедурного подхода.

Сначала предполагалось, что таким образом будет описан только второй интерфейс, однако оказалось, что одни и те же функции (объекты) используются различными интерфейсами и писать спецификации по-интерфейсно нет смысла, тогда документ был назван WAPI (Workflow Application Programming Interface) и стал фактически относиться ко второму-пятому интерфейсам.

Следующий шаг в рамках данной эволюции сделала коалиция OMG (ObjectManagementGroup). В 2000 г. Она выпустила документ Workflow Management Facility Specification [13]. В нем построены основы архитектуры ядра WF-системы, на языке IDL определены основные интерфейсы многих компонентов. Несмотря на то, что в предисловии к документу говорится, что спецификация основана на WAPI WfMC (OMG IDL binding), это другая спецификация, которая унаследовала только основные принципы построения общей архитектуры системы коалиции WfMC.

Большинство известных нам OpenSource WF-систем, разработчики которых утверждают, что они полностью соответствуют спецификации WfMC, реализуют именно эту архитектуру, предложенную OMG (а не WAPI коалиции WfMC).

 Программистские технологии продолжали развиваться. Появились Web-сервисы, вслед за ними  WF-языки и спецификации (не совместимые со стандартами коалиции WfMC), ориентированные на эти технологии. В конце 2001 г. WfMC выпустила документ Workflow Standard - Interoperability Wf-XML Binding [17], в котором для реализации четвертого интерфейса  предлагался язык Wf-XML. Этот язык можно использовать в рамках технологии Web-сервисов. По мнению некоторых экспертов, в настоящее время Wf-XML постепенно расширяется и на другие интерфейсы (второй, третий, пятый). Похоже, что таким образом  WfMC также переходит на использование технологии Web-сервисов (с большим опозданием по сравнению с коалициями-конкурентами).

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

WfMC отстает и по другим направлениям, например, у коалиции нет совместимой с языком определения бизнес-процессов графической  нотации для визуализации бизнес-процесса. Кроме того, большая часть спецификаций коалиции была разработана в конце 90-х годов, а в настоящее время количество новых документов сильно сократилось.

Все это вызывает сомнения в том, что в будущем коалиция останется лидером в области WF-стандартов.

История стандартов коалиции BPMI

В 2000 г. появилась коалиция BPMI, которая достаточно быстро разработала основанный на технологии Web-сервисов язык определения бизнес-процессов BPML и начала создание других полезных стандартов (не совместимых со стандартами WfMC).

Через некоторое время коалиция BPMI подготовила стандарт графических диаграмм, описывающих WF-процесс - BPMN. Язык также содержал правила автоматического перевода графических диаграмм BPMN в язык BPML.

Однако вслед за объединением IBM, Microsoft и BEA и созданием новой коалицией другого WF-языка, также основанного на технологии Web-сервисов (BPEL4WS), в рядах коалиции BPMI началась паника - прогнозы абсолютного большинства экспертов говорили о том, что IBM, Microsoft и BEA «продавят» свою спецификацию и именно BPEL4WS станет стандартом де-факто в качестве языка определения бизнес-процессов.

Был период, когда BPMI позиционировало язык графических нотаций  BPMN как графическую оболочку для BPEL4WS. Однако в настоящее время коалиция реанимировала BPML и предлагает экспорт из BPMN как в BPML, так и в BPEL4WS. Но ситуация с языком BPML остается очень неопределенной. На наш взгляд, BPML проще и удобнее BPEL4WS, но вполне возможно, что корпорации-гиганты все-таки задавят его своей спецификацией BPEL4WS.

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

Также коалиция BPMI создает язык запросов для WF-процессов (BPQL), который пока не привлек большого внимания.

История языка BPEL4WS

К моменту образования коалиции BPMI корпорация IBM начала работу над своим стандартом WF-языка (WSFL), Microsoft также приступила к составлению собственного стандарта (XLANG) (оба - несовместимы с XPDL и BPML). В августе 2002-го IBM, Microsoft и BEA объявили о подготовке совместного стандарта - языка BPEL4WS (или просто BPEL), позже к этим компаниям примкнули  SAP и Siebel.

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

WF-системы легко стыкуются с Web-сервисами. Можно без труда определить интерфейс для взаимодействия с WF-системой через Web-сервисы, однако идея, предполагающая, что все взаимодействие с WF-системами должно осуществляться только при помощи Web-сервисов, является сомнительной.

Другие стандарты

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

●     Business Process Specification Schema  - BPSS (Electronic Business XML - ebXML). www.ebxml.org/specs/ebBPSS.pdf.

●     Business Transaction Protocol - BTP (OASIS). www.oasis-open.org/committees/download.php/1184.

●     Web Services Conversation Languange - WSCL (HP Labs/W3C) www.w3.org/TR/2002/NOTE-wscl10-20020314.

●     Web Services Choreography Interface - WSCI (SUN/BEA/W3C) https://ftpna2.bea.com/pub/downloads/wsci-spec-10.pdf.

●     Process Specification Language - PSL (National Institute of Standards and Technology, USA). www.mel.nist.gov/psl/.

●     Business Process Definition Metamodel  (OMG). www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-Revision.pdf.

Тенденции развития стандартов

Спецификации языков определения бизнес-процессов BPML иBPEL4WS были поданыв консорциум OASIS (Organization for the Advancement of Structured Information Standards) на утверждение в качестве промышленного стандарта. Также в OASIS была подана спецификация Wf-XML.

Однако консорциум OASIS не утвердил в чистом виде ни BPEL4WS, ни BPML, а создал собственный комитет по разработке спецификации языка определения бизнес-процессов на основе BPEL4WS с учетом решений BPML. Эта спецификация будет называться WS-BPEL.Когда она будет разработана, неизвестно.

Также вполне вероятно, что в будущем графическая  спецификация BPMN сольется с Activity diagram UML.

Заключение

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

По-видимому, в условиях «войны стандартов» при выборе WF-системы имеет смысл не привязываться к какому-либо одному  стандарту, а наложить более слабые требования, например обеспечение выполнения системой важных для данного предприятия workflow patterns (набора образцов элементов бизнес-процессов, признанного международным сообществом).

В последующих публикациях мы планируем подробно рассказать о достоинствах и недостатках конкретных WF-стандартов, а также дать описания workflow patterns.

Литература.

1. 21-я Международная конференция по сетям Петри. Petri Nets. Introductory tutorial. www.daimi.au.dk/PetriNets/introductions/pn2000_introtut.pdf.

2. An introduction to Petri nets. viking.gmu.edu/http/syst511/vg511/AppC.html.

3. Фиошин. М. Основыπ-исчисления. progr.tsi.lv/research/picalc.pdf

4. High-level Petri Nets - международный  стандартISO/IEC 15909, версия 4.7.1. www.informatik.hu-berlin.de/top/PNX/pnstd-4.7.1.pdf.

5. Van der Aalst, A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language. www.citi.qut.edu.au/pubs/technical/yawlrevtech.pdf.

6. Van der Aalst.  Pi calculus versus Petri nets: Let us eat «humble pie» rather than further inflate the «Pi hype». tmitwww.tm.tue.nl/staff/wvdaalst/pi-hype.pdf.

7. Michael zur Muehlen. Process Management Standards Overview. www.wfmc.org/standards/docs/Process_Management_Standards_files/frame.htm.

8. WfMC. Workflow reference model. www.wfmc.org/standards/docs/TC00-1003_10_1994.pdf.

9. Коалиция WfMC, язык XPDL. www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf.

10. Коалиция BPMI, язык BPML. www.bpmi.org/bpml-spec.esp.

11. Коалиция BPMI, графический язык BPMN. www.bpmi.org/bpmn-spec.esp.
12. Коалиция IBM, Microsoft и BEA, язык BPEL4WS. www-

06.ibm.com/developerworks/library/ws-bpel/.

13. OMG. Workflow Management Facility Specification www.omg.org/docs/formal/00-05-02.pdf.

14. OMG Unified Modeling Language Specification www.omg.org/docs/formal/03-03-01.pdf

15. WfMC. Terminology and glossary. www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf.

16. WfMC. WAPI (Workflow Application Programming Interface). www.wfmc.org/standards/docs/TC-1009_20e_1997.pdf.

17. WfMC. Workflow Standard - Interoperability Wf-XML Binding. www.wfmc.org/standards/docs/Wf-XML-11.pdf.