An Evaluation of Communication Protocol Languages for Engineering Multiagent Systems

TL;DR

This paper provides a comprehensive evaluation of various modern communication protocol languages for multiagent systems, comparing their features, capabilities, and architectural alignments to guide future research.

Contribution

It introduces evaluation criteria, compares languages based on these criteria, maps findings to system architectures, and proposes design principles for protocol language development.

Findings

Scribble uses session types for protocol specification.

Trace-C and Trace-F utilize trace expressions.

HAPN is based on hierarchical state machines.

Abstract

Communication protocols are central to engineering decentralized multiagent systems. Modern protocol languages are typically formal and address aspects of decentralization, such as asynchrony. However, modern languages differ in important ways in their basic abstractions and operational assumptions. This diversity makes a comparative evaluation of protocol languages a challenging task. We contribute a rich evaluation of modern protocol languages based on diverse approaches. Among the selected languages, Scribble is based on session types; Trace-C and Trace-F on trace expressions; HAPN on hierarchical state machines, and BSPL on information causality. Our contribution is four-fold. One, we contribute important criteria for evaluating protocol languages. Two, for each criterion, we compare the languages on the basis of whether they are able to specify elementary protocols that go to the heart of the criterion. Three, for each language, we map our findings to a canonical architecture style for multiagent systems, highlighting where the languages depart from the architecture. Four, we identify a few design principles for protocol languages as guidance for future research.

Tables

Table 1. Table 1 : Summary of evaluation. The table indicates for each language, whether it fully satisfies (Yes), partially satisfies (Partial), or does not satisfy (No) each criterion.

	Criterion	Scribble	Trace-C	Trace-F	HAPN	BSPL
Information
	Instances	Partial	Partial	Partial	Partial	Yes
	Integrity	No	No	Partial	Partial	Yes
	Social meaning	Partial	Partial	Partial	Partial	Yes
Flexibility
	Concurrency	No	No	No	No	Yes
	Extensibility	No	No	No	No	Yes
Operational environment
	Asynchrony	Yes	Yes	Yes	No	Yes
	Unordering	No	No	No	No	Yes

Full text

We contribute a rich evaluation of modern protocol languages based on diverse approaches. Among the selected languages, Scribble is based on session types; Trace-C and Trace-F on trace expressions; HAPN on hierarchical state machines, and BSPL on information causality. Our contribution is four-fold. One, we contribute important criteria for evaluating protocol languages. Two, for each criterion, we compare the languages on the basis of whether they are able to specify elementary protocols that go to the heart of the criterion. Three, for each language, we map our findings to a canonical architecture style for multiagent systems, highlighting where the languages depart from the architecture. Four, we identify a few design principles for protocol languages as guidance for future research.

1 Introduction

We understand a multiagent system (MAS) as a decentralized system of autonomous agents, each of whom represents a real-world entity such as a person or an organization. In particular, a MAS is not a separate computational entity but is realized purely through its member agents. When a MAS models a collective such as an institution,

the institution can be viewed as an entity that is itself a member of the MAS (Singh, \APACyear2013).

Agents in a MAS coordinate their computations while retaining loose coupling in their construction and decision making.

To accommodate such a conception of a MAS, it is crucial that (1) agents coordinate their computations via arms-length communication, that is, via asynchronous messaging, and (2) the coordination requirements be clearly specified and support a programming model that facilitates the construction of agents.

The foregoing twin requirements have motivated an extensive study of languages for specifying communication protocols. Broadly, a communication protocol specifies the coordination in a MAS by specifying two or more interacting roles, the messages (that is, message schemas) exchanged by these roles, and the conditions under which agents playing those roles may send (instances of) the various messages to one another. Further, a protocol yields a programming interface (skeleton) for every agent such that if an agent implements its interface, then the agent is compliant. Compliance with the stated protocol is the primary correctness criterion for individual agents: If all agents complied, then the desired coordination between them would obtain.

For concreteness, Use Case 1 describes a protocol informally.

Use Case 1** (Purchase)**

A buyer requests an item from a seller, who responds with an offer. The buyer may accept or reject the offer. If the buyer accepts the seller’s offer, the seller delivers the specified item to the buyer, following which the buyer sends the specified payment to the seller.

For Use Case 1, the roles would be buyer and seller. The messages would be Request, Offer, Reject, Accept, Payment, and Deliver. And, buyer may send Request, Accept, Reject, and Payment, and seller may send Offer and Deliver. Each message contains the information relevant to that message (presumably capturing what that message connotes in the protocol). For example, Request contains the item and Offer contains the price. We identify additional constraints from Use Case 1: Offer concerns the same item as specified in Request; and, Payment specifies the same amount as the price in Offer.

The notion of protocol is naturally a foundational one for multiagent systems. Following Hewitt (\APACyear1991), Gasser (\APACyear1991) identifies protocols as one of the central challenges for MAS. Protocols are central to work on agent communication languages (FIPA, \APACyear2002; Vieira \BOthers., \APACyear2007); on institutions, e.g., (d’Inverno \BOthers., \APACyear2012); and on agent-oriented software engineering (AOSE) methodologies such as Gaia (Zambonelli \BOthers., \APACyear2003), Tropos (Bresciani \BOthers., \APACyear2004), and Prometheus (Padgham \BBA Winikoff, \APACyear2005).

The centrality of protocols has spurred work on protocol specification languages and approaches. Agent UML (AUML) (Odell \BOthers., \APACyear2001), an early graphical notation for specifying protocols that extends UML, is applied in Tropos and Prometheus and by FIPA for specifying interaction protocols (FIPA, \APACyear2003).

Inspired from problems in telecommunications networks and UML, Message Sequence Charts (ITU, \APACyear2004) was another early standardization of a protocol notation.

Problem

From modest beginnings in informal notations based on UML, work on protocol languages has grown to encompass a number of sophisticated—and in some cases, complicated—formal approaches that boast diverse basic abstractions and operational assumptions. For example, the abstractions employed include state machines (Baldoni \BOthers., \APACyear2006; Winikoff \BOthers., \APACyear2018), logic-based constraints (Baldoni \BOthers., \APACyear2013), action descriptions (Desai \BBA Singh, \APACyear2008\APACexlab\BCnt1), trace expressions (Castagna \BOthers., \APACyear2012; Ferrando \BOthers., \APACyear2019), session types (Yoshida \BOthers., \APACyear2013), and information constraints (Singh, \APACyear2011\APACexlab\BCnt1). Operational assumptions range from synchronous communication (Winikoff \BOthers., \APACyear2018), to asynchronous but pairwise FIFO communication (Castagna \BOthers., \APACyear2012; Yoshida \BOthers., \APACyear2013), to unordered asynchronous communication (Singh, \APACyear2011\APACexlab\BCnt1).

The rich diversity of languages for specifying protocols raises an important question: how may we compare and evaluate them? Today, we lack generally clear evaluation criteria and use cases for protocol languages that would enable us to evaluate them on conceptual grounds. And yet, there is a general belief in the research community that

existing languages can largely tackle the challenges of building multiagent systems.

Contributions, Novelty, and Significance

We posit that current languages, illustrating the established paradigms, largely do not support the engineering of decentralized multiagent systems.

In support, we contribute a conceptual evaluation of protocol languages with respect to decentralization.

More specifiically, our contributions in this paper are the following.

First, we provide evaluation criteria for protocol languages that are informed by decentralization. The criteria have to do with how well a language supports specifying flexible interactions; whether a language enables expressing the appropriate information constraints; and the assumptions (demands) a language makes of a MAS’s operational environment.

Second, we undertake a comparative evaluation of selected protocol languages against the aforementioned criteria. The selected languages are modern, diverse, and prominent. An important feature of our evaluation is our reliance on “minimal” use cases for protocols that help bring forth the distinctions between the languages. Specifically, for each criterion, we take realistic use cases that go to its heart and specify them as best possible in each of the selected languages. We then analyze each resulting protocol specification for validity according to the semantics of the language it is specified in. Following this methodology, we show that several of the selected languages fall short of what is required to support decentralization.

Third, we identify the architectural assumptions underlying the selected languages and discuss how they map to MAS architecture.

Fourth, we posit principles for engineering MAS and discuss how the languages fare against them. No unitary perspective states that a protocol must not specify orderings of events from a unitary perspective. Noninterference and the end-to-end principle for protocols both concern layering. Noninterference states that a protocol must not interfere with agent reasoning. The end-to-end principle states that a protocol can be fully and correctly implemented only in agents, not in the infrastructure. Relying on infrastructure for correctness (e.g., via FIFO message delivery) may be inadequate and unnecessary for correctness. The end-to-end principle for protocols derives from the more general end-to-end principle for system design (Saltzer \BOthers., \APACyear1984).

This paper’s significance lies in bringing forth the information models, semantics, and architectural assumptions underlying protocol languages as they relate to decentralization. Doing so not only provides a conceptual framework for understanding protocols and protocol languages but also clarifies requirements for MAS and yields guidance on research into protocol languages. Its novelty arises from the absence, currently, of such a framework. Notably, this paper focuses on essential representational criteria for protocols and plays down contingent features such as current tool support and popularity.

