Introducing Mobility into Agent Coordination Patterns

Sergio Esparcia

and Ichiro Satoh

Departamento de Sistemas Inform

aticos y Computaci

on, Universitat Polit

ecnica de Val

encia, Valencia, Spain

National Institute of Informatics, Chiyoda-ku, Tokyo, Japan

Keywords:

Mobile Agents, Coordination, Interaction, KQML.

Abstract:

This paper proposes coordination patterns that support matchmaking, communication and interaction among

mobile agents in addition to stationary ones. Mobile agent technology is a powerful implementation technique

of distributed systems, but we need to manage migrations of agents, including their current and destination lo-

cations. The proposed patterns enable us to deﬁne coordination between mobile agents or between mobile and

stationary agents without explicitly knowing their migrations between locations. They are mostly based on the

Knowledge Query and Manipulation Language, one of the most extended Agent Communication Languages,

but also new patterns are proposed. Additionally, a case of study about tourism is presented.

1 INTRODUCTION

Agent coordination is an important issue when some

agents are required to work together towards a global

goal (e.g., if these agents belong to a Multi-Agent

System (MAS) (Ferber, 1999)). Commonly, agents

have different abilities and capabilities, so they have

to collaborate to achieve this global goal, which will

satisfy also the individual goals of the agents. There

exists the possibility that agents cannot achieve their

goals if they are attached to a speciﬁc environment

or machine (i.e., they are stationary). For this rea-

son, mobile agents (Lange and Oshima, 1999) are

implemented to be able to move around different ma-

chines and continue their execution there. Mobile

agents have to be able to understand the languages and

protocols of the destination machine. Mobility also

brings new issues to tackle when dealing with coor-

dination. For example, mobile agents may not know

their next destinations, because they may not have the

topology of the current network. Thus, the capabili-

ties, services, and agents of reachable computers are

unknown to them. Therefore, a matchmaking mecha-

nism that enables mobile agents to discover other sta-

tionary or mobile agents and destinations is required.

To solve this problem, a matchmaking mechanism

for stationary agents is extended with support to mo-

bility of agents. Agent communication languages

(ACL) (Labrou et al., 1999), such as the Knowledge

Query and Manipulation Language (KQML) (Finin

et al., 1994), present interaction patterns and perfor-

matives that focus on the matchmaking and commu-

nication between stationary agents that cannot change

their position and already know the location of their

communication partners. The KQML itself does not

support mobility of agents, but it is useful for new vis-

iting agents because since it is a well-known ACL by

the community of agent researchers, their interaction

patterns have became widely used not only in situa-

tions where KQML is used as the ACL employed by

agents, but in different scenarios where other ACLs

are used. Then, the KQML patterns are a suitable in-

teraction and coordination mechanism to be extended

with new patterns supporting mobile agents.

The objective of this paper is to deﬁne and present

new interaction patterns for KQML that extend the

original stationary features with new patterns that are

intended to improve coordination and interaction be-

tween mobile agents. These patterns give mobile

agents the capability of correctly managing their in-

teractions, no matter that the agents move from their

previous locations to a new ones, thus improving

the performance of the agents and helping them to

achieve not only their individual goals, but also when

agents are required to fulﬁl a set of global goals.

The rest of this paper is structured as follows: Sec-

tion 2 describes the background of this work. Sec-

tion 3 presents the main contribution of this work,

the patterns that support interaction and coordination

between mobile agents. Section 4 presents a case of

study based on tourism. Finally, Section 5 describes

our conclusions on this topic and the future work.

131

Esparcia S. and Satoh I..

Introducing Mobility into Agent Coordination Patterns.

DOI: 10.5220/0004813401310138

In Proceedings of the 6th International Conference on Agents and Artiﬁcial Intelligence (ICAART-2014), pages 131-138

ISBN: 978-989-758-016-1

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

2 BACKGROUND

This section deﬁnes the concepts that are part of the

patterns that enhance KQML with mobility features.

Agents and mobile agents are deﬁned, as well as the

