Bruce once again writes about a specific element of BPMN.? While others write about more abstract concepts and leave the implications up to the reader to decide on, Bruce continues to write practical treatises on applying BPMN and good modeling practices.
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.
Each time I read one of these posts I find myself comparing the spec to how specific products handle the same issues. For example, Lombardi and IBM have for years allowed for ?message? and ?signal? events, but the message flows simply aren?t captured in the modeling environment. It is a bit of magic to hand off the message to the engine and then assume there will be someone on the other side catching it (or multiple someones as the case may be). From an implementation perspective, it works fine ? all the representational / implementation power is there. But from an understanding perspective there?s still a lot that people have to understand without seeing (which is a drawback).? On the other hand, there are limitations to what can be drawn when you consider an observer pattern, that are relaxed in an environment where message flows don't have to be explicitly drawn.
From working with other tools, there are similar (but different) blind spots in each.