Development of Mobile Agent Applications with Ajanta 1 - CiteSeerX

Development of Mobile Agent Applications with Ajanta 1 Anand R. Tripathi, Neeran M. Karnik, Ram D. Singh, Tanvir Ahmed, John Eberhard, and Arvind Prakash EECS Building 4-192, 200 Union Street SE. Department of Computer Science, University of Minnesota Minneapolis MN 55455 Contact Author: Anand Tripathi ([email protected], Tel: 612-625-9515, Fax: 612-625-0572) Abstract

Ajanta is a Java-based system for mobile-agent programming over the Internet. We present here an overview of the Ajanta system and its programming model. We outline the salient features and implementation of three agent-based distributed applications developed using Ajanta. These were designed to test and demonstrate the capabilities of Ajanta's programming model, APIs, and security architecture. The primary underlying motivation was to experiment with the agent paradigm itself. The applications described here include a distributed calendar manager, a distributed le access system, and a web search system.

1 Introduction The concept of mobile agent based distributed computing has received widespread attention in the recent years for its potential to support increased asynchrony and disconnected operations in client-server interactions [2] [4]. Agents can be used for information searching, ltering and retrieval, and for electronic commerce on the Web, thus acting as personal assistants for their owners. Agents can also be used in low-level network maintenance, testing, fault diagnosis, and for dynamically upgrading the capabilities of existing services. However, security and robustness concerns are the major obstacles to the widespread deployment of this paradigm. Telescript [8], an object-oriented type-safe language, was among the earliest mobile agent systems. It was followed by systems like Tacoma [3] and Agent Tcl [1], which supported mobile agents written as Tcl scripts. The emergence of Java has led to the development of several Java-based mobile-agent systems [11], such as Aglets, Odyssey, Voyager, and Concordia. Sumatra [5] and Mole [7] were among the rst generation of Java based mobile agent systems. Ajanta2 is a Java-based system that we have developed for programming mobile agent applications in an open system such as the Internet. It has been designed with the goal of supporting secure and robust agentbased applications in the Internet environment. The Ajanta system addresses several important problems and oers the following key features:  

1 2

A security architecture that provides mechanisms for granting restricted access of host resources to visiting agents based on their credentials. Primitives to detect tampering of an agent's data by a malicious host on its travel path. It also provides a mechanism using which an agent can carry with it a tamper-proof append-only container for collecting data items at various hosts it visits.

This work was partially supported by National Science Foundation grants ANIR 9813703 and EIA 9818338. See http://www.cs.umn.edu/Ajanta

1

A novel approach of constructing an agent's itinerary using composable migration patterns. It also supports creation of child agents and their synchronization using the fork-join paradigm.  Mechanisms for securely controlling remote agents for recall or termination, and a model for handling exceptions encountered by a remote agent.  A secure name service based on the URN framework that allows location-independent naming and access of all global resources, including the mobile agent objects. The mobile agent paradigm can be used at many dierent levels in a distributed computing environment. It can be used in implementing system level functions, middleware support, or user-level applications. This paper describes the use of the mobile agent paradigm in building two distributed applications and one middleware system. There were several motivations for developing these distributed systems and applications. The rst one was to test and evaluate the capabilities of the Ajanta system in terms of its support for agentbased application development, agent server security, and remote control of mobile agents by their creators. The second motivation was to demonstrate the utility of the agent paradigm itself by creating applications that can potentially be used by the community. The rst application is a distributed calendar management system for scheduling meetings for a distributed group of users. The second system, an agent-based le access system, is a middleware that allows a group of users over the Internet to share les for any collaborative work. Agents can be used to fetch les from some other users' le-access servers, or deposit les there. This system was implemented to evaluate the Ajanta mechanisms for protecting server resources and granting restricted access to agents based on their credentials. The third system is a Web search system, built over the le access system. It uses agents to perform full-text keyword searches on the web-pages of users. The next section presents an overview of the Ajanta system architecture. Most of the implementation details are omitted here; these details can be found in our other publications[9] [10]. Section 3 presents Ajanta's programming model and APIs. In Sections 4, 5, and 6 we describe three agent-based applications. Finally, in Section 7 we present the conclusions and the future directions of our work. 

2 An Overview of the Ajanta System Ajanta provides facilities to build customizable servers to host mobile agents, and a set of primitives for the creation and management of agents. Programming abstractions are provided to specify an agent's tasks and its travel plans. Robustness of the system is also an important concern. An application can monitor its agents' status, and control them remotely when needed. Security is another important requirement of an agent infrastructure. Malicious agents can damage host resources, leak sensitive data, or mount \denial of service" attacks. Security mechanisms are thus provided to safeguard host resources. In Ajanta, agents are mobile objects. Agents encapsulate code and execution context along with data. In implementing agents and servers, the Ajanta architecture makes use of several important features of the Java language | such as object serialization, security architecture, and re ection. An application extends the system-de ned Agent class to de ne a new application-speci c agent. The Agent class implements the generic functionality of a mobile agent. It de nes the protocol for handling the arrival and departure events of an agent at a server. Each agent is bound to its environment through an object reference named host. Using this, an agent can request various services from its local host. The most commonly used requests are migration using the go function or access to a host resources using the getResource function. The AgentServer class de nes and implements the generic functionality of an agent server. It can be easily extended to customize it for speci c services by creating appropriate resources (objects) and making them available to the visiting agents through its resourceRegistry. A visiting agent can request access to a resource through this registry. The resource then constructs a suitably restricted proxy[10], based on its security policy, and gives to the agent a reference to this proxy. The agent cannot access the resources directly, and the proxy object ensures that sensitive operations are protected. Ajanta ensures that the proxy class is loaded from a trusted codebase. 2

Ajanta uses the Uniform Resource Name (URN)[6] scheme for naming global entities such as agent servers, agents, users etc. A URN is a persistent, location-independent name for a resource, which can be used for accessing the resource, or its attributes. The URN of a mobile object, such as an agent, does not change on migration. The name service framework supports three security requirements: (1) access control on the name server's registry entries, (2) client-server authentication, and (3) protection of namespaces of dierent principals (users, agents, agent servers). An example of a URN in Ajanta's namespace is: urn:ans:cs.umn.edu/UserName/ResourceName. Here \ans" is the Ajanta Namespace Identi er and \cs.umn.edu/UserName/ResourceName" is the namespace speci c string. We use the existing resolution framework of the Domain Name System (DNS) for URN resolution { the translation of URN to a URL, or another URN, or other attributes. In the above URN example, \cs.umn.edu" is the DNS domain where the object was rst created. We refer to this as the creation domain, which is used as a hint to locate an object. Within this domain, \UserName" is a naming authority or a subdomain, and \ResourceName" is a unique string in this subdomain. This hierarchical structure provides ease of maintenance and delegation of namespaces. A new name can be created by a naming authority only in its own namespace.

3 Ajanta Programming Model and APIs An agent is usually created by an application program or another agent { we call this the creator of the agent. An agent executes on behalf of a user, which is its owner. An application creates for its agents a guardian object, which is the exception handler for the agent. If an agent encounters any exceptions during its execution, it is transported to its guardian, which takes the appropriate recovery actions. An agent's creator can itself act as its guardian. Every agent carries a certi cate, called credential, signed either by its owner or creator. Any tampering of this certi cate can be detected. It contains the names of the agent, its owner, creator, and guardian. It also includes the URL for agent's code base server, which is a server that provides the code for the classes required by the mobile agent. All code migration in Ajanta takes place \on demand" during the agent's execution. An agent server associates a new system-de ned class loader with each agent that it hosts. This class loader rst looks for the classes on the server's class path; if not found there, it then contacts the agent's code base server.

3.1 Agent Creation and Dispatch

An agent can be created by instantiating a subclass of the base Agent class. It is given a unique name (its URN) and a Credentials object is embedded in it. Every agent also contains an AgentStatus object, which describes the status of its execution. A newly created agent is activated by dispatching it to some agent server for execution, using the start primitive of the base agent class. The agent's creator optionally speci es a method to invoke on the agent. If this is omitted, the server executes the (parameterless) run method by default. Figure 1 shows a simple agent which is derived from the base Agent class. Once created, this agent is dispatched to an agent server using the start method. When relocated at that server, the agent will execute the run method. This method prints a greeting on the console. It obtains the agent's name from the credentials object, and it obtains the name of its current host server using the agent's environment reference host and its method getHostURN. This simple agent will terminate at that server unless one de nes some other migration action in the agent's code.

3.2 Arrival and Departure Actions

The Ajanta computation model supports execution of entry and exit actions whenever an agent arrives at a server or leaves. The base agent class transparently executes the system-de ned entry and exit actions. The application speci c entry action is de ned by the arrive method of the agent. The base Agent class de nes an abstract arrive method, which must be de ned in the application speci c agent class inheriting 3

public class HelloAgent extends Agent { public HelloAgent(Credentials credential) { super(credential); } public void run() { System.out.println("Agent " + credential.name + "says Hello to " + host.getHostURN()); } public void arrive() { } public void depart() { } }

Figure 1: Example of a Simple Agent | Hello Agent from the Agent class, to execute an entry protocol at every host it visits. The agent thread rst executes the arrive method, and it then invokes the method speci ed in the agent's migration request. In the arrive method an agent generally executes some resource acquisition actions. When the agent nishes its task at a server, its application speci c exit action, de ned by the depart method, is executed. The base agent class de nes an abstract method depart. In a derived class, the programmer can appropriately implement this method to control the course of the agent by specifying migration to another host. 

3.3 Agent Migration

An agent can request migration using the go primitive. It speci es the URN of the desired destination agent server, along with the method to be executed there. If an error occurs during the transfer, go method throws an exception, allowing the agent to handle the error. In some situations, the agent may prefer to co-locate itself with another agent or resource that it needs to access, or an object it needs to report to. It can use the colocate method of the base Agent class, specifying the URN of the target to co-locate with, and the method to invoke on it. The concept of itineraries is built above the go primitive. The generic agent and server do not embody this concept. We have provided an ItinAgent class which extends the Agent class to abstract an agent's mobility into an Itinerary object. The ItinAgent class also implements the arrive and depart methods. The arrive method's implementation is empty. The depart method executes the next method of the agent's Itinerary object to move the agent to the next host according to its itinerary. An itinerary is built as a sequence of migration patterns. An itinerary provides the next method, using which an agent can migrate to the next destination in the current pattern being traversed in the itinerary. Fig. 2 shows the hierarchy of pattern classes de ned by Ajanta. The root of this hierarchy is an abstract class Pattern. Every pattern is associated with an action (speci ed by the programmer) that the agent performs at the hosts it visits. This can be overridden to specialize the action performed at a speci c host. The pattern traversal is determined by the abstract method next. It captures the notion of the next hop in the migration path of the agent. Each pattern has its own semantics to determine the next hop. The basic unit of migration is an ItinEntry, which speci es a destination server to migrate to, and the action to be performed at that host. Its implementation of the next method actually migrates to the speci ed server using go. The abstract class PatternCollection represents an aggregation of patterns. The next method can be given dierent semantics, to implement various patterns. More detailed description of patterns and their composition can be found in another paper [9]. These basic patterns include, the Sequence pattern for visiting destination servers in a given order, Set for an unordered traversal of a set of servers, and Selection for visiting any one in a set of servers. The Split pattern allows an agent to create a set of child agents. SplitJoin allows the parent to wait for the child agents to return and synchronize by reporting their results. 4

Pattern

ItinEntry

Sequence

PatternCollection

Selection

Split

Key

Set

SplitJoin

Class Abstract Class

SplitJoinAll

SplitJoinAny

Figure 2: Hierarchy of Migration Patterns A SplitJoinAll pattern causes the parent to wait for all of its child agents to report back. In contrast, in the execution of SplitJoinAny pattern the parent waits only until any one of its child agents reports back.

3.4 Agent Control

Ajanta provides various primitives to control an agent. For security reasons, these primitives can only be invoked by the agent's owner or guardian. The recall primitive allows the caller to recall an agent back to its home site/guardian, or another location. The runtime system sends a recall request to the current host. That host authenticates the requester, and if permitted, transports the agent to the designated location once the agent has completed its computation. The retract primitive allows the caller to recall an agent back immediately, by interrupting it. The terminate primitive allows the caller to kill the agent immediately.

3.5 Creation of Agent Servers

The base AgentServer class provides the generic functionality to host agents, creates a protected environment for their execution, transfers agents from one server to another using its Agent Transfer Protocol (ATP), and responds to various agent control functions. The example HelloAgent shown in Figure 1 can be hosted by any generic agent server because this agent does not need any additional service or resource other than the generic ones provided by the server. An application speci c agent server is implemented by inheriting from the base AgentServer class. Additional resource types and services can be provided to the agents by simply de ning and creating appropriate objects, and registering them in the base server's resource registry. Using the getResource primitive, an agent can obtain a proxy for a resource. Using the distributed calendar management system as an example, we illustrate here how an applicationspeci c server is created. Figure 3 shows the code for CalendarServer, which is derived from the generic agent server. Its constructor creates a new CalendarDatabase object and initializes its contents from the database le. It then registers this database object as a resource in the server's resource registry. The URN assigned to this resource is the URN of the server extended with the string \CalendarDB".

4 Distributed Calendar Management System The main function of this distributed calendar management system is to be able to schedule appointments based on the availability of the various participants involved. When a user needs to schedule a meeting, she can initialize a mobile agent with the set of possible times for the meeting. The agent then visits the calendar server of every participant and tries to nd a possible time-slot when all the participants are available. If 5

public class CalendarServer extends AgentServer { private CalendarDataBase calendar; private ResourceRegistryEntry rrEntry; public CalendarServer (String n) { super(n); calendar = new CalendarDataBase(); URN calendarURN = new URN(myURN + "/CalendarDB"); rrEntry = new ResourceRegistryEntry(calendarURN, calendar); resourceRegistry.put (calendarURN, rrEntry); // reads user's calender events from database file readCalendarDataBase(calendar); } public static void main (String[] args) { // Create the calendar server object, and its URN be the string given in CalendarServer obj = new CalendarServer (args[0]); } }

arg[0]

Figure 3: Calendar Server Implementation such a time-slot is found, the agent must then revisit the calendar servers to insert a meeting event in the participant's calendar database. In this application, a user maintains her personal calendar of activities. Each user runs a calendar server which maintains a database for the user's calendar events. It provides two methods to visiting agents { one to check for con icting events with a given event to be scheduled, and the other for inserting an event in the database. The database object stores events in the form of a hash-table. The calendar database needs to be concurrently accessed by the user and visiting agents. Since the agent or the user should always see the latest copy of the database, after any update to the hash-table it is serialized and written to a le. Before any access to the hash-table, this le is checked for its modi cation time. If the le has been modi ed since the hash-table was updated, the hash-table is reloaded from the le. The graphical interface for this calendar management system allows a user to add, delete and edit an event into her calendar database. The user can also schedule an event for more than one person by launching agents based on SplitJoin pattern as described below. We experimented with two implementations for agents to schedule meetings, using two dierent migration patterns: Sequence and SplitJoin. These are described below.

Sequence Based Calendar Agent: This uses a single agent to perform the task. A calendar agent is created with a list of possible options for meeting times. The agent rst visits all servers to check for con icts for each of the options and marks a meeting time as busy if it con icts with some previously scheduled event in any participant's database. At the end of the rst round if all meeting times in the options list are marked as busy, then there is no choice suited for the meeting. Otherwise, the agent picks one of the non-con icting options and revisits the participants' severs again to schedule that event. The calendar agent using the Sequence pattern is implemented by extending the ItinAgent class. In this implementation of the calendar agent, arrive and depart methods of the ItinAgent class are overridden. The arrive method obtains a reference to the calendar database object of the server using the getResource primitive. The depart method checks if the rst round for checking con icts is over. If so, it reverses and resets the itinerary to execute the second round of visits by the agent to schedule the meeting; otherwise it executes the next method of the itinerary. Split-Join Based Calendar Agent: In the implementation using the SplitJoin pattern, the calendar agent creates child agents to visit each participant's server and check for con icts in parallel. Each child is given the parent's list of options for meeting times. After visiting the designated server, a child agent 6

returns to the parent agent's host and reports back data on con icts. The calendar agent's itinerary contains two SplitJoinAll patterns. When the method next of this itinerary is called for the rst time, the rst SplitJoinAll pattern is executed and it creates child agents to check for con icts. On creating a child agent, the parent's list of options is passed to it by calling setResource method. After a child agent has checked for the con ict it returns to the parent agent and executes its actionBeforeJoin method, which merges child agent's status of meeting time options with that of the parent agent. Upon joining of all the child agents, the parent has the complete con ict information of all the participants. The parent agent then chooses a non-con icting option, if there is one. If no such option is found, the parent raises an exception and aborts the next phase. In the next SplitJoinAll pattern, child agents are created and dispatched to insert a meeting event in each participant's calendar database.

5 A Distributed File Access System This middleware system uses the agent paradigm to support sharing of les by a group of users over the Internet. Each user runs a File Access Server, which is an agent server providing secure access to a user's local les. An agent, working on behalf of a user, can visit this server, read some le from or deposit a le in the server's le system. It can also search les using keywords. Higher level applications can be built on top of this middleware; e.g., collaborative authoring tools, shared data repositories for collaborative design, agent-based remote software installations and upgrades etc. The le access system has to satisfy certain security requirements so that only valid users are allowed to access the les according to their credentials and the server's control policies. Hence, it also makes a good testbed to check the security capabilities of the Ajanta System. This system was designed to meet the following requirements. A user should be able to make a set of its local les available to other users. It should be possible to grant access to these les selectively to dierent users. The owner should be able to enforce any desired access control.

5.1 File Access Interface to Agents

The File Access system de nes APIs available to an agent to deposit a le, obtain the contents of some les, search for les containing some keyword etc. The following primitives are available to an agent. The fetchFile method requests the le system to read the contents of the named le. The response object that is returned either contains the le data as a byte array or an exception if the operation failed. The transferFile operation provides an alternative to fetchFile, especially for large les. The le is transferred to the speci ed host/port directly over a TCP connection. Thus, the agent does not need to carry the le data while it traverses its itinerary. For a le transfer request, the agent speci es the DNS hostname and port number to which the le should be transferred. For this, as usually the le is transferred to the agent's creator, the creator runs a le transfer thread to receive les on the designated port. The depositFile operation is the converse of the fetchFile - the agent carries some data that it wants to store on a remote le system. The agent must have the appropriate permissions to create or write a le on this server's le system. The search operation allows agents to perform full-text searches on the index. We use Glimpse3 for indexing and searching. If successful, the search operations return a list of the les that contain the speci ed keywords. The le list generated is ltered to contain only those les for which agent's owner has read permission, otherwise it may lead to a security violation. Based on the search results, the agent may then choose to fetch or transfer the contents of those les, as appropriate.

5.2 File Access Agents

The FileAccessAgent class is derived from the ItinAgent class. A le access agent is given a tasklist specifying servers to visit and the le access operations to execute there. The tasklist translates into an 3

Glimpse is a system from the University of Arizona for full-text search of les.

7

itinerary for the agent. An example tasklist description is shown below. urn:ans:fourier.cs.umn.edu/rsingh urn:ans:fourier.cs.umn.edu/tripathi urn:ans:fourier.cs.umn.edu/tahmed

fetch deposit transfer

ProjectReport message.txt paper.doc

ReportFromSingh messageForTripathi tahmed.doc

Each line indicates a task for the agent. For example, the rst line directs the agent to fetch from user rsingh's server the le named ProjectReport, and store it locally as ReportFromSingh. The agent, when launched, visits the servers on this list performs the requested operations. The client program, which extends the generic agent server, creates and launches an agent. An agent is created with the tasklist and the credentials identifying its creator, owner and the guardian. This system provides both a text-based and a graphical interface for creating an agent.

5.3 File Server Architecture

A le access server extends generic agent server provided by Ajanta. It thus inherits basic agent hosting capabilities from the AgentServer class. It implements a FileSystem resource whose proxy is given to the agents to be used to access the les. When the server starts executing, it creates an instance of the FileSystem resource and inserts it into the resource registry. The user con gures the le access server by specifying a top-level directory, which acts as the root of the le system visible to agents. The root directory contains a full-text index of the contents of all the les in that directory and its subdirectories. All les are protected by associating access control lists with les and directories. The access control list can specify a user's access privileges for a le or directory. The le system implementation includes a separate thread running under the agent server's protection domain that provides the actual access to the underlying local les. Figure 4 shows the nature of the interactions that occur when an agent makes a service request. For example, when the agent invokes the fetchFile method on its le system proxy, the agent thread merely requests the le system thread to perform this operation. This communication between the two threads is implemented using a shared buer, through which these two threads exchange requests and responses. This structure ensures that the agent thread (and thus agent code) never has direct access to the host le system. The le server thread, which receives requests from a visiting agent, performs the requested operation if permitted by the access control list, and returns a response object to the agent.

6 An Agent-Based Web-Search System This agent-based Web Search system is built upon the File Access system described above. The main function of this Web Search system is to allow an agent to perform full-text keyword searches on the les in some remote user's web directory. The system should allow a client to dispatch an agent to a remote user's le access server, perform the search and return the le names as URLs. We wanted to exploit the inherent asynchrony provided by the agent-based paradigm. We also wanted to restrict the information search/ ltering at the server side as much as possible. This system has been designed to facilitate searching of web pages of speci c users. The motivation in pursuing this project was to help students at the University of Minnesota nd if their course webpages have been updated in the past few hours. This kind of search is not possible with the existing search utilities A user has to run the File Access server to facilitate search of his web-pages. The le server rst constructs an index for the user's web directory and stores the index in the root directory of the shared le system. The indexing is done using the Glimpse utility. Visiting agents can then search this web index with any desired combination of keywords permitted by Glimpse. To re ne the granularity of search and to make it more eective, we introduce some ltering constraints in the Web Search system. This ltering is done on the server side. The File Access System takes care of the ltering based on the ltering arguments provided. The user can specify a combination of search words using the and and or operators, as per the Glimpse syntax. An option can be used to specify if the user 8

FILE SYSTEM Job Buffer

File System proxy

AGENT FileSystem Thread

Agent Thread

Access Control List

RESOURCE FILE SERVER OS FILE SYSTEM

Figure 4: File Access Server Architecture wants a case-insensitive search. Another option speci es the frequency count lter. Only those les that have keywords occurring with more than this frequency will be returned. It is also possible to search for only those web documents that have been modi ed in the past over some period of time. Thus, only those les that were modi ed after the speci ed date (and having the keyword) will be returned. The option to obtain a brief abstract (50 words) is also very helpful. This option speci es whether the user wants the rst 50 words of the le to be brought back. This works like a preview. If the user disables this option, then only the lenames and frequency count are brought back. The results of a search are brought back by the agent to its creator. A Perl script is then executed on this data to convert it into an HTML document, which is then opened by a browser for the user to preview. The user can select among several possible options for viewing the results. Security and privacy are obviously important concerns in this kind of web search. Even though a web directory is made for others to view the information one provides, there are times when one does want the world to view a certain le in the web directory. Common examples are data les aiding CGI scripts and other les. Therefore, the Web search system only returns those les that have UNIX \world read" permissions on them.

7 Conclusions and Future Work We have described the Ajanta programming model and how it is used to build three agent based distributed applications. In this paper we have described one middleware application (a distributed le access system) and two user-level applications (a distributed calendar manager and a web search system). These systems test, evaluate and demonstrate the capabilities of Ajanta's programming model, APIs and security architecture. Distributed calendar manager demonstrates how dierent migration patterns can be used to program an application and to simplify the task of creating complex agent itineraries. SplitJoin pattern allows it to parallelize the task of scheduling events at multiple servers. We have used the Distributed File Access system to test and demonstrate the capabilities of the Ajanta security architecture. In future we would include security features in the calendar management system to further test Ajanta's security mechanisms. The Web Search system running on top of the File Access system demonstrates the bene ts of the agent paradigm for remote processing and information ltering. In our future work we intend to implement and study applications involving agent-group management and communication. Another closely related area that interests us is collaborative systems. Currently we are also investigating use of the mobile agent paradigm in assisting our system administrators in monitoring our departmental computing facilities for intrusion detection.

9

References [1] Robert S. Gray. Agent Tcl: A exible and secure mobile-agent system. In Proceedings of the Fourth Annual Tcl/Tk Workshop (TCL 96), July 1996. [2] Colin G. Harrison, David M. Chess, and Aaron Kershenbaum. Mobile Agents: Are they a good idea? Technical report, IBM Research Division, T.J.Watson Research Center, March 1995. Available at URL http://www.research.ibm.com/massdist/mobag.ps. [3] Dag Johansen, Robbert van Renesse, and Fred B. Schneider. An Introduction to the TACOMA Distributed System. Technical Report 95-23, Department of Computer Science, University of Troms, June 1995. [4] Neeran M. Karnik and Anand R. Tripathi. Design Issues in Mobile Agent Programming Systems. IEEE Concurrency, 6(6):52{61, July{September 1998. [5] M. Ranganathan, Anurag Acharya, Shamik Sharma, and Joel Saltz. Network-aware Mobile Programs. In Proceedings of USENIX '97, Winter 1997. [6] Karen Sollins and Larry Masinter. RFC 1737: Functional Requirements for Uniform Resource Names. Available at URL http://www.cis.ohio-state.edu/htbin/rfc/rfc1737.html, December 1994. [7] Markus Straer, Joachim Baumann, and Fritz Hohl. Mole - A Java Based Mobile Agent System. In Proceedings of the 2nd ECOOP Workshop on Mobile Object Systems, 1996. [8] Joseph Tardo and Luis Valente. Mobile Agent Security and Telescript. In Proceedings of COMPCON Spring '96, pages 58{63. IEEE, 1996. [9] Anand Tripathi, Neeran Karnik, Manish Vora, Tanvir Ahmed, and Ram Singh. Mobile Agent Programming in Ajanta. In Proceedings of the 19th International Conference on Distributed Computing Systems, May 1999. [10] Anand R. Tripathi and Neeran M. Karnik. Protected Resource Access for Mobile Agent-based Distributed Computing. In Proceedings of the 1998 ICPP Workshop on Wireless Networks and Mobile Computing, pages 144{153. IEEE Computer Society, August 1998. [11] David Wong, Noemi Paciorek, and Dana Moore. Java-based Mobile Agents. Communications of the ACM, 42(3):92{102, March 1999.

10