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.