Agent Naming and Locating: Impact On Agent Design: working paper

Book Chapter

Reference

Agent Naming and Locating: Impact On Agent Design: working paper

TAHA, Karim, PILIOURA, Thomais

Abstract

Interest in network-centric programming and applications has surged over the last few years due to the exponential growth of the Internet and the widespread popularity of the WWW. In response to this, new techniques, languages and paradigms have evolved to facilitate the creation of such applications. Perhaps the most promising among them is the mobile agent paradigm. However, in order to take advantage of this new technology, several issues must be addressed, such as naming and locating mobile agents. These two services are necessary for efficient agent management. In this paper we discuss these issues and their impact on agent design. Several abstractions are introduced that allow an easy and flexible integration of these services in agent-based applications.

TAHA, Karim, PILIOURA, Thomais. Agent Naming and Locating: Impact On Agent Design:

working paper. In: Tsichritzis, Dionysios. Trusted objects = Objets de confiance . Genève : Centre universitaire d'informatique, 1999. p. 149-169

Available at:

http://archive-ouverte.unige.ch/unige:155916

Disclaimer: layout of this document may differ from the published version.

1 / 1

Agent Naming and Locating:

Impact On Agent Design

Karim Taha Tuomi Pilioura Working paper

Abstract

Interest in network-centric programming and applications has surged over the last few years due to the exponential growth of the Internet and the widespread popularity of the WWW. Jn response to this, new techniques, languages and paradigms have evolved to facilitate the creation of such applications. Perhaps the most promising among them is the mobile agent paradigm. However, in order to take advantage of this new technology, several issues must be addressed, such as naming and locating mobile agents. Th.ese two services are necessary for efficient agent management. Jn this paper we discuss these issues and their impact on agent design. Several abstractions are introduced that allow an easy and flexible integration of these services in agent-based applications.

1 Introduction

Mobile agent technology has received a great deal of interest over the last few years from both academia and industry. A mobile agent is a self-contained software element responsible for executing a process that can autonomously migrate during execution from machine to machine in a heterogeneous network. On each machine, the agent interacts with stationary agents, other mobile agents and local resources in order to accomplish its task.

According to various definitions [I] a mobile agent can exhibit a number of attributes. In this paper we are interested in the mobility and autonomy aspects of a mobile agent. These two characteristics have been proven enough for making mobile agent technology increasingly popular for network-centric programming. Compared to traditional distributed computing schemes, mobile agents promise (at least in many cases) to cope more efficiently and elegantly with a dynamic, heterogeneous and open environment such as Internet. In contrast with mechanisms such as RPC or single message passing, the use of mobile agents for distributed applications has several potential benefits, including bandwidth savings, limited latency, higher degree of robustness and improved support for nomadic computing and disconnected operation.

The benefits that mobile agent technology offers make it an appropriate solution for many Internet applications. We define an agent-based application (or ABA for short) as a potentially large-scale distributed application based on agents in an open and heterogeneous context such as the Internet. The last ten years have seen a marked interest in ABAs,

spanning applications as diverse as active networks. [8][9], information retrieval [10] and electronic commerce [11][12][18].

Designing flexible and reliable ABAs requires the integration of some mechanisms for efficient agent management. In this paper, we examine two important aspects of agent management, namely agent naming and agent locating. Agent naming allows applications to bind symbolic names to agents in order to address them later. Agent locating introduces mechanisms for retrieving agents over the network. Those two mechanisms are needed for inter-agent communication, remote management such as orphan detection [7] and efficient persistency management.

Integrating efficient naming services in ABAs impose some requirements. We first list some of them and then discuss how agents should be designed in order to cope with these requirements. We also describe a design pattern that deals with agent naming in the particular case of agent persistency management.

Aetmt locating is covered in the third section. We will present different mechanisms that can be used for offering location services and show how they constraint flexibility. To overcome this problem we present a design-pattern (5][16] that help designers to make flexible use of such mechanisms.

Our ideas and thoughts are the outcome of our experience on the implementation of JavaSeal [13][14] and HyperNews [17)[18][19] systems. HyperNews is an agent,based system that runs on top of the Java-based agent kernel JavaSeal. It is a system for the electronic distribution of newspaper articles. The actors in this system are;

• Jnformation Providers: These are either amcle producers or distributors. Article production consists of encrypting the content of articles and encapsulating this content within Article Agents.

• Information Consumers: The HyperNews clients download article agents from the infom1ation provider's site. These agents regulate content usage- rules in collaboration with financial institutions by triggering a payment process (for a first usage) or receipt checking process (for a re-use). lnfonnation consumers can download issuer specific proxies. These are small environments that offer issuer's services.

• Financial Institutions: These are the trusted parties between consumers and providers.

They deliver keys for article decryption against payment from the consumer. Upon a successful payment, the provider's account is credited and a nominative receipt is given to the consumer that purchased the article.

JavaSeal is a secure kernel for constructing agent-based applications. It implements security properties such as verifying the absence of forbidden or untrusted classes and isolating agents from each other. The later property ensures that provider proxies are protected from each other in the client platform.

JavaSeal applications are organized in hierarchical structures where each agent is run by its parent agent. HyperNews Article agents are run by their issuer's proxies. Proxies in tum are run by the application root-agent

K Taha and T. Pi/ioura 151