We use the following notational conventions throughout (except in listings and figures). We use small caps for role names; Slant for protocol and message names; sans serif for parameter names; and teletype for parameter values.

Organization

The rest of this paper is organized as follows. Section 2 introduces protocols as an architectural abstraction for MAS. Section 3 introduces the selected approaches we analyze at depth in this paper. The paper then motivates each criterion and studies how the selected languages fare. Section 4 evaluates the languages for concurrency and extensibility, as important aspects of flexibility; Section 5 for protocol instances, integrity, and social meaning, as important aspects related to the information exchanged in protocol enactments; and Section 6 for assumptions about the operational environment for protocol enactment. Section 7 teases out the architectural models underlying the various languages and compares them to the canonical MAS architecture, as presented earlier. It also presents broad principles for protocol languages and evaluates the selected languages against them. Section 8 summarizes the overall evaluation in the context of alternative evaluations in the literature. It ends with a discussion of future directions.

2 Multiagent Systems Architecture

A protocol is an architectural abstraction and therefore any evaluation of protocol languages must start with a clear understanding of MAS architecture. Below, we present a canonical architectural style (Shaw \BBA Garlan, \APACyear1996) for MAS, clearly indicating its components, assumptions, and constraints. The idea is that any concrete instantiation of the architecture must satisfy constraints but without making stronger assumptions.

Strictly speaking, agents and roles are distinct categories (an agent may play several roles and a role may be played by several agents). For expository convenience, and to focus on other concerns in this paper, we assume that any role is played by a single agent and distinct roles are played by distinct agents. This assumption enables us to identify an agent with the role it plays. From here on, we talk primarily of agents and deemphasize roles.

As Figure 1 depicts, each agent represents an autonomous principal, for example, a human or an organization. An agent internally encodes the private decision making of its principal, including any private knowledge bases that it relies upon for decision making. We elide principals in the later figures.

In general, to achieve interoperation, the interoperating parties must agree at multiple levels (Singh \BBA Huhns, \APACyear2005). Here, the protocols focus on the operational level, which concerns the exchange of information (i.e., reflected in constraints on the ordering and occurrence of messages). In particular, we set aside both low-level concerns such as how the information is encoded and high-level concerns as to the meaning of the information exchanged—though we insist that protocols be able to support a flexible representation of meaning.

An agents sends and receives messages via a communication infrastructure. An agent’s observations are its message emissions and receptions. For simplicity and in accordance with the literature, we assume that agents make observations serially (Hewitt, \APACyear1977; Agha, \APACyear1986; Fagin \BOthers., \APACyear1995). An agent’s history is the set of its observations. Technically, an agent complies with a protocol if and only if all of its observations are correct with respect to the protocol. Constraints 1 and 2 addresses the correctness of emissions and receptions, respectively.

Constraint 1** (Emission correctness)**

The correctness of a message emission by an agent may be determined from the agent’s history.

Constraint 1 rules out reliance on any kind of state other than the history for purposes of determining the correctness of emissions. In particular, it rules out reliance on (1) the global state, which may include what the agent has not observed; (2) the future state of an agent, because any decision should respect causation; and (3) an agent’s internal state, for example, as encoded in its beliefs (Singh, \APACyear1998).

Constraint 2** (Reception correctness)**

The reception of any message that was emitted correctly is correct.

Constraint 2 captures the intuition of respecting the structure of causality. Specifically, if the reception of a message would be incorrect, then that message ought never to have been sent. Otherwise, the recipient would enter a “corrupted” state from which there is no recourse. The only alternative would be for the infrastructure to intervene and prevent a message reception that would be erroneous, but doing so would customize the infrastructure to include application-specific details, in contravention of the famous end-to-end principle (Saltzer \BOthers., \APACyear1984), which advocates generality in the infrastructure.

Constraints 1 and 2 imply that agents need no more than an asynchronous communication infrastructure, as captured by Constraints 3 and 4.

Constraint 3** (Asynchrony: Nonblocking

emission)**

Sends are nonblocking, meaning that when an agent sends a message, it does not synchronize with the receiver on the sending action.

Constraint 4** (Asynchrony: Anytime reception)**

An agent receives a message when it is delivered by the infrastructure. That is, message reception is nondeterministic.

Of course, an agent being autonomous may choose not to act on a message it has received but the reception itself occurs due to the infrastructure.

Asynchrony promotes loose coupling between agents. Notably, programming paradigms for building distributed systems such as the actor model (Hewitt \BOthers., \APACyear1973; Hewitt, \APACyear1977; Agha, \APACyear1986) give prominence to asynchronous messaging for organizing decoupled computations. Practical communication infrastructures such as the Internet support asynchronous messaging. In fact, asynchrony is the only viable option in the important setting of the Internet of Things (IoT) (XMPP, \APACyear2015; OASIS, \APACyear2014; Shelby \BOthers., \APACyear2014).

Assumption 1** (Infrastructure

guarantees)**

The infrastructure is noncreative; that is, only sent messages are received. Further, the infrastructure does not deliver corrupt messages.

Notice that Assumption 1 does not say that a sent message be also received. Indeed, messages may be lost in transit. Some applications of MAS may require messages to be delivered; the analysis in this paper however does not rely upon such an assumption. Also notice that no message delivery order was assumed. Constraint 2 means no such assumption is required for purposes of correctness.

Constraint 5** (Fullness)**

A protocol fully specifies a multiagent system at the operational level.

Conceptually, as stated above, a protocol specifies the constraints on the operational level, i.e., on the information exchange.

Constraint 5 states that nothing else besides a protocol is needed to characterize a MAS at the operational level. That is, this constraint rules out reliance on extra-protocol mechanisms, such as agreements about when to send or not send certain messages. Such extra-protocol mechanisms would amount to hidden coupling between the agents: agents who were developed to interoperate in accordance with such mechanisms would not interoperate with agents who were developed to in accordance solely with the protocol. Constraint 5 means that Figure 1 captures a MAS fully from the standpoint of coordination.

Figure 2 elaborates on the architecture of Figure 1 by refining an agent into two components: protocol filter and reasoner.

An agent’s protocol filter ensures compliance. The filter interfaces with the communication infrastructure to send and receive messages. And it interfaces with the reasoner to notify the reasoner of observations of interest and to accept message emission requests. The filter materializes the agent’s history and uses it to check for correctness any message that the reasoner requests it to send. If the message is correct, the filter sends the message on the infrastructure (and records the emission as an observation in the history). If the message is not correct, the filter discards the message with the indication of an exception to the reasoner (and does not change the history). The filter is a form of generic protocol-based control on the reasoner (Banihashemi \BOthers., \APACyear2016, \APACyear2018).

In principle, the filter may have to deal with the incorrect reception of a message if the message were incorrectly sent. For simplicity, let’s assume that agents do not send incorrect messages, even when they are not equipped with a filter.

An agent’s reasoner encodes the decision making of its principal. The reasoner determines how an agent processes events, both private (e.g., an update to an internal knowledge base) and observations recorded by the filter. The processing of an event may require the emission of a message, for which the reasoner relies on the filter. For example, referring to Use Case 1, buyer’s reasoner, upon being notified by an internal database that a particular item was out of stock, may ask the filter to send a Request for that item to seller. If the Request is correct, the filter sends it to seller. seller’s reasoner, when notified by its filter of the reception of the Request, may determine by looking up its internal price list, that an Offer for the requested item should be sent for some price. And so on.

The architecture in Figure 3 further refines the architecture in Figure 2 by introducing a declarative specification of the social meaning of an interaction (Singh, \APACyear1998) and a runtime for the language in which meaning is specified, namely, the meaning computer. The meaning specification takes an agent’s observations as the base-level social events and maps combinations of social events to higher-level social events.

Constraint 6 defines what may be considered a social event.

Constraint 6** (Social)**

A social event is either an observation or is inferred from other social events (Chopra \BBA Singh, \APACyear2016).

Constraint 6 means that a social event cannot feature any information that does not show up in an observation (of a message, as defined earlier). Internal events that reflect updates to an agent’s internal state (e.g., its beliefs) have no effect on the computation of social events (Singh, \APACyear1998).

Social meaning is essential to the application-specific correctness of MAS. A MAS for financial loans may model social meaning via abstractions for debt, collateral, default, and so on. For example, from events corresponding to the issuance of a loan and a payment against the loan, a new debt event could be inferred that reflects the outstanding debt. Further, were the outstanding debt to be zero, it could lead to the inference of a new repaid event. In like manner, a MAS that supports a community of toy train enthusiasts could model social meaning via abstractions for the provenance, ownership, and desirability of a toy train.

In MAS research, social meaning is often modeled via commitments (Yolum \BBA Singh, \APACyear2002; Fornara \BBA Colombetti, \APACyear2002; Bentahar \BOthers., \APACyear2004; Winikoff \BOthers., \APACyear2005; Dastani \BOthers., \APACyear2017; Meneguzzi \BOthers., \APACyear2018; Telang \BOthers., \APACyear2019) and other norms (Artikis \BOthers., \APACyear2009; Padget \BOthers., \APACyear2018; Alechina \BOthers., \APACyear2018). In the rest of the paper, for reasons of concreteness and familiarity, we use commitments as an exemplar way of modeling social meaning. Use Case 2 illustrates the use of commitments to capture meaning.

