Well probably it doesn’t matter because Data Objects as defined by BPMN 2.0 can’t be used in interprocess communications anyway. E.g. at fig. 3 we need a collection of Purchase Orders created by multiple process instances to be read at once by Production process - it can’t be modelled by a Data Object because it can only represent data associated with a single process instance.

But please note that BPMN 2.0 defines data associations to be used exclusively with Data Objects and directed associations for everything else, including Data Stores I guess. The two associations use the same graphical representation - dotted arrow - meaning that even if data associations can’t cross the borders, something else looking exactly the same can.

The recomendation about using messages is irrelevant while the Data Store approach is a valid pattern for me, not a workaround.

I’ll check later in the spec. about data associations crossing pools. At the moment, here’s one citation from another reliable source:
“Data objects only exist within a process; therefore data associations cannot cross the borders of pools. Direct data exchange with other processes is modelled with message flows. In order to specify that the content of a message is processed as a data object, a catching message event can have an outgoing data association. Conversely, a throwing message event can have an incoming data association”
BPMN2.0 - Introduction to the standard for Business Process Modeling, Prof. Thomas Allweyer, page 124.

I agree with the Data Store approach. I’m currently implementing something which uses this as a workaround.

Thanks a lot for pointing this out. As you can see from other posts on this blog (e.g. http://mainthing.ru/item/332/) I’m relying heavily on data-based interprocess communications so this is very sensitive issue for me. Messaging isn’t a replacement because there are many cases when a receiving process instance just isn’t instantiated yet.

You are right that Data Object in BPMN 2.0 must belong to a process: “Data Object elements must be contained within Process or Sub-Process elements.” (p. 205). “The lifecycle of a Data Object is tied to the lifecycle of its parent Process or Sub-Process. When a Process or Sub-Process is instantiated, all Data Objects contained within it are also instantiated. When a Process or Sub-Process instance is disposed, all Data Object instances contained within it are also disposed. At this point the data within these instances are no longer available.” (p.207). So Data Object within BPMN 2.0 are similar to process attributes: they exist only as long as a process instance does.

The BPMN 2.0 Data Store is more suitable for interprocess communications: “A Data Store provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process.” (p. 208). I couldn’t find in the spec the explicit forbiddance for data associations to cross pools - could you please point it out? Besides, BPMN 2.0 distinguishes “data associations” which are used only with Data Objects and directed associations - I guess the latter should be used with Data Stores. So I hope that the diagram at fig. 3 would be BPMN 2.0 compliant if the Data Object was replaced by a Data Store. Unfortunately the spec doesn’t provide such an example but Bruces Silver in his “BPMN Method & Style” does (p. 33).

There is no Data Stores in BPMN 1.x so we use Data Objects for them, too. Luckily, BPMN 1.x is more flexible and doesn’t require a Data Object to belong to a process so the diagram at fig.3 should be valid BPMN 1.x.

Just one remark. According to BPMN2 specification, Data Objects exist only within a process. Data associations cannot cross pools and data exchange between processes is modelled with message flows only.

I assume the diagram in Fig. 3 is BPMN1.2 compliant.

У меня есть кое-какие системные предложения по этому вопросу, но надо найти время, чтобы их додумать и внятно изложить.