The remainder of the paper is structured as follows. In section 2, we discuss agent naming and present a design pattern for a particular application of agent naming, specifically, managing agent persistency. In section 3, we present agent locating and we propose a design pattern for integrating locating mechanisms in ABAs. The paper concludes with a summary of the paper's key points.

2 Agent Naming

A fundamental facility in any computing system is the naming service. lt is a service that binds symbolic representations (names) to an object or set of objects. Names are usually people-friendly strings (such as file names) and objects may be tiles, addresses, identifiers or programmatic objects. In the mobile agents' context, objects can be agents, platforms on which agents are running or other names.

DNS is a well-known and widely used naming service that binds human-readable strings to IP addresses. It is based on a standard naming scheme and uses a large distributed database. The main feature of this system is that it guarantees uniqueness of domain name identifiers. However this requires a highly centralized management. In the mobile agent context, a DNS-like service is not feasible at a large scale. Mobile agent locations change much more frequently than IP addresses' domain names. Using such system for agents will lead to an unrealistic amount of updates.

A typical way to name mobile agents or mobile objects in general is to assign them global unique identifiers (GUIDs). The underlying distributed system must ensure, using for example a central authority, that the identifier is globally unique and does not change during th.e agent's life cycle. While this is essential for agent control and management, it is not convenient at application level.

In this section, we first describe some possible semantics of agent names, we then define some abstractions in naming services and present° a list of basic requirements for integrating naming services in ABAs. Finally we illustrate the impact of these requirements on agent design.

2.1 Agent naming semantics

Names can be considered as views over agents. Using agent names allows applications to invoke or communicate with local or remote agents. We can distingcish two different kinds of agent naming: location-based naming and property-based naming.

2.1.1 Location-based naming

Internet names such as URLs and domain names are related to resource locations. A resource name tells us where the resource is. Using such names in ABAs facilitates inter-agent communication, since it allows a straightforward locating. It also facilitates agent management by supporting- global unique names. Indeed, if a platform combines its IP address with a locally unique name it can provide globally unique names for its agents.

However, this type of naming has two major shortcomings:

• Location does not tell us about what are the other properties of the agenL Thus agents are able to communicate only if they know their mutual locations. This is very constraining for application design.

• Location is dynamic in the context of mobile agents. Therefore other type of naming schemes must be used.

2.1.2 Property-based naming

As we me.otioned earlier agent names are somehow v!ews over agents. Choosing the right naming scheme should be close to how applications perceive an agent. In the following paragraphs we present some of the ways that an application may view an agent

Agents as information carriers

Let's take an example from HyperNews. An information provider publishes newspaper articles that are encrypted and encapsulated by Article agents. Article agents are subsequently serialized and stored on disk. The issuer's IP address, the date of publication and the rubric of the article are used for naming these article ^agent~. In this case; article agents are seen as i11formation earners. Their name reflects a relevant part of the information they enclose.

Agents as a set of services

In HyperNews every actor runs a set of service agents. These are stationary agents that offer a list of services, such as GUI, E-commerce, Storage and cryptography. Any agent running on the platform can invoke these agents by simply using the name of the service they offer. This naming is useful to build and invoke service agents in a distributed system.

Agents as a set of history-based properties

ABAs may require more than the services or the data encapsulated by an agent. In distributed problem solving applications for example, the tasks that have been peiformed by an agent are much more representative than the tasks it can perform. Names in this context should reflect the actions petfonned, and whether they are successful or not.

An ex.ample from HyperNews is the request agent that pulls article agents from the provider's servers. In an off-line operation the re<jUest agent may be serialized and stored in a database. When reconnected the client puns back the request agent. To retrieve back this agent a uniqu.e identifier may be used but this does not tell us if the request agent has succeeded or not. If this was possible, a client application may request only agents that terminated successfully the taskS they were assigned.

Agents as a group member

An agent may be named by the name of the group it belongs to. The group name may reflect the agent type, information retrieval agent for instance, or a common task they are willing to realize. Such naming can facilitate implementing communication by meeting, which is convenient in such contexts. At arrival in a meeting platform an agent can ask for an agent petforming the same collaborative task.

K Taha and T. Pi/ioura 153 Choosing a name depends on the nature of the agent and the nature of its tasks. We presented some types of names that can be frequently used in ABAs. In the next part we discuss how agent names should be structured.

2.2 Naming schemes

A naming scheme defines the structure of a naming convention. It specifies the permitted characters and the set of delimiters that divide

a

The Internet domain names scheme for example, defines a name as two or more strings separated by dots. The suffix of each name is a top-level domain name that belongs to a limited namespace and represents a country such as "eh" or a general type of Internet domains such as "corn" or "edu".

In HyperNews we use different naming schemes for different purposes. For article agents' downloading and management we use the article naming scheme. A request for downloading is of the form:

get Article having name "129.94.138.9.19990608.142357767.100" according to the

"article naming scheme".

According to this scheme the sub-string:

• 129.94.138.9 represents the IP address of the article issuer,

• 19990608 the publication date,

• 142357767 the hashcode of the article's rubric;

• 100 a sequence number to differentiate articles of the same rubric, published the same day by the same provider.

For inter-agent communication within a platform we use the hierarchy naming scheme.