Use Case 2** (Deliver-Payment Commitment)**

In the context of purchase in Use Case 1, the meaning of an Accept from seller to buyer for some item for some price is that it creates a commitment from buyer to seller that if seller Delivers the item by some (specified) deadline, then buyer will make a Payment of the price by some (specified) deadline.

3 Overview of Selected Approaches

For this evaluation, we select protocol specification languages that are recent, have a formal semantics, and represent diverse doctrines. AUML notably is not in our selection: neither is it recent nor does it have a satisfactory formal semantics. AUML is closely related to UML Sequence Diagrams, which too lacks a formal semantics. Some of the selected languages though adopt important intuitions behind AUML, including the idea of specifying an interaction as a control flow of messages and using a graphical notation. One might argue that some of the languages we discuss (Scribble and Trace-F) seek to clarify intuitions that undergird AUML and to provide a formal semantics.

Below, we introduce the main ideas of the selected languages by specifying Use Case 1.

3.1 Multiparty Session Types: Scribble

Scribble (Yoshida \BOthers., \APACyear2013) is a practical instantiation of multiparty session types (Honda \BOthers., \APACyear2016). In Scribble, a protocol is an ordering of constituent protocols (bottoming out at individual message specifications) using constructs such as sequence, choice, and recursion. Scribble assumes that communication between pairs of participants is asynchronous but ordered over FIFO channels.

Listing 1 gives an encoding of Use Case 1 as a Scribble protocol. In the listing, a semicolon (;) indicates sequencing.

Given a protocol, Scribble yields projections, called local protocols, for each agent. (We retain the term “projection” to avoid conflict with “protocol.”) The idea is that the protocol represents computations from a unitary perspective whereas an agent’s projection represents computations from its own local perspective. Scribble’s tools (Scribble, \APACyear2018) may be used to generate these projections. We have used the tooling to verify all Scribble specifications presented in this paper.

Listing 2 gives the projections for each of the agents in the Purchase protocol in Listing 1. buyer’s projection says: send Request to seller, then receive Offer (from seller), then send either Accept or Reject. If Accept is sent, then receive Deliver and then send Payment. seller’s projection is read in an analogous manner.

Notice that in the protocol the choice between Accept and Reject is indicated as buyer’s. Therefore, in the projections, the choice is interpreted as an internal choice for buyer and as an external choice for seller. The agent with an internal choice chooses from the available alternatives autonomously. The agent with an external choice does not choose but follows along. The internal choice determines the external choice. Thus, if buyer chooses to send Accept (alternatively, Reject), its reception resolves the seller’s choice to receive Accept (alternatively, Reject).

The notion of realizability ties together a protocol and its projections. A protocol is realizable if and only if the agents acting locally based on their projections jointly realize exactly the computations of the protocol (as we shall see, this is not always the case). The Purchase protocol in Listing 1 is realizable.

3.2 Trace-C

Castagna \BOthers. (\APACyear2012) describe a language for specifying protocols that is based upon trace expressions, which we refer to as Trace-C. A trace is a sequence of communication events. In Trace-C, each expression maps to a set of traces. The expression x\raisebox{-2.0pt}{\xrightarrow{\text{m}}}y is atomic; it denotes the communication of message $m$ from $x$ to $y$; and it maps to the following set of traces containing just one trace: $\{m\}$. The ; operator denotes sequential composition; the expression $e;f$ is the concatenation of the traces of $e$ with the traces of $f$. The $\mathbf{\lor}$ operator denotes choice; the expression $e\lor f$ is the union of traces of $e$ and the traces of $f$. The $\mathbf{\land}$ operator denotes the shuffle of its operands; the expression $e\land f$ is the set of those traces that represent an interleaving of a trace of $e$ with a trace of $f$. Like Scribble, Trace-C assumes FIFO-based asynchronous communication.

Listing 3 shows how Use Case 1 may be rendered in Trace-C. Although the Trace-C specification appears more algebraic than Scribble, we can see that they are structurally similar once we realize that the choice operator in Scribble corresponds to the $\lor$ operator in Trace-C.

Like in Scribble, a Trace-C protocol yields projections for each agent. Listing 4 gives the projections for Purchase in Listing 3. In the projections, $\mathbf{\oplus}$, +, and ; denote internal choice, external choice, and sequence, respectively; agent!Message and agent?Message, respectively, denote the emission of Message to agent and the reception of Message from agent. The projections are structurally similar to those of Purchase in Scribble, even though the syntax is different. Notice that buyer’s choice is internal and seller’s external, meaning that although seller could receive either Accept or Reject, the choice of what it receives depends on what buyer sends. The protocol is realizable.

3.3 Trace-F

Ferrando \BOthers. (\APACyear2019) describe a trace expressions-based language for specifying protocols, which we refer to as Trace-F. It builds upon earlier work on monitoring decentralized MAS (Ferrando \BOthers., \APACyear2017). Trace-F, like Trace-C, features operators for sequence, choice, and shuffle.

In Trace-F, shuffle is represented $\mathbf{|}$; however, for uniformity with Trace-C, we use the Trace-C representation for shuffle, that is, $\mathbf{\land}$.

With this simplification, the protocol in Listing 3 serves as a specification of Use Case 1 in Trace-F.

The projections generated by Trace-F for Listing 3 though are different from the projections produced by Trace-C as shown in Listing 4. Specifically, in Trace-F, the choice in the protocol does not reduce to internal and external choice in the projections for buyer and seller. Instead, the choice is preserved in the projection and the distinction between internal and external choice is captured semantically in a decision structure. In general, Trace-F preserves all binary operators used in a protocol in the projections.

Ferrando \BOthers. (\APACyear2019) introduce two dimensions of variation in reasoning about the realizability (which they term “enactability”) of a protocol. One dimension concerns the communication infrastructure—whether it is asynchronous or synchronous and if it is asynchronous what kind of ordered delivery guarantees it offers. Out of the other approaches evaluated in this paper that support asynchrony, none requires stronger ordering guarantees than FIFO delivery. Hence, the interesting cases for Trace-F, for our purposes, are asynchrony without any kind of ordered delivery, which we refer to as unordered asynchrony, and asynchrony with FIFO delivery, which we refer to as FIFO asynchrony.

The other dimension that Ferrando \BOthers. (\APACyear2019) introduce (drawing upon (Desai \BBA Singh, \APACyear2008\APACexlab\BCnt2)) concerns how the sequence operator is interpreted in terms of the observations of events. Take the protocol in Listing 6.

Under the send before send (SS) interpretation, w must send p before w sends q. Under the send before receive (SR) interpretation, w must send p before y receives q. Under the receive before send (RS) interpretation, x must receive p before w sends q. And, under the receive before receive (RR) interpretation, x must receive p before y receives q.

Whether a protocol is realizable depends on the communication infrastructure and the interpretation of the sequence operator. For concreteness, let’s consider the protocol in Listing 6 under unordered asynchrony. The protocol is realizable with either SS (w being the sender of both p and q can ensure that p is sent before q) or SR (from the fact that the protocol is realizable under SS and the emission of a message must be prior to its reception). However, the protocol is realizable neither under RS (w has no way of knowing when x has received p, so it cannot ensure that q will be sent after the reception of p) nor under RR (since the receivers are different, there is no way to ensure that q will be received after the reception of p). Changing the interpretation to FIFO asynchrony makes no difference (because the receivers of p and q are different).

To see how the choice of communication infrastructure makes a difference, consider the protocol in Listing 7. Notice that both p and q are messages from w to x. Under unordered asynchrony and with the RR interpretation, the protocol is unrealizable (there being no way to guarantee that p will be received before q). However, under FIFO asynchrony and the RR interpretation, the protocol is realizable (p is sent before q, so p is also received before q).

3.4 HAPN

HAPN (Winikoff \BOthers., \APACyear2018) is a graphical protocol language that supports nested state machines in a manner similar to statecharts (Harel, \APACyear1987). As Figure 4 shows, nodes represent states or reference other protocols to compose those protocols. Edges can have complex annotations, supporting the specification of message transmissions, guard expressions, and changes to the state. HAPN specifies the enactments of a protocol in terms of state machines. It assumes synchronous communication (Winikoff \BOthers., \APACyear2018, p. 61) and does not give a method for projecting a protocol to local perspectives (though Winikoff \BOthers. acknowledge the need to develop such methods).

HAPN provides methods to flatten a hierarchical protocol into simple protocols and finite state machines for verification.

3.5 BSPL

BSPL (Singh, \APACyear2011\APACexlab\BCnt1, \APACyear2012), the Blindingly Simple Protocol Language, and Splee (Chopra \BOthers., \APACyear2017), which extends BSPL, are exemplars of information-based languages. Instead of specifying the control flow between messages, BSPL specifies information causality and integrity constraints.

