Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Bruce Silver

Оригинал статьи: Roundtripping Revisited

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

Затем возникла новая концепция: BPM-система (BPM Suite), объединяющая в одном интегрированном пакете моделирование, средства исполнения и BAM, что сулило лучшее взаимопонимание между бизнесом и ИТ и динамичность (agility), позволяющую реагировать на непрерывно меняющиеся требования бизнеса. Модель процесса вдруг перестала быть просто спецификацией бизнес-требований – оказалось, что на самом деле это первая фаза реализации процесса. Нет проблем, сказали BPEL-вендоры. Мы просто сгенерируем «скелет» кода BPEL из модели процесса, и передадим его разработчику BPEL. Готово! Вовлечение бизнеса! Взаимопонимание между бизнесом и ИТ!

Но такой взгляд на интерфейс между фазой моделирования процесса и фазой проектированием его исполнения – как на односторонний канал передачи информации – изначально был ущербным. Одна проблема возникает на стороне моделирования. Экспорт модели в BPEL, с его блочной структурой, накладывает новые ограничения на диаграмму. При попытке сгенерировать и экспортировать BPEL из модели, абсолютно корректной с точки зрения спецификации BPMN, вдруг появляются сообщения об ошибках. Другая проблема встает на стороне BPEL. Когда BPEL-проект обретает плоть и кровь, он неизбежно отклоняется от исходной диаграммы BPMN, и бизнес-аналитики теряют контакт с исполняемой схемой вскоре после передачи информации. Замечательная вовлеченность бизнеса, ничего не скажешь!

Мы получили то, что стало известно как “roundtrip”-проблема. Простого способа обеспечить на протяжении всего жизненного цикла процесса соответствие между моделью в BPMN или другой аналогичной нотации и исполняемым BPEL не существует. Суть дела в том, что вы не можете модифицировать модель процесса в соответствии с изменениями в BPEL. Нельзя вернуть обратно зубную пасту, выдавленную из тюбика. Таким образом, модель не является текущим взглядом бизнеса на реализацию процесса. Фактически, она остается тем, чем была всегда – начальными бизнес-требованиями.

Проблема roundtrip застала некоторых BPEL-вендоров врасплох. Для них, пришедших к BPM от интеграции, идея подпустить людей бизнеса сколько-нибудь близко к реализации представлялась как минимум безвкусицей. Но стало ясно: вовлечение бизнеса – это, в конечном счете, ключевой элемент ценности BPM. И вендоры признали, что да, действительно, BPMN-BPEL roundtrip – это серьезная проблема.

Тем временем, группа меньших по размеру компаний достигла успехов в привлечении как покупателей BPM, так и аналитиков, полностью игнорируя BPEL. Такие вендоры, как Lombardi, Appian и Savvion, сконцентрировавшиеся в большей степени на процессах, вовлекающих людей, чем на интеграции, открыли путь для новой разновидности BPMS, в которой детали исполнения накладываются прямо на модель процесса в виде свойств шагов BPMN-процесса, относящихся к исполнению. Новая разновидность не предусматривает передачу информации между различными инструментами (с разными моделями потоков, моделями данных и моделями программирования), а использует преимущество единого инструмента, совместно используемого бизнесом и ИТ, где бизнес фокусируется на шагах и потоках, а ИТ – на том, как эти шаги исполняются.

Для этой новой разновидности BPMS проблемы roundtrip не существует. Если ИТ необходимо внести правку в последовательность шагов, то модифицированная модель процесса немедленно становится видна бизнес-аналитику. Сам инструментарий способствует совместной работе бизнеса и ИТ на протяжении всего цикла разработки, и хорошо стыкуется с agile-методологиями итерационной разработки, которые существенно сокращают продолжительность цикла от модели до внедрения. Преимущества вовлечения бизнеса и большей динамичности с лихвой перекрывают недостаток проприетарной среды исполнения BPMS, и в последние годы этот подход выбрало большинство BPMS вендоров. Когда крупные компании – поставщики промежуточного ПО, приверженные стандартам, такие как BEA и TIBCO, выскочили на арену BPM, купив «чистые» (pureplays) BPMS, они взялись не за BPEL. Вместо этого они выбрали подход, в котором моделирование и реализация едины, несмотря на проприетарную среду исполнения, и оба постепенно трансформируют свои системы в направлении полной поддержки стандарта BPMN.

