Issue 16551: Unclear introduction of the concept of MEP (bpmn2-rtf) Source: (, ) Nature: Clarification Severity: Significant Summary: Page 315 reports the following text on MEPs: “To leverage the familiarity of flow charting types of Process models, BPMN Choreographies also have “activities” that are ordered by Sequence Flows. These “activities” consist of one (1) or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (“Activity”) of a Choreography. Some MEPs involve a single Message (e.g., a “Customer” requests an “Order” from a “Supplier”). Other MEPs will involve two (2) Messages in a request and response format (e.g., a “Supplier” request a “Credit Rating” from a “Financial Institution,” who then returns the “Credit Rating” to the “Supplier”). There can be even more complex MEPs that involve error Messages, for example.” This wording may result confusing to practitioners for the following reasons. First of all, there is no way in BPMN 2.0 Choreographies to mark a message as an “error message”. What the specification seems to hint at is that some of the messages in the choreography may deliver information over errors. However, since BPMN 2.0 Choreographies (and, more generally, BPMN 2.0 as a whole) does not differentiate among the possible “typologies” of messages (e.g. error, acknowledgement, invocation, or response), there is no immediate way to map WSDL 1.1/2.0 MEPs to single Choreography Tasks without losing some information (e.g. the distinction between output messages and fault messages). Even using the structureRef of the message (see e.g. Page 7 of dtc/2010-06-05) to point to a WSDL 1.1/2.0 message, this would provide no information about what “type” of message it is. In fact, in WSDL 1.1/2.0 a message is “labelled” as input, output or fault only in the WSDL operations, so much that a given WSDL message could, for example, be input in one operation and a fault in another. Secondly, despite the fact that the text mentions Choreography Activities as the realization of MEPs (i.e. also Sub-choreographies), the reference to MEPs as atomic units sounds intuitively related to Choreography Tasks. Given the fact that it is not possible to (1) specify error messages and (2) specify the sequencing in a single Choreography Task of more than two messages, a single Choreography Task allows the specification of only the WSDL 1.1 “one-way messaging” and “notification” MEPs. In fact, the specification of “request/reply” and “solicit/response” MEPs is not possible because their faults cannot be represented in the same Choreography Task alongside the input and output messages. To clarify this issues, the specification should address clearly and in detail the relation between BPMN 2.0 Choreographies and MEPs in WSDL 1.1 and WSDL 2.0, in particular with relation to the granularity of the MEPs (Choreography Task-level, Sub-choreography level, etc.). Additionally, it might be beneficial to for the sake of clarity to explicitly that it is outside the scope of ChoreographyTasks to be able to map entire WSDL 2.0 Complex MEPs, but that, instead, they have to be realized by multiple choreography tasks appropriately sequenced. Resolution: Revised Text: Actions taken: September 15, 2011: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 15 Sep 2011 08:09:38 -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: 315 Title: Unclear introduction of the concept of MEP Nature: Clarification Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Page 315 reports the following text on MEPs: .To leverage the familiarity of flow charting types of Process models, BPMN Choreographies also have .activities. that are ordered by Sequence Flows. These .activities. consist of one (1) or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (.Activity.) of a Choreography. Some MEPs involve a single Message (e.g., a .Customer. requests an .Order. from a .Supplier.). Other MEPs will involve two (2) Messages in a request and response format (e.g., a .Supplier. request a .Credit Rating. from a .Financial Institution,. who then returns the .Credit Rating. to the .Supplier.). There can be even more complex MEPs that involve error Messages, for example.. This wording may result confusing to practitioners for the following reasons. First of all, there is no way in BPMN 2.0 Choreographies to mark a message as an .error message.. What the specification seems to hint at is that some of the messages in the choreography may deliver information over errors. However, since BPMN 2.0 Choreographies (and, more generally, BPMN 2.0 as a whole) does not differentiate among the possible .typologies. of messages (e.g. error, acknowledgement, invocation, or response), there is no immediate way to map WSDL 1.1/2.0 MEPs to single Choreography Tasks without losing some information (e.g. the distinction between output messages and fault messages). Even using the structureRef of the message (see e.g. Page 7 of dtc/2010-06-05) to point to a WSDL 1.1/2.0 message, this would provide no information about what .type. of message it is. In fact, in WSDL 1.1/2.0 a message is .labelled. as input, output or fault only in the WSDL operations, so much that a given WSDL message could, for example, be input in one operation and a fault in another. Secondly, despite the fact that the text mentions Choreography Activities as the realization of MEPs (i.e. also Sub-choreographies), the reference to MEPs as atomic units sounds intuitively related to Choreography Tasks. Given the fact that it is not possible to (1) specify error messages and (2) specify the sequencing in a single Choreography Task of more than two messages, a single Choreography Task allows the specification of only the WSDL 1.1 .one-way messaging. and .notification. MEPs. In fact, the specification of .request/reply. and .solicit/response. MEPs is not possible because their faults cannot be represented in the same Choreography Task alongside the input and output messages. To clarify this issues, the specification should address clearly and in detail the relation between BPMN 2.0 Choreographies and MEPs in WSDL 1.1 and WSDL 2.0, in particular with relation to the granularity of the MEPs (Choreography Task-level, Sub-choreography level, etc.). Additionally, it might be beneficial to for the sake of clarity to explicitly that it is outside the scope of ChoreographyTasks to be able to map entire WSDL 2.0 Complex MEPs, but that, instead, they have to be realized by multiple choreography tasks appropriately sequenced.