On the Enactability of Agent Interaction Protocols: Toward a Unified Approach

TL;DR

This paper investigates whether global agent interaction protocols can be practically implemented in distributed multi-agent systems, considering various message ordering and communication constraints to determine enactability.

Contribution

It introduces a comprehensive framework for analyzing the enactability of global protocols under different message and communication assumptions.

Findings

Identifies conditions under which protocols are enactable

Provides a formal method for checking enactability

Considers multiple message ordering interpretations

Abstract

Interactions between agents are usually designed from a global viewpoint. However, the implementation of a multi-agent interaction is distributed. This difference can introduce issues. For instance, it is possible to specify protocols from a global viewpoint that cannot be implemented as a collection of individual agents. This leads naturally to the question of whether a given (global) protocol is enactable. We consider this question in a powerful setting (trace expression), considering a range of message ordering interpretations (what does it mean to say that an interaction step occurs before another), and a range of possible constraints on the semantics of message delivery, corresponding to different properties of underlying communication middleware.

Equations

$$[[ϵ]]$$

$$[[M]]$$

$$[[{\tau }_1\cdot {\tau }_2]]$$

$$[[{\tau }_1\wedge {\tau }_2]]$$

$$[[{\tau }_1\vee {\tau }_2]]$$

$$[[{\tau }_1|{\tau }_2]]$$

$${\mathcal{E}}_{\mathcal{I}}=\{aM!|{\exists }_{b\in \mathcal{A}}.a\stackrel{M}{⟹}b\in \mathcal{I}\}\cup \{bM?|{\exists }_{a\in \mathcal{A}}.a\stackrel{M}{⟹}b\in \mathcal{I}\}$$

$${\mathcal{L}}_{{\mathcal{E}}_{\mathcal{I}}}$$

$$\mathrm{poset}(ϵ)$$

$$\mathrm{poset}(I)$$

$$\mathrm{poset}({\tau }_1\wedge {\tau }_2)$$

$$\mathrm{poset}({\tau }_1|{\tau }_2)$$

$$\mathrm{poset}({\tau }_1\vee {\tau }_2)$$

$$\mathrm{poset}({\tau }_1\cdot {\tau }_2)$$

$$(E_1,{<}_1)\cdot (E_2,{<}_2)$$

$$[[ϵ{]]}_{\text{moi}}$$

$$[[I{]]}_{\text{moi}}$$

$$[[{\tau }_1\wedge {\tau }_2{]]}_{\text{moi}}$$

$$[[{\tau }_1\cdot {\tau }_2{]]}_{\text{moi}}$$

$$[[{\tau }_1\vee {\tau }_2{]]}_{\text{moi}}$$

$$[[{\tau }_1|{\tau }_2{]]}_{\text{moi}}$$

$${\mathcal{L}}_{CM1}^{{\mathcal{E}}_{\mathcal{I}}}$$

$${\mathcal{L}}_{CM2}^{{\mathcal{E}}_{\mathcal{I}}}$$

$${\mathcal{L}}_{CM3}^{{\mathcal{E}}_{\mathcal{I}}}$$

$${\mathcal{L}}_{CM4}^{{\mathcal{E}}_{\mathcal{I}}}$$

$${\mathcal{L}}_{CM5}^{{\mathcal{E}}_{\mathcal{I}}}$$

$${\mathcal{L}}_{CM6}^{{\mathcal{E}}_{\mathcal{I}}}$$

$$[[{\tau }_i{]]}_{\text{moi}}^{\text{CM}}$$

$$[[{\tau }_m{]]}^{\text{CM}}$$

$$(ϵ{)}^A$$

$$(a\stackrel{M}{⟹}b{)}^A$$

$$(aM!{)}^A$$

$$(aM?{)}^A$$

$$({\tau }_1\otimes {\tau }_2{)}^A$$

$$┌\tau ┐$$

$$reqInfo=Alice\stackrel{Info}{⟹}Carol\cdot$$

$$(Carol\stackrel{Wrong}{⟹}Alice\cdot reqInfo\vee Carol\stackrel{Booked}{⟹}Alice)$$

$$┌main┐$$

$${main}^{Alice}$$

$${modifyRes}^{Alice}$$

$${reqInfo}^{Alice}$$

$${main}^{Bob}$$

$${modifyRes}^{Bob}$$

$${reqInfo}^{Bob}$$

$${main}^{Carol}$$

Full text

K****eywords Agent Interaction Protocols  $\cdot$ Enactability  $\cdot$ Enforceability  $\cdot$ Implementability  $\cdot$ Realizability  $\cdot$ Projectability  $\cdot$ Trace Expressions

1 Introduction

