Personal Travel Assistant A Multi-Agent Approach

Transcription

1 BABEŞ-BOLYAI UNIVERSITY CLUJ-NAPOCA FACULTY OF MATHEMATICS AND COMPUTER SCIENCE SPECIALIZATION COMPUTER SCIENCE DIPLOMA THESIS Personal Travel Assistant A Multi-Agent Approach Supervisor Prof. univ. dr. Czibula Gabriela Author Dîncu Andra 2012

2 TABLE OF CONTENTS INTRODUCTION CHAPTER 1: Multi-agent systems What is an agent? Uses of agents Multi-agent systems and their advantages Communication in multi-agent systems Societies of agents Multi-agent systems in e-travel CHAPTER 2: Agent development environments Agent oriented programming languages Agent Jack intelligent agents Open Agent Architecture FIPA Agent communication Agent management Abstract architecture JADE JADE architecture JADE tools Remote Monitoring Agent The Dummy Agent The Sniffer Agent The Introspector Agent JADE features Creating agents Agent behaviors Agent communication The Yellow Pages Service 25 CHAPTER 3: Our approach to a multi-agent system for e-travel Existing e-travel projects. Related work The system s architecture Stationary agents approach Mobile agents approach The agents roles

3 3.3.1 Personal Travel Assistant Retrieving the request from the user Showing the results to the user Learning the user s preferences Coordinator Agent Web Agent Coordinator Mobile Agent..35 CHAPTER 4: The application Problem description and analysis Usage scenario Analyzing the learning behavior Design Class diagram The sequence of operations Implementation Personal Travel Assistant Coordinator Agent Web Agent Coordinator Mobile Agent Evaluating the architectures: mobile agents vs. stationary agents Comparison to related work Further improvements.55 CONCLUSIONS.57 BIBILIOGRAPHY. 58 2

4 INTRODUCTION Imagine that you want to travel to Paris this weekend. The first thing you would think of doing would be to contact a travel agent, present him all your preferences regarding the trip, and then wait for the response that meets your specifications. It does not seem that hard, but after you asked the agent for some offers, he will call other agents representing hotel companies, transport companies and other agents in the same area. There are just a few calls to make, but it would be easier if all this work could be done at home or from your mobile device, automatically, with the help of only one application, an application that in time would manage to know your preferences and offer you results that are more suitable. The goal of our work is to create a proper system that can act as a personal assistant for the user and which can become useful to him when looking for travel related elements. The system s aim is to act in a similar manner to a travel agency, providing the required data and in the same time trying to personalize the results as much as possible based on the accumulated knowledge on the user s profile. Due to the similarities with a travel agency, the project will be approached as a multiagent system. Based on interaction and communication, the agents will manage to create a proper environment to satisfy the goal of our work. In addition, to underline the personal part of the project a learning algorithm was used in order to create the user s profile and make the agent capable of knowing the user s preferences. In this paper we propose two flexible architectures for such a system, evaluating and comparing the two possible approaches: one based on stationary agents and one that uses mobile agents. To our knowledge, mobile agent based architecture for e-travel has not been proposed in the literature, so far. The rest of the paper is structured as follows. The first chapter describes the main aspect of the project, agents and the multi-systems, briefly presenting their basic characteristics, their importance and the domains they can be used in. In the second chapter, agent oriented programming along with agent development environments are described, focusing on the FIPA compliant framework, JADE (Java Agent 3

5 Development Framework) which helped us into building a stable and extendable system. In this chapter, we will also underline the reasons why JADE represents the proper framework for developing such projects. In chapter three, we introduce our approaches at designing the architecture by describing both the stationary agent approach and the one based on mobile agents. After describing the two approaches, we come with a comparative analysis between them in order of finding out which is more suitable in this context. In addition, some of the related projects are presented here. Chapter four presents the main aspects of the application s development that appear when implementing the multi-agent system with the aid of JADE framework. We have to mention that the original part of this thesis was the subject of a research paper presented at the Students Scientific Communications Session in 2012 organized by Babes-Bolyai University and Technical University from Cluj-Napoca, and also published in the proceedings of the event. 4

6 CHAPTER 1 Multi-Agent Systems This chapter aims to introduce the subject of agents and multi-agent systems, to describe them and to underline their main characteristics. Furthermore, this chapter shows the link between multi-agent systems and other areas such as e-tourism or e-travel. 1.1 What is an agent? In the context of multi-agent systems, the first thing that needs to be done would be to define the term agent. Unfortunately, there is no universal definition of an agent varying from one author to another. One such definition is given by S.Russel and P.Norvig in [20] stating that an agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors. This claims that agents can come in any form, so human beings as well as robots can be agents. Another definition given to the term agent is suggested by M. Woolridge [28] in the following form: An agent is a computer system that is situated in some environment, and that is capable of autonomous action in this environment in order to meet its design objectives. A concept that appears here is the autonomy aspect which means that the agents have control over their behavior as well as its internal state based on its own experience. An abstract view of an agent is designed in Figure 1 (see Figure 2.1 from [28]). The agent takes the input from the environment through its sensor and then its actions produce the output that affects the environment. Figure 1. An agent in its environment (See Figure 2.1 from [28]) 5

7 In both definitions, the environment or the place where the agents are located in represents a central aspect of agent modeling. The complexity of the agent s design process can be affected by the environmental properties. According to Russel and Norvig [20], these properties can be classified as follows. Accessible vs. Inaccessible An environment considered accessible is one in which the agent can obtain accurate, correct and complete data about. The majority of the real-world environments, like the Internet, are considered inaccessible. Deterministic vs. non-deterministic We speak of an deterministic environment when the action has only one guaranteed effect over it, knowing the exact state that will be produced by performing that action. The real world as well as the majority of environments is non-deterministic. Episodic vs. non-episodic We say that an environment is episodic if the performance of the agent is dependent on a number of discrete episodes, with no link between the performance of the agent in different episodes [28]. Static vs. dynamic A static environment is one that does not change while the agent is still deliberating its next action, otherwise the environment is considered dynamic. Discrete vs. continuous A discrete environment is one that has a finite and clearly defined actions and percepts in it. As stated in [20] the class of environments that is the most complex and general is given by the inaccessible, non-deterministic, non-episodic, dynamic and continuous environments. Agents are used in different domains, thus many examples of agent could be presented. One of the most simple is the thermostat. Thermostats can determine the temperature in the room through its sensors. If the temperature is too high or too low, it produces an output for indicating this and an action of raising or decreasing the room s temperature will be started. Any other similar control system can be seen as an agent. 6

