Оригинал блога: http://mainthing.ru/ru/item/328
Рассмотрим процессную диаграмму, позаимствованную мною (с
некоторыми упрощениями) из книги Stephen White, Derek Miers, «BPMN Modeling And
Reference Guide» (стр. 113):
Диаграмма иллюстрирует фрагмент процесса создания книги.
Процесс распадается на два подпроцесса, исполняемых параллельно: написание
текста и разработка обложки. Причем обложку можно начать делать только после
того, как автор определился с концепцией книги.
Сложность тут в том, что мы не можем реализовать эту
логику при помощи потока управления (sequence flow), так как он не может
пересекать границы подпроцессов. (Оставим в стороне вопрос, зачем нам тут
понадобились подпроцессы; будем считать, что зачем-то они нужны.) Сообщения
(message) использовать тоже нельзя, так как мы находимся в пределах одного
пула.
Стандартная рекомендация - использовать в подобной
ситуации механизм сигналов BPMN (signal event):
● когда концепция
готова, первый подпроцесс шлет соответствующий сигнал;
● второй процесс
до этого момента находится в ожидании сигнала; получив его, он переходит к задаче
«Разработать дизайн обложки».
Это так называемый процессный паттерн «этап»
(milestone). Аналогичный пример использования сигнала BPMN приведен в
книге Bruce Silver, «BPMN Method and Style» (стр. 98).
В чем тут подвох?
Пока мы рассматриваем написание одной книги (один
экземпляр процесса), все в порядке. Но предположим, что одновременно в работе
находится несколько книг. Вспоминаем, что сигнал BPMN - это широковещательное
сообщение, которое получают все, кто его ожидают в данный момент. Значит, как
только будет готова концепция первой книги, дизайнеры всех книг получат сигнал
о том, что можно приступать к работе над обложкой - явно не то, чего мы
ожидали.
Для того чтобы приведенная диаграмма сработала, нам
необходимо как-то ограничить распространение сигнала. Как это можно было бы
сделать?
1.
Первое, что приходит в голову - предусмотреть атрибут сигнала, который
будет ограничивать его распространение границами данного экземпляра процесса.
Но, к сожалению, такого атрибута стандарт не предусматривает. Причем если в
рамках BPMN 1.x еще можно сказать, что это вопрос реализации, то в BPMN 2.0
метамодель процесса специфицирована полностью. Смотрим страницу 281 документа
OMG, датированного июнем 2010 г.: у сигнала есть единственный атрибут - имя.
Значит, сигнал всегда будет распространятся по всем экземплярам процесса.
2.
Что ж, раз у сигнала есть только имя, то будем использовать то, что
есть. Рассматриваемая схема сработает, если мы сможем динамически, т.е. в
процессе исполнения процесса, задать его имя. Если имя сигнала будет не «Концепция
готова», а «Процесс 9999 Концепция готова», то все будет в порядке. Но
это, конечно, приемчик так себе, и рассчитывать на него сложно. Движки BPMS
позволяют что-то менять в процессе исполнения (например, задавать время
срабатывания таймера), но название - вряд ли.
Почему это важно?
В зависимости от того, можем мы или нет использовать
сигналы для координации потоков внутри одного экземпляра процесса, мы должны
ориентироваться на ту или иную процессную архитектуру:
● если
распространение сигнала можно ограничить, то можно смело использовать
подпроцессы - если возникнет необходимость их синхронизовать, это можно будет
сделать при помощи сигнала;
● если сигналы
распространяются неограниченно, то единственный вариант - запускать для каждой
ветви отдельный процесс (благо процессы можно синхронизовывать при помощи
сообщений), примерно так:
Выводы:
1.
В стандарте BPMN не хватает атрибута, ограничивающего распространение
сигнала.
2.
В отсутствии стандартного способа ограничить распространение сигнала для
реализации процессного паттерна «этап» следует использовать сообщения.