In order to organise her staying in Montreal, Alice books an apartment from Bob via the online platform AIPbnb. AIPbnb policy states that owners cannot interact with each other, users can interact with owners only via the platform, and if a user finds a better solution for her accommodation, she must cancel the previous one before she makes a new reservation for the same dates, otherwise she will be charged for one night there. When Alice discovers that Carol rents a cheaper and larger apartment, she decides to cancel the reservation of Bob’s apartment and book Carol’s one. This situation can be represented by the global Agent Interaction Protocol $\mathit{modifyRes}=Alice\stackrel{{\scriptstyle{Canc}}}{{\Longrightarrow}}Bob~{}\cdot~{}Alice\stackrel{{\scriptstyle{Res}}}{{\Longrightarrow}}Carol$ where $a1\stackrel{{\scriptstyle{M}}}{{\Longrightarrow}}a2$ models the interaction between $a1$ and $a2$ for exchanging message $M$, “$\cdot$” models interaction concatenation, and $Canc$ and $Res$ are sent to the recipients by using the AIPbnb platform as required. Alice believes that the above protocol correctly meets AIPbnb policy, but she is charged for one night in Bob’s apartment by AIPbnb: Carol received Alice’s request before Bob received the cancellation, and this violates the policy. What went wrong is the interpretation of “before”. To Alice, it meant that she should send $Canc$ before she sent $Res$, while for AIPbnb it (also) meant that Bob should receive $Canc$ before Carol received $Res$. This ambiguity would have had no impact on Alice if the physical communication model underlying AIPbnb guaranteed that between the sending and receiving stages of an interaction, nothing could happen. However, if the communication model provides weaker or no guarantees, it may happen that a message sent before another, is delivered after.

This simple example shows that enacting the respect of a global protocol without a clear semantics of the “before” meaning, without guarantees from the platform implementation on message delivery order, and without hidden communications between the participants (“covert channels”), may not be possible. Many real situations can be resorted to this one: for example, a citizen must wait for the bank to have received (and processed) the request for adding some money to a new, empty account, before sending a request to move that amount to another account, otherwise he can go in debt.

Global protocols are modelled using many different formalisms including global types [1], Petri Nets [2], WS-CDL [3], AUML [4], Statecharts [5], and causal logic [6]. In each of these formalisms the enactability problem, that we define as “by executing the localised versions of the protocol implemented by each participant, the global protocol behaviour is obtained, with no additional communication”, has been addressed in some form. Despite their diversity, however, most of these formalisms do not support protocol concatenation and recursion, which are needed to achieve a high expressivity: their expressive power is limited to regular languages.

Moreover, although – from an operational point of view – these approaches agree on the intuition that a global protocol is enactable if the composition of the local protocols, obtained by projecting the global one onto each participant, behaves exactly in the same way as the global protocol, the semantic definition of enactability is far from being standard and sometimes is also more restrictive than necessary: some protocols will be classified as not enactable, while (under suitable conditions) they could be enacted.

The intended message ordering and the communication model of the infrastructure in which the agents will be implemented and run are never taken into consideration together. As shown in the example above these two elements are effectively two sides of the same coin which must be both modeled for providing a precise and generally applicable definition of enactability.

In a similar way, the need to associate the protocol with a decision structure to enforce consistent choices, is recognised as a necessity and suitably addressed by [7] only, and not in conjunction with the other issues that affect enactability.

Finally, the availability of a working prototype to check the enactability of global protocols under message ordering and communication models is usually disregarded in the literature.

In this paper we provide a semantic characterisation of enactability which integrates message ordering and communication model in a unified framework, along with decision structures. This combination prevents unnecessary restrictions from the definition, which is as general as possible and suitable for highly expressive protocol representation languages like Trace Expressions [8]. We also developed a working prototype in Haskell for enactability checks, which is one key benefit of out approach.

2 Background

Trace Expressions.

Trace expressions [8] are a compact and expressive formalism inspired by global types [9] and then extended and exploited in different application domains [10, 11, 12, 13, 14]. Trace Expressions, initially devised for runtime verification of multiagent systems, are able to define languages that are more than context free.

A trace expression $\tau$ denotes a set of possibly infinite event traces, and is defined on top of the following operators:111Binary operators associate from left, and are listed in decreasing order of precedence, that is, the first operator has the highest precedence.

• •

$\epsilon$ (empty trace), denoting the singleton set $\{\langle\rangle\}$ containing the empty event trace $\langle\rangle$.

• •

$M$ (event), denoting a singleton set $\{\langle M\rangle\}$ containing the event trace $\langle M\rangle$.

• •

$\tau_{1}{\cdot}\tau_{2}$ (concatenation), denoting the set of all traces obtained by concatenating the traces of $\tau_{1}$ with those of $\tau_{2}$.

• •

$\tau_{1}{\wedge}\tau_{2}$ (intersection), denoting the intersection of the traces of $\tau_{1}$ and $\tau_{2}$.

• •

$\tau_{1}{\vee}\tau_{2}$ (union), denoting the union of the traces of $\tau_{1}$ and $\tau_{2}$.

• •

$\tau_{1}{|}\tau_{2}$ (shuffle), denoting the union of the sets obtained by shuffling each trace of $\tau_{1}$ with each trace of $\tau_{2}$ (see [15] for a more precise definition).

Trace expressions are cyclic terms, thus they can support recursion without introducing an explicit construct.