Every active agent in the platform is assigned a hierarchical name (Unix-like path strings) that reflect its position in the hierarchy. Due to the hierarchical structure of JavaSeal applications, this naming scheme is very convenient for message routing inside and across platforms.

A message routing request for the previous article agent example is of the form:

Send message "m" to agent having name "HNServer/129.94.138.9.Proxy/Article4"

according to the "hierarchy naming scheme"

In this example, the location of an agent within the hierarchical structure is sufficiently representative and much more convenient than the article naming scheme. It is also more general since the article-naming scheme is limited to article agents.

For service invocation we use a service agent naming scheme that consists simply of the name of the service to invoke. Thus when an agent invokes a writeFile service from the storage agent, the request is of the form:

Invoke writeFile(fileName, fileContent) from "storage service" agent according to the

"service agent naming scheme".

This naming scheme is very convenient for basic service invocation like storage, GUI and cryptography or for some application specific services such as Wallet management and off-line payments.

We can extract from these different HyperNews examples some general requirements for naming schemes. Some of these requirements are covered in FIPA's [23] normative naming specifications.

• Flexibility: Applications should not be bound to one naming scheme. Our examples show that depending on the purpose some naming schemes are more convenient than others.

Agents must ·be able to use different nwning schem.es and hold different names at the same time.

• Dynamicity: Sometimes names need to be dynamic. A hierarchy name in our example changes whenever the agent cbw1gt:l> i~ pusitiou in the hierarchy inside the platform. In general, this is useful when the name reflects a changing state of the agent.

• Reusability: Naming schemes can be reu.sed by different applications. Furthermore, a naming scheme can be a composition of two naming schemes. URL ·naming scheme, for example, combines the domain name scheme and file names naming scheme. This can be extended to agent naming.

While designing a naming scheme for an ABA, checking its compliance with these requirements is an important point. Another important point is to see how this scheme can be used to dynamically bind a name to an agent. In the next part, we discuss the name resolution process and see how it is related to the nwning schemes.

2.3 Agent name resolution

The name resolution process is a chain of responsibility where several participants can be involved. Every involved participant uses a part of the name to locate the requested agent or to find to whom the resolution will be delegated. A participant can be an agent, a platfonn or any object

The UML collaboration diagram of Figure 1 represents an abstract name resolution process: (We extended the notation by using the tenns nameManager and mobile. These terms are explained later)

2.3.1 Participants

A participant is any entity that handles at some time the name resolution process. It may be an agent, a platform or a simple object.

A participant receives a handle request with a part of the agent name as a parameter. If it can handle the request, it does so (case 2.1 in Figure I); otherwise it forwards the request to its successor (case 2.2 in Figure I). The way a participant chooses its successor can depend on the name to be resolved, as we will see in the next example from HyperNews.

K. Taha and T. Pilioura

~

I: lookup(name) :Partlclpantl

l

I

_:

I

:Partlclpapt5 {nameManager}

2: lookup(sub-namel)

.+

!

It

t

:PtnlclpanQ {mobile}

{new}

·PartlrJp•nt1 2.2: [agent not located]: I J: lookup(sub-aamc2)

lookup(sub-namc2)

@Client's lotadon I @Remote Locadon

Figure 1 The collaboration scheme of the name resolution process

155

Two participants are of interest in this architecture: Name Managers and Mobile Participants. Name Managers are participants that can ultimately handle a name resolution request. They can directly locate agents that are under their responsibility without the need for intermediates. They also act as observers for the agents with dynamic names. Examples of name managers are storage agents that can immediately locate persistent agents in the local disk. The provider proxies in HyperNews are name managers of Artic1e agents, as described in the following example.

Mobile parti.cipants can move from a platform to another to delegate resolution to their successors. This is an interesting alternative to classical name resolution processes that rely on distributed directories such as CORBA and RMI.

For example, when a Hypernews user asks for an article with the name

"129.94.138.9.19990608.142357767.100", the system triggers the following resolution process:

• The first participant is the HyperNews server. It uses the IP address "129.94.138.9" to forward the request to the corresponding issuer's proxy. The pr,oxy then uses the whole name to determine whether the article agent is active or stored locally on disk. If the agent is active, the resolution terminates; otherwis~ it delegates the resolution to the storage agent.

• The storage agent uses the whole name to locate the agent on disk.

• If the agent is not located on disk, the resolution is handled by a mobile request agent.

The destination of this agent is determined by the IP address in the agent name.

• At arrival, the remote HyperNews server handles the resolution.

The article naming scheme can be used for another name resolution process. When a cl.ient requests a list of articles that meet some requirements (i.e. an article from a given rubric, articles published after a given date, etc.) the second and the third sub-strings are used to request remote article servers regardless of the value of the first sub-string.

2.3.2 Name resolution and naming schemes

The resolution of a given name is tightly coupled to its naming scheme. The later gives a structured input to the process participants. The sub-name that is passed from a participant to its successor is defined by the naming scheme. In the above example, the HyperNews server uses the naming scheme to determine which part of the name relates to the IP address.

We presented in this part some abstract entities and mechanisms involved in naming services, including naming schemes, name resolution processes and their participants. We also discussed how these entities are interrelated. Then using these abstractions we outlined some major requirements for integrating naming services in ABAs.