Listing 8 shows the Purchase protocol in BSPL. It specifies a set of roles, a set of parameters, and a set of messages. In Purchase, the roles are buyer and seller; the parameters are ID, item, price, decision, and OK; and message schemas are Request, Offer, and so on. Request is a message from buyer to seller and has parameters ID and item. BSPL is declarative; the order in which the messages appear in a protocol is irrelevant to how the protocol may be enacted.

A BSPL protocol may be viewed as an information object as described by the protocol parameters, at least one of which is annotated $\mathsf{key}$. The $\mathsf{key}$ parameters enable identifying instances of the protocol: distinct bindings for the key parameters identify distinct instances of the protocol. Purchase specifies ID as its key parameter. A key parameter of the protocol is also a key parameter of the messages in which it appears and enables identifying distinct instances of messages. Parameter ID is key for all messages in Purchase. Protocol instances are related to protocol enactment: A protocol instance is a view over correlated (by bindings of common keys) message instances. For example, an emission of Request with ID 1 and item fig yields a protocol instance with ID 1 and item fig.

A protocol instance must satisfy integrity, which is the idea that no two message instances that are correlated with the protocol instance may conflict on (that is, have different bindings for) any parameter—this is the meaning of a key. Thus for example, a Request with ID 1 and item fig and an Offer with ID 1 and item jam would violate integrity: ID 1 may either be associated with item fig or item jam, but not both.

For any instance, causality constraints specify information flow and are expressed via $\ulcorner\mathsf{in}\urcorner$ and $\ulcorner\mathsf{out}\urcorner$ adornments on parameters (we omit discussion of the $\ulcorner\mathsf{nil}\urcorner$ adornment since it does not feature in any BSPL specification in the present paper). Ordering between messages falls out of these constraints. To see how, consider Request. In Request, both ID and item are adorned $\ulcorner\mathsf{out}\urcorner$, meaning that in sending a Request, buyer produces bindings for ID and item. When seller receives the Request, it comes to know those bindings unless it knew them already. In Offer, both ID and item are adorned $\ulcorner\mathsf{in}\urcorner$, meaning that seller needs to know these parameters before seller can send Offer. This means that if seller has seen Request before, it can send Offer by producing a binding for price. When buyer receives Offer, it may send either Accept or Reject since it knows the bindings of ID, item, and price and it may produce a binding for address (which features in Accept but not Reject), decision and OK (which features in Reject but not Accept). It cannot send both Accept and Reject though because both messages produce a binding for decision, and integrity requires a parameter to have at most one binding. When seller receives Accept, it knows address and therefore may send Deliver by producing a binding for dropOff. Upon reception of Deliver, buyer knows dropOff, and therefore, it can send Payment by producing a binding for OK.

A tuple of bindings for a protocol’s parameters corresponds to a complete protocol instance. That is the motivation for Purchase being designed such that Reject features OK but Accept does not. On the Accept branch, the protocol completes with Payment.

Unlike the languages introduced earlier, BSPL does not give the computations of a protocol from a unitary perspective. Instead, it takes an inherently decentralized perspective. Any computation of a protocol is a vector comprised of a history for each agent. However, the vector is conceptual (not materialized anywhere). To be able to correctly enact a protocol, an agent needs no more than its history. Therefore projections are trivial in BSPL.

BSPL works with asynchronous communication without any ordering guarantees.

4 Flexibility

Does a language support specifying flexible protocols? Being able to interact flexibly is supportive of autonomy (Yolum \BBA Singh, \APACyear2002). However, flexibility is in tension with decentralization: Independently-constructed agents deciding locally must still be able to interoperate. Below, we discuss concurrency and extensiblity, two aspects of flexibility.

Below, we denote enactments via sequence diagrams, as in Figure 5, where each agent’s lifeline captures its history.

4.1 Concurrency

Does a language enable protocols in which agents may emit and receive messages concurrently? Consider 3.

Use Case 3** (Flexible purchase)**

buyer* sends Request to seller to ship some item. After sending Request, buyer may send Payment. After receiving Request, Seller may send Shipment. That is, Payment and Shipment are not mutually ordered.*

Figure 5 shows some possible enactments for Use Case 3.

Listing 9 serves as a protocol specification in both Trace-C and Trace-F that prima facie captures Use Case 3 by not mutually ordering Payment and Shipment.

To understand what enactments are supported by the protocol in Listing 9, following Trace-C (Castagna \BOthers., \APACyear2012, p. 14), we eliminate $\land$ from the protocol to obtain the equivalent protocol in Listing 10. Trace-C determines the protocol in Listing 10 as unrealizable.

Let’s see why. Listing 11 gives the projections that Trace-C yields for Listing 10. The choice (denoted by $\lor$) in the protocol must be interpreted as external choice (denoted $+$) for one agent and internal choice (denoted $\oplus$) for the other. An agent with an internal choice can choose autonomously. An agent with an external choice cannot; its choice is determined by the internal choice of another agent. In Listing 11, buyer has the internal choice and seller the external choice (it wouldn’t matter to our analysis if it were the other way around since the situation is symmetric).

Given the projections in Listing 11, if buyer chooses to send Payment, when Payment reaches seller, it effectively determines the choice to receive Payment by seller. Such an enactment realizes the protocol trace where Payment happens before Shipment, so no problem here. However, if buyer chooses to receive Shipment, seller must send it. The seller could send Shipment if it knew of buyer’s choice or it could act autonomously. However neither is a possibility. Constraint 5 rules out covert communication and synchronization and therefore rules out the possibility of the seller learning of buyer’s choice. As seller’s choice is internal, it cannot send Shipment autonomously. This means the system is deadlocked, which leads Trace-C to conclude that the protocol is unrealizable. The situation where agents must make mutually compatible choices to ensure correctness is known as nonlocal choice (Ladkin \BBA Leue, \APACyear1995).

Listing 12 shows the projections in Trace-F for the protocol in Listing 9. Under both unordered and FIFO asynchrony, the protocol is determined unrealizable by Trace-F, no matter what interpretation is chosen for the sequence operator. The reason behind the rejection is the same reason the Trace-C protocol above is rejected: a nonlocal choice that cannot always be made in a mutually compatible manner by the agents.

Listing 13 shows how we might model Use Case 3 in Scribble. For the same reasons as for Trace-C, the protocol in the listing is determined unrealizable by Scribble.

Some research branches of Scribble (Demangeon \BOthers., \APACyear2015) have included a parallel operator, which however is absent from the main Scribble language and implementation. We hypothesize that a parallel operator would manifest as a problematic nonlocal choice. Our hypothesis is based on the fact that Trace-C’s $\land$ operator is in essence a parallel operator and as we showed in the analysis of flexible purchase in Trace-C, $\land$ manifests as a problematic nonlocal choice in the projections.

Figure 6’s HAPN protocol captures only the first two enactments of Figure 5, not the concurrent one because HAPN requires synchrony.

Listing 14 gives a BSPL protocol. It supports the enactment in Figure 5(c) because after buyer sends Request, it has the information needed to send Payment and, upon receiving Request, seller has the information needed to send Shipment. The protocol also supports the enactments in Figures 5(a) and 5(b).

4.2 Extensibility

Is the protocol language such that an agent may participate in multiple, potentially unrelated protocols specified in it? If the answer is yes, we refer to the language as extensible. Technically, extensibility means that an agent may interleave observations of messages from several protocols and yet be compliant with each of them. If an agent may participate in only one protocol, that is, observe messages from only one protocol, then the language is nonextensible.

Extensibility is a practical necessity. For example, an organization as an agent may interact with other organizations using one protocol but interact with its own members using another protocol. Further, nonextensibility would be an undue restriction on an agent’s design and therefore its principal’s autonomy.

As basic a requirement as extensibility appears to be, we show below that several languages are in fact not extensible.

Use Case 4** (Pricing+Catalog)**

seller* and buyer engage in the Pricing protocol, by which a buyer may obtain offers for requested items from seller. In addition, seller engages with provider via the Catalog protocol to obtain information about the newest products. Further, buyer is unaware of Catalog and provider is unaware of Pricing, indicating that these protocols are not composed into a single protocol.*

Figure 7 shows an enactment of Use Case 4 in which the messages of Pricing and Catalog are interleaved. In particular, notice that seller observes messages from both protocols. There is nothing in the enactment that tells us it should be deemed incorrect. Such enactments would in fact be indicative of flexibility. If a protocol language were not extensible, then enactments such as the one in Figure 7 would be deemed incorrect.

Trace-C’s semantics is in tension with extensibility. Listings 15 gives the specifications of Catalog and Pricing in Trace-C. Castagna \BOthers. (\APACyear2012, p. 3) promote a correctness criterion fitness with respect to a protocol, which says that an agent correctly implements (fits) a protocol only if it observes no message that is not in the protocol. Castagna et al. give the example of a protocol in which seller may send buyer messages corresponding to price and descr (of an item) and say that a seller that sent any message other than price and descr would violate the protocol. Naturally, it follows that if an agent observes messages from two or more Trace-C protocols, then it correctly implements none of those protocols. In essence, fitness limits agents to implementing a single protocol.

