Message choreography modeling

Abstract

Service-based applications are based on modern architectures that require careful design of interfaces and protocols to allow smooth integration of service components. These design artifacts are not only useful for implementation, but could also be used for the derivation of integration tests. In order to be applied in these different activities of the development process, they have to conform to existing requirements and other specifications at different architectural levels. In addition, their internal consistency has to be ensured. In this paper, we present an approach to service integration based on a domain-specific language for service choreographies. We first explain the motivation for our work by defining the industrial context that led to the definition of a domain-specific choreography language, called message choreography modeling (MCM). We then provide syntax and semantics for MCM, together with suitable methods for ensuring its consistency. Finally, we report on our experience in applying the described language in practice.

Appendix: MCM semantics via transformation to the Event-B language

In the main paper the trace semantics of MCM has been given. This trace semantics can be refined by describing a transformation of MCM artifacts to a modeling notation with a formally defined semantics. This is a common approach to defining language semantics (cf. [36]). In this section, the transformation of MCM into the formal language Event-B [37], as published in [7], is presented.

Event-B fits quite naturally with MCM as interactions can be expressed seamlessly as events and the relationship between GCM and LPMs can be formulated as Event-B refinement. Apart from defining the MCM semantics, Event-B opens a variety of possibilities for analyzing the model, as described in Sect. 4.4. In this appendix, we start with a brief overview of Event-B. Afterwards, the translation of MCM artifacts into Event-B is introduced.

1.1 Introduction to Event-B

Event-B [37] is an evolution of the B-Method [38] that places emphasis on a lean design. In particular, the core language of Event-B is (with a few exceptions) a subset of the language used in its predecessor. It distinguishes between static and dynamic properties of a system. While static properties are specified in a context, the dynamic properties are specified in what is termed a “machine”. A context contains definitions of carrier sets, constants as well as a number of axioms. A machine basically consists of a finite set of variables and events. The variables form the state of the machine and can be restricted by invariants. The events describe transitions from one state into another state.

An event has the form

$$\begin{aligned} EVENT\,\widehat{=}\,ANY\,t\,WHERE\,G(t,x)\,THEN\,S(x,t)\,END \end{aligned}$$

It consists of a set of local variables $t$, a predicate $G$, called the guard and a substitution $S(x,t)$. The guard restricts possible values for $t$ and $x$. If the guard of an event is false, the event cannot occur and is called disabled. The substitution $S$ modifies the variables $x$. It can use the old values of $x$ and the local variables $t$. For example, an event that takes two natural numbers $a, b$ and adds the product $ab$ to the state variable $x$ could be written as

$$\begin{aligned}&\!\!\!EVENT \,\widehat{=}\,ANY\,a,b\,WHERE\,a \in \mathbb N \wedge b \in \mathbb N \\&\!\!\!THEN x:=x+a*b\,END \end{aligned}$$

For events that do not require local variables, the abbreviated form

$$\begin{aligned} EVENT\,\widehat{=}\,WHEN\,G(x)\,THEN\,S(x)\,END \end{aligned}$$

can be used. The primary way to structure a development in Event-B is through incremental refinement preserving the system’s safety and termination properties.

1.2 Design considerations of the transformation

The transformation from MCM to Event-B contains a formal representation of both, the GCM and the CS, incorporating the two LPMs and the CM. Therefore, the subsequently described translation generates two Event-B machines, which use a common context. The Global Model describes the GCM and the Local Model describes the composition (defined as in [37]) of the two LPMs and the CM. Both machines describe the exchange of messages, the former in terms of observing a message, and the latter in terms of sending and receiving messages.

As messages with the same type and content may occur more than once, a unique natural number is assigned to each message, and this number is incremented when a new message is sent. Further, to each message data type is assigned while it is possible to specify the content of the message as functions on the message data type. Because we aim towards the use of a model checking technique, the translation result is designed to be as deterministic as possible. We experimented with an assignment of types to messages which was non-deterministically initialized upfront; however this resulted in too big a state space for the model checker.

1.3 Transformation description

By defining a translation from the global and from the local MCM models into the two Event-B machines a precise semantics of MCM is obtained, which is presented in the following. The transformation is implemented and can thus be applied completely automatically.

Global model For each GCM transition exactly one event is generated. The states are represented by a global variable $status$ with elements from a set type ${s_1,\ldots ,s_k}$, with constants $s_1,\ldots ,s_k$. It is initialized with $init \in S$. The basic translation of an interaction $i\in I$ with $({s_1,\ldots ,s_k}, \ I, \ s_m) \in \, \Rightarrow$ is as follows:

$$\begin{aligned}&i\,\widehat{=}\,WHEN\,guard1:\,status=s_1 \wedge \cdots \wedge status=s_k\\&THEN\,act1:\,status\,:=\,s_m\,END \end{aligned}$$

This basic translation must be augmented with preconditions and actions, associated with that interaction. Therefore, data types, constants, variables, terms and formulae used in MCM must be represented in Event-B. This is done as follows. For each data type $t\in T$, a set is defined in the Event-B context, without explicit characterization of elements. These sets are named in Event-B according to their type name $name(t)$. For each complex data type $t={(f, t^{\prime })}$, we define a partial function $f\!\!: name(t) \nrightarrow name(t^{\prime })$. $f$ is initialized with $f:=\emptyset$.

The constants and global variables are defined in a standard way. For each constant $c \in C_t$ an element is added to the set $name(t)$. For the interactions $I=\{i_1,\ldots ,i_n\}$, we additionally define a set $MESSAGES=\{name(itype(i_1)),\ldots , name(itype(i_n))\}.$

Example 6

Consider the interaction Request with

