Process choreographies

Prof. Dr. Koen Vanhoof

Choreographies

• Interconnection or full model - Redundancy leading to

potential incompatible behaviour - Complex and/or clumsy - No ordering• Interaction model• Hub model

Motivating exampleHigh level view

Motivating examplestructural view

Interconnected model

Interaction model

Choreographies

• Interconnection or full model - Redundancy leading to

potential incompatible behaviour - Complex and/or clumsy - No ordering• Interaction model• Hub model

Send pattern

Receive pattern

Send/receive pattern

Racing incoming messages pattern

One-to-many send pattern

One-from-many receive pattern

One-to-many send/receive

Multi-response pattern

Contingent request pattern

Atomic multicast notification pattern

Request with referral pattern

Relayed request pattern

Choreographies

• Interconnection or full model - Redundancy leading to

potential incompatible behaviour - Complex and/or clumsy - No ordering• Interaction model• Hub model

Potential incompatible behaviou

Solution Interaction model

Interaction model

Interaction model

Exercise: travel agency

Exercise : Energy market• In the energy market for a state or small country there are three parties: customers (who use

electricity to power their homes), retailers (who sell electricity to customers), and the distributor (who supplies the electricity). Before deregulation, the distributor sold electricity directly to customers; there were no retailers back then. Deregulation introduced competition and broke up the distributor's monopoly. Customers can now buy electricity from one of many competing retailers. The distributor is now merely a supplier, having moved out of the retail sales business. When a customer enrolls with a retailer, the retailer uses the following protocol to complete the enrollment:

• The retailer submits the customer's request for enrollment to the distributor. • The distributor responds in one of the three ways. If there is a problem with the request (for example,

the customer has another enrollment in progress, or the customer has been flagged for fraud), the distributor sends a rejection to the retailer. If the request is valid and the customer is not currently enrolled with a retailer, the distributor sends an acceptance to the retailer. If the customer is currently enrolled with a competing retailer but intends to switch, the distributor sends a notice of pending switch to both the retailers.

• In the acceptance case, there is a 10-day waiting period during which the customer may cancel the enrollment. To cancel, the customer contacts the retailer, who forwards the cancellation request to the distributor. Assuming the customer does not cancel, at the end of the waiting period, the distributor sends a completion event to the retailer. The customer is now enrolled with the retailer.

• In the switch case, there is also a 10-day waiting period. To cancel, the customer contacts the initiating retailer (that is, the retailer to whom the customer is switching). The initiating retailer forwards the cancellation to the distributor, who then sends completion events to both retailers indicating that the customer will remain enrolled with the original retailer. Assuming the customer does not cancel, at the end of the waiting period, the distributor sends completion events to both retailers indicating that the customer is now enrolled with the initiating retailer.

Interconnected solution

Hub solution

Reading the hub solution

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

Exercise : e-mail bank transfer

• The person sending the money contacts his bank (the Sender bank), specifying from which account to draw the funds, how much money to send, and the name and email address of the recipient.

• The Sender bank sets aside the amount and sends an email to the recipient with instructions on how to complete the transfer.

• The Sender bank sets aside the amount and sends an email to the recipient with instructions on how to complete the transfer.

• The Recipient bank submits the transfer request to the Sender bank. • The Sender bank accepts, and the funds are moved into the

recipient's account, completing the transfer. • At any point, either the sender or recipient may cancel the transfer,

and the transaction is automatically canceled if not completed within 30 days. On cancellation, the funds are returned to the sender's account. (We assume both banks are members of the email transfer programme.)

Hub solution

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 his or 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.