KQML agent communication language, and the envi-

ronment where our proposal is deployed.

Agents (Wooldridge and Jennings, 1995) are au-

tonomous software entities that act representing users.

These agents have functionalities in order to help the

users they represent. Agents are able to be station-

ary or mobile, depending on whether they can move

around different computers or not. Also, they are able

to communicate with other agents. The agents used

in this paper are deﬁned as intelligent, autonomous,

social, able to learn, and mobile.

A mobile agent (Lange and Oshima, 1999) is a

process that can transport its state from one environ-

ment to another, with its data intact, and be capable

of performing appropriately in the new environment

the same activities as in the original one. Mobile

agents decide when (e.g., to look for a better resource

allocation, a less hostile environment to work, etc.)

and where to move. When a mobile agent decides

to move, it saves its own state, transports this saved

state to the new host, and resumes execution from

the saved state. This makes them a powerful tech-

nique for implementing distributed applications. Ad-

vantages of mobile agents are: computation bundles,

parallel processing, dynamic adaptation, tolerance to

network faults, ﬂexible maintenance, and portability.

Knowledge Query and Manipulation Lan-

guage (KQML) (Finin et al., 1994) is an ACL to sup-

port communication between intelligent agents. Each

KQML message contains the action to be carried out

(also known as the performative) as well as the param-

eters of this communication (e.g., sender, receiver,

etc.). In this work, we propose a subset of KQML

patterns that require a facilitator: recommend, broker,

subscribe, recruit, and forward; and the point-to-point

communication pattern, which does not require it.

In the recommend pattern, the service provider

agent advertises one of its capabilities to the facilita-

tor. Then, the client agent queries the facilitator about

an agent that has to be able to develop the same capa-

bility. In this case, the facilitator will send the recom-

mendation to the client agent, and ﬁnally this agent

will send the query to the service provider. The bro-

ker pattern works in a similar way as the recommend

pattern. That is, the service provider advertises one of

its capabilities, and then the client queries the facilita-

tor to act as a broker for the same capability. Then, the

facilitator will ask the service provider and then col-

lects its answer and sends it to the client agent. This

is, the facilitator acts as a mediator in the communi-

cation process between client and service provider.

The subscribe pattern consists on the service

provider querying the facilitator to subscribe to all the

answers of a query. Then, the facilitator sends the

client all the answers it receives to the query. The re-

cruit pattern is similar to the broker pattern, but the

service provider sends the answer to the client di-

rectly. Finally, in the forward pattern, the client sends

a query to the facilitator, but asking it to forward the

query to a speciﬁc agent, because the client agent

knows a speciﬁc service provider agent, but for any

reason it does not know its location.

For the deﬁnition of the environment, this pro-

posal relies on the Agents & Artifacts conceptual

framework (Ricci et al., 2007). This framework rep-

resents and structures the environment by means of

an aggregation of workspaces. The workspace where

an agent is located is considered as its local environ-

ment, and its granularity can be chosen by the sys-

tem designer (e.g., a workspace could be a portion of

a machine, the whole machine, or a network of ma-

chines), being possible to make a scalable system.

Workspaces provide a physical description of the

environment, in a similar way as the real world is

described. Each workspace has an absolute posi-

tion inside the environment. Workspaces can be in-

tersected and nested between them, features that al-

low an agent to be located in different workspaces

at the same time, and to make the system extensible

(adding new workspaces, merging or splitting exist-

ing workspaces, etc.). An agent is placed, at least,

in one workspace, so this agent has a speciﬁc loca-

tion within the environment. It is also possible for an

agent to move inside a workspace if the workspace

is big enough. In this case, the position of the agent

will not be the position of the workspace it is located,

but a position inside the workspace. The proposed

approach assumes that each mobile agent knows the

facilitator located in their current environment using a

service discovery protocol via multicast communica-

tions. For example, each facilitator periodically issues

heartbeat messages with its agent identiﬁer so newly

visiting agents receive the messages to know the fa-

