BPMN: What is a Message?

[in a collaboration]”.  As explained last time, “Participants” here means the process on one end and some entity external to the process on the other end.  The message is just the content of the communication, i.e. the information communicated.  The communication itself is a message flow, a dashed connector in the diagram.  In non-executable models, the message flow label is generally taken as the name of the message, a noun.  In executable models, a message icon can be attached to the message flow for purposes of binding the message flow element to a message element in the semantic model, which in turn references an item definition linked to a data structure defining the message content.  Some people use the message icon even in non-executable models, but unless they are referencing some defined data structure there is really no point to it.

You won’t be surprised to learn, however, that there is more to it than that.  Just as a process is not just any sequence of activities that performs work, a message is not just any communication between participants in a collaboration.  In particular, it means different things in executable vs non-executable models.  In executable BPMN, a message is really a system-to-system message related to a service operation, as used in WSDL.  BPMN goes to great pains to stress that “service” does not just mean a SOAP-based web service, but it still means something very much like one.  It still has a set of operations with interfaces defined by input and output messages, for example.  Thus, in executable BPMN, an email is not a message, nor is a fax, letter, or phone call.

In non-executable BPMN, however, human communications between participants is the norm.  How else you would explain things like the diagram above, Figure 7.3 in the spec?  I suppose you could argue that these message flows are “abstract” and don’t strictly represent messages.  But the spec never says that, and it’s more reasonable to say that in a non-executable BPMN the term message means something more general than a communication bound to a service operation input or output.  These message flows seem more like phone calls or emails.

So let’s stick with non-executable BPMN.  You might think that the way an external actor – the Customer, for instance – passes information to the process, or the way one process passes information to another one, is always via some form of message.  The spec pretty much says that.  But it’s not the only way.  In fact, I think it’s not even the most common way.

What does “receiving” a message mean in BPMN?  It depends on the element doing the receiving, the one the message flow arrow points to, such as a Message event.  A Message start event means create a new instance when the message arrives.  A catching Message intermediate event or Receive task means resume a paused flow as soon as the message arrives.  A Message boundary event means initiate some handler action immediately when the message arrives.  A Message event or Receive task is really a flow control object that reacts to an incoming message.  Two things about it are significant: the reaction is immediate and it is unconditional. Receiving a message, then taking time to think about it and decide to maybe act on it or not… that’s not what a Message event or Receive task does.

However, a message flow to a User task or a generic task, as in the diagram above, could conceivably be handled in that way.  But even there, the process is reacting to information pushed to it.  I believe in the real world it is more common for a process activity to pull information from a storage location when it needs it.  BPMN has a way to do that, too, but it doesn’t use a message.  Instead it uses a data store, a global element accessible to both participants.  The external entity or process writes information to the data store, and the process activity – when it needs to do so – queries and retrieves the information from the data store.  This, for instance, is how ordering a song on iTunes works.  You don’t pass your credit card info in the order.  iTunes’ order handling app pulls it from your profile, the data store.  As the customer, you update your profile when you need to, and iTunes processes query it when when they need to.  If you look at the processes in your own organization, I suspect you will find that most of them talk to each other via this shared data mechanism rather than via messages.

The BPMN spec completely ignores this form of integration, however.  In fact, it makes it extra hard to correctly translate it from the diagram to the semantic model.  In the diagram, the connection to a data store is not a message flow – since data store is not allowed to send or receive messages – but a dotted line connector called a data association.  A data association into the data store means a write operation and out of the data store means a read.  For reasons too obscure to contemplate, the data association shape in the diagram does not directly reference the global data store element but a data store reference element within the process.  But if Process 1 is integrating with Process 2 via a data store, which process is that?  Actually, the single data store shape is bound to two different data store reference elements, one inside each process, and both of which point to the same data store global.

What if it’s just the Customer – a black box pool – interacting via a data store, the iTunes example?  Here’s a nasty surprise:  You cannot connect a data association to a black-box pool.  It is not allowed by the BPMN metamodel and schema.  Fortunately, the regular association element looks the same, and you can attach those anywhere.  In this case there would be only one data store reference, with an incoming association and an outgoing data association.  What a mess.

Somebody’s bound to bring up signal, another message-like thing that’s different from a message.  That’s true, but signal has its own problems, and I’ll talk about that another time.