AN AIRLINE RESERVATION SYSTEM USING MOBILE AGENTS

A Project

Presented to

The Graduating Committee, Department of Computer Science

Lamar University

In Partial Fulfillment

Of the Requirements for the Degree

Master of Science in Computer Science

by

Prabhu, Balkrishna

Date

(April, 2003)

2

AN AIRLINE RESERVATION SYSTEM USING MOBILE AGENTS

by Prabhu, Balkrishna Approved: ___________________________________

(Dr. Lawrence Osborne) Supervising Professor ____________________________________ (Dr. David Read)

Committee Member ___________________________________

(Dr. Hikyoo Koh) Committee Member

_________________________________ (Dr. Lawrence Osborne) Chair, Department of Computer Science

3

Abstract The project I have tried to undertake involves the effort to understand mobile agents and

explore their properties with the intention of utilizing them to develop new functionalities

and using these new functionalities to bolster the airline reservation system. The airline

reservation system primarily consists of getting mobile agents entrusted with the task to

carry out the request of an end user, considering the specifications of that user. I am sure

this project shall portray most if not all properties of mobile agents including, dispatching

to contexts of remote host, carrying out an operation on the remote host, message passing

between agents and most importantly their interaction with the web server engine.

The interaction of mobile agents (aglets) with Servlets is to the best of my knowledge not

been done before. The interface currently available is the Fiji Applet which allows firing

of a mobile agent from outside the context. I have decided to use a web interface instead

of the Fiji Applet since not every end user can have that interface readily available to

him. The web interface I am attempting to provide though is readily available to every

user since it just involves a web browser commonly available to all.

The project should also be able to demonstrate mobile agents in parallel execution over

remote competing database servers each passing best results available on that server to

the home node.

4

Acknowledgement I would like to extend my gratefulness to Dr. Lawrence Osborne for his invaluable

guidance from time to time, and for having faith in me and letting me extend my project

to the current semester. He gave my uncertain mind a true sense of direction.

I would also like to emphasize my respect and gratitude to Dr. David Read and Dr.

Hikyooh Koh under whom I learnt most of my courses through my degree.

My heartfelt obligation also extends out to Dr. Peggy Doerschuk, Dr. Zhang, Dr. Tran,

and Mr. Foreman under whom I took all my remaining courses.

This project however, would not be possible without the love and blessings of my parents

who supported me through what were some highly testing times for me.

Last but not least, I humbly pray and thank to the presence of the almighty for showing

me the light.

5

Table of Contents 1. Introduction 6

1.1 Introduction 6 1.2 Purpose and Function of the Project 12 1.3 What computer science principles and technologies were used and why 13 1.4 The Aglet Standard Development Kit specification 15 1.5 Airline Reservation System 36 2. Methodology, Security factors and other competing technologies 38

2.1 Architecture 39 2.2 Scenarios and Implementation 45 2.3 Design of software 50

2.3.1 Use Case diagram 51 2.3.2 Sequence Diagram 52 2.3.3 UML collaboration diagram 54 2.3.4 Activity Diagram 56 2.3.5 List of Classes and Class Diagram 58

2.4 Software testing 66 2.5 Security 67

2.5.1 Security among agents 67 2.5.2 Security between user and Client Host 73 2.5.3 Security between Client Host and Database Server Hosts 74

2.6 Other competing technologies and advantages of Mobile agent system 76 2.6.1 RMI 76 2.6.2 Java XML RPC 76

3. Conclusions and Suggestion for Future work 77

3.1 Results and Conclusions 78 3.2 Other possible areas for implementing mobile agents 79 3.3 Scope of future work. 79 3.4 Problems faced in programming and other coding subtleties 81 involving aglets

4. Bibliography and references 82 Appendix I Source Code Appendix II Database table structure on Client and Server Appendix III User Guide

6

Section I: Introduction

7

1.1 Introduction Mobile Agents have changed and effected the world of distributed computing in a unique

way. Mobile Agents in short, are executable class files which can visit new hosts and

carry out execution in a remote context, pass messages between each other, create and

spawn new agents from a referenced code-base, and carry out specified tasks over a given

duration. Thus in effect mobile agents are �role players� carrying out designated tasks at

specified target hosts and perhaps returning back to the host with the results of the said

execution or even passing results to the original host and then either disposing or moving

to a new host context to resume execution there. The advantages here over other

conventional technologies of computing are obviously the movement of the code itself to

a specified host rather than execution of a pre-existent code there, as in remote method

invocation (RMI). It is thus safe to say that mobile agents have given the world of

ubiquitous computing a totally new dimension. Also, in this context two terms that are of

high relevance are �Mobility� and �Mobile Computing�. Though seemingly similar there

is a subtle difference in terms as described below.

Mobility Mobility as we refer to is a term used to signify the procedure of process migration.

Process Migration is defined plainly, as the transference of a currently executing process

from one computer processor to another. The procedure involved though, is thoroughly

complex and intricate since it involves movement of an operating system abstraction

involving the code, data and state associated with a running application.

8

Mobile Computing

This involves the physical movement of computers from within or outside a network.

Hence there arises a scenario of �weak connectivity� which involves a computer getting

disconnected often from the network and then getting intermittently connected at the

same physical point on the network or another physical point within or outside the

network. Another aspect deals with wireless connection, during which a computer moves

between �cells� in a wireless network.

Both mobility and mobile computing complement each other, though the following

discussion shall lay more emphasis on the principles of mobility and understanding the

principal tool enforcing mobility � Mobile Agents.

As mentioned earlier mobility involves process migration. The efficacy of process

migration is exacted from knowing its advantages, which are:

1. Load Distribution. If a given host (node) gets suddenly overloaded, then some of

the processes could migrate to another host having lesser load by virtue of fewer

processes running there thus enabling system stability and enhancing performance

by quicker execution of existing processes.

2. Fault resilience. By enabling a process to move from faulty machines or hosts

which need to be shut down for maintenance or otherwise. This is a very

common occurrence and thus instead of restarting the process from the beginning

the process could get to a new context and start executing from where it had left

off.

9

3. Data Access Locality. This quite simply means taking the code to the data instead

of executing it remotely. Locality can provide significant performance gains. For

example, if a process needs to make a series of queries to a database, it makes

sense to move the client code to the database itself which would reduce the access

time and reduced network traffic, which wouldn�t be the case if the queries were

made remotely.

Process migration per se, can be broadly categorized as either strong migration or weak

migration.

Strong migration involves ability of a system to migrate code and execution state of a

process currently under execution. This involves saving of different attributes of a

process at the point it wants to migrate like registers, program counters, current memory

and address space associated and then migrating the state along with the code itself so

that execution can resume on the new host context from where it left off. This process of

saving state is referred to as �checkpointing�.

Weak migration involves just migration of code, thus there is no need to save state of the

process in one host as it gets ready to move to the other. When in the new context, the

process shall start over from the beginning, for example applets.

�A mobile agent is a software object that has the ability to interact with the execution

environment and among other entities of its types with the ability to act upon it

asynchronously�(Dejan Milojicic et al). An agent thus is a goal driven entity with the

ability to take decisions for it self, doing tasks for its user autonomously.

10

Mobile agents have the following mandatory properties:

1. Reactive � sensing change in the environment and act accordingly to those changes;

2. Autonomous � has control over its own actions;

3. Goal driven � is proactive and works toward the objective it was created for;

4. Temporally continuous � ability to be continuously executing;

5. Communicative � ability to communicate with other agents;

6. Mobile � can move from one host to the other;

7. Learning � adapts in accordance with previous experience.

Agents that do not move about from one context to another, but that may be involved in

communicating with remote mobile agents or some other objective are referred to as

stationary agents.

Advantages of using mobile agents:

1. Reduce load on the network. In a distributed computing environment, a task

would involve multiple transactions between and to and fro from the client to the

server. This definitely results in lots of traffic in the network. Mobile agents

involve the moving of the code itself to the data and carrying out execution at the

context holding the data and then just passing back the results, thus reducing the

network traffic effectively.

2. Overcome network latency. Real time systems like robots and airplanes which

need to do certain actions with accuracy anywhere between the millisecond to the

microsecond cannot tolerate network latency. Hence mobile agents provide an

11

adequate system where computation is local rather than being effected from a

remote host.

3. Encapsulate protocols. When data is exchanged between hosts in a distributed

system, each host owns the code that implements the protocol needed to code

outgoing data and interpret incoming data. With security risks these protocols

become very cumbersome. Mobile agents on the other hand, establish channels

based on proprietary protocols.

4. Asynchronously executing and autonomous. Mobile devices such as laptops and

PDA�s are often on expensive or weak network connections hence feasibility of

tasks requiring sustained connection over a large duration become questionable.

Mobile agents however can carry out the specified task autonomously and then

send back results to the user when he reconnects to the network.

5. Adapt dynamically. Mobile agents can sense changes in their execution

environment, for example increased loads on the processor and then react to it by

moving to another context itself or sending a clone object to a remote context to

carry out the specified task and send results back to wherever desired.

6. Naturally heterogeneous. Mobile agents are transport layer and execution

environment independent and thus enable system integration to a large scale.

7. Robust and fault tolerant. The ability of mobile agents to react dynamically to

unfavorable situations and events makes it easier to build robust and fault-tolerant

