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

1

TABLE OF CONTENTS

INTRODUCTION ……….………………………………….……..………..…... 3

CHAPTER 1: Multi-agent systems ………………….……………………....…. 5

1.1 What is an agent? ..................................................................................... 5

1.2 Uses of agents ……………………………….…………………………. 7

1.3 Multi-agent systems and their advantages …………………….….......... 9

Communication in multi-agent systems ...…………………..... 8

Societies of agents ……...…………………………………….. 9

1.4 Multi-agent systems in e-travel …………………………….…….....… 12

CHAPTER 2: Agent development environments ……………………..……… 13

2.1 Agent oriented programming languages ………………..…………….. 13

2.1.1 Agent0 ………………………….......……………………...… 14

2.1.2 Jack intelligent agents………………………………………… 14

2.1.3 Open Agent Architecture……………………………………... 15

2.2 FIPA ………………………………………………………………....... 16

2.2.1 Agent communication………………………………………… 17

2.2.2 Agent management…………………………………………… 17

2.2.3 Abstract architecture………………………………………….. 19

2.3 JADE…………………………………………………………………... 19

2.3.1 JADE architecture………….…………….………………....… 19

2.3.2 JADE tools……………………….…………….……………... 20

2.3.2.1 Remote Monitoring Agent …………………..………. 21

2.3.2.2 The Dummy Agent ………………………………….. 21

2.3.2.3 The Sniffer Agent……………………………………. 21

2.3.2.4 The Introspector Agent...…………………………...…22

2.3.3 JADE features………………………………………………….22

2.3.3.1 Creating agents …………………………………….…23

2.3.3.2 Agent behaviors……………………………………….23

2.3.3.3 Agent communication ………………………………..25

2.3.3.4 The Yellow Pages Service ……………………………25

CHAPTER 3: Our approach to a multi-agent system for e-travel……………27

3.1 Existing e-travel projects. Related work ……….……….…….………..27

3.2 The system’s architecture …. ………………………………………….29

3.2.1 Stationary agents approach…………………………………….29

3.2.2 Mobile agents approach ………………….................................31

3.3 The agents’ roles……………………………………………………..…32

2

3.3.1 Personal Travel Assistant……………………………………...33

3.3.1.1 Retrieving the request from the user……….……….…33

3.3.1.2 Showing the results to the user…………….………..…33

3.3.1.3 Learning the user’s preferences …………….…………34

3.3.2 Coordinator Agent……………………………………………..34

3.3.3 Web Agent……………………………………………………..34

3.3.4 Coordinator Mobile Agent……………………………………..35

CHAPTER 4: The application…………………………………………………..36

4.1 Problem description and analysis……………………………………….36

4.1.1 Usage scenario…………………………………………………37

4.1.2 Analyzing the learning behavior……………………………….38

4.2 Design…………………………………………………………………..39

4.2.1 Class diagram………………………………………………….39

4.2.2 The sequence of operations……………………………………44

4.3 Implementation…………………………………………………………45

4.3.1 Personal Travel Assistant…….………………………………..48

4.3.2 Coordinator Agent…………………………………………..…49

4.3.3 Web Agent………………………….………………….………49

4.3.4 Coordinator Mobile Agent……………………………………..51

4.4 Evaluating the architectures: mobile agents vs. stationary agents……...53

4.5 Comparison to related work ………………....………………………... 54

4.6 Further improvements ………………………………………………….55

CONCLUSIONS………………………………………………………………….57

BIBILIOGRAPHY…………………………………………………………….…58

3

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 multi-

agent 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

4

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.

5

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])

6

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.

7

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]:

8

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, service-

providing 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.

9

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 multi-

agent 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.

10

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.

11

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

12

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.

13

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.

14

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.

2.1.1 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.

2.1.2 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

15

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].

2.1.3 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.

16

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 email, 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

17

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 2.3.

2.2.1 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.

2.2.2 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].

18

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.

19

The Message Transport Service (MTS) represents the default service provided by

the AP for communication between agents on different Agent Platforms.

2.2.3 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.

2.3. 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.

2.3.1 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.

20

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 2.1.2. 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.

2.3.2 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

21

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.

2.3.2.1 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.

2.3.2.2 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