8 When thinking at the Artificial Intelligence domain, one question that pops into our minds is What is intelligence? a question not so easy to answer. In this context, we want to describe what are the intelligent agents. Wooldridge [28] defines the intelligent agents as the ones that pursue their objectives through flexible autonomous actions. The flexibility is defined by reactivity, pro-activeness and social ability. Reactivity refers to the fact that the intelligent agents are capable of interacting with the environment they are placed in by perceiving and acting upon it. The second property that gives the agent its flexibility is pro-activity. This is defined by the agent s capability of starting actions at his own initiative in order to satisfy its design objectives. The third property is the social ability that makes the agent capable of interacting with other agents, even human agents, via a communication language in order to accomplish its goals. There are different types of software systems, some being more difficult than others are. The simplest software systems are the functional ones, these work by taking some input, computing a function of it and giving back the result [16]. This class of systems include compilers. Opposite to them, there are the reactive systems, which maintain a continuous interaction with the environment. Here, process control systems, computer operating systems and computer network management systems are included. As stated in [16], reactive systems are some of the most complex types of system to design and implement, therefore a lot of time and effort has been invested into developing programming languages, software tools and methodologies for managing this complexity. Even if such tools were created, there are certain types of reactive agents for whom the tools fail, thus new techniques being required. These systems can be divided into three classes: open systems (its structure is capable of dynamically changing), complex systems (and ubiquitous computing systems. 1.2 Uses of agents Agent applications can be classified from various points of view such as the technology used or the application domain itself. The domain type classifies the following described agent applications. Industrial applications were among the first developed and this include a wide range of applications such as the ones described in [16]: 7

9 Process Control is a natural application for agents and multi-agent systems since they are themselves autonomous and reactive systems. The most popular system of this type is ARCHON. Manufacturing a manufacturing enterprise is modeled as a hierarchy of workcells. Each of these workcells will have a functionality such as assembly, buffering of products, etc. [16]. Air Traffic Control one such system is OASIS. In this system agents are used to represent the aircraft and the various air traffic control systems. An agent is allocated to every aircraft entering Sydney s airspace with the basic knowledge and goals corresponding to the real-world aircraft. Commercial applications include: Information management Since the diversity of the information resources has grown, the need of managing it has increased as well. The information overload problem has increased due to the lack of effective information management tools. Information filtering and information gathering characterize this problem. Projects developed in this direction are Maximis, Newt and The Zuno Digital Library. Electronic commerce represents the automation of human activities in the commerce area. In this direction, commercial decision making can be placed in the hands of agents. Business Process Management represent IT systems that assist with various aspects of their business process. Project ADEPT has been developed to solve this problem by viewing a business process as a community of negotiating, serviceproviding agents. Medical applications are the ones from the health industry, two of these applications are: Patient monitoring used for managing and monitoring patients, job usually done by doctors or nurses. Health care include prototype systems that were designed in this direction in order to integrate the patient management process, which typically involves many individuals. 8

10 The Entertainment domain can also be developed through agent technologies. Even though this domain s applications are frequent considered peripheral to the serious applications, agents have a well-defined role is their development because these systems tend to be full of semi-autonomous animated characters which can naturally be regarded as agents [16]. Here we can find: Games are activities which require other entities to either work with or against the human player under a set of well-defined rules. For a game to be entertaining the agents must be intelligent enough to play at a decent level. Interactive Theater and Cinema represents a system in which the user plays a role similar to the real life roles of actors from theater or cinema. The agents playing the part of humans in these applications are called believable agents. 1.3 Multi-agent systems and their advantages Agents live in open or closed environments that might or might not contain other agents. Even if there are situations when an agent can operate by itself, nowadays these situations become rare due to the increasing interconnection and networking of computers thus being more convenient to deal with a society of agents [27]. For defining and managing these societies of agents, distributed artificial intelligence appeared as a sub domain of artificial intelligence. Distributed artificial intelligence (DAI) is split into two sub domains according to P. Stone in [25]: distributed problem solving (DPS) and multiagent systems (MAS). In DPS, the problem is split into several sub problems not necessarily independent, computed and then put back together in order to give the solution to the original problem. Multi-agent Systems [27] represent a collection of intelligent agents living in the same environment who can interact, communicate, negotiate and coordinate in order to achieve their goals. MAS are usually used for solving problems that are too complex for only one agent to solve. According to Sycara [26], multi-agent system has the following characteristics: Each agent has incomplete information or capabilities for solving the problem and, in addition, it has a limited viewpoint. It lacks the global control so there is no centralized designer for the system. The data is decentralized, each agent having its own information about the environment. 9

11 The computation is done asynchronous. Even though there are situations when a multi-agent system is not required, there also are ones when even the domain of the represented scenario suggest the usage of such systems giving us reasons to use them. As stated in [26], there are a couple of motivations regarding the interest in MAS, including: solving the complex problems that are too large for a single agent to solve; providing solutions to problems that can be regarded as societies of agents, to problems that use spatially distributed resources or to problems where the expertise is distributed. In addition, the multi-agent systems are used to increase the performance of the solution in several directions: greater computational efficiency given by concurrency; increased reliability because agents with redundant capabilities are dynamically found; extensibility given by the possibility of altering the agents capabilities; robustness due to the suitable information exchanged between agents; maintainability given by the modularity of the system; responsiveness because anomalies are not propagated in the entire system; reusability given by the possibility of reusing the agent for other agent systems to solve different problems. Communication in multi-agent systems One of the basic characteristic of agents is their capability to communicate with each other in order to better achieve their goals or the goals of the society they are part of. Through communication, the agents can coordinate their actions and behaviors resulting into more coherent systems [27]. For achieving this, agents will have to be able to send and receive messages through a communication network. There are two main approaches regarding the agent communication one based on agent communication languages and one based on blackboard systems. 10

12 The Agent Communication language permits the agents to form a real society and solve accomplish problems no individual agent could, by allowing them to exchange information, intentions and goals. Some of the popular agent communication languages include FIPA s ACL and KQML. The Knowledge Query and Manipulation Language (KQML) represents an information and knowledge exchange protocol, having the particularity that all the information needed for understanding the content is included in the message [27]. The second main aspect regarding agent communication are the Blackboard Systems. They represent a centralized approach to the agent communication and are often presented using the following metaphor [27]: Imagine a group of human specialists seated next to a large blackboard. The specialists are working cooperatively to solve a problem, using the blackboard as the workplace for developing the solution. Problem solving begins when the problem and initial data are written onto the blackboard. The specialists watch the blackboard, looking for an opportunity to apply their expertise to the developing solution. When a specialist finds sufficient information to make a contribution, she records the contribution on the blackboard, hopefully enabling other specialists to apply their expertise. This process of adding contributions to the blackboard continues until the problem has been solved. This metaphor marks a few important characteristics of blackboard systems such as the independence of expertise, the diversity in problem-solving techniques, the flexible representation of blackboard information, the common interaction language, the event based activation, the need for control as well as the incremental solution generation. Societies of agents Even though the methods of constructing intelligent agents have been widely researched, it is less likely for intelligent system to be isolated since a part of the environments already contains other intelligent systems. Because these environments are large, complex and dynamic, the agents must be long-lived, adaptive and social [27]. Inside a small society, each agent can play a different role defined by the group. When an agent joins the society, it will receive one or more roles there. Even though they can enter the group autonomously, they are being constrained after they join. The social context in which the interaction between agents takes place, is defined by these groups. One of the main characteristics of the agents in the societies is sociability and it is essential for cooperation. Another aspect is the social commitments that represent the 11

13 commitments of an agent to another and are defined in [27] as flexible means through which the behavior of autonomous agents is constrained. As stated by Weiss in [27], a group of agents form a cooperative team when - the agents have a common goal; - each agent does his part in order that the group achieves its goal; - each agent adopts a request to do its share. 1.4 Multi-agent systems in e-travel Nowadays, tourism has become one of the world s largest trades constantly expanding from a year to another. In addition, the Internet is center spot for the travelers to gather information on the touristic destinations. As stated in [24], Tourism Information Systems are a new form of business systems that enable the support of e-travel organizations such as travel agencies, airlines, hotel companies and car rental companies. Agent technology is gaining popularity both in the area of research and in the development of applications related to other domains such as telecommunications, Internet information management, e-commerce, computer games, information retrieval and user interface design. By successfully using this technology for these applications, a big impact on their corresponding industries will be created [4]. Agent systems are suitable for domains in which information is physically distributed and a set of autonomous entities have to join their efforts and coordinate their activities to solve a complex task [19]. Since tourists need to search for trip related information from a certain destination, filter the ones that correspond to his preferences and try to build a plan for the activities he wants to perform, tourism is a domain that has the characteristics mentioned before. Therefore, e-tourism is one in which agent technologies can be applied. Modeling a multi-agent system for a travel scenario is quite direct. Depending on the designed scenario, the system s actors may have different roles and positions in it. The most common functionalities given to these agents are learning, planning and searching for up-to date information on the Internet. For each of these tasks there exists a big variety of algorithms that can be used, especially for the learning and planning roles. The information gathering part is a little tricky depending on what sort of information needs to be collected, but research is trying to improve the current methods or even find new ones. 12

14 CHAPTER 2 Agent development environments The development of multi-agent systems can be made in any kind of programming language, especially on object-oriented ones because the concept of object is not that far from the agent. Even though the agents can be modeled starting from objects, agent specific programming languages, platforms or development tools are helpful and when dealing with a multi-agent systems. Also they can improve the quality and stability of the system. In this chapter we will describe some of these development tools, focusing on the FIPA compliant agent platform, JADE. 2.1 Agent Oriented Languages Agent Oriented Programming (AOP) is a programming paradigm that was first introduced in 1990 by Yoav Shoham in his Artificial Intelligence studies in [23] and then revised and detailed in [21]. As he describes in [21], AOP is a specialization of the object oriented programming (OOP) paradigm where the actors are now represented by agents that have a mental state consisting of beliefs, capabilities and decisions instead of OOP s objects that were able to communicate and handle the incoming messages. These agents are actually informing, requesting, offering, accepting, rejecting, competing and assisting one another in order to achieve their goals [21]. In [21] Shoham suggests that an AOP system should need the following three elements in order to be considered complete: a formal language for describing the syntax and semantics of the agent s mental state, where the mental state is defined by several modalities such as belief and commitment [21]. a programming language for defining the agents with semantics closely related to those of the formal language; a method to convert neutral systems into agents. 13

15 In the following subsections we will briefly present some of the existing programming languages that follow the AOP paradigm such as Shoham s Agent0, Jack Intelligent Agents and the Open Agent Architecture Agent0 Agent0 is the language proposed by Shoham in [22] in order to prove his theories and represents a starting point into AOP languages. Agent0 is based only on belief and commitment mental categories and excluding the more complex ones such as desires, goals, intensions and plans. Between the mental states of an agent and his environment there are several relations defined by the notion of capability [22]. According to Agent0, an agent program is composed of two parts: initialization and commitment rules. In the initialization part the capabilities, initial beliefs and initial commitments are defined. The commitment rules represent the manner of how the commitments are added over time. As presented in [22], the syntax of the commitment rules is the following: COMMIT (msgcond, mntlcond, agent, action) in which msgcond represents the message, mntlcond the mental state, agent defines the agent s name and action is the action s statement. The Agent0 s interpreter acts as a cycle in which each agent iterates the following steps: read the current messages and update the beliefs and commitments; execute the commitments for the current time Jack Intelligent Agents Jack Intelligent Agents, or Jack for short, is an agent development environment built by Agent Oriented Software Pty. Ltd. (AOS). Jack is a Java based framework that comes as an extension of the object oriented programming by introducing agent related features such as agents, plans, capabilities, events and knowledge bases. Jack uses intelligent agents for modeling the simple and rational behaviors [13]. In [1] Jack agents are described as autonomous software components that have explicit goals to achieve or events to handle. Jack introduces a set of classes and interfaces, as well as a set of plug-in components that allow the development of agent related components. The agents are not bound to a certain agent communication language, though communication languages such as KQML or FIPA s ACL can be used [13]. Jack offers support for various architectures but the 14

16 basic one that is approached by the authors is the Belief Desire Intention (BDI) model. Based on the BDI model the agent will pursue its given desires or goals by finding the proper plans, intentions, based on its current set of data (beliefs) on the state of the environment [1]. According to [13] Jack is composed of three main extensions of Java. The first one gives the language additional syntax that can be divided into: keywords for identifying the agent related components; a set of statements used for declaring attributes or other characteristics of the components; a set of statements used for defining the relationships; a set of statements used for manipulating the agent s state. The compiler is considered Jack s second extension and it is used for converting the syntax into pure Java. Since it is fully compiled into regular Java, the compiled code can be called from other java code. Finally, the third extension is represented by the Jack Agent Kernel which provides a set of classes required at runtime that provide the agent-oriented functionality to the Jack Agent Language [1] Open Agent Architecture The Open Agent Architecture (OAA) is an agent development framework created at the Artificial Intelligence centre of Stanford Research Institute (SRI). It is defined by the authors as a framework for integrating a community of heterogeneous software agents in a distributed environment. So, OAA allows the development of multi-agent systems in which agents communicate in order to achieve their goals [7]. The agent library s procedures are available in several programming languages such as Java, Lisp, Prolog, C and C++. In OAA the agents are seen as independent processes with a high-level communication language and who can contribute actively to the computation process [7]. The autonomy and reactivity characteristics of an agent are also required by the OAA agents. The OAA is based on agents that communicate with each other by using the Inter-agent Communication Language (ICL) and it also specifies the model of communication between agents described by the system s structure, as shown in Figure 2. 15

17 Figure 2. OAA System Struncture (see Figure 1 in [17]) In this structure the Facilitator agent plays the central part. He represents a specialized server agent with the role of coordinating the agent communication and cooperation and who allows a blackboard style of communication to be developed [17]. In an OAA environment several Facilitator agents can exist, each of them having its own service agents. The other categories found here are the Application Agent, Meta Agent and User Interface Agent. Application Agents provide a certain service, either domain independent technologies such as speech recognition, natural language processing or , or domain specific such as reservation agent. Meta Agents have the role of assisting the Facilitator when coordinating other agents. In addition the Meta Agents can use domain and application specific knowledge or reasoning [17]. In some systems the User Interface Agents consist of several micro-agents each of them monitoring different input types such as handwriting, speech or point-and-click. These micro-agents are called Modality Agents and they can be seen in the structure. Except for the Facilitator who acts similar with a server, all these agents are referred to as client agents because they act as a client for some facilitator who offers the essential services needed by the client [17]. 2.2 FIPA FIPA [10], or the Foundation of Intelligent Physical Agents, is an organization founded in 1996 with the aim of developing and promoting software standard specification that would support interoperability among heterogeneous agents and agent-based systems. FIPA was 16

18 originally created to specify several aspects of multi-agent systems and over the years it developed a core set of specifications that went through three review cycles: FIPA 97, FIPA 98 and FIPA2000 [3]. Among all the agent-related ideas that have been proposed during its evolution only some of them are now called standards. Out of these we will briefly present in the following paragraphs the ones that present a central importance. A complete description of all the current specifications can be found on the FIPA Web Site [10]. Some of the agent development environments that comply with the FIPA standards specifications are Fipa-OS, Tryllian ADK, JADE, LEAP, Jadex and WADE. We will discuss about JADE in section Agent communication Agent communication represents the central part of FIPA specifications and it works with Agent Communication Language (ACL) messages, message exchange interaction protocols, speech act theory-based communicative acts and content language representations [10]. FIPA ACL is based on speech act theory, containing 22 communicative acts. As stated in [3], the most frequently used acts are inform, request, agree, not understood, and refuse. Each of the interaction protocols defined in FIPA contains a sequence of communicative acts in order to coordinate the multi-message actions Agent management The second central aspect underlined in the FIPA specification is agent management. Agent management deals with the creation, registration, location, communication, migration and operation of agents. The FIPA agent management reference model s structure is presented in Figure 3 [3]. 17

19 Figure 3. The FIPA agent management reference model (see Figure 2.5 in [3]) As detailed in the specifications [FIPA00023] and described in [3] the model s components are as follows: The Agent Platform (AP) consists of an AMS, one or more MTS, optionally one or more DF and Agents as shown in the model. The AP offers the physical infrastructure for agents to be deployed in. FIPA doesn t provide any specifications for implementing the agent platforms so this aspect is left to the developer to handle. An Agent represents a computational process inside the AP that offers one or more services published as a service description. An agent is distinguished unambiguously using the FIPA AID (Agent Identifier). The agents inside the AP communicate with the help of an ACL. An Agent Management System (AMS) is a mandatory component responsible with managing the operations of the AP. In order to get a valid AID, each agent must register with an AMS; also the life of an agent is ended when deregistering from the AMS. Even though the agent platform is spread across multiple hosts, there can only be one AMS. The Directory Facilitator (DF) is an optional component of the AP that maintains the list of services offered by the agents. 18

20 The Message Transport Service (MTS) represents the default service provided by the AP for communication between agents on different Agent Platforms Abstract architecture The abstract architecture represents a unified specification created on the basis of all central parts in the FIPA specifications. The mandatory specifications included are ACL message structure, message transport, agent directory services and service directory services, others being considered optional. The goals of the abstract architecture are explained in [FIPA00001] The primary focus of this FIPA Abstract Architecture is to create semantically meaningful message exchange between agents which may be using different messaging transports, different Agent Communication Languages, or different content languages. For achieving this interoperability in different points is required JADE The Java Agent Development Framework (JADE) [15] represents a framework implemented completely in Java with the goal of simplifying the development of multi-agent systems according to the FIPA specification standards. JADE is a free software distributed by Telecom Italia as the copyright holder. JADE offers possibilities for distributing the agent platform across several machines as well as a set of graphical tools useful for the deployment and debugging phases of the application JADE architecture JADE s platform formed by one or more agent containers which can be distributed across a network. A container can store a set of agents and it represents a running instance of the JADE runtime environment as stated in [5]. Between these containers there is a special one called Main container which represents the first container to be launched as well as the one that is always active in the platform. All the others must register with the Main Container once they start. The containers are identified by their names, so the main container is named Main Container while the others are simply named Container-1, Container-2, etc. These names can be changed by the developer. Figure 4 presents the FIPA agent management reference model implemented in JADE. 19

21 Figure 4. Screenshot of JADE s Agent Platform The agents inside the containers are identified by the AID as stated in the FIPA standards. The basic elements contained by the AID are the agent s name and its address. The agent s name is a globally unique identifier and it has the following form local_name@platform_name. The local_name represents the nickname given by the user to the agent and the platform_name is the platform s name on which the agent is running on. The agent s address is inherited from the platform it lives on and it is used to exchange FIPA compliant messages by using the Message Transport Protocol (MTP). JADE implements all the standard Message Transport Protocols defined by FIPA with the goal of achieving interoperability between different, non-jade platforms [3]. The default protocol used by the JADE MTP is the HTTP protocol and it starts at the initialization of the main container. Other MTPs available in the public domain are IIOP, JMS and Jabber XMPP. Along with the main container two special agents are started and instantiated automatically. These agents are the Agent Management System (AMS) and the Directory Facilitator (DF) defined in the FIPA agent management standard discussed in section The AMS is responsible with managing the operations of the agent platform and with providing the naming service, this way it becomes the authority in the platform [5]. The DF offers a Yellow Pages service whose duty is to help the agents to find the services required for achieving their goals JADE Tools JADE offers a set of useful tools for operating, managing and monitoring agents needed in the deployment and debugging phases of the application. The implementation of each of these 20

22 tools extends the jade.core.agent class, thus they can be managed like any other agents. Some of these tools are presented in the following paragraphs Remote Monitoring Agent The Remote Monitoring Agent or the RMA is probably one of the most useful tools JADE has to offer. It represents a graphical interface (see Figure 2) for managing and controlling Jade s agent platform and offers a graphical way of starting other Jade tools. An instance of the RMA can be started with the command line option -gui or by invoking the class jade.tools.rma.rma. This tool offers the developer the possibility of easily manipulating the basic JADE entities: agents, agent platforms and agent containers The Dummy Agent The Dummy Agent is a tool used for testing the behaviors of other agents by sending them ACL messages. The GUI (see Figure 5) offered permits the developer to easily compose and send the message as well as checking the history list of the sent or received messages. Figure 5. Screenshot of the Dummy Agent s graphical user interface The Sniffer Agent The Sniffer Agent has the role of intercepting the ACL messages sent between agents and to highlight them graphically (see Figure 6) similar to the sequence diagram. It is a very useful tool for monitoring the communication between the agents that live inside the platform. 21

23 Figure 6. Screenshot of the Sniffer Agent s graphical user interface The Introspector Agent The introspector agent (see Figure 7) is used for debugging and monitoring an individual agent s life cycle and behavior as well as the incoming and outgoing messages. It offers the developer the possibility of executing the observed agent s behaviors step by step. Figure 7. Screenshot of the Introspector Agent s graphical user interface JADE Features Along with the graphical tools helpful for the debugging process Jade respects the FIPA specification standards offering several agent related features needed in the development of the multi-agent systems. Some of these are described in the following sections. 22

24 Creating and terminating agents Creating a JADE agent is in fact just the action of creating a new Java class that extends the jade.core.agent class and then implementing the setup( ) method. This method represents the start point of the agent, thus all its initializations go in here. The basic Hello World agent example is shown below. import jade.core.agent; public class HelloWorldAgent extends Agent { protected void setup() { System.out.println("Hello World!"); } } The termination of an agent occurs when dodelete() method is called. Similar to the creation process, just before termination the takedown() method of the Agent class is invoked. The implementation of this method is optional, though it is very useful when clean-up such as closing database connections or disposing GUIs is required Agent behaviors The tasks an agent has to accomplish are done in Jade with the behavior abstraction model. Since one of the main properties of an agent is autonomy, Jade agents can control their behaviors by instantiating them according to their needs. These are implemented as Java classes that extend the jade.core.behaviours.behaviour class and they are assigned to the agent by using the addbehaviour(behaviour) method and are unassigned with the removebehaviour(behaviour) method. The parameter given to these methods represents the behavior implemented by the developer. Every behavior class must implement two abstract methods action() and done(). The action() method contains the implementation for the agent s task, while the done() method has to indicate whether the task was completed or not. Each time the agent executes a behavior the action() method will be executed until the task it s done. Because the behaviors are executed concurrently and scheduling of behaviors is cooperative in an agent [5] it is the programmer s duty to define when the agent should switch between the executions of the behaviors. As presented in [5], the agent execution model (see Figure 8) shows how the scheduling of the behaviors works. 23

25 Figure 8. The agent s execution model (see Figure 2 in [5]) In this context, JADE offers three primary types of behavior: one-shot behaviors, cyclic behaviors and the generic behaviors [3]. Each of them respecting the properties stated above, but still each having their particularities described in the following paragraphs. One-shot behavior represents the simplest behavior by being completed in one execution. By this we mean that the action() method is called only once while the done() method is always returning the Boolean true value. For implementing it the jade.core.behaviours.oneshotbehaviour class needs to be extended. Cyclic behavior is the opposite of one-shot behavior by being executed forever. So the done() method always returns false while the action() method is repeated over and over. The 24

26 implementation of cyclic behaviors is made by extending the jade.core.behaviours.cyclicbehaviour class. To stop this infinite loop the behavior needs to be removed from the pool of the current executing behaviors by using the removebehaviour() method of the Agent class. Generic behavior is represented by the jade.core.behaviours.behaviour class. It differs from the aforementioned behaviors because of its unimplemented done() method. Unlike OneShotBehaviour and CyclicBehaviour classes, in a generic behavior the responsibility of implementing the done() method is left to the developer. By doing this, the possibility of adding task related conditions can be satisfied Agent communication One of the main aspects in developing multi-agent systems is represented by the agent communication. JADE offers this as one of its fundamental features and its implementation is in accordance to the FIPA standards described in The communication between Jade agents is based on an asynchronous message exchange, every agent having an internal queue where the messages sent by other agents are stored [3]. Even though the agent is notified when a message has been added to the queue, it is the developer s choice when or if the messages are picked up. The form of the messages, according to the FIPA ACL message structure, consists of several elements, such as: the sender of the message, the list of receivers, the communicative act as stated in 2.2.1, the content of the message, the content s language, the ontology as well as some additional fields that enable the control of concurrent conversations such as conversationid, reply-with, in-reply-to, reply-by [3]. The content s language refers to the syntax used for expressing the content of the message while the ontology refers to the meanings associated to this content The Yellow Pages Service Another important feature is represented by the Yellow Pages Service which allows the agents to publish a description of the services they offer in order to be easily found by other agents interested in these services [3]. According to the FIPA Agent Management specifications Jade provides the Directory Facilitator (DF) agent which offers the yellow pages service, so the publishing and searching for services is done through ACL message exchange. 25

27 For publishing a service the information that has to be provided include: the agent s AID, the list of provided services and their description, and optionally a list of content representation languages and ontologies required to have access to the service. For each service the description includes its name and type as well as a list of service specific properties represented as key-value pairs. In order to actually publish the service the description must be created as an instance of DFAgentDescription class and then call the register() method of DFService class [3]. On the other hand, when searching for a service the template description of the required service must be defined. This template is sent to the DF agent who will give the reply in form of a list of services that match the given description. The implementation for this process is made through the search() method of the DFService class. 26

28 CHAPTER 3 Our approach to a multi-agent system for e-travel In this chapter we are introducing our approaches in designing a multi-agent system for e- travel. First of all we will present the system s architectures proposed then we will point out the roles of each agent involved in the scheme. Since there are two proposed architectures we will detail an analysis between the two of them in order to find the one that fits better into the problem s context and solution. 3.1 Existing e-travel projects. Related work The problem of developing e-tourism (or e-travel) systems was studied before in different countries and universities. The problem of designing such a system associated with an approach into information retrieval was studied and developed in several projects. In this chapter we describe some of these existing projects. In [11] the authors introduce a travel support system, named E-Travel: Agent-based Travel Support System, based on Semantic Web and software agents. This system presents a multi-agent architecture with agents having different task like planning the trip, learning the user s preferences, searching for the desired data using Web semantics and ontology-based stereotyping. The current disadvantage of using the Semantic Web is that it lacks the large repositories of semantically demarcated, travel related data. Therefore, the proposal is still incomplete due to this cause. In [12] a tourist advisory system, MATOURA, is described. It was made for Greece that was implemented in the parallel constraint logic programming language Elipsys. The authors introduce a multi-agent system that can handle various types of requests to construct personalized tours that satisfy the tourists wishes. This system is composed of the following - Tour Generation Agent is responsible for the personalized tours; - Activity Agent answers to the requests of the system s agents; - Event Agent - it answers to activity related requests from the system; - Site Agent - it deals with the sites of Greece; 27

29 - Accommodation Agent handles accommodation related information; - Transportation Agent holds information about connections between the elementary sites; - Ticketing Agent has information on the about the connections established between elementary sites by public transportation means; - Package Tour Agent packages the tours that match the user s requirements; - User Interface Agent controls all of the user s interactions with the system; - Info retreival/maintenance Agent deals with large volumes of data; - Training Agent assists the user in the use of the tourist advisor. The authors of PITA [2] design the prototype of a system for guidance of travelers in the Dutch public transportation with the goal of introducing the digital personal travelling assistants. When connecting to the system, the traveler s location is determined through the GPS. Then PITA will consult the train schedule combined with the available delay information and rerouting information and determine the best travelling option for the user, giving him optimal, personalised advice for how to use the public transportation system to get to his destination. The multi-agent system proposed by the authors is a BDI approach to improve the planning problem. A minor issue of the system is caused by the performance of the search algorithm implementation. In NADIM-Travel [4] the authors introduce a multi-agent platform in which a plannercoordinator agent manages the user s requests and the response aggregation process. The service agents are used to retrieve the responses while acting as gateways to the external service providers. Its advantage is given by the fact that the system was tested for one month by random users on the Internet. All this month the platform was functional without interruptions or system crashes. The authors consider that they were successful in developing a flexible and robust platform. ITP [6] represents a multi-agent planning system that offers solutions in the e-tourism domain to the users. The system automatically extracts and filters data from the web, learns from the user s profile while trying to adapt to the user s preferences. The main problems integrated by the authors in this system are planning and learning techniques combined with the advantages provided by distributed systems. ITP is a multi-agent system that integrates the following heterogeneous agents: 28

30 - User Agent handles the user s request and offers him the solution, all this by obtaining an abstract representation of the problem. - Planner Agent has skills like communication, planning and learning. - WebBot is the agent responsible with collecting from the Internet the information requested by the Planner Agent. - Coach Agent is the one that controls the set of agents, manages their registration, searches for new agents, suspends communications, etc. All these agents use a common language representation based on KQML that allows cooperation and knowledge sharing. The authors state that the system was tested both by the users evaluation and through an automatic system evaluation for analyzing the performance. The results of this evaluation experiments were not stated in [12]. 3.2 The system s architecture As stated before, the purpose of this paper is to develop a personal travel assistant similar to a human tourist agent. From this similarity, the requirement for using a multi-agent system for solving the scenario is easily observed. For this multi-agent system we propose two architectures one that uses stationary agents as units in its design and one that uses mobile agents. Each of these two proposals is presented in the following sections Stationary agents approach In literature the term of stationary agents is often used to represent the regular agents, especially when we talk about other types of agents in the same context. So these agents have their roles well defined and their task is to wait for a notification and when they receive it they have to act according to the function they supply. As shown in Figure 9, the architecture proposed uses three types of agents: Personal Travel Assistant agent, the Coordinator Agent and the Web Agents. The roles of these agents are presented in section 4.2. In both cases the situation analyzed is for one user only. When more users are involved each one has its own system of agents to help him. 29

31 Figure 9. The system s architecture using stationary agents a) Personal Travel Assistant Agent The Personal Travel Assistant agent (or PTA) is the one interacting with the user through the Web page. This agent has the role of taking requests from the user and sending them forward to the other agents in order to get the desired response. Another role of the agent is learning the user s preferences and filtering the set of results received based on them. Each user of the system has its own personal agent with whom he interacts. b) Coordinator Agent The Coordinator Agent is the one that receives the request from the PTA (Personal Travel Assistant) agent. Then from the content of the request, it finds out the categories needed to find the proper information such as: accommodation, transport or touristic attractions. After it selected that, it will send the request to all the Web Agents located in the corresponding categories, waiting for the reply from them. After receiving all the replies, the coordinator will report back to 30

