Performance Analysis of Java-based Approaches to Distributed ...

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

7 Ιουν 2012 (πριν από 6 χρόνια και 1 μήνα)

464 εμφανίσεις

International Journal of Recent Trends in Engineering, Vol. 1, No. 1, May 2009


Performance Analysis of Java-based Approaches
to Distributed Computing
S.R. Mangalwede
and Dr.D.H.Rao

Research Scholar, Dept. of Computer Sc. and Engg., Gogte Institute of Technology, Belgaum, India.
Principal, Gogte Institute of Technology, Belgaum, India.

Abstract - Distributed computing extends traditional
computing by allowing computational components to be
distributed across a heterogeneous network and seamlessly
interoperating with each other to perform a task. This paper
investigates three Java-based approaches to distributed
computing viz., Java RMI (Remote Method Invocation),
Java applet-servlet communication and Java Mobile Agents
(MA), using performance measurement parameters like
code size, latency, response time, partial failure and
concurrency, ease of development and discusses the benefits
of one over others. This study is aimed at investigating the
suitability of the approaches in different application
scenarios using a demonstrative example to analyze the
performance of these approaches to distributed computing.

Index terms - Distributed Computing, Servlet, RMI, Mobile
Distributed computing utilizes a network of many
computers, each accomplishing a portion of an overall
task, to achieve a computational result. Distributed
computing differs from local computing in the sense that
in local computing programs are confined to a single
address space. In contrast, in distributed computing
programs can make calls to other address spaces, possibly
on another machine. In the case of distributed computing,
nothing is known about the recipient of the call (except
the service it offers on its interface). For example, the
client of such a distributed object does not know the
hardware architecture on which the recipient of the call is
running, or the language in which the recipient was
Java features include simplicity, reliability, and
platform neutrality. As the potential for Java as a network
programming language increased, developers at Sun
Microsystems added support for networking, security and
multithreaded operations. All these features of Java make
it an excellent choice for distributed application
By providing a homogeneous view to a heterogeneous
group of machines and by safely allowing the dynamic
downloading of code into a running process, Java has
changed the usual set of assumptions that have governed
distributed computing systems. Coupled with a strongly-
typed language, the Java platform gives an environment
for developing distributed computing system.
As distributed computing became more widespread,
more flexibility and functionality was required than
Remote Procedure Calls (RPC) could provide. RPC
proved suitable for Two-Tier Client/Server Architectures
where the application logic is either in the user
application or within the actual database or file server. As
Three-Tier Client/Server Architectures gained ground,
where the application is split into client application
(usually a GUI – Graphical User Interface or browser),
application logic and data store (usually a database
server), the advantages started becoming obvious in the
form of reusable, modular, easily deployable
The following paragraphs briefly discuss each of the
three Java-based approaches to distributed computing
viz., RMI, Servlets and MA. Some of the characteristics
of these technologies that impact their decision are
Support for Objects, Statefulness of components,
Blocking versus non-blocking calls, Communication
Protocol, Speed, and Robustness [1].
The Java Remote Method Invocation system allows a
Java object running in one virtual machine to make
method calls on other Java objects in other virtual
machines, perhaps on a different physical machine. The
overall design of RMI has much in common with other
distributed object and remote procedure call systems.
However, since RMI assumes that the calls are made
from one Java object to another Java object, the system is
able to pass object arguments and return values by their
actual type rather than their declared type, allowing full
distributed polymorphism. If the class of such a passed
object is not present in the receiving machine, the system
allows the code for the type to be dynamically loaded.
The system also utilizes the garbage collection present on
the base platform to implement a distributed garbage
collection scheme, enhanced to be robust in the face of
network failures [2].
Java servlets are the basic building blocks of web
applications. A servlet receives a request object, extracts
parameters, if any, from it, processes application logic
that depends on the request parameters and finally
generates the response. We can extend this model by
building a larger web application having several servlets,

Supported by Visvesvaraya Technological University, Belgaum, India
International Journal of Recent Trends in Engineering, Vol. 1, No. 1, May 2009