2.3.2.3 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.

22

Figure 6. Screenshot of the Sniffer Agent’s graphical user interface

2.3.2.4 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

2.3.3 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.

23

2.3.3.1 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.

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.

2.3.3.2 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.

import jade.core.Agent;

public class HelloWorldAgent extends Agent {

protected void setup()

{

System.out.println("Hello World!");

}

}

24

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

25

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.

2.3.3.3 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 2.2.1. 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 conversation-

id, 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.

2.3.3.4 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.

26

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.

27

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;

28

- 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 planner-

coordinator 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:

29

- 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.

3.2.1 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.

30

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

31

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.

3.2.2 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 10.

32

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.

33

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.

3.3.1.1 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:category1,category2,…categoryn: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

“category1,category2,…categoryn” 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.

3.3.1.2 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.

34

3.3.1.3 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.

3.3.2 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.

3.3.3 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.

35

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 5.

3.3.4 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.

36

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.

37

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

4.1.1. 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

20.07.2012 to 25.07.2012, 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

38

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.

4.1.2 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.

39

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 sk. 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 sk+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.

4.2.1 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.

40

Figure 12. Class diagram for Coordinator agent and PTA agent

TravelAgent – represents the Personal Travel Assistant described in 3.2.1 a) and in 3.3.1.

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.

41

d) LearningBehavior – represents the agent’s behavior used for learning the user’s

preferences.

CoordinatorAgent – represents the Coordinator agent presented in section 3.2.1 b) and 3.3.2.

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 3.2.2 and 3.3.4.

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.

42

WebAgent – represents an abstract class for the Web Agent type of agents described in

the sections 3.2.1 c) and 3.3.3.

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

43

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.

44

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

4.2.2 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 15.

45

Figure 15. Jade’s Sniffer Agent following a sequence of communication acts between the agents

As observed in Figure 15, when the TravelAgent receives a request message, it searches

for an agent offering the “coordinator” service through a request message and receiving the reply

as an inform communicative act. Then it sends the request to the Coordinator Agent who will

now ask for the agents situated in the desired categories. Once found, the coordinator will send

requests to these agents waiting for their confirmations. When all of them have confirmed, it will

send a confirmation message to the TravelAgent letting it know the task was finished.

4.3 Application implementation

The application was fully implemented in Java technologies and tools such as JADE,

HtmlUnit as well as Servlet and JSP Web development technologies. We will describe how the

main agent functionalities of the project were implemented, focusing on the agents’ roles

described in 3.3.

We used Jade’s features for the agent implementation. So when started, each agent

registers to the AMS and then it registers it services to the DF’s Yellow Pages. The services are

distinguished through their description, so each Web Agent registers with the name of its

category, the other agents (PTA and Coordinator) register with their services. By this, the agents

46

can easily find each other and communicate for achieving their goals. Algorithm 1 shows how

such a registration was made, and then Algorithm 2 will present how the search for a desired

service is implemented.

Algorithm 1 Agent service registration method

In the agent service registration, “type” represents the agent’s service type and “name” is

the service’s name. In our implementation, the Web Agents will register their services with the

corresponding category as their type, and with the name of the corresponding Web Page as the

service’s name. The PTA will register as “travel-agent” both name and type and the Coordinator

Agents, both the simple and the mobile one, will register as “coordinator” since they will not be

active at the same time.

Algorithm 2 Agent service search

