Transcription

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15 Towards developing multi-agent systems in Ada G. Aranda, J. Palanca, A. Espinosa, A. Terrasa, and A. García-Fornes Information Systems and Computation Dept. Technical University of Valencia, Spain Abstract. Agent-oriented technology is a rising paradigm for developing quality software in complex domains. Currently, no Ada interface or middleware exist for the development of agent-based applications. In this paper, an Ada binding for developing agent and multi-agent-based applications in Ada is proposed. This binding is compatible with an existing open-source agent platform named SPADE. 1 Introduction Agent-based systems are one of the most active areas of research and development in information technology. Many researchers believe that agents represent the most important new paradigm for software development since object orientation. The concept of agent introduces a high level of abstraction, which is appropriate to the development of complex computational systems, especially in open and dynamic environments. As shown in [1], software agents are generally presented as computational entities with a human behavior. They run on regular computers (i.e. PCs, PDAs, mobile phones, etc.) and in network nodes. They are autonomous and are able to take decisions for themselves, to reason, to learn, to communicate with other agents, to organize themselves, and to move from one node to another. They use their capacities to solve problems in an intelligent, pro-active and helpful way for the user. An agent can do this in a collaborative way (cooperating with other agents) or by itself. In this context, one of the most important topics to be considered is the development of technologies that provide infrastructures and supporting tools for agent systems, such as agent programming languages and software engineering methodologies. As stated in [2], any infrastructure deployed to support the execution of agent applications must be long-lived and robust. More generally, middleware, or platforms for agent interoperability, as well as standards, will be crucial for the medium-term development of agent systems. Over the last few years, several initiatives have appeared for the definition and standardization of agent technologies, such as KQML [3], OMG [4] or, more recently, the Agentcities Project [5]. Among these, one of the best known is FIPA (Foundation for Intelligent Physical Agents) [6]. This foundation has proposed some important aspects for agent communication, like platform interoperability or message transport protocols. This work is partially supported by the TIC C02-01 and TIN projects of the spanish government.

16 However, there is still a lack of maturity both in methodologies and programming tools. Current tools work well in straightforward situations with few agents; but, in general, they do not address the development of large-scale, efficient agent systems. These tools do not offer facilities for monitoring or tuning the behavior of such complex systems. In addition, languages for high-level programming of multi-agent systems are also needed. These languages should be expressive, easy-to-use, and efficient, in order to coordinate large, open, scalable, dynamic and heterogeneous systems. Agent technology displays very interesting features and new approaches to solve problems. But in practice, the agent community has limited itself to the use of very few computer technologies. Nearly all the relevant agent-based products and developments are done in the Java programming language. Moreover, these products generally operate in a way that only agents programmed in Java are compatible with them. In order to contribute to cover part of this gap, we have developed SPADE [7]. SPADE (Smart Python multi-agent Development Environment) is a fully FIPA compliant agent platform. Its main objective is to provide good performance while retaining strong scalability options and to provide an open design that allows the implementation of platform components and agents in several high-level programming languages. The work presented in this paper is to provide the means to allow the development of SPADE agents with Ada, and to propose the necessary middleware to do so. This middleware allows the Ada and agent technologies to be integrated with each other, effectively combining the advantages of both. On the one hand, the development of agents can benefit from the use of Ada in cases when safety, reliability or real-time features are needed. On the other hand, Ada engineers can benefit from the higher level of abstraction of the agent-based technology. For example, in cases when high-level communication protocols enabling complex interactions are useful; or when abstractions more complex than the inheritance are needed; or when developing heterogeneous systems which require the integration of different technologies (such as databases, web applications, software components, etc.). The rest of the paper is structured as follows. In Section 2, a review of the SPADE agent platform is done. Later, in Section 3, a programming interface to develop agents for the SPADE agent platform with the Ada programming language is introduced. Finally, conclusions and future work lines are presented. 2 SPADE SPADE is a multi-agent platform which provides a new framework to build agents using a communication model different from other platforms. This platform provides a simple interface for the agent development using the above-mentioned communication model. Thanks to this interface, agents can be built in any programming language with total independence of the SPADE platform. As every component inside the SPADE platform has been developed as an agent, this communication model is also used to communicate the internal elements of the platform. In addition, SPADE has a special agent to provide a user-friendly view of the platform. This GUI agent provides a mechanism to load and unload agents in the platform.