$$\begin{aligned}&\!\!\!pre(\mathtt{Request}) = msg.\mathtt{Header.ID} \not \in \mathtt{ID\_SET}\\&\!\!\!act(\mathtt{Request}) (\mathtt{ID\_SET})\\&\quad = \mathtt{ID\_SET} \cup \{msg.\mathtt{Header.ID}\} \end{aligned}$$

of the running example. For this interaction, the partial functions $Header: \mathbb N \nrightarrow MessageHeader$ and $ID: MessageHeader \nrightarrow InstanceID$ (here, $MessageHeader$ and $InstanceID$ are the corresponding names from $name (T)$) are defined, as well as the local variables $t1$ and $t2$ in order to choose appropriate values to be assigned in the functions. Because $ID\_SET \in T_{Set(InstanceId)}$, an Event-B variable $ID\_SET$ of type $\mathbb P (InstanceID)$ is defined.

$$\begin{aligned}&\!\!\!Request \widehat{=} ANY\,t1\,t2\,WHERE\\&\!\!\!grd1: status= Reserved \vee status= Start \\&\!\!\!grd2: t1 \in MessageHeader \\&\!\!\!grd3: t2 \in InstanceID \\&\!\!\!grd4: t3 \notin ID\_SET \\&\!\!\!grd5: t1 \in dom(ID) \Rightarrow ID(t1)=t2 \\&\!\!\!THEN\\&\!\!\!act1: status:=Requested \\&\!\!\!act2: Header(msg):=t1 \\&\!\!\!act3: ID(t1):=t2 \\&\!\!\!act4: type(msg):=Request\\&\!\!\!act5: ID\_SET:= ID\_SET \cup \{t3\} \\&\!\!\!act6: msg := msg + 1 \\&\!\!\!END \end{aligned}$$

The guard $grd5$ describes a consistency property: if the function is already defined on an element, then the value must be the corresponding term.

For the accepting state $e_i \subseteq S$, a special event $terminate$ with a guard ($status=c_1 \vee \cdots \vee status=c_k$) such that $e_i=\{c_1,\ldots ,c_k\}$ and an action $acceptingstate:=true$ is defined, where $acceptingstate$ is a global variable. In each event from the translation of GCM, an additional action $acceptingstate:=false$ is added. As a result, $acceptingstate$ equals true if and only if the system state is an accepting state.

Local model In the local model, events representing the sending and receiving of messages are generated. Depending on the viewpoint either the send or the receive event can be defined as a refinement of the corresponding interaction in GCM.

By definition of LPMs, the variables from $V$ and the status variable are duplicated (one for each partner). The variable $msg$ is translated as for the GCM in order to keep the unique message enumeration. It is only used by send events, where it is set in the same way as in the GCM. In receive events, local variables (parameters) are used in order to obtain a message from a channel.

A channel is defined as a global variable of type $\mathbb P (\mathbb N )$, denoting the set of messages being exchanged. It is initialized with $\emptyset$. Typically, there are two partners $P_1$ and $P_2$ and two sequencing contexts (EO and EOIO). In that case, four possible channels can be obtained in the model (two for each direction).

Example 7

Below, a translation of the interaction Request from the LPMs for the partners buyer ($B$) and seller ($S$) in the example is shown. The duplicated variables can be distinguished by the corresponding prefixes. The channel from buyer to seller having the sequencing EO is denoted by $channel\_BS\_EO$.

$$\begin{aligned}&send\_Request \,\widehat{=}\, ANY\,t1\,t2\,t3 WHERE\\&grd1: B\_status= Reserved \vee B\_status=Start \\&grd2: t1 \in MessageHeader \\&grd3: t2 \in InstanceID \\&grd4: t3 \notin B\_ID\_SET \\&grd5: t1 \in dom(ID)\Rightarrow ID(t1)=t2 \\&THEN\\&act1: B\_status:= Requested \\&act2: Header(msg):=t1 \\&act3: ID(t1):=t2 \\&act4: type(msg):=Request \\&act5: B\_ID\_SET:=B\_ID\_SET \cup \{t3\} \\&act6: channel\_BS\_EO:= channel\_BS\_EO \cup \{msg\} \\&act7: msg := msg + 1 \\&END \\&receive\_Request \;\widehat{=}\; m WHERE \\&grd1: S\_status= Reserved \vee S\_status=Start \\&grd2: m \in channel\_BS\_EO \\&grd3: type(m) = Request \\&grd4: m \in dom(Header) \\&grd5: Header(m) \in dom(ID) \\&grd6: ID(Header(m)) \notin S\_ID\_SET \\&THEN \\&act1: S\_status := Requested \\&act2: S\_ID\_SET := S\_ID\_SET \cup \{ID(Header(m))\} \\&act3: channel\_BS\_EO := channel\_BS\_EO \setminus \{m\} \\&END \end{aligned}$$

The translation of a send event is very similar to the translation of the corresponding event in GCM. In receive events, all function values are already set, so that the purpose is to find a matching message $m$ in the channel and “receive” it (i.e., delete it from the channel). If a sequencing context is EOIO, then an additional guard is needed to ensure that the message $m$ has the smallest number in the channel.

For inhibitor conditions $inhib(i)=C$ (with $i \in I$), a guard $status \notin C$ is added to the event $send\_i$. In our example, the guard $grd6: B\_status \notin \{Reserved\}$ is added to $send\_Request$.

Accepting states are treated in a similar way to the translation of GCM, except that it is demanded additionally that $channel=\emptyset$ for all of them, because only if all channels are empty can the system enter into an accepting state. For all other events of the translation from the LPM, an action $acceptingstate:=false$ is added.