BPMN21 — Underspecification of Multi-instance participants in Choreographies

Page 327 reports the following text on multi-inistance participants:

"There are situations when a Participant for a Choreography Task is actually a multi-instance Participant. A multiinstance
Participant represents a situation where there are more than one possible related Participants (PartnerRoles/
PartnerEntities) that might be involved in the Choreography. For example, in a Choreography that involves
the shipping of a product, there can be more than one type of shipper used, depending on the destination."

Page 344 of dtc/2010-06-05 reads almost verbatim, but referring to multi-instance participants in Sub-choreographies:

“There are situations when a Participant for a Sub-Choreography is actually a multi-instance Participant. A multiinstance
Participant represents a situation where there are more than one possible related Participants (PartnerRoles/
PartnerEntities) that can be involved in the Choreography. For example, in a Choreography that involves the
shipping of a product, there can be more than one type of shipper used, depending on the destination.”

The above wordings seem unclear with respect to which of the following two cases applies at run-time with multi-instance participants:
1) Exactly one partner entity (as defined on Page 117 of dtc/2010-06-05) out of many possible ones during the enactment of the choreography.
2) One or more partner entities partake the choreography enactment.

We assume (2) for consistency with the Orchestration part of the specification. However, having a multi-instance participant resolve to multiple partner entities during the enactment of the choreography raises several serious issues:

• Multi-instance recipient participants in a choreography task violate the assumption that each choreography task involves exactly two partner entities, which is a fundamental assumption for the specification of Message Exchange Patterns (MEPs) in Choreography Tasks.
• Similarly to the previous case: how to deal with Choreography Task senders that are multi-instance participants? How many initiating messages are actually sent?
• Assuming both the sender and recipient of a ChoreographyTask to be multi-instance, how many message exchanges actually take place? All the possible permutations?

Even more complicated issues arise from multi-instance participants in terms of the enforceability of choreographies. For example, if the partner entities that resolve a given multi-instance participant are decided at enactment time, how are the other partner entities supposed to know (and therefore be able to deliver messages to them)?