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.
Top Related