Таким образом, один ответ на проблему roundtrip – это сказать, что она больше не существует, что это артефакт дней минувших, попытка применить BPEL в области, к которой он не имеет отношения… к BPM! Я считаю, что в этом утверждении истины больше, чем крупица. Но это еще не конец истории.

В последние годы я преподавал моделирование бизнес-процессов средствами BPMN бизнес- и ИТ-пользователям. Естественно, я ожидал увидеть слушателей, чьи компании выбрали BPMN в качестве стандарта моделирования процессов. Но они приходили не из-за того, что только что приобрели Lombardi, Savvion или Appian. На самом деле, если они и успели сделать выбор BPM для исполнения процессов, то в большинстве случаев это был BPEL. Он стандартен, широко распространен, доступен в виде open source. Именно его используют для исполнения бизнес-процессов IBM и Oracle. Все это – факторы в пользу BPEL. Но стандартизовать и BPMN, и BPEL? Нет, конечно это нелогично. Обычно решения принимались независимо разными группами внутри компании, не имеющими никакого представления о заботах других. Но решения были приняты, и если BPM суждено развиваться в этих компаниях, то с этим надо что-то делать.

После того, как я около года был в лагере сторонников мнения «roundtrip мертв», я теперь столкнулся с необходимостью снова вернуться к этой теме. В частности, на моих курсах слушатели интересуются: какие стратегии или паттерны следует использовать в диаграммах BPMN, чтобы они хорошо стыковались с предполагаемой BPEL-реализацией? Не предполагал, что мне придется об этом задумываться.

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