17 It allows the user to search for agents and services and to send messages to any agent. This feature can be used as a dummy agent to send simple messages to other agents and to show their answers. The basic SPADE components have been developed using the Python programming language. It is a versatile interpreted language that runs on several architectures and operating systems, although it has a poorer performance than compiled languages like Ada or C. In particular, being implemented in Python allows the platform to be executed in systems such as Windows, Linux, MacOS, Windows Mobile, PalmOS, SymbianOS (for mobile phones), etc. The core of the communication layer of the platform is a standard, well-known protocol called Jabber[8], which provides virtual channels to put in contact conversational entities, like agents. The most popular application of the Jabber protocol is a social communication network with similar functionalities to the ones present in legacy systems like AIM, ICQ, MSN or Yahoo Messenger. These networks allow for the interconnection of known users by means of trust networks, and are tested and used by thousands of users simultaneously every day. The Jabber protocol uses a distributed client-server topology. The servers that route the Jabber messages are designed to support a very large number of users and messages. This feature helps to improve the SPADE performance and scalability. The interface between the SPADE platform and its agents is purely Jabber-based (in fact, TCP/IP-based at its lowest level). Therefore, SPADE agents can be implemented with any framework that supports Jabber communications and with any programming language capable of dealing with Jabber and/or TCP/IP communications. To ease the development of SPADE agents, we provide the necessary code-base to develop agents in the Ada and Python programming languages. Besides using the Jabber protocol, SPADE also supports the HTTP protocol, which is used in other agent platforms. The following sections introduce the different models that compose SPADE. 2.1 The Platform Model The SPADE platform is modeled according to the FIPA standard proposal for a multiagent platform [6]. It features the standard basic FIPA services (such as an Agent Management System and a Directory Facilitator), which have been designed as Jabber server components (or add-ins). Although the core communication system relies on the Jabber technology, other legacy message transport protocols, such as the HTTP protocol, are also supported. Platform Elements In this section, the elements that make up the SPADE platform are described. The XML Router is the main platform element, the one that the rest of the platform components and agents are connected to. It is a standard XMPP server[8] that routes all the messages from its sender to the specified receiver without having the user to intervene. This XML Router acts as the Message Transport System (MTS) and

18 it is the only external component of the platform that has been reused. It has been chosen for its flexibility: this component can be replaced with no re-writing of any other component, so the developer is free to replace it with any other XML Router of choice. One of the components connected to the router is the SPADE Agent Communication Channel (ACC). It manages all the communication within the platform and receives the FIPA-ACL 1 [9] messages that arrive to the platform. After arrival, it redirects the messages to the correct destination element. This destination can be either an agent or another component. Should the receiver element is an agent, the MTS would relay the message to the agent and it would be held in the agent s message queue for later processing. A default Message Transport Protocol (MTP) is built within the platform. In addition to internally connecting the platform elements, the XML Router is the element that connects the platform to outside entities (like other platforms or even humanagent communications). The Agent Management System is the component that implements the basic management services for the agents. The AMS agent complies with the entire fipaagent-management ontology. The Directory Facilitator is a component that provides a service directory to register and query services offered by the agents that are registered at the platform. The DF agent also complies with the fully fipa-agent-management ontology. A brief schematic view of the SPADE Platform can be seen in Figure 1. Fig. 1. SPADE Platform and Agent Models There is a graphical block that represents the MTS (using the Jabber protocol) which handles all the received messages and redirects them to their actual receivers. A receiver 1 FIPA Agent Communication Language