Returning to our example, Trace-C says that to correctly implement Pricing, seller must not observe any message from Catalog and to correctly implement Catalog, seller must not observe any message from Pricing. An agent that engages in both Pricing and Catalog violates both.

A possible way to interleave interactions from two protocols in Trace-C is to compose them into a single protocol, which an agent can potentially fit. Listing 16 shows a composition of Pricing and Catalog. The fitness of seller with respect to the composed protocol is thus a possibility. However, there are significant drawbacks to requiring explicit composition just for the sake of fitness. First, it would create large unwieldy protocols with potentially unrelated communications and introducing otherwise unrelated agents into the MAS just because they are reachable from each other based on their interactions with common agents. Second, when protocols are large and unwieldy, projections for agents and their implementations would become correspondingly complicated. Third, it would prevent any organizational abstraction. For example, the protocol by which an organization trades with others will have to be composed with all the protocols pertaining to interactions internal to the organization, which would be undesirable. Fourth, the composite protocol may turn out to be unrealizable anyway. Consider Listing 16, which gives a protocol, Pricing+Catalog, that composes Pricing and Catalog. This protocol is unrealizable. The reason is that the protocol sets up a problematic nonlocal choice (seller sends Query or buyer sends Request).

Based on the foregoing analysis, we conclude that Trace-C does not support extensibility. Considering the seller’s projections for Pricing and Catalog, given in Listing 17, helps see the point intuitively. If you consider the projection from Pricing, the only trace that satisfies projection is Request followed by Offer. In particular, no trace with Query or Newest satisfies the projection from Pricing. By an analogous argument, no trace with Request or Offer would satisfy the projection from Catalog.

Following an analogous line of reasoning, we can see that Trace-F and Scribble do not support extensibility either: Pricing and Catalog yield projections for seller, none of which entertains traces with events from the other (in fact, the projections in Listing 17 double as projections in Trace-F as well). HAPN’s state-machine semantics rules out interleavings with other protocols. Therefore, HAPN too does not support extensibility.

The underlying reason Trace-C, Trace-F, Scribble, and HAPN come up short on extensibility is they all implicitly identify the universe of discourse (the messages that agents may observe) with the messages specified in the protocol.

BSPL supports extensibility. In fact, BSPL refers to a universe of discourse, which for an agent would include any messages it observes, regardless of the protocols they feature in. Any message schema is an elementary protocol is BSPL and determining the correctness of an observation of the message depends on the causality and integrity constraints specified in the schema. Correctness does not depend upon the protocol in which a message schema occurs. Listing 18 and Listing 19 specify Pricing and Catalog, respectively, in BSPL. The role seller features in both protocols and interleaves observations of messages from both protocols.

5 Information Modeling

Does a language enable capturing the information model underlying the interactions in a MAS? Further, does the information model captured in a protocol specification enable computing social meaning correctly?

It is the information conveyed via messaging that enables coordination in a MAS.

Such information has a model, starting with constraints such as would be captured in a message schema, e.g., to capture message instances, and extending to constraints between message schemas in a protocol specification, e.g., to capture correlation and integrity in protocol enactments, which may be viewed as groups of message instances. Further, due to Constraint 6 states, since a meaning-level event is computed as a view over one or more protocol events, the soundness of

information at the meaning-level relies on the soundness of information generated in protocol-level events.

We elaborate below on protocol instances and the integrity of information as a lead up to social meaning.

5.1 Protocol Instances

A practical requirement is that a protocol, being a pattern of communication, may be instantiated several times. We refer to each instantiation as a protocol instance that would be comprised of some appropriately correlated messages. How well do protocol languages support protocol instances? Consider Use Case 5.

Use Case 5** (Concurrent Pricing)**

A buyer and seller may engage in several, possibly concurrent engagements, in each of which a buyer sends a request for some item and the seller responds with an offer.

Figure 8 illustrates some enactments involving two instances of the pattern in Use Case 5. The messages contain identifiers (1 and 2) to help distinguish the instances from each other and to correlate messages within an instance.

Listing 20 gives a candidate Scribble protocol capturing Use Case 5. Notice the recursion, which crucially enables buyer and seller to engage repeatedly in the pricing pattern of Use Case 5. However, each pricing engagement must happen in its entirety before another can start; that is, the protocol does not allow interleaving of multiple pricing engagements. Thus, although the protocol supports the enactment of Figure 8(a), it excludes the enactments of Figures 8(b) and 8(c). The enactment of Figure 8(d) is also excluded but for a different reason: it violates FIFO, which is a requirement for Scribble.

Listing 21 gives a Trace-C protocol for Use Case 5. Here, the ∗ means that the enclosed pattern may be repeated zero or more times. As for Scribble, each iteration must complete before another can begin, thereby excluding the enactments of Figures 8(b) and 8(c) due to the semantics of the language and excluding Figure 8(d) due to the FIFO requirement.

Listing 22 gives a recursive Trace-F protocol for Use Case 5. As for Scribble and Trace-C, each iteration must complete before another can begin, thereby excluding the enactments of Figures 8(b) and 8(c) due to the semantics of the language. Under unordered asynchrony, the protocol is unrealizable because the enactment in Figure 8(d) may occur but the protocol cannot handle it. Under FIFO asynchrony, Figure 8(d) is excluded, just as for Scribble and Trace-C.

With the aim of supporting the enactment in Figure 8(c), Listing 23 gives an alternative Trace-F specification. This specification has two problems.

One, it would support at most two instances. Two, and in any case, it is unrealizable. This is because it would manifest in a problematic nonlocal choice in the projections for buyer and seller: after sending the first Request, buyer can either send the second Request or receive Offer, and after receiving the first Request, seller can either send Offer or receive the second Request.

Listing 24 (unclear if it is a legal Trace-F specification) improves upon Listing 23 by allowing an unbounded number of instances; however, it remains unrealizable for the same reason as Listing 23.

Figure 9 specifies the protocol in HAPN. As for Scribble, Trace-C, and the Trace-F protocol in Listing 22, each iteration must complete before another can begin, thereby excluding the enactments of Figures 8(b) and 8(c). Notice that the requirement of synchrony eliminates Figures 8(c) and 8(d). That is, there are two strikes against Figure 8(c).

Because Scribble, Trace-C, and Trace-F support one of the four enactments in Figure 8, we conclude that they partially support instances. By contrast, BSPL fully supports the specification of instances via key parameters of protocols. Listing 18 in fact gives the BSPL protocol that supports all the enactments in Figure 8.

To help understand why the protocol in Listing 18 supports each of the enactments in Figure 8, the following observations suffice. First, buyer can send a Request at any point because it can generate bindings for both parameters of Request, namely, ID and item. However, as ID is key, no two Requests may contain the same binding for ID. Second, seller may send Offers only for those IDs whose bindings it knows from prior communications—here, from Request messages it has received. Further, once seller knows a binding for ID, it can send (depending on whether its reasoner determines that it should send) an Offer with that binding of ID at any point since the protocol allows it to generate a binding for the only other parameter in Offer, namely, price.

5.2 Integrity

Building upon instances, integrity means that information in a protocol instance must not be inconsistent. For example, in any instance of Purchase, item must have a unique binding; it cannot be fig in Request and jam in Offer.

Scribble does not support integrity. In Scribble, the message names and the data types of the information carried in a message matter; however, the information carried in the message does not matter. The motivating example of a Scribble travel booking protocol (Yoshida \BOthers., \APACyear2013, p. 8) is illuminating in this regard. Listing 25 reproduces the relevant parts of that protocol.

Figure 10 partially reproduces the customer’s finite state machine (FSM) that is extracted from the above protocol and that serves as the basis for compliance checking in the agent: a deviation from the FSM is a violation of the protocol (Yoshida \BOthers., \APACyear2013, p. 10). Notice that the parameter journey is absent; all that matters is that customer sends a String to agency. To drive home the point about the lack of information modeling in Scribble, we refer the reader to the implementation of the customer agent (Yoshida \BOthers., \APACyear2013, p. 11), which does not mention journey.

Returning to the domain of our running examples, consider the Scribble protocol in Listing 26, a variant of Listing 20. Specifically, in the Alt-Pricing protocol, Offer additionally includes the parameter item. Figure 11 gives the seller’s FSM. Notice again that the parameter names are absent; what matters are the data types. This machine would determine to be legal even those protocol enactments that violate integrity, e.g., where Request contains (the item) fig but Offer contains (the item binding) jam.

Like Scribble, Trace-C does not support integrity either. Like Scribble, messages are opaque in Trace-C: the message names matter but their contents do not, as Listing 3 illustrates.

HAPN partially guarantees information integrity. Once a variable is bound in an enactment, as item is at state $s_{1}$ in Figure 9, any message attempting to use that variable with a different value is illegal. HAPN’s “unbind” operation does not compromise integrity under its assumptions of synchronicity and shared state; all agents would simultaneously see any updates, and would never have inconsistent bindings for any variable. However, HAPN does not ensure integrity when implementing the protocol in a decentralized asynchronous environment, expecting the designer to check for realizability and to make corrections to any problems arising.

BSPL supports integrity, as described in Section 3.5.

