Abbottabad University of Science & Technology

Report on Multi-agent System Issue

Submitted By: Ahsan Rahim (1838)

What kinds of languages can agents use to

communicate?

ulti-Agent System (MAS) is composed of multiple heterogeneous intelligent software

systems called agents. Agents need an Agent Communication Language (ACL) in

order to interact in a shared language, hiding the details of their internals and to build

communities of agents that can tackle problems that no individual agent can.

Introduction:

As a Multi-Agent System (MAS) is composed of multiple heterogeneous intelligent software

systems (called agents) which can compete, negotiate or cooperate. In recent years the interest in

MAS has grown tremendously and today agent technology is being used in a large range of

industrial applications. Agent technology is widely used to help users to achieve various tasks in

diverse domains such as network management, air-traffic control, telecommunications, and

electronic commerce.

Communication is considered as a negotiation game where agents negotiate about proposed

communicational states. An agent proposes a communicational state and other agents react to the

proposal by accepting, rejecting the proposed communicational states or even asking for further

information. Such an action establishes a relationship between the communicational states and

the agent that is called an agent's positioning.

Agent technology is widely used to help users to achieve various tasks in diverse domains such

as network management, air-traffic control, telecommunications, and electronic commerce.

Agent applications have one thing in common: agents must be able to communicate in order to

decide which actions to perform. In a multi-agent system, we distinguish two levels of

communication: agent/user communication and agent/agent communication. In both kinds of

communication, industry is trying to find a standard communication language. To assist

developers in the use of agent technology, some multi-agent system tools have been developed.

However, these tools are still suffering from the following drawbacks:

There is no standard architecture for Multi-Agent Systems

There is no standard design method for the design of a Multi-Agent System

There are no standard communication protocol agents /users.

Agents suggest a paradigm for software development which emphasizes autonomy (both at

design time and run time), adaptivity (change is everywhere) and cooperativity (humans agents

do it all the time, so should the software ones, too). This approach seems appealing in a world of

distributed, heterogeneous systems. Languages for communicating agents promise to play the

role that language played for their human counterparts.

M

The Communication Model:

When interacting, agents can engage in two kinds of communication:

i. Agent/user communication

ii. Inter-agent communication

Agents communicate with users in order to characterize their needs and to provide them with

answers or solutions. Agents communicate with each other in order to exchange various kinds of

information. When communicating with other agents, an agent uses a specific Agent

Communication Language (ACL). An ACL provides agents with a means to exchange

information and knowledge. At the technical level, when using an ACL, agents transport

messages over the network using some lower-level protocol (SMTP, TCP/IP, IIOP, HTTP, etc.).

The ACL itself defines the types of messages (and their meaning) that agents may exchange.

Agents though, do not just engage in single message exchanges but they have conversations, i.e.

task-oriented, shared sequences of messages that they follow, such as a negotiation or an auction.

At the same time, some higher-level conceptualization of the agent's strategies and behaviors

drives the agent's communicative (and non-communicative) behavior.

An agent's architecture contains a communication process which handles communication

activities as well as other processes used to perform various tasks such as planning, decision

making or negotiation.

Agent Communication Protocols

There are a variety of interprocess information exchange protocols. In the simplest, one agent

acts as a client and sends a query to another agent acting as a server and then waits for a reply ,

as is shown between agents. The server's reply might consist of a single answer or a collection or

set of answers. In another common case, shown between agents A and C, the server's reply is not

the complete answer but a handle which allows the client to ask for the components of the reply ,

one at a time. A common example of this exchange occurs when a client queries a relational

database or a reasoner which produces a sequence of instantiations in response. Although this

exchange requires that the server maintain some internal state, the individual transactions are as

before.

Basic concepts of an Agent Communication Language

An ACL provides agents with a means to exchange information and knowledge; Genesereth has

gone as far as equating agency with the ability of a system to exchange knowledge using an

ACL. Of course other means and pproaches have been used over the years to achieve the lofty

goal of seamless exchange of information and knowledge between applications. From Remote

Procedure Call (RPC) or Remote Method Invocation (RMI), to CORBA and Object Request