protected void registerService(){ // Register the service offered by the agent DFAgentDescription dfd = new DFAgentDescription(); dfd.setName(getAID()); ServiceDescription serviceDescription = new ServiceDescription(); serviceDescription.setType(type); serviceDescription.setName(name); dfd.addServices(serviceDescription); try { DFService.register(this, dfd); } catch (FIPAException fe) { fe.printStackTrace(); } }

AID[] agents = null; DFAgentDescription template = new DFAgentDescription(); ServiceDescription sd = new ServiceDescription(); sd.setType(category); template.addServices(sd); try { DFAgentDescription[] result = DFService.search(myAgent, template); agents = new AID[result.length]; } catch (FIPAException fe) {

fe.printStackTrace(); }

47

Algorithm 2 illustrates how the agents from a certain category are being searched for. All

the agents use this when they want to communicate with each other. For this, a new template is

created for defining the description of the service the agent is looking for. After this was set, all

the agents offering service of the defined type are searched by using the search() method of

DFService class.

Next, Algorithm 3 illustrates how the agents communicate and send messages to each

other through the Jade’s Agent Communication Language. A new ACLMessage request is created

setting its communicative act as REQUEST. An agent is added as a receiver and a request string

as the content and then the current agent named myAgent is sending the message.

Algorithm 3 Sending an ACL message

Starting the agent platform

Starting Jade’s AP means the creation of the desired locations for the mobile agent and

starting all the agents needed in the platform. This is made after the user has logged in

successfully. Algorithms 4 and 5 shows how these elements are initiated. Algorithm 4 is for

deploying the stationary agent approach to the architecture (see 3.2.1); while Algorithm 5 is used

for deploying the mobile approach (see 3.3.2).

Algorithm 4 Deploying the stationary agent approach of the system

ACLMessage request = new ACLMessage(ACLMessage.REQUEST); request.addReceiver(agents[i]); request.setContent(cerere); myAgent.send(request);

try { String [] args = {"-gui", "TravelAgent:agents.TravelAgent;"+

"BookingWA:agents.webAgents.BookingWebAgent;"+ "EuroBookingsWA:agents.webAgents.EuroBookingsWebAgent;"+

"CoordinatorAgent:agents.CoordinatorAgent;"}; jade.Boot.main(args); System.out.println("Jade Inited()");

System.out.println("Start"); } catch (Exception ex) { out.println(ex); }

48

Algorithm 5 Deploying the mobile agent approach of the system

In the following subsections, we will present how the three algorithms presented above

are combined for implementing the agent’s functionalities as well as each agent’s particularities.

4.3.1 Personal Travel Assistant

The PTA agent’s roles described in 3.3.1. were retrieving the request from the user,

showing him the results and learning his preferences.

First off, for interacting with the user (retrieving the request and showing the results)

through the user interface Jade’s GateWay communication protocol was used. This implies the

usage of several elements as shown in the corresponding class diagram. First is the

GateWayServlet used for handling the post message received from the JSP page by invoking the

SendMessageAction and starting the GateWayAgent. The second element involved is the

SendMessageAction and it is used to create the content of the request based on the values

received from the Servlet, create a BlackBoard object and then post the request for the GateWay

agent to see it. Third, MyGateWayAgent is the agent responsible with processing the message

from the BlackBoard and passing the request to the PTA (see Algorithm 6).

try { String [] args = {"-gui", "TravelAgent:agents.TravelAgent;"+

"CoordinatorMobileAgent:agents.mobileAgent.CoordinatorMobileAgent;"}; jade.Boot.main(args); jade.core.Runtime runtime = jade.core.Runtime.instance();

jade.wrapper.AgentContainer[] container = new jade.wrapper.AgentContainer[8];

ProfileImpl p = new ProfileImpl();

p.setParameter(p.CONTAINER_NAME, "accomodation-booking"); container[0] = runtime.createAgentContainer(p); ProfileImpl p1 = new ProfileImpl();

p2.setParameter(p1.CONTAINER_NAME, "accomodation-euroBookings"); container[1] = runtime.createAgentContainer(p1); System.out.println("Jade Inited()");

System.out.println("Start"); } catch (Exception ex) { out.println(ex); }

49

Algorithm 6 Processing the message from the BlackBoard

The backward communication works in the same manner just from the GateWay agent to

the servlet who will post it on the user’s results page.

Second, the learning behavior is being approached as described in 4.1.2. When a user

clicks a link from the results page, a message with the clicked item is sent to the PTA using the

same GateWay protocol. The PTA will determine which the next state is by classifying the

clicked item’s properties and offer a direct reward to this state. We are currently considering this

direction to improve the solution.

4.3.2. Coordinator Agent

The Coordinator Agent’s roles described in 3.3.2 are implemented using Algorithms 2

and 3 presented before. Therefore, when it receives a request message from the PTA it parses it,

searches for the Web Agents from the desired categories using Algorithm 2 and then it sends

them the message (see Algorithm 3).

4.3.3 Web Agent

The Web Agents have the role of retrieving the information from a certain Web Page.

This process is made by invoking the getResults() method from the corresponding Web Page’s

class. This method uses the HtmlUnit class libraries in order to fill in the search form from the

page, click the submit button and then parse the resulting HTML page in order to collect the data.

A section of the implementation is shown below in Algorithm 7, exemplifying the search on the

“eurobookings.com” Web Site.

protected void processCommand(java.lang.Object obj) { if (obj instanceof BlackBoardBean) { board = (BlackBoardBean)obj; ACLMessage msg = new ACLMessage(ACLMessage.REQUEST); msg.addReceiver(new AID( board.getReceiver(), AID.ISLOCALNAME) ); msg.setContent(board.getMessage()); send(msg); } }

50

Algorithm 7 Collecting data from a Web Page using HtmlUnit

Therefore, when the WebAgent (a class that extends the WebAgent abstract class) receives

a request from the PTA, it will parse the message’s content and invoke the previously described

method. After all the results were gathered and added into the database the WebAgent sends an

INFORM message using Algorithm 3 where instead of the REQUEST communicative act,

public void getResults(){ //connect to the webSite WebClient webClient = new WebClient(); webClient.setJavaScriptEnabled(false); HtmlPage page = null; try { page = webClient.getPage(webSite); } catch (Exception e) { e.printStackTrace(); } //Autocomplete form HtmlForm form = (HtmlForm) page.getElementById("search_form"); HtmlElement destTB = form.getElementById("destSearch"); destTB.setAttribute("value", destination); //destination if (!specificDate){ HtmlElement checkbx = form.getElementById("showAvail"); try{ checkbx.click(); //Check : "I don't have specific dates yet" } catch (Exception e){e.printStackTrace();} }

else { HtmlSelect checkinday = form.getElementById("b1_checkin_day");

HtmlOption option = checkinday.getOptionByValue(checkInDay); checkinday.setSelectedAttribute(option, true);

HtmlSelect checkinmonth = form.getElementById("b1_checkin_month"); option = checkinmonth.getOptionByValue(checkInMonthYear); checkinmonth.setSelectedAttribute(option, true); //same for checkout

} HtmlElement submitButton = form.getElementById("submitBtn"); //Get the results page by clicking the submit button HtmlPage resultsPage = null; try { resultsPage = submitButton.click(); } catch (IOException e) { e.printStackTrace();} //… the rest of the method is parsing the resulted page and adding // the result into the database }

51

INFORM is used. The message parsing for the “eurobookings.com” Web Page is described in

Algorithm 8. Where the message in the form described in 3.3.2 is being parsed, and the desired

elements are extracted from there.

Algorithm 8 Parsing the request received from the Coordinator

4.3.4 Coordinator Mobile Agent

The Coordinator Mobile Agent appears in the mobile agent approach of the architecture.

It combines the roles of the Coordinator Agent (see 4.3.2) and Web Agent (see 4.3.3). Even

though the roles are the same, taking into consideration that it is a mobile agent the

implementation differs.

First, the Coordinator Mobile Agent finds all the available locations inside the platform

through the GetAvailableLocations behavior by querying the AMS as shown in Algorithm 10.

After it receives a request it will filter the location list and select only the ones needed using

filterLocations() method, then it starts moving using the move() method. The afterMove() method

tells the agent what to do after it arrived at a location. Here, corresponding to the location it

arrived at, it will start gathering the data from the corresponding Web Site. This is repeated until

all locations have been visited, moment when it will inform the PTA it finished the task.

A sample of the set of operations done in the afterMove() method is detailed below in

Algorithm 9.

public void manageRequest(String request){ //parseaza cererea String[] requestParam = request.split(":"); String user = requestParam[0]; String[] requestParams = requestParam[1].split(","); BookingWebPage page; if (requestParams.length==1){ page = new BookingWebPage(user,requestParams[0]); } else { String dest = requestParams[0]; String ciday = requestParams[1]; String ciYearMonth = requestParams[8]+"-"+requestParams[3]; String coday = requestParams[9]; String coYearMonth = requestParams[5]+"-"+requestParams[15];

page = new BookingWebPage(user,dest, ciday, ciYearMonth, coday, coYearMonth);

} //ia rezultatele page.getResults(); }

52

Algorithm 9 Coordinator Mobile Agent’s afterMove() method

Algorithm 10 Getting the agent platform’s available locations

protected void afterMove(){ inits();

String currentContainer=""; try { currentContainer = home.getContainerName(); } catch (ControllerException e) {e.printStackTrace();} if (currentContainer.contains("accomodation-booking")){ //accomodation - bookingWebSite bookingRequest(); if (contor<filteredLocations.size()-1){ contor = contor + 1; move(); } else addBehaviour(new notifyDone()); } else { //… the rest of the web pages

// Get available locations with AMS sendRequest(new Action(getAMS(), new QueryPlatformLocationsAction())); //Receive response from AMS MessageTemplate mt = MessageTemplate.and(MessageTemplate.MatchSender(getAMS()), MessageTemplate.MatchPerformative(ACLMessage.INFORM)); ACLMessage resp = blockingReceive(mt); ContentElement ce; try {

ce = getContentManager().extractContent(resp); Result result = (Result) ce; jade.util.leap.Iterator it = result.getItems().iterator(); while (it.hasNext()) { Location loc = (Location)it.next(); System.out.println(loc.getID()); locations.put(loc.getName(), loc); containerNames.add(loc); } } catch (Exception e) {

e.printStackTrace(); }

53

4.4 Evaluating the architectures: Mobile agents vs. stationary agents

In order to detect the better form of the system’s design we made a short comparative

analysis with the results presented in Table I. These results were obtained by running each

version of the application on a computer with the following system configuration: Intel(R)

Core™2Duo CPU T6600 @2.20GHz 2.20GHz, 4.00GB RAM. A detailed description for the

results obtained is presented in the following paragraphs.

TABLE I. Comparative Results

At first, the architecture based on stationary agents seemed better due to the fact that the

Web Agents work independently but all at the same time instead of one agent that needs to

collect all the data sequentially.

The total time needed for receiving the response from the first architecture would be

the maximum time needed by a Web Agent to collect all the data from the Web Page plus

the time taken by the communication between the agents. In comparison with this, the total

time needed by the second architecture would be the sum of the times needed to gather the

information from each Web Page. The time needed for communication is reduced in the

second approach due to the small number of agents involved.

At first glance, it would seem obvious for the first design to be better, but when adding

the whole context the facts change a little. A big number of agents running in the system at the

same time on the same platform, even the ones in a waiting state, represent a large number of

processes for the computer to handle, making it a little harder for the agents to work and for the

Stationary agents approach Mobile agents approach

Number of Web Agents/Locations(Web Pages) involved : 2

Response time 90528ms 85075ms

Number of Web Agents/Locations(Web Pages) involved : 3

Response time 106980ms 85647ms

54

Web Pages to be filtered when searching for the desired information. This aspect makes the

amount of time used in gathering data rise, resulting in a slower system.

Based on these results we concluded that the aspect of resource management needs

to be taken care of so the architecture based on mobile agents is preferred in this context.

Another advantage of the mobile agent design would be the security of the channel the

agents are communicating on. Supposing we want to develop a booking agent correlated with the

current system, the security of the transactions needs to be prioritized.

Besides all this, we specify that the test results might change when the application is ran in

on a different system configuration with another internet connection speed. So the mobile agent

approach has advantages in the current context: the way we collect the data combined with the

system, but when the information gathering side is improved, there is a high chance for the

stationary agent approach to be better.

4.5 Comparison to related work

Multi-agent systems in the area of e-travel are commonly used because even in the real

life travel domain the basic units involved are the human agents. The problem of representing

different existing scenarios is wide spread and different solutions have been brought to it.

Even though these systems are all oriented in the same direction, a proper comparison

regarding their performances is difficult to be made between them, because they don’t use the

same techniques and approaches for solving the problem, or because the problem’s context

slightly differs. Some of the authors tried to evaluate their work from the users’ point of view or

by analyzing the efficiency of the algorithms used, but the results of these evaluations were not

provided for the projects stated before.

Though a numerical evaluation is hard to make for these kinds of systems, some

similarities can be found and a brief comparison regarding their functionalities and approaches is

presented in the next paragraphs.

The similarity between all the encountered solutions is given by the architecture of the

system. If we take into consideration the big picture they all have the same basic structure: the

user asks for travel related offers, the agents take that request, they search for the response on the

55

Internet or inside a database and then they give the response back to the user. The functionalities

of the systems differ because of the scenario they each want to represent.

Besides this scheme each of them has a certain architecture design for the multi-agent

system. Even at this point the designs are quite similar. They all have an agent responsible with

the user interaction and one or more agents responsible with gathering the desired information.

Besides these the rest of the agents involved differ from a system to another. The particularities

of each one are at the level of agent behaviors and at the information gathering one. Some of the

projects have exploited a planning behavior for one of its agents while others have introduced a

form of learning or were focused on how to get the desired data.

Compared to these, our project follows the main scheme stated before. The architecture

proposed has a simple design but still manages to cover all the aspects needed. As a particularity

the paper shows a way of using mobile agents in such a system. This usage offers the projects

some advantages over the approach with stationary agent. These advantages include a better

management of the computer’s resources and a strong base for further improvements related to

the mobile agents’ strong points such as the security of the communication channel.

Taking into consideration the nature of this kind of projects there is not a proper way of

comparing or evaluating them. That is why the comparison is just from the point of view of the

functionalities. Maybe an evaluation system could be offered to the system’s users, but even then,

the results might not be very accurate.

4.6 Further improvements

Our work made so far offers a flexible system that can be improved and extended in

different directions. Some of the future improvements that can be made are:

Adding new features to the project such as a planning agent for creating a proposal for the

whole trip regarding all aspects of it such as accommodation, transport, events.

Adding the planning capability to the Coordinator Agent so it would be able to schedule the

tasks given to other agents, especially in a global coordinator context.

Creating a global Coordinator Agent placed between the user’s assistant agents and the web

agents placed on the Web Pages.

Implementing and improving the Personal Travel Assistant’s learning capability.

56

Exploiting the usage of mobile agents by adding features that require a better security such

as booking services.

Adding more Web Sites for gathering information and/or finding a way of dynamically

modifying the list and then using a more general technique to gather the data that can be

used on all the Web Sites from the list.

Finding a better solution for the information gathering problem. Semantic Web seems like a

good direction because of its continuous development.

Extending the application to other platforms such as mobile devices. This extension is

possible due to JADE’s LEAP libraries that allow the development of agents for mobile

devices.

57

CONCLUSIONS

Multi-agent systems in the area of e-travel are commonly used because even in the real

life travel domain the basic units involved are the human agents. The problem of representing

different existing scenarios is wide spread and different solutions have been brought to it.

In this paper, we have introduced an approach for representing a real scenario from the

tourism area. The aforementioned scenario is one where a person wants to find out information

such as prices and availability of different travel related elements like hotels and transportation. At

this point, an application like the one we presented comes as an aid to the user.

Through our work, we managed to conclude that a computational representation using

agents is possible for this scenario and the multi-agent system comes as a solution for developing

it. Through the comparison made between the usage of stationary agents and mobile agents we

came to the conclusion that, under the conditions specified, mobile agents offer additional

advantages to the project’s design such as lowering the time needed for getting the response and

improving the management of the computational resources used by the application.

Since the solution proposed creates a flexible system, it can be easily extended in different

directions. The first directions being considered are the ones that would improve the system’s

performance and functionalities such as the travel agent’s learning capability or the coordinator

agent’s task scheduling for a better management of the Web Agents.

58

BIBILIOGRAPHY

1. Agent Oriented Software Pty. Ltd.: Jack Intelligent Agents-Agent Manual, 4.1 ed.,

Australia, 2003

2. Beelen M., Datcu D., Rathkrantz L.: Personal Intelligent Travel Assistant- A distributed

approach, CSREA Press,pp. 24-30, 2005

3. Bellifemine F. L., Caire G., Greenwood D.: Developing Multi-Agent Systems with JADE,

Wiley, February 2007.

4. Ben-Ameur H., Bedard F., Vaucher S., Kropf P., Chaib-Draa B., Gerin-Lajoie R.:

NADIM-Travel: A Multiagent Platform for Travel Services Aggregation, In proceedings

of ENTER2004, eds Springer Verlag, Cairo, Egypt, January 26-28, 2004.

5. Caire G.: JADE tutorial – JADE programming for beginners, June 2009.

6. Camacho D., Borrajo D., Molina J.M.: Intelligent Travel Planning: A Multi-agent

Planning System to Solve Web Problems in the e-Tourism Domain, “Journal of

Autonomous Agents and Multi-Agent Systems”, pp. 387-392, December 2001.

7. Cohen, P.R., Cheyer, A.J., Wang, M., Baeg, S.C.: An Open Agent Architecture, AAAAI

Spring Symposium pp.1-8, 1994

8. FIPA Agent Management Specification [FIPA00023]

http://www.fipa.org/specs/fipa00023/index.html

9. FIPA Abstract Architecture Specification [FIPA00001]

10. Foundation for Intelligent Physical Agents Specifications: http://www.fipa.org

11. Ganzha M., Gawinecki M., Paprzycki M., Gasiorowski R., Pisarek S., Hyska: Utilizing

Semantic Web and Software Agents in a Travel Support System, In: “Semantic Web

Technologies and eBusiness: Virtual Organization and Business Process Automation”,

Idea Publishing Group, 2006.

12. Halatsis C., Stamatopoulos P., Karali I., Mourlas C., Goucos D., Margaritis D.,

Fouskakis C., Kolokouris A., Xinos P., Reeve M., Veron A., Scuerman K. and Li L.-L.:

MaTourA: Multi-agent Tourist Advisor, International Conference on Information and

Communication Technology in the Field of Tourism (ENTER'94), pp. 140-147,

Innsbruck,Austria, January 1994.

59

13. Howden, N., Rönnquist, R., Hodgson, A., Lucas A.: JACK intelligent agents – Summary

of an agent infrastructure, Proceedings of the 5th International Conference on

Autonomous Agents, Montreal, 2001

14. HtmlUnit: http://htmlunit.sourceforge.net/

15. Jade: http://jade.cselt.it/

16. Jennings N.R., Wooldridge M.: Applications of Intelligent Agents, In, Jennings, N.

R. and Wooldridge, M. J. (eds.) Agent Technology: Foundations, Applications and

Markets. Agent Technology: Foundations, Applciations and Markets , Springer, 3-28,

1998.

17. Martin, D.L., Cheyer, A.J., Douglas B.M.: The Open Agent Architecture: A Framework

for Building Distributed Software Systems, Applied Artificial Intelligence, vol. 13, no. 1-

2, pp. 91-128, January-March 1999.

18. Mitchel T.: Machine Learning, McGraw-Hill Science/Engineering/Math, March 1, 1997.

19. Moreno A.: Agent Applications in Tourism, in Issues in Multi-agent systems, Whitestein

Series in Software Agent Technologies and Automatic Computing, 2008.

20. Russel S., Norvig P.: Artificial Intelligence: A modern approach, Prentice-Hall, 1995.

21. Shoham Y.: Agent Oriented Programming, Journal of Artificial Intelligence 60(1), pp.

51-92, March 1993

22. Shoham Y.: AGENT0: A simple agent language and its interpreter, In Proceedings of the

National Conference on Artificial Intelligence, pp. 704-709, 1991

23. Shoham Y.: Agent Oriented Programming, Tehnical Report STAN-CS-1335-90,

Computer Science Department, Stanford University, Stanford, CA 94305, 1990.

24. Siricharoen W. V.: Learning Semantic Web from e-tourism, Proceedings of the 2nd KES

International conference on Agent and multi-agent systems: technologies and

applications, Incheon, Korea, March 26-28, 2008.

25. Stone, P., Veloso, M.: Multiagent Systems: A Survey from a Machine Learning

Perspective, Journal of Autonomous Robots, Volume 8, Number 3, 2000.

26. Sycara, K.: MultiAgent Systems, AI Magazine, 19 (2), 1998

27. Weiss G.: Multiagent Systems – A modern Approach to Distributed Modern Approach to

Artificial Intelligence, The MIT Press, Cambridge, Massachusetts, London,

England,1999.

28. Wooldridge M.: An introduction to Multiagent Systems, 2nd Edition, Wiley, May 2009.