cilitator that is available in their current locations.

The A&A framework also includes artifacts, enti-

ties located in the environment that are reactive (but

not proactive), and provide functionalities to agents

(that are able to use artifacts in order to achieve their

objectives). Artifacts feature: (i) observable proper-

ties, which are able to be checked by agents but not

directly modiﬁed by them; (ii) operations, which are

functions that agents can execute; and (iii) link oper-

ations, similar to operations but they require another

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

132

artifact to be completed. We rely on the use of arti-

facts instead of agents in situations where proactivity

is not required, but it is necessary to be provided with

entities providing speciﬁc functionalities.

3 COORDINATION PATTERNS

FOR MOBILE AGENTS

Since mobile agents can migrate between computers,

other agents and external systems that want to inter-

act with them need mechanisms to locate their cur-

rent positions. However, such mechanisms are com-

plicated and costly, so that they should be supported

by particular agents or services. Agents also should

select their partners, which may be mobile or station-

ary, according to their functions. Therefore, we use

agents corresponding to facilitators studied in the lit-

erature of agents (e.g., KQML), and distributed ob-

jects (e.g., CORBA (Vinoski, 1997)). However, ex-

isting approaches do not support mobility of agents.

KQML provides a set of agent communication pat-

terns that rely on stationary agents, so an agent knows

the location of the agent it is communicating with, or

the location of the facilitator. Therefore, agent mobil-

ity is an interesting feature to be supported.

Since this work focuses on agent mobility, the

KQML patterns have been adapted to mobile agents,

and this section presents the modiﬁcation of well-

known patterns. Most of the included patterns rely on

a facilitator agent which helps in the communication

process, but the point-to-point communication pattern

is also included. Notice that it is also presented a pat-

tern which is not included in the KQML speciﬁcation,

the footprint pattern, but it is also interesting when

dealing with mobile agents.

These patterns represent basic communicative

structures between agents featuring mobility proper-

ties. The patterns are able to be combined (e.g., by ex-

ecuting them sequentially), thus creating more com-

plex patterns to deal with more complex problems and

situations. The patterns are presented in a generic way

in order to facilitate both, its combination and its us-

age in different frameworks that use different ACLs.

Since these patterns focus on basic communica-

tion structures, it can be seen that some entities partic-

ipating in the patterns are not proactive, so they could

be represented as artifacts instead of agents, at least

from the point of view of one speciﬁc pattern. How-

ever, from the point of view of the global system (due

to pattern combination) this entity could require to be

proactive, so it has to be an agent. Therefore, these

entities are represented as agents in this paper, giving

system designers the ﬁnal decision about representing

them as agents or artifacts.

The following subsections describe the proposed

patterns by means of a text description and for most

of them a ﬁgure is provided. Figure 1 presents the

legend of the graphical notation. The number written

next to each message depicts the order number.

Agent WorkspaceArtifact

Figure 1: Legend of the graphical notation.

3.1 Point-to-Point Communication

In a point-to-point communication (Figure 2), agent

A makes a query directly to agent B. Agent B knows

where A is located because of the source point of the

received message. However, if the location of agent

A changes after it queried, at the moment agent B an-

swers A’s query, B would not know where to send the

message, or it would send the message to an empty

location. In order to solve this situation, A could send

a message to B indicating its current location while

A does not receive any answer from B. This solution

could maybe overload the network, but it is required

to avoid failures when sending the answer message.

Agent B

1. ask(x) Agent A

2. move(Location)

Agent A

4. tell(x)

3. tell(Location)

Figure 2: Point-to-point communication pattern.

3.2 Register Pattern

This pattern is used by agents who join a new

workspace (Figure 3, left). The facilitator in charge

of that environment has no information about the new

agent and the latter has no information about the fa-

cilitator. Therefore, we use two approaches as service

discovery protocols, e.g., UPnP and Jini (Allard et al.,

2003). Using UPnP, the new agent informs its pro-

ﬁle information (identiﬁer, functionalities, and so on)

