BPMN 2.0 FTF Avatar
  1. OMG Issue

BPMN2 — Ambiguity when multiple message flows associated with a choreography task

  • Key: BPMN2-237
  • Legacy Issue Number: 14890
  • Status: closed  
  • Source: Red Hat ( Gary Brown)
  • Summary:

    a choreography task is associated with more than two message flows, or with two message flows that are in the same direction (i.e. same sending and receiving participants), then the ordering of the message flows is ambiguous.

    If the choreography is ambiguous, and process models associated with each participant in the choreography are independently developed, it may mean that the resulting process models may not be able to interact correctly.

    There are a couple of possible solutions:

    1) Only permit a choreography task to have a max of two message flows. If two are defined, then they must be in opposite directions.

    2) If more than two message flows are defined, then an MEP (and possibly other additional supporting information) needs to be specified that makes the ordering explicit. For example, request/response/fault MEP could be specified, where only one message flow could be in one direction (i.e. the request), and all others are in the opposite direction - and the semantics would be that only one of the 'response' message flows could occur. Note: not sure whether it would be necessary to distinguish those flows as one normal response and remaining being fault responses - may be necessary to map to standard rpc pattern.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    PDF page 360:
    (a) Replace: "A single Choreography Task can be used for one (1) or more Messages. Most of the time there will be one (1) or two (2) Messages for a Choreography
    With: "A single Choreography Task can be used for one (1) or two (2) Messages, with at most one (1) Message per Participant."
    PDF page 388:
    (b) Change schema for tChoreographyTask "<xsd:element name="messageFlowRef" type="xsd:QName" minOccurs="1" maxOccurs="unbounded"/>" so that
    maxOccurs is 2.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT