BPMN21 — BPMN 2.0 Choreography issues page 339 of dtc/2010-06-05

N.B. In the reminder /dtc/2010-06-05 /is the BPMN 2.0 specification.

------ ISSUE START ------
Page 339 of /dtc/2010-06-05/ reads as follows:

“There are situations when a Participant for a Choreography Task is
actually a multi-instance Participant. A multi-instance 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 multi-instance 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.”

First of all, the above wordings are 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 could not find in the /dtc/2010-06-05/any wording that clarifies
which of the two possible meanings is the correct one. 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 raises several serious issues:

• Multi-instance recipient participants in a choreography task
  violate the assumption that each choreography task involves
  exactlytwo 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?

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)?

It is our opinion that multi-instance participantsis a complicated
construct to deal with in Choreographies, and should be thoroughly
re-considered (possibly leading to its elimination from the
specification).