As customary, the operational semantics of trace expressions, defined in [16], is specified by a transition relation $\delta\subseteq\mathcal{T}\times\mathcal{E}\times\mathcal{T}$, where $\mathcal{T}$ and $\mathcal{E}$ denote the set of trace expressions and of events, respectively. We do not present all the transition rules for space constraints. They are standard ones which state, for example, that $\delta(ev\cdot\tau,ev,\tau)$ (the protocol whose state is modelled by $ev\cdot\tau$ can move to state $\tau$ if $ev$ occurs), and that $\delta(\tau_{1}\lor\tau_{2},ev,\tau)$ if $\delta(\tau_{1},ev,\tau)$ (if the protocol whose state is modelled by $\tau_{1}$ can move to state $\tau$ if $ev$ occurs, then also the protocol whose state is modelled by $\tau_{1}\lor\tau_{2}$ can).

The denotational semantics is defined as follows:

[TABLE]

Where $t_{1}\bowtie t_{2}$ is the set of all interleavings of $t_{1}$ and $t_{2}$, and $\circ$ is concatenation over sequences.

Events can be in principle of any kind. In this paper, we will limit ourselves to consider interaction and message events.

An interaction has the form $a\stackrel{{\scriptstyle{M}}}{{\Longrightarrow}}b$ and gives information on the protocol from the global perspective, collapsing sending and receiving. We say that $\tau$ is an interaction protocol if all the events therein are interactions. Interaction protocols take other names in other communities, such as Interaction Oriented Choreography [17] in the Service Oriented Community, and global type in the community working on process calculi and types [1].

Message events have the form ${a}{M}!$ ($a$ sends $M$) and ${b}{M}?$ ($b$ receives $M$). They model actions that one agent can execute, hence taking a local perspective. A trace expression where all events are messages will be named a message protocol throughout the paper. Message protocols have different names in different communities, such as Process Oriented Choreography [17] and “local type” or “session type” in the global type community [18, 19].

Communication Models.

Given that in our proposal we explicitly take the communication model supported by the MAS infrastructure into account, we provide a summary of communication models based on [20]. We use CM0 to CM6 to identify them in a compact way.

CM0: Synchronous Communication. Sending and receiving are synchronised: the sender cannot send if the receiver is not ready to receive.

CM1: Realisable with Synchronous Communication (RSC). After a communication transition consisting of a send event of a message, the only possible communication transition is the receive event of this message. This asynchronous model is the closest one to synchronous communication and can be implemented with a 1-slot unique buffer shared by all agents.

CM2: FIFO n-n communication. Messages are globally ordered and are delivered in their emission order: if sending of $M_{1}$ takes place before sending of $M_{2}$, then reception of $M_{1}$ must take place before reception of $M_{2}$. This model can be implemented by means of a shared centralised object, such as unique queue.

CM3: FIFO 1-n communication. Messages from the same sender are delivered in the order in which they were sent. It can be implemented by giving each agent a unique queue where it puts its outgoing messages. Destination peers fetch messages from this queue.

CM4: FIFO n-1 communication. A send event is implicitly and globally ordered with regard to all other sending actions toward the same agent. This means that if agent $b$ receives $M_{1}$ (sent by agent $a$) and later it receives $M_{2}$ (sent by agent $c$), $b$ knows that the sending of $M_{1}$ occurred before the sending of $M_{2}$ in the global execution order, even if there is no causal path between the two sending actions. The implementation of this model can, similarly to FIFO 1-n, be done by providing each agent with a queue: messages are sent by putting them into the queue of the recipient agent.

CM5: Causal. Messages are delivered according to the causality of their emissions [21]: if a message $M_{1}$ is causally sent before a message $M_{2}$ then an agent cannot get $M_{2}$ before $M_{1}$. An implementation of this model requires the sharing of the causality relation.

CM6: Fully Asynchronous. No order on message delivery is imposed. Messages can overtake others or be arbitrarily delayed. The implementation is usually modelled by a bag.

Message Ordering.

The statement “one interaction comes before another” is ambiguous, as exemplified in Section 1. This ambiguity has been recognised by some authors who suggested how to interpret message ordering, when moving from the interaction (global) level to the message (local) level. In this section we summarise and compare the proposals by Lanese, Guidi, Montesi and Zavattaro [17] and that by Desai and Singh [22].

To identify the interpretations, we will use the acronyms used in [22] when available, and our own acronyms otherwise. The starting point for interpreting message ordering is the interaction protocol $\tau=a\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}b{\cdot}c\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}d$. For the sake of clarity, we denote ${a}{M_{1}}!$ with $s1$, ${b}{M_{1}}?$ with $r1$, ${c}{M_{2}}!$ with $s2$, and ${d}{M_{2}}?$ with $r2$; we characterise the message ordering interpretations by the traces of messages that respect them.

RS: a message send must be followed immediately by the corresponding receive, so w.r.t. $\tau$, $M_{1}$ must be received before $M_{2}$ is sent. The set of traces that respect this model is $\{s1~{}r1~{}s2~{}r2\}$. This interpretation is named RS (receive before send) in [22] and disjoint semantics in [17].

SS: $M_{1}$ is sent before $M_{2}$ is, and there are no constraints on the delivery order. The set of traces that respect this model is $\{s1~{}r1~{}s2~{}r2,$ $s1~{}s2~{}r1~{}r2,$ $s1~{}s2~{}r2~{}r1\}$. This interpretation is named SS (send before send) in [22] and sender semantics in [17].