32 the PTA that the search was finished meaning now the PTA can start offering the results to the user. Currently each user has a Coordinator Agent associated to his PTA agent that acts in the previously described manner. Another solution worth analyzing in the future would be the usage of only one global Coordinator Agent that would have a strong planning capability in order to manage the requests and plan the Web Agents tasks efficiently. This approach will be further investigated. c) Web Agent The Web Agent represents an abstraction of the web searching agents. Each agent of this type will be located on a certain Web Page from which it is responsible of collecting the desired data. When finished, it has the duty of reporting back to the Coordinator Agent that it finished gathering the results for the given request and that they were deposited in the database Mobile agents approach The use of mobile agents does not seem so popular in this area and it seems as though it has not been used a lot in e-travel multi-agent systems. Taking into consideration the fact that all the agents are running on the same platform the performance of the system will decrease when dealing with a large amount of agents. Our approach aims at improving the previous design in terms of resource management efficiency by removing the Web Agents presented before and transforming the Coordinator Agent from a stationary agent into a mobile one. And with that we are trying to improve the performance of the whole system. In this case the remaining agent types are the PTA and the Coordinator Mobile Agent, like shown in Figure

33 Figure 10. The system s architecture using mobile agents The roles of the Personal Travel Assistant agent remain the same as in the previous design. In direct association with this one is a Mobile Coordinator Agent, with the function stated below. Coordinator Mobile Agent is a new agent incorporates the roles of both Coordinator Agent and Web Agent from the previous design. It receives a request from the Personal Travel Assistant agent, finds the categories needed and instead of passing the request to the proper Web Agents it starts moving to all the locations found in those categories. When arriving at a certain location it has the duty of extracting all the requested information from the corresponding Web Page. 3.3 The agents roles The system is able to offer the user relevant and personalized result to his search and for this communication and interaction between the agents is needed. Each agent has a well defined role in the system; the behaviors of each of the agents presented above are as follows. 32

