Hi there
I am working now since years with BPMN. The enterprise I worked at was one of the first enterprises in Switzerland to use BPMN as process standard. So since the standard was still not in a final state, we defined our own standard within BPMN. We never understood what the message flow is good for and why there must be such strict restrictions when communicating across pools and not when communicating across lanes. For example, I understand that communication across pools is only possible via message, that's clear. But communication across lanes mostly as well, isn't it?
Following use case: Customer calls Call Center and requests a statement copy. Call Center logs ticket and back office prints the statement copy out and sends it to the customer.
So we have two pools, "external" and "enterprise xy", which holds two lanes, "Call Center" and "back office". Now why would you want to differentiate (in terms of rules and design of the connector) between the communication between customer and Call Center and Call Center and back office?
Am very thankful for any explanation.
Why more restrictive rules between pools than between lanes?
Pools often represent different organizations. As a result formal contracts how to communicate are quite often required. I often had the situation these contracts have to be signed by all participants including myself as author. I also found the restrictions forced by BPMN make me preparing these contracts early.
About messages
The term message abstracts all means to pass information. The term "message" is just a metaphor not an implementation. A message could be implemented i.e. as XML-document, EDIFACT-message, a database dataset or even as arguments passed to a subroutine (method, function, ...).
In my point of view message is a very good abstraction. So far that abstraction did not impose any limitations to my work.
Why only messages?
Simply because it is the minimal, sufficient solution. Adding other means of passing information would make BPMN more complex.
And if you need to specify the implementation details of a message, add a comment. If this is not sufficient use UML (SysML, MARTE, SDL, Esterel, LOTOS) or any other more appropriate notation or a message description (XML Schema, EDIFACT MIG, DDL, ...) to complement your BPMN models.