RR: $M_{1}$ is received before $M_{2}$ is, and there are no constraints on the sending order. The set of traces that respect this model is $\{s1~{}r1~{}s2~{}r2,s1~{}s2~{}r1~{}r2,s2~{}s1~{}r1~{}r2\}$. This interpretation is named RR (receive before receive) in [22] and receiver semantics in [17].

RR & SS: this combines the requirements of RR and of SS: $M_{1}$ is sent before $M_{2}$ is sent and also $M_{1}$ is received before $M_{2}$ is received. The set of traces that respect this model is $\{s1~{}r1~{}s2~{}r2,s1~{}s2~{}r1~{}r2\}$: both $s1$ comes before $s2$ (“coming before” according to the senders), and $r1$ comes before $r2$ (“coming before” according to the receivers). This interpretation is named sender-receiver semantics in [17].

SR: $M_{1}$ is sent before $M_{2}$ is received. The set of traces that respect this model is $\{s1~{}r1~{}s2~{}r2,$ $s1~{}s2~{}r1~{}r2,$ $s1~{}s2~{}r2~{}r1,$ $s2~{}s1~{}r1~{}r2,$ $s2~{}s1~{}r2~{}r1\}$. This interpretation is named SR (send before receive) in [22].

It is easy to see that the following inclusions among asynchronous models hold: RS $\subset$ RR & SS $\subset$ SS $\subset$ SR and RS $\subset$ RR & SS $\subset$ RR $\subset$ SR. The SS and RR interpretations are not comparable. In the remainder of this paper we consider only the four interpretations defined by Desai & Singh, i.e. we do not consider “RR & SS”.

3 Defining Enactability using a Semantic Approach

Basic Notation.

In the following let $\emph{ComModel}=\{CM1,CM2,CM3,CM4,CM5,$ $CM6\}$ be the set of possible (asynchronous) communication models, and $\emph{MOISet}=$ $\{\emph{SS}$, SR, RS, RR $\}$ the set of possible message order interpretations that can be imposed.

We also define $\mathcal{A}=\{a,b,c,d,a_{1},a_{2},\ldots,a_{n}\}$ to be the set of agents involved in the interaction protocol.

Recall that we consider both interaction and message protocols. When we say that $\tau$ is an interaction protocol, we mean that the protocol represents sequences of interactions. The set of traces recognized is obtained following the semantics defined in Section 2, and for an interaction protocol $\tau$ we have that222We use “$\in$” to also denote membership of an item in a sequence. ${I}\in\llbracket{\tau}\rrbracket\implies\forall_{{i}\in{I}}.{i}\in\mathcal{I}({\tau})$, where we define $\mathcal{I}({\tau})$ to be the set of interactions involved in the interaction protocol $\tau$. We also define $\mathcal{I}$ to be the set of all possible interactions events. Similarly, when $\tau$ is a message protocol (rather than an interaction protocol), it represents sequences of send and receive events of the form ${a}{M}!$ (send event) and ${b}{M}?$ (receive event), and given a particular set of possible interactions $\mathcal{I}$, we define $\mathcal{E}_{\mathcal{I}}$ to be the corresponding set of events:

[TABLE]

In a message protocol $\tau$ we have that ${E}\in\llbracket{\tau}\rrbracket\implies\forall_{{e}\in{E}}.{e}\in\mathcal{E}_{\mathcal{I}({\tau})}$. Given a message protocol $\tau$ we also define $\mathcal{E}(\tau)$ to be the set of events that occur in the protocol.

Next, we define the language of traces for interaction protocols and message protocols. For interaction protocols, the set of all possible traces is defined to be: $\mathcal{L}_{\mathcal{I}}=\mathcal{I}^{*}\cup\mathcal{I}^{\omega}$. For message protocols the definition is somewhat more complex, since there is a relationship between a send and a receive event. Specifically, the set of all possible traces of events is constrained so that a message being received must be preceded by that message having been sent. We also constrain the set so that each message can be sent at most once, and received at most once (i.e. message names are unique). The assumption is made by most authors, see [20] for example, and it is considered as a harmless one; we can integrate many elements to the notion of “message name”, such as content, protocol id, conversation id, etc, to discriminate between messages at design time. Formally:

[TABLE]

Message Order Interpretation (MOI).

An interaction protocol $\tau$ defines orderings between messages $M_{i}$, whereas a message protocol deals in events (sending and receiving). If a protocol says that $M_{1}$ comes before $M_{2}$, how should we interpret this in terms of events? Should sending $M_{1}$ come before sending $M_{2}$, or does it mean that receiving $M_{1}$ should occur before receiving $M_{2}$? The message ordering interpretation (MOI) specifies this. As discussed earlier, we follow prior work in considering four (natural) interpretations (SS, SR, RS, and RR). We formalise this by defining a variant semantics that takes an interaction protocol $\tau$ and returns its semantics in terms of events rather than interactions. The possible sequences of events are constrained: given a situation where $\tau$ specifies that $M_{1}$ must occur before $M_{2}$, we constrain the possible sequence of events with the appropriate constraint on events corresponding to the selected MOI.

Def. 3.1** (Order on interactions in a trace)**