Some authors of Trace-F have investigated a language closely related to Trace-F that supports parameters (Ancona \BOthers., \APACyear2017). This language (which we dub Trace-Parameters), like HAPN, partially captures integrity by supporting parameter bindings. Listing 27 (reproduced from (Mascardi \BBA Ferrando, \APACyear2019)) gives a protocol in Trace-Parameters. The expression on the right-hand side of the $=$ may be read as a binding for a parameter (here, ID) followed by the scope over which that binding holds. That is, ID must have the same fresh binding throughout the specified scope. The fresh binding mechanism is not sufficiently expressive to capture integrity, since integrity needs identifiers (as BSPL supports via key parameters). Specifically, the protocol in Listing 27 allows two Request messages to be sent with the same binding for ID. Not only that, it allows two Request messages with the same binding of ID to have different bindings for item.

Additional Remarks. In the absence of protocol language support for protocol instances and correlation, approaches may resort to using the syntactic notion of a conversation identifier to identify messages belonging to the same protocol instance. FIPA ACL (implemented in the JADE platform (Bellifemine \BOthers., \APACyear2007)), adopts such an approach,

supporting the tagging of messages with conversation identifiers. Relying upon conversation identifiers though has significant drawbacks.

• •

The burden of checking that conversation identifiers were being used appropriately would fall upon agent developers, for example, to check that no two Requests are sent with the same identifier.

• •

More importantly, since conversation identifiers represent an extra-protocol mechanism, using them would be a violation of Constraint 5 and would couple agents at the level of their implementations.

• •

The required correlation may in any case go beyond whatever a single identifier supports. For example, a single identifier would be ineffective for describing one-to-many relationships, which require composite identifiers.

5.3 Social Meaning

In general, a specification of social meaning specifies the lifecycle of meaning instances, as exemplified by recent work on commitments (Chopra \BBA Singh, \APACyear2015).

For example, the Deliver-Payment commitment specification in Use Case 2 specifies the lifecycle of Deliver-Payment commitment instances. Where each of the instances differ would be in their information content, as Use Case 6 illustrates.

Use Case 6** (Commitment instances)**

buyer* and seller repeatedly engage in purchase (Use Case 1). A distinct instance of the Deliver-Payment commitment (Use Case 2) is created for every Accept. Several commitment instances may exist at any moment.*

The information content of a commitment instance would need to obey certain soundness constraints. Each commitment instance referred to in Use Case 6 would involve a specific item binding and a specific price binding. And in fact, those bindings must be immutable over the entire lifecycle of the instance. In particular, it cannot be that the commitment instance is created with item binding fig and discharged with item binding jam; such an enactment would clearly be unsound. Notably, reasoning about the state of a commitment instance involves reasoning about several correlated messages that satisfy integrity—e.g., a message to create the instance and a message to discharge it.

Given that meaning-level information is derived from (is a view over) underlying protocol events (Constraint 6), identifiers for commitment instances and the necessary correlation and integrity already be present in protocol enactments. For each instance of the Deliver-Payment commitment, an instance of Purchase must generate the relevant information in a sound manner: an identifier to identify the commitment instance and the bindings for item and price. This means that a commitment instance created by a particular Accept (belonging to a particular protocol instance) may be discharged only by a properly correlated instance of Payment (belonging to that same protocol instance). And integrity of the protocol instance would ensure that the bindings are immutable over the lifecycle of the commitment instance.

It was common in early work on commitments to introduce arbitrary (syntactic) identifiers for them disconnected from the underlying information. As Chopra \BBA Singh (\APACyear2009) show, such schemes are incompatible with commitment reasoning.

In a nutshell, the soundneed of computations at the commitment level and more generally meaning level imposes requirements relating to protocol instances and their integrity on the protocol language. Scribble, Trace-C, Trace-F, and HAPN at best partially support instances and integrity and therefore fall short on this criterion. BSPL supports both instances and integrity and therefore better supports social meaning. Indeed, Singh (\APACyear2011\APACexlab\BCnt1, p. 498) discusses social meaning and other work has applied BSPL toward commitment consistency in decentralized settings (King \BOthers., \APACyear2017). Listing 28 specifies the Deliver-Payment commitment in Cupid (Chopra \BBA Singh, \APACyear2015). It says that each instance of this specification is from Buyer to Seller; it is created upon an Accept; detached upon a Deliver that happens within three days of Accept; and discharged upon a Payment that happens within three days of Payment. Notably, the events in the commitment specification refer to observations of messages of BSPL Purchase protocol given in Listing 8. Since BSPL supports protocol instances and their integrity, as a protocol instance progresses, the commitment instance too progresses soundly.

6 Operational Environment

How strong are the assumptions that a language makes of the operational environment of a multiagent system? The properties a language requires of a communication infrastructure are assumptions about the agent’s operational environment. The stronger the assumptions a language makes, the more restrictive and less practical the language.

We split this criterion into two: whether a language can work over asynchronous infrastructures and if so, whether it can work with unordered message delivery.

6.1 Asynchronous Communication

Assuming synchronous communication would be so strong an assumption as to make the language impractical for MAS. Asynchronous communication, on the other hand, promotes loose coupling between agents and is also practical in that it matches real-world constraints. Scribble, Trace, and BSPL accommodate asynchrony but HAPN (Winikoff \BOthers., \APACyear2018, p. 61) does not.

6.2 Unordered Communication

Asynchronous communication though comes in many flavors. Asynchronous communication with some kind of ordered delivery, for example, pairwise FIFO (simply FIFO, from here on) would be a weaker assumption (and therefore better) than synchrony. FIFO in fact is supported in practical, widely-used infrastructures such as TCP and the Advanced Message Queuing Protocol, better known as AMQP (\APACyear2014). An even weaker assumption than ordered delivery would be asynchronous communication without any kind of ordered delivery. Then, protocols in the language could be enacted directly over the Internet and in highly resource-constrained settings such the IoT.

Relying on any kind of ordered delivery guarantees from the communication infrastructure naturally limits the kinds of infrastructure upon which a protocol may be used to implement a multiagent system. More importantly, as we show below, ordering guarantees are inadequate for ensuring the correct enactment of even simple protocols.

Prima facie, there appears to be a simple motivation for using FIFO channels between agents, as illustrated by the enactments of Use Case 7.

Use Case 7** (Want+WillPay)**

buyer* sends Want (some item) and then WillPay (some amount) to seller.*

Figure 12 shows two possible enactments of Use Case 7. Notice that in Figure 12(b), the messages are reordered in transit so that WillPay is received by seller before Want.

Listing 29 gives the protocol in Trace-C and Trace-F and its projections.

The protocol of Listing 29 cannot handle the enactment of Figure 12(b) because the seller’s projection expects to receive Want before WillPay. The enactment of Figure 12(b) though is ruled out if the infrastructure guarantees FIFO delivery; only the enactment of Figure 12(a) is possible under FIFO. That is, in essence, there are two mutually exclusive alternatives: (1) either declare the enactment with the reordered messages to be valid and the protocol to be unrealizable; or, (2) assume FIFO channels between agents and declare the protocol to be realizable. Scribble and Trace-C take the latter alternative. Trace-F also effectively takes the latter alternative: the protocol is unrealizable under unordered asynchrony but is realizable under FIFO (with the SR, SS, and RR interpretations).

Listing 30 gives a BSPL specification for Use Case 7. The protocol ensures that buyer can send WillPay with some binding for ID only after Want; however, it does not constrain when the messages should be received by seller. Thus, it supports both enactments of Figure 12.

Assuming FIFO to help ensure correctness seems innocuous at first glance. However, a FIFO communication infrastructure is infeasible in important application settings. For example, in the Internet of Things (IoT), many of the devices lack a capability for anything beyond packet-based communication and in particular lack the capability for buffering. Buffering is the common way to implement FIFO; another implementation approach would be to drop a message whose sequence number is not the next number to the one most recently received—but that too is not practicable since it would waste resources and exacerbate the latency of communication. In settings that demand fast interactions (e.g., for financial transactions), the additional latency due to FIFO is an avoidable overhead.

Moreover, and crucially, the FIFO assumption faces a profound semantic problem: FIFO turns out to be inadequate for correctness in settings of more than two parties, as Use Case 8 demonstrates.

Use Case 8** (Indirect payment)**

In an indirect-payment purchase protocol, after receiving an Offer, buyer first sends Accept to seller and then sends Instruct (a payment instruction) to bank. Upon receiving Instruct, bank sends a funds Transfer to seller.

Figure 13 shows two enactments for Use Case 8. In Figure 13(a), seller receives Accept before Transfer whereas in Figure 13(b), seller receives Accept after Transfer. Both enactments satisfy FIFO since at most one message is being sent on any channel. The enactments illustrate that even with FIFO ordering, asynchrony makes ordering indeterminate for protocols involving more than two agents.