to the facilitator by using a multicast communication

protocol (Banavar et al., 1999) e.g., UDP multicast-

ing. If the workspace is big enough, the new agent has

to include its location inside its proﬁle information.

With Jini, the facilitator periodically sends messages

with its address within the workspaces that it supports

through a multicast protocol. When the new agent re-

ceives the message returns its proﬁle information to

the facilitator speciﬁed in the address of the message.

IntroducingMobilityintoAgentCoordinationPatterns

133

3.3 Unregister Pattern

The unregister pattern is the inverse version of the

is intended to leave the workspace that it is populat-

ing. Unregistering from a workspace means to cancel

all the pending activities with the facilitator of that

workspace. Depending on how the facilitator is im-

plemented, it could maintain the agent data inside its

Knowledge Base (KB), since this information could

be interesting for solving future queries.

However, a problem arises with this pattern if a

message is sent to agents that unregistered from the

environment, because the message will not arrive to

its addressee agent. This problem is handled with the

use of the footprint pattern (see subsection 3.11). If

a message arrives to an agent which has unregistered

from the workspace, it will be forwarded by the foot-

print artifact to the current location of the agent.

3.4 Transport Address Pattern

An agent can also move around its current workspace

(i.e., its local environment) if its size and architec-

ture allows to do so (Figure 3, right). When an agent

moves inside a workspace, it has to communicate its

new location in the workspace to the facilitator using

the transport address performative.

Facilitator

Agent

1. register(A,L)

Facilitator

Agent

1. transport-address(A,L)

Agent

Figure 3: Register pattern (left); and Transport address pat-

tern (right).

3.5 Broker Pattern, Mobile Service

Provider Agent

The broker pattern (Figure 4, left) is used when the

client agent wants the facilitator to tell it an appro-

priate agent who could be able to provide a solution

for its query. In this pattern, client and provider do

not communicate to each other directly. Therefore,

the client is not informed about the position of the

service provider since it does not require the position

for communication purposes. For the service provider

agent it is required to send updated information about

its location to the facilitator because the facilitator has

to be able to locate the service provider at any time,

to answer the query of the client.

3.5.1 Fetch Pattern

This is a broker situation (Figure 4, right) where the

client asks the facilitator to fetch himself with a ser-

vice provider agent to help it to achieve a goal. Be-

fore, the service provider agent had advertised that it

is ready to fetch with another agent. Having received

messages from the two agents, the facilitator sends to

the service provider agent the information of the client

who asked for fetching. Finally, the service provider

agent moves to the location of the client.

Facilitator

Client

Mobile

Server

2. broker(ask(X,L))

1. advertise(ask(X))

5. tell(X)

4. tell(X)

3. tell(X)

Facilitator

Client

Mobile

Server

2. broker(fetch(S,C))

1. advertise(fetch(S))

3. fetch(C)

4. move-to(L)

Figure 4: Broker pattern with mobile service provider agent

(left); and Fetch pattern (right).

3.6 Broker Pattern, Mobile Client

Considering the client to be mobile is very similar as

considering it as stationary. The only difference is

that the client has to send its updated location to the

facilitator, thus assuring receiving the answer to the

query associated to the broker performative.

3.7 Recommend Pattern, Mobile

Service Provider Agent

In the recommend pattern (Figure 5) client and ser-

vice provider agents communicate in a direct way.

First, the service provider will advertise to the facil-

itator the performative it is able to answer, as well

as its location. The client will then ask for a recom-

mendation to the facilitator including the query to be

solved. The facilitator sends the client the data of the

service provider agent, including its location, and then

the client directly asks the server provider. Finally,

the server tells its answer to the client. In this case,

the service provider agent has to send updated infor-

mation about its location to the facilitator.

Facilitator

Client

Mobile

Provider

2. recommend(ask(X,L))

1. advertise(ask(X,L))

3. recommend(ask(X,L))

4. ask(X)

5. tell(X)

Figure 5: Recommend pattern with mobile service provider

agent.

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

134

Facilitator