*Let ${I}\in\mathcal{L}_{\mathcal{I}}$ be a trace of interaction events, ${E}\in\mathcal{L}_{\mathcal{E}_{\mathcal{I}}}$ be a trace of send and receive events, $\emph{moi}\in\emph{MOISet}$ a message ordering interpretation, and $a\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}b\in\mathcal{I}$, $c\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}d\in\mathcal{I}$ two interactions. Abbreviating $a\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}b$ as $I_{1}$ and $c\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}d$ as $I_{2}$, we define an order on $M_{1}$ and $M_{2}$ for moi in ${E}$ as follows:

${I_{1}}\prec_{\emph{SS}}^{{E}}{I_{2}}\triangleq{{a}{M_{1}}!}\prec_{{E}}{{b}{M_{2}}!}$

${I_{1}}\prec_{\emph{SR}}^{{E}}{I_{2}}\triangleq{{a}{M_{1}}!}\prec_{{E}}{{d}{M_{2}}?}$

${I_{1}}\prec_{\emph{RS}}^{{E}}{I_{2}}\triangleq{{b}{M_{1}}?}\prec_{{E}}{{b}{M_{2}}!}$

${I_{1}}\prec_{\emph{RR}}^{{E}}{I_{2}}\triangleq{{b}{M_{1}}?}\prec_{{E}}{{d}{M_{2}}?}$

where ${e_{1}}\prec_{{E}}{e_{2}}\triangleq\exists_{i,j\in dom({E})}.{E}[i]=e_{1}\wedge{E}[j]=e_{2}\wedge i\leq j$*

Formalising the MOI is not as simple as it might seem. An obvious approach that does not work is to compute the semantics of the interaction protocol $\tau$, and then map each sequence ${I}\in\llbracket{\tau}\rrbracket$ to a set of message event traces. This does not work because the trace is linear, and therefore a total order, whereas a protocol can specify a partial order. An illustrative example is $\tau=(M_{1}\cdot M_{2})\;|\;M_{3}$. This simple protocol has three sequences of interactions: $\{\langle M_{1},M_{2},M_{3}\rangle,\langle M_{1},M_{3},M_{2}\rangle,\langle M_{3},M_{1},M_{2}\rangle\}$. Assume an RS message ordering interpretation, then each of the message sequences corresponds to exactly one sequence of events, giving333For readability we use $s(M)$ and $r(M)$ to abbreviate sending and receiving message $M$, eliding the identity of the agents involved. $\{\langle s(M_{1}),r(M_{1}),s(M_{2}),r(M_{2}),s(M_{3}),r(M_{3})\rangle,$ $\langle s(M_{1}),r(M_{1}),$ $s(M_{3}),r(M_{3}),$ $s(M_{2}),r(M_{2})\rangle,\langle s(M_{3}),r(M_{3}),s(M_{1}),r(M_{1}),s(M_{2}),$ $r(M_{2})\rangle\}$. However, the protocol does not specify any constraint on $M_{3}$, so should also allow other interpretations where the occurrences of $s(M_{3})$ and $r(M_{3})$ are not constrained relative to the other events, for example $\langle s(M_{1}),r(M_{1}),s(M_{3}),s(M_{2}),r(M_{2}),$ $r(M_{3})\rangle$.

Instead, we define a variant semantics, which is compositional. The semantics follow the standard semantics (Section 2) with a few exceptions. Firstly, the semantics of an interaction $I$ is given as the sequence of sending the message, followed by receiving it (denoted respectively $s(I)$ and $r(I)$). Secondly, the semantics for a sequence $\tau_{1}\cdot\tau_{2}$ is given by taking the semantics of $\tau_{1}$ and of $\tau_{2}$. These are then combined by interleaving them (rather than simply concatenating them), but with the constraint that the result must satisfy the appropriate MOI constraint (${I_{1}}\prec_{\emph{SS}}^{{E}}{I_{2}}$) for all possible final messages of $\tau_{1}$ ($I_{1}$) and all possible initial messages of $\tau_{2}$ ($I_{2}$). Determining initial and final messages is itself somewhat complex, and is done using partially ordered sets.

A partially ordered set (poset) is a pair $(E,<)$ where $E$ is the set of elements (in this case send and receive events) and $<$ is a binary relation on $E$. We define the union operator to act piecewise on posets, and to take the transitive closure of the resulting relation, i.e. $(E_{1},<_{1})\cup(E_{2},<_{2})=(E_{1}\cup E_{2},(<_{1}\cup<_{2})^{*})$. We can then define the $\mathrm{poset}$ of an interaction protocol as follows

[TABLE]

Where we define a sequence of two posets $(E_{1},<_{1})\cdot(E_{2},<_{2})$ by collecting the orderings of each of $E_{1}$ and $E_{2}$, and adding additional ordering constraints between the maximal elements of $E_{1}$ and the minimal elements of $E_{2}$. We can now proceed to define $\llbracket{\tau}\rrbracket_{\emph{moi}}$.

[TABLE]

Where $t_{1}\bowtie t_{2}$ is the set of all interleavings of $t_{1}$ and $t_{2}$.

Communication Model Semantics.