34 3.3.1 Personal Travel Assistant As described before, the Personal Travel Assistant agent has the role of interacting with the user offering him results to his requests. In order to get the results the agent will interact with the Coordinator Agent and in order to show the user the results according to his preferences the learning of his profile is needed. The behaviors of this agent are the following Retrieving the request from the user The agent is always waiting for requests from the user. Each time it receives such a request it will send the request forward to the Coordinator Agent giving it the duty of searching for the results. The message sent to the Coordinator Agent is a little modified than the content of the message received from the user. The content of the message sent between these two agents has the following form: user_id:category 1,category 2, category n :origin,destination, departure_day,departure_month, departure_year, return_day,return_month,return_year. Where user_id represents the id of the user making the request and category 1,category 2, category n represents the category of the trip related elements the user searches for, such us : accommodation, transportation, touristic attractions. The origin represents the user s departure city while the destination parameter represents the city he wants to go to. Depending on the categories requested some of the parameters can be null. For example if the accommodation category is required the origin parameter is irelevant because the user is interested in searching for hotels from the given destination. But if the transportation category is needed then all the parameters should be initialized. The first part of the request is the one analised by the Coordinator agent, and the second part consisting of destination, departure date and return date, will be the content that creates the search parameter Showing the results to the user After the request has been handled by the agents in charge the PTA agent will be notified that the search process has ended. Now it is its duty to filter, sort and show the results to the user. The filtering and sorting process is made according to the user s profile. The agent has knowledge on the user s preferences and priorities so the sorting will be made accordingly. 33

