A short addendum to previous post “A Case For BPMN Signal Event“.
The pecularity of the signal event noted there - a signal is catched by every instance of a receiver process which is waiting for the event at the moment the signal is thrown - refers to intermediate events.
In case of start event one process initiates a signal and another process starts as a result. But why using a signal here - a message seemingly can do the same?
Firstly, a signal allows to initiate several processes at once.
Secondly, a signal has conceptual advantage:
- Let a given signal thrown by a process A initiate start of a process B.
- Now let’s recall that BPM is a management of business processes that change in time and assume that we decided to make process C handle the signal instead of B.
- When a message is used, the receiver is specified in process A, hence we need to modify A scheme in order to change the handler. And if we do we got a problem with A instances already running.
- When a signal is used, we simply install C and uninstall B. We don’t need to modify A nor to do anything with A instances.
This way signal implements late binding: a handler can be set/reset at time of execution rather than development.
It allows the ultimate “late binding” of not having to design the world process … only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise … Signal … then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.
Yes, I know that the end-end process is sacrosanct but the real world is better with some compartmentalising … a bit like the IT world of programming.
Dave
Regarding end-to-end processes: it’d be too simple if they could be implemented by a single-threaded diagram. It’s an extremly vulgar view.
I’m going to get back to this topic because for me it’s the coolest thing in BPM and BPMN.
Anatoly
Interesting writeup. This is, incidentally, how one BPM product always treated events (since 2004/5) - e.g. late binding of them to process starts and Intermediate messages across any number of instances. Its a very useful abstraction.