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

BPML

BPEL

XPDL

XPDL (XML Process Definition Language) - это язык на основе XML, предназначенный для описания определений и реализаций рабочих процессов. Спецификация XPDL, предложенная Workflow Management Coalition (WfMC), представляет собой формальную модель для описания рабочих процессов, относящихся к любым сферам деятельности. В соответствии с ней каждый поток работ разбивается на следующий набор взаимодействующих между собой компонент (см. рисунок 6.2).

Рис. 6.2. – Компоненты потока работ в XPDL.

- WorkflowProcessDefinition - представляет собой контекст выполняющегося процесса, и его данные могут быть доступны всем остальным компонентам.

- Activity - <действие> процесса, представляющее собой этап, на котором происходит изменение содержания объектов процесса.

- TransitionInformation - переходы между заданиями (могут быть условными и безусловными).

- WorkflowRelevantData - оперативные данные, доступные всем компонентам процесса в ходе его выполнения.

- Participant - участник процесса, производящий <действия> над объектами и осуществляющий переходы (участники могут являться как человеческими, так и машинными ресурсами).

- Application - внешнее IT- или другое приложение, используемое для выполнения <действий>.

В языке XPDL рабочий процесс представляет собой направленный граф, узлами которого являются <действия>, связанные между собой переходами. Переходы могут быть условными, причем условие проверяется на этапе выполнения конкретного <действия>. В языке существует возможность выделения <блоков>, возможность объединения <действий> в блок <действий> со своими отдельными условными или безусловными точками входа и выхода. Так же имеется возможность определять вложенные подпроцессы внутри родительского процесса, которые сами по себе представляют полноценные потоки работ. Спецификация поддерживает возможность экспорта некоторых блоков описания одного процесса в описание другого с возможностью переопределения части импортируемого описания, что исключает необходимость дублирования идентичных фрагментов описания в нескольких процессах. XPDL является расширяемым стандартом. Он позволяет определять набор элементов и атрибутов, специфичных для конкретной сферы его применения. Элементы описания процессов XPDL имеют обширный набор атрибутов, определяющих ход выполнения процесса. К ним можно отнести условные выражения для переходов, временные рамки, задание множественных исполнителей <действий> и т.д.

Рассмотрим в соотвествии с [115] основные элементы языка XPDL и правила их использования.

Основные элементы языка:

- Activity (узел-действие);

- Transition (переход);

- Participant (участник бизнес-процесса);

- Application (внешнее приложение);

- DataType (тип переменной);

- DataField (переменная).

Граф бизнес-процесса определяется наборами элементов Activity и Transition. Activity - это основной элемент бизнес-процесса. Элементы Activity соединяются при помощи элементов Transition.

Существует три типа элементов Activity: • Route; • Implementaion; • BlockActivity.

Route - узлы, не выполняющие действий. Они используются в целях маршрутизации точек управления.

Inplementation - узлы, с которыми связаны действия в бизнес-процессе. Существует три варианта Inplementation:

- узел взаимодействия с пользователем;

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

- узел, запускающий подпроцесс.

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

Элемент Transition используется для описания переходов между элементами Activity. Каждый такой элемент содержит информацию о том, между какими Activtiy и при каких условиях осуществляется переход (переходы бывают условные и безусловные).

В начале описания workflow-процесса находятся спецификации типов (тег TypeDeclaration). Для описания данных, относящихся к процессу, и параметров, передаваемых и возвращаемых приложениями, используются элементы DataField и DataType. Кроме того, в XPDL существует понятие ExtendedAtributes - оно дает возможность расширять язык путем ввода дополнительных типов переменных.

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

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

- OrganisationUnit - соответствует административному подразделению организации;

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

- System - конкретное приложение;

- Resource - некоторый ресурс, который может предложить исполнителя работы;

- RecourceSet - набор ресурсов.

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

Упрощенно описание бизнес-процесса в XPDL выглядит следующим образом.

- Определяются переменные бизнес-процесса (и их типы).

- Описываются участники бизнес-процесса (роли и т. д.).

- Задается множество внешних приложений, вызываемых бизнес-процессом (имена функций и типы их параметров).

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

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

Переход может соединять любые два узла, то есть бизнес-процессу может соответствовать граф любой сложности и топологии. В частности, в графе бизнес-процесса допустимы циклы. В языках, описывающих поток работ (workflow(WF)-языках), к которым относится XPDL, цикл рассматривается как workflow(WF)-паттерн “произвольный цикл”. Поддержка “произвольных циклов” в WF-языке аналогична допустимости использования оператора “goto” в обычных языках программирования. Однако в силу того, что переход управления осуществляется только по ребрам графа, в XPDL нельзя реализовать WF-паттерн “отложенный выбор”.