35 Learning the user s preferences Given the fact that we want to develop a system that acts like a personal assistant, a proper way of accomplishing this is by trying to personalize the results and to sort them according to a set of known priorities. A learning approach that fits the context of the current problem would be from the perspective of a reinforcement learning technique, such as Q-Learning. However, this aspect has been only partially exploited up to this point and remains as a future improvement for the moment Coordinator Agent This agent has the duty of parsing the message received from the Personal Travel Assistant agent in order to find out which are the categories needed for the search. After finding this out, it has the duty of searching for all the Web Agents placed in these categories and then sending them all a message with the request. The message sent to the Web Agents has the following form: user_id: origin,destination, departure_day,departure_month, departure_year, return_day, return_month, return_year After sending them this message, the Coordinator Agent waits for confirmation from all the Web Agents that received the task. No matter what the reply from each agent is ( error or success ) it will not send a confirmation message back to the PTA until all the specialized Web Agents have stated their status. The confirmation message has the role of informing the PTA agent that the data has been collected Web Agent Web Agents are located on Web Pages, each of them being responsible with retrieving results from its corresponding page. The agent receives a message from the Coordinator Agent with the form presented above, after that it executes the search inside the page and then it sends a message of confirmation to the coordinator agent letting it know that it finished its task. The information gathering part would have been easier if the dates had no importance in the query, but since we want to refine the search the first aspect added are the dates. That s why querying a search engine such as Google or Bing is out of the question. 34

