address of the local host where the agent resides separated by an @ symbol. More information on the AID parameter can be found in FIPA (2002b).
5.8.3 Directory Facilitator (DF)
Whilst not being an essential component of a multi-agent system, the DF is a useful tool when developing multi-agent systems. It essentially acts as a yellow pages service, allowing agents to search for other agents that can perform the services that they require. This allows for a developer to create agents with different capabilities without the need to keep every agent updated on which agents can perform what service.
5.8.4 Agent Management System (AMS)
The AMS, as the name suggests, deals with the actual management of the agents in the AP. It is responsible for creating and deleting agents in the AP. It keeps track of all of the AIDs of all of the agents in the system, along with their current state.
5.8.5 Message Transport System (MTS)
The MTS is responsible for communications between agents on an AP using an agent com- munication channel (ACC). It also uses a message transport protocol (MTP) to handle the delivery of messages between APs if there are more than one. An ACC and MTP are anal- ogous to a national mail service and an aeroplane where the national mail service ensures the desired recipient receives their message and the aeroplane is a transport medium between countries. The MTS is further analysed in Section 5.9.
5.9
Agent Communication
Given the level of ambiguity about what an agent is, it would be possible to develop any kind of inter-agent communication protocol so long as both the sender and the recipient use the same encoding/decoding process. However, due to the nature of multi-agent systems being often difficult to design, implement and debug, a communication protocol that is illegible to the programmer can be problematical. For this reason, agent communication languages are predominantly based on speech act theory, (Searle, 1969), which posits that intent can be derived from simply specified performatives. This allows the system designer to be able to
5.9. Agent Communication 101
read and understand the messages being sent from one agent to another and decipher their meaning.
5.9.1 The FIPA Agent Communications Language (FIPA-ACL)
The FIPA Agent Communications Language (FIPA-ACL) (FIPA, 2002a) uses a set of per- formatives to define the kind of message that is being sent. The performative is the only required part of an ACL message. However, it is assumed that there will also be, at least, a sender, receiver and message content. Table 5.2 shows all of the fields that can be used in an ACL message.
Parameter Category of Parameters performative Type of communicative acts sender Participant in communication receiver Participant in communication reply-to Participant in communication
content Content of Message language Description of Content encoding Description of Content ontology Description of Content protocol Control of conversation conversation-id Control of conversation reply-with Control of conversation in-reply-to Control of conversation reply-by Control of conversation
Table 5.2: FIPA ACL message parameters. Adapted from FIPA (2002a)
The ACL messages are delivered by the message transport service (MTS), as described in Section 5.8.5 using a FIPA standardised message transport protocol (MTP). Details of the MTP are not covered; the inner workings of the protocol do not aide understanding of the developed systems. Detail can be found in FIPA (2002c).
5.9. Agent Communication 102 Envelope Payload Message Content Transport information Encoded message Message parameters Message content
Figure 5.4: FIPA message structure. Adapted from Bellifemine et al. (2007)
Despite the rigidity of this message structure, it is still necessary for agents to be sure that they can understand one another, so ontologies must be introduced to ensure that they all understand a parameter to mean the same thing. A note in FIPA (2002a) states that:
The ontology parameter is used in conjunction with the language parameter to support the interpretation of the content expression by the receiving agent.
There is no specification for the format that ontologies must take or even how they are interpreted by the agent. In the context of this work, ontologies have been employed to ensure that information communicated between agents is properly and appropriately interpreted and handled.
5.9.2 The FIPA Contract Net Protocol
Another of the FIPA standards is called the Contract Net Protocol FIPA (2002d), which gives agents a standardised method for negotiation. A diagram of the structure of this protocol is given at Figure 5.5. The terminology is explained in the text.
5.9. Agent Communication 103
Figure 5.5: Contract Net Protocol. From FIPA (2002d)
This structure allows for an agent (the Initiator) to shop around for a best price before accepting a service proposal. For this protocol to be useful it assumes that there is a single initiator agent and multiple participant agents take part.
Call For Proposals (CFP)
The initiator agent first sends out a call for proposals (CFP) message to all the participants to see which one can provide the service the initiator is requesting for the best price. It is assumed that the initiator knows the details of the participant agents and that they are able to provide the required service, whether this be from previous experience or using a DF service within the MAS itself. The CFP messages include a reply-by field which specifies a deadline by which proposals should be received.
5.9. Agent Communication 104
Proposals
Once a participant has received a CFP, it is up to them to decide whether to propose an offer to the initiator. The decision-making process for this action is unspecified, but if the participant decides to make an offer, and it is before the reply-by deadline, it replies with a propose message to the initiator. This message will usually contain a price, or utility, that the participant wishes to receive as payment which the initiator can then use to determine the best offer.
Handling Proposals
The next stage of the contract negotiation takes place when either all of the participants that were sent a CFP message have responded, or the deadline has passed. If the deadline has passed, then the initiator uses any proposals it has received, within the time-frame, to make a decision. Depending on the task that is being contracted out, it is possible for more than one participant to be selected for a task. However, usually only one participant is selected and, to them, an accept-proposal message is sent. To all of the other participants, a reject-proposal message is sent.
Informing the Initiator of the Result
At this point, the contract has been successfully negotiated and all that remains is for the participant to attempt to complete the task and report back to the initiator on the outcome. This can be done in three ways, depending on the nature of the task: a failure message if the the task is Boolean in nature and could not be completed; an inform-done message if the the task is Boolean in nature and has been completed successfully; an inform-result if the task is not Boolean in nature and has result that needs conveying.
Exceptions to the Protocol Flow
The participant in a contract net negotiation can, at any point, send a not-understood message to the initiator to cancel their involvement with the task. The initiator can also cancel the interaction by sending a cancel message using the same conversation id. This allows for both parties to reset the protocol to its initial state and prepare for a new negotiation to be initiated.