Sender

Mobile

Receiver

1. forward(Receiver,ask(x))

2. forward(Receiver,ask(x))

Facilitator

4. ask(x)

5. tell(x)

6. tell(x)

7. tell(x)

Mobile

Receiver

0. unregister(Receiver)

Facilitator

3. forward(Receiver,ask(x))

Figure 6: Forward pattern with mobile receiver (only to selected facilitators).

3.8 Recommend Pattern for

Destination, Mobile Client

This case is similar to the case of the recommendation

pattern for a mobile service provider agent. The dif-

ference here is that the content of the query made by

the client is the speciﬁc location to get a requirement.

In this case, the facilitator recommends the service

provider to the client, and sends not only the name

or identiﬁer, but the location of this service provider.

Therefore, after receiving this recommendation, the

client makes use of its mobility features and moves

where the service provider is located to get the re-

quirement (resource, information, etc.) that it queried.

3.9 Forward Pattern, Mobile Receiver

In the forward performative, the sender of the mes-

sage knows about the existence of a receiver that is

able to fulﬁl the query it intends to solve, but it does

not know the current location of the receiver, so the

use of a facilitator is required. Nevertheless, since

the receiver is mobile, it is possible to move to a dif-

ferent workspace. When this situation occurs, then

the facilitator has to send a broadcast performative

to ask the facilitators from other workspaces. Since

all facilitators are stationary, they know the location

of other facilitators, so they are able to communicate

between them. Each facilitator will look around its

workspace for the receiver agent. Once located, the

receiver agent will answer the query, and the two fa-

cilitators will bring the response to the sender.

A more efﬁcient solution for forwarding is to

make a multicast, sending the message to a limited

number of agents (Figure 6). The facilitators to send

the multicast are chosen by proximity or by using

the previous knowledge about the type of agents that

populate the different environments. If the receiver

agent is not located inside any of the environments of

these facilitators, then they will forward the message

to more facilitators until the receiver gets the message.

Then, the facilitator in the environment of the receiver

will send the answer to the environment of the client.

There is a third possibility for solving this prob-

lem, the use of a directory. A directory contains the

name and/or the identiﬁer of an agent, and the cur-

rent location of the agent. Therefore, the facilitator

will send the forward message to the facilitator of the

correct environment, or will directly ask to the agent.

This approach supposes new problems because in or-

der to keep these directories up-to-date, facilitators

have to exchange messages between them. However,

it improves the broadcast approach, since the number

of messages using the directory is smaller than the

number of messages when broadcasting.

3.10 Forward Pattern, Mobile Sender

In the case of the forward pattern with mobile sender,

the sender has to send the facilitator its updated lo-

cation information. This is critical when the message

is a query that requires an answer from the receiver.

Therefore, if the information about location that the

facilitator has inside its KB is not up-to-date, sending

the answer back will fail.

3.11 Footprint Pattern

When an agent wants to send a message to another

agent, it must know its current location. Therefore, a

mechanism is needed for tracking a mobile receiver.

Immediately before the receiver moves into another

workspace, it creates and leaves a footprint artifact

behind. This artifact has a more updated location of

the receiver and receives messages on behalf of it.

Two approaches to ﬁnd the receiver are supported:

(i) each footprint artifact registers the latest location

of the receiver (as an observable property), so after

receiving a query, the footprint artifact (using reactiv-

ity) sends it directly to it (Figure 7); and (ii) a footprint

artifact only stores the next location of the mobile re-

ceiver, so the queried footprint artifact has to query

another footprint artifact, and so on, until the agent is

located and the query is sent to it (Figure 8).

This pattern is not part of the KQML speciﬁca-

tion, but it is included here because of its relevance

IntroducingMobilityintoAgentCoordinationPatterns

135

Footprint2

Footprint1

Mobile

Receiver

0. move 0. move

Sender

1.ask(x)

2. ask(x)

Figure 7: Footprint pattern (ﬁrst approach).

Footprint2

Footprint1

Mobile