36 One way of gathering the data is by using tools that can search inside a web site similar to a human but in an automatic way. One such tool is HtmlUnit and by using it, the Web Agent s task can be accomplished. HtmlUnit [14] is a GUI-less browser for Java Programs. Its role is to model HTML documents and to provide an API that allows you to do the actions you normally do in a browser such as clicking links, invoking pages, filling forms, but all this in a programmatic way. More details on the usage of HtmlUnit in the problem s solution as well as the detailed presentation of all the functionalities will be presented in chapter Coordinator Mobile Agent This agent is used in the second architecture proposed in this paper and has the roles of both Coordinator Agent and Web Agent. It waits for messages from the Personal Travel Assistant agent, parses the message to search for the categories and then instead of sending the message forward it moves to the next locations from each category needed to retrieve the results until every location is visited. When it arrives back at the first visited location it sends a confirmation message to the PTA. 35

37 CHAPTER 4 The application This chapter describes the context of the problem we are dealing with accompanied by its analysis. The application will be described systematically, presenting the design and the implementation offered by combining several tools. 4.1 Problem description and analysis As stated before, the problem we are dealing with has the goal of representing real life systems in a computational way, in our case travel agencies, leading us to the e-travel system. The situation considered is the moment when a person wants to go on a trip and travel related elements are required. In this context, he will want to search for these elements one way or another. Instead of letting him go to the travel agent and ask him for solutions, the problem resumes at creating a multi-agent system that will do all this for him, in an automatic manner. So he will be able to look for elements such as accommodation, transport, touristic attractions and others from his own computer or from his mobile device through one application. The solution requires an approach into solving the personal agent part of the problem, part that is approached as a learning algorithm for one of the agents. Also the information offered as a response to the user s request needs to be up-to-date and relevant. The provided system allows for multiple users to register and use it. In this context the registration is made through the Web Page which represents the system s interface that can be accessed from any internet browser. The system is available for users of all ages that are interested in organizing their trip without the aid of a specialized human agent. They just have to access the Web Site and proceed with the search. In the context mentioned above our approach to the solution is centered on the architecture presented in the previous chapter. In the following sections the implementation of these architectures will be described. Besides the architectures presented in Chapter 5, the use-case diagram in Figure 11 describes the main scheme of the application shown from the user s point of view. The functionalities that can be observed in this diagram represent the center point of our work. 36