distributed systems. If a host is being shut down, all agents executing there will

be warned and given time to dispatch and resume execution on another host on

the network.

12

1.2 Purpose and Function of the Project

The purpose of the project was the need to conceptualize an application which would

involve the effective use of mobile agents, emphasizing their different aspects,

functionalities and their interaction with other technologies. I decided to develop an

ecommerce based application where a user would want to perform a certain task and

entrust it to a mobile agent, which in turn would give him back all the best possible

results. I also wanted to emphasize the manner in which mobile agents could interact

with other technologies namely, HTML and Servlets on the user side, agent environment

as the middle tier between the client and the server and MySQL database on the server

side. I also wanted to show how results sent back to the user can be updated in a dynamic

environment as in changes in prices occurring suddenly due to various factors and hence

give the end user a view of the best possible alternatives available to him at any given

instant. This would also illustrate how a user could submit his request and disconnect

and connect at a later time to see the options available to him delivered by mobile agent

querying his request on his behalf. Another important aspect would be the demonstration

of agent persistence in the remote context for a specified amount of time to carry out the

given task. For all reasons mentioned above, I came up with the idea of the Mobile agent

based airline reservation project which could clearly demonstrate the most important

properties of mobile agents including their interaction with web-based technology and

databases.

13

1.3 What technology is being used and why

Most of the technology used is Java based. I chose Java because of obvious reasons. The

Java Virtual Machine enables code portability and operating system independence. Java

doesn�t use pointers and is particularly important in this case where mobile agents travel

to remote hosts and carry out execution there. Use of pointers as in C or C++ is out of

question here, since malicious agents can create havoc on remote computers through

accessing critical data in memory.

The Aglet software development kit (ASDK) implementing aglets, uses Java and is the

primary reason I used aglets. ASDK was developed by Danny B. Lange and Mitsuru

Oshima at IBM�s Tokyo research lab. It has an open source code and the current version

is bug free. I decided to use their basic skeleton as my middle tier and append my own

architecture by adding functionalities and API�s to it in order to implement the airline

reservation system.

The other agent systems enlisted on page 79, mostly use languages other than Java and

not just as popular.

The Database servers use MYSQL and Oracle and the Client host uses Tomcat Apache

Servlet engine which can be accessed using JDBC/ODBC and are Java compliant.

14

Why is the use of mobile agent necessitated?

1. Once the client (user) gives his request he can log off and stay disconnected. The

mobile agents will pass on the results to the client once he is logged back on. The

results brought back by the mobile agent shall be written to a log file for

reference.

2. Mobile agents give the ability to process multiple requests from different users.

Hence local agent A can be interacting with mobile agent m1 even as local agent

B is interacting with mobile agent m2. This shall be taken care of by a scheduling

algorithm.

3. Mobile agent can stay in the agent environment for a specified time which can be

important as the deal it may want may be blocked for a certain amount of time by

some other agent, but may get released in which case it shall grab the deal.

4. Even after a deal is finalized a copy of the mobile agent can stay in the agent

environment to monitor any changes in flight schedule or if the flight gets

cancelled to intimate the client as soon as such a change occurs.

15

1.4 Description and Specification of the Aglet Software Development Kit (ASDK)

The Aglet Object Model

The Aglet API defines the fundamental functionality of mobile agents. The following

figure shows the major interfaces and classes defined in the Aglet API and the

relationship between these interfaces.

Figure 1

com.ibm.aglet.Aglet The Aglet abstract class defines the fundamental methods (for example, dispatch(URL))

used to control the mobility and life cycles of mobile agents. All mobile agents defined in

Aglet have to extend this abstract class. The Aglet.dispatch(URL) primitive causes an

aglet to move from the local machine to the destination specified as its argument. The

Aglet.deactivate(long time) primitive allows an aglet to be stored in secondary storage,

and the Aglet.clone() primitive spawns a new instance of the aglet that has the same state

as the original aglet. Note that the object returned by the clone primitive is not an Aglet

object but an AgletProxy object.

Aglet Proxy

Aglet Proxy MessageAglet Aglet

Aglet Context

16

The Aglet class is also used to access the attributes associated with an aglet. The

com.ibm.aglet.AgletInfo object, which can be obtained by the Aglet.getAgletInfo()

primitive, contains an aglet's inherent attributes, such as its creation time and codebase,

as well as its dynamic attributes, such as its arrival time and the address of its current

context.

The following table shows some primary methods and their semantics. Method Behavior dispose() Dispose of the aglet. dispatch(URL) Dispatch the aglet to the destination specified in the URL.deactivate(long duration) Instruct the aglet to store itself into a persistent medium. getAgletInfo() Get information on the aglet com.ibm.aglet.AgletID

All aglet instances have their own unique identities that are immutable throughout the life

cycle of the aglet. An identity may consist of several attributes such as a user's id, the

type of an agent system, and some large number. The AgletID is an object that keeps a

unique identifier for the given agent, while encapsulating its representation details.

com.ibm.aglet.AgletProxy

The AgletProxy interface object acts as a handle of an aglet and provides a common way

of accessing the aglet behind it. Since an aglet class has several public methods that

should not be accessed directly from other aglets for security reasons, any aglet that

wants to communicate with other aglets has to first obtain the proxy object, and then

interact through this interface. In other words, the aglet proxy acts as a shield object that

protects an agent from malicious agents. When invoked, the proxy object consults the

Security Manager to determine whether the caller is permitted to perform the method.

17

Another important role of the AgletProxy interface is to provide the aglet with location

transparency. If the actual aglet resides at a remote host, it forwards the requests to the

remote host and returns the result to the local host.

The AgletProxy can be obtained in the following ways:

1. Get an enumeration of proxies in a context by calling the primitive

2. AgletContext.getAgletProxies().

3. Get an AgletProxy for a given AgletID via either

4. AgletContext.getAgletProxy(AgletID) or Aglets.getAgletProxy(String contextName,

AgletID).

Get an AgletProxy object by message passing. An AgletProxy object can be put into the

Message object as an argument, and sent to the aglet locally or remotely.

Put an AgletProxy object into the context-property by

AgletContext.setProperty(String,Object), and share the proxy object.

The runtime library is responsible for providing the implementation of the AgletProxy

interface; thus, aglet programmers do not have to implement this interface.

com.ibm.aglet.AgletContext

The AgletContext class provides an interface to the runtime environment that occupies

the aglet. Any aglet can obtain a reference to its current AgletContext object via the

Aglet.getAgletContext() primitive, and use it to obtain local information such as the

address of the hosting context and the enumeration of AgletProxies, or to create a new

aglet in the context. Once the aglet has been dispatched, the context object currently

occupied is no longer available, and the destination context object is attached instead

when arrived.

18

The runtime library is responsible for providing the implementation of this interface;

thus, aglet programmers do hot have to implement this interface.

com.ibm.aglet.Message

Aglet objects communicate by exchanging objects of the Message class. A message

object has a String object to specify the kind of the message and arbitrary objects as

arguments. A message can be sent to the aglet by calling Object

AgletProxy.sendMessage(Message msg) , FutureReply

AgletProxy.sendAsyncMessage(Message msg) , or void

AgletProxy.sendOnewayMessage(Message msg) and it is passed as an argument to

Aglet.handleMessage(Message msg).

com.ibm.aglet.Ticket

A Ticket object is used to specify both of a destination and a quality of transfer. In other

words, it defines the way in which an aglet is transferred. It may include the destination,

the protocol to be used, and quality such as timeout, the level of integrity or

confidentiality that must be secured. This object is used where URL were used as the way

to specify the destination.

com.ibm.aglet.FutureReply

An object of the FutureReply interface is returned by the asynchronous message-passing

and used as a placeholder to receive the result later asynchronously. With this interface,

the receiver can determine whether a reply is available, and can wait for the result with a

19

specified timeout value so that it can continue its execution if a reply was not returned

within the specified time.

In the following sections, we shall see more classes and interfaces that allow you to

control the activities of an aglet.

Extending the Aglet class

Here are general guidelines for defining a subclass of the abstract Aglet class.

A user-defined Aglet class extends the com.ibm.aglet.Aglet class.

It can extend another Aglet implementation class. It may also implement a

java.io.Externalizable interface to customize the serialization process of the aglet. But

you need to call super.writeExternal and super.readExternal to properly

serialize/deserialize the state defines in the Aglet class. It cannot override pre-defined

Aglet API methods, such as dispatch() and getAgletContext() since these are declared to

be final.

Unlike normal Java objects, it should not implement a constructor to initialize the objects

because the instance of the Aglet class is initialized after this instantiation. You should

use onCreation method instead.

If it implements java.io.Externalizable, the public constructor without arguments would

be needed to successfully deserialize the object. In addition, the constructor should not

have any side effects because the constructor is called every time the deserialization is

taken place.

20

The following methods of the Aglet class are supposed to be overridden by a subclass to

allow an aglet to implement its own specific behavior:

void Aglet.onCreation(Object init)

This method is called only once during its lifecycle, when it is created. Aglet

programmers have to use onCreation(Object init) to initialize an aglet, because the Aglet

API (e.g. dispatch(URL)) is not ready in the constructor.

void Aglet.onDisposing()

This method is called just after the dispose() method is called. The aglet should release

any resources previously allocated. It can perform additional actions in response to its