Receiver

0. move 0. move

Sender

1.ask(x)

2. ask(x)

3. ask(x)

Figure 8: Footprint pattern (second approach).

on dealing with mobile agents. Differently from the

forward pattern, using footprint artifacts reduces the

number of messages that are required to be sent be-

fore ﬁnding the receiver, and avoids to use facilitator

agents to ﬁnd the receiver. However, this pattern does

not substitute the use of forwarding, which is useful

in other situations (e.g., if it is not allowed to place

artifacts in the environment).

3.12 Subscribe Pattern, Mobile Service

Provider Agent

The subscribe performative is used by a client to ask

the facilitator about the truth of a statement. The fa-

cilitator waits until a conﬁrmation of the statement

is given by any agent of the workspace. However,

this conﬁrmation is not requested by the facilitator,

so agents proactively inform the facilitator. The case

of the mobile service provider agent (Figure 9, left) is

slightly different from the case where this agent is sta-

tionary. The difference between both situations is that

the service provider agent has to inform the facilitator

about its movements, to make sure to be found by the

facilitator when it needs to solve a query. However,

in the case of subscription it is not a strong require-

ment because of the proactivity of the service provider

agent when sending messages to the facilitator.

3.13 Subscribe Pattern, Mobile Client

Differently from the mobile service provider agent sit-

uation, in this case (Figure 9, right) the mobility of the

client is a key aspect when an agent subscribes to a

facilitator. It is important to notice about that because

a client could send a subscribe performative to the fa-

cilitator, and then it could move to a different place.

When a client agent moves from one workspace to

another, it has to inform the facilitator, and to unsub-

scribe if it has any pending subscription queries. In

the case that the client does not unsubscribe before

Facilitator

Mobile

Client

Server

1. subscribe(ask(X))

2. tell(X,L)

3. tell(X)

4. unsubscribe(ask(X))

New

environment

5. move-to

Facilitator

Client

Mobile

Server

1. subscribe(ask(X))

2. tell(X,L)

3. tell(X)

Figure 9: Subscribe pattern with: Mobile Service Provider

Agent (left); and Mobile Client (right).

moving to a new workspace the network will be over-

ﬂowed with messages from the facilitator while trying

to locate the client. Therefore, it is an implementa-

tion decision to automatically unsubscribe if the agent

leaves the workspace so as to keep the network load

under control or to keep the subscription active until

the client unsubscribes. This second option could be

interesting if the agent has moved from the workspace

only as a temporary situation and it plans to come

back, so it wants to keep updated information com-

ing from the workspace that it has temporarily left.

3.14 Recruit Pattern, Mobile Service

Provider Agent

The recruit pattern (Figure 10, left) consists on a

client sending a petition to the facilitator to ﬁnd an

agent who is able to ﬁnd a solution for its query. Here,

the answer to the query from the client is given di-

rectly by the service provider agent to the client. Mo-

bility of the service provider agent is employed to as-

sure the correct arrival of the information to the client.

The service provider agent will move to the location

of the client, thus delivering the answer to the query,

and then it will come back to its initial position.

3.15 Recruit Pattern, Mobile Client

The main feature of the recruit pattern is that exists di-

rect communication between the client and the service

provider agent. Thus, mobility of any of the agents

could suppose a failure in the process if the agents

do not ﬁnd each other. The case of a mobile client

(Figure 10, right) is important because if it moves,

the service provider agent would not be able to locate

it. In order to avoid this problem to happen, when

the client sends a recruiting performative the facilita-

tor has to be updated with the current position of the

client. When the facilitator sends the received query

to the service provider agent, it also sends the current

location of the client, thus being able for the service

provider to send the message to the address where the

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

136

Facilitator

Client

Mobile

Provider

1. recruit(tell(X))

2. advertise(ask(X))

3. ask(X)

4. move-to(tell(X))

Facilitator

Mobile

Client

Provider

1. recruit(tell(X,L))

2. advertise(ask(X))

3. ask(X,L)

4. tell(X)

