Issue 16546: BPMN 2.0 Choreography issues page 339 of dtc/2010-06-05 (bpmn2-rtf)
Source:  (, )
Nature: Uncategorized Issue
Severity: 
Summary:  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).


Resolution: 
Revised Text: 
Actions taken:
September 14, 2011: received issue
Discussion: 

End of Annotations:=====
s is issue # 16546  from <michele.mancioppi@iaas.uni-stuttgart.de


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