Anatoly on Signal Events
- December 2, 2010
- 0 Comments
If you don’t know much about Signal events in BPMN2, read Anatoly’s blog post on the subject:
In order to make the diagram work we must limit the signal propagation somehow. How it can be done?
- The first thing that comes into my mind is an attribute that would limit signal broadcasting by the current process instance boundaries. Yet there is no such attribute in the standard. Under BPMN 1.x one may say that it’s implementation issue not covered by the standard. But BPMN 2.0 fully specify the process metamodel. Let’s look at page 281 of OMG document dated June 2010: signal has a single attribute – its name. Therefore, a signal will be transmitted to all process instances.
- If the signal has only name then let’s use what we have. The diagram above may work if we could change signal name dynamically i.e. during the process execution. If we could name the signal “Process 999 Concept Ready” instead of “Concept Ready” then everything will be fine. But it’s a dirty hack and it’s hard to count on it. BPMS engines allow to change certain things during the execution (e.g. timer settings) but unlikely the name.
As Anatoly points out, the signaling examples given in several highly regarded books are fine, but when you think about how to make them work for the n>1 case, the logic breaks down.
It turns out that Lombardi’s BPM product (Now IBM’s Websphere Lombardi Edition) does not distinguish between Message flow and Signal events (the distinction between the two has only artificial merit). All events include an information payload (which can be arbitrarily simple or complex). The receivers control what they listen to by identifying a correlation key. The correlation key has to be something in the information payload, and as you can imagine, often one element of the payload is specifically designed to be the correlation key for listeners.
So sometimes implementations get the design right in a way that the spec-writers don’t – because of what I would call over-design. Let’s face it, writing specifications like BPMN2 goes against the principle of lean development (producing the minimum viable set of features).
So I find it interesting to see some of the challenges Anatoly has faced by facing in some cases a more pure representation of the BPMN 2 specification.