Figure 10: Recruit pattern with: Mobile Service Provider

Agent (left); and Mobile Client (right).

client is located. In the case the client leaves the envi-

ronment the recruit performative is canceled.

4 CASE OF STUDY: TOURISM

The tourism market is increasing its electronic busi-

ness in the last years, with more products and services

being offered online. However, the prices offered to

the users of the tourism market are not stable, and they

change due to the ﬂuctuation of the demand at dif-

ferent moments. Additionally, competence between

tourism providers is another factor that inﬂuences the

prices, with sales and special discounts.

For this reason, clients are interested on ﬁnding

the best available prices for the tourism products and

services they require. Due to the aforementioned ﬂuc-

tuations on the prices, the users will spend so much

time looking for the best available prices. Therefore,

a tourism online market based on mobile agents is

created. This market is open, including agents rep-

resenting the clients, and agents representing the dif-

ferent tourism providers. A client agent has stored

the preferences of the human client which it is rep-

resenting (e.g., budget, preferred destinations, etc.)

and its goal is to ﬁnd a trip that satisﬁes these pref-

erences. Each tourism provider agent offers products

of a speciﬁc type (e.g., hotels, ﬂights, train tickets,

etc.). Clients and providers access the system in order

to look for products and services (in the case of the

clients), or for offering and publicizing them (in the

case of providers). The environment of the system is

distributed among different workspaces, one for each

type of products or services. For example, there is

a workspace for hotel reservations, another for ﬂight

tickets, etc. It is necessary for a client agent to move

around different workspaces to get the products and

services of the desired trip. Each workspace has its

own facilitator that provides the functionalities de-

scribed in the patterns. In case that the client agent

was not able to move around different workspaces, it

would be necessary to have more than one client agent

per user, thus complicating the process of ﬁnding an

appropriate trip, from both computational and tempo-

ral points of view. Therefore, using a mobile agent

saves time and computational resources.

A scenario depicting the use of the broker and

forward patterns in the tourism market is presented.

Here, a mobile client agent has the goal of reserving

a hotel and buying the ﬂight tickets to the destina-

tion. In the example (Figure 11), there are two differ-

ent workspaces (Flight and Hotel), where reservations

for ﬂights and hotels, respectively, are carried out. In

each workspace, providers advertise their capabilities

to the respective facilitators. The mobile client is lo-

cated in the ﬂight workspace, and queries the facilita-

tor to act as a broker to ﬁnd a proper ﬂight. After mak-

ing this query, the client unregisters from the ﬂight

workspace and registers into the hotel workspace (the

to improve the readability of the ﬁgure). Once in the

hotel workspace, the client asks the hotel facilitator to

work as a broker to ﬁnd a hotel that matches its re-

quirements. In this moment, there are two concurrent

tasks (i.e., some messages have the same order num-

ber). On the one hand, the ﬂight facilitator ﬁnds a

ﬂight provider that is offering ﬂights that match the

client expectations and gets a ﬂight for the client.

Then, the ﬂight facilitator sends a forward message

with the ﬂight information to the hotel facilitator. On

the other hand, the hotel facilitator sends the query of

the mobile client to the hotel provider, which answers

it back to the facilitator including the chosen hotel.

Finally, the hotel facilitator sends the answer of both

queries, ﬂight and hotel, to the client, whose desired

trip is now planned and reserved.

From the human point of view, this approach saves

time and the agent is able to search in a wider scope

than the human herself. From a computational view,

having only one agent in control of reserving the trip

facilitates the computation.

5 CONCLUSIONS AND FUTURE

WORK

This paper has presented a proposal for introducing

mobility concepts into the KQML interaction pat-

terns, also including new patterns that support mobile

agents. These patterns are aimed at improving coor-

dination and interaction between mobile agents, since

coordinating entities that are able to move around dif-

ferent environments supposes a challenge due to the

uncertainty about the exact location of the agents par-

ticipating in the communicative process. There are

patterns that rely on a point-to-point communication,

