In my recent post about what is a message, I omitted one important aspect: the addressee. Unlike its close cousin signal, a message definitely has one! But once again, the BPMN spec does not explain what the addressee of a message means. The closest it gets is to say that the target of a message flow may only be an activity, Message event, or participant (black-box pool). But this utterly fails to explain exactly who or what is the intended recipient of the message. Here is how I make sense of it.
Recall that regardless of how it is used in practice, BPMN’s conceptual foundations derive from a paradigm of service orchestration. In that context, I believe BPMN’s founding fathers had in mind a message queue as the addressee of a message, i.e., an address monitored by a specified entity that handles any messages received. That distinguishes it from a topic, an address monitored by any number of subscribers, entities not necessarily known to the sender. The Signal event was added in BPMN 1.1 specifically to handle this sort of broadcast, or publish-subscribe, integration. But the terms queue and topic are never mentioned in the BPMN spec.
A Message event with incoming message flow represents a particular handler for the message. But the sender of the message isn’t always trying to send to a particular handler. It really depends on the type of Message event.
A Message start event always means the same handler action: create a new instance of a process whenever the message arrives. Implicitly, the addressee of such a message is a specific process definition, the defined handler for that message.
But that is not the case with a Message intermediate event (including boundary event) or Message event subprocess. Here the message is really addressed to a specific process instance. When a process receives an order cancellation, it does not mean cancel all orders in flight, just a particular one. Messages to intermediate events always imply some form of correlation – identification of the addressed instance. For some inexplicable reason, BPMN 2.0 moves correlation out of process and collaboration models and defines it only in terms of conversation models, a BPMN backwater that nobody uses and hardly anyone knows exists. Nevertheless, some kind of correlation is absolutely required with messages to intermediate events. The addressee is a specific process instance, and the handler is the flow out of the Message event (or within the event subprocess).
Here, however, the sender isn’t really addressing a particular handler. How the process will handle an order update or cancellation may be different at different points in the process. The sender of the order cancellation message does not know the state of the instance when the message is sent, which in turn determines how that message will be handled. Thus a single order cancellation message may be represented by more than one message flow in the diagram, each drawn to a different intermediate or boundary event representing a different handler for the message. That implies that there is more than one handler entity monitoring the same message queue.
When a single incoming message equates to multiple message flows from a black-box pool, there is no problem. You just draw the message flow multiple times. But what if the sender is an explicit message node, such as a Message end event in another process? Are you allowed to draw more than one message flow from that end event, one to each boundary event in the target process? It’s only one physical message, but whether this is allowed or not by the BPMN metamodel is unclear. I believe most BPMN tools would flag this as an error.
When a message flow is received by a User task, the handler action is generally invisible to the process model. In fact, BPMN does not require the task to wait for the message before completing, or specify any difference in behavior whether or not the message is received. I would say that the addressee of such a message is not well-defined, but others might disagree. In most cases, it probably works like an intermediate event or Receive task, i.e., addressed to a specific process instance.
A message flow may also be addressed to a black-box pool, representing an abstract entity, either a participant role (such as Customer) or an organization. In that case, the addressee is simply that role or entity, not a specific process or process instance of that entity.
So, to recap, a message must have an addressee, but the meaning of the addressee depends on the target of the message flow:
- Message start event, message is addressed to a process (definition)
- Message intermediate event, boundary event, event subprocess, or Receive task, message is addressed to a specific process instance
- User task, message addressee is not well-defined, but usually a specific process instance
- Black-box pool, message is addressed to an abstract entity, not a process
Before we leave, one last bit about Signal events. The example of loosely-coupled publish-subscribe integration mentioned at the top is not the only behavior BPMN defines for a signal. That really applies to Signal start events, and some BPM Suites like Oracle take good advantage of it. Sadly, BPMN 2.0 overloads signal with an additional, completely different behavior, which is effectively the same as message, i.e. addressed to a specific process instance, except that the sender and receiver may be in the same process. That makes no sense at all. Why didn’t they make a separate event type for the new behavior, or just enlarge Message event to allow for it? Fortunately, it’s not used often, so we just shut our eyes.
Bruce
Thank you for continuing the process and message stories. These concepts are both critical and most confusing for BPMN beginners.
Yet I can’t fully accept that BPMN message was introduced with message queue in mind. Not all engines implement it this way, to say the least, and there is no such indication in the spec. Hence I believe it’s safer to model “send-store-retrieve” scenarios explicitly via data flows and data stores and reserve messages to true “call-response scenarios” – phone call instead of mailbox metaphor. (We used to discuss it some time ago.)
What’s new for me in this post is the last statement regarding signal addressing a specific instance in BPMN2. Could you point out where the spec says this, please? I studied it through plenty of times but can’t recall this.
Kind regards
Anatoly
Anatoly,
My interpretation of message to mean “queue” is specific to its distinction from signal, which means pub-sub “topic”. But signal event is overloaded. The pub-sub usage really applies to Signal start events. Signal also may be used as an intra-process message, e.g. to cancel an activity on a parallel path. Such a use cannot be loosely coupled. It must be addressed to a specific instance of a specific process. I agree the spec does not explicitly say this, but how else could it work? Signal event is a bit of a mess. It should be split into 2 different elements. Will that happen? No.
Bruce
Here is the alternative universe:
1. There is no message queue in BPMN – the message receive shall precede message send just like with any other event type: catcher shall become active before initiator. If the event was triggered before catcher became active then the latter will wait untill it happened again.
2. Model queue-like communications explicitly with a data store and tasks.
3. Avoid intermediate signal catch event completely – any time you may need it, use message send task in multi-instance loop.
4. Use signal start event to build a loosely coupled system – e.g. to define event initiator without defining the catching process (impossible with message).
5. Use conditional event to synchronize parallel paths within a single process (semaphor-like communication).
I believe all scenarios are covered here strictly within the spec without extra assumptions about message queue and signal propagation limits.
Unfortunately conditional events aren’t supported by BPMSs that I know but it can be always workarounded by exclusive gateway plus timer.