BPMN2 — CorrelationSubscription - Description & use-cases

The Correlation Subscription concepts in the spec are difficult to follow and understand.

We need improved explanations in the spec, with descriptions of when and how someone would use this, and the motivations behind it.

Comments:
From: wstephe created: Fri, 24 Jul 2009 13:05:02 -0500 (CDT)
Yes, Section 8.3.3 (V0.9.14) needs a complete overhaul.

1. Add the following introductory paragraph motivating the need for correlation:
Business processes typically may run for days or even months, requiring asynchronous communication via messages. Also, many instances of a particular business
process will typically run in parallel, e.g., many instances of an order process, each representing a particular order. Correlation is used to associate a particular
message to an ongoing conversation between too particular business process instances. BPMN allows using existing message data for correlation purposes, e.g., for
the order process, a particular instance can be identified by means of its order ID and/or customer ID, rather than requiring the introduction of technical correlation
data.
2. Add a footnote to the next paragraph clarifying that it also refers to message events – here is the original paragraph with the suggested footnote in *** ***:
The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task***All references to Send or Receive Tasks in this section also
include message catch or throw events – they behave identically with respect to correlation*** in a
Conversation, a mechanism BPMN refers to as instance routing. It is a particular useful concept where there is no
infrastructure support for instance routing. Note that this association can be viewed at multiple levels, namely the
Conversation, Choreography, and Process level. However, the actual correlation happens during runtime (e.g., at
the Process level). Correlations describe a set of predicates on a Message (generally on the application payload) that
need to be satisfied in order for that Message to be associated to a distinct Send Task or Receive Task. By the same
token, each Send Task and each Receive Task participates in one or many Conversations. Furthermore, it identifies
the Message it sends or receives and thereby establishes the relationship to one (or many) CorrelationKeys.
Disposition: Resolved