I have a rather theoretical question: if I want to depict on a diagram communication between different pools, I can use the Message Flow. But with Message Flow I’m limited to connecting events of “Message” type only.
In some cases communication can be based on signals. But BPMN2.0 doesn’t provide any graphical means to connect throwing and catching signal events located in different pools.
Is there any (conceptual) reason why BPMN does not support this?
BPMN specified the signal to be a broadcast. It can be catched up in many process diagrams and all process instances waiting for a signal event.
Messages have always a one-to-one relationship. This relationship can be expressed with message flows.
Hope this helps, Ingo
Indeed; the idea being that with messaging in BPMN, you have a specific target in mind, whereas with signals it’s meant as “to whomever it may concern”. BPMN’s notion of messaging is therefore slightly different than what is often considered messaging in technical terms, where a message contains an event that is published to potentially many consumers. Even though it’s not required to be done that way, many implementations follow that idea.
As a matter of practice, with BPMN signals, just as with messages, using a corresponding name for the events is a good indication of recipients of a specific signal, even though there is no connecting flow.
@Ingo_Richtsmeier, @tiesebarrell thank you for replies.
The unicast/broadcast nature of messages/signals seems to be reflected strictly in the BPMN2.0. Establishing a design guideline covering e.g. naming convention for signal names (and documented on diagrams using text annotations) could be in this case indeed a good practice especially for larger scale projects.