Перспективы WorkFlow-систем

ОБЗОР

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

_____

Продолжение. Начало см. PC Week/RE, N 23/2004, с. 26.

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

Итак, деятельность любого предприятия можно представить в виде набора бизнес-процессов.

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

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

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

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

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

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

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

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

Рис. 1. Схема бизнес-процесса, соответствующего рассмотрению заявления об уходе в отпуск сотрудника предприятия

На этом этапе встает вопрос о формальных языках описания бизнес-процессов, которые позволяют перенести их в 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-языки не являются строгими: в ряде случаев можно составить такие языковые конструкции, которые будут синтаксически допустимыми, хотя поведение порожденного ими бизнес-процесса не будет определено однозначно.

Аалст и Хофстед предложили расширение концепции сетей Петри для WF-систем, введя дополнительные базовые элементы. Этот подход привел к появлению нового строгого WF-языка - YAWL (Yet Another WorkFlow Language, "еще один WorkFlow-язык") [5]. К сожалению, он оказался очень сложным, его графические диаграммы также непонятны интуитивно, и скорее всего использоваться он будет исключительно в теоретических целях.

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

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

Концепция Pi calculus

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

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

WF-системы и война стандартов

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

Зачем вообще нужны стандарты такого рода?

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

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

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

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

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

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

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

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

Таблица 4. Коалиции, вырабатывающие стандарты WorkFlow-систем

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

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

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

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

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

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

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

- внешние приложения, вызываемые 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 (Object Management Group). В 2000 г. он выпустил документ WorkFlow Management Facility Specification [13]. В нем построены основы архитектуры ядра WF-системы, на языке IDL определены основные интерфейсы многих компонентов. Несмотря на то, что согласно предисловию к документу спецификация основана на WAPI WfMC (OMG IDL binding), это другая спецификация, которая унаследовала только основные принципы построения общей архитектуры системы коалиции WfMC.

Большинство известных нам WF-систем с лицензией OpenSource, разработчики которых утверждают, что они полностью соответствуют спецификации 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-х годов, а в настоящее время количество новых документов сильно сократилось.

Все это вызывает сомнения в том, что в будущем WfMC останется лидером в области 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 именно она, а не 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). http://ftpna2.bea.com/pub/downloads/wsci-spec-10.pdf ;

- Process Specification Language - PSL (National Institute of Standards and Technology, США). 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 языка UML.

Заключение

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

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

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

(Продолжение следует)

С авторами статьи, сотрудниками консалтинговой группы "Руна", можно связаться по адресу: wf@runa.ru.

Литература

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. Фиошин М. Основы p-исчисления - 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, Hofstede A. H. M. YAWL: Yet Another WorkFlow Language - www.citi.qut.edu.au/pubs/technical/yawlrevtech.pdf.

6. Van der Aalst W. M. P. 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-106.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.