As we mentioned earlier agent naming services support mobile agent management by providing means for remote inter-agent communication. We will describe in the following part how we can apply these services to agent persistency management.

2.4 Agent naming for persistency management

Agent based applications, as any kind of applications must cope with persistent data management. Database management systems provide interfaces that make management transparent at the aJ?plication level. We briefly present in this part some benefits of using these systems in the context of mobile agents. We then discuss how agents can be modeled for persistency using naming concepts. We illustrate the discussion by using a design pattern that makes use of some of the abstractions defined earlier.

2.4.1 Benefits

We call AgentBase any system that offers interfaces for managing agent persistency. As for any kind of data, persistency allows data reuse and data sharing. It also provides efficient mechanisms for storing and retrieving data, for concurrent access control, controlling data integrity and redundancy, etc. In agent-based applications other benefits include:

• Coping with connectivity problems: A platform can send a roaming agent to perform some tasks over the network and discow:iect afterwards. The mobile agent cannot return after terminating. An AgentBase can be used to store the agent until its sender requests it.

The same problem can rise in mobile networks if the launching platform is running on hardware with an unknown or a changing IP address. The AgentBase can act in this case as a dedicated message queuing system.

• Coping with resource limits: Agent-platforms may implement resource-control policies by deactivating and reactivating agents using an AgentBase. Another benefit in this context is the possibility of getting relevant information about agents from their names without activating them, thus saving up the resources consumed by active agen.ts.

K. Taha and T. Pilioura 157

• Recovery and versioning: An application may need to store successive versions of an agent or keep backup copies of it in case an agent crashes locally or on a remote platform.

AgentBases can be used for this purpose.

2.4.2 AgentName pattern

Storing data for an efficient use relies on high level data models that are close to the way many users and applications perceive data. A persistent agent at the application level is a combination of a "passive agent" which is dependent on the agent kernel's implementation and an external representation, its name(s).

This pattern is inspired from the template method pattern [16], which describes an abstract algorithm in an operation. The skeleton of the algorithm is defined by the superclass using abstracted steps. Subclasses redefine these steps without changing the algorithm's structure. AgentName pattern defines how agents can be structured and an abstract algorithm for deactivating agents.

Note that the pattern we describe here is an application-level pattern. The serialized format of an agent (data and code) depends on the underlying platform and is not considered here.

The pattern descriptions of this paper follow a common template that covers intent, motivation, applicability, participants, collaboration and consequences. All diagrams follow the UML notation.

Intent

Define an abstract structure and a general algorithm for agent storage process using some agent naming abstractions.

Motivation

Consider a roaming agent that gathers information from different platforms in collaboration with other mobile agents (Figure 2). The agent bolds three names: a unique identifier, a group name that facilitates collaborative work with oth.er agents and a logbook that contains information about the success or the failure of different actions.

After terminating its tasks the agent is stored in an AgentBase. Once serialized, the agent can be pulled or garbage collected using one of its names. The entities that call the pull operation may be: a group member that uses the group name or the sender platform using the global unique· identifier. A .remote or local garbage collector may use the logbook name to remove the agent if it didn't succeed.

The Name Manager, which is the storage agent in this case, should be able to use any name to locate the agent. Thus during the storage process, an agent recorder should use its names to build an external representation of the persistent agent. One may store the agent in an object-oriented database or a relational one or simply in the file ~Stem . The-details of the effective storage are implemented by the subclasses of AgentRecorder (or the classes that implement the AgentRecorder interface).

The idea here is that any agent that could be serialized and stored on disk should be composed of a list of names that are instances of the subclasses of the AgentName class.

Each subclass of AgentName implements a naming scheme. When the agent is stored on disk any relevant information about the agent should be accessible by one of the AgentNames.

HNServer

storcAgent(passiveAgent, ais);O- lf(dbStorage) {

//Update AGENT table using different names

) fileName = LogBook.intValueO + stores ^{.. + groupName +} GUID .. ID

ais .rubric,

writeFile(paSsiveAgeot, fileName); ._.

RoamingAgent logbook Lo2book I

Logbook logbook;

~

GroupName gpName; GUID

GUIP guid;

~

-.::::::

Figure 2 Participants in the storage process of a roaming agent Applicability

This pattern is useful when:

• Activating an agent is costly if not impossible. The different agents are therefore used for getting relevant information about an agent without activating it.

• To control remotely persistent agents using different naming schemes.

Structure

AgentRecorder Agent AgentName

saveAgent(Agent agent),

s:;

storeAgent(passiveAgent, agentName());j _{I !} fN.,,11:{] nam<S; ioctNamcs(); rv 1..n

' 6 6

6

IAgentNamc r = agentgetName();

il'is:.ivcAgcnlpa • IAgeni.dcactivotc(agcnt);

ktorc(pa.r); ,,,,

ConcreteRccorder ConcreteAgent CooctticN1me:1 ConcreteName

storeAgent(passiveAgent, nxonl);C !.A. getName();

IV

rpccific

::J

Figure 3 Structure of the agentName pattern

K. Taha and T. Pilioura 159

Participants

• Agent: The agent that will be stored. It maintains a list of instances of a subclass of AgentName.

• AgentName: Abstract class that represents an abstract Naming Scheme.

• ConcreteName: It implements a concrete naming scheme.