We formalise the defined communication model semantics by defining for each communication model $CMi$ a corresponding language of event traces that incorporates the appropriate restriction, ruling out event sequences that violate the communication model. The definitions below are those already provided in Section 2. For example, for $CM1$ the constraint is that immediately after each sending event in $u$ we have its corresponding receiving event, with nothing in the middle; etc.

[TABLE]

[TABLE]

We can then apply a particular communication model to an interaction protocol $\tau_{i}$ using $\llbracket{\tau_{i}}\rrbracket_{\emph{moi}}^{\emph{CM}}$, and to a message protocol $\tau_{m}$ using $\llbracket{\tau_{m}}\rrbracket^{\emph{CM}}$, which are defined as follows:

[TABLE]

Projection.

Projection is defined, intuitively, as focussing on the aspects of the protocol that are relevant for a given role. It is defined as follows, where we write $\tau^{A}$ to denote projecting trace $\tau$ for role $A$.

[TABLE]

We then define the distribution of $\tau$, denoted $\ulcorner{\tau}\urcorner$, where $\tau$ involves roles $a_{1}\ldots a_{n}$ as444We use $\|$ to distinguish between parallel composition of different agents, and parallel composition within a protocol. This distinction is used later in this section.:

[TABLE]

To make an example, let us consider again the scenario proposed in Section 1. Alice decided to book Carol’s apartment and now Carol needs some pieces of information from Alice in order to complete the reservation. This information can be wrong or incomplete, and Carol might need to ask Alice twice or more times. This can be represented using a cyclic specification

[TABLE]

[TABLE]

where if the information provided by Alice is not satisfactory, Carol tells Alice and asks for new one (recursion on $\mathit{reqInfo}$). Once Carol will be satisfied with Alice’ answer, she will confirm the booking. Thanks to cyclic specifications, we can represent protocols with infinite behaviours. Let us consider $\mathit{main}$ as the combination of the two protocols: $\mathit{main}=\mathit{modifyRes}~{}\cdot~{}\mathit{reqInfo}$.

The projection of $\mathit{main}$ on each single agent would generate

[TABLE]

[TABLE]

[TABLE]

[TABLE]

In order to define the semantics of a projected protocol we need to first define what we term a decision structure. This is needed in the semantics in order to deal correctly with projected protocols. Specifically, the intuition for enactability (see Section 3) is that an interaction protocol $\tau$ involving, say, three roles $a$, $b$ and $c$ is enactable iff there exist three protocols $\tau^{a}$, $\tau^{b}$ and $\tau^{c}$ such that their concurrent interleaving results in the same behaviour as the original protocol. However, when a protocol contains choices ($\lor$) we need to ensure that the occurrences of $\lor$ in each of $\tau^{a}$, $\tau^{b}$ and $\tau^{c}$ arising from the same $\lor$ in $\tau$ are treated consistently. For example, consider the protocol $\tau=a\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}b\lor a\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}c$. This protocol is simple: it specifies that agent $a$ can either send a message (“$M_{1}$”) to $b$, or it can send a different message (“$M_{2}$”) to agent $c$. When we distribute the protocol by projecting it (see Section 3) and forming $\tau^{a}\|\tau^{b}\|\tau^{c}$ we obtain the distributed protocol $({a}{M_{1}}!\lor{a}{M_{2}}!)\|({b}{M_{1}}?\lor\varepsilon)\|(\varepsilon\lor{c}{M_{2}}?)$. However, if we interpret each $\lor$ independently (as the semantics would naturally do) then we can have inconsistent choices. For example, we could have $({a}{M_{1}}!)\|(\varepsilon)\|(\varepsilon)$ where the message is sent by $a$, but $b$ does not elect to receive it. So what we need to do is ensure that each of the three occurrences of “$\lor$” represent the same choice, and that the choice should be made consistently.

The heart of the issue is that the trace expression notation offers a choice operator ($\lor$), which is adequate for global protocols. However, for local protocols it is important to be able to distinguish between a choice that represents a free (local) choice, and a choice that is forced by earlier choices. In this example, $a$ can freely choose whether to send $M_{1}$ or $M_{2}$. However, the choice of $b$ whether to receive $M_{1}$ or not is not a free choice, but is forced by $a$’s earlier choice.

Our semantics handles this by defining a decision structure which is used to enforce consistent choices. Formally, given a protocol $\tau$ we define $d(\tau)$ as a set of decision structures (formal definition below). A decision structure is a syntactic structure that mirrors the structure of $\tau$, except that each $\lor$ is annotated with a decision (e.g. $L$ or $R$). We define three operations defined on a decision structure: to get the sub-decision structure corresponding to the left part (denoted $d.L$), to get the right part ($d.R$) and to get the decision (L or R) associated with the current $\lor$ node (denoted $d.D$). We define $d(\tau)$ to create a set of decision structures, each of which corresponds to the structure of $\tau$, but where all possible assignments of decisions are made. Observe that If $\tau$ contains $N$ occurrences of $\lor$ then the set $d(\tau)$ contains $2^{N}$ elements. For example, given $\tau={a}\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}{b}\lor{a}\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}{b}$ we have that $d(\tau)=\{\_\overset{L}{\lor}\_,\_\overset{R}{\lor}\_\}$ where we use $\_$ to indicate an irrelevant part of a decision structure, and $\overset{L}{\lor}$ to denote a node tagged with a decision $L$.