38 Besides them, others are added or might be considered to be added as future improvements to the project. Figure 11. Use-Case Diagram representing the center-point functionality of the project Usage Scenario In the following, we present a study case scenario for the moment the user makes a request. Supposing the user wants to search for accommodation possibilities in Barcelona from to , he will fill in the search form s text boxes and then submit it. Next, we will describe what happens in the multi-agent system, for each approach, after the user clicks the search button. After the user has sent his request, this is being taken by the Personal Travel Assistant agent in order to be processed and taken care of. The communication between the user and the PTA is made through JadeGateway class. A servlet handles the user s request, which is passed to a GatewayAgent through a BlackBoard object. The GatewayAgent extracts the receiver and the message s content and then sends the message to the PTA. Stationary agent approach After the PTA has taken the message, it searches for the Coordinator Agent services, this way identifying the agent, and then it sends the request. The Coordinator Agent now extracts the 37

39 desired categories from the message s content and searches for the agents that offer services named like those categories. After the Web Agents have been found, the request is sent to them. Now the Web Agents that received a request message will start the searching process on their corresponding Web Pages. After all the data has been collected, it is stored in the database and an inform message is sent back to the Coordinator Agent. After the coordinator receives all the notifications it will know that the Web Agents have finished their duties and it can inform the PTA as well. Mobile agent approach After the PTA has taken the message, it searches for the Coordinator Mobile Agent s service and it sends the request. The coordinator extracts the desired categories from the message s content and searches for all the locations corresponding situated in those categories. Once these were found, it starts moving from a location to another. Each location has a corresponding Web Site, so when the agent arrives at a location he starts collecting the data from the corresponding page storing it into the database and then moving to the next location. This action is repeated until all locations are visited and then the coordinator informs the PTA that the data was collected. When the PTA received the notification it sends an inform message back to the GatewayAgent who will use the same BlackBoard to send the message to the servlet. Now the collected results are loaded from the database and displayed to the user according to the user s preferences Analyzing the learning behavior For making the system a personal one, the capability of learning user preferences is added to the PTA agent. For this task we are considering a reinforcement learning technique such as Q-learning [18]. The Q-learning algorithm is based on a numerical evaluation function for action-state pairs with the purpose of maximizing the total reward by learning which action is optimal for each state. In the project s context, we could consider the set of results received by the user as the environment and an order of the user s priorities as a state of the environment. In our case, the action needed for moving from a state to another is the user s click on a certain item from the resulted list. That means the action is the same no matter what the current or the next state is. 38