own disposal.

void Aglet.run()

The run() method in the Aglet class is called whenever an instance is created or resumed.

Because this method is called whenever it occupies the context, this is a good place to

define the common task.

boolean Aglet.handleMessage(Message msg);

All messages sent to the aglet are passed to the handleMessage method. Aglet

programmers can check whether the incoming message is a known message, and can

perform the task according to the kind of message.

21

public class HelloAglet extends Aglet {

public void onCreation(Object init) {

System.out.println("created!");

}

public void run() {

System.out.println("hello!");

}

public boolean handleMessage(Message msg) {

if (msg.sameKind("sayHelloAgain") {

System.out.println("hello!");

return true;

}

return false;

}

public void onDisposing() {

System.out.println("bye!");

}

}

22

Aglet Object and Its Life Cycle

The com.ibm.aglet.Aglet class provides the basic functionality for a mobile object, and

every aglet (aglet objects) has to be an instance of a subclass of it. To use an aglet, you

first have to instantiate it. There are two ways to create a new instance of an aglet. The

first is to instantiate a completely new aglet from class definitions by calling

AgletContext.createAglet(URL codebase, String name, Object init). This primitive

creates a new instance within the specified context and initializes it if necessary, then

invokes Aglet.onCreation(Object init) on the created object along with the initializer

object passed to the createAglet primitive. The other way is to create a copy of an

existing aglet by using the Aglet.clone() primitive. The cloned aglet has the same state as

the original one but has a different AgletID object, and thus a distinct identity.

Once created, an aglet object can be dispatched to and/or retracted from a remote server,

deactivated and placed in secondary storage, then activated later.

Figure 2

An aglet can dispatch itself to a remote server by calling the Aglet.dispatch(URL dest)

primitive. To be more precise, an aglet occupies the aglet context and can move from this

context to others during its execution. Because the server may serve multiple contexts

23

within one Java VM, and one host may serve multiple servers in one host the context are

named as the following set:

1. The address of the host, typically IP-address.

2. The port number to which the server is listening.

3. The name of context within the server.

Example: atp://aglets.ibm.com:1434/context_name

Dispatching causes an aglet to suspend its execution, serialize its internal state and

bytecode into the standard form and then to be transported to the destination. On the

receiver side, the Java object is reconstructed according to the data received from the

origin, and a new thread is assigned and executed.

Aglets can be persistent. Since a mobile aglet needs to be serializable into a bit-stream,

all mobile aglet can be persistent in nature. The Aglet.deactivate(long timeout) primitive

causes an aglet to be stored in secondary storage and to sleep for a specified number of

milliseconds. After the given time has passed or another program has requested its

activation, the aglet is activated within the same context where as that in which it was

deactivated.

Unlike normal Java objects, which are automatically released by garbage collector, an

aglet object, since it is active, can decide whether or not to die. If you call the dispose()

method to kill the aglet, onDisposing() is called to perform the finalization suitable for

the current state of the aglet. (Note that this is different from Java's finalizer(), which is

invoked when the object is garbage-collected.) Aglet programmers are responsible for

releasing allocated resources such as file descriptors or DB connections, because these

may not be released automatically. Once disposed of, the instance becomes an invalid

24

entity, and any attempt to operate it will result in a Security Exception. (This may be

replaced with another Exception class).

Aglet Events and Delegation Event Model

Java VM does not allow stack frames to be stored or a thread object to be resumed from

them. It is impossible for a thread object to migrate from one JVM to another while

preserving its execution state. Instead, Aglets uses an event model to give programmers a

way of implementing an action that emulates the migration. When an aglet dispatches,

the Aglet runtime system issues the corresponding event to notify the aglet that it is being

dispatched, or that it is arriving at the destination.

Figure 3

For example, the following code fragment defines the MyListener class, which

implements the MobilityListener interface, and MyAglet, which extends the Aglet class.

import com.ibm.aglet.Aglet;

import com.ibm.aglet.event.MobilityEvent;

import com.ibm.aglet.event.MobilityListener;

class MyListener implements MobilityListener {

public void onDispatching(MobilityEvent l) {

25

closeWindow();

closeFile();

}

public void onReverting(MobilityEvent l) {

openWindow();

donNextJob();

}

public void onArrival(MobilityEvent l) {

}

}

public class MyAglet extends Aglet {

public void onCreation(Object init) {

MobilityListener listener = new MyListener();

addMobilityListener(listener);

}

}

The onDispatching() method of the MyListener object is called before an aglet is actually

dispatched, and the onArrival() method is called after it arrives at its destination. If an

aglet has multiple listeners, they are called in the order in which they were attached. In

this way, an aglet programmer can implement an action such as onDispatching that

should be taken in response to the following events, regardless of when or by whom an

aglet is dispatched.

26

When Event Object Listener Method called Just before cloning CloneEvent CloneListener onCloning When clone is created CloneEvent CloneListener onClone After creation of clone CloneEvent CloneListener onCloned Just before dispatch MobilityEvent MobilityListener onDispatching Just before retraction MobilityEvent MobilityListener onReverting After arrival at the destination MobilityEvent MobilityListener onArrival Just before deactivation PersistencyEvent PersistencyListener onDeactivating After activation PersistencyEvent PersistencyListener onActivation

More than one listener objects can be added. Complex tasks can be divided into multiple

listeners so that some of them can be reused by other aglets. For example, the following

code fragments define the Updater class, which updates the information on its location

registered in a RegistryAglet. Since this listener object is pluggable, it can be added at

runtime and used for any aglets.

public class Updater extends MobilityAdapter {

One thing programmers should bear in mind is that these listener objects are called in

sequence. Therefore, the listener object being added last may not be called, depending on

the behavior of the former listeners. For example, if a listener object disposes of the aglet

in the onArrival, subsequent listeners are never invoked.

Note that these event callbacks are also queued and processed one by one. You may not

receive them until the current message handling is completed. See the section "Messaging

in Aglets" for more details.

27

Object Mobility

Serializing an Aglet Object

When an aglet is dispatched, cloned, or deactivated, it is marshaled into a byte array, then

unmarshaled from it later. Aglets use the standard Java ObjectSerialization mechanism to

marshal and unmarshal an aglet. While the serialization is being executed, all objects

within the object-graph starting from an aglet instance are regarded as its state to be

marshaled. Therefore, these objects need to implement the java.io.Serializable interface

or java.io.Externalizable interface, or else they must be referenced as transient. If a non-

serializable object is found in the object graph, it results in a

java.io.NotSerializableException being thrown.

class ListingAglet extends Aglet {

// result and its contents are transferred.

private Vector result = new Vector();

transient InputStream in = new InputStream(); // will not be transferred

}

Objects Moved by Value

Through the serialization/deserialization process, ordinary objects that are a part of its

state are moved by value. One of the consequences of this is that once serialized, an

object shared by multiple aglets is copied and is no longer shared after the dispatch,

clone and deactivate/activate operations.

28

Objects Moved by References

When an aglet proxy is transferred, on the other hand, it keeps the aglet id and its address,

and uses that information to restore the correct reference to the original aglet. Therefore,

AgletProxy objects can keep the reference to the actual aglet even if the proxy is

transferred to a remote host or deactivated, as long as the aglet resides at the same

location.

class Transferrable implements java.io.Serializable {

Hashtable hash; // Hashtable is also serializable

}

class NotTransferrable {

int dummy;

}

class MyClass extends Aglet {

transient FileDescriptor fd; // never get transferred.

int value; // moved by value

String str; // moved by value

Object transferable = new Transferrable(); // move by value

Object not_transferable = new NonTransferable(); // throws

NotSerializableException.

AgletProxy proxy; // moved by reference

}

29

Class Variables

Since a class variable is not a part of an object, the values of class variables are never

serialized. Thus, class variables are local to their class, and the aglet may obtain a

different value when it arrives at a new destination.

public class MyAglet {

static int class_variable = 0;

public void onCreation(Object init) {

class_variable = 10;

dispatch("atp://next.place");

}

public void run() {

if (class_variable != 10) {

System.out.println("Class variable never get transferred!");

}

}

}

Transferring RMI Objects

The remote interface of RMI is used to define remote objects whose methods can be

invoked remotely. A client-side RMI object (stub) works well with the Aglets library

without modification. That is, when an aglet is dispatched along with a remote object, the

remote object is automatically rebound to the server object when the aglet is

unmarshaled.

30

However, Aglets cannot handle server objects. Transfer of an RMI server object results in

the creation of another copy of the server object at the destination site.

public class MyAglet extends Aglet {

RMIHelloImpl impl = new RMIHelloImpl();

String naming = "//naming.com/hello";

public void onCreation(Object init) {

java.rmi.Naming.rebind(naming, impl);

addMobilityListener(new MobilityAdapter() {

void onArrival(MobilityEvent ev) {

java.rmi.Naming.rebind(naming, impl);

impl.hello(); // calling local method

// It cannot be Stub anyway because it's impl!

}

});

}

}

This is a limitation of RMI in JDK1.1. (Note: JDK1.2 supports "unexporting" of a remote

object, which solves the above problem.)

31

Implementing writeObject/readObject Methods

Aglet programmers who want to customize writeObject/readObject methods on

serializable objects should be aware that onDispatching() is called while the aglet is

running, while writeObject() is called after the aglet has been suspended. Similarly,

readObject() is called while the aglet is being unmarshaled, which means that Aglet

primitives such as getAgletContext() do not work. On the other hand, onArrival() is

called after the entire aglet has been restored and activated successfully, so you can call

the Aglet API.

Proxy Object Whose Aglet Has Been Dispatched

Currently, the AgletProxy cannot keep track of roaming aglets. Once an aglet has been

dispatched, the proxy previously referencing the aglet is no longer valid.

Messaging in Aglets

An application or aglets can communicate with other aglets by message passing. An aglet

that wants to communicate with another aglet first has to create a message object, then

send it to the target aglet. A message object has a kind and an optional argument object.

The receiver aglet determine what to do by checking the kind of received message and

get parameters as the argument object in the Aglet.handleMessage() method.

MyAglet extends Aglet {

public boolean handleMessage(Message msg) {

if (msg.sameKind("doJob")) {

doJob();

32

} else if (msg.sameKind("shutdown")) {

deactivate(0);

}

}

}

Aglets supports the following types of message passing:

Now-type: AgletProxy.sendMessage(Message msg)

A now-type message is synchronous and blocks the current execution until the receiver

has completed the handling of the message.

String answer = proxy.sendMessage(new Message("question"));

System.out.println(answer);

Future-type: AgletProxy.sendAsyncMessage(Message msg)

A future-type message is asynchronous and does not block the current execution. The

method returns a FutureReply object, which can be used to obtain the result or wait for

the argument later.

FutureReply future =

proxy.sendAsyncMessage(new Message("question"));

int num_task = 10;

// do private job at most 10 times while waiting for the result.

while(future.isAvailable() == false && num_task-- >0) {

doPrivateJob();

}

System.out.println( (String)future.getReply() );

33

Note: If an aglet sends a message to itself, the message is not put at the tail of the queue.

Instead, it is placed at the head of the queue and executed immediately, to avoid

deadlock.

Oneway-type: AgletProxy.sendOnewayMessage(Message msg)

A oneway-type message is asynchronous and does not block the current execution. It

differs from a future-type message in the way it is placed at the tail of the queue even if it

is sent to the aglet itself.

proxy.sendOnewayMessage(new Message("question"));

Delegation-type: AgletProxy.delegateMessage(Message msg)

The receiver aglet has to define its handleMessage(Message msg) method to handle

incoming messages. In the handleMessage() method, a message object is passed as an

argument and can be used to perform the operation according to the kind of message. In

the method, you have to return a boolean value indicating whether it has been handled or

not.

public boolean handleMessage(Message msg) {

if (msg.sameKind("sayHello")) {

System.out.println("Hello");

return true;

}

return false; // false, otherwise

}

34

If it returns false, the sender of the message receives a NotHandledException and thus

knows that the message has not been handled. There is no way of knowing whether a

one-way message has been handled or not.

Future future = proxy.sendAsyncMessage();

try {

Object reply = future.getReply();

} catch (NotHandledException ex) {

// the receiver didn't handled the message

} catch (MessageException ex) {

// an exception has been thrown in the receiver's handleMessage()

System.out.println(ex.getException());

}

Messages in Aglets also support acknowledge-type replies, whereby the receiver can send

the reply (result) even before completing the handling of the message. When you have a

return value, you need to use this interface to return the value. Once you send a reply via

the Message.sendReply() method, you cannot send a reply again, and the return value of

handleMessage will be ignored.

public boolean handleMessage(Message msg) {

if (msg.sameKind("accessDB")) {

openDB(); // pseudo code

Object reply = accessDB(msg.getArg());

msg.sendReply(reply);

closeDB();

35

return true; // i know this message...

}

return false; // false, otherwise

}

36

1.5 The Airline Reservation System

This particular airline reservation system has been designed to provide a user more

flexibility and than ever before with regards to all options available to him in accordance

to his query. A user inputs his requirement as starting city, destination city, start date and

priority with respect to economy or a specific time of travel. Mobile agents then travel to

all the registered prospective hosts with the said query and send the user the best possible

option available, pertaining to his request type. The most important aspect, however, is

the persistence of the query in the remote database server for a specified interval. To

emphasize this, a user may want to know his best possible options before purchasing

tickets for a period of a day or even more, since in the current dynamic ticketing scenario,

prices of tickets are subject to change and the implemented interface allows the user to

view what is best in store for him. Mobile agents dedicated to his query shall get current

and updated information from the remote databases and send it to the user in almost real

time. This implementation is even more critical today with endless flight delays and time

wasted from reporting for a flight and subsequent checking in due to flight delay. Results

are updated as required on the client host and the user can log in at any time and view

what his current options are and if he comes to like any one, he could duly proceed

towards purchasing that particular deal. Though the user has access to all the options

available to him, he doesn�t have access to any of the system critical information like

where the mobile agents carrying his query are executing nor does he know where

exactly the deal he is interested in purchasing, is available. The system saves the state of

the user and all his possible options and does the purchasing as required from the

database unknown to the user. Thus the user has only access to all the information that

37

he is supposed to know, no more or no less. To use the system, the user has to be

registered and shall access the website hosted by the client host. The client host shall run

a servlet engine (Tomcat Apache) and have the resource of a local MySQL database

server.

38

Section II: Methodology, Security factors and other competing

technologies

39

2.1 The Architecture

The architecture of the system is best explained through the description of all the

components of the architecture and how they are related and work in conjunction to

enable its mechanism. I shall therefore give an apt description of each component along

with which other component it relates and then after describing each component, in the

end, I shall describe how the picture comes together.

Components of the architecture:

1. The User. Though surprising, the user forms probably one of the most important

component of the system due to uncertainties involved in choices and

complexities involved in the type of queries or request. Fine tuning the system to

incorporate each and every given choice possible from the user is the gist of the

entire system.

2. The Client Host. It is the client host that hosts the website to which a user logs in

first before submitting his request. This particular component can be divided into

sub-components:

a. The Servlet Engine. The Tomcat Apache server is responsible in creating

the execution environment for accessing local database to validate the

user�s identity, log his requests and corresponding results. Thus engine

provides a interface to create aglets entrusted with the prerogative to send

back best possible results from the remote host.

b. The Local MySQL Database. The Client host also has this database

resource available to store critical customer information, the requests

currently processing and updated results of such requests.

40

c. The Aglet Context. This is a server program on the Client side which

hosts aglet proxies which send child aglets to each of the active server

hosts on the Server side. Since this forms a part of the active Aglet

interface between the client and the various servers, it is explained more

in-depth in the following section.

3. The Aglet Interface. This is the most critical component of all since the entire

scheme is the act of hosting, creating, synchronizing, display of persistence and

messaging between aglets. This interface principally comprises of the aglet

context and the aglets themselves.

a. The aglet contexts which are located on the client and each of the

prospective servers form an environment where aglets are created,

dispatched and eventually disposed. They provide the aglet instance with

the ability to message between themselves. For example, an aglet in a

remote context can send messages to the creating proxy in the home

context (the creating context) when it is passed the creating proxy�s object

as a reference. They also provide a platform where aglets can keep

executing for sustained periods, and where they can deactivate themselves

and execute at a later time. When an aglet gets ready to be dispatched the

aglet object is serialized and sent to the remote aglet context denoted by

atp://somehost.com:portnumber. Aglet contexts can be configured to

accept http tunneling requests. Aglet contexts are configured to refer to a

default path to find the class files which represent the aglets. This path is

generally referred to as the code base. Issues dealing with code bases and

41

the corresponding java policy files are discussed in more detail in the

section concerning security. There could be more than one aglet contexts

running on the same host though each shall be supported by the same aglet

engine. Each host however shall obviously run on a different port number.

The default port number is 434, hence any new aglets being created shall

have to run on a different port number in the following manner:

agletsd �port 4444 , this shall create a new aglet context listening on port

4444. The diagram below, best describes the representation of the aglet

interface architecture

Figure 4

b. The aglets are created at a particular context and then perform further

actions such as access local resources, perform an operation, dispatch

themselves on an event or otherwise to another context which may be

located on the same local host or entirely different host, create new aglets,

HOST SERVER

Resources

Aglet Engine

Agents

Place/Context

Agents

Place/Context

Agents

Place/Context

42

pass and receive messages from other aglets and deactivate/activate

themselves. These functions render the aglets a great deal of flexibility in

carrying out operations which are more user defined. Synchronization

between aglets is another aspect which gives more sophisticated control

over efficiently implementing a networked system like the airline

reservation system proposed earlier.

4. The Database System. MySQL databases are located on the client host and each

of the server hosts. Each server host carries database relating to flight details

information and flight availability information. The client host in turn carries

information specific to the user like, customer information details, customer query

details, customer booking information and billing information.

All these four components stated above, interact in a manner to provide the user the best

possible deal in relation to his request. Any other method employed to accomplish the

same task using RMI or Java XML RPC or JNDI/JMS would be painstaking and an

enormous exercise, including the fact that neither could implement all the features

provided by the agent system. A more detailed diagram illustrating how each component

relates to the other and their interaction is given on the following page.

43

html form

aglet context1

aglet context2

aglet context3

aglet context4

aglet context4

Client Context

Airline Ticket agent 1

Airline Ticket agent 2

Mob_Ag 1

Directory service of active hosts

Airline Ticket agent 3

Airline Ticket agent 4

Mob_Ag 2

Mob_Ag 3

Mob_Ag 4

User1

User2

User3

User4

User5

Market PlaceServer

Agent Environment

Airline1 database server

Airline2 database server

Airline3 database server

Airline4 database server

Structured Diagrammatic representation Figure 5

Form (takes requirement, submits to Mobile Agent)

SERVLET ENGINE

Listing of registered hosts

44

Aglets in Parallel Execution

This section shall demonstrate how parallel execution of multiple mobile agent is

enforced in to getting choices from the remote hosts at where they are executing and why.

If an aglet has to search say 10 hosts for information, it can do it either sequentially

where information is extracted from one host before moving to the next, or 10 aglets

could visit those 10 different hosts simultaneously, extract information and send results

back to the user in one trip time. The advantage here extends to beyond the obvious

reason of time saving. In a environment where the remote aglet has to query the remote

database for sustained amount of time, the question of it querying one host and then

moving to the next one becomes totally out of question.

Fig 6

Home node

Home node

Parallel Execution

Serialized Execution

45

2.2 Scenarios and Implementation

The client interface is so designed as to provide for all possible selections that a user can

possibly make taking into consideration all options available to him. Hence it is

necessary to understand all possible scenarios of the user interface and how

correspondingly the aglets need to adapt to dynamically changing tasks evolving out of

user changing his mind, re-querying, booking issues and possible disconnection of a

database server. Disconnection of a database server, resulting in temporary suspension of

services should not hamper the results being passed to the user. In this sense, if the best

deal is present on a particular server which has been disconnected for a short while, and

the query being executed, enabled by aglet persistence on other servers should not

overlook the deal once the server is back in the reckoning. The following scenarios will

be able to clearly present different cases of a customers possible choices and what is to

follow depending upon those choices.

Scenario I: Submitting the request

After a registered user has logged in with proper authentication, he has the ability to

submit his request through the first requested page. This page shall take minimum

information such as starting city, destination city, travel date, maximum budget and

number of passengers. On submitting this pre-requisite information, the action shall lead

the user to a page where he can fine grain his query depending on whether he wants the

cheapest ticket available for that particular day or whether he has constraints and can

travel only after or before a specific time. Depending on the day he wants to travel and

the actual proposed date of travel, the customer shall also have the choice to get results at

46

a regular frequency over a sustained duration which could run up to two to three days, so

that he can clinch the best possible deal available to him over that larger time frame.

Hence, his choice shall lead him to a subsequent html page where he can enter his choice

with regarding to specific time or whether he would just want the cheapest tickets

available. After he enters all the required information here and submits this, the request

is complete in all respects. The user could also enter a plain entry without fine tuning his

request in which case he shall see all the flights available to him though then the selection

would be restricted in the sense that the user shall have to sort out his choice from a

larger selection and results that do not apply to him would be displayed. For example if a

person is looking for cheapest tickets between two cities on a given day, he shall see all

the choices available connecting the two cities and not just the cheapest ticket available.

Implementation:

When a user submits his query choices, captured as fields in the text boxes, they are

concatenated as a �:� separated single string in the servlet codes

doPost(HttpServletRequest request, HttpServletResponse response) method and passed

on to the home based aglet through the createAglet(p1,p2,p3,p4) method where p4 is a

String type parameter denotes the concatenated string, embedded in the doPost( ) method.

The Home based aglet in turn spawns new aglets through the

getAgletContext().createAglet(p1,p2,p3) method where getAgletContext() returns the

current home context and p3 is a proxy object of the home based aglet. The parameter p3

is passed in order to enable messaging between the remote aglets and the home based

aglet since messaging can be done only through its proxy reference. The number of new

47

aglets created depends on the number of active hosts and each of the created aglet is

dispatched to the appropriate host. Once at the remote host each of the spawned aglets

receives a message through the handleMessage(Message msg) method from the home

based aglet which uses the proxy.sendMessage( ) method. The parameter msg denotes

the message passed to the remote aglet, which is actually the string passed by the user

initially. The string thus received is broken down to various fields using the

StringTokenizer method to be formatted properly as a MySql query and then executed on

the remote context. One of the parameter passed to the remote aglet also defines the time

for which this query shall be executed and at what intervals. Obviously, greater the time

for which the remote aglet shall execute at the remote context, greater shall be the

interval at which it shall query the database. Every time it queries the database and gets

results, those results are again concatenated as a single string and messaged to the home

aglet using the proxy.sendMessage( ) method. Again the home aglets handleMessage( )

method gets the message and parses the string and inputs the current results into the local

database. Every new message received updates the database, thus old messages coming

from a particular remote aglet are deleted and the new message added, eliminating data

redundancy. In this manner when a user wants to check results only the most recent

updates are available to him.

Scenario II: Checking Results

As soon as a user submits his request, he is directed to an html page which allows him to

check his results. The results displayed to him are all the choices available to him from

the different databases. Though the user himself has no knowledge where this databases

48

are located or which deal has come from where. It is the prerogative of the local host to

store such information and have logged entries stating which deal has come from which

database server. The user can select any one of the options offered to him and proceed

towards purchasing that deal.

Implementation:

When the results of the remote queries are passed back to the home aglet, it in turn

updates the results in the local database and the user can get to view the most updated

results. If after submitting his request the user logged out, he can re-login at a later (but

not too late) time to check his results. This is implemented using the servlets

doGet(HttpServletRequest request, HttpServletResponse response) method which

retrieves all the available data corresponding to that particular user. Thus the MySQL

querying client now is embedded in the doGet( ) method to do the required task.

Scenario III: Purchasing Tickets

Once all the choices that are available to him are displayed on the page, the user

subsequently may wish to purchase the tickets or redo the query all over again. If he

wishes to redo the query he has to start from all over again which will take him to

scenario I. If it so happens there is a particular deal among all the choices available to

him, that he likes, he can proceed to go ahead and purchase that particular deal. The

billing information existing on the local host for that registered user shall enable billing

the customer accordingly.

49

Implementation:

Once a customer makes a selection and proceeds to purchase it, on submitting the

selection, the servlet code creates an aglet with all the required information passed to it as

a string. The information shall include where the deal is located (not seen by the user),

and the flight details. This aglet in turn shall create a solitary child aglet, and much in the

way of the querying agent pass the flight detail information to this child and dispatches it

to the host where the deal is available. If the deal is still available then the flight

bookings table at that particular remote host is updated with this information and seats are

granted to that user. Hence, when the user goes ahead to check the confirmation of the

purchase, he shall get it. It can also so happen that if the user is very late in purchasing

the deal, the deal may get sold out. My architecture doesn�t enable blocking of seats and

only allows purchasing on �first come first served� basis. Thus in that event, the remote

agent passes a message back to the home agent that the seats are full and that the deal is

sold out. In this case the home agent shall delete that particular deal and tell the user that

the deal was sold out, when he asks for confirmation of the purchase and that he can

either purchase either of the other deals available to him or redo the query and booking

from all over again. The occurrence of such an event though remote is still quite possible

and the system implemented duly takes care of such an eventuality.

50

2.3 Software Design

This is the most critical stage since coding a quality software product depends on how

intensely the product was planned to perform given different situations in conditions

dynamic or passive. The interaction of different objects and analysis of all outcomes

after a particular state would definitely enhance code writing. In accordance with the

principles of software designing, the system is designed in keeping with the prescribed

conventions. The design is structured and planned using the classical designing format

and includes the following diagrams to illustrate each and every aspect of the proposed

architecture:

a. Use Case diagram

b. Sequence Diagram

c. UML collaboration diagram

d. Activity Diagram

e. State-chart Diagram

f. Class Diagram

2.3.1 The Use Case diagram: This is the first step and involves summarizing all

possible interfaces of the user. This presents the end users view of the system

and how and at exactly what stage he interacts with the system which could be

either feeding data or an activity.

51

2.3.1 Use Case Diagram

Figure 7

Submit Query with all details

Check results sent back tohome agent from remote

agents

Purchase Tickets

Client

Airline Database

server

52

2.3.2 Sequence Diagram

Sequence Diagram: It enlists the sequence of events taking place in the interaction of

different object components of the system. For example, the �users� submit their query to

the �home agent� at the local host which in-turn creates child agents that visits the

�remote database place� where it queries the database. Once the results are obtained at

the remote database the remote agents pass the message back to the home agents. Here

the vertical dimension (broken line) represents the lifetime of an object and the horizontal

dimension represents different objects in the actual sequence the come in play

53

Sequence Diagram

Figure 8

User Home Agent

Remote Agent

Remote Host

Context

Airline Database

Server

Submit details Creates

Dispatched to

Query

Query resultPass results

Pass results

Check Results

Purchase Tickets

Creates Dispatched to Update

Database

Update resultPass resultsSend

confirmation of updating

Check confirmation

54

2.3.3 UML Collaboration Diagram

UML Collaboration diagram: It is a representation of how different entities or objects

interacts with the sequence of events being numbered. It is more like a flowchart

diagram and can be said to be an index to what could happen next. Here the objects

are represented by rectangular figures and the flow of operation represented by

arrows.

55

UML Collaboration Diagram

1: Submit requirements 9: best deal results

8: updates table

2: Creates

4: Passes query by messaging 7: Pass current result

3: Dispatch to remote context

5: queries request to database 6: query result

Figure 9

Customer

Home Agent

Remote querying agent

Querying agent at remote context

Remote Database server

Local database

56

2.3.4 Activity Diagram

Activity diagram: An activity diagram illustrates the workflow of a use case

comprehensively. It is a more in depth analysis and follows the collaboration

diagram. This diagram not only shows the sequence of events but presents each event

and activity clearly showing where they occur and under what conditions. The user

submits the query through the servlet to the home aglet at the client host but the query

is actually executed by a remote aglet at the remote host. Thus the activity diagram

divides the setup in to different areas and elucidates exactly which activity takes place

where, under what conditions and what follows next. Activity diagrams constitute the

following:

a. A start state and an end state.

b. Activities representing steps in the work flow.

c. Transitions that show what state follow another.

d. Decisions allowing alternative threads in the workflow

e. Synchronization bars showing parallel sub-flows.

f. Swim lanes representing roles or areas containing activities.

57

Activity Diagram

Figure 10

User Client Host Server Database Host

User logs in

User submits query Create stationary home

agent

Create child agents

Dispatch child agents to remote databases

Receive child agents at database server context

Remote agent receives message from home agent

Home agent sends user query to remote agent as a

message

Remote agent queries the local database

Remote agent receives query result from database

Remote agent sends results back as message to home

agent

Home agent receives results from remote aglet

Home agent logs result into local database

User accesses database to check results and

proceeds to purchase

START

END

58

2.3.5 List of Classes and Class Diagrams

Class Diagram: It is the last operation performed before writing the code itself.

TogetherSoft�s package generates the code in relation to the class diagram which

makes the coding quite easy. This diagram is primarily a representation of classes

denoted as rectangular blocks and the relations between the various classes. Before

coding begins, it is important to realize what would be all the classes involved whose

objects come into play, what would be the variables required to be initialized and

what functions or methods are associated with that class. Also to be understood is

which class extends or implements what which basically are the inheritance

objectives. A clear understanding of all these concepts can have us first enlist the

classes and methods and then build the class diagram itself. In the airline reservation

system, a number of classes and their methods have been implemented. The

following are the class definitions:

---------------------------------------- SERVLET CLASSES ---------------------------------------- class Login_Verify extends HttpServlet{ HttpServletRequest request; HttpServletResponse response; String user_id; String passwd; Connection myConnection; Statement myStatement; ResultSet myResultSet; String SQLString; PrintWriter output; public void LoadDriver() public void Connect() public void getStatement() public void getSQL() public void executeSQL() public void DisplayScreen()

59

} ----------------------------------------- Class Submit_Query extends HttpServlet{ HttpServletRequest request; HttpServletResponse response; String user_id; String start_city; String dest_city; String start_date; String num_passenger; String max_budget; ResultSet myResultSet; PrintWriter output; public void DisplayScreen() public void doPost() } ----------------------------------------- Class Check_Results extends HttpServlet{ HttpServletRequest request; HttpServletResponse response; String user_id; String start_city; String dest_city; String start_date; Connection myConnection; String SQLString; Statement myStatement; ResultSet myResultSet; PrintWriter output; public void LoadDriver() public void Connect() public void getStatement() public void getSQL()

public void executeSQL() public void DisplayScreen()

} ----------------------------------------- Class Purchase_seats extends HttpServlet{ HttpServletRequest request; HttpServletResponse response; String user_id; String start_city; String dest_city; String start_date;

60

String context_name; Connection myConnection; String SQLString; Statement myStatement; ResultSet myResultSet; PrintWriter output; public void LoadDriver() public void Connect() public void getStatement() public void getSQL() public void executeSQL() public void DisplayScreen() public void doPost() } ----------------------------------------- Class Check_Confirm extends HttpServlet{ HttpServletRequest request; HttpServletResponse response; String user_id; String start_city; String dest_city; String start_date; String context_name; Connection myConnection; String SQLString; Statement myStatement; ResultSet myResultSet; PrintWriter output; public void LoadDriver() public void Connect() public void getStatement() public void getSQL() public void executeSQL() public void DisplayScreen() } ------------------------------------------ AGLET CLASSES ------------------------------------------ public class Send_Query extends Aglet { String MYSQL_HOST; String MYSQL_DB; String MYSQL_USER; String MYSQL_PASSWD; String MYSQL_TABLE;

61

String Driver; String[] Context_Names; public Connection myConnection; public Statement myStatement; public ResultSet myResultSet; public String SQLString; public String SQLString2; public void onCreation() public void sendMessage() public void dispatch() public boolean handleMessage() } ------------------------------------------ public class Do_Query extends Aglet { String MYSQL_HOST; String MYSQL_DB; String MYSQL_USER; String MYSQL_PASSWD; String MYSQL_TABLE; String Driver; String[] Context_Names; boolean IfRemote; public Connection myConnection; public Statement myStatement; public ResultSet myResultSet; public String SQLString; public String SQLString2; public void onCreation() public void sendMessage() public void dispatch() public boolean handleMessage() } ------------------------------------------ public class Send_Buy extends Aglet { String MYSQL_HOST; String MYSQL_DB; String MYSQL_USER; String MYSQL_PASSWD; String MYSQL_TABLE; String Driver; String Context_Name; public Connection myConnection; public Statement myStatement; public ResultSet myResultSet;

62

public String SQLString; public String SQLString2; public void onCreation() public void sendMessage() public void dispatch() public boolean handleMessage() } ------------------------------------------- public class Do_Buy extends Aglet { String MYSQL_HOST; String MYSQL_DB; String MYSQL_USER; String MYSQL_PASSWD; String MYSQL_TABLE; String Driver; boolean IfRemote; public Connection myConnection; public Statement myStatement; public ResultSet myResultSet; public String SQLString; public String SQLString2; public void onCreation() public void sendMessage() public void dispatch() public boolean handleMessage() } ------------------------------------------- Aglet CLASS ------------------------------------------- public abstract class Aglet implements java.io.Serializable { public static final int ACTIVE; public static final int INACTIVE; protected Aglet() public final void dispatch() public final void dispose() public final void deactivate() public void run() public void onCreation(Object init) public void addCloneListener() public void addMobilityListener() public void addPersistencyListener() public void onDisposing() public boolean handleMessage()

63

public void waitMessage() public void notifyAllMessages() public AgletProxy getProxy() public AgletContext getAgletContext() public final AgletID getAgletID() public final AgletInfo getAgletInfo() } -------------------------------------------- HttpServlet CLASS -------------------------------------------- public abstract class HttpServlet implements java.io.Serializable { HttpServletRequest request; HttpServletResponse response; ServletRequest req; ServletResponse res; protected void doDelete() protected void doGet() protected void doOptions() protected void doPost() protected void doPut() protected void doTrace() protected void getLastModified() protected void service() }

64

HttpServlet

Login_Verify Submit_Query

Check_Results

request : HttpServletRequest response : HttpServletResponse req : ServletRequest res : ServletResponse

doDelete() doGet() doOptions() doPost() doPut() doTrace() getLastModified() service()

request : HttpServletRequest response : HttpServletResponse user_id : String passwd : String myConnection : Connection myStatement : Statement myResultSet : ResultSet SQLString : String Output : PrintWriter

LoadDriver() Connect() getStatement() getSQL()

request : HttpServletRequest response : HttpServletResponse user_id : String start_city : String dest_city : String start_date : String num_passenger : String max_budget : String myResultSet : ResultSet Output : PrintWriter

DisplayScreen() doPost()

request : HttpServletRequest response : HttpServletResponse user_id : String start_city : String dest_city : String start_date : String myConnection : Connection SQLString : String myStatement : Statement myResultSet : ResultSet

LoadDriver() Connect() getStatement() getSQL() executeSQL() DisplayScreen()

Purchase_Seats

request : HttpServletRequest response : HttpServletResponse user_id : String start_city : String dest_city : String start_date : String context_name : String myConnection : Connection SQLString : String myStatement : Statement myResultSet : ResultSet Output : PrintWriter

LoadDriver() Connect() getStatement() getSQL() executeSQL() DisplayScreen() doPost()

Check_Confirm

request : HttpServletRequest response : HttpServletResponse user_id : String start_city : String dest_city : String start_date : String context_name : String myConnection : Connection SQLString : String myStatement : Statement myResultSet : ResultSet Output : PrintWriter

LoadDriver() Connect() getStatement() getSQL() executeSQL() DisplayScreen()

implements

implements implements

implements implements

1

uses

2

uses

65

Figure 11

Aglet

ACTIVE : int INACTIVE : int

Aglet() dispatch() dispose() deactivate() run() onCreation() addCloneListener() addMobilityListener() addPersistencyListener() onDisposing() handleMessage() waitMessage() notifyAllMessages() AgletProxy getProxy() getAgletContext() AgletID getAgletID() AgletInfo getAgletInfo()

Send_Query

MYSQL_HOST : String MYSQL_DB : String MYSQL_USER : String MYSQL_PASSWD : String MYSQL_TABLE : String Driver : String Context_Names : String[ ] myConnection : Connection myStatement : Statement myResultSet : ResultSet SQLString : String

onCreation() sendMessage() dispatch() handleMessage()

Do_Query

MYSQL_HOST : String MYSQL_DB : String MYSQL_USER : String MYSQL_PASSWD : String MYSQL_TABLE : String IfRemote : boolean Driver : String Context_Names : String[ ] myConnection : Connection myStatement : Statement myResultSet : ResultSet SQLString : String

onCreation() sendMessage() dispatch() handleMessage()

Send_Buy

MYSQL_HOST : String MYSQL_DB : String MYSQL_USER : String MYSQL_PASSWD : String MYSQL_TABLE : String IfRemote : boolean Driver : String Context_Names : String[ ] myConnection : Connection myStatement : Statement myResultSet : ResultSet SQLString : String

MYSQL_HOST : String MYSQL_DB : String MYSQL_USER : String MYSQL_PASSWD : String MYSQL_TABLE : String IfRemote : boolean Driver : String Context_Names : String[ ] myConnection : Connection myStatement : Statement myResultSet : ResultSet SQLString : String

onCreation() sendMessage() dispatch() handleMessage()

onCreation() sendMessage() dispatch() handleMessage()

Do_Buy

implements

implements

implements

implements

1

2

uses

uses

uses

uses

66

2.4 Software Testing

Testing has to be performed during both the implementation and integration phases.

Each module is tested when it is being added to what has already been integrated. The

method adopted is to test the new module after it has been added and then check the rest

of the modules to see if they behave as they did earlier. Testing the software is done by

storing standard input data for a test case in a file and the product is then executed by

supplying relevant data from the file to it. User satisfaction is the ultimate goal in

software testing and different use case scenarios are checked and re-checked in order to

ensure stability of the system and robustness of the code. There are four major

components of testing the software, namely, testing correctness, robustness, performance

and documentation of both code and methodology. The user may perform an action

which was not anticipated thereby giving undesirable results. Such an event has to be

looked upon before hand so as to prevent software failure. A user guide has been

provided at the end to give the user the manner in which the software operates and a

sequential flow of what event follows another.

67

2.5 Security

System security is of course the most important consideration taken into account when

developing any software. A system that is unreliable and open to attacks or eaves-

dropping is rendered useless, no matter how efficiently the code performs. The airline

system has been totally developed in Java. Java�s runtime environment incorporates a

security manager feature preventing execution of clients or as in this case aglets, without

proper authentication. This relates to the java.policy file which references a particular

Codebase authenticated by tokens in the .keystore file. This shall be dealt more

elaborately later in the section. This section on security has been divided into three

subsections referring to areas where security lapses could occur and the measures in

effect to prevent such lapses: Security in mobile agents, security between user and client

host, security between client host and database servers.

2.5.1 Security in Mobile Agents:

The following are the possible security lapses:

1. Agent Protection

a. Remote host threatening agent. An agent on a trip that visits an untrusted

server may have that server extracting critical data and information from

the agent or even tamper with the agent. This can include illegal

execution, and illegal access.

b. Agent threatens another agent. If an agent has the ability to interact with

other agents and this agent happens to be of the malicious type, then it

may extract private information from the other agent causing illegal access

68

c. Unauthorized third parties threaten agent. A malicious entity may alter

messages exchanged between hosts or tap the communication between

them and reveal the content of the agent. This would be an eavesdropping

example.

2. Host protection

a. Incoming agent threatens host. An incoming agent visiting a server

attempts to access and corrupt the host�s sensitive data or alter its private

files maybe passing information from the /etc/passwd file. Possible

attacks can include Trojan horse and repudiation.

b. Unauthorized third parties threaten host. A malicious entity may send a

large number of spam agents to a server and take it out of service due to

sheer volume of agents queued up for accessing the host context. Possible

attacks may include denial of service.

3. Network protection

a. Incoming agent threatens the network. An agent starts multiplying and

traveling extensively in an attempt to flood the network with agents. This

could also lead to denial of service.

Security measures adopted:

1. Authentication. Before accepting an incoming agent, the goal is to know its

source. The procedure involves verification of the entity that instantiated it and

send it to you. Before accepting an agent, a check of whether the server that sent

the aglet is indeed the server that the agent claims to have sent it, needs to be

done.

69

a. Authentication of the user. The user needs to authenticate himself to a

given server. Public-key encryption or password can be used for this

purpose.

b. Authentication of host. Before a server starts to communicate with another

server or client, it needs to know with whom exactly it is communicating.

This is important, because cannot ensure integrity and confidentiality

without knowing who you are receiving agents from or sending agents to.

c. Authentication of code. Before executing an incoming agent, the server

needs to know who is responsible for the agent�s implementation. Digital

signatures are typically used for this purpose.

d. Authentication of agent. Before executing an incoming agent, the server

needs to know the owner of the agent.

2. Integrity. To rely on an agent, you need to make sure no one has tampered with

its state or code. Checking the integrity of the agent is the technique we use to

verify that no illegitimate alterations have been made to the state and code of the

agent.

3. Confidentiality. An agent may carry out confidential or private information that

should be readable only by particular servers or agents. Such information should

be kept secret from other servers or agents. An agent may request a server to

transport itself in a secret way to cope with the possibility of eavesdropping.

4. Authorization. An incoming agent should be given the right to access information

according to its principals. Authorization, or access control, is the way to specify

70

and enforce an agent�s capability to access information or to use the services

provided by the server.

5. Auditing. An auditing service records security related activities of an agent for

later inspection. The records can be stored in a log file which can be viewed later.

Java runtime resources ensure that executing code shall be given ability to execute

enforced by a security manager. Though the java virtual machine allows code

portability, system checks performed by the security manager allows only specific

code to be executed. Codebases containing executables are typically signed by a

secure user and access is granted with authentication of tokens stored in the .keystore

file generated and stored in the home directory. Location of the policy file is

typically stored in the java.security file located in /java.home/lib/security directory.

By default the java.policy file is located in /java.home/lib/security directory and it is

specified in the java.security file by the following notation:

policy.url.1=file:$(java.home)/lib/security/java.policy

The user can however generate his own .java.policy file and store it in his home

directory. In this case the following entry shall have to be made in the java.security

file:

policy.url.2=file:$(user.home)/lib/security/.java.policy

71

The .java.policy file looks like this :

// Entry granting permissions to aglets code.

grant codeBase "file:/space/std/balkrisp/Aglets1.0.3/lib/-" SignedBy(balkrisp){

permission java.security.AllPermission;

};

grant codeBase "file:/space/std/balkrisp/Aglets1.0.3/public/-" SignedBy(balkrisp){

permission java.security.AllPermission;

}

This file and the .keystore file can be generated using the policytool which is a GUI

interface to implement the same. To run an application without making the

policy.url.2 entry, the method would be:

java -Djava.security.manager -Djava.security.policy=pURL SomeApp

The permission in the .java.policy file represents access to a system resource. In order

for a resource access to be allowed for an applet (or an application running with a

security manager), thus the corresponding permission must be explicitly granted to

the code attempting the access. The following diagram illustrates how the java

security model is implemented

72

Figure 12

The advantages of this model are:

1. Fine grained access control. It allows the user to choose from a small number of

different security levels.

2. Easily configurable security policy. It allows application builders and users to

configure security policies without having to program especially to incorporate

security.

3. Easily extensible access control structure. This architecture allows typed

permissions (each representing an access to a system resource) and automatic

handling of all permissions (including yet-to-be-defined permissions) of the

correct type. Hence no new method in the security manager class needs to be

created every time

4. Extension of security checks to all Java programs, including aglets. Local code

(e.g., non-system code, application packages installed on the local file system) is

subjected to the same security control as applets, although it is possible, if desired,

73

to declare that the policy on local code (or remote code) be the most liberal, thus

enabling such code to effectively run as totally trusted. The same principle applies

to signed applets and any Java application.

2.5.2 Security between user and Client host:

Since a user connects to a client host and sends critical data over the internet including

credit card information, there is a necessity to implement at least a minimum level of

security between the user and the client host. Transactions over the internet are subject to

eavesdropping and critical data can be captured without much fuss. To take care of this I

am proposing to implement HTTPS which is an SSL (secure socket layer)

implementation of the HTTP protocol. The way this can be done:

public class Handler extends URLStreamHandler { public Handler() throws ProtocolNotSuppException { new HTTPClient.HTTPConnection("https://someurl", "", -1); } public URLConnection openConnection(URL url) throws IOException, ProtocolNotSuppException { return new HTTPClient.HttpURLConnection(url); } }

74

2.5.3 Security between Client host and Database servers:

Security between the client host and the database servers is very critical. Each of the

database servers is a competing server and a user request or purchasing details are done

by mobile agents holding this critical data. In the real sense, these competing servers and

the client host could be located on virtual private networks (VPN�s) with possibly non

routable IP addresses from the outside networks. A system should be incorporated to

ensure data and code integrity across the client and the remote database servers. Besides,

the Client or the database servers could be hot targets for denial of service attacks since

they are commercial servers. Any such eventuality could result in loss in business and

revenue which cannot be compromised. Thus a totally secure system ensuring secrecy of

transactions and immunity against any type of malicious attack must be enforced.

To this effect I am proposing IP masquerading. The setup shall involve Linux boxes as

gateways to the networks on which the different servers are located. Basically, IP-

Masquerading translates internal IP addresses into external IP addresses. This is called

network address translation and Linux does this by using well defined port-numbers.

From the outside world, all connections will seem to be originating from your Linux box

gateway. To enable masquerading the Linux kernel has to be configured.

The masquerading Linux gateway server restamps all outgoing packets with its own real

IP address and an alternate port, and restamps all incoming packets with the masqueraded

addresses and sends them over the masqueraded network to the client. The client system

has no way of knowing whether or not it is actually on the Internet, except that operations

that involve the client taking the role of a host do not work with IP masquerading, since

the IP address of the client is not a real, valid IP address. Because masqueraded IP

75

addresses may not be addressed from anywhere but the network itself, the network is

effectively put behind a firewall. The gateway can then be setup to accept packets from

only certain reliable hosts using IP tunneling. Tunneling means encapsulating data of one

protocol type in another protocol, and sending it over a channel that understands the

protocol. Encapsulation of IP within IP makes the machine seem to be on a different

network than where it is actually located.

76

2.6 Comparison between agent system and other competing network technologies

This section provides insight into the advantages of using an agent system in the given

project rather than remote method invocation (RMI) or Java XML RPC.

The main difference and advantage of agent system over the other mentioned

technologies is the movement of code to the context rather than vice versa. In RMI, code

existing on the remote host is invoked by a method in the local host. Persistency of

execution as attained in the mobile agent system is advantageous as compared to RMI

because in RMI frequent invocations of the same method at the remote host from the

local host to attain the same objective. This would involve so many more transactions

between local and remote host as compared to mobile agents who take the code to the

remote context and can carry out the execution persistently and send back results as and

when required. Again mobile agents are not affected by network traffic or latencies since

it can send back messages at a more convenient time. RMI would be severely affected by

larger amounts of network traffic. The agent system also supports disconnected

operation as opposed to RMI.

Similarly in Java XML RPC a similar system could be implemented but it would not be

just as efficient. The problems faced by RMI are in common with the XML RPC

procedure and passing of the data type definition (DTD) files which need to be parsed at

each context involve large overheads. Again different codes will have to be written to

take care of different use cases depending upon the values attained on parsing the DTD

files. Mobile agents can use the same code which can adjust to the user�s needs or

request.

77

Section III: Conclusions and Suggestion for Future work

78

3.1 Results and Conclusions

The Airline Reservation System was successfully implemented using mobile agents. The

different properties of aglets and functionalities were put to good use and the desired

effect of dynamically getting a user the best deal possible was achieved systematically.

This system also illustrated the implementation and integration of html, servlets, aglets

and databases located on the local and remote hosts. This ecommerce based application

was designed to give the user satisfaction with regards to him knowing all options to him

and letting him take his time to make the best choice and that was efficiently achieved.

Aglet technology automate many of the processes users now perform manually, and it is

poised to transform the conventional network programming paradigm.

Though security of aglets remain a concern development is in progress to enhance the

currently existing system into being fault resilient and totally dependable.

3.2 Other agent system projects:

1. Odyssey at www.generalmagic.com

2. Concordia at www.metica.com/HSL/Projects/Concordia

3. Voyager at www.objectspace.com/voyager

4. Agent Tcl at www.cs.dartmouth.edu/~agent

5. Ara at www.uni-kl.de/AG-Nehmer/Projekte/Ara

6. TACOMA at www.cs.uit.no/DOS/Tacoma

79

3.3 Scope of future work

Though an attempt is being made to implement an advertising agent system in my current

project, its efficacy would not be established without competing Client hosts just as there

are competing Database servers. The current system was a single client system. Further

efforts could include multi client market place servers with advertising agents playing a

major role towards reducing network traffic resulting out of a number of child aglets

being created for each query.

The current system also incorporates flight reservation between any two cities. Further

implementations could involve integrating query results to get connecting flights by

searching a hashtable for common cities connecting any two given cities when there is no

direct flight available. If this system is implemented along with hotel bookings and car

rentals, it would result in a comprehensive travel package.

3.4 Other possible areas of using mobile agents

1. Electronic commerce. Mobile agents can be used to develop virtually every

ecommerce based software. Virtual stores are a thriving entities today and mobile

agents could be used in a variety of ecommerce bases applications.

2. Software distribution. Installing, maintaining and updating software�s has

become significantly difficult to achieve as the number of machines that support

these software�s grow exponentially. Agents can automate the process by

customizing installation of onsite verification and versioning, and inventorying of

software packages

80

3. Large stores such as Walmart could have an agent system built in to take care of

inventory control. Since at any time there is a record of what was on the shelf and

what was sold the procedure of ordering inventory could be automated by sending

buying agents to suppliers.

4. Information retrieval is another important application for mobile agents. Being

able to visit a site with information provides for locality of reference and

significantly improves performance. This system may be used to receive stock

updates from various sources or otherwise sending stock updates to a large

number of customers.

5. System administration. Since this involves work which is distributed in nature

mobile agents can carry out the task of traveling around large systems

independently, and perform periodic management like backups, identification of

unwanted core files and other security checks. This is necessary since it alleviates

the task of constant human monitoring.

6. Network management. Networks are inherently distributed and provide a suitable

environment for deploying agents. Agents in this context can be used in the

purpose of load balancing and solving problems which require reliable network

connections even when the connection type is weak or intermittent.

81

Programming difficulties and code subtleties

The remote agent queries the database repeatedly for a definite duration at specified

intervals when you deactivate the agent using the deactivate(time in ms) method, all the

public variables have to be reassigned to null in order to save its (the aglets state) if this

is not done the agent cannot save its state and �hangs�. This is very cumbersome and

unwanted since it could have many agents hanging at the remote context for the inability

to save state and then those agent will have to be manually disposed.

In the development phase to reprogram a particular aglet, the host context has to be re-

booted in order to the changes to take effect from the newly compiled aglet. Since the

aglet context contains a class cache, if you fire the newly compiled aglet code without

rebooting the context the original class file (the class before recompiling the original

aglet) shall take effect which can lead to confusion.

The environment in which you create aglets and have the web server to interact with

aglets is also important and utmost care has to be taken to set the paths of the

environment variables in the .cshrc file. The environment variables I had to use are:

HOME, AGLET_HOME, AGLET_PATH, CATALINA_HOME, JDK_HOME,

JAVA_HOME. The CLASSPATH and the PATH variables have also to be suitably

initialized to get the system to work with special emphasis on {mysql_hom}\bin

{tomcat_home}\bin and {aglets_home}\bin paths and the JDBC/ODBC classpaths. No

words can describe how important it is to have the environment set up appropriately

before starting to code the application.

82

Section IV: Bibliography and References

83

References

1. Mobility, Processes, Computers and Agents

By Dejan Milojicic, Fredrick Douglis and Richard Wheeler

2. Programming and deploying Java Mobile Agents with Aglets

By Danny B. Lange and Mitsuru Oshima

3. The Complete Reference JAVA2

By Patrick Naughton and Herbert Schildt

4. Java Servlet Programming

By Jason Hunter and William Crawford

5. MySql Reference Manual

By Michael Widenius and David Axmark

6. Java Servlet Technology

http://java.sun.com/webservices/docs/1.1/tutorial/doc/index.html

7. Integrating Java-based Mobile Agents into Web Servers under Security Concerns

By Stefan Funfrocken http://www.informatik.tu-darmstadt.de/VS/Mitarbeiter/Fuenfrocken/

8. Security and Policy file implementation

http://java.sun.com/products/jdk/1.2/docs/guide/security/PolicyFiles.html

9. Aglets Specification

http://www.cs.uidaho.edu/~abdullah/fmca/aglet/Aglets.htm#Security%20in%20A

glets

10. Java Aglet Application Programming interface White Paper � (JAAPI)

http://www.trl.ibm.com/aglets/JAAPI-whitepaper.htm

84

Appendix I :

Source Code

85

Appendix II :

Database Tables

86

Client side database tables

1. customer_info table

Customername Userid Password Dateofbirth creditcardno

2. user_options table

Userid Startcity Dest Traveldate Starttime Flightno Numpass Airfare context

3. billing_info table

Custname Userid Startcity Dest Traveldate Flightno Numpass Totfare

87

Database server side tables

1. Flight_info table

Flightno Startcity Dest Starttime Traveltime Airfare

2. Flight_booking table

Flightno Traveldate Startcity Dest Sold Capacity

88

Appendix III

User Guide

89

User Guide

1. login with valid username and password.

2. Submit first part of the query stating start city, destination city, start date,

number of passengers and maximum budget.

3. Fine tune the query by stating whether you want the cheapest possible deal or

would like to take the first possible flight after a particular time or the last

possible flight before a particular time.

4. Check the results of the query.

5. Select any one particular deal you like among the ones displayed if you like it and

proceed to purchase it or wait for some more time and check your results again or

redo your query all over again.

6. If you decide to purchase a selection, once you submit to purchase, check for

confirmation.

7. If you were too late in purchasing the deal or if that deal gets sold out, you shall

not get a confirmation. Instead the deal shall be deleted from your list of current

options and the remaining choices displayed to you if you like any of the

remaining choices you could proceed to purchase that deal or redo the query all

over again.

8. Once a deal is purchased a confirmation shall be displayed and you shall be billed

according to the billing information in the customer info table.