In addition to decisions of $L$ and $R$, the definition of $d(\tau_{1}\lor\tau_{2})$ has a second case ($\ldots\cup\{t_{1}\overset{LR}{\lor}t_{2}\ldots$). The reason is that it is only possible to enforce consistent choice if the choice is made by a single agent. If this is not the case, then we annotate with “$LR$” to indicate that a mixed choice is possible. For example, given $\tau={b}\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}{a}\lor{a}\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}{b}$ we have that $d(\tau)=\{\_\overset{LR}{\lor}\_\}$ because $ag({\tau_{1}})=\{b\}\neq ag({\tau_{2}})=\{a\}$.

[TABLE]

Where $\otimes$ is any operator, and $\oplus$ is any operator other than $\lor$.

We now specify the semantics of a distributed protocol, denoted $\llbracket{\tau}\rrbracket_{\mathrm{dist}}$. The semantics is defined in terms of a union over possible decision structures (first line). The remaining of the equations for the semantics carry along the decision structure, and follow it in recursive calls, and for the semantics of $\lor$ it enacts the decision specified in the structure, rather than considering both sub-protocols. Note that projection is defined using $\|$ rather than the usual $|$ - this differs in the semantics below, in that $\|$ passes the same decision structure to both arguments. This ensures consistency between agents, but not within agents.

[TABLE]

Where $t_{1}\bowtie t_{2}$ is the set of all interleavings of $t_{1}$ and $t_{2}$, and $\circ$ is concatenation over sequences. Note that if $\tau$ does not contain any occurrences of $\lor$ then the semantics above reduce to the standard semantics.

Finally, we define $\llbracket{\tau_{i}}\rrbracket_{\mathrm{dist}}^{\emph{CM}}$, which computes the semantics of an interaction protocol $\tau_{i}$ by distributing it, and also applies a particular communication model CM.

[TABLE]

Enactability.

We are now finally in a position to define enactability. The intuition is that an interaction protocol $\tau$ is enactable iff the semantics of $\tau$, with respect to a selected message ordering interpretation and communication model, can be realised by a distributed version of the protocol. In other words, if there exists for each role $r$ a corresponding message protocol $\tau_{r}$ such that the combination of these protocols realises the same behaviour as $\tau$. However, instead of considering whether there exists some $\tau_{r}$, we let $\tau_{r}=\tau^{r}$, i.e. we take for each role the projected protocol as its protocol.

We also consider a notion of weak enactability. This applies in a situation where the a distributed enactment is able to avoid violating the behaviour specified by $\tau$, but is not able to recreate all of the behaviours that $\tau$ specifies. This situation can arise with weaker message ordering interpretations (see below for examples). Weak enactability can also arise in situations where two ordered messages have two overlapping roles (e.g. $\tau={a}\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}{b}\cdot{b}\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}{a}$). In this situation the projection operator is too strict: it has $\tau^{b}=r(M_{1})\cdot s(M_{2})$, but if we adopt an SR message ordering interpretation, then we do not need to ensure that $M_{2}$ is sent after $M_{1}$ is received, only that $M_{1}$ is sent before $M_{2}$ is received, which role $a$ can ensure on its own.

Def. 3.2** (Strongly/Weakly Enactable)**

Let $\tau$ be an interaction protocol, $\{a_{1},a_{2},$ $...,$ $a_{n}\}$ the set of agents involved in $\tau$, $\emph{moi}\in\emph{MOISet}$ a message order interpretation and $\emph{CM}\in\emph{ComModel}$ a communication model. We say that, $\tau$ is strongly (weakly) enactable, for moi semantics in CM model iff the decomposition of $\tau$ through projection on its agents $\{a_{1},a_{2},...,a_{n}\}$ recognizes the same (a subset of) traces recognized by $\tau$. Formally:

[TABLE]

If a protocol is weak enactable, the interleaving of the corresponding local protocols generates a subset of its traces (with a fixed moi and communication model). In practice, this means that our implementation is sound (generates only valid traces), but it is not complete (not all the traces are generated). Consequently, our system will be more restrictive than we wanted.

Figure 1 show the results of applying this definition to a number of cases, with different message ordering interpretation, and different communication models. These tables were all generated by the Haskell implementation of the definitions in this paper, in which ✔and (✔) denote strongly and weakly enactable, respectively. The prototype counts ~300 LOC. It implements the trace expression standard semantics, message order interpretation, communication model semantics and enactability check555The code is available on the web at: http://enactability.altervista.org/.

Looking at the tables in Figure 1, we make the following observations.

Firstly, CM1 is quite strict: all the cases considered are enactable under CM1, regardless of the selected message ordering interpretation. This is expected: we know that CM1 is quite strong.

Secondly, for many examples there is not a difference in enactability with the different communication models (other than CM1), except where the communication model corresponds to the combination of MOI and the pattern in the protocol. For example, in the top row, second table from the right, the simple protocol is enactable given SS message ordering interpretation only with CM2 and CM4 (and, of course, CM1). This is because for this protocol both messages are received by the same agent but sent by different agents, and, given an RR MOI, the desired constraint that agent $B$ receives the first message before the second, can only be enforced using a communication model that guarantees delivery of messages to the same recipient in the order in which messages were sent. Both CM2 and CM4 provide this guarantee (in fact CM4 provides exactly this, and CM2 is stronger).

