Issue 16553: Underspecification of Multi-instance participants in Choreographies (bpmn2-rtf) Source: (, ) Nature: Clarification Severity: Significant Summary: 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)? Resolution: Revised Text: Actions taken: September 15, 2011: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Sep 2011 09:43:32 -0400 To: issues@omg.org, bpmn2-rtf@omg.org From: Juergen Boldt Subject: issue 16553 -- BPMN 2 RTF issue From: webmaster@omg.org Date: 15 Sep 2011 08:30:05 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Michele Mancioppi Employer: IAAS, University of Stuttgart mailFrom: michele.mancioppi@iaas.uni-stuttgart.de Terms_Agreement: I agree Specification: Business Process Model and Notation (BPMN) Section: 11 FormalNumber: formal/2011-01-03 Version: 2.0 Doc_Year: 2011 Doc_Month: January Doc_Day: 03 Page: 327 Title: Underspecification of Multi-instance participants in Choreographies Nature: Clarification Severity: Significant CODE: 3TMw8 B1: Report Issue Description: 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)? Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org