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

02/04/2019 ∙ by Angelo Ferrando, et al. ∙ University of Otago University of Liverpool Utrecht University Università di Genova 0

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.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

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 where models the interaction between and for exchanging message , “” models interaction concatenation, and and 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 before she sent , while for AIPbnb it (also) meant that Bob should receive before Carol received . 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 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.

  • (empty trace), denoting the singleton set containing the empty event trace .

  • (event), denoting a singleton set containing the event trace .

  • (concatenation), denoting the set of all traces obtained by concatenating the traces of with those of .

  • (intersection), denoting the intersection of the traces of and .

  • (union), denoting the union of the traces of and .

  • (shuffle), denoting the union of the sets obtained by shuffling each trace of with each trace of (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 , where and 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 (the protocol whose state is modelled by can move to state if occurs), and that if (if the protocol whose state is modelled by can move to state if occurs, then also the protocol whose state is modelled by can).

The denotational semantics is defined as follows:

Where is the set of all interleavings of and , and 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 and gives information on the protocol from the global perspective, collapsing sending and receiving. We say that 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 ( sends ) and ( receives ). 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 takes place before sending of , then reception of must take place before reception of . 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 receives (sent by agent ) and later it receives (sent by agent ), knows that the sending of occurred before the sending of 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 is causally sent before a message then an agent cannot get before . 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 . For the sake of clarity, we denote with , with , with , and with ; 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. , must be received before is sent. The set of traces that respect this model is . This interpretation is named RS (receive before send) in [22] and disjoint semantics in [17].

SS: is sent before is, and there are no constraints on the delivery order. The set of traces that respect this model is . This interpretation is named SS (send before send) in [22] and sender semantics in [17].

RR: is received before is, and there are no constraints on the sending order. The set of traces that respect this model is . 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: is sent before is sent and also is received before is received. The set of traces that respect this model is : both comes before (“coming before” according to the senders), and comes before (“coming before” according to the receivers). This interpretation is named sender-receiver semantics in [17].

SR: is sent before is received. The set of traces that respect this model is . This interpretation is named SR (send before receive) in [22].

It is easy to see that the following inclusions among asynchronous models hold: RS RR & SS SS SR and RS RR & SS RR 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 be the set of possible (asynchronous) communication models, and , SR, RS, RR the set of possible message order interpretations that can be imposed.

We also define to be the set of agents involved in the interaction protocol.

Recall that we consider both interaction and message protocols. When we say that 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 we have that222We use “” to also denote membership of an item in a sequence. , where we define to be the set of interactions involved in the interaction protocol . We also define to be the set of all possible interactions events. Similarly, when is a message protocol (rather than an interaction protocol), it represents sequences of send and receive events of the form (send event) and (receive event), and given a particular set of possible interactions , we define to be the corresponding set of events:

In a message protocol we have that . Given a message protocol we also define 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: . 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:

Message Order Interpretation (MOI).

An interaction protocol defines orderings between messages , whereas a message protocol deals in events (sending and receiving). If a protocol says that comes before , how should we interpret this in terms of events? Should sending come before sending , or does it mean that receiving should occur before receiving ? 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 and returns its semantics in terms of events rather than interactions. The possible sequences of events are constrained: given a situation where specifies that must occur before , 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 be a trace of interaction events, be a trace of send and receive events, a message ordering interpretation, and , two interactions. Abbreviating as and as , we define an order on and for moi in as follows:




where

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 , and then map each sequence 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 . This simple protocol has three sequences of interactions: . Assume an RS message ordering interpretation, then each of the message sequences corresponds to exactly one sequence of events, giving333For readability we use and to abbreviate sending and receiving message , eliding the identity of the agents involved. . However, the protocol does not specify any constraint on , so should also allow other interpretations where the occurrences of and are not constrained relative to the other events, for example .

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 is given as the sequence of sending the message, followed by receiving it (denoted respectively and ). Secondly, the semantics for a sequence is given by taking the semantics of and of . 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 () for all possible final messages of () and all possible initial messages of (). Determining initial and final messages is itself somewhat complex, and is done using partially ordered sets.

A partially ordered set (poset) is a pair where is the set of elements (in this case send and receive events) and is a binary relation on . We define the union operator to act piecewise on posets, and to take the transitive closure of the resulting relation, i.e. . We can then define the of an interaction protocol as follows

Where we define a sequence of two posets by collecting the orderings of each of and , and adding additional ordering constraints between the maximal elements of and the minimal elements of . We can now proceed to define .

Where is the set of all interleavings of and .

Communication Model Semantics.

We formalise the defined communication model semantics by defining for each communication model 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 the constraint is that immediately after each sending event in we have its corresponding receiving event, with nothing in the middle; etc.

We can then apply a particular communication model to an interaction protocol using , and to a message protocol using , which are defined as follows:

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 to denote projecting trace for role .

Where is any operator.

We then define the distribution of , denoted , where involves roles as444We use to distinguish between parallel composition of different agents, and parallel composition within a protocol. This distinction is used later in this section.:

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

where if the information provided by Alice is not satisfactory, Carol tells Alice and asks for new one (recursion on ). 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 as the combination of the two protocols: .

The projection of on each single agent would generate

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 involving, say, three roles , and is enactable iff there exist three protocols , and such that their concurrent interleaving results in the same behaviour as the original protocol. However, when a protocol contains choices () we need to ensure that the occurrences of in each of , and arising from the same in are treated consistently. For example, consider the protocol . This protocol is simple: it specifies that agent can either send a message (“”) to , or it can send a different message (“”) to agent . When we distribute the protocol by projecting it (see Section 3) and forming we obtain the distributed protocol . However, if we interpret each independently (as the semantics would naturally do) then we can have inconsistent choices. For example, we could have where the message is sent by , but does not elect to receive it. So what we need to do is ensure that each of the three occurrences of “” 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 (), 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, can freely choose whether to send or . However, the choice of whether to receive or not is not a free choice, but is forced by ’s earlier choice.

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

In addition to decisions of and , the definition of has a second case (). 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 “” to indicate that a mixed choice is possible. For example, given we have that because .

Where is any operator, and is any operator other than .

We now specify the semantics of a distributed protocol, denoted . 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 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.