Brokers (ORB's) the goal has been the same. What distinguishes ACLs from past such efforts are

the objects of discourse and their semantic complexity. ACLs like KQML or FIPA ACL, stand a

level above CORBA, because: (1) they handle propositions, rules and actions instead of simple

objects (with no semantics associated with them), and (2) the ACL message describe a desired

state in a declarative language, rather than a procedure or method. But ACLs by no mean cover

the entire spectrum of what applications may want to exchange. More complex objects can and

should be exchanged between agents, such as shared plans and goals, or even shared experiences

and long-term strategies.

At the technical level, when using an ACL, agents transport messages over the network using

some lower-level protocol (SMTP, TCP/IP, IIOP, HTTP, etc.). The ACL itself defines the types

of messages (and their meaning) that agents may exchange. Agents though, do not just engage in

single message exchanges but they have conversations, i.e. task-oriented, shared sequences of

messages that they follow, such as a negotiation or an auction. At the same time, some higher-

level conceptualization of the agent's strategies and behaviors drives the agent's communicative

(and non-communicative) behavior. Traditionally, we understand the message types of ACLs

as speech acts, which in turn are usually accounted for in terms of beliefs, desires, intentions and

similar modalities. This kind of intentional-level description can either be just a useful way to

view a system or it can have a concrete computational aspect. The latter case describes a large

range of BDI3 agents which have some (implicit or explicit) representation of the corresponding

modalities.

This representation is built on top of a substrate that describes the conceptual model of

knowledge, goals and commitments of an agents, commonly known as a BDI theory. Despite the

criticism that BDI theories and BDI agents have faced, such as the number and choice of

modalities and the fact that multimodal BDI logics have neither complete axiomatizations nor

they are efficiently computable, they offer an appealing framework to account for agent

communications, because agents, when communicating, they communicate their BDI states and

attempt to alter their interlocutors BDI states.

Basic concepts of ACL

The Knowledge Sharing Effort initiated circa 1990 by the Defense Advanced Research Projects

Agency of the US Department of Defense, enjoyed the participation of dozens of researchers

from both academia and industry. Its goal was to develop techniques, methodologies, and

software tools for knowledge sharing and reuse at design, implementation, or execution time.

The central concept of the KSE was that knowledge sharing requires communication, which in

turn requires a common language; the effort focused on defining that common language. In the

KSE model, software systems are virtual knowledge bases that exchange propositions using a

language that expresses various complex attitudes. The proper term is propositional attitudes.

An ACL provides agents with a means of exchanging information and knowledge; Michael R.

Genesereth has gone as far to equate agency with the ability of a system to exchange knowledge

using an ACL.3 Of course, other means have been used to achieve the lofty goal of seamless

exchange of information and knowledge between applications. From remote procedure call and

remote method invocation (RPC and RMI) to CORBA and object request brokers, the goal has

been the same. What distinguishes ACLs from such past efforts are the objects of discourse and

their semantic complexity. ACLs stand a level above CORBA for two reasons:

• ACLs handle propositions, rules, and actions instead of simple objects with no semantics

associated with them.

• An ACL message describes a desired state in a declarative language, rather than a procedure or

method.

But ACLs by no means cover the entire spectrum of what applications might want to exchange.

Agents can and should exchange more complex objects, such as shared plans and goals, or even

shared experiences and long-term strategies.

The KQML Language

Communication takes place on several levels. The content of the message is only a part of the

communication. Being able to locate and engage the attention of someone you want to

communicate with is a part of the process. Packaging your message in a way which makes your

purpose in communicating clear is another. When using KQML, a software agent transmits

content messages, composed in a language of its own choice, wrapped inside of a KQML

message. The content message can be expressed in any representation language and written in

either ASCI I strings or one of many binary notations (e.g. net work indep endent XDR

representations). All KQML implementations ignore the content portion of the message except to

the exten t that they need to recognize where it b egins and ends.

The syntax of KQML is based on a balanced parenthesis list. The initial element of the list is the

performative and the remaining elements are the performative's arguments as value pairs.

Because the language is relatively simple, the actual syntax is not signicant and can be changed

if necessary in the future. The syntax reveals the roots of the initial implementations, which were

done in Common Lisp, but has turned out to be quite exible.

KQML is expected to be supported by an software substrate which makes it possible for agents

to locate one another in a distributed environment. Most current implementations come with

custom environments of this typ e, these are commonly based on helper programs called routers

or facilitators. These environments are not a specied part of KQML. They are not standardized

and most of the current KQML environments will evolve to use some of the emerging

commercial frameworks, such as OMG's CORBA or Microsoft's OLE2, as they become more

widely used. The KQML language supports these implementations by allowing the KQML

messages to carry information.

CG-KQLM+ : an extension of KQML:

CG-KQLM is a first attempt to provide a standardized Agent Communication Language (ACL)

came forth from the ARPA knowledge sharing project and produced KQML. In the context of

that project, researchers developed two main components:

i. a representation language used to express message contents.

ii. a communication language KQML (Knowledge Query Manipulation Language).

KQML has been designed to facilitate high level cooperation and interoperation among agents.

KQML offers an extensible set of so-called performatives which specify what kind of

communication actions agents can perform. KQML performatives are either assertive (used to

state a fact) or directives (used to give orders or send requests). A typical KQML message has

the following syntax:

(tell

: sender A

: receiver B

: content "raining”)

KQML and ACL Concepts:

KQML (knowledge query and manipulation language) illustrates the basic concepts of existing

ACLs. KQML is a high-level, message-oriented communication language and protocol for

information exchange independent of content syntax. So, KQML is independent of the transport

mechanism (TCP/IP, SMTP, IIOP, etc.), independent of the content language (KIF, SQL, STEP,

Prolog, etc.) and independent of the ontology assumed by the content.

The KQML language is divided into three layers: the content layer, the message layer, and the

communication layer. The content layer bears the actual content of the message; in the programs

own representation language. KQML can carry any representation language, including languages

expressed as ASCII strings and those expressed using a binary notation.

Every KQML implementation ignores the content portion of the message, except to determine

where it ends. The communication level encodes a set of features to the message which describe

the lower level communication parameters, such as the identity of the sender and recipient, and a

unique identifier associated with the communication. It is the message layer that is used to

encode a message that one application would like to transmit to another.

The message layer forms the core of the KQML language, and determines the kinds of

interactions one can have with a KQML-speaking agent. The primary function of the message

layer is to identify the network protocol to be used to deliver the message and to supply a speech

act or performative which the sender attaches to the content (such as that it is an assertion, a

query, a command, or any of a set of known performative).

KQML Routers

Routers are content independent message routers. Each KQML speaking software agent is

associated with its own separate router process. All routers are identical each is just an executing

copy of the same program. A router handles all KQML messages going to and from itsassociated

agent.

Because each program has anassociated router process, it is not necessary to make extensive

changes to each program's internal organization to allow it to asynchronously receive messages

from a variety of independent sources. The router provides this service for the agent and provides

the agent with a single point of contact for the rest of the network. It provides both client and

server functions for the application and manages multiple simultaneous connections with other

agents. The router nev er lo oks at the content elds of the messages it handles. It relies on the

KQML performatives.

Conclusion

The concept of a standard communication language for software agents that is based on speech

acts has found wide appeal, both among researchers interested in working out the theory of agent

communication as well as those with the aim of engineering practical software systems. Many

researchers believe that the development of an effective, rich ACL is one of the keys to the agent

paradigm.

The KQML language was among the first such ACL to be developed and used. Moreover, is the

only one which has enjoyed substantial use by more than its developers to date. However, after

eight years of experimentation and experience there are still serious signs of immaturity. In

general, different KQML implementations can not interoperate; (2) there is no fixed specification

sanctioned by some consensus-creating body; and (3) there is no agreed-upon semantics

foundation. Is the KQML experiment a failure? We think not. KQML has played a large role in

defining what an Agent Communication Language is and what the issues are when it comes to

integrating communication into agent systems. Although existing KQML implementations tend

not to interoperate, this is mainly due to a lack of a real motivation to do so. Agent-based

systems research is still at an early stage of development, and there has been no benefit to

individual research groups in focusing on the interoperability issues. Although the lack of a

sanctioned specification has probably impeded the adoption of KQML for many big projects, it

has had the benefit of allowing much experimentation with dialects and variations on the theme.

We hope that the current FIPA effort will supply the needed sanctioning body for the next

iteration of a KQML-like language. Finally, the semantics issue is in practice much less

important than it sounds as long as the problem of defining and identifying conformance to the

semantics, is not resolved. But given the possibility that it might be impossible to find a

satisfactory solution to the latter problem, we will be left with a justifiable sense of

disappointment, as computer scientists, for a language that lacks formal, verifiable semantics.