Listing 31 is an attempt to capture Use Case 8 in Trace-C. Following the reasoning for Trace-C (Castagna \BOthers., \APACyear2012, p. 16), this protocol is unrealizable. Specifically, the projection for seller expects to receive Accept before Transfer and therefore does not support the enactment in Figure 13(b), which may arise despite using FIFO channels. In summary, by ruling out the protocol, Trace-C rules out realistic message orders that are simply the result of asynchrony. Listing 31 additionally serves as the specification of the protocol in Trace-F. Under FIFO, no matter what sequence interpretation is chosen, the protocol is unrealizable.

Listing 32 gives a Scribble protocol to capture Use Case 8. The Scribble projections are analogous to the Trace-C and Trace-F projections in Listing 31. In particular, seller cannot receive Transfer before Accept; it blocks on the reception of Accept on the channel from buyer even when Transfer may have arrived earlier on the channel from bank. The listing shows seller’s projection (other agents’ projections are elided). Effectively, the projection enforces a reception order for the two messages that may be different from their arrival order.

The BSPL specification in Listing 33 specifies a protocol that supports both of the enactments shown in Figure 13. The reason is that, in BSPL, an agent may receive a message whenever the communication infrastructure delivers a message to the agent. Information causality and integrity in BSPL constrain the emission of messages by an agent; message reception is unconstrained.

We omit HAPN from this discussion since it does not support asynchrony.

7 Mapping Back to Multiagent Systems

We now map the findings from our analysis of the protocol languages to multiagent systems.

7.1 Architecture

We identify the architectural assumptions that underlie the protocol languages discussed above.

Figure 14 depicts the architecture underlying HAPN. HAPN does not give a method for deriving projections from protocols; assuming, however, a suitable method for projecting and enacting HAPN protocols, the major difference from the architecture in Figure 1 is that HAPN, as currently formalized, requires synchronous communication, a violation of Constraints 3 and 4.

Figure 15 shows the architecture induced by Trace-C. Communication between agents is via a FIFO-based asynchronous infrastructure. Recall that Trace-F has a pluggable communication infrastructure. Figure 15 also depicts the architecture induced by Trace-F when FIFO is assumed.

FIFO (delivery) though is a stronger assumption than Assumption 1, which requires only noncreativity from the infrastructure. Without FIFO, Trace-C and Trace-F would violate reception correctness (Constraint 2), which states that any reception of a message that is correctly sent is correct. The Trace-C and Trace-F Want+WillPay protocol (Listing 29) illustrates the violation. Even though buyer sends Want before WillPay, as required by the protocol, seller receiving WillPay before Want is an incorrect enactment.

In fact, even with FIFO, both Trace-C and Trace-F violate reception correctness (Constraint 2). This is illustrated by the Trace-C and Trace-F Indirect Payment protocol (Listing 31). Asynchrony means that Transfer may be received by seller before Accept; however, that order of reception is incorrect according to the protocol.

Scribble induces the architecture in Figure 16. As with the architecture for Trace-C in Figure 15, it requires FIFO. If FIFO were to be dropped, Scribble, like Trace-C and Trace-F, would violate reception correctness (Constraint 2).

Scribble treats the reception of a message as a logically blocking operation on the channel on which the message is expected: an agent will not receive a message on any other channel until it receives the message it is blocked on. The notion of blocking reception is instrumental to Scribble’s ability to handle the arrival of Transfer before the arrival of Accept in the indirect payment protocol. Specifically, seller blocks on the channel from buyer, on which Accept is expected; in the meantime, if Transfer arrives on the channel from the banker, it is ignored and thereby not considered received.

In essence, Scribble reorders message arrivals to suit the agent. Such reordering is incompatible with asynchrony; specifically, it is a violation of anytime reception (Constraint 4). Scribble attempts to disguise the violation by treating the reception of a message as the result of an agent’s decision to receive the message, distinct from the event of the arrival of the message. Architecturally, the reordering across channels is captured in the channel selector component in Figure 16 that mediates between the FIFO infrastructure and an agent and hides all channels from the agent except the one on which it is expecting to receive a message.

If the idea of reordering messages received on different channels were dropped, then even with FIFO, Scribble would violate reception correctness (Constraint 2) (just as Trace-C and Trace-F do).

By contrast, Figure 1 captures the architecture induced by BSPL. A multiagent system based on BSPL satisfies all the constraints given in Section 1. In particular, BSPL works with asynchronous communication but does not require FIFO. Given any safe BSPL protocol, any message sent according to the protocol is also received correctly regardless of when that reception occurs relative to other receptions.

For completeness, we comment on some recent programming and architectural frameworks for MAS. In JaCaMo (Boissier \BOthers., \APACyear2013), agents coordinate their computations by shared artifacts—components that provide “functionalities and services” (p. 750) for agents. JaCaMo can be used to realize a MAS that satisfies the canonical architectural style of Figure 1—or any of the others for that matter. Specifically, messaging between agents could be realized using artifacts. The infrastructure can avoid centralization by, for example, using a dedicated artifact for each channel and deploying the artifacts across the system. The sender of a message would send it to the channel artifact and the receiver would pick it from that artifact. Indeed Baldoni \BOthers. (\APACyear2019) implement commitment-based coordination between agent by representing commitments in a shared JaCaMo artifact.

Jason (Bordini \BOthers., \APACyear2007), the language in which agents are programmed in JaCaMo, supports specifying an agent’s reasoning about incoming and outgoing messages. However, Jason’s programming model does not include protocols of the sort motivated here.

ReST (Vinoski, \APACyear2008) is an architectural style for Web applications that has been advocated as a basis for engineering MAS (Ciortea \BOthers., \APACyear2018). An important ReST constraint is that an application’s state is fully captured in the representation of the relevant Web resources (as identified by URIs) on the server. The architectural style that BSPL adopts is analogous to ReST but in a more general peer-peer setting (Singh, \APACyear2011\APACexlab\BCnt2).

7.2 Principles for MAS

We present some broad principles that are relevant for MAS but are violated by several of the evaluated protocol languages.

Principle 1** (No unitary

perspective)**

A protocol should avoid specifying computations (enactments) from a unitary perspective.

Principle 1 follows from the fact that there is no valid unitary perspective in a MAS (Hewitt \BOthers., \APACyear1973; Gasser, \APACyear1991); the only perspectives that count are those of the agents in the MAS. Protocols that specify computations from a unitary perspective are either (1) unrealizable by agents acting based solely on their local knowledge or (2) unduly restrict concurrency.

Scribble, Trace-C, Trace-F, and HAPN violate Principle 1.

In each of those languages, a protocol’s computations are given from a unitary perspective. HAPN assumes synchrony (Winikoff \BOthers., \APACyear2018, p. 61) and does not provide a method to generate endpoint projections. Some HAPN protocols may not be realizable without the assumption of synchrony.

A computation of a Scribble, Trace-C, or Trace-F protocol is a single sequence of messaging events. Scribble, Trace-C, and Trace-F support asynchrony and each describes how to derive the local perspective, that is, the projection, for each agent. In the Scribble, Trace-C, and Trace-F approaches, extracting the projections relies on a custom (and usually complicated) theory of causality.

Despite all the machinery that goes into specifying the semantics of protocols, projections, and realizability in these approaches, as we saw above, they fail to model important aspects of the simple and realistic uses cases described above.

The Scribble, Trace-C, and Trace-F protocols for Flexible Purchase (in Section 4.1) highlight the pitfalls of the unitary perspective. From the unitary perspective, as Listing 10 illustrates, it is a clear choice between either Payment first or Shipment first. However, when seller and buyer exercise their respective choices locally, that is, on the basis of their projections, a deadlock may obtain. This leads to the protocols being ruled out as unrealizable.

Protocols in BSPL satisfies Principle 1: The computations of a BSPL protocol are given directly in terms of agent perspectives.

Any protocol is a “global” specification for a MAS in the sense that it specifies the (public) computations of the entire MAS. And every protocol conceptually yields a “local” specification, or projection, for every role in the protocol.

Such a global-local distinction is perfectly reasonable and not in conflict with Principle 1.

Indeed, the global-local distinction applies to BSPL as well: A BSPL protocol is a global specification in the foregoing sense and a projection for a role in the protocol is the set of all message specifications referenced by the protocol where the role is either sender or receiver. What Principle 1 rules out is giving the computations of a global protocol from a unitary perspective.

In the discussion of the following principles, Trace-F stands for Trace-F under FIFO asynchrony. We can ignore Trace-F under other communication models for two reasons. First, under one of those models, namely, unordered asynchrony, Trace-F is too weak a language—it is unable to capture a protocol as simple as Want+WillPay (Use Case 7). Second, all the remaining communication models are strictly stronger than FIFO and the conclusions we draw for Trace-F under FIFO asynchrony are valid for them as well.

Principle 2** (Noninterference)**

A protocol must not prevent legitimate agent reasoning.

An agent may want to process a message as soon as the message has arrived. The agent’s motivations for doing so need not concern us since the agents are autonomous and may adopt any preferences arbitrarily in light of their autonomy. However, Scribble, Trace-C, and Trace-F, in requiring messages to be received in a certain other relative to other messages, rule out such agents and, therefore, violate Principle 2.

