Issue 9363: shared collaboration (bpmn-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: This was submitted to BPMN members in addition to the OASIS ebBP list 13-14 February 2006. This is sent in an abbreviated fashion to FTF for comment inclusion. Diagram examples: http://www.oasis-open.org/committees/download.php/16684/ebxmlbp-v2.0.2-Document-pr-BPMN-r02-en.zip As a subsequent followup between BPMN and ebBP (discussions 7 and 9 February 2006), our team has begun to delve deeper into using (future) joint activity, associate the operation activities to business transaction activities, show the use of business signals and business signal exceptions (such as Negative Receipt Acknowledgement) and understand what questions remain. Initial thoughts of potential needs (current or future) for BPMN that may be relevant for shared collaboration [1]: 1. Visibility of the BT pattern and its constraints and guidelines 2. Business QoS aspects (guidance that may translate to technical mechanisms in the messaging infrastructure) 3. More detailed modeling of the business document (this may be part of properties). This may be too granular for BPMN however. 4. Need for end timers * Timers are not just for exceptions but may be for receipt of a business signal (Receipt or Acceptance Ack), and for the overall collaboration, activity, etc. 5. Need to be able to model simply multiple internal processes to support different operations, or the same operation using different mechanisms. 6. How to effectively show how a business partner may assume many roles in a pool. * For example, a Supplier (exposed in Business Collaboration) may assume the roles of Buyer, Distributor or Seller. These roles may be specific to the activities within a joint activity or be associated with the activities defined elsewhere but visible in a Complex Business Transaction Activity. Visibility and participation in this activity are different but may be associated. 7. Last year we spoke to some of your team members about the use of inclusive OR gateway, and intermediate or end messages for representing that a response could be several different types of responses (cancel, change, accept for example). The current BPMN semantics preclude use of message flows into / out of a gateway. In addition, we couldn't determine how to indicate that multiple types of business messages (specifically) may occur. We originally used exclusive rather than an inclusive OR gateway notation object (per BPMN suggestion in September). With inclusive OR, parallelism could result. For example, in a decision, it is modeled that one path is taken. In order to represent the sequence flow into a gateway, and several possible paths out (termed end messages in BPMN), I opted to use the inclusive OR gateway as suggested. In ebBP, forks can be non-deterministic intentionally. Forks can resemble a non-deterministic OR or parallel ANDs or exclusive OR (like a Decision). This question arose outside of the option to use a future joint activity. What gateway control type is appropriate when you actually could have -n- potential paths on a fork or join, and either only one is actually performed or many could be performed, and business messages are sent? This is actually a conceptual difference in current BPMN v1.0 and collaboration whereby not all paths may be rendered executable or be used in execution (monitorable in ebBP context). Resolution: Revised Text: Actions taken: February 14, 2006: received issue Discussion: Discussion: The FTF agrees that there is a problem that needs fixing or addressing, but considers the resolution to be too complex for a FTF and defers its resolution to future work on BPMN. Disposition: Deferred End of Annotations:===== te: Tue, 14 Feb 2006 17:58:33 -0800 From: Monica J Martin Subject: ebbp-bpmn 2/14/2006: BPMN FTF Comment To: bpmn-ftf@omg.org Cc: Stephen A White , Dale Moberg X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 This was submitted to BPMN members in addition to the OASIS ebBP list 13-14 February 2006. This is sent in an abbreviated fashion to FTF for comment inclusion. Diagram examples: http://www.oasis-open.org/committees/download.php/16684/ebxmlbp-v2.0.2-Document-pr-BPMN-r02-en.zip As a subsequent followup between BPMN and ebBP (discussions 7 and 9 February 2006), our team has begun to delve deeper into using (future) joint activity, associate the operation activities to business transaction activities, show the use of business signals and business signal exceptions (such as Negative Receipt Acknowledgement) and understand what questions remain. Initial thoughts of potential needs (current or future) for BPMN that may be relevant for shared collaboration [1]: 1. Visibility of the BT pattern and its constraints and guidelines 2. Business QoS aspects (guidance that may translate to technical mechanisms in the messaging infrastructure) 3. More detailed modeling of the business document (this may be part of properties). This may be too granular for BPMN however. 4. Need for end timers * Timers are not just for exceptions but may be for receipt of a business signal (Receipt or Acceptance Ack), and for the overall collaboration, activity, etc. 5. Need to be able to model simply multiple internal processes to support different operations, or the same operation using different mechanisms. 6. How to effectively show how a business partner may assume many roles in a pool. * For example, a Supplier (exposed in Business Collaboration) may assume the roles of Buyer, Distributor or Seller. These roles may be specific to the activities within a joint activity or be associated with the activities defined elsewhere but visible in a Complex Business Transaction Activity. Visibility and participation in this activity are different but may be associated. 7. Last year we spoke to some of your team members about the use of inclusive OR gateway, and intermediate or end messages for representing that a response could be several different types of responses (cancel, change, accept for example). The current BPMN semantics preclude use of message flows into / out of a gateway. In addition, we couldn't determine how to indicate that multiple types of business messages (specifically) may occur. We originally used exclusive rather than an inclusive OR gateway notation object (per BPMN suggestion in September). With inclusive OR, parallelism could result. For example, in a decision, it is modeled that one path is taken. In order to represent the sequence flow into a gateway, and several possible paths out (termed end messages in BPMN), I opted to use the inclusive OR gateway as suggested. In ebBP, forks can be non-deterministic intentionally. Forks can resemble a non-deterministic OR or parallel ANDs or exclusive OR (like a Decision). This question arose outside of the option to use a future joint activity. What gateway control type is appropriate when you actually could have -n- potential paths on a fork or join, and either only one is actually performed or many could be performed, and business messages are sent? This is actually a conceptual difference in current BPMN v1.0 and collaboration whereby not all paths may be rendered executable or be used in execution (monitorable in ebBP context). The ebBP team Dale Moberg, co-chairs Monica J. Martin Note: Dale Moberg is currently at the meeting in Tampa. [1] Some of these may be outside of the scope of the BPMN FTF and considered in any future version of the notation and/or other inclusive effort. To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9363 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Thu, 11 May 2006 18:00:28 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 05/11/2006 19:00:30, Serialize complete at 05/11/2006 19:00:30 The resolution and related information about this Issue can be found here: http://www.bpmn.org/FTF/Issues/Issue%209363.htm If you have any comments, questions, suggested revisions about the current resolution, or an alternative resolution, then reply to this message or speak up at a group meeting. Thanks.