Технология работы с определениями и экземплярами бизнес-процессов, записанных на языке XPDL, определяется другими спецификациями коалиций WfMC и OMG:

- OMG - Workflow Management Facility Specification;

- WfMC - WAPI (Workflow Application Programming Interface).

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

- “Сгенерировать список текущих заданий”;

- “Сообщить ядру, что данное задание выполнено”.

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

BPEL (Business Process Execution Language) — язык на основе XML, предназначенный для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций. Данный язык часто рассматривается как ключевая составляющая сервис-ориентированной архитектуры приложений (SOA). Действительно, BPEL позволяет эффективно управлять вызовами сервисов; в особенности он удобен при работе с Web-сервисами.

Одно из главных направлений развития современных информационных систем масштаба предприятия связано с концепцией сервис-ориентированной архитектуры (services-oriented architecture, SOA), которая, являясь идеей компонентного построения распределенных компьютерных систем, совсем не нова. Качественно новым элементом идеи стала ориентация SOA на применение, появившихся относительно недавно, технологий, позволяющих создавать распределенные системы на базе Web-сервисов.

В несколько упрощенном виде новизна Web Services заключается в использовании Интернет-технологий на базе открытых отраслевых стандартов, что, в свою очередь, позволяет создавать гетерогенные (платформно независимые), масштабируемые (от локальных до глобальных) решения. Web Services вполне допустимо назвать технологиями XXI века - за точку отсчета их истории, хотя и с некоторой долей условности, можно принять 2000 г. Именно тогда в специализированной прессе стали появляться названия первых WS-стандартов: SOAP (Simple Object Access Protocol) для обмена данными между приложениями, WSDL (Web Services Description Language) для описания программных интерфейсов сервисов и UDDI (Universal Description Discovery & Integration) для хранения и получения WSDL-описаний. Этих стандартов вполне хватает для создания несложных распределенных решений, но явно недостаточно для построения корпоративных систем. Именно потому наряду с модернизацией базовых стандартов стали появляться специализированные технологии для решения таких задач, как гарантированная доставка сообщений, шифрование и обеспечение безопасности, управление транзакциями и т. п. Все они реализованы на основе XML.

В результате к сегодняшнему моменту сложилась целая система WS-стандартов. Подавляющее большинство этих стандартов существуют лишь на бумаге и пока не поддерживаются в программных продуктах. Более того, здесь наблюдается неприятная тенденция - создание конкурирующих между собой спецификаций, подготовкой которых занимаются две группировки ИТ-компаний: одна во главе с IBM и Microsoft и другая, возглавляемая Sun Microsystems и Oracle.

Основу структуры WS-технологий (см. рис. 6.3) составляет все та же базовая тройка - SOAP, WSDL, UDDI, которой пока, к счастью, не коснулась конкурентная борьба ИТ-вендоров. Над ними располагаются слои "Безопасность", "Обмен сообщениями", "Управление контекстом", "Координация", "Управление транзакциями". Выше находятся еще два слоя - "Оркестровка" (Orchestration) и "Хореография" (Choreography). Первый из них стали использовать в лексиконе WS-технологий для обозначения задач управления бизнес-процессами. Второй появился относительно недавно и также относится к проблематике автоматизации процессов, но акцент при этом делается на интеграцию разнородных приложений.

	Рис. 6.3. – Структура стандартов и спецификаций Web Services.

Для решения задач "оркестровки" и "хореографии" также разработан целый набор стандартов. На лидирующие позиции в этой сфере сейчас претендует в первую очередь Business Process Execution Language for Web Services (язык исполнения бизнес-процессов для Web-сервисов), обозначаемый как BPEL4WS, или просто BPEL. Разработкой этого стандарта занимались в основном специалисты IBM и Microsoft. Более того, BPEL фактически стал прямым наследником ранее созданных спецификаций IBM WSFL и Microsoft XLANG. В нем используются сразу несколько XML-спецификаций - WSDL 1.1, XML Schema 1.0, XPath 1.0.

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

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