but most of the patterns rely on the existence of a fa-

cilitator that knows the agents populating its environ-

ment and is also able to communicate with facilita-

IntroducingMobilityintoAgentCoordinationPatterns

137

Flight

Facilitator

Flight

Provider

1. advertise(ask(flight))

4. ask(flight)

3. Move-to(Hotel)

6. forward(MobileClient,tell(flight))

5. tell(x)

2. broker(ask(flight))

Hotel

Facilitator

Mobile

Client

4. broker(ask(hotel))

7. tell(flight,hotel)

5. ask(hotel)

1. advertise(ask(hotel))

Mobile

Client

Hotel

Provider

6. tell(hotel)

Figure 11: Example for the tourism market with a mobile client and two different workspaces.

tors in other environments, thus making possible for

agents located in different environments to commu-

nicate through the facilitators. The coordination pat-

terns proposed in this paper are also useful in the real

world where agents, e.g., humans, can move between

locations to work or meet others, like mobile agents.

As future work, the patterns presented here will be

implemented in an agent platform that gives support

to mobile agents, like MobileSpaces (Satoh, 2003), or

to MAS, as THOMAS (Argente et al., 2011), along

with other useful coordination patterns for mobile

agents we found. Since patterns are deﬁned in a

generic way in this paper, they can be then expressed

by means of the speciﬁc ACL of the framework where

the patterns will be implemented in. We also plan to

use the approach in physically mobile systems, and

real societies whose people move between locations.

ACKNOWLEDGEMENTS

This work is supported by the NII International

Internship Program, the MINECO/FEDER grant

TIN2012-36586-C03-01, the TIN2009-13839-

C03-01 project of the Spanish government, and

CONSOLIDER-INGENIO 2010 under grant

CSD2007-00022.

REFERENCES

Allard, J., Chinta, V., Gundala, S., and Richard III, G.

(2003). Jini meets upnp: an architecture for jini/upnp

interoperability. In Proc. Symposium on Applications

and the Internet, pages 268–275. IEEE.

Argente, E., Botti, V., Carrascosa, C., Giret, A., Julian, V.,

and Rebollo, M. (2011). An abstract architecture for

virtual organizations: The thomas approach. Knowl-

edge and Information Systems, 29(2):379–403.

Banavar, G., Chandra, T., Mukherjee, B., Nagarajarao, J.,

Strom, R. E., and Sturman, D. C. (1999). An ef-

ﬁcient multicast protocol for content-based publish-

subscribe systems. In Proc. 19th IEEE Int. Conf. Dis-

tributed Computing Systems, pages 262–272. IEEE.

Ferber, J. (1999). Multi-agent systems: an introduction to

distributed artiﬁcial intelligence, volume 1. Addison-

Wesley Reading.

Finin, T., Fritzson, R., McKay, D., and McEntire, R.

(1994). Kqml as an agent communication language.

In Proc. 3rd international conference on Information

and knowledge management, pages 456–463. ACM.

Labrou, Y., Finin, T., and Peng, Y. (1999). Agent commu-

nication languages: The current landscape. Intelligent

Systems and Their Applications, IEEE, 14(2):45–52.

Lange, D. B. and Oshima, M. (1999). Seven good rea-

sons for mobile agents. Communications of the ACM,

42(3):88–89.

Ricci, A., Viroli, M., and Omicini, A. (2007). Give

agents their artifacts: the a&a approach for engineer-

ing working environments in mas. In Proc. 6th int.

conference on Autonomous agents and multiagent sys-

tems, page 150. ACM.

Satoh, I. (2003). A testing framework for mobile computing

software. IEEE Transactions on Software Engineer-

ing, 29(12):1112–1121.

Vinoski, S. (1997). Corba: Integrating diverse applications

within distributed heterogeneous environments. IEEE

Communications Magazine, 35(2):46–55.

Wooldridge, M. and Jennings, N. R. (1995). Intelligent

agents: Theory and practice. Knowledge engineering

review, 10(2):115–152.

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

138