Попытки создать более изощренную трансляцию предпринимались нечасто, и общее число их невелико. Наиболее удачные из мне известных предпринимались Марлона Думаса (Marlon Dumas) и его коллег из Университета Квинсленда в Австралии (см. http://eprints.qut.edu.au/archive/00005266/) и И Гао (Yi Gao), техническим директором начинающей компании-разработчика инструментария eClarus (см. http://www.eclarus.com/pdf/BPMN_BPEL_Mapping.pdf). Они применили разные подходы, но сошлись в общей стратегии. Она заключается в том, чтобы идентифицировать те фрагменты диаграмм, которые без труда преобразуются в BPEL, а оставшиеся фрагменты преобразовать или перерисовать в семантически эквивалентные, опять-таки приведя их к таким, для которых преобразование в BPEL не составляет труда. При таком подходе подмножество диаграмм BPMN, которое не может быть преобразовано в BPEL, в действительности оказывается весьма небольшим. На самом деле, множество проблемных паттернов, выделенных Думасом, не соответствуют спецификации BPMN. Однако такие подходы, насколько мне известны, не нашли широкого признания у BPMN-вендоров. Это проблема номер один.

Проблема номер два – более тонкая. Цель, которую поставили перед собой упомянутые выше исследователи – создать из BPMN «читабельный» BPEL – основывается на предположении, что разработчикам все же понадобится редактировать сгенерированный BPEL. С моей точки зрения, это в корне неправильно. Возможно, roundtrip-проблема не умерла, но односторонняя передача информации от требований к реализации – эта парадигма точно мертва, по крайней мере применительно к BPM. Парадигма совместной реализации, в которой исполняемый процесс накладывается на BPMN-модель,– вот к чему по-прежнему надо стремиться. Я смотрю на BPEL как на Java: вы можете генерировать его «под полой», но в этом случае у вас не должно возникнуть желания вручную его редактировать. Достоинства BPEL, которыми следовало бы воспользоваться – это его стандартность и общедоступность среды исполнения, а не его полезность в качестве языка исполнения для BPM.

Итак, если создание «читабельного» BPEL – это не та цель, к которой стоит стремиться, то что является такой целью? Я считаю, что целью должно быть определение возможно более широкого подмножества BPMN, допускающего автоматическую трансляцию в BPEL (с использованием последних достижений), и затем определение самой этой трансляции. Мне необходимо это знать, потому что я хочу иметь возможность учить моих слушателей использованию в диаграммах BPMN дружеских по отношению к BPEL паттернов. Уже сейчас фактически тренинги по BPMN – это в основном изучение паттернов, которые наилучшим образом выражают семантику процессов, так что концептуально в этом нет ничего нового. Если мы не редактируем BPEL прямо, то нам незачем беспокоиться об обратной трансляции в BPMN (но если редактируем, то беспокоиться определенно надо).

На фоне ожиданий, что IBM, SAP и Oracle повлияют на работы над BPMN 2.0, мы можем надеяться на некоторую помощь в этом со стороны самого стандарта. Но я не хочу ждать так долго.

Диалог с Думасом на тему roundtrip

Марлон Думас дал вдумчивый ответ на мою заметку о проблеме roundtrip. Чтобы разобраться по пунктам, ниже я цитирую комментарии Марлона, перемежая их моими ответами:

Марлон: Брюс, я согласен со многими из Ваших утверждений, но я решительно не согласен с тезисом о том, что BPEL – это аналог языка ассемблера и что читабельность кода BPEL, сгенерированного из BPMN, не важна. Вот основные мои возражения:

Марлон: 1) Вам не удастся исключить разработчика из жизненного цикла BPM – просто потому, что ни один бизнес-аналитик никогда в жизни не захочет писать что-либо напоминающее выражение XPath или любой другой язык регулярных выражений. А как иначе вы закодируете для целей исполнения все ваши условные выражения и функции преобразования данных, необходимые для запуска процессов и передачи данных? Надо просто познакомиться с опытом первых последователей парадигмы «BPM поверх SOA», например Danske Bank, в котором такой проект выполняется в течение 4 лет. У них есть три роли: бизнес-аналитик разрабатывает высокоуровневую модель при помощи нотации типа BPMN, архитектор решения уточняет модель т определяет какие ее части могут быть автоматизированы и каким образом, и наконец разработчик, который транслирует их (вручную) в исполняемую модель процесса (подробное обсуждение см. здесь: http://brahe.org/MamboPHD/index.php?option=com_docman&task=docclick&Itemid=31&bid=27&limitstart=0&limit=5).

Брюс: Никто и не говорит об исключении ИТ из жизненного цикла BPM. На самом деле, я даже согласен с 3 Вашими ролями, хотя я бы определил их функции несколько иначе. Бизнес-аналитик создает модель процесса в BPMN. Архитектор решения (ИТ) делает шаги процесса исполняемыми, конфигурируя их при помощи диалоговых окон, отрывающихся при помощи наведения и клика, и помощников (wizards), не прибегая к кодированию. Разработчик создает бизнес-сервисы при помощи Java, BPEL и чего угодно еще, при условии что их можно привязать к шагам процесса, чтобы сделать их исполняемыми. Разработчик может использовать SOA-инструментарий, в то время как бизнес-аналитик и архитектор решения используют BPMS.

Марлон: 2) Если мы вообще не беспокоимся о коде BPEL, то почему вендорам просто не разработать движок, непосредственно исполняющий BPMN? Если у вендора уже есть хороший движок BPEL, то ему не будет так уж сложно (при тех инженерных ресурсах, которыми он располагает) доработать его так, чтобы он непосредственно интерпретировал BPMN. И это позволит избавится от дополнительной суеты по поддержанию сложной трансляции между BPMN и BPEL, которая только усложняет трассировку и отладку. А если вендор так уж озабочен трансляцией BPMN во что-нибудь еще, то гораздо больше смысла было бы транслировать его в язык низкоуровневый по отношению к BPEL, например в набор привязанных к событиям (event-driven) правил, которые мог бы исполнять хорошо масштабируемый движок обработки сложных событий (CEP, Complex Event Processing).

Брюс: И я о том же. Примерно это и сделали Lombardi, Appian и Cordsys. У большинства вендоров уже есть движок, который можно доработать, поэтому если он поддерживает семантику, выраженную в BPMN, то второй возможный вариант – это сделать BPMN площадкой для проектирования и спрятать проприетарный внутренний язык. Под это описание подошли бы Savvion, TIBCO, webMethods, а вскоре, я думаю, BEA и прочие. Почему не CEP-движок? Действительно, почему нет, если он работает? Движок оценивается по производительности, устойчивости и стоимости. Разве кого-нибудь волнует что представляет собой его внутренний язык? Я утверждал, что достоинство BPEL заключается в том, что для него есть недорогие высокопроизводительные движки, доступные из нескольких источников. Никакого отношения к языку, как таковому, это не имеет.

Марлон: 3) После того, как в BPEL так много инвестировано, маловероятно, что такие вендоры как Oracle и IBM заменят его BPMN. BPMN должен быть дополнением к BPEL (т.е. находиться на более высоком уровне абстракции).