• AgentRecorder: The entity responsible for storing the agent. It defines the saveAgent abstract algorithm and the abstract method storeAgent.

• ConcreteRecorder: It redefines the storeAgent method for application specific storage.

• StorageAgent: It's the Name Manager of all persistent agents.

Collaborations

If the name represents a changing part of the concrete agent's state (list of visited hosts, for example) the StorageAgent should act as an observer on this part of the state.

The StorageAgent is a Name Manager that retrieves agents using one of their names.

AgentRecorder's saveAgent method is the abstract method for the storage process, it keeps the list of names to be used for retrieval before storing the agent. The Concrete Recorder implements the specific storage process in the storeAgent method.

Consequences

• Agents are constantly aware about their persistent structure, according to different naming schemes. Tiris is objectified by a list of AgentName objects.

• It is possible to specify which names may be used for persistency. Thus, it .is possible to use some pseudonyms that guarantee confidentiality. Tiris can be done by defining in the getName method of ConcreteName, when and what part of a name is confidential and what pseudonym to give.

2.5 Summary

We presented in this section a set of concepts and mechanisms in agent naming services and their impact on agent design. We. also discussed the use of naming in the context of agent persistency management. One question raises by itself. Are agent names sufficient to locate and communicate with agents? In our design pattern we suppose that agent location can be extracted from its name. What if the agent is stored in an unknown AgentBase or running in an unknown platfonn? Some mechanisms that cope with such problems are discussed in th.e following section. We will also examine how the integration of such mechanisms influences the design of an agent.

3 Agent Locating

To stress the problem of agent locating, let us consider a simple example of an ABA for information retrieval. First the user formulates a structured request for a server using the GUI.

Then the request is encapsulated by a named agent and sent over the network. A basic functionality of this application would be to allow the user to interrupt such actions. While in a classical Client/Server application this can be easily done by an RPC or a disconnection message, in our example the request agent may be running in an unknown agent platform after a few seconds. How can a name resolution process cope with the agent mobility?

In the previous section, we did not discuss the details on how participants in a name resolution process delegate the resolution to another participant. In our examples, agent location was always predicted using its names. But what if participant cannot locate neither the agent nor the next participant to handle the resolution? Special locating mechanisms must be used.

We conside1 lui.;1:1ling 1:1S 1:1 sub-prut:t:ss uf agt:nl naming llml invulvt:s more than one host.

The only participants that we consider in this process are Hosts and Requestors. The name resolution process that occurs within a platform is not detailed.

In this section, we present some algorithms that can be used for locating agents. Some of the aspects related to these algorithms have also been examined in [6][15). We also discuss the usability of each algorithm and the requirements that the involved entities must fulfil!.

Then we discuss the impact of these algorithms on agent modeling and propose a design pattern that objectifies the agent locating process.

3.1 Broadcasting

In this algorithm we suppose that the requestor participant holds a list of all the possible locations where the requested agent can be hosted.

The requestor broadcasts a message to all potential hosts [Figure 4). The platform where the agent is currently hosted locates it and forwards the message to it. The agent does not have to be aware of the locating process and therefore does not have to be programmed to be located. However, the hosts must maintain a list of the identities of the hosted agents and be able to forward messages to them.

D

0

• Current location of the agent __. Messages for locating agents

--+

K Taha and T. Pi/ioura 161

Requirements:

• Requestor: The requestor must know in advance all potential hosts of the requested agent.

• Hosts: They must be reachable and keep a list of all hosted agents' identifiers.

• Agent: It presents its identity to every host and cannot be hosted by unknown hosts.

Figure 5 presents a segment of code in Java for locating agents using the Broadcast algorithm. For simplicity, we use the following small set of primitives that have equivalents in all agent-based systems.

send(m, recipient): sends a message m to a recipient or a set of recipients. The recipient can be a location or an agent.

move(location): defines the operations to perform before moving to the new location:

arriveQ: defines the operations to perform on arrival at a new location.

Message: encapsulates an RPC-like message. It contains the method signature, the name of the recipient (returned by getRecipient()) and the name of the sender.

Requestor

//send a message m to all potential hosts send(m, hosts);

Agent

