In BPMN, two possible models for choreography are as follows:
Invisible hub:
Although choreography is fundamentally decentralized, we imagine there
is a central hub through which all messages pass, and model the
choreography as the process of that hub.
Sum of parts:
The public process of each participant (that is, the process containing
steps required by the choreography, with private steps omitted) is
drawn in a swim lane. Message flow (dashed lines) is used to show
inter-participant communication.
A sum-of-parts model for the enrollment choreography is shown in next figure.
There are three swim lanes in the diagram: one for the distributor (referred to as Distributor), one for the initiating retailer (referred to as Retailer), and one for the current retailer (referred to as CurrentRetailer).
Each lane contains the public process of the participant. The dashed
arrows show the flow of messages between participants. The enrollment
choreography is, according to this approach, the combination of the
public processes of each participant plus the message flow that connects
them.
The choreography begins when the customer enrolls with the retailer (Cust Enrolls in the Retailer lane). The retailer then submits the enrollment request to the distributor by calling Dist.enroll. This call sends a message to the distributor, which triggers the event Enroll (the first step in the Distributor lane). The Distributor
process is now underway, and it responds to the enrollment request
either by rejecting the request, accepting it, or notifying the
initiating retailer and the current retailer of a pending switch. The
distributor rejects by calling Ret.reject, and, as the dashed line signifies, triggers the event Dist.reject in the retailer. The remaining steps are straightforward.
The
sum-of-parts method is intuitive, and variations on it can be found in
business process literature (in the WSCI and BPMN specifications, for
example). Sum-of-parts, however, has two disadvantages. First, the
message flow creates an indecipherable clutter, making complex
choreographies almost impossible to read; the swim lanes, for their
part, use a lot of real estate. Aesthetics aside, sum-of-parts fails to
present a global, consolidated view of the choreography. We grow
bug-eyed trying to keep track of what each participant is doing. We are
forced to watch each dancer rather than the group as a whole.
The invisible-hub
representation is comparatively compact. The next figure, which shows
the enrollment choreography as a hub, has fewer steps than the
sum-of-parts equivalent, and it makes do without lanes or dashed lines.
The hub works as
you would expect a hub to work: it listens for inbound events and routes
them to their intended recipients. The act of receiving an event and
sending it elsewhere is a single unit of work (shown in the figure as a
rounded box with a dashed line), known as an interaction. The hub choreography represents the communication of its participants as a process of interactions.
Before walking through this process, consider the following notational conventions:
The event with a thin border (Ret.enroll(Dist)) is the process' start event. Events with a double-line border (for example, Dist.reject(Ret))
are intermediate events, which occur over the course of the process.
Intermediate events can be used in three ways: for cancellation, for
deferred choice, or simply to wait for the next message before
continuing. The enrollment hub has examples of the latter two forms.
We'll come back to cancellation while discussing the email transfer hub.
Deferred
choice, also known as an event pick, uses a diamond containing an
inscribed star (known as an event-based gateway) with arrows leading to a
set of intermediate events. The intent is to wait for one of those
events to occur, execute its activities, and discard the remaining
events. There are three deferred choices in the enrollment hub. The
first occurs in three steps, and selects one of the three events: Dis.reject(Ret), Dist.accept(ret), or Dist.pendingSwitch(Ret, CurrRet). If, say, Dist.reject(Ret) occurs first, the activity Ret1.reject(Dist) is executed.
The intermediate event Dist.switchCompleteCurrent (Ret, CurrRet) simply waits for something to happen before continuing. This event is sandwiched between the activities Dist.cancel(Ret) and Ret.switchCompleteCurrent, CurrRet.switchCompleteCurrent (Dist).
Thus, when the first activity completes, that branch of the process
waits for the event to occur before continuing with the second activity.
Events have labels of the form Sender.msg (Recipients),
meaning that the event received by the hub is a message from the sender
bound for the specified recipients. (There must be at least one.) Thus, Dist.switchCompleteCurrent(Ret, CurrRet) is the message switchCompleteCurrent from the distributor (Dist) to both the initiating retailer (Ret) and the current retailer (CurrRet).
Send tasks (rounded boxes with a straight border) are labeled Recipient.msg(Sender),
meaning that hub is sending the specified message to the recipient and
is indicating that the message originated with the specified sender. In Dist.enroll(Ret), for instance, the hub sends the message enroll to the distributor (Dist), and is indicating to the distributor that this message came from the retailer (Ret).
If
the event that preceded it specifies multiple recipients, the send task
sends the message to each recipient. Each send counts as one
interaction. Ret.pendingSwitch, CurrRet.pendingSwitch (Dist), for example, sends the message pendingSwitch to both the retailer (Ret) and the current retailer (CurrRet), and thus spans two interactions.
A rounded box with a dashed border, known in BPMN as a group, pairs up an event and a send task. Thus, the grouping of Ret.enroll(Dist) and Dist.enroll(Ret) means that when the hub receives the message enroll
from the retailer bound for the distributor, it sends that message to
the distributor, indicating to the distributor that the message
originated with the retailer.
A
group that contains multiple interactions has a label in the top-center
of the dashed box indicating the number of interactions. The number of
interactions is equal to the number of recipients.
The enrollment hub diagram reads as follows:
The
choreography begins with the interaction in which the retailer sends an
enrollment request to the distributor. For convenience, this
interaction is labeled a in the figure.
Exactly one of three interactions can happen next: the distributor sends a rejection to the retailer (b); the distributor sends an acceptance to the retailer (c); or the distributor sends a notice of pending switch to both the initiating and current retailers (d). Exactly one of two interactions can follow acceptance: the retailer sends a cancellation to the distributor e, or the distributor sends a completion event to the retailer (f).
In
the pending switch case, one of the two interactions follows the notice
of pending switch: the initiating retailer sends a cancellation to the
distributor (g);
or the distributor sends a switch completion event to both the
initiating and current retailers indicating that the current retailer
won (h). If
the switch is cancelled, the distributor sends a switch completion
event to both retailers indicating that the initiating retailer won (i).
The
choreography has 12 interactions assembled in a process flow. (There are
nine groups, but three of them have two interactions each.) Reading the
diagram means spotting the 12 interactions and traversing the control
flow that connects them.
The email transfer choreography hub, shown in the next figure, is somewhat more complex.
The email transfer hub reads as follows:
The choreography begins when the sender submits the transfer request to the sender bank (a). The sender bank can reject the request (b), or accept it (c). The acceptance event in c is routed to both the sender and the recipient, and thus results in two interactions.
The
remainder of the hub process is a loop that continues until the
transfer is completed. The loop is modeled as a BPMN embedded
sub-process labeled Loop. The arched
arrow pointing counter-clockwise in the bottom-center of the sub-process
box denotes that this sub-process is iterative.
In the first step of the loop, the recipient requests her bank to transfer the funds into her account (d). The recipient's bank either rejects (e) or accepts (f)
the request. In the rejection case, the recipient's bank sends a
rejection notice to the recipient. In the next iteration of the loop,
the recipient can try again. In
the acceptance case, the recipient's bank sends a transfer request to
the sender's bank. The sender's bank can either accept (g) or reject (h) the request. In the acceptance case, the sender's bank sends a transferOK message to both the recipient's bank and the sender. The recipient's bank then notifies the recipient (i), and the choreography completes. (The Set Done task sets the loop's continuation condition to false, which causes the loop to exit and the hub process to complete.)
In the rejection case, the sender's bank sends a rejectTransfer message to the recipient's bank, and the recipient's bank notifies the recipient of this (j). In the next iteration of the loop, the recipient can try again.
While the loop is executing, any of the parties may cancel the request (k). The label in the event *.cancel (SenderBank) informs the hub to listen for a cancel message from any party-the * works as a wildcard-and to route that message to the sender's bank. The sender's bank, in turn, sends an abort message (l)
to the sender, the recipient, and the recipient's bank (the bank into
which the recipient is currently requesting the transfer). Interaction (k)
is an example of a cancellation intermediate event; it terminates the
loop and transition into a series of cancellation activities.
Choreographies
are not executable, as we discussed previously. A choreography is a
protocol, a set of traffic laws. It is, emphatically, not a central hub through which all participant interactions flow. Our hub model is merely a specification
of how the individual participants should communicate. There are
countless senders, recipients, and banks in the world of email transfer,
but there is no hub that helps them talk to each other. The invisible
hub for email transfer is merely a model; it is every bit as
hypothetical as the invisible hand of Adam Smith's free-market economy.
The economy is self-powered, and does not require the intervention of a
hand; email transfer goes on without a hub.
Still,
the BPMN hub model is more than an informative picture. As we'll see,
it maps easily to WS-CDL, and it serves as the basis for the generation
of participant stubs and a choreography 'protocol' tester.
|
