|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Литература: Автор: Артамонов Иван Васильевич «Процессное направление» современной ИТ-индустрии активно развивается. Последнее десятилетие привнесло в нашу жизнь ряд важных и не очень BP-терминов и BP-аббревиатур: 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). За некоторыми аббревиатурами из них скрываются мощнейшие комплексы информационных систем поддержки бизнес-процессов, подходы к описанию, моделированию и исполнению бизнес-процессов, общепринятые и нишевые, активно использующиеся и возможно уже устаревшие (всего за несколько лет!) стандарты. На данный момент (начало 2010 года) в отрасли сформировались и используются несколько стандартов описания бизнес-процессов. Отмечу, что из данного обзора намеренно исключены стандарты описания бизнес-процессов, которые разработки которых были завершены до 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. Приведем таблицу, предложенную М. Романовым [11], и дополним ее.
Эти стандарты стали разрабатываться в ответ на потребности рынка информационных технологий для бизнеса в начале 2000-х. В тот момент обострились проблемы интеграции разнородных приложений на одной технологической площадке, проблемы поддержки унаследованных приложений и данных, появилась концепция веб-служб, стали активно развиваться технологии управления бизнес-процессами (BPM), а вслед за этим появилась и парадигма сервис-ориентированной архитектуры (SOA). Эти и другие вызовы рынка заставили крупнейших поставщиков, развивая свои предложения, разрабатывать внутрикорпоративные стандарты поддержки бизнес-процессов для их описания, реализации и исполнения в рамках своих программных систем. Было опубликовано множество спецификаций, таких как 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 можно узнать в официальной спецификации стандарта в [22]. В общем случае BPEL-скрипт включает:
Команды BPEL называют activities (букв. с англ. «действия»). Их можно разделить на 4 типа: 1. Коммуникации, например:
2. Управление, например:
3. Ошибки, например:
4. Другое, например:
Подробнее о семантике 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), вице-президент по исследованиям и разработкам корпорации Fujitsu America Inc, считает возможность его расширения [2]. Язык поддерживает возможность введения дополнительных атрибутов (ExtendedAttributes), которые производитель ПО может вводить для своих целей. Например, одна утилита может вводить определенные требования на диаграмме, сохраняя их через расширенные атрибуты. Другая утилита, естественно, эти расширения распознать и адекватно обработать не сможет, но может их сохранить в модели, и, в случае необходимости, вернуть обратно. С другой стороны, возможности расширения и поддержки элементов и атрибутов именно для исполнения процессов некоторые аналитики считают недостаточными, выходящими за рамки возможностей 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 NotationBPMN – графическая нотация для моделирования бизнес-процессов. BPMN изначально был разработан консорциумом BPMI, а на сегодняшний день поддерживается OMG после того, как эти две организации объединились. Основная цель BPMN – поддержка нотации, которая одинаково будет пониматься всеми участниками бизнеса, от бизнес-аналитиков, которые разрабатывают эскизы процессов, разработчиков, которые реализуются технологию для выполнения этих процессов, и до бизнесменов, менеджеров, которые будут управлять и наблюдать за процессами. Таким образом, отмечает официальная спецификация, 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 (EPCs). С одной стороны, BPMN разработана как простой и понятный механизм моделирования процессов, с другой стороны, спецификация должна быть способна обеспечить описание всей полноты и сложности бизнес-процесса, поэтому все графические элементы BPMN разбиты в упорядоченную иерархию:
В стандарте BPMN 1.2 события делили также на две группы: события генерации и обработки. События обработки реагируют на определенный триггер, к таким событиям относятся все начальные и некоторые промежуточные. События обработки возвращают некий результат, к таким событиям относятся все завершающие и некоторые промежуточные события. В BPMN 2.0 группировка усложнилась, начальные и промежуточные события стали разделять для разных типов процессов и прерываний. Activity (Действие) – это работа, которая выполняется в бизнес-процессе. Это исполняемый элемент BPMN-диаграммы. Действие может быть атомарным или составным. Отображается прямоугольником с закругленными углами. Определено 3 типа действий:
Вызывающее действие (call activity) позволяет включать повторно используемые глобальные задачи и процессы в диаграмму и идентифицируют точку их входа в процесс. Изображается прямоугольником со скругленными краями и толстой линией границы. Gateways (Логические операторы) необходимы для контроля над объединением и разветвлением потоков управления процессами. Прямой перевод слова как «ворота, шлюз» предполагает наличие некоего шлюзового механизма, который разрешает или не разрешает потоку управления проходить через себя, при этом поток может быть как разделен на альтернативные ветви, так и альтернативные ветви могут объединиться. Логические операторы определяют все типы поведения потока с условиями включения, исключения, сложными условиями, объединениями и разветвлениями. Логический оператор изображается «алмазом», внутри которого изображается тип операции.
Data (Данные) предоставляют процессу объекты, которые могут создаваться, использоваться и обрабатываться в ходе выполнения процесса.
Connecting Objects (Соединяющие объекты) определяют четыре способа взаимодействия объектов потоков друг с другом и с другими элементами:
Swimlanes (букв. «Плавательные дорожки», иначе говоря «Разделительные дорожки») позволяют группировать элементы модели по пулам и дорожкам, распределяя между ними обязанности.
Artifacts (Артефакты) используются для предоставления дополнительной информации о процессах. Существуют два стандартных артефакта (Group (Группа), Text Annotation (Аннотация), однако для своих нужд разработчики могут создавать любые другие. Текстовая аннотация служит для дополнительного описания элемента диаграммы. Изображается половинкой прямоугольника. Группа служит для группировки элементов диаграммы. Изображается прямоугольником с закругленными углами в пунктирную через точку линию. Артефакты не могут выступать как элементы потока управления, не могут соединяться потоками управления или сообщения, на них не накладываются ограничения пулов и дорожек. Таким образом, например, группа может пересекать границы пула для объединения элементов диаграммы. Отдельно следует выделить особый элемент BPMN, который не отображается отдельным графическим элементом, но присутствует или предполагается на любой диаграмме – это участник (participant). Под участником может пониматься некая сущность – бизнес-партнер (например, компания-поставщик) или роль процесса (например, покупатель), участвующая в процессах взаимодействия. Именно участника отображают пулы BPMN. С понятием участника тесно связаны диаграммы взаимодействия (совместные диаграммы) BPMN. В ранних спецификациях эти диаграммы выделяли в отдельный тип и называли глобальными (Collaboration (global)). На диаграмме взаимодействия показаны несколько пулов и потоки сообщений между ними. В BPMN 2.0 определены два основных типа процессов процессы хореографии и процессы оркестровки. Процессы оркестровки представляют собой набор действий или взаимодействие внутри компании. С этими процессами наиболее часто работают бизнес-аналитики. В BPMN к ним относят частные (внутренние) и абстрактные (открытые) процессы.
BPMN 2.0 стал поддерживать процессы хореографии, основной целью которых стало формализация взаимоотношений между бизнес-партнерами (организациями, компаниями), участниками некоторых совместных операций. Диаграммы фокусируются на не работе, выполняемой участниками, а на процессах обмена информацией между ними. В официальной спецификации BPMN 2.0 приведен интересный пример, наглядно изображающий, как при описании взаимодействия диаграммы хореографии позволяют уменьшить количество необходимых элементов в разы по сравнению с теми же диаграммами взаимодействия. Основным элементом диаграмм хореографии стало действие хореографии (Choreography Activity) – некий этап взаимодействия между двумя сторонами. Единое, неделимое действие, задача хореографии описывает процесс обмена сообщениями между двумя участниками. Название процесса и имена участников подписываются на графическом элементе задачи хореографии – скругленном прямоугольнике с тремя областями. Соединяются задачи потоками управления, которые могут проходить через шлюзы. Существуют несколько специфических типов потоков управления и особенностей их использования в диаграммах этого типа. Диаграммы хореографии могут быть как детализированы с помощью диаграмм взаимодействия, так и присутствовать на них. Процессы хореографии поддерживались в BPMN 1.2 в виде диаграмм взаимодействия, однако специалисты находили в этом подходе ряд существенных недостатков, например, Геро Декер в [63] говорит о ненужной избыточности, несоответствии потоков управления и событий запуска процессов. Введение элементов хореографии устранила часть этих проблем, но и породило свои, например, проблемы очередности взаимодействия между множеством участников. Подробнее об элементах BPMN можно прочесть в официальной спецификации BPMN. Взаимоотношение 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), основатель компании Intalio и вообще концепции BPMS, вступая в эту дискуссию напрямую, приводит несколько положений в [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 роль только в процессах интеграции и СОА. Список используемой литературы
Комментарии |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|