servicechoreographies.com

A choreography in Let's Dance consists of a set of interrelated service interactions corresponding to message exchanges. At the lowest level of abstraction, an interaction is composed of a message sending action and a message receipt action (referred to as communication actions). Communication actions are represented by non-regular pentagons (symbol for send and  for receive) that are juxtaposed to form a rectangle denoting an elementary interaction. As illustrated in Figure 1, a communication action is performed by an actor playing a role, specified at the top corner of a communication action. Roles are written in uppercase and the actor playing this role (the “actor reference”) is written in lowercase between brackets. The name of the message type for the receive actions can be omitted (since the same type applies for both send and receive).

Figure 1: Constructs of Let's Dance

Interactions can be connected using the three constructs depicted in Figure 1. The relationship on the left-hand side is called “precedes" and is depicted by a directed edge: the source interaction can only occur after the target interaction has occurred. That is, after the receipt of a message “M1" by “B", “B” is able to send a message “M2" to “C". The rectangle surrounding these two interactions denotes a composite interaction, which can be related with other interactions with any type of relationship. The relationship at the center of the figure is called “inhibits", depicted by a crossed directed edge. It denotes that after the source interaction has occurred, the target interaction can no longer occur. That is, after “B" has received a message “M1" from “A", it may not send a message “M2" to “C". The latter interaction can be repeated until “x” messages have been sent, which is indicated by the header on top of the interaction. The actor executing the repetition instruction is noted in brackets. Finally, the relationship on the right-hand side of the figure, called “weak-precedes", denotes that “B" is not able to send a message “M2" until “A" has sent a message “M1" or until this interaction has been inhibited. That is, the target interaction can only occur after the source interaction has reached a final status, which may be “completed” or “skipped” (i.e. “inhibited”). In the example, the upper interaction has a guard assigned, which is denoted by the header on top of the interaction. This interaction is only executed if the guard evaluates to true. The actor who evaluates the guard is noted in brackets.

Let's Dance abstracts away from implementation details and avoids reliance on imperative programming constructs. In particular, the language does not rely on variable assignment and conditions need not be written in an executable language. Instead, conditions are treated as free-text labels that should be subsequently refined.

Example

An example of a choreography corresponding to a loan application process is depicted in Figure 2. A client “c” sends a (loan) application to the loan department “l” of a financial institution. Once this interaction is completed, a composite interaction is enabled. This composite interaction contains two guarded sub-interactions. The two elementary interactions on the left-hand side take place only if a credit check is requested. If so, the loan department sends a message “check credit" to the Bureau of Credit Registration (BCR) and receives the credit information for the requested client. If no credit check is requested and the guard evaluates to false, both elementary interactions are inhibited. The two elementary interactions on the right-hand side are executed only if the loan department requests an optional insurance. Since a composite interaction is completed if all sub-interactions have been executed or inhibited, the succeeding interactions are enabled even if both guards inside the composite interaction evaluate to false. For connecting the two following interactions with the composite interaction, a connector has been used for multiple arrows. The loan department either sends a rejection of the application to the client or issues a request for payment with the payment department, whereby here a two-way inhibits relationship is used. If a request for payment is issued, payment notifications for each of the accounts nominated by the client are sent. This is captured through the repetition of the interaction using an (informally) specified condition in the box at the top corner of the interaction.

Figure 2: Choreography of a loan application

Figure 3: Local model for the client

Figure 3 shows the loan application choreography from the view of the actor “c”, playing the role of a client. This local model starts with an interaction for the client sending an application to the loan department, followed by the receipt of either a rejection or payment notifications. The two-way inhibits relationship is a derived relationship that does not explicitly appear in the global model (i.e. it is a “derived” relation). The same holds for the precedes relationship that connects to the interaction for sending the payment notifications, since the client is not involved in any interaction occurring between these two. This illustrates that local models may reflect relationships that are derived from, but not explicitly represented in the global model.

Flash animation

The following animation illustrates one execution of the choreography model presented above. Interactions that are ready to be performed are marked in green and can be clicked upon to denote their execution. The right-hand side represents the flow of messages that results from the execution of an interaction.