40 We said we want to learn the priorities of the user. If we simplify the problem a bit and stop at searching just for hotels from the accommodation category these priorities would mean: the price category, the hotel s rating on the Web Site and the hotel s category (number of stars). For each of these three parameters we consider a limited set of values: five price categories, five rating categories and five hotel categories. That means that a certain state would be represented as a pair of three values, one for each attribute, leading us to 125 possible states. In this context a learning episode would be described by the following. Considering the current state of the environment is s k. When the user clicks an item from the list, according to its own attributes, the item is assigned to a certain category, meaning the pair of those exact three attributes needed to determine the state s k+1 is searched. When found the state described by those three values will be given an award. After more such episodes the agent should be able to sort the resulted list according to the user s preferences. 4.2 Application design The application was designed based on the Model View Controller design pattern, this way the model is separated from the graphical user interface (view). These components are linked through the Controller. Since the solution is approached with the usage of an agent oriented development framework, the controller includes all the classes needed for changing the results to the user interface such as the system s agents and the required elements for the agents to communicate with the user interface, the Web Page. By using this pattern, the application becomes easily extendable also increasing its maintainability Class Diagram The project follows the structure described in Chapter 3, so the class diagram reflects the stated architecture. Since there are many classes, the diagram was divided in order to get a better caption of it. The first part (see Figure 12) presents the Coordinator agent along with the Personal Travel Assistant agent with their corresponding classes. As shown in the diagram, each of these two agents has several behaviors associated. These behaviors will be described in the following paragraphs according to the agent they correspond to. Each behavior actually represents an inner class of the agent this way it has access to the agent s attributes. 39

41 Figure 12. Class diagram for Coordinator agent and PTA agent TravelAgent represents the Personal Travel Assistant described in a) and in with the following inner classes representing its behaviors. a) WaitForRequestBehaviour is used for interacting with the user and to wait for requests. When a message from the user was received the TravelCoordinatorBehavior and the WaitForResponseBehavior will be invoked. b) TravelCoordinatorBehavior is used for searching for an agent with coordinator services in order to send it the request received from the user. c) WaitForResponseBehaviour is a cyclic behavior that waits for an inform message from the Coordinator agent. This message will let the PTA know that the search was done and that he can pass the results to the user. 40

42 d) LearningBehavior represents the agent s behavior used for learning the user s preferences. CoordinatorAgent represents the Coordinator agent presented in section b) and a) SendRequestBehavior is invoked when the Coordinator agent receives a request message from the PTA. After received, it will parse the message, find the desired travel related categories, search for the Web Agents responsible for those categories and then send them the rest of the message. b) WaitForDoneBehaviour is a cyclic behavior that waits for notification from all the Web Agents that received a request. When all the inform messages were received, it will send another message to the PTA letting it know the search was finished. c) ErrorAppearedBehaviour each time a Web Agent encounters an error in the information collection process it will send an error message to the coordinator. This behavior will catch that message and will tell the agent not to wait for that Web Agent anymore. Stare is the class that models a state used in the PTA s learning behavior, while StareDAO is the class used to save and update the states in the database. The next part of the whole class diagram reflects the Web Agents, the Coordinator Mobile Agent and all the other classes related to them, as shown in Figure 13. CoordinatorMobileAgent is the mobile agent from the second approach to the system s architecture. It was described in and a) GetAvailableLocations is a behavior that finds the Agent Manager System s available locations. This is invoked when the agent is created in order to update its locations list. b) ReceiveCommands is used to wait for request messages from the PTA agent. When such a message is received it will parse its content in order to get the travel related categories, then according to them it will search within the locations list and determine the ones that correspond to the categories desired. These locations contain in their name the category they belong to, so the agent will be able to identify them easily. Once they were determined the agent starts moving from a location to another. c) NotifyDone this behavior is invoked after the agent has visited all the desired locations. When invoked it will send an inform message to the PTA agent telling it that the search was finished. 41

43 WebAgent represents an abstract class for the Web Agent type of agents described in the sections c) and a) WebAgentRequestManagingBehavior extends Jade s CyclicBehavior class and it represents an abstract for the Web Agent s main functionality, the management of the received request used for searching the desired data inside the corresponding Web Page. Figure 13. Class diagram for the WebAgents and the Coordinator Mobile Agent 42

44 BookingWebAgent extends the Web Agent class and it represents a Web Agent specialized into searching for data from the booking.com Web Site, thus being added into the accommodation category. a) RequestManagingBehaviour extends the WebAgentManagingBehaviour class and it is the behavior used for searching the desired data from the corresponding Web Site. EuroBookingsWebAgent similar to the BookingWebAgent, it extends the Web Agent class and it is specialized into searching for data from the eurobookings.com Web Site and it is part of the accommodation category. a) RequestManagingBehaviour does the same thing as the BookingWebAgent s behavior only for another Web Page. WebPage represents an abstract class for defining a Web Page from which data will be gathered. BookingWebPage and EuroBookingsWebPage represent classes that extend the WebPage each of them defining the methods for collecting the information within the pages. Hotel is the base class that models the elements from the accommodation category, the hotels. HotelDAO represents the link to the database. With the aid of this class, the database is managed so hotels can be added to their corresponding tables. The next set of classes (see Figure 14) is used for the communication between the user interface controlled by the user and the PTA agent. This was made by using Jade s Gateway protocol. GateWayServlet class is the Servlet that handles the POST message received from the browser when the user submitted the search form. Also, it forwards the response back to the browser when this is received. SendMessageAction class is the one used to perform the sending of the user s request. When invoked, it will create a new request message as well as a new BlackBoard object. BlackBoardBean represents the message channel between the servlet and the GatewayAgent. 43

45 MyGateWayAgent is the agent that gets the object created by the action and extracts the recipient and the message. After figuring this out, it will send the message to the PTA agent. In addition, when the results need to be given to the user, the same process will take place. SearchRequest class models the request performed by the user that will be sent between the agents. Figure 14. Class diagram for the GateWay communication The sequence of operations Jade s Sniffer agent allows us to observe in real time how the agents communicate with each other in order to solve the problem. Such a sequence is described in Figure