Для иллюстрации возможностей BPEL рассмотрим простой пример. Предположим, что есть некоторый онлайновый продавец антиквариата. Когда он через свой Web-сайт получает запрос на покупку, ему необходимо запустить процессы для автоматического определения кредитоспособности клиента и поиска у оптовых торговцев нужного товара по наименьшей цене. Для этого программа должна отправить запрос в соответствующую учетную систему и в целый ряд профильных электронных магазинов, например, в Amazon и eBay, у которых есть общедоступные интерфейсы Web-сервисов. После получения ответной информации выбирается вариант с наименьшей ценой. Диаграмма этого бизнес-процесса определения стоимости товара приведена на рисунке 6.4. Разумеется, за ним может следовать автоматическое продолжение - заказ товара, отправка его покупателю и т. д.

Рис. 6.4. – Определение стоимости товара.

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

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

<invoke name="invoke-1" partnerLink="AccountingDept" portType="services:CreditRatingService" operation="process" inputVariable="crIn" outputVariable="crOut"></invoke>

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

Создаваемые с помощью BPEL приложения относятся к категории "процессно-ориентированных" (process-based applications). Фактически они состоят из двух отдельных слоев исполнения. Верхний слой описывает бизнес-логику процесса, представленную на языке BPEL, нижний слой выполняет собственно все функциональные операции с помощью различных Web-сервисов. BPEL-приложение может выполняться на любом сервере приложений, имеющем механизм исполнения BPEL.

Развитые инструменты позволяют визуально проектировать полнофункциональные BPEL-приложения, не требуя написания кода вручную. Эти средства, кроме того, включают функции автономного тестирования программы. Однако для работы в реальных условиях под управлением BPEL-сервера требуются правильные установки для всех используемых Web-сервисов в WSDL-файлах, а также конфигурирование необходимых коммуникационных протоколов (например, Java Message Service или HTTP).

Рассмотрим в соотвествии с [115] основные элементы языка BPEL (BPEL4WS) и правила их использования.

Язык BPEL4WS во многом он похож на BPML, однако существенно сложнее его. Как уже было отмечено выше, появился BPEL4WS путем слияния WF-языков WSFL и XLANG. Эти языки основаны на разных моделях: WSFL базируется на теории графов, XLANG - на иерархии тегов XML. BPEL4WS унаследовал конструкции обоих языков. Например, он допускает реализацию некоторых WF-паттернов в двух вариантах: в стиле WSFL и в стиле XLANG. В некоторых случаях допустим и смешанный стиль. Это делает BPEL4WS трудным для изучения.

Несмотря на то что BPEL4WS является наследником языков различной природы, его можно отнести к классу структурно-ориентированных: унаследованные “граф-ориентированные” конструкции реально соответствуют некоторым ограничениям на порядок выполнения Activities внутри параллельного блока.

BPEL4WS определяет два вида процессов - абстрактный и исполняемый. Абстрактный процесс определяет протокол обмена сообщениями между различными участниками, не “открывая” алгоритмы их “внутреннего” поведения. В отличие от абстрактного исполняемый процесс содержит в себе алгоритмы, определяющие порядок выполнения Activities, назначение исполнителей, обмен сообщениями, правила обработки исключений и т. д. Activities в BPEL4WS делятся на примитивные и структурные.

Примитивные Activities:

-  Receive - ожидает сообщения от внешнего источника;

-  Reply - отвечает внешнему источнику;

-  Invoke - “запускает” операцию какого-либо Web-сервиса;

-  Wait - ждет в течение определенного периода времени;

-  Assign - копирует значение одной переменной в другую;

-  Throw - отбрасывает исключение в случае ошибки;

-  Terminate - принудительно завершает выполнение службы;

-  Empty - не выполняет никаких действий.

Структурные Activities:

-  Sequence - соответствует последовательному выполнению Activities, содержащихся внутри этого элемента.

-  Switch - условная передача управления (соответствует оператору Switch языков программирования С++, Java и т. д.);

-  While - организует цикл типа “While”;

-  Pick - запускает обработку событий и исключительных ситуаций;

-  Flow - соответствует параллельному выполнению Activities, содержащихся внутри этого элемента;

-  Scope - группирует узлы для программы -- обработчика ошибок.

Кроме того, в языке присутствует понятие “связь” (link). Эта конструкция унаследована из граф-ориентированного “предка” BPEL4WS. Как правило, применяется она к Activities, находящимся внутри параллельного блока, и накладывает ограничения на порядок их выполнения. К конструкции языка, использующей link, может быть применено, например, такое ограничение: «Activities, соединенные при помощи этого элемента, не могут образовывать циклы».