Брюс: Не меняйте BPEL на BPMN, ведь в действительности они не конкурируют друг с другом. Я предлагаю поменять прямое редактирование BPEL (в BPM-системе, не обязательно в SOA-инструментарии) на BPMN плюс помощники (wizards), вызываемые по клику мыши, в духе Lombardi. Оба упомянутых Вами вендора уже сделали начальные шаги в этом направлении, и я предсказываю, что в течение пары лет BPM от Oracle и IBM в части инструментария станут гораздо более дружественными по отношению к бизнес-пользователям, не отказываясь при этом от BPEL в нижележащей среде исполнения.

Марлон: 4) Даже если мы решим использовать BPMN для определения исполняемого процесса (к чему сейчас стремятся различные вендоры), нам понадобятся две версии BPMN: «Бизнес-BPMN» и «Исполняемый BPMN», предназначенные для разных типов пользователей (например, для бизнес-аналитиков и архитекторов/разработчиков). Приоритеты бизнес-аналитика отличаются от приоритетов архитектора решения и приоритетов разработчика. Бизнес-аналитик захочет снабдить свою модель атрибутами, содержащими информацию о рисках, требованиях регулирующих органов, а также параметрами для имитационного моделирования. Архитектора решения и разработчика интересуют извлечение и передача данных, задание связей с приложениями, управление безопасностью, масштабируемостью и надежностью.

Брюс: Я согласен с тем, что модели процессов не всегда создаются с намерением их исполнять, а также с тем, что в зависимости от этого используемые стили BPMN могут несколько различаться. Но я думаю, что это результат незрелости обучения BPMN. Не уверен что Вы это имели в виду, но BPMN содержит массу атрибутов, введенных исключительно для генерации BPEL, причем они, как правило, игнорируются. Если Вы это подразумевали под исполняемым BPMN, то я согласен – давайте избавимся от всего этого барахла. Независимо от того, намереваемся мы создавать исполняемую версию или нет, есть еще линия раздела между разработчиками модели, которые думают о таких вещах, как обработка событийных исключений (event throw-catch), multipool процессах, связанных потоками сообщений, и о компенсациях транзакций, и теми, кто обо всем этом не заботится. Как раз эти возможности во многих BPMN-средствах отсутствуют, так что должна быть какая-то разграничительная линия по отношению к классам степени соответствия требованиям совместимости, и я работаю с ребятами из XPDL с целью продвижения этой идеи.

Марлон: Если Вы когда-нибудь передумаете и захотите познакомиться с трансляцией из BPMN в BPEL, которая достаточно полна И производит читабельный код, просто направьте Ваш браузер Firefox сюда: http://www.bpel4chor.org/editor/. Для примера взгляните на BPMN модель PriceRequest. Открыв, вы сможете экспортировать ее в BPEL – в меню четвертая кнопка слева («Export to BPEL4Chor»). Примечание: этот полностью онлайновый BPMN-редактор работает только в Firefox и его загрузка в окно браузера занимает от 10 до 15 секунд. Эта работа не завершена – если Вам удалось правильно экспортировать в BPEL Вашу любимую модель BPMN при помощи этого онлайнового редактора, просто бросьте email на gero.decker@hpi.uni-potsdam.de.

Брюс: Если судить по тому, что Вы рассказали здесь, а также приватно, это очень круто. Я намерен посмотреть!

Прочие комментарии

CraigH: Я думаю, Марлон ухватился не за тот конец. Дело не в том, чтобы сгенерировать читабельный BPEL для разработчиков – дело в том, чтобы отразить все изменения в процесс, которые вносят разработчики, обратно в модель аналитиков. До тех пор, пока разработчики используют свое собственное представление процесса, при попытке аналитика внести правки разработчика (BPEL) обратно в модель BPMN будет оставаться масса возможностей ошибочной интерпретации. Это означает, что кто-то – вероятно, разработчик – должен быть способен взглянуть на представление BPEL и определить какие кусочки BPEL каким кусочкам BPMN соответствуют, чтобы хотя бы определить в какие части карты BPMN нужно вносить исправления.

Занятие это ручное, подверженное ошибкам и неэффективное. Но что хуже всего, оно продолжает традицию взаимоотношения между аналитиками и программистами в стиле «мы и они», от которого мы только начали избавляться. Совместная работа над одной и той же моделью – вот отличная для этого возможность.

jdubray: Craig, хотя работа этой группы исследователей заслуживает внимания, я от всего сердца с Вами согласен. Эту статью я написал, чтобы аргументировать более подробно: http://www.infoq.com/articles/seven-fallacies-of-bpm

Комментарии