19 can be an agent, a platform component, or even a human user. Moreover, control information (iq queries) and routing information are managed by the MTS. The ACC, AMS and DF elements are plugged into to the platform as modular components. Besides, all of them are built as agents, so they have the full functionality provided by a standard SPADE agent. As it can be seen in the figure, agents are also connected to the MTS, which virtually connects them with the SPADE Platform. 2.2 The Agent Model As mentioned above, every component inside a SPADE platform is built as an agent. SPADE agents are elements connected to the MTS that can send messages to each other and to other platforms (or even to human users). The Agent Model of SPADE is basically composed of a connection module to the platform, a message dispatcher, and a group of different behaviors that the dispatcher gives the messages to ( see Figure 1). Every SPADE agent needs an identifier called Jabber ID (JID) and a correct password to make a connection with the platform. Should the default platform registration process be disabled, the platform administrator would have to define alternate registration policies. The JID is composed by a username, and a server domain. It will be the internal name that identifies an agent in the platform. The agent virtual address (which is another important field on the Agent Identifier) would be the JID of the platform s ACC (i.e: xmpp://acc.gti-ia.dsic.upv.es). The prefix xmpp:// has been defined for the XMPP addresses. A behavior is a task that an agent can execute using scheduling patterns. A SPADE agent can run several behaviors simultaneously. SPADE provides some predefined behavior types: Cyclic, One-Shot, Periodic, Time-Out, and Finite State Machine Behavior. These behavior types help the implementation of the different tasks that a SPADE agent can perform: A behavior has a message template associated to it. The message dispatcher uses this template to know which types of messages a behavior must receive: it compares every arriving message with the templates of the behaviors. Every SPADE agent can have as many behaviors as wanted. When a message arrives to a SPADE agent, the message dispatcher forwards it to the message queues of the adequate behaviors ( see Figure 1). 3 Ada Application Programming Interface As stated above, SPADE agents can be developed by default using Python (like the core platform components). Now, we introduce the possibility of developing SPADE agents in Ada. In this section, the programming API for creating a SPADE agent with Ada is presented. The structure of the application interface is shown in Figure 2. There are 8 packages included in a main package called Spade.

20 Fig. 2. SPADE Package Structure 3.1 Package Spade Spade is the main package that contains the rest of the application interface packages. It also includes some basic Ada types to help in common operations (like String lists). 3.2 Package Spade.Aids This package provides the interface to build Agent Identifiers (called AID). An Agent Identifier is a record composed by the name of the agent, its addresses (an agent can have more than one address). The interface provides an Ada type called Aid and some Set and Get procedures to manipulate Agent Identifiers. package Spade.Aids is type Aid is private; function Get Name ( From: Aid ) return Aid Name; function Get Addresses ( From: Aid ) return List Addresses; function Get Resolvers ( From: Aid ) return List Resolvers; procedure Set Name ( To : in out Aid; Name: in Aid Name ); procedure Add Address ( To : in out Aid; Address: in Address ); procedure Add Resolver ( To : in out Aid; Resolver: in Resolver ); end Spade.Aids; 3.3 Package Spade.Basic Fipa Date Times This package provides a help class to manage dates and times in the FIPA standard format. This format is a string composed by the year, the month, the day, a separator, the hour, minutes, seconds and milliseconds with 3 digits (e.g T ). An example of the API is as follows. package Spade.Basic Fipa Date Times is type Basic Fipa Date Time is tagged private; function Get Day ( From: Basic Fipa Date Time ) return Day;

21 function Get Milliseconds ( From: Basic Fipa Date Time ) return Milliseconds; procedure Set Day ( To: in out Basic Fipa Date Time; Day: in Day ); procedure Set Milliseconds ( To: in out Basic Fipa Date Time; Milli: in Milliseconds ); procedure From String ( To: in out Basic Fipa Date Time; String Date : in String ); function To String ( From: Basic Fipa Date Time ) return String; end Spade.Basic Fipa Date Times; 3.4 Package Spade.Envelopes A FIPA Message is a structure that contains a Payload and an Envelope. The payload has the content of the message and some meta-information. This payload can be in some different languages (like ACL). The envelope contains the routing information for the message like the receiver, the sender, the encoding, the date, etc. A brief example of some of the interface methods is now shown: package Spade.Envelopes is type Envelope is tagged private; function Get To ( From: Envelope ) return List Aid; function Get From ( From: Envelope ) return Aid; function Get Comments ( From: Envelope ) return String; procedure Set Payload Length ( To: in out Envelope; Len : in Length );... end Spade.Envelopes; Package Spade.Acl Messages The package Acl Messages contains the Ada type Acl Message, used to build the payload of a FIPA Message. This payload has the content of the message and some meta-information like the language and ontology of the content, or the performative. package Spade.Acl Messages is type Acl Message is tagged private; function Get Conversation Id ( From: Acl Message ) return Id; procedure Set Language ( To: in out Acl Message; Lang: in Language ); procedure Set Ontology ( To: in out Acl Message; Onto: in Ontology ); Creates a reply of the message function Create Reply ( From: Acl Message ) return Acl Message; end Spade.Acl Messages; Once Envelopes and Acl Messages packages are viewed, it is possible to build a FIPA Message, which is the basic communicative structure used by agents. Sending

22 messages of this kind between FIPA compliant agents (like SPADE agents) ensures the success of a communicative act. 3.6 Package Spade.Message Receivers This package provides the Message Receiver type. Objects of this type are entities capable of sending and receiving messages. This tagged type is extended by other packages (like agent or behavior) that will be introduced later. package Spade.Message Receivers is type Message Receiver is tagged private; function Is Alive ( Who : Message Receiver Class ) return Boolean; function Receive ( From : Message Receiver Class ) return Acl Message; function Blocking Receive ( From : Message Receiver Class; Time Out: Time) return Acl Message;... end Spade.Message Receivers; 10 The Receive and Blocking Receive functions return an Acl Message when a message arrives to a Message Receiver. If there is no message in the inbox, it returns an empty Acl Message. The function Blocking Receive also accepts a Time Out parameter. This parameter indicates the time (in seconds) that the function will wait for a message (it can also be forever). 3.7 Package Spade.Behaviors Agents are entities composed of SPADE s behaviors. These behaviors are supposed to provide the intelligence to the agent. Programmers must implement these behaviors and add them to the agent to compose the brain that controls the agent. The package Spade.Behaviors contains the five behaviors currently supported by SPADE: Behavior: This is the Cyclic Behavior type. Its code is executed continuously. Periodic Behavior: The Periodic Behavior type runs every user-defined period. One Shot Behavior: One Shot Behavior type. Runs only one time. Time Out Behavior: The Time Out Behavior type is a Periodic Behavior with a timeout. It is executed every period with a time lag (the timeout). FSM Behavior: Finite State Machine (FSM) Behavior type. It runs different behaviors according to a defined FSM. The nodes of the FSM are behavior types (which can be any kind of behavior: cyclic, one shot or even another FSM). The transitions between nodes are called events. Each of these events has a value which is the exit codes of a behavior node. Figure 3 shows the Types Hierarchy. Some of the presented classes are simply support classes with access methods to manage FIPA information structures. However,

23 more interesting Ada types (such as the hierarchy of Behavior types) provide a full interface to create software agents with a simple middleware. The next block is an example of the behavior interface. package Spade.Behaviors is type Behavior is new Message Receiver with private; function Exit Code ( From: Behavior Class ) return Integer; Executed when the behavior finishes procedure On End ( From: in out Behavior Class ); Executed when the behavior starts procedure On Start ( From: in out Behavior Class ); Executed when the behavior is running procedure Process ( From: in out Behavior Class ); 10 type Periodic Behavior is new Behavior with private; function Get Period ( From: Periodic Behavior ) return Time; procedure Set Period ( To: in out Periodic Behavior; Period: in Time ); procedure On Tick ( From: in out Periodic Behavior ); type Time Out Behavior is new Periodic Behavior with private; function Get Time Out ( From: Time Out Behavior) return Time; procedure Set Time Out ( To: in out Time Out Behavior; Time Out: in Time); type One Shot Behavior is new Behavior with private; 20 type FSM Behavior is new Behavior with private; procedure Register First State (From: in out FSM Behavior; State: in Behavior Class; Name: in String); procedure Register Last State (From: in out FSM Behavior; State: in Behavior Class; Name: in String); procedure Register State (From: in out FSM Behavior; 30 State: in Behavior Class; Name: in String); procedure Register Transition (From: in out FSM Behavior; From Node: in String; To Node: in String; Event: in Integer);... end Spade.Behaviors; Examples of use of such behavior interface range from simple to really complex agents. For instance, agents mostly reactive that perform quick responses to environment changes can be developed using a reduced number of behaviors executed in a cyclical scheme with a short period. On the contrary, agents displaying a sophisticated and deliberative (intelligent) functionality can be implemented by using a higher number of behaviors of more complex types, like finite state machines.

24 A behavior executes the code defined in the procedure Process. In addition, procedures On Start and On End are run when a behavior is created and finishes (or it is killed), respectively. Fig. 3. SPADE Class Hierarchy 3.8 Package Spade.Acl Templates A behavior can be configured to receive only the messages that match with a defined template. When a message arrives to an agent, the message dispatcher of the agent puts the received message in the inbox of the behaviors which template matches. If there is no match, the message is sent to a default behavior (defined with the Behaviors.Set Default Behavior procedure). The interface is very similar to the Acl Messages package. package Spade.Acl Templates is type Acl Template is tagged private; function Get Sender(From: Acl Template) return Aid; function Get Conversation Id(From: Acl Template) return Id; procedure Set Performative(To: in out Acl Template; Perf: in Performative);... end Spade.Acl Templates; The procedure Behavior.Add Template is used to add a template to a behavior.

25 3.9 Package Spade.Agents Finally, the agent interface is now introduced. There is a basic type called Basic Agent from which the two agent types are inherited. There is a Platform Agent type for internal purposes (like component agents: AMS, DF, etc.) and a simple Agent type, used to develop user agents. This hierarchy can also be viewed in Figure 3. The interface is now shown: package Spade.Agents is type Basic Agent is new Message Receiver with private; function Get Aid(From: Basic Agent Class) return Aid; procedure Start (What: in out Basic Agent Class); procedure Take Down (What: in out Basic Agent Class); procedure Setup (What: in out Basic Agent Class); procedure Kill (What: in out Basic Agent Class); procedure Add Behavior (To: in out Basic Agent Class; Behav: in Behavior Class; 10 Template: in Acl Template); function Search Agent (From: Basic Agent Class; Template: Ams Agent Description) return List Ams Agent Description; procedure Register Service (From: in Basic Agent Class; Service: in Df Agent Description); procedure Send Message (From: in out Basic Agent Class; Env: in Envelope; Message: in Acl Message); 20 type Agent is new Basic Agent with private; type Platform Agent is new Basic Agent with private;... end Spade.Agents; Finally, the following code contains an example of use of this interface. The example creates an agent and two behaviors that are included into the agent Then it is started. An Agent: Agent; Behavior One: Periodic Behavior; Behavior Two: One Shot Behavior; A Template: Acl Template; Set Default Behavior (To => An Agent, Behav => Behavior One); Add Template (To => Behavior Two, Template => A Template); Add Behavior (To => An Agent, Behav => Behavior Two); Start (What => An Agent); 10

26 4 Conclusions and Future Work A middleware that allows the development of intelligent agents using Ada has been developed. This middleware focuses on creating Ada agents that are compatible with the SPADE agent platform. The middleware s API is object-oriented, which is a paradigm fully supported under Ada. This middleware opens the possibility of creating agents in Ada, which is a very interesting topic since it allows bringing the advantages of Ada to the agent realm and vice-versa. Robust and stable agents can be created due to Ada s proved robustness. In scenarios where performance is a key element, Ada can show its celerity against interpreted languages (like Python) or Virtual Machine-based ones (like Java). Moreover, due to Ada s fitting in the real-time domain, the possibility of developing real-time SPADE agents with Ada is now opened. In the future, we intend to study the behavior of this software solution, from both the efficiency and the scalability points of view. Our intention is to perform tests to compare the performance of agents built using this middleware against SPADE agents implemented in other programming languages, and also against agents developed in different agent platforms. References 1. Mas, A.: Agentes software y sistemas multiagente. Pearson Educacion (2005) 2. Luck, M., McBurney, P., Shehory, O., Willmott, S.: Agent Technology Roadmap. A Roadmap for Agent Based Computing. AgentLink III (2005) 3. Finin, T., Fritzson, R., McKay, D., McEntire, R.: KQML as an Agent Communication Language. In Adam, N., Bhargava, B., Yesha, Y., eds.: Proceedings of the 3rd International Conference on Information and Knowledge Management (CIKM 94), Gaithersburg, MD, USA, ACM Press (1994) Object Management Group: OMG: Object Services - Request for Information. RfI (1991) 5. : AgentCities Homepage. (2005) 6. FIPA: Abstract architecture specification. Technical Report SC00001L (2002) 7. : Smart python multi-agent development environment. (2005) 8. Jabber Software Foundation: Extensible Messaging and Presence Protocol (XMPP): Core. Technical report, (2004) 9. FIPA: Agent ACL message structure specification. Technical Report XC00061E (2001)