with each servlet performing a well-defined independent
task. [3]
A Mobile Agent (MA) can be defined as an
autonomous, problem solving computational entity
capable of effectively performing operations in dynamic
unpredictable environments. Such environments are
known as multi-agent systems [4]. Agents interact and
cooperate with other agents. They are capable of
exercising control over their actions and interactions and
do not always have to wait for commands. An agent
adapts its behavior in response to the changing
environment. It can migrate from server to server in
heterogeneous networks. On each server, the agent
interacts with stationary services and other resources to
accomplish its mission. It can communicate to anticipate,
adapt and plan tasks. Its behavior consists of beliefs,
desires, and interaction depending on the place function
of an entity within an agent-based system. A mobile
agent consists of two different parts: the code itself,
which is composed of instructions that define the
behavior of the agent and its intelligence, and the current
state of execution of the agent. A mobile agent is not
bound to the system where it begins execution. It has the
unique ability to transport itself from one system in a
network to another. The ability to travel, allows a mobile
agent to move to a system that contains an object with
which the agent wants to interact, and then to take
advantage of being in the same host or network as the
object [5].
The rest of the paper is organized as follows: Section II
briefly describes the test bed environment used for
performing a qualitative and quantitative analysis of the
three approaches. In section III and IV, we elaborate the
characteristics of the application developed for the three
approaches and discuss the observations made in each of
the approaches with reasoning about the observations.
Section V summarizes the work presented here.
The experiment was carried out in two ways. The
entire sequence was performed on localhost and
observations were recorded. The same sequence of
operations was performed on a 10/100Mbps Ethernet
LAN (Local Area Network) consisting of 52 computers
with network traffic generated by those computers not
participating in the experiment pinging each other.
The application was developed using JSDK 1.4.2_13.
For hosting the servlets, we used Tomcat Application
Server 4.1.31-2. For developing and deploying mobile
agents we used Aglet Software Development Kit (ASDK)
2.0.2 [6]. The applications were coded using NetBeans
IDE 6.0.
We define a metric Elapsed Time (ET) as,
ET=L1 + PT + L2 + TT ------------------(1)
L1 is the latency at the client, L2 is the latency
at the server (or at both hosts in case of Aglets), PT is the
Processing Time for service, and TT is the trip time for
the request and response.

For performing a comparative study of the three
approaches, we developed a demonstrative application
that generates requests for certain service available

We implemented a random number generator as a
service that was made available as a remote method, as a
Servlet and as a service via an autonomous agent. The
client machine running as an RMI client, an applet or a
machine with agent hosting context makes use of the
service available remotely. The experimental setup is
shown in Figure 1.

Figure 1. Application Setup Scenario.

The experimental sequence is as follows:
For RMI:
The client machine running as an RMI client locates
the remote object, invokes the remote random number
generator service and starts the timer. The client obtains
the result, records the current time and calculates the
elapsed time.
For Applet/Servlet Communication:
The client browser downloads the applet, which in turn
invokes the Servlet from the its origin to obtain the result
of the service. The applet calculates the ET between the
request and the response.
For Aglets:
An aglet running in one aglet context coordinates with
another aglet running in another aglet context to obtain
the random number. The second aglet has the intelligence
to generate the same. The first aglet records the time for
obtaining the result back to its context and stores it as ET.
In each of the above scenarios, the experiment was
conducted both on the localhost as well as a LAN
environment. In each of the two cases, we tested the three
scenarios with number of requests
{10, 20, 30, 40 and
50}. We performed five trials with each request and
computed average. Table I shows the observations made
during experiments on localhost. Table II shows the
observations made during experiments on LAN.

International Journal of Recent Trends in Engineering, Vol. 1, No. 1, May 2009


Figure 2 and 3 depict the observations for different Java-
based approaches on localhost and LAN using line graph.
From the above results, we observe that both RMI and
MA perform similarly in both the cases. The size of the
MA has minimal effect on the network latency and the
round trip time, though the object serialization
mechanism of the agent has a significant effect on the
performance. Also, that the agent has to be instantiated at
the context to which it migrates contributes to the ET that
is slightly larger than that of RMI. RMI does not suffer
from this overhead. However, the important characteristic
of MA is its autonomy and ability to work even in
disconnected environment as it doesn’t use synchronous
However, when we compare the performance of
applet-servlet communication for distributed computing
applications with that of RMI and MA-based approach,
we can observe that the need for HTTP (HyperText
Transfer Protocol) request and HTTP response formation,
as well as the connection management contribute to the
large amount of time required for the applet-servlet

# of
RMI Servlets Aglets
Time in Milliseconds
10 93.8 249.8 37.6
20 109.2 449.8 100.2
30 125 786.8 156.8
40 144 1705 215.8
50 156.2 2887.4 247


# of
RMI Servlets Aglets
Time in Milliseconds
10 112.2 653 84.4
20 128.2 1625 197.8
30 156.4 2177.8 409
40 187.6 2609.2 487.6
50 203.4 3468.6 698

Comparison of different Java Approaches to Distributed
Computing (Expertiments conducted on Localhost)
10 20 30 40 50
Count of Requests generated
Time in Milliseconds

Figure 2. Experimental results on localhost.