For example, in Use Case 7, seller may want to process the WillPay message even if Want hasn’t yet been received. In Use Case 8, seller may want to process the Transfer message even if Accept hasn’t been received. The Scribble, Trace-C, and Trace-F protocols rule out this possibility. BSPL, by contrast, satisfies Principle 2: the only constraints it imposes on agents have to do with information causality and information integrity. Indeed, the BSPL protocols for Use Case 7 and Use Case 8 allow seller to process WillPay before Want is received and Transfer before Accept is received, respectively.

Principle 3** (End-to-end principle for protocols)**

Correct protocol enactment must not rely on message ordering guarantees from the communication infrastructure since the appropriate constraints are to be implemented and checked in agents.

Scribble, Trace-C, and Trace-F violate Principle 3 because they require a FIFO communication infrastructure. BSPL satisfies Principle 3 because it requires no ordering guarantees from the infrastructure.

Principle 3 derives from the end-to-end argument for system design (Saltzer \BOthers., \APACyear1984), which originated in the early days of computer networking in the 1960s. In its networking form, the end-to-end principle states that functionality that makes sense at a higher (“application”) layer should not be replicated at a lower (“infrastructure”) layer. The motivation is that if some function of a networked application can be fully and correctly implemented only at the application’s end points standing above a communication infrastructure, then supporting that function partially in the infrastructure (1) is not adequate (still requires the application to work to achieve that function); (2) imposes a cost on all internal nodes; and (3) restricts the functioning of application end points that are not concerned with that function. We can think of FIFO as a “function” in this case—notably, Saltzer \BOthers. specifically discuss the disadvantages of adopting a FIFO delivery infrastructure; such an infrastructure is also not assumed in the actor model (Agha, \APACyear1986).

A protocol can be fully and correctly implemented only by the agents who instantiate it. Relying on the infrastructure for correctness is of little benefit. For explanation, let’s consider emissions and receptions, the two kinds of observations that a protocol may constrain. An agent must ensure the correctness of its emissions because emissions are driven by an agent’s internal decision-making. For the correctness of receptions, an agent may rely on ordering guarantees from the infrastructure. However, such guarantees may be insufficient for correctness. For example, as we saw in the modeling of indirect payment (Use Case 8), Scribble, Trace-C, and Trace-F’s reliance on FIFO turns out be insufficient for correctness.

In addition to being insufficient, infrastructure ordering guarantees may be excessive since they constrain even messages that are unrelated in terms of meaning but merely contingently happen to occur together. Listing 34 is illustrative of how infrastructure ordering may be excessive. The listing specifies two protocols Just-Want and Hello-World. Each protocol has a single message from buyer to seller; the two messages do not have any parameters in common, signifying that there is no causal dependency between them. Even so, a FIFO infrastructure will necessarily deliver the messages to seller in the order in which they are sent by buyer.

Finally, consider that ordering guarantees from the infrastructure come with a heavy price: increased complexity and overhead in the architecture, restrictions on the settings in which a multiagent application may be deployed, and interference with higher-level agent reasoning (as we discussed in the context of Principle 2).

8 Discussion

Our contribution in this paper is an evaluation of select modern, formal, and prominent languages for specifying protocols. Our evaluation criteria have to do with representations and operational assumptions. Our evaluation is concrete and comparative, driven by the specification of protocols in the selected approaches, followed by an analysis of the specifications. The Scribble, Trace-F, and BSPL protocols have been verified in their respective tooling. We understand verification tools for Trace-C and HAPN are not available.

Table 1 summarizes our findings. For reasons given above, Trace-F stands for Trace-F under FIFO-asynchrony. Our evaluation shows that BSPL is able to model the use cases considered in all their richness despite—or because of—weaker guarantees from the communication infrastructure.

We discussed how Scribble, Trace-C, Trace-F, and HAPN violate the canonical MAS architectural style presented in Section 1. HAPN requires synchrony, which makes it impractical for decentralized settings. Scribble, Trace-C, and Trace-F reorder messages to fit an agent’s perspective. BSPL works with unordered asynchrony; the MAS architecture induced by BSPL is compatible with the canonical architectural style.

Information (as captured by parameter bindings) in BSPL are immutable. For MAS where agents communicate asynchronously, the immutability of information simplifies ensuring correctness even though the participants make observations in different orders—as expressed by Chandy \BBA Lamport (\APACyear1985).

The immutability of information, however, calls for a different way of specifying interactions. Specifically, to achieve the effect of updates, a BSPL protocol must incorporate a composite key such that a part of the key reflects the version ID, thereby preventing the versions from interfering with each other. To capture finality, the protocol must incorporate a message that conflicts with (and thus prevents) subsequent versions.

In this way, there is a tradeoff between (1) adopting a new way of modeling interaction to accommodate realistic communication assumptions (asynchrony), and (2) making unrealistic assumptions (synchrony) to support a familiar programming style (mutability). Immutability in BSPL contrasts most clearly with HAPN, which explicitly supports both bind and unbind operations on parameters and therefore supports rebinding a parameter.

We set out to evaluate protocol languages from the standpoint of building decentralized multiagent systems.

An informally but widely held attitude in the multiagent systems research community (and in related external subcommunities) is that our approaches are adequate for tackling autonomy and flexibility as needed in decentralized settings.

Accordingly, researchers have taken support for decentralization as a done deal and gone on to tackle challenges such as tool support and ease of use—which are no doubt crucial challenges. However, as we have shown in this paper, the more fundamental challenges of decentralization have largely not been overcome by languages of the established paradigms. One language from a new, information-oriented paradigm does tackle those challenges. Whether that or another, as yet unknown, paradigm prevails remains to be seen. But what we can conclude from this exercise is that a new way of thinking is needed to properly accommodate decentralization.

8.1 Other Criteria for Evaluating Protocol Languages

The criteria by which we study protocol languages in this paper are not exhaustive.

Winikoff \BOthers. (\APACyear2018) compare several protocol languages, including HAPN and BSPL, for orthogonal criteria such as precision, simplicity, graphical representation, and so on.

They note that whereas HAPN supports multiple agents playing a role, BSPL doesn’t (Splee (Chopra \BOthers., \APACyear2017), an extension of BSPL, though supports this feature). Winikoff \BOthers. also report on their personal experience of encoding protocols in BSPL. They observe that BSPL is “more of a core calculus than a usable notation.” Recent work on meaning-based languages that compile into BSPL appears to supports the idea that BSPL represents a core calculus (Singh \BBA Chopra, \APACyear2020). Winikoff \BOthers. also report an extensive user study that evaluated HAPN, AUML, and statecharts for ease of reading, understanding, and writing specifications.

Ancona \BOthers. (\APACyear2018) include BSPL, HAPN, and trace expressions in an evaluation of MAS approaches for support remote patient monitoring. Although their ten criteria are diverse, a predominant thrust is tooling, e.g., IDE support, static and runtime verification, testing, code generation, and so on. In their evaluation, trace expressions offer a clear advantage over both HAPN and BSPL in supporting self-adaptation. A criterion where both trace expressions and HAPN shine over BSPL is that they come with IDE support whereas BSPL doesn’t. In contrast to our and Winikoff et al.’s evaluations, Ancona et al.’s evaluation is informed by protocols as use cases.

Together, the three evaluations—the present paper, Winikoff et al.’s, and Ancona et al.’s—highlight the variety of criteria and methods for evaluating protocol languages. Ultimately, they all bear upon usability in the larger sense of the term. Nevertheless, it is helpful to distinguish representational criteria from contingent ones. A representational criterion is one whose evaluation for any language relies on primarily on the syntax and semantics of the language itself. Each criterion in our evaluation is representational; we relied on nothing more than the formal description of the language itself in our analysis. A contingent criterion is one whose evaluation is potentially affected to a significant degree by factors external to the language. Criteria such as popularity, ease of use (viewed it as a matter of the familiarity of the paradigm), and tool support are thus contingent. In contrast to our evaluation, both Winikoff et al.’s and Ancona et al.’s evaluations have a strongly contingent flavor.

8.2 Directions

With respect to future evaluations of protocol languages, two directions (with a more contingent flavor) stand out, especially since they are informed by what would be perceived as broad strengths of the languages that BSPL outperformed in the current evaluation. One, perform a comparative study of protocol languages for the kinds of properties that can be verified for both protocols and endpoints. Scribble and the Trace approaches may do better in such an evaluation given that verification (both static and runtime) has been the primary motivation in their development and both benefit from deep connections with programming language theory. Two, perform a comparative study of the programming models supported by the languages in terms of how they make it easier to write correct programs. Scribble, notably, has implementations in several popular languages such as Java and Python.

A more theoretical direction would be to determine the fragment of a protocol language that can be encoded in another with the purpose of formally establishing their relative expressiveness. We hope that the evaluation presented in this paper, bearing as it does solely on representational issues, will help inform such an effort.

Acknowledgments. Raymond Hu provided helpful suggestions regarding Scribble. Viviana Mascardi and Angelo Ferrando helped us understand Trace-F.

Thanks to the anonymous reviewers for helpful comments. Christie, Smirnova, and Chopra were supported by EPSRC grant EP/N027965/1 (Turtles). Christie and Singh were partially supported by the National Science Foundation under grant IIS-1908374.