arrive() {//notify the local host of its identity}

Host

Message m = receiveFromNetO;

if(nigetRecipient ( ).isHostedO) ... forward(m, m.getRecipient());

Figure 5: Sample code for locating agents using 'Broadcasting"

3.2 Tracking

Hosts are not always known in advance. For example, a front-end agent platform may forward incoming agents to iln auxiliary platform for better resource management reasons. In such a scenario an agent requestor does not know this auxiliary location and therefore cannot broadcast the request to it. A solution could be that the front-end platform keeps some information about the agent's new location. This information can then be used to locate the mobile agent. This suggests another locating algorithm, namely the tracking algorithm.

Every host keeps the agent's next destination. The message is forwarded from host to host until the agent is located (Figure 6).

Requirements:

• Requestor: It has information about the first destination of the requested agent.

• Hosts: They keep information about all the previously hosted agents and their next hosts.

All hosts must be up and running during the locating process.

• Agent: Before moving to a platform, it must report it to the host.

Figure 6 Agent locating by "Tracking"

Sample code in Java for the requestor, the host and the mobile agent is shown in Figure 7. The Host offers an interface to get/set the next location. of an agent given its name (getNextLoc(agentName), setNextLoc(agentName, Location))

Requestor Host

//the requestor sends a message to the first Message m

=

location

//of the recipient recipientName ⁼ m.getRecipient( );

send(m,locationl)

Mobile Agent

void move (Location nextLoc) { Host.setNextLoc( myName, nextLoc);

}

//if the recipient is hosted, forward the message to it

if (isHosted(recipientName)) send(m, recipientName);

//else, forward it to the next location of the agent

//returned by the getNextLoc method using log files

else {

send( m, getNextLoc(recipientName));

}

Figure 7 Sample code for locating agents using "tracking'

In contrast to the first algorithm there is no need to know all potential hosts of an agent.

However, we should assume that all hosts keep logs for all agents that have previously hosted. While this algorithm does not restrict agent mobility to a predefined list of hosts, it has an important drawback: the locating process relies on the fact that all intennediate hosts are up and running. If one of them is unreachable or does not maintain agents' log files, the locating process cannot be completed.

3.3 Dedicated Locating Service

The two previous algorithms face a common problem: they both rely on intermediate hosts' availability. To overcome this restriction one solution could be to use a dedicated locating

K Taha and T. Pi/ioura 163 server. Any agent movement is reported to this server and a database is constantly updated to reflect the current location of agents. This allows any authorized application to locate and forward messages to a given agent without the need to rely on intermediate hosts' connectivity.

The locating server can either act as a simple database server that receives requests from different entities and sends back the location information of an agent, or as a router that forwards messages to requested agents. In the latter case, the router must be coupled with a message queuing system that stores messages in case the requested agent is running on a disconnected host. When the host is re-connected, it reads all the messages from the server and forwards them to the hosted agents. Before moving to a new host an agent should report its new location to the locating server.

Locating Requestor

agtX@Loc2

Agent notifies locating service before moving -= ^{lr.) _,,(}

or at arrival

D

Figure 8 Agent locating using "Dedicated Locating Service"

Requirements:

• Requestor: It knows which dedicated locating service will be used.

• Dedicated Locating Server: It must be constantly reachable.

• Hosts: They know the dedicated locating service used. If a host is disconnected, it reads and forwards messages after its re-connection.

• Agents: agents need to agree in advance upon a dedicated naming server and report any of their movement to this server.

Figure 9 illustrates a sample code for the requestor, the locating service and the mobile agent. The locating service presents an interface for getting the current location of an agent (getCurrentLocQ) and setting a new location of an agent ( setLocation()).

3.4 Integrating locating mechanisms in ABAs.

In the previous algorithms we considered the locating process as fixed for the whole life cycle of an agent However, parameters and conditions considered when the agent was sent may change over time. Applications should be able to dymurucally set the locating algorithm.

The sample codes in Figures 5, 7 and 9 show that agent has hard-coded behavior according to the way it is located. This is not a flexible way to program mobile agents.

Requestor

//send the message to the locating server Is.

send(m, ls);

Mobile Agent

void arrive(Host nextHost) {

//notify the locating server the new location setLocation(myName, myLocatingService);

LocatingService

Message m ⁼ receiveFromNet();

recipientName = nLgetRecipient( );

if (isLocated(recipientName ))

send(m, getCurrentLoc(recipientName)) else{

II returns an exception or queue the message

}

Figure 9 Sample code for locating agents using a "Dedicated Locating Service"

As we described above different algorithms can be odopted for agent locating and message forwarding. Despite the different requirements of these solutions, they all have two common drawbacks:

• Agent is aware of the way it is located and must behave accordingly. If this behavior is hard-coded it restricts the flexibility of the agent.

• Requestors are aware of how the requested agent is located. This is constraining since it forces a strong coupling between the requestor and the requested agents

In the following we propose some solutions to overcome these two drawbacks.

3.4.1 AgentLocator pattern

The pattern descriptions follow a common template that covers intent, motivation, applicability, participants, collaboration and consequences.

Intent

Modeling agents for a flexible use oflocating mechanisms.

Motivation

Suppose that in an E-Commerce ABA we want to design a set of specialized mobile agents including information retrieval, commercial transactions, etc. This requires much effort since every locating algorithm comes with a set of requirements and constraints on agent design.

What we present here is a solution that makes the agent loosely coupled to the way it is located (Figure 10).

Every mobile agent is composed of an AgentLocator object. It is notified whenever the agent's location has changed (at arrival) or is changing (before moving). The AgentLocator acts according to the locating algorithm in use. It offers two abstract methods notifyAtDepartureO and noti.fYAtArrivalO that defines the actions to perform when an agent moves to a new platform and when it arrives at it respectively. For every locating algorithm we subclass the AgentLocator and define these methods. All an agent has to do is to notify its

K. Taha and T. Pilioura 165 AgentLocator whenever it is moving or arriving at a new host. Thus, the AgentLocator encloses all the behavior related to the locating process. To change dynamically the way an agent is located one simply assigns it a new AgentLocator object.

mov<();

arrive();

Agent

SaleAgent

AgentLocator

"I locator

I

notifyAIDepartun:(location);

locator

BroadcastLocator getRecord();

notlfyAtAnivnl(loe);

c:;:

notifyAtD<p0rtuR(}ac.\ ^I T rackingU>cn1ot

ge!Rcc:md();

notifyA!Arriva1( loe);(:;:

r---t nott~epilrt'Urc(loo)j ^{II do nothing}

I

//notify ncxl ]OQlion ^t current host nothing I [!1.;~ J

Figure 10 Example structure of the Agentlocator pattern

The information retrieval agent is assigned a TrackingLocator because its itinerary is unpredictable since it depends on data gathered. The sale agent is assigned a Broadcast Locator because all the buyers' platforms are known. Note that the move and an·ive methods do not depend on the locating algorithm. To add. a new locating algorithm one can simply subclass the AgentLocator class. To change dynamically the locating algorithm we can use the setLocatorO method to set a new locator object.

Applicability

The AgentLocator pattern is applicable in the following situations:

• When we do not want the behavior of an agent to be tightly coupled to the way it is located.

• When we want to change dynamically the locating algorithm of an agent.

• When we want to add new locating mechanisms with minimal changes.

Participants

• Agent: It holds an instance of AgentLocator and defines a method for setting locator.

• AgentLocator: It defines two methods called by the Agent object at departure and arrival with the location as parameter.

• ConcreteLocator: It defines the actions, according to an algorithm, to perform when an agent moves or arrives at a platform.

• ConcreteAgent: It notifies the locator whenever it arrives at a new location or is moving to a new one.

Structure

Collaborations

Agenl movcTo();

amve();

ConcreteAgent Locator locator, amve();

moveTo(locotion);

sc1Loco1or(Loaolor); :

AgentLocator __ _ ____ tifyAIArri"1ll(IOC11tion);

) ~fyAtDepostutt(localioo);

ConcreteLocator notifyAIAnival(loe);,

!IO!ifyAtDqiiutur<(lno,il' 'r

~1or.notifyAtDqiiutur<(IOCBli:J

Figure 11 Generic structure of the AgentLocator pattern

ConcreteLocator: collaborates with external entities such as locating services, hosts, agent proxies, etc depending on the location algorithm. When notified the AgentLocator may require more information from the Agent object to perform its tasks.

Consequences

• The locating algorithm used for locating an agent can be changed dynamically: as mentioned earlier in the E-Commerce application example, by setting a new locator.

• Locators can force the constraints of an algorithm: for example a broadcast locator holds the list of all the predicted hosts of the agent. When an agent notifies that it is moving to a new host the locator checks if it is predicted.

• New locating algorithms can be implemented without re-implementing agents.

3.4.2 Agent proxies

An agent that wants to communicate with a remote one does not have to know the way the requested agent is located. On the other hand, the requested agent cannot inform all of its requestors about its locating algorithm. One solution is to have an interface between an agent and its requestors. We call this interface AgentProxy (Figure 12).

The proxy knows how to locate the agent and forwards messages to it. Thus, the requestor agent sends a message to a proxy agent representing the receiver agent, after which

K Taha and T. Pilioura 167 the proxy forwards the message to its agent. The proxy agent may be hosted on the same location where the agent has been created or on a common platform.

Proiiy Kno"WS how the agent is located and if the message is to be forwarded

Requestor Doeso l need to know

'Oil •be w.iy requested

ogent i< located Requested agent

,4 Docsn\ need to

rcquestor the way it is located

Figure 12 Message forwarding using agent proxy The proxy can have additional uses.

• Security: the proxy may perform some security tasks such as requestor's authentication and message content checking. In a restrictive policy, the agent may accept only messages coming from its proxy, this can be insured by cryptographic authentication.

• Message filtering and queuing : The proxy may remove the message or forward it later if the agent is unreachable or busy.

4 Conclusion

The widespread expansion of Internet has imposed new needs that require new paradigms and new technologies. In this scenario mobile agents have been proposed as a model to cope with the requirements of wide distributed applications. But with new paradigms come new requirements and new challenges. While agent mobility and autonomy offer potential benefits for distributed applications, we believe that managing agents is critical in designing large- scale ABAs.

In other words ABAs need to keep a remote control over mobile agents. This requires some infrastructure to be deployed. Agent naming, AgentBases, agent locating and message forwarding services are part of this infrastructure. We presented some of the benefits of these services and described some of their mechanisms. Our major focus was the impact of using this infrastructure on agent design.

Agent naming imposes some requirements such as flexibility, dynamicity, and reusability of naming schemes. Naming schemes should also be convenient to the way agent names are resolved. These requirements add complexity to agent design. The AgentName pattern illustrates an abstract structure of agents and a general algorithm for agent persistency management. It also presents how in this particular application of agent naming agents should be designed to comply with naming services' requirements. This design pattern can be easily applied to other applications of agent naming.

Agent names are not always sufficient to locate and retrieve agents. To cope with this problem some locating mechanisms must be integrated in ABAs. We presented some of these mechanisms and showed how they restrict agent flexibility and introduce complexity to agent

design. The AgentLocator pattern avoids a strong binding of an agent to the way it is located, and allows us to dynamically modify locating solutions without changing the agent's code.

We think that this pattern can be extended to a more general use. The reason is that mobile agents deployed on wide and heterogeneous networks face dynamic environments and should be able to dynamically adopt new behaviors.

References

[l] M. Wooldridge, N. Jennings, "Intelligent agents: Theory and Practice'', Knowledge Engineering Review, 10(2), 1995.

[2] T. Walsh, N. Paciorek, D. Wong, "Security and Reliability ill Concordia", In the Proceedings of the 3Jst Annual Hawaii lntemallonal Conference 011 System Sciences (HICSS31), Kana, Ha\Vaii on January 6-9,

1998.

[3] Voyager White Papers, Available at http://www.objectspace.com

[4] D. Chess and C. Harrison, A. Kershcnbaum, "Mobile Agents: Are They a Good Idea?", In Lecture Notes in Computer Science, Vol. 1222, p. 2$47, 1997.

[5] Y. Aridor, D. B. Lange, "Agent Design Patterns: Elements of Agent Application Design", In Proceedings of the 2nd lntema(iona/ Conference on Autonomous Agents (Agents '98). pp. 108· l 15, ACM Press, May 9- 13, 1998.

[6] Y. Aridor, M. Oshima, ''Infrastructure for mobile agents: requirements and design", In Procudlngs oftlie 2nd Jnt. Worksl1op on Mobile Agents, Lecture Notes in C<m1puter Science, Vol. 1477, pp. 38-49, Springer- Verlag, Berlin.

[7] J. Baumann, K.Rothermcl, "The Shadow Approach: An Orphan Detection Protocol for Mobile Agents", In Proceedings of the 2nd Jnr. Workshop on Mobile Agents, Lecture Notes in Computer Science, Vol.

1477, pp. 2-13, Springer-Verlag, Berlin.

[8] 0. J. lluber, L . Toutain, "Mobile Agents in Active Networks", lo Proceedings of the Jrd ECOOP Workshop on Mobile Object Sys/ems, June 1997

[9] J. J. Hartman, P. A. Bigot, P. Bridges, B. Montz, R. Piltz, 0. Spatscheck, T. A. Proebsting, L. L. Peterson, A. B11vier, "Jou.st: A Platfonn for Liquid Software", IEEE Computer, April 1999, Vol. 32, No 4, pp. 50- [10] 56. B. Brewington, R. Gray, K. Moizumi, D. l(otz, G. Cybenko, D. Rus, "Mobile agents in dislribu!Cd information retrieval", In Matthias Klusch, editor, Intelligent Infonnation Agents, chapter 12. Springer- Verlag, 1999, To appear as ISB:t-13-540-65112-8.

[11] R. Guttman, A. Moukas, P. Maes, "Agent-mediated Electronic Commerce: A Survey'', Knowledge Engineering Review, June 1998.

(12] H. S. NWlUla, J. R.osenschein, T. Sandholm, C. S.icmi, P. Maes, R. Guttmann, "Agent-Mediated Electronic Commerc"' Issues, Challenges and Some Viewpoints", In Proceedings of the 2nd lntemalional Conference on Autonomous Agents (Agents '98), pp. 189-196, ACM Press, May 9-13, 1998.

[13] J. Vitek, C. Bryce, W. Binder, "DesigningJavaSeal or How to Make Java Safu for Agents'', ill Electronic Commerce Objects, D. Tsichritzis (Ed.). Centre Universitairc d'Infonnatiquc, University of Geneva, July 1998, pp. JOS-126.

(14] C. Bryce, J. Vitek, "The JavaSeal Mobile Agent Kernel", also ill this report, pp.

[15] Roger S. Chin, Samuel T. Chanson, "Distnbuted Object-Based Prognunming Systems", ACM Computing Surveys, 23(1), pp. 91-124, March 1991.

[16] Erich. Gamma, Richard Helm, Ralph Johnson, John Vlissides "Design Patterns: Abstraction and reuse of objecr-oriented design"

[17] J. -H. Morin, D. Konstantas, "Towards Hypennedia Electronic Publishing", In Proceedings of 2nd LASTEDIJSMM lnternationol Conference on Distrib11ted Multimedia Systems and Applications, Stanford, Coli(ornia, August 7-9 l99S.

[18) J. -H. Morin, "HyperNews: a Hypennedia Electronic-Newspap,er Environment Based on Agents'', In Proceedings of HJCSS-31, Hawaii Jn.tematio11al Conference on System Sciences, IEEE l998, January 6-9,

L998, Kona, Hawaii, Volume Il, pp 5_8-67.

(19) J.-H. Morin, D. Kons~ntas, "HyperNews: A MEDIA Application for the Commercialization of an El.ectronic Newspapes''. In Proceedings of SAC'98, 1998 ACM Symposium oo Applied Computing, Atlanta, Georgia, February 27-March I, 1998, pp. 696-705.

[20] UML, http;//www.rntioool.com/urnl/jndex.jtmpl

K Taha and T. Pi/ioura 169 [21) G. Boacb, J. Rumbaugh, I. Jacobsoa, "The Unified Modelling Language User Guide: UML", Addison-

Wes!ey, 1999, The Addison-Wesley object.technology series, ISBN 0-201-57168-4 , 1999.

[22) I. Rumbaugh, I. Jacobsoo, G. Boocb, "The Unified Modelling Language Reference Manual: UML", Addison-Wesley, cop. 1999, The Addison-Wesley object technology series, ISBN 0-201-30998-X, 1999.

[23) FIPA's Fifth Call for Proposals. http://drogo.cscU.stet.it/fipaldurbam/cfp5.html