Protocol engineering in multiagent systems

There are a number of parallel strands of research on protocols and interaction be-haviour specification in multiagent systems. [190, 86, 120] discuss protocols and protocol engineering in multiagent environments and propose conceptual frameworks.

The standard approach to agent interactions has been message oriented, with inter-actions defined by interaction protocols that give permissible sequences of messages.

Examples of research activity include work done on enhancing existing methods dis-cussed above, i.e. finite state machines, petri-nets. Other attempts consider deeper issues of agent communication languages and the use of conversation policies [98] , and conversation oriented approach to agent interactions [20].

There are some arguments that the message centric approach is limited especially re-garding robustness and flexibility [244]. It is with these concerns that there are strands of research that consider a shift away from message centric view to the introduction of social semantics and consideration of higher level notions such as social commitments and development of commitment machines, CMs. [252].

There is also further research that consider dialectical approaches , advocating the use of dialogue-games. [162] surveys commitment-based and dialogue-based protocols.

It is worth noting however, that some of these approaches often assume some under-lying model of agents, e.g. logical frameworks as it is the case for dialogue-based protocols, and commitment machines can be mapped [244] to BDI frameworks [196].

The next sections considers briefly some of these approaches in turn.

4.4.1.1 Finite state machine based protocols

As discussed above there is historical precedent to using finite state in modelling pro-tocols. This extends to multi-agent interaction protocols [251].

An interaction protocol as an fsm will show states and transitions labelled with allowed messages. As an example consider a finite state machine representation of the Contract Net Protocol³[215] shown in Figure 4.3. In that figure,a and b represent roles, i.e. in the rolea, an agent can send messages from the set{cfp, accept_proposal, cancel, reject_proposal} to a group of agents each playing the role b. In the role b and agent can send messages from the set{propose, refuse, inform, cancel}. Indexing can be used in the protocol message labels for both roles, e.g. to capture the fact that a cf p message is broadcast by an agent playing role a to multiple agents in a group. We can writea : cf p : b(i) and more generally if multiple instances of role a exist write a(i) : cf p : b(i). This setup can be generalised to multiple roles.

Finite state machine based protocols and conversation models are predominantly used in multiagent system research. A justification is given in [57] where it is observed that it is mainly because the finite state machines have an established underlying formal model that supports structured design techniques and formal analysis and facilitates development, composition and reuse. Furthermore finite state machines are simple, intuitive, provide visual flow of action or communication and are sufficient for many

3Contract Net Protocol is a task allocation protocol that facilitates negotiation between bidders and an auctioneer in a Multi-Agent System to form a contract.

1

2

5 6

7

8 3

4 a:cfp:b(i)

b(i):propose:a

a:accept_proposal:b(i)

b(i):failure:a, a:cancel:b(i) b(i):inform:a

a:reject_proposal:b(i) b(i):refuse:a , b(i):not_undersood:a

(a)

Figure 4.3: Contract Net protocol, showing messages and indexed agent roles for protocol participants.

sequential interaction.

4.4.1.2 Petri Nets and agent protocols

While finite state machine based protocols and conversation models are predominantly used, the main criticism has been that finite state machines are not adequately expres-sive to model interactions with degrees of concurrency.

Therefore there is some research directions that explore the use of petri-nets in mod-elling agent interactions, some work is reported in [102, 86].

Because the petri-net language is a generalisation of automata folmalism⁴ then with appropriate transformations petri nets can be derived from finite transition systems [56] and reverse transformation also exists, called reachability analysis, is part of the definition of Petri Net. It generates a form of FSM labelled with Petri net transitions and called state graph.

Coloured Petri-nets [128] have recently been explored to represent agent interactions and related issues. [57] proposes the use of colored petri-nets as model underlying language for conversation specification. The motivation cited there for this is that;

1. While finite state machines are commonly used, they are not sufficient for com-plex agent interactions requiring concurrency.

2. Petri-net carry relative simplicity and graphical representation of Finite state Machines in addition supports greater expressive power to support concurrency.

Furthermore, a language, Protolingua [57] based on this model was investigated within the Jackal [58] agent development environment. For example [102] presents an anal-ysis of existing Petri net representation approaches in terms of their scalability and appropriateness for different tasks.

4

4.4.1.3 AUML

There is active research on the use of AUML [21, 150] in modelling agents interaction protocols, the rationale being that by aligning this work with the closest antecedent technology object oriented software development, there are benefits to be accrued, es-pecially in the wide acceptance of agents [21], indeed there is a view in some research strands in Agent-oriented programming that multiagent systems can be considered ex-tensions of object-oriented systems.

AUML is an extension of Unified Modelling Language, UML ⁵ [124] and there has been attempts to model agent protocols and interactions using it, examples can be seen in [136].

The motivation for the use of AUML has largely centered around the need for mod-elling methods and tools that supports a complete process lifecycle [136]. For example, the use of AUML specified interaction protocols in a prometheus⁶based designed tool [230] has been discussed in [185].

AUML has also been used by FIPA⁷ to specify FIPA agent interaction protocols [1].

Regarding implementation, FIPA protocols implementations in multiagent tools has been largely as finite state machines.⁸

Figure 4.4 below shows an example of a FIPA contract-net protocol.

The AUML FIPA interaction protocol can be mapped to other formalisms, for example [39] provides a transformation of AUML diagrams to petri-nets to help define opera-tional semantics of interaction protocols, i.e. the semantics of the AUML diagrams are defined through the semantics of petri-nets. Also [102] makes an argument for a

5Object Management Group.

6Prometheus is a software engineering methodology for designing agent systems.

7FIPA is an IEEE Computer Society standards organization that promotes agent-based technology and the interoperability of its standards with other technologies. FIPA has specified and defined seman-tics of FIPA-ACL, an agent communication language.

8Open source agent platform JADE uses finite state machine based "behaviours" for example.