|
|||||||||
|
|||||||||
BPMN 2.0: говорят о ней так часто и так много, что уже не все помнят, чем она отличается от версий 1.х. И еще вопрос, стоят ли изменения, которые ожидается увидеть в 2.0, того, чтобы так долго и с такой надеждой их ожидать? BPMN – это графическая нотация для изображения бизнес-процессов. Задумана она с целью создания единообразных описаний процессов. Однако в первых версиях нотация не была рассчитана на исполнение процессов в BPM-системе, поэтому разработчиков стандарта мало заботило то, каким образом BPMN-схема будет переведена в XML формат. Все инициативы WfMC в этом направлении не находили поддержки со стороны OMG. Но необходимость создания исполняемых моделей процессов вызвала необходимость создания такой нотации, которая поддерживала бы XML формат и была бы одинаково интерпретирована любой, поддерживающей эту нотацию, системой. Статус стандарта вынуждал бы производителей BPM-систем поддерживать эту нотацию. Таким стандартом претендует стать BPMN 2.0. Однако далеко не все члены BPM сообщества настроены по этому поводу оптимистично. Условно можно выделить несколько групп различного рода специалистов, ожидания которых не одинаковы, о чем пишет в своей заметке BPMN 2.0 – Marriage Made In Heaven or Trough of Disillusionment Дерек Миерс (Derek Miers), шеф BPM-focus.
Франк Пулман (Dr. Frank Puhlmann) выделяет две таких группы («BPMN 2.0 drafts»). Первая, в которую входят IBM, Oracle, SAP, Unisys в качестве инициаторов, а также IDS Scheer, Software AG, TIBCO, Intalio и другие предлагает базироваться строго на предыдущих версиях спецификации. В то время как вторая, к которой Франк относит Axway Software, EDS, Lombardi Software, MEGA International, Troux, Unisys в качестве инициаторов (Unisys и тут и там!) предлагают подогнать нотацию под Business Process Definition Metamodel (BPDM). Сам автор придерживается первого мнения, поскольку во втором случае мы получим набор таблиц и фигур, которые сделают модель нечитаемой. Рассматривая BPMN 2.0 с позиции первой группы, Франк выделяет несколько областей расширения нотации по сравнению с 1.1.
«Эта спецификация также устраняет имеющиеся в 1.1 противоречия и неясности» (цитата из драфта спецификации) За границами будущей спецификации остаются такие аспекты как
Основным достижением спецификации будет включение XML схемы на основе мета-модели, поддержка хореографии, семантика исполнения, усовершенствованное BPEL-отображение и множество мелких добавлений и исправлений. Мета-модель, основанная на XML-схеме. Все BPMN элементы описаны в XML, что обеспечивает стандарт мета-модели. Было бы полезно, если бы это было визуализировано. Хореография. Спецификация вводит третий тип модели – хореографию. Первые два – оркестровка и совместная работа. Хореография – это «определение ожидаемого поведения, по существу, процедурный договор между взаимодействующими участниками. В то время как обычный процесс существует внутри пула, хореография существует между пулами (или участниками)». Проект спецификации определяет ряд правил, по которым могут быть определены задания. Говоря о хореографии, необходимо упомянуть обмен сообщениями, называемый «conversation», определяемый в BPMN как «набор обменов сообщениями, имеющими одинаковую взаимосвязь». Спецификация определяет несколько видов взаимосвязей (на основе ключей или выражений), тесно связанных с BPEL. Семантика исполнения. Каждый объект имеет свой жизненный цикл с состояниями, такими как активирован, в работе (исполняется), завершен, выполняется компенсация и т.д. Семантика исполнения – это описание в табличном виде различных состояний объектов процесса. Кроме того, описание непосредственно указывает на соответствующий шаблон процесса. Единственное, чего не хватает – это формального представления. К примеру, описание OR-Join до сих пор еще очень расплывчато. С другой стороны, неформализованное описание оставляет большую свободу исполнителям. BPEL-отображение. BPEL-отображение является очень существенным шагом. Однако часть ответственности остается на производителях BPM-систем, поскольку такое отображение накладывает на WS-BPEL процесс определенные ограничения. По крайней мере, он должен соответствовать операционной семантике BPMN процесса. Другие улучшения. Черновик спецификации содержит еще некоторые улучшения, такие как множественные пулы, маркеры для разных типов заданий, сборники данных, расширение взаимодействий между людьми (исполнителями, владельцами). Спецификация определяет расширенную модель, которая может использоваться для интеграции с другими артефактами. Появился новый вид события, который напоминает символ Star Trek и используется для эскалации. Промежуточные события могут быть представлены в виде подпроцессов. Один из самых авторитетных аналитиков и специалистов в области BPMN, Брюс Силвер, будучи участником команды разработчиков стандарта, консорциума OMG, в своем блоге часто обращается к этой теме. В заметке «5 Things to Love About BPMN 2.0» он приводит пять основных преимуществ 2.0:
Теперь о том, что не вошло в стандарт. Заметки от того же автора (Брюса Силвера) «Five Things They Left Out of BPMN 2.0».
Примерно о том же пишет Роберт Шапиро (Robert Shapiro) в заметке BPMN Process Interchange. Он считает, что некоторые нововведения усложнят модели, т.к. нет четкого разграничения атрибутов для исполняемых моделей и для более высокого уровня моделей, которые использует бизнес-аналитик. Кроме того, т.к. портативность модели подразумевает ее интерпретацию в XML, то необходимы будут инструменты, контролирующие структурную целостность XML данных. Причем, делать это надо как со стороны BPMN 2.0, так и со стороны XPDL 2.2. Франк Михаэль Крафт (Framk Michael Frank), Success with BPMN 2.0 отмечает, что большим плюсом BPMN 2.0 является возможность изображения как сильно-, так и слабосвязанных процессов. Сильно связанным является процесс, в котором возможность регистрации клиентского заказа зависит от наличия утвержденной цены на продукцию. Слабосвязанный процесс – это клиент регистрирует заказ в любое время. В первом случае шаги процесса объединяются в один пул. Слабосвязанные процессы моделируются сквозь пулы как совместная работа или как хореография. Такое деление – на сильно- и слабосвязанные процессы – оказывает решающее влияние на успех. И это вопрос не столько разработки, сколько бизнеса, поскольку от него зависит гибкость компании. А вот мнение Макса Пачера (Maks J. Pucher), основателя и главного архитектора ISIS Papyrus Software не такое радужное. В своей статье BPMN 2.0 - A Step Sideways! Он пишет, что несколько дезориентирован будущим стандартом. Он считает, что дополнения, сделанные в стандарте, делают модели очень неоднозначными. «Activity» может представлять любое количество различных функций, и новые типы событий недостаточно детализируют то, как они взаимодействуют в потоке. Там все еще нет артефактов, атрибутов и моделирования состояний и нет бизнес-правил. Обещанное UML-подобное моделирование данных, похоже, тоже отсутствует. Т.е. модели в BPMN 2.0 нельзя будет взять как есть, а необходимо будет перекодирование в BPEL+Java. Т.е. нет никакого замкнутого цикла («roundtrip») и вовлечения пользователей («user empowerment»). Весь входящий и исходящий контент и артефакты по-прежнему придется программировать. Правда, дальше выясняется, что автор вообще противник диаграмм и считает ущербным не столько BPMN 2.0, но и подход к BPM на основе диаграмм («flowcharting BPM approach») в целом. Это еще раз доказывает, что единого мнения по поводу будущего стандарта не существует (да и не может существовать), поскольку выбирая один путь развития, непременно остаются в стороне интересы другого «лагеря». Остается только надеяться, что если стандарт будет принят такими крупными BPM-вендорами, как IBM, SAP, Oracle, TIBCO, Appian и т.д., то остальное сообщество «подтянется». Лучшего-то пока не придумали… =WJ Комментарии |
|||||||||
Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | |||||||||
|
Спасибо за статью - много, интересно и по делу.
Можно еще немного пояснить ситуацию с
> будет включение XML схемы на основе мета-модели
т.е. будет XML Shema и соответственно можно будет говорить о корректном и валидном XML-документе диаграммы процесса?
> усовершенствованное BPEL-отображение
т.е. будет постулированный путь прямого BPEL преобразования файла процесса, и может будет сразу готовый XLST?
> Мета-модель, основанная на XML-схеме. Все BPMN элементы описаны в XML,
> что обеспечивает стандарт мета-модели. Было бы полезно, если бы это было
> визуализировано.
возвращаемся к началу ... т.е. будет BPMN XML Shema, которая включает все возможные элементы BPMN-файлов процессов.
тогда вопросы переносимости моделей между средствами разработки должны сниматься или я не прав? разве что останутся проблемы одинакового отображения процессов в разных инструментах?
а визуализация схем это уже давно не проблема, редакторы есть, давно встроено в eclipse ee.
Николай,
честно говоря, у меня не сложилось впечатления, что в 2.0 все будет прямо в шоколаде. Судя по оценкам Брюса (а именно его я считаю наиболее объективным, да и к тому же он ближе всех к источнику), разработчики стандарта несколько далеки от реальности, плохо себе представляют РЕАЛЬНОГО пользователя стандарта. Приближать стандарт к разработчикам... да эти и так что хошь запрограммируют. Поморщатся - и запрограммируют. Им нужен моделлер? Не думаю. Хотя есть надежда, что, благодаря влиянию того же Брюса, направление все же выровняется.
Но то, что в 2.0 BPMN XML будет - это уже точно. В этом даже самые отъявленные скептики не сомневаются.