Mobile Agents for World Wide Web Distributed Database Access

  Mobile Agents for World Wide Web.pdf (Size: 1.87 MB / Downloads: 0)
1 INTRODUCTION
THE widespread use of Java [1] in network-centric
computing, attributed mainly to its portability and
security control system, gives Java the lead in client/server
programming and mobile computing [2]. Moreover, the
already established Java database connectivity application
interface (JDBC API) [3], [4] and the constantly growing and
refining of JDBC [5] drivers have drawn the attention of
major database vendors. On the other hand, the World
Wide Web (simply Web) [10], [11], [12] is rapidly being
accepted as a universal access mechanism for network
information. The popularity of the Web suggests that Web
browsers may offer a compelling end-user interface for a
large class of applications, including database management
systems (DBMSs).
Thus, an important issue is to combine these two
technologies, namely Java and Web, for the retrieval of
information residing in database systems. The real challenge
is the formation of smart, lightweight, flexible,
independent, and portable Java DBMS client programs that
will support database connectivity over the Internet.
However, the currently proposed approaches [5] (i.e., the
applet/JDBC based ones) overload the client, in terms of the
size of downloaded code, and offer limited flexibility and
scalability. In this paper, we introduce a new approach for
the development of Java-based distributed client/server
applications over the Web. Our approach is based on using
mobile agents [6], between the client program and the
server machine, to provide database connectivity, processing
and communication, and consequently eliminate the
overheads of the existing approaches.
The proposed framework, called the ªDBMS-Aglet
Framework,º utilizes the technology of mobile agents and
demonstrates its effectiveness over a specific application
context (i.e., DBMS access). The framework is comprised of
a set of Java based agents that cooperate to efficiently
support Web database connectivity. The main agent, called
DBMS-aglet, acquires its database capabilities dynamically,
not at the client but at the server. The other agents of the
framework assist this dynamic acquisition. This idea
promotes a much more efficient way of utilizing the JDBC
API and the JDBC driver API and eliminates the overheads
of the various conventional approaches. Consequently, it
frees the remote client to perform other tasks.
The new form of Web-based database access supported
by ªDBMS-Aglet Frameworkº is shown to be more flexible,
scalable, and robust than the current JDBC-based database
connectivity. Furthermore, the framework supports lightweight,
portable, and autonomous clients as well as
operation on slow or expensive networks. The framework
is generic and portable and can be used not only within the
Web but stand-alone as well for direct Java database
connectivity. Although, in this paper, we present performance
results for accessing relational databases, it is worth
pointing out that our approach is not restricted to relational
databases but it can be used to access any type of database
or file system. This is an additional strong point of the
ªDBMS-Aglet Framework,º since it allows accessing different
types of resources in a seamless manner.
The implementation of the framework shows that its
performance is comparable to, and in some cases outperforms,
the performance of current approaches. In fact, in
802 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 12, NO. 5, SEPTEMBER/OCTOBER 2000
. S. Papastavrou and G. Samaras are with the Department of Computer
Science, University of Cyprus, CY-1678 Nicosia, Cyprus.
E-mail: cssamara[at]cs.ucy.ac.cy.
. E. Pitoura is with the Department of Computer Science, University of
Ioannina, Greece. E-mail: pitoura[at]cs.uoi.gr.
Manuscript received 10 Sept. 1999; revised 10 July 2000; accepted 10 July
2000.
For information on obtaining reprints of this article, please send e-mail to:
tkde[at]computer.org, and reference IEEECS Log Number 112702.
1041-4347/00/$10.00 ß 2000 IEEE
wireless and dial-up environments and for average size
transactions, a certain adaptation of the framework provides
a performance improvement of approximately a
factor of ten. For the fixed network, the gains are about
40 percent and 30 percent, respectively. These performance
results were gained while using the Aglets Workbench [7]
for the implementation of mobile agents. Since the Aglets
Workbench is more tuned towards functionality than
performance, we expect our framework to perform even
better. This assumption is substantiated by early experiments
conducted using Voyager [22] as our implementation
platform. We report these experimental results as well.
The remaining sections of this paper are organized as
follows: Section 2 presents the needed background material.
This includes a short introduction to Java, mobile agents,
and mobile aglets along with an evaluation of the current
applet-based approaches for web access to distributed
databases. In Section 3, we present the proposed DBMSaglet
framework, discuss its adaptations and effectiveness
within the various client/server computational models, and
present and compare its advantages to the current
approaches. A variation of the framework and its advantages
for accessing distributed multidatabase systems is
discussed in Section 4. In Section 5, we present a Java-based
hierarchy and generalization of the various frameworks and
discuss future work. A specialized-agents library for
database services is also presented. Performance evaluation
is presented in Section 6. Implementation issues and the
role of the implementation platform are discussed in
Section 7. Section 8 concludes the paper.
2 BACKGROUND MATERIAL
2.1 Supporting Technologies
2.1.1 Java and JDBC
Java is an object-oriented, interpreted, robust, secure,
architecture neutral, portable, and multithreaded language.
The uniqueness of Java lies on the fact that it combines both
compiled and interpreted code. The Java executable code
(called bytecode) runs on any hardware platform with a
Java interpreter or any Java-enabled Web browser. In
particular, the Java bytecode represents the instructions
for a virtual microprocessor called the Java Virtual Machine
(JVM). The Java Virtual Machine, also known as the ªJava
Interpreterº [2], is an abstract computer that runs Java
compiled programs. The JVM is ªabstractº in the sense that
it is software based and runs over various hardware
platforms. Another key characteristic of Java is the small
size of its compiled code. This feature enables Java
compiled classes to travel efficiently through the Web,
making it very attractive for network-centric programming.
A Java applet is a Java object-program that can run within
the context of a Java enabled web browser. A downloaded
Java applet can perform tasks only within the context of the
client's hosting web browser and it is not allowed to access
any local resources of the client for security considerations.
Another restriction is that Java applets are not allowed to
communicate with URLs other than the one they were
downloaded from.
The Java Database Connectivity (JDBC) is the Java
standard specification for accessing and manipulating
relational databases [4]. The JDBC consists of two layers:
The JDBC API that provides a Java interface to the relational
database, and the JDBC driver API that executes/implements
this interface. A client that employs the JDBC API
must first download to its environment a JDBC driver
before accessing a particular database. In this work, the
version of the JDBC drivers used was 1.1.
2.1.2 Mobile Agents
Mobile agents are processes dispatched from a source
computer to accomplish a specified task [14], [15]. After its
submission, the mobile agent proceeds autonomously and
independently of the sending client. When the agent
reaches a server, it is delivered to an agent execution
environment. Then, if the agent possesses necessary
authentication credentials, its executable parts are started.
To accomplish its task, the mobile agent can transport itself
to another server, spawn new agents, or interact with other
agents. Upon completion, the mobile agent delivers the
results to the sending client or to another server.
Aglet Technology [7] (also known as the Aglets Workbench)
is a framework for programming mobile network
agents in Java developed by the IBM Japan research group.
The IBM's mobile agent, called ªAgletº (agile applet), is a
lightweight Java object that can move autonomously from
one computer host to another for execution, carrying along
its program code and state as well as the data so far
obtained. One of the main differences between an aglet and
the simple mobile code of Java applets is the itinerary or
travel plan that is carried along with the aglet. By having a
travel plan, aglets are capable of roaming the Internet
collecting information from many places. The itinerary can
change dynamically.
An aglet can be dispatched to any remote host that
supports the Java Virtual Machine. This requires from the
remote host to preinstall Tahiti, a tiny aglet server program
implemented in Java and provided by the Aglet Framework.
A running Tahiti server listens to the host's ports for
incoming aglets, captures them, and provides them with an
aglet context (i.e., an agent execution environment) in which
they can run their code from the state that it was halted
before they were dispatched. Within its context, an aglet can
communicate with other aglets, collect local information
and, when convenient, halt its execution and be dispatched
to another host. An aglet can also be cloned or disposed.
To allow aglets to be fired from within applets, an
abstract applet class, called ªFijiApplet,º is provided as part
of a Java package, called ªFiji Kit.º The FijiApplet maintains
some kind of an aglet context (like the Tahiti aglet server).
From within this context, aglets can be created, dispatched,
and retracted back to the FijiApplet. For a Java-enabled web
browser to host and fire aglets to various destinations, two
additional components are provided by the Aglet Framework.
These are an aglet plug-in that allows the browser to
host aglets and an aglet router that must be installed at the
Web server to capture incoming aglets and forward them to
their destination.
PAPASTAVROU ET AL.: MOBILE AGENTS FOR WORLD WIDE WEB DISTRIBUTED DATABASE ACCESS 803
2.2 The Current Approach: Applets for Distributed Database Access
The challenge is to provide the Internet user with a Webbased
database connectivity with the lowest possible
overhead. To this end, various non-Java-based approaches
(e.g., CGI) have been proposed [16], [17]. The concept,
however, of running applets within Java enabled browsers
that utilize the JDBC application interface is increasingly
gaining popularity with major database vendors. There are
four ways a Java applet can gain access to a remote
relational database (Fig. 1), making use of one of the four
existing types of JDBC driver implementations.
The first approach makes use of the JDBC-ODBC bridge
driver (JDBC driver type 1). The JDBC-ODBC bridge
translates the JDBC API calls into ODBC1 calls and sends
them to an ODBC driver already installed on the server.
This approach requires the client applet to download, along
with its code, some ODBC binary code. Moreover, in many
cases, client database code must be preinstalled on the client
machine. Thus, this approach poses many extra layers of
overhead. Nevertheless, it is useful in accessing databases
that do not directly support JDBC [5].
The second approach makes use of a JDBC driver written
half in Java and half in native2 code. The client applet,
through this JDBC driver (type 2 driver), speaks directly to
the protocol of the remote SQL database. While this
approach is very efficient in terms of performance, it
requires the preinstallation of native code at the client.
The third approach is considered to be the most flexible:
It uses a JDBC driver written entirely in Java meaning that
the entire driver can be downloaded to the client applet.
The client applet, through this JDBC driver (type 3 driver),
speaks an intermediate language that is translated by a
middle-tier gateway at the server into a DBMS-specific
protocol and eventually passed to the SQL server. The more
vendor protocols the gateway speaks, the more databases
the applet can be attached to simultaneously. Despite the
extra layer of the gateway, this approach has drawn the
attention of many database vendors, including Borland
with DataGateway [18], IBM with DB2 client support for
Java [19], and Symantec with dbANYWHERE [20].
Finally, the fourth approach makes use of a JDBC driver
(type 4 driver), also written entirely in Java. The driver can
be fully downloaded to the client applet and speaks a
DBMS-vendor protocol directly to the remote SQL server.
The approach can efficiently serve the Internet user over the
Web, but for attaching to various SQL servers, several JDBC
drivers need to be loaded. Borland and Sybase have already
released type 4 JDBC drivers.
All four existing approaches require, to some extent,
downloading and initiating the JDBC driver on the client
machine, which is generally a very resource-consuming
procedure. Our primary concern is to simplify and relieve
the remote client so that it does not need to handle a
complex set of JDBC interface classes, but just the input of
requests and the expected formatting of the output.
3 DBMS-AGLETS: MOBILE AGENTS FOR DISTRIBUTED DATABASE ACCESS
In a nutshell, our idea is to use mobile agents between the
client and the server machine. Instead of having a DBMSapplet
at the client machine that downloads from the
remote SQL server, initiates a JDBC driver, and handles a
complex set of JDBC interfaces, our proposed DBMS-applet
creates and fires a mobile agent (or agents if necessary) that
travels directly to the remote SQL server. At the SQL server,
the mobile agent initiates a local JDBC driver, connects to
the database and performs any queries specified by the
sending client. When the mobile agent completes its task at
the SQL server, it dispatches itself back to the client
machine directly into the DBMS-applet from where it was
initially created and fired. Since our mobile agents posses
database capabilities, they are called DBMS-aglets.
3.1 The DBMS-Aglet Framework
To realize our approach, a number of processes are defined
to complement the existing agent execution environment
(i.e., the aglets). In particular, applets need to be enhanced
to provide database specific interfaces and be capable to
804 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 12, NO. 5, SEPTEMBER/OCTOBER 2000
1. Open Database Connectivity: An API that defines the routines for
accessing MS-windows databases.
2. Native code: Database-vendor specific code.
Fig. 1. Standard JDBC approaches.
host agents with database capabilities. In addition, the
existing aglets need to be extended to be database capable.
Finally, supporting aglets need to be provided to assist such
database-capable aglets in their negotiations with the SQL
server.
Specifically, to support the DBMS aglet framework, the
following components are needed:
. A DBMS-applet: The DBMS-applet is responsible for
forming a graphical client database interface that the
user can utilize to input database requests. Our
suggested DBMS client applet is an extension of the
abstract FijiApplet class.
. A DBMS-aglet: The DBMS-aglet is created within the
context of the DBMS-applet and is responsible for
carrying the user's request directly to the remote
database, executing it, and returning the results back
to the DBMS-applet context. Our suggested DBMSaglet
is a Java-based extension of the Aglet class.
. A DBMS-assistant stationary aglet: The DBMS-assistant
stationary aglet resides at the site of the SQL
server. Its responsibility is to inform any incoming
DBMS-aglets carrying database requests about the
available JDBC drivers and data sources and to assist
them in carrying out their requests. Our suggested
DBMS-assistant stationary aglet is an extension of
the Aglet class.
The DBMS-applet, the DBMS-aglet, and the DBMSassistant
aglet compose the suggested ªDBMS-Aglet Framework
º that provides DBMS-capable mobile agents for
distributed database access. The DBMS-Aglet Framework
builds on and extends a mobile agent framework, in our
case, the Aglets Workbench [7], that provides the facilities
for hosting and routing mobile agents. In turn, the mobile
agent framework can exploit a standard networking
infrastructure, such as tools and services for Web-based
access. Table 1 summarizes the complete Web-based DBMSaglet
infrastructure that consists of 1) the DBMS-aglets
framework, 2) the aglets framework, and 3) the standard
networking infrastructure.
3.2 Demonstrating the Web-based DBMS-Aglet Framework
To demonstrate our approach, we have set-up a Web-based
DBMS-aglet infrastructure. To this end, we have programmed
a DBMS-applet and a DBMS-aglet and included
them in an html page at the web server machine.
Additionally, we have installed an aglet router at the web
server machine and a Tahiti aglet server at the SQL server
machine. We have also developed a DBMS-assistant
stationary aglet and initialized it within the Tahiti aglet
context at the SQL server machine. Then, we downloaded,
at the client host, the html page containing the DBMS-applet
and the DBMS-aglet. Through the DBMS-applet's GUI, we
entered a database request and order the DBMS-applet to
carry it out. The DBMS-applet fired a DBMS-aglet that
returned with the results.
Fig. 2 demonstrates the life-cycle of the DBMS-Aglet of
the previous typical scenario. Execution begins with a web
user downloading into his Java-enabled browser an html
page that contains a DBMS-applet and the DBMS mobile
agent (a DBMS-aglet) (Step 1).
After it has been initiated, the DBMS-applet forms a
front-end DBMS client application interface. This can be
achieved by making use of Java's standard GUI components
(also known as AWT components [8]) to design an
appropriate database interface (see, for example, [9]).
Once the database query is passed to the DBMS-applet
interface, the DBMS-applet creates a lightweight DBMS
mobile agent (the DBMS-aglet) within its context. The aglet
then receives information from its creator DBMS-applet
regarding the nature of the user's query. These directions
must include among others:
. The address of the URL where the SQL server is
located.
. The SQL query to be executed at the SQL server.
. The appropriate certificates for the aglet to be
trusted at the SQL server.
. The route itinerary in case the agent is to visit more
than one server.
Then, the DBMS-applet dispatches the aglet from its
context to the URL of the SQL server (Step 2). Due to Java
applet security restrictions mentioned earlier, the aglet must
first go through the web server URL from where the html
page containing the DBMS-aglet was downloaded. At the
Web server machine, an aglet router captures the incoming
DBMS-aglet and immediately forwards it to its destination
(Step 3).
Arriving at the SQL server machine, the DBMS-aglet is
received by a Tahiti aglet server. The DBMS-aglet communicates
with the DBMS-assistant stationary aglet to be
informed of the available JDBC drivers to load, and the
available data sources to get connected to. Once this is done,
and always within the Tahiti's context, the DBMS-aglet
connects to the appropriate SQL server (the specific data
PAPASTAVROU ET AL.: MOBILE AGENTS FOR WORLD WIDE WEB DISTRIBUTED DATABASE ACCESS 805
TABLE 1
The Web-Based DBMS-Aglet Infrastructure
source) to execute the query. When the aglet completes its
task at the SQL server, it can either dispatch itself to another
SQL server to perform another user's query or it can
dispatch itself back to the DBMS-applet at the client
machine, going through the aglet router at the web server
machine (Step 4 and 5).
Arriving back to its original context, the aglet delivers
the results to the DBMS-applet, which then presents them to
the user through the graphical interface.
3.3 Refining the DBMS-Aglet Framework
The role of the aglet in the DBMS-aglet framework is to
convey the various database requests to the SQL server and
bring back the result. By simply replacing any direct
requests with aglets that encapsulate and carry these
requests, the remote client is relieved from the
responsibility of downloading JDBC drivers. Downloading
JDBC drivers and connecting to the database is now the
responsibility of the various aglets. Unfortunately, though,
this is done each and every time a request is issued and an
aglet is fired to the database server, thus introducing an
unnecessary and undesirable overhead. Figs. 7, 8, and 9 in
Section 6 clearly confirm this overhead.
3.3.1 DBMS-Aglet and the Messenger Aglet
To eliminate this overhead, an extension of the client/server
model, called the client/agent/server model (c/a/s) [21] is
employed. In this three-tier architecture, an agent is placed
on the path from the client to the server. Any communication
between the client and the server goes through this
agent. In our case, this agent is a service-specific (namely
database connectivity) surrogate of the client which is
placed (parked) at the SQL server and maintained there for
the duration of the application. Between the parked aglet
and the remote client, another aglet carries requests and
results back and forth.
Based on this variation, upon the first client request, two
DBMS-aglets are fired from the DBMS-applet. The first one
is called parked DBMS-aglet. Its role is to ªcampº at the
SQL server's agent context, load the appropriate JDBC
driver, connect to the database, submit the request, and
collect and filter the answer. The second DBMS-aglet is
called the messenger aglet. The messenger aglet is responsible
for carrying the result back to the DBMS-applet (see
Fig. 3). Any subsequent requests are transmitted via the
messenger aglet to the parked DBMS-aglet.
This scheme is proved to be very efficient in cases where
the user issues, through the DBMS-applet, a number of
consecutive database requests to the same remote SQL
servers. Furthermore, since these two aglets are (almost!)
identical,3 they own the same itinerary and, thus, if the
parked DBMS-aglet moves to another server the messenger
can deterministically follow it. An additional benefit of this
approach is the ability of the messenger aglet to roam, if
needed, around the net before returning to the client.
3.3.2 DBMS-Aglet Using Messages
The deployment of a parked DBMS-aglet attached locally to
the database server eliminates one overhead, namely the
time to reload the JDBC, and reconnect to the database for
each and every query. The other overhead left is the time
required for the messenger aglet to travel between the
DBMS applet and the parked DBMS-aglet carrying results
and new queries.
Replacing the messenger aglet with two messages can
eliminate this overhead. The first message is delivered from
the parked DBMS-aglet to the DBMS applet and contains
the results of the last query. The other message from the
DBMS applet to the DBMS-aglet contains the new client
query and any additional directions to the parked DBMSaglet
that might be needed. This approach demonstrates a
true service-specific client/agent/server application. The
aglet is literally inserted into the path between the client
and the server communicating with each other via
messages. The message protocol is provided by the Aglet
platform and is an RPC-like mechanism using Java sockets.
Thus, by using a parked DBMS-aglet, we avoid the
reconnection cost (just like with the messenger approach)
806 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 12, NO. 5, SEPTEMBER/OCTOBER 2000
3. The only difference is that the DBMS-aglet is database capable, in any
other aspect they are identical.
Fig. 2. The DBMD-Aglets life cycle.
and by using messages instead of the messenger aglet, we
eliminate the time of negotiation and the amount of data
transmitted between the client and the server. Performance
results show that this approach by far outperforms the
traditional applet approach as well as the other variations of
the framework for direct data access.
3.4 Advantages of the DBMS-Aglet Framework
By using a DBMS mobile agent (namely the DBMS-aglet) to
encapsulate all interactions between the client applet and
the SQL server machine, the client applet becomes light and
portable. This is achieved by:
. Avoiding the unnecessary downloading and initialization
of JDBC drivers at the client's DBMS-applet.
. Passing the responsibility of loading the JDBC driver
at the SQL server to the DBMS-aglet.
. Not using any JDBC API classes at the client's
DBMS-applet.
The only responsibility of the client is to specify the URL
address of the database server, the query to be performed,
security certificates, and an itinerary. The rest is the
responsibility of the DBMS-aglet. The effect on performance
is quite significant, this delegation of responsibility results
in performance gains of approximately a factor of ten (see
performance evaluation in Section 5).
The DBMS-aglet is also independent of the various JDBC
driver implementations. The DBMS mobile agent cannot
(and is not supposed to) be aware of which JDBC driver to
load when it arrives at an SQL server. Upon arrival at the
SQL server's context, the DBMS-aglet is informed of all
available JDBC drivers and corresponding data sources. The
DBMS-aglet is then capable of attaching itself to one or
more of these vendor data sources.
This is where the need for the local DBMS-assistant
stationary aglet arises. The stationary aglet can be initialized
and trained by the DBMS administrator to verify the
certificates of incoming DBMS-aglets (thus, imposing the
needed security) and to provide them with essential
information about connecting to the local databases and
carrying out their queries. The DBMS-assistant aglet can be
made even more flexible. There might be cases, for example,
where the DBMS-aglet encounters obstacles, such as an
unreachable SQL server or an SQL server that fails to
completely satisfy a user's query. If the DBMS-aglet is
intelligent enough, it can negotiate with the local DBMSassistant
aglet to get alternative paths in order to accomplish
its query.
The DBMS-aglet framework further benefits from the
inherent advantages of the mobile technology itself:
. A DBMS-aglet can be fired (and forgotten) by a
DBMS-applet initialized from a laptop or a palmtop
computer during a short (and high-priced) Web
session. The agent can roam around the unstructured
network to perform the client's request and
then wait until the communication page link is again
available to return home with the results.
. In cases of weak connectivity (i.e., a period of low
bandwidth) between the client and the server, or
when the client has limited storage capacity, a
DBMS-aglet can minimize the transmitted information
by performing both retrieval and filtering at the
remote SQL server.
. A DBMS-aglet, having a certain load of work
assigned to it, can split up the workload by cloning
itself.
. A DBMS-aglet can dispatch to another host when its
current host is powerless or has a very heavy
workload.
In general, the DBMS-aglet framework allows aglets to
be portable, light, independent, autonomous, flexible, and
robust.