Thirdly, RS appears to be a good choice for message ordering interpretation, since it is the only MOI where protocols are never weakly enactable. For the other message ordering interpretations, there are protocols that are only weakly enactable (for communication models other than CM1). A protocol being weakly enactable indicates that the desired behaviour specified by the MOI is too loose: it permits behaviours that the distributed realisation cannot realise. On the other hand, in the case of the left-most table on the bottom row (protocol ${a}\stackrel{{\scriptstyle{M_{1}}}}{{\Longrightarrow}}{b}~{}\cdot~{}{a}\stackrel{{\scriptstyle{M_{2}}}}{{\Longrightarrow}}{b}$), the protocol is not enactable under RS (except for CM1), but is enactable under SS and under RR. Turning to SR, we observe that it seems to be too weak: almost all the protocols in the figure are enactable (although in most cases only weakly enactable).

Returning to the example from the introduction:

[TABLE]

where $a1\stackrel{{\scriptstyle{M}}}{{\Longrightarrow}}a2$ this example corresponds to the second table from the left in the top row of Figure 1. This shows that, if one desires an $RR$ MOI, i.e. that what is meant by $Canc$ coming before $Res$ is that Bob receives the $Canc$ message before Carol receives the $Res$ message, then the underlying message communication must be $CM1$, $CM2$ or $CM3$, in order for the protocol to be enactable.

4 Discussion

Despite the large amount of work on enactability, very few approaches consider how message ordering and decision structures affect its definition, very few come with an implemented prototype, and none considers the issues raised by the communication model.

Although one motivation might be that it is generally desirable to have robust protocol specifications that are independent of the underlying platform implementation, also ensuring separation of concerns, we observe that robustness could make the protocol too complex, or harder to maintain. Considering what the underlying implementation guarantees w.r.t. communication model, we can relax our specifications, and above all, a protocol that is not enactable in some platform, can be in some other. This makes our work relevant to platform designers, and protocol designers.

Taking all these features into account in a unified semantic-driven way, and demonstrating the potential of the approach on a highly expressive protocol language, are the innovative and original features of this contribution.

Desai and Singh [22] limit their investigation to the RS message ordering interpretation, that they consider the standard of correctness. Hence, despite the nice introduction they provide to other message orderings and to the problems they might raise, the definition of enactability they provide is not parametric in the MOI.

Lanese et al. [17] move a step further, but the generality of their approach is still limited. They define three different notions of enactability, that they name conformance: sender conformance, receiver conformance, and disjoint conformance. That approach is more flexible that the one by Desai and Singh, but less general than ours, where the definition of enactability is parametric in the MOI and does not require different cases. Also, they only consider how sequence and choice are affected by MOIs, leaving the study of other operators for the future. Moreover, when discussing interaction protocols whose most external operator is a choice, they put a very strong constraint for enactability, namely that the agents involved in the two branches of the choice (excluding the agents involved in the choice itself) are the same. We added decision structures to overcome this restriction, and provide a notion of enactability that can succeed even when that constraint is not met.

Neither Desai and Singh, nor Lanese et al., use formalisms for protocol representation as expressive as trace expressions, and neither of them presents experiments obtained from a working prototype, as we do.

With respect to the introduction of decision structures to remove unnecessary restrictions on enactability of protocols when choice is involved, our proposal is similar to that by Qiu et al., [7], as for the other works we have discussed in this section, we implemented our enactability checker, whereas their work only provides definitions. Additionally, our approach is simpler in that we do not need to label the choice operator with agents as they do.

In the future, we will address both theoretical and practical issues. On the theoretical side, we will carry out a systematic analysis of the relationships between Communication Model and Message Ordering Interpretation, to identify those combinations which provide some guarantees by design. We will also consider the relationships between enactability and distributed monitorability [11], as they might turn out to resort to the same definition.

On the practical part, we plan to improve our working prototype to provide a useful tool to assess protocols for enactability. Apart from providing a user-friendly interface, a key issue to address will be to provide a way to isolate the part of a non-enactable protocol that makes it non-enactable. Also, trace expressions are interpreted in a coinductive way [23] to represent infinite traces of events. Since Haskell does not support coinduction, the existing prototype can be only used on acyclic message and interactions protocols. Haskell has been chosen because the implementation mimics the semantics requiring next to no effort. In order to fully implement the proposed features we are planning to develop the enactability check using SWI-Prolog666http://www.swi-prolog.org, which natively supports coinduction. To stress-test the prototype and assess its performance from a qualitative and quantitative viewpoint we plan to create a library of interaction protocols known to be “problematic” w.r.t. enactability, and perform systematic experiments.

Finally, this work highlighted the need of characterising the existing agent infrastructures like Jade [24], Jason [25], Jadex [26], etc, in terms of the communication model they support. This would allow us to state if a protocol is enactable on a given infrastructure, strengthening the potential of our proposal to be exploited in real applications.