BPMN11 — shared collaboration

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

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred