DEVELOPMENT OF DISTRIBUTED SYSTEMS USING MOBILE AGENTS IN AJANTA

grapedraughtΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

111 εμφανίσεις

DEVELOPMENT OF DISTR
IBUTED
SYSTEMS USING MOBILE

AGENTS
IN AJANTA

by

Ram D. Singh

Submitted in partial fulfillment of the
requirements for the degree of

Master of Science

University of Minnesota

1999

Approved by

________________________________
___________________


Chairperson of Supervisory Committee


________________________________
__________________



________________________________
__________________



________________________________
__________________


Program Authorized

to Offer Degree

________________________________
_________________


Date

________________________________
__________________________



University of Minnesota

Abstract

DEVELOPMENT OF
DISTRIBUTED SYATEMS
USING
MOBILE AGENTS IN AJA
NTA

by Ram D. Singh

Chairperson of the Supervisory Committee:

Professor Anand Tripathi


Department of Computer Scien
ce

Ajanta is a Java

based system for programming applications using mobile agents
over the Internet. Focus of this thesis is design and implementation of three
agent
-
based distributed systems in Ajanta. We first describe the architecture and
the programmi
ng environment of the Ajanta system. Then we present design
features and implementation details of these agent based systems. These systems
test and evaluate the capabilities of the Ajanta system in terms of its support for
agent
-
based system development a
nd security architecture. The systems described
here include a distributed file access system, a global file system and a distributed
calendar manager.



TABLE OF CONTENTS

1.

INTRODUCTION

1

2.

OVERVIEW OF AJANT
A ARCHITECTURE

2

3.

DISTRIBUTED FILE ACC
ESS SYSTEMS

4

3.1.

R
EQUIREMENTS

4

3.1.1.

APIs to be supported

4

3.2.

O
VERVIEW OF THE
S
YSTEM
A
RCH
ITECTURE

5

3.2.1.

File Access Agents and Client Program

5

3.2.2.

File server Architecture

5

3.2.2.1.

The file system resource

6

3.2.3.

S
erver Side ACLs and Ajanta Security Model

8

4.

ARCHITECTURE OF A GL
OBAL FILE SYSTEM

9

4.1.

R
EQUIREMENTS

10

4.2.

O
VERVIEW OF
A
RCHITECTURE

10

4.3.

A

PROOF
-
OF
-
CONCEPT
I
MPLEMENTATION IN
A
JANTA

11

4.3.1.

File System Initialization and Open Command

12

4.3.2.

FileProxy agent and FileServer agent

13

5.

DISTRI
BUTED CALENDAR MANAG
EMENT SYSTEM

13

5.1.

R
EQUIREMENTS

13

5.2.

C
ALENDAR
S
ERVER
A
RCHITECTURE

14

5.2.1.

Calendar Database

15

5.2.2.

GUI for

Calendar Database

16

5.3.

C
ALENDAR
A
GENT
D
ESIGN

17

5.3.1.

Sequence Based Design

17

5.3.2.

Split
-
Join Based Design

18

6. CONCLUSIONS AN
D FUTURE WORK

20





ii

LIST OF FIGURES



F
IGURE
1:

T
HE
A
JANTA
S
ERVER
A
RCHITECTURE

2

F
IGURE
2

:

F
ILE
A
CCESS
S
ERVER
A
RCHITECTURE

6

F
IGURE

3:

G
LOBAL
F
ILE
S
YSTEM
A
RCHITECTURE

10

F
IGURE
4:

R
EMOTE
F
ILE
O
PEN

11

F
IGURE
5:

C
ALENDAR
S
ERVER
I
MPLEMENTATION

14

F
IGURE
6

M
AIN
GUI

FOR
C
ALENDAR

16

F
IGURE
7

C
ALENDAR
GUI

FOR
S
CHEDULING

16

F
IGURE
8

C
ALENDAR
A
GENT
I
MPLEMENTATION USING
S
EQUENCE
P
ATTERN

18

F
IGURE
9

C
ALENDAR
S
PLIT
J
OIN
P
ATTERN
I
MPLEMENTATION

19

F
IGURE
10

C
ALENDAR
A
GENT WITH
S
PLIT
J
OIN
P
ATTERN
I
MPLEMENTATION

20




iii

ACKNOWLEDGMENTS

I would like to thank Prof. Anand Tripathi for his guidance and inspiration through the course of
this project. We spent lots of time tog
ether solving problems and what I learnt is invaluable. He
provided a unique research opportunity and congenial working atmosphere.


I would also like to thank Tanvir Ahmed and Arvind Prakash for great collaboration and being a
constant source of support w
hen needed.


I want to thank my parents for their support over the years and for believing in me the entire time.
My accomplishments are reflection of their values and beliefs.


This project represents an experience that can’t really be described in words
. It gave me wonderful
opportunity to be associated with many and who helped me in learning. I would like to thank
them.




1.

Introduction

The concept of mobile agent based distributed computing has received widespread attention in the
recent years for its po
tential to support increased asynchrony in client
-
server interactions. It also raises
the promise of reduced network interaction and disconnected operations where a client needs to
maintain a connection during its interactions with a server. The main advan
tages of the mobile
-
agent
paradigm lie in its ability to move client code and computation to remote server resources, and in
permitting increased asynchrony in client
-
server interactions [1]. Agents can be used for information
searching, filtering and ret
rieval or 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 or dynamically upgrading the capabilities of existing services.


Aja
nta
1

is a Java
-
based mobile agent programming system that we have developed at the University of
Minnesota. This system has been designed with the goal of supporting development of secure and
robust agent
-
based programs in an open distributed system. Ajant
a architecture and programming
model have several unique features. Naming of all globally accessed objects (agents and servers) is
based on the URN framework. Ajanta provides mechanisms for a server to grant restricted access of
its local resources to visi
ting agents. It allows an agent creator/owner to recall its agent. For application
programming, Ajanta supports the concept of programmable patterns of migration for constructing
agent itineraries. Additionally, Ajanta presents a clear model for handling e
xceptions encountered by a
mobile agent. Ajanta's
guardian

mechanism allows the programmer to perform recovery actions
from exceptions that are encountered, but not handled by an agent.


This thesis report demonstrates the use of the mobile agent paradigm

in building three distributed
middleware and application systems. These systems were developed above the Ajanta system. There
were several motivations for developing these distributed applications. The first one was to test and
evaluate the capabilities o
f the Ajanta system in terms of its support for agent
-
based 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
be potentially used by the community.


The first system is a middleware. It is a distributed file access system to support sharing of files
between users over the Internet. This system allows a user to send agents to distribute a fi
le to a group
of other users. He can also send an agent to obtain a file from some user's file system if appropriate
access privileges have been granted by the file's owner. This system also allows one to perform full
-
text
key
-
word searches over the files
at a remote host. The second system presented in this report is an
experimental proof
-
of
-
concept implementation of an agent
-
based global file system. This system is
envisioned to provide the flexibility of dynamically controlling the caching and synchroniz
ation
policies for shared files. The third application is a distributed calendar manager system. It allows a user



1

See http://www.cs.umn.edu/Ajanta



2

to launch an agent to visit other user's calendar to search of a non
-
conflicting meeting time to schedule
a meeting.


2.

Overview of Ajanta Archi
tecture

Ajanta is Java
-
based system for developing mobile agent programs over the Internet. Ajanta system
provides facilities to build customizable servers to host agents, and a set of primitives for the creation
and management of agents. Programming abst
ractions are provided to specify an agent's tasks and its
migration plans. Robustness of the system is also an important concern. An application can monitor
its agents' status, and control it remotely when needed. Security is another important requiremen
t of
an agent’s 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.
Conversely, an agent needs to be protected while in

transit, because it may carry sensitive information
about the user that it represents.



Figure
1
: The Ajanta Server Architecture

In Ajanta, mobile agents are mobile objects [2]. Agents encapsulate code and execution context a
long
with data. In implementing agents and servers, the Ajanta architecture makes use of several of
important features of the Java language
---

such as object serialization, security architecture, and
reflection. We use Java's facilities for object seria
lization and dynamic class loading to implement
agent mobility.




3

An application extends the system
-
defined Agent class to define a new application specific agent. The
Agent

class implements the generic functionality of a mobile agent. It defines the proto
col for
handling the arrival and departure events of an agent at a server. It also provides a reference to the
agent’s current host environment. Each agent is bound to its host environment object through an
object reference named
host
. Using this, an agen
t can request various services from its local host.
These include obtaining access to local resources, registering itself as a resource, or requesting
migration. The most commonly used requests are migration using the
go

function or access to host
resource
s using the
getResource

function.
Figure
1

depicts overall architecture of server and client
side in Ajanta system.


An extension of the base
Agent

class is the
ItinAgent

class, which defines and implements an
itinerary
-
based agen
t. Itineraries can be composed using some basic patterns of migration. More
detailed description of the migration patterns and their composition can be found in another paper [6].
These basic patterns include, a
Sequence

for visiting destination server in

a given order,
Set

for an
unordered traversal of set of servers, and
Selection

for visiting any one among a set of servers.
The
Split

pattern allows an agent to create a set of child agents.
SplitJoin

allows the parent to
wait to the child agents to retu
rn and synchronize by reporting their results. An itinerary provides the
next

method, using which an agent can migrate to the next location in its itinerary.


The
AgentServer

class defines and implements the generic functionality of an agent server. It can

be easily extended to customize it for specific services by creating appropriate resources (objects) and
making them available to the visiting agents through its
resource registry
. A visiting agent
can specify the name of a resource it wants to access. If

the resource is registered in the server's
registry, it passes the request to that resource. The resource then, based on its security policy,
constructs suitably restricted proxy, and gives to the agent a reference to this proxy. The agent cannot
access t
he resources directly, and the proxy object ensures that security sensitive operations are
disallowed. The Ajanta system architecture ensures that the proxy class is loaded from trusted
codebases. Details of Ajanta's proxy access to resources can be found
in [6].


Ajanta design uses the Uniform Resource Name (URN)[5] scheme for naming global entities such as
agent servers, agents, users etc. An URN is a persistent, location
-
independent resource name, which
can be used for accessing the resource, or its char
acteristics. 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 different principals (users, agents, and agent
s
ervers). To meet these requirements, Ajanta name service protects its database using access control
lists for its entries.


The name service maintains DSA public key and the El
-
Gamal public key for each registered principal,
and it executes a challenge/res
ponse based authentication protocol [7] for any update operation. An
example of an URN in Ajanta's namespace is:



urn:ans:cs.umn.edu/UserName/ResourceName



4

Here “ans” is the Ajanta Namespace Identifier [4] and “cs.umn.edu/UserName/
ResourceName” is
the namespace specific 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
characteristics. In the above URN example, “cs.umn.ed
u” is the DNS domain where the object was
first 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 th
is 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.

Distributed File Access Systems

It is a middleware using the agent paradigm fo
r implementing a system for sharing files over the
Internet. Using this file system a user or an application can read or write a file from a remote machine.
Each user runs a file server process, which is an agent server that provides access to a portion of

the
user’s local files in restricted manner using an access control list. Agents can visit this server, request
files by name (URN), deposit files into its local file system, search files using keywords, etc. Higher
level applications can be built on top
of this middleware; e.g., collaborative authoring tool, shared data
repositories for collaborative design etc. File system has to satisfy certain security requirements so that
only valid users are allowed to access the files according to their credentials
and control visibility of
data made accessible via this file sharing system. Hence, it also gives a very good test
-
bed to check the
security capabilities of the Ajanta System.


3.1.

Requirements

The agent
-
based file sharing system described here allows users t
o selectively share files over the
Internet. This system was designed to fulfill following basic requirements:




A user should be able to make a set of its local files available to other users



It should be possible to grant access to these files selective
ly to different users. Typically, a user
would be interested in either reading or writing a file on a remote user's file system. The owner
should be able to enforce any desired access control.



To provide full
-
text keyword searches over the files using glim
pse index


3.1.1.

APIs to be supported



FetchFile

to retrieve the content of a specified remote file and store the content of the file
locally.



DepositFile

to store the content of a local file as a specified file on the remote host.



TransferFile
for transferring c
ontents of large file from remote site over TCP connection.



Search

operation to locate names of the files on remote site which conations the specified
keywords or search expression.




5

3.2.

Overview of the System Architecture

To facilitate access to the files for

other users one has to run a file server. File server is extended from
generic
AgentServer

and hence it has agent
-
hosting capabilities. In order to facilitate access to its
local file it implements a resource whose proxy is given to the visiting agents to

be used to access the
files. Any user wishing to access a file has to send an agent to the corresponding server. Now to launch
an agent one creates an agent launcher (
Client program
), which creates, initializes and launches a
file access agent.
FileServer

is described in section
3.2.2

and Client and file access agent is
described in following section.


3.2.1.

File Access Agents and Client Program

The
FileAccessAgent

class is derived from
ItinAgent
. A file access agent is given a taskl
ist
specifying servers to visit and the file access operations to execute there. The tasklist translates into an
itinerary for the agent.
Client

program that extends generic agent server creates and launches the
agent. The agent is created with the taskli
st and the credentials identifying its creator, owner and
guardian of the agent. User specifies the tasklist of the agent in request file, passed as command line
argument to the client server. A typical request file is shown below


urn:ans:fourier.cs.umn.e
du/rsingh fetch somefile somefile.out

urn:ans:fourier.cs.umn.edu/rsingh deposit somefile somefile.out

urn:ans:fourier.cs.umn.edu/rsingh transfer somefile somefile


The first line of the above tasklist indicates that the file somefile has to
be fetched and stored as
somefile.out. The client server reads and parses the above file to create a vector of tasks and pass it to
the agent. After creating the agent server sign the agent with the owner’s keys and start the agent.
Start

method of the
Iti
nagent

finds out the first
itinEntry

from the itinerary and lunches
the agent to execute that entry. When an agent arrives at a server it first obtains the proxy of the
fileSystem

and issues a file access request (
FetchRequest
,
DepositRequest

etc). For a
F
ileTransfer

request, the agent specifies the DNS hostname and port number to which the file
should be transferred. For this, as usually the file is transferred to client object, the client object runs a
file transfer thread to receive files on a designated

port. After depositing the request agent waits for the
response object from the current host and on completion of the requested task it migrates to the next
host in the itinerary.


3.2.2.

File server Architecture

A file server extends the generic agent server pr
ovided 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 files. When the server starts executing it creates an instance
o
f the
FileSystem

resource and inserts it into resource registry.
FileSystem

interface is
implemented by the class
FileSystemImpl
.




6



Figure
2

: File Access Server Architecture

The user configures the file server by specifying a
top
-
level directory, which acts as the root of the file
system exposed to agents. The root directory also contains a .
acl

file, which is used to initialize the
access control list, which is in turn used to restrict access to files based on the user’s ident
ity. It also
contains full
-
text index of the contents of all the files in that directory and its subdirectories. This
allows agents to perform keyword
-
based searches to locate files of interest. Index files are generated
using Glimpse
2

index and hence appr
opriate for text files only.


3.2.2.1.

The file system resource

FileSystem

interface defines the API available to an agent to deposit a file, obtain content of a file,
search for keyword etc.
FileSystemImpl

implements the above APIs of the
FileSystem

class
as well
as implements
Resource

and
AcessProtocol
. To access the files extended by file
server, agent uses URN, which are translated by the
FileSystemImpl

to appropriate internal path,
needed to access the files on its local disk.
Definitions

of the APIs implemente
d by the system are


Public
FetchResponse

fetchFile

( URN fileName )

Public
TransferResponse

transferFile

(URN fileName, URL dest )

Public
DepositResponse

depositFile

(byte [ ] fileBuf, URN fileName)

Public
SearchResponse

search

(String searchString , Bool
ean ignoreCase)


The
fetchFile

method requests the file system to load the contents of the named file. The
fetchResponse

object that is returned either contains the file data as a byte array or an exception
if the operation failed. Fetch operation may fail

due to a number of reasons


for example due to a



2

Glimpse is a full

text file search and index tool developed and made available by University of Arizona.



7

security violation, file is not available at all etc. An agent is able to fetch or transfer a file only if the
owner of the agent has the read permission on the file.


The
transferFile

operation provides
an alternative to
fetchFile

operation especially for
large files. If the content of the file is large then it will be more beneficial to transfer the content of the
file to the specified URL directly over a TCP connection. Otherwise, agent has to carry the

data along
while it traverses its itinerary. The parent application of the agents starts a
ListnerThread
, which
listens at the address specified by the URL, receives the incoming data and stores the file locally.


The
depositFile

operation is the convers
e of the
fetchFile



the agent carries the contents
of the file in the
fileBuf buffer
, and specifies the output file’s URN. If the agent has the
authority to deposit file and write permission on the specified file on the target server, the data is
stored u
nder appropriate filename. Otherwise, an exception is enclosed in the
DepositResponse

object that is returned.


The
search

operation allows agents to perform full
-
text searches on the index. We use the Glimpse
utility for indexing and searching. The
searc
hString

provided by the agent can include Boolean
operators and other parameters supported by Glimpse. In addition,
ignoreCase

parameter
specifies whether the search should be case sensitive or not. If successful, the search operations return
a list of the

file names that contain the specified keywords. The list of the files generated by the
Glimpse is filtered to contain only those files for which agent’s
owner

has read permission as it may
lead to security violation. Based on the result of search the agen
t may then chose to fetch or transfer
the contents of those files if appropriate.


File System Thread
:

If the file system resource was implemented as a passive object, then if the agent
invoked any of its methods, it would be agent’s thread attempting to a
ccess the local file system on the
file server machine. Naturally, by default this is not allowed by Ajanta's security manager. Instead, the
file system implementation includes a separate thread running under the agent server's protection
domain that prov
ides the actual access to the underlying local files. This thread is created and started
by the constructor of the
FileSystemImpl
.
Figure
2

shows the nature of the interactions that
occur when an agent makes a service request. Fo
r example, when the agent invokes the
fetchFile

method on its file system proxy, the agent threads merely requests the file system thread to perform
this operation by depositing a
FetchRequest
. This communication between the two threads is
implemented usi
ng a shared buffer, into which a job request is deposited. The agent thread then waits
for the file system thread to complete the operation. Server thread serves the requests in order and
wakes the agent thread after completing the task. Results are retur
ned to the agent as
response

objects, which are member of the request. The
response

object is allocated memory and properly
initialized by the server thread before it wakes up the agent. This structure ensures that the agent
thread (and thus agent code) n
ever has direct access to the local disk.




8

3.2.3.

Server Side ACLs and Ajanta Security Model

The very purpose the file system is to provide secure access to certain files to visiting agents. Since the
files are being shared over the Internet a stringent security
requirement has to be fulfilled. Current
system tries to meet such security requirements by means of the following: a user based ACLs, Ajanta
security manager and Agent’s credentials.



Agent’s Credentials
:

FileSystemImpl

class implements the
AccessProtoco
l

interface, i.e. a
getProxy

method. This method can inspect the agent’s credentials to determine its owner identity
and based on its security policy, enable or disable any of the
FileSystem

interface methods. In
order to ensure that the credentials of an
Agent is not modified during transfer, and to ensure that it
represents the correct
User
/
Owner

, the agent transfer protocol takes extra precautions. The steps
of the agent transfer protocol can be briefly described in these steps.




Before an agent can be

transferred from an its current host to the next host an
ATPTransfer

request is sent to the next host. Request contains the credential of the agent as well as the signature
of the credential signed either by the
Owner

or by the
Creator

of the agent.




Age
ntServer
’s ATP handler on receipt of an
ATPRequest

first determines the signer of the
credential and obtains its public keys from the name registry. It then verifies the signature of the
credential with the credential present in the
ATPrequest
. Now based o
n the verified credential
the AgentServer may or may not permit transfer of the requested agent and accordingly it sends a
positive or negative acknowledgement (
ATPReply
).




After sending a reply to the requester,
ATPHandler

creates a
domain database

entry
for
the agent. Entry signature field is set to the signature verified in the previous step. However, the
verified

field is set to false. This indicates that a second round of verification is required once
the agent itself is transferred.




Upon receipt of
positive acknowledgement the current host of the agent serializes the agent and
sends it to the target host. The target server upon receipt of the agent obtains the credential of the
transferred agent and verifies it with the signature stored in the domain

database entry. If signature
matches then domain database
verified

field is set to true and agent is started. Else, it sends
exception as part of
ATPReply
.


Each of the above steps is executed in authenticated environment provided by the
AgentServer

and e
nsuring validity of credentials of the agent.


Ajanta Security Manager
:
It extends Java Security Manager. Its
readAccess

and
writeAccess

methods are checked before any file operation is performed. This allows a server to restrict access to
its local files.

If a file is accessed by the “main” thread group (server thread group) then it grants read
and write permission. On the other hand, if it is accessed by any agent’s thread group it checks for


9

signature and the ACL associated with each agent server. If the

agent was signed by the
Creator

then read and write permission is denied. Whereas, if the agent was signed by the
Owner
, security
manager grants read and write permission based on the ACL entry for the owner. ACL is initialized by
reading the .
acl

files p
resent in the server’s
config

directory. Thus limiting access to its local files
to only certain threads.


File System’s Access Control List
:

Files are protected by associating an access control list with files and
directories in this system. An agent belo
nging to a user may have a proxy with enable method, but that
does not imply that it can access any of the files available. ACL list therefore places appropriate limits
on file accessibility. The
FileAccessServer

thread, which receives requests from a visi
ting agent,
performs the requested operation if permitted by the access control list, and returns a response object
to the agent. For example, some entries in the access control list can be

< root ri urn:ans:fourier.cs.umn.edu/rsingh >

< somefi
le rw urn:ans:fourier.cs.umn.edu/rsingh >

This means that rsingh User may be given read and write access to the file “somefile” and he can
inherit read permission from the root. The rules for granting or denying access are as follows:




If an access c
ontrol list (ACL) for the file exists, then the system checks if this list contains an
entry giving permission to the agent's
Owner

for the requested operation (read, write, inherit). If
so, the operation is allowed.




If there is no access control list (
ACL) associated with a file/directory, then the system looks for
the ACL of its parent directory. This rule is applied recursively, until a directory with an ACL or
the root directory is reached. If no ACL is associated with the root directory, access is
denied.




If a directory is reached with an ACL associated, this ACL is searched for the access rights given to
the agent's owner. Each entry also contains an “inheritance” right, which means that the rights
given to a principal for this directory are also
applicable to the files and directories contained
within it if no ACL is associated with them.


4.

Architecture of a Global File System

It is an experimental file system developed using mobile agent technology. It allows an agent or
program to open, read and
write a file on a remote machine. Instead of the agent migrating to the file
system resources as in the case of Distributed File Access system, an agent moves to a host to provide
the resource. The important issues addressed in the design of this file syst
em were global availability,
flexibility and adaptability. The file system should be available to an agent at all the servers where it
migrates. In order to avoid building file system functionality in each agent, file system was
implemented using mobile ag
ents. The protocol to maintain the consistency of the data of
concurrently accessed file is flexible. Moreover, certain system defined parameters and protocol can be
changed at run time.




10

4.1.

Requirements

The global file system should be able to meet the follo
wing requirements:



An agent should be able to open, read and write a remote file from anywhere.



It should provide distributed as well as centralized caching so that their trade off can be analyzed.
Moreover, different kinds of consistency model can be supp
orted.



Cache module should be dynamically configurable i.e. (block size, cache size etc).



It should be able to support any kind of policy for consistency control at per file basis (Andrew
model, Sprite model, NFS model etc [3]).



Policy used to maintain the

consistency of concurrently opened file can be changed dynamically.



4.2.

Overview of Architecture

Instead of the agent migrating to the file system resources as in the case of the File Access system
described in Section
3
, an age
nt moves to a host to provide a resource. This agent, a
FileProxy
agent, is created when a client opens a file, and it migrates from the server to reside on the client side.
To service requests from the
FileProxy

agent, a
FileServer

agent resides on the se
rver side. A
client program is able to read and write a file by interacting indirectly with the
FileProxy

agent, by
using a
RandomAccessFile

interface. For each opened file there exists a single
FileServer

agent and multiple
FileProxy

agents residing at d
ifferent agent servers. On any agent server, a
FileProxy

agent can be shared by more than one client program at a host, if it is permissible by the
file consistency policy.
Figure
3

show the overall architecture of the system.





Figure
3
: Global File System Architecture



11

The
AjfsFile

class, like the Java
RandomAccessFile

class, provides methods to open, read,
write, and seek in the file. In order to provide these services to the user agent it interac
ts with the
FileProxy

agent to read and write the file at the block level. The
FileProxy

and
FileServer

agents contain two primary components: a
cache module

and a
policy module
. The file is
kept updated and consistent by interaction between the
FileServe
r

agent and all the
FileProxy

agents. There exist two RMI communication channels between the
FileServer

agent and the
FileProxy

agent. A control channel is used to send command from the
FileServer

agent to the
FileProxy

agent (i.e. flush the cache, change

cache size, stop caching,
change policy etc) or requests from the
FileProxy

agent to
FileServer

agent (get or put data).
The data channel is used by
FileProxy

agent to either download data from the
FileServer

agent or upload the data to it.


4.3.

A proof
-
of
-
co
ncept Implementation in Ajanta

A prototype of this global file system was implemented to test and study the above
-
proposed concept.
The current prototype supports the AFS (Andrew File System) consistency policy. In the AFS policy
once a file has been op
ened by a user, the only visible modifications to the file are the modifications
performed by this user and not by others. The AFS policy uses a write
-
on
-
close policy for writing the
updated file to the server. After a file is closed, all modifications be
come visible to all future open
requests. However, the modifications are not visible to those clients who have already opened the file.
If two clients happen to be writing the file at the same time, the changes made by the last writer
become effective and

visible to subsequent users of the file. Any changes made by the other writers are
lost.




Figure
4
: Remote File Open



12

4.3.1.

File System Initialization and Open Command

A client accesses a file in the global file system using an
instance of the AjfsFile class. This class
provides the interface for random file access and is carried with the agent as it migrates through the
network. When the client wishes to access a global file, it creates a local instance of the file using the
con
structor of
AjfsFile
, passing the URN of the file. The URN contains the URN of a server for
the file as well as the name of a file on the server.
Figure
4

shows the events that occur when a client
programs open a remote file.


St
ep 1: The
AjfsFile

constructor determines whether the requested file has already been opened in
the current client agent environment. If it is already opened then it obtains the proxy of
FileProxy

agent from the local resource registry and initializes itse
lf. If the file is not already opened then
AjfsFile

obtains proxy of the agent server for the file and calls its open method with file name as
the argument.


Step 2: If a
FileServer

agent does not exist for the requested file, open method on server side
cr
eates a
FileServer

agent and launches the agent to itself. In the current prototype, one file
server agent is created for each file that is opened. Each file is associated with a consistency policy that
is set by the creator of the file. The
FileServer

age
nt uses this policy to control its interactions
with file proxy agents that maintain cache copies of the file.


Step 3: Now the server creates a
FileProxy

agent who will manage the cached portions of the file
that residing on the client server. The
FilePr
oxy

agent is first started on the current server where it
communicates locally with the file server agent to initialize the state of the cached file.


Step 4: After the cache module of the
FileProxy

agent has been initialized, it migrates to the client
se
rver.


Step 5:
FileProxy

agent upon migrating to the client side registers itself as the resource and then
wakes up all the
AjfsFile

or any other process waiting for this resource.
AjfsFile

constructor
after calling the open method of the file server crea
tes a null resource entry for the
FileProxy

agent.
AjfsFile

then waits for this resource to be initialized later by the arriving
FileProxy

agent. When
AjfsFile

is woken up it initialize itself with this registered resource and in future, it
reads and writ
es the file using this agent.


Step 6: The
FileProxy

agent upon arriving at the client host communicates with the
FileServer

agent to notify the file server agent of its arrival and setup data and control channel
with it. As the file is used, the file prox
y agent and the file server agent communicate with each other
to manage the consistency of the file. The communication that takes place is determined by the
consistency policy that is being used.




13

4.3.2.

FileProxy agent and FileServer agent

In global file system
, the
FileProxy

agent maintains a cache of fixed size blocks of the global file.
On the other hand,
FileServer

agent caches the global file and keeps the file consistent when
multiple
FileProxy

agents are interacting with it.
FileProxy

provides interface t
o read and
write a block to its cache. Thus, blocks are accessed by the
AjfsFile

class using a block level
interface. The
AjfsFile

class then reads and writes directly from the cache blocks and server the
user request.


The
Policy

class is used to control

the consistency of the blocks in the
CacheModule
. At the
beginning and after completion of every block read or write the
CacheModule

consults the
Policy
. The
Policy

is then able to perform any necessary consistency actions. In the AFS policy,
each file pr
oxy agent maintains a copy of the file, which represents the state of the file when it was
initially opened. As long as the file does not change, the file proxy agent will permit other agents in the
client agent environment to open the file. The policy mod
ule of FileServer makes sure that any open
call receives latest copy according to the AFS policy.


When an agent client who has opened the file for writing finishes writing a file by issuing the
close

() method, the changes are then written back to the
Fil
eServer

agent. When a file is written to the
FileServer

agent, it notifies all the file proxy agents to invalidate their caches for new accesses. It
prevents new clients from accessing the cached copy of the file, which is now stale. Any agent that has
the

file open may continue to access the file. However, when an agent opens the file, a new version of
the file must be obtained from the
FileServer
. In our prototype, the
AjfsFile

class requests
another file proxy agent when the cache managed by the current
file proxy agent becomes stale.


5.

Distributed Calendar Management System

5.1.

Requirements

The main objective of this distributed calendar management system is to be able to schedule
appointments based on the availability of the various participants involved. I
t allows users to maintain
a calendar of their daily activities, which can be made available to other users on a restricted basis. A
user may not want others to be able to see the details of the appointments. He should be able to
specify the privacy constr
aints for every appointment. When a user needs to schedule an appointment,
he can launch a mobile agent to visit each participant's calendar server with a set of possible times for
the meeting. The agent then visits the calendar server of every participant

and tries to find a possible
time
-
slot when all the participants are available. If such a timeslot is found, the agent must then revisit
the calendar servers to insert a meeting event in the participant's calendar database. To design and
implement a GUI
for the above calendar manager, where an user can add, delete or edit an activity
already scheduled. User should also be able to launch agents to schedule meeting with other
participants. User or an Agent should be able to modify the database concurrently
and they should
always see the modified data.




14

5.2.

Calendar Server Architecture

In this application, a user maintains his personal calendar of activities. Each user runs a
CalendarServer
, which is derived from the base
AgentServer

class. A calendar server
cu
stomizes the generic agent server by adding a
Resource

viz. a
CalendarDatabase

object,
which is a database recording the schedule of activities and appointments for a user. The
CalendarEvent

class is used to represent an appointment. This calendar databas
e implements the
Calendar

interface which provides the following two methods to agents.

checkConflictingEvent

(
CalendarEvent

e )

scheduleEvent

(
CalendarEvent

e )


The
checkConflictingEvent

method checks if a given event clashes with an existing
appoi
ntment. The
scheduleEvent

method allows the agent to schedule a particular appointment
by inserting an entry into the database. Access to this resource is restricted by a
CalendarProxy
.
CalendarServer

constructor creates a new
CalendarDatabase

object and r
egisters 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”.
Figure
5

shows implementation details of
CalendarServ
er
.
























Figure
5
: Calendar Server Implementation

public class CalendarServer extends AgentServer {


private CalendarDataBase calendar;


private ResourceRegistryEntry rrEntry;




public CalendarServer (String n) {


super(n);


calendar = new Calend
arDataBase();


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
arg[0]



CalendarServer obj = new CalendarServer (args[0]);


}

}




15

5.2.1.

Calendar Database

CalendarDatabase

class store events in the database in form of a hash
-
table, hashed on the date.
An entry in the hash
-
table c
omprises of date and corresponding
DayEvents
. It’s
getProxy
()
methods creates and return an instance of
CalendarProxy

with a set of enable methods. An
agent or an application gets this instance as the registered resource and is able to call the methods,
w
hich are allowed for them. The methods extended by the proxy are
scheduleEvent
,
checkConflict
, and
getDayEvents
. The calendar database needs to be concurrently accessed
by the user and agents. Since the agent or the user should always see the latest copy o
f the database,
after any update to the hash
-
table it is serialized and written to a file (
HashTableDB)
. Before any
access to the hash
-
table,

this

file is checked for its modification time. If the file was modified later
than the last time hash
-
table was u
pdated, then the hash
-
table is read again from
the
file. Moreover,
to allow concurrent access with small latency and for better security,
CalendarDatabase

starts a
CalendarDBThread
.
CalendarDatabase

deposit request to read or write the file to the
thread
and the thread serves these requests accordingly.


DayEvents

class extends Java vector class and stores
CalendarEvents
, where each
CalendarEvent

represents an individual event of the day. It provides insert and delete method, to
add and remove a
CalendarE
vent

from the vector respectively. Besides the above two methods
it also provide following methods


GetCalEvent

(
Date

d )

CheckConflict

(
CalendarEvent

e )

Sort

()


GetCalEvent

return the
CalendarEvent

in
DayEvents

whose start time matches with the
date

argument.
CheckConflict

method determines whether the
CalendarEvent

passed as
the argument to the function conflict with any
CalendarEvent

present in the
DayEvents
. A
CalendarEvents

e1 and e2 are at conflict if events duration overlap each other i.e. end
time of e1
< start time of e2 or vise versa. Sort method sorts
CalendarEvents

of the
DayEvents

in the
increasing order of their start time.


CalendarEvent

contains a description, a list of participants involved, the start time, the duration, a
flag indica
ting status and a flag indicating privacy constraints. The status flag indicates whether the
appointment is active, tentative, busy or free. The privacy constraint flag specifies restricted access to
the details of the appointment (private, semiprivate or
public). It also provides
getX

(
getStatus
,
getStartTime

etc) and
setX

(
setStatus
,
setStartTime

etc) methods to change
individual components of the
CalendarEvent
.




16

5.2.2.

GUI for Calendar Database

GUI for
CalendarDatabase

management allows a user to ADD, DELETE a
nd EDIT a
CalendarEvent

into his database. User can also schedule a
CalendarEvent

for more than
one person by launching agents based on
SplitJoin

pattern as described in section
5.3.2
.

Figure
6

depicts the main window of the calendar database manager.




Figure
6

Main GUI for Calendar

After entering appropriate date in month:day:year format pressing GET obtains all the events
sc
heduled for that date. User can select an event from list of the items shown in the window edit or
delete that event from the database. ADD, SCHEDULE and EDIT share a common window which is
shown in the
Figure
7
. Each event entry
comprise of date, start time, duration, description and list of
participant. Date, start time and duration are compulsory field and without filling these, an operation
can not be performed.


Figure
7

Calendar GUI for Sch
eduling



17


SCHEDULE button pops up the same edit window, but when Ok is hit instead of just modifying the
local database as in add, delete or edit, it launches agents to do this. When the calendar GUI manager
is started, it creates an instance of the
Calenda
rClient
, which is an agent launcher. Schedule
method creates a request file from the data obtained from the edit window and calls the run method of
the
CalendarClient

with this request file as the parameter.
CalendarClient

“run” creates
and launches agents

to schedule the requested event. For detail discussion of
CalendarClient

and Agent, please refer to section
5.3

and
5.3.2
.


5.3.

Calendar Agent Design


We experimented with two implementations for agent
s to schedule meetings, using two different
migration patterns: the
Sequence

and the
SplitJoin
. The calendar agent implementation using
the
Sequence

pattern has a single agent visiting all participants
CalendarServers

in the order
mentioned in the itinerar
y. The second implementation uses a group of agents, one agent to visit each
participant's calendar server. This is achieved using the
SplitJoin

pattern.


A calendar agent is created with a list of possible options for meeting times. This is encapsulated
in the
agent as an object called
Briefcase
, which is a list of choices (
CalendarEvents
). The agent
first visits all servers to check for conflicts for each of the choices. If there is a conflict in the timing of
a
CalendarEvent

in the
Briefcase

with that
of current server database then that
CalendarEvent

in the Briefcase is marked as,
busy
. At the end of the first round if all the
CalendarEvents

in the Briefcase are marked as
busy,

then there is no choice suited for the
meeting. Else, if at the end of the

first round it finds at least one choice when none of the participants
have a conflict, it revisits them again to insert an event in each participant's calendar database.


A
CalendarAgent

implements four public methods:
checkConflict
,
schedule
,
arrive
,
a
nd
depart
. The
checkConflict
() method is executed at a CalendarServer of a participant to
check if there are any conflicts with the participant's schedule and the requested timings. This is done
by calling the
checkConflictingEvent

method of the
CalendarD
atabase

of that
participant. The schedule method is executed at the participant's
CalendarServer

to insert an
event in the server's database. This is done by calling the
scheduleEvent

method of the
CalendarDatabase

object through a proxy.


5.3.1.

Sequence Based
Design

The
CalendarAgent

that uses the
Sequence

pattern extends the
ItinAgent

class. It is
created with a list of possible options for meeting times. This is encapsulated in the agent as an object
called
Briefcase
, which is a list of choices. This
Briefcas
e

is set by the agent launcher by
reading the request file specified as the command line argument to agent launcher. In this
implementation of calendar agent,
arrive

and
depart

methods defined in the
ItinAgent

class


18

is overridden.
arrive

method obtains a r
eference to the calendar database object of the server using
the
getResource

primitive. Depending upon whether it is first phase (check conflict) or second
phase (schedule), agent execute
checkConflict

or
schedule

method at the server respectively.
depart

method uses a local flag
firstRound

to check if the first round for checking conflicts is
over. If so, it resets the itinerary to execute the second round of visit by the agent to schedule event;
otherwise it executes the next method of the itinerary.
Figure
8

shows implementation details for
CalendarAgent.













Figure
8

Calendar Agent Implementation using Sequence Pattern

5.3.2.

Split
-
Join Based Design

In the implementation using the
SplitJoin

pattern, t
he calendar agent creates child agents to visit
public class CalendarAgent extends ItinAgent {


protected Briefcase briefcase;


private transient Calendar calendar;


private boolean firstRound = true;



public CalendarAgent (Credentials cred, Itinerary itin, Vector eventChoices) {



super (cred, itin);


briefcase = eventChoices;


}


public void arrive () {


URN calendarURN = new URN (host.getHostURN().toString() + "/CalendarDB");


calendar = (Calendar) host.getResource (calendarURN);


}


public

void depart () {


if (!itin.done()) {




int status = itin.next (host);




if ((status == DONE) && (firstRound)) {


firstRound = false;


// Check for non
-
conflicting event, if such an event is found, reset
the


// itinerary to schedule the event at each participant's calendar server


}


}


}


public void checkConflict () {


// Check for events in the calendar database conflicting with the choices


}


p
ublic void schedule () {


calendar.ScheduleEvent ((CalendarEvent) briefcase.firstElement());


}

}



19

each participant's server and check for conflicts in parallel. Each child is given the parent's
Briefcase

of choices for meeting times. After visiting the designated server, a child agent returns
to the pare
nt agent's host and reports back data on conflicts. The calendar agent using the
SplitJoin

pattern is extended from the
JoinableAgent

class. In our example implementation,
CalendarSplitJoinAll

(shown in
Figure
9
) pattern is define
d by extending from
SplitJoinAll
. We needed an extension of the generic
SplitJoinAll

