In the same way that the different entities of a distributed application have to exchange messages, agents need to communicate during their operation, albeit at a higher-level of abstraction. Agents may communicate using different mechanisms. We expose in the following sections different levels of communication capabilities starting from indirect communication to general-purposeAgent Communication Languages(ACL).
For any agent communication mechanism, three levels must be considered (Fig-ure 2.2). Firstly, there is a need for a network-level transport protocol, which can be any suitable protocol ranging from raw TCP or UDP, to Java RMI or CORBA IIOP. Other inter-mediate protocols can also be used such as SMTP or HTTP. Secondly, a communication
:receiver
protocol is required to specify general header information concerning the message such as the names of the sender and receiver agents, the context of the message within a con-versation thread and the intention behind sending the message. This is the purpose of theAgent Communication Language. Finally, the content of the message itself is speci-fied using aContent Language. The content language should be suitable for the subject of conversation between the agents.
However, all of these three layers are not necessarily present in all the agent systems.
This depends on how rich the agent communication is required to be in the target agent-based application.
Indirect Communication In some agent applications, agents may not need to commu-nicate directly. Instead, they exchange information indirectly by modifying the status of the environment. This is the approach used in general with biologically inspired agents (see Section 2.2.3), which communicate using simulated chemical signals that they de-posit on their paths.
Indirect communication is therefore a primitive kind of communication. Its main advantage is robustness and simplicity.
Ad Hoc Agent Communication Some agent applications may use proprietary commu-nication languages. This means that the transport protocol, the message syntax and con-tent language are tailored to meet exactly the objective of the application. Moreover, the three layers of agent communication shown in Figure 2.2 are mixed up altogether and cannot be distinguished. Such approach might be easier to implement and more effi-cient for a particular given agent application. Its main drawback is that it does not allow for interoperability between agents designed for different systems.
2.4.1 General-purpose and Standardized Agent Communication Lan-guages
A structured communication protocol can be used such as KQML (Knowledge Query Ma-nipulation Language) [LF97, FW91] or FIPA (Foundation for Intelligent Physical Agents) ACL (Agent Communication Language) [ACL99]. Such agent communication protocols are based on the speech act theory [Sea70], which attributes intentions,communicative actsorperformativesto the messages exchanged between the agents.Tell,ask,achieve are examples of possible performatives. The advantage of KQML and ACL is that they are completely independent of the message transport protocol and the message con-tent. KQML and ACL provide a means to structure exchanged agent messages in com-municative acts with well specified semantics. Approaches based on KQML and ACL are supposed to provide a high degree of interoperability and openness in agent based ap-plications.
For a comparative analysis of KQML and ACL and further references, the reader is referred to [LFP99].
Note also that there are many variations based on KQML and the speech act theory in general proposed for particular agent applications. For example, COOL, which is a KQML-based coordination language, proposes a set of performatives which enable ne-gotiation and coordination in multiagent systems [BF96]. Also, JAFMAS [Cha97] extends KQML with new performatives such asproposeandrejectto support agent coordina-tion.
2.4.2 Content Languages
KQML and FIPA ACL are neutral regarding the content language. This means that any general-purpose content language that allows the exchange of knowledge between agents such as Lisp, Prolog or SQL can be used. There are three major proposals for con-tent languages in literature.
The Knowledge Interchange Format (KIF) is a declarative Lisp-like language [GF92].
The language definition includes both a specification for its syntax and another for its se-mantics. It allows to express simple and more complex data, logical expressions, knowl-edge, knowledge about knowledge and procedures. Its main advantages are readability and translatability to and from typical knowledge representation languages. KIF is often combined with KQML.
The second proposal is the FIPA’s Semantic Language (SL). Originally, SL was used to formally define the semantics of ACL (Agent Communication Language) performatives.
As such, SL is also appropriate for use as a content language. FIPA defines three profiles
for SL: SL0, SL1 and SL2. SL0 is the minimal subset of SL, SL1 extends SL0 by adding propositional expressions, while SL2 is another restricted subset (see [ACL99] for more details).
Another increasingly proposed content language is the eXtended Markup Language (XML) [BPSM98]. Data Type Definition (DTD) files are used to define the data types that can be used in XML messages. The main advantage of XML is that it is a state-of-the-art web-directed language. XML-based content languages are gaining increasing success in the agent community.
2.4.3 Ontologies
Both KQML and FIPA ACL contain anontologyfield associated to the contents of the ex-changed messages. Theontologyallows to interpret the content of the message accord-ing to a certain subject or field [Gru93]. In practice, this is mainly useful in situations where confusion may arise when the same vocabulary used in agent messages can be understood with different meanings according to the topic of the dialog.
Ontologies are also useful to provide a basic shared knowledge that allows agents tackling the same application domain (e.g. network management, enterprise business workflow, etc.) to seamlessly communicate together. The ontology formally describes the semantics of the vocabulary used in a certain domain, which allows agents to cor-rectly interpret messages related to this particular domain. More references about agent ontologies can be found in [Gru93, GF92, NW96].
2.4.4 Relevant Aspects in Inter-agent Communication
Besides the communication language aspects described above, other design issues have to be considered when agents communicate.
Synchronous/Asynchronous Messages An agent communication mechanism can be either synchronous or asynchronous. When synchronous communication is used, an agent processes the incoming messages as soon as they are received. Each agent includes a thread that listens to incoming messages, processes them, and promptly initiate replies whenever needed.
When asynchronous communication is used, the agent does not constantly listen to incoming messages. Instead, incoming messages are stored in a given repository, e.g. a mailbox, or a message queue. The agent then has to check for these messages from time to time during its execution. There is no beforehand knowledge about when a message
will be processed by the receiver agent. Asynchronous communication can be imple-mented using several mechanisms such as the blackboard or a mailbox.
Let’s note that both synchronous and asynchronous communication do not suppose any underlying communication content language. As an example, both mechanisms can be used with a KQML-like language as well as with a proprietary application-specific lan-guage.
Note however that asynchronism is used with a different meaning in KQML and FIPA ACL (Agent Communication Language). A synchronous communication in their context means that the sender agent has to synchronously wait for the reply of the receiver. This applies for example to querying performatives. Conversely, an asynchronous communi-cation means that the initiator of a dialog may receive asynchronous unsolicited replies from the receiver agent. This applies for example when the sender subscribes for certain change notifications, which are sent back asynchronously by the receiver agent when they occur.
Reliability In an unreliable network such as the Internet, agent messages are not guar-anteed to reach their destinations. The question to be asked in this case is: Does the agent application tolerate message loss or not? The approach adopted in FIPA ACL (Agent Communication Language) is to assume that messages are delivered reliably and orderly [ACL99]. But this might not be the case in many practical applications. If mes-sage transportation is not reliable, then mechanisms that detect lost mesmes-sages should be included in the agent behavior. In general, since agent communications are considered as acts, the failure to send a message, or to receive an expected reply, is considered as a failure in the agent course of action. The agent should include dedicated behaviors when it fails to achieve a certain action, and in the particular case of a communication actions, to recover from unexpectedly interrupted communication threads.
Time Aspects In many cases, the message transmission time cannot be neglected by the agents. For example, if a sender agent communicates real-time information to a re-ceiver agent, then the rere-ceiver should be aware that this information can be out-of-date by the time it is delivered. Time aspects are not explicitly considered in FIPA. However, in time-sensitive applications agents have to cope with transmission delays (for example, using timestamps).
Direct and Indirect Communication Another important factor is that agents may not in reality communicate directly, but use an intermediate entity instead. This is the case for KQML and FIPA ACL (Agent Communication Language), which make use of
facilita-torsthat play the role of message forwarders orrouters. Facilitators, by their role, provide registration, naming and location services for agents in the same domain or region. In addition, they provide a suitable means to support multicast agent communication by the definition of groups of interest or agent regions.
The blackboard mechanism can also be used for indirect agent communication. The principle of the blackboard is that any agent can write messages that can be read by the other agents.
Such facilitations are certainly valuable to ensure flexibility, dynamism and support for group communications in the multiagent system. In these cases however, special care should be addressed to scalability concerns.