Comparison of different Java Aproaches to Distributed
Computing (Experiments conducted on LAN)
10 20 30 40 50
Count of Requests generated
Time in Milliseconds

Figure 3. Experimental results on LAN

We used Codesize 1.0 [7], a Java utility application
that can retrieve the effective code size from .class files.
The code size of a .class file is the sum of its Method
Code block sizes [8]. Following is the result of running
Codesize utility on the applications developed for RMI,
Aglets and Applet-Servlet communication.

A. Code size for RMI Approach
Code Class Class
Nr size size files Location
1 46 772 1 RandomServer.class
1 20 433 1 RandomServerImpl.class
1 166 1372 1 RandomServerImpl_Skel.class
1 342 2834 1 RandomServerImpl_Stub.class
1 0 235 1 RandomServerIntf.class
1 143 1241 1 RandomClient1.class
Total Code Size: 717 Bytes

B. Code size for MA Approach
Code Class Class
Nr size size files Location
1 500 2775 1 Random2.class
1 139 1538 1 RClient.class
Total Code Size: 639 Bytes

C. Code size for Applet-Servlet Approach
Code Class Class
Nr size size files Location
1 802 4388 1 Newclientapp.class
1 123 1510 1 Rservlet.class
Total Code Size: 925 Bytes + 104 bytes of HTML file

As can be observed, the effective code size of Aglets is
comparable to that of RMI with the latter requiring more
code size due to generation of stub and skeleton classes.
International Journal of Recent Trends in Engineering, Vol. 1, No. 1, May 2009


However the code size of Applet-Servlet communication
application is the largest (not including the size of
supporting HTML file).
All the three approaches make use of transport layer
virtual circuit for the purpose of communication.
However, only RMI and MA are fully object oriented.
Applet-Servlet approach does not have object oriented
interface. Both RMI and Aglets make use of non-standard
ports, but as servlets use HTTP, well-known port is used
for applet-servlet approach. RMI communication uses
special stub and skeleton classes for each remote object,
and it requires a naming registry from which clients can
obtain references to these remote objects which can be an
overhead compared to the other two approaches. Security
is another important consideration and both RMI and
Applet-Servlet approaches have added security for client
and server by means of employing SSL (Secure Sockets
Layer). Security in MA approach is an area of active
research. However, a secure protocol doesn’t necessarily
translate into a secure system as most of the security
breaches take place by exploiting the defects in
implementation and not through protocol weaknesses.
Finally, as all the three approaches use Java, they can be
used to develop platform independent distributed
computing applications.

V. Conclusion
We presented a study of performance of three Java-
based approaches to distributed computing. Each of the
approach has its relative advantages and disadvantages.
However, MA approach may be considered over others as
the advantages of MA outweigh the disadvantages. The
autonomy, ability to operate in volatile, disconnected
network environments, and ability to collaborate
proactively with other MAs are striking features of MA
that are not available with other approaches considered.
In applications such as adaptive eLearning where
remotely available content should be delivered after
processing the learner profile and learning characteristics,
autonomy becomes an important issue and MA
technology seems a feasible approach as compared to
other approaches considered in this paper. However,
there is no “one-best” approach that fits all application
domains or needs. Perhaps the best solution is to use
every solution in the most appropriate way.
This work is supported partially by Visvesvaraya Technological
University (VTU) Research Grants Scheme: VTU/Aca-RGS/08-
09/7196. The authors acknowledge the support of VTU,
Belgaum, India.
[1] Distributed Computing Technologies –
Selecting an Appropriate Approach, Philip Maechling,
Web Services Workshop, UNAVCO/IRIS Joint Workshop, 8
June 2006.
[2] Ann Wollrath, Jim Waldo, Roger Riggs, "Java-centric
distributed computing," IEEE Micro, vol. 17, no. 3, pp. 44-
53, May/Jun, 1997].
[3] Subrahmanyam Allamaraju, Karl Avedal,
Professional Java Server Programming, J2EE Edition,
Shroff Publishers, ISBN: 81-7366-300-9.
[4] T.A. Montgomery, E.H. Durfee, “MICE: A Flexible Test
bed for Intelligent Coordination Experiments”,
Proceedings of the 1989 Distributed Artificial Intelligence
Workshop, pp.25-40, 1989.
[5] Danny B. Lange, “Mobile Objects and Mobile Agents: The
Future of Distributed Computing?,” Jul (Ed.): ECOOP’98,
LNCS 1445, pp.1 -12, 1998.
[6] IBM Aglet Software Development Kit (Open Source),
[7] Codesize 1.0 Utility,
[8] JVM Specification,