pattern to implement
the method
setAgentResource

so that parent could pass its resources, in this case its briefcase,
to the child agents as needed. The
CalendarAgent

cl
ass is defined by extending the
Joinable

agent class.











Figure
9

Calendar SplitJoin Pattern Implementation

This class implements five public methods:
checkConflict
,
schedule
,
actionOnArrive
,
actionOnJoin
,
actionBeforeJoin

and
createItinerary
. Method
checkConflict

and
schedule

was described in the section
5.3
. Agent on arriving at server
executes
actionOnArrive
, which obtains and set agent’s calendar database proxy. The calendar
agent's itinerar
y is created by executing
createItinerary

method. Itinerary contains two
SplitJoinAll

patterns. The first one assigns the method
checkConflict

to be executed at
each of the servers; the second pattern executes the
schedule

method. When one of these pattern
s
is executed (by invoking its next method). Agent creates child agents, directing each child agent to visit
a server and then migrate back to the parent to join with. When the method
next

of this itinerary is
called, the first split
-
join pattern is execut
ed and it creates child agents to check for conflicts. On
creating a child agent, the parent's
Briefcase

is passed to it by calling
setResource

method.
After child agent has checked for the conflict it returns to the parent agent and execute its
actionBefo
reJoin
, which merges child agent
Briefcase

with that of parent agent. Upon
joining of all the child agents, the parent has the complete conflict list of all the participants. In
actionOnJoin

parent agent chooses a non
-
conflicting choice, if there is one, a
nd sets up its
briefcase for next phase for scheduling. If no empty slot found, the parent raises an exception and
aborts the next phase. In the next
SplitJoin

pattern, child agents are created and dispatched to
insert an event in each participant’s calend
ar database.
Figure
10

shows implementation of
CalendarAgent with SplitJoin Pattern.


public class CalendarSplitJoinAll extends SplitJoinAll {


public void setAgentResource(ItinAgent agent, ItinAgent parent ) {


// Parent agent's briefcase is passe
d to child agents.


(CalendarAgent)agent).briefcase = ((CalendarAgent)parent).briefcase;


}

}




20













Figure
10

Calendar Agent with SplitJoin Pattern Implementation

6. Conclusions and Future Work

We have desc
ribed Ajanta programming environment and how it is used to build three agents based
distributed systems. These systems test, evaluate and demonstrate the capabilities of Ajanta’
programming modal, APIs and security architecture. Distributed file access sys
tem allows other users’
agents to access a subset of his/her file. It tests the capabilities of Ajanta security architecture. It brings
forth several interesting security issues. Ajanta security manager and authentication in agent transfer
protocol also ev
olved along with the development of distributed file access system. Global file system
exercise Ajanta architectural paradigm to build a distributed system, requiring distributed coordination
public class CalendarAgent extends JoinableAgent {


public Briefcase briefcase;


private transient Calendar cal;


public CalendarAgen
t (Credentials cred, Itinerary itin) {


super (cred, itin);


briefcase = new Briefcase();


}


public void actionOnArrive () {


// Agent gets a reference to the server's calendar database


}


protected void createItinerar
y () {


// Creats an itinerary with two SplitJoinAll patterns.


// First pattern will create agents to check for conflicts at each server.


// Second one will create agents to schedule if a free timeslot is found.


}


public voi
d checkConflict () {


// Check conflicting events in the agent's briefcase against the server's calander.


}


public synchronized void actionBeforeJoin(Agent ag) {


// When a child agent returns and joins, parent's briefcase is updat
ed with acquired
info.


}


public void actionOnJoin() {


// After all children return, a new briefcase for the parent is set with the


// First non
-
conflicting event. In case of no such event, an exception is thrown.

}

public void sch
edule() {


// Insert in the server’s database the event in the agent’s briefcase.

}

}



21

and control. It allows an agent to open a remote file and access

it like a local file. It also laid out
foundation for studying agent
-
group management and coordination. Distributed calendar manager
maintains users’ appointment schedule and provides primitives to schedule appointments using agents.
It demonstrates how d
ifferent migration patterns can be used to achieve the same result and to
simplify the task of creating complex itineraries. SplitJoin patterns allows it to parallelize the task of
scheduling at multiple servers. We implemented global file system at experi
mental level for AFS
(Andrew File System) policy for file access synchronization and extending this to support other file
system policies will require further study. We would also like to analyze the trade off involved with
various consistency policies and

cache model (distributed or centralized). We would also like to
enhance the security feature of distributed calendar manager.






















22

BIBLIOGRAPHY

[1] Colin G. Harrison, David M.
Chess, and Aaron Kershenbaum.
Mobile Agents: Are they a good
ide
a? Technical report, IBM
Research Division, T.J.Watson
Research Center, March 1995.
Available at URL
http://www.research.ibm.com/massdis
t/mobag.ps.


[2] Eric Jul, Henry Levy, Norman
Hutchinson, and Andrew Black. Fine
-
Grained Mobility in the Emerald
System.

ACM Transactions on
Computer Systems, 6(1):109
-
133,
February 1988.


[3] Eliezer Levy and Abraham
Silberschatz. Distributed File
Systems: Concepts and Examples. ACM
Computing Surveys, pages 321
-
374,
December 1990.


[4] R. Moats. RFC 2141: URN Syntax.
Avail
able at URL
http://www.cis.ohiostate.edu/htbin/
rfc/rfc2141.html, May 1997.


[5] Karen Sollins and Larry
Masinter. RFC 1737: Functional
Requirements for Uniform Resource
Names. Available at URL
http://www.cis.ohiostate.edu/htbin/
rfc/rfc1737.html, December 1
994.


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





[7] Bruce Schneier. Applied Cryptogra
phy.
John Wiley, 2
nd

edition, 1996


3





4