Переменные описываются при помощи тега “variables”. Для задания исполнителя используется тег “partnerLink”. В некоторые теги добавлен параметр “variable”.

Общение с “внешним миром” в BPEL4WS определяется технологией Web-сервисов.

BPML (Business Process Modeling Language) - язык на основе XML, предназначенный для определения формальной модели, выражающей выполнимые процессы, которые описывают все аспекты корпоративных бизнес-процессов, в том числе с использованием Web-сервисов. В отличие от XPDL, он принадлежит (как и BPEL) к так называемым структурно-ориентированным языкам: бизнес-процесс в BPML соответствует не математическому графу, а иерархическому набору вложенных и последовательных тегов.

Рассмотрим общее описание языка в соотвествии с работой [116].

Язык BPML дополняет язык реализации бизнес-процессов BPEL. BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого Web-сервиса. BPML преобразует ("мэппирует") бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web-сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др.

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

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

Простые типы операций BPML:

- Action - выполняет или вызывает выполнение операции, включающей обмен входящими и исходящими сообщениями;

- Assign - присваивает новое значение показателю;

- Call - запускает процесс и ждет его завершения;

- Compensate - инициирует компенсацию для указанных процессов;

- Delay - выражает промежуток времени;

- Empty - ничего не делает;

- Fault - выдает сообщение об ошибке в текущем контексте;

- Raise - активизирует сигнал;

- Spawn - запускает процесс без ожидания его завершения;

- Synch - синхронизирует по сигналу.

Сложные типы операций BPML:

- All - выполняет операции параллельно;

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

- Foreach - однократно выполняет операции для каждого пункта из списка;

- Sequence - выполняет операции в последовательном порядке;

- Switch - выполняет операции из одного из составных комплектов, выбранного на основе истинного значения условия;

- Until - выполняет операции один или более раз на основе истинного значения условия;

- While - не выполняет операции или выполняет их один или более раз на основе истинного значения условия.

Простые операции - это операции, которые могут привести к выполнению множественных операций, в частности такие, как action, call, compensate и spawn. Но сама простая операция не определяет контекст для выполнения других операций. BPML включает все логические конструкции строгого языка программирования. Простые операции прерывают выполнение (abort) или выдают сообщение об ошибке (fault), если их завершению препятствует неожиданная ошибка.

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

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

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

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

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

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

Рассмотрим в соотвествии с [115] основные элементы языка BPML и правила их использования.

Основные элементы, при помощи которых определяется workflow-процесс в BPML:

-  Activity (узел - действие);

-  Context (контекст);

-  Property (свойство);

-  Signal (сигнал);

-  Exception (исключение).

Activity - основной элемент бизнес-процесса. Элементы Activity могут соединяться последовательно или вкладываться один в другой. Соответственно Activity могут быть простыми (не содержащими других Activity) или сложными. В описании языка указано, что бизнес-процесс является специальным типом сложной Activity. Всего существует 17 типов простых Activity. Основной тип простой Activity называется Action. Когда управление бизнес-процессом попадает в Activity этого типа, происходит вызов описанных там Web-сервисов. Есть типы Activity, соответствующие ветвлению процесса (ветвление относится только к содержащимся внутри них Activities), - это Switch и All Activities. Также существуют типы Activities, которые запускают дочерние процессы (как с ожиданием их окончания, так и без), организуют задержки выполнения процесса и т. д. Кроме того, есть несколько типов Activities, реализующих разного вида циклы. Для синхронизации точек управления, находящихся в Activities одного уровня вложенности, в языке используются сигналы (Signals).

В BPML также введены понятия “исключение” (Exception) и “компенсация” (Compensation). “Исключение” соответствует возникновению нештатной ситуации, когда оказывается, что выполнять некоторый участок бизнес-процесса уже не требуется. Например, во время выполнения бизнес-процесса оформления туристической поездки клиент позвонил в туристическую компанию и сообщил, что он отказывается от поездки.

“Компенсация” соответствует необходимым действиям по корректному завершению ситуации, возникшей в связи с Exception. Если в вышеприведенном примере для клиента были забронированы билеты на самолет и номер в гостинице, то задачей Compensation будет отменить бронирование.

На языке BPML данные описываются в рамках контекста (Context). Контекст содержит относящиеся к процессу переменные, локальные определения процессов, сигналов и т. д. и служит для передачи информации между узлами и синхронизации. Переменные определяются тегом Property. Они могут быть локальными или глобальными по отношению к данному контексту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-12-27