Mobile active objects in Java

Baomin Xua,*, Aiqin Xub

aSchool of Computer and Information Technology, Beijing Jiaotong University, Beijing 100044, ChinabInstitute of Electronic Technology, The PLA Information Engineering University, Zhengzhou 450004, China

Received 22 July 2002; revised 29 October 2003; accepted 29 October 2003

Abstract

Mobility is a natural ability of Java objects as they can be easily serialized and transmitted between Java virtual machines, however,

mobility is not provided in the standard Java programming environment. We design a metacomputing environment for Distributed, Parallel

and Concurrent computing (JDPC) based on the extension to the standard Java library. JDPC supports active objects as the basic units of

activity and distribution used for building applications using JDPC. This paper investigates the design, implementation and performance of

mobility of active objects in JDPC. The migration is done in a scalable and secure way based-on JDPC. It has the ability to easily migrate

computation, especially in heterogeneous environments. Moreover, it can be used for dynamic load balancing and dynamic deployment

purposes to gain improved performance and flexibility of distributed applications.

q 2004 Elsevier Ltd. All rights reserved.

Keywords: Mobility; Active object; Distributed computing

1. Introduction

Mobility has recently received a lot of attention because

of its wide application [1]. Mobility means the movement of

an active entity from one machine to another during

execution. Such mobility is a key concept for dynamic

load balancing [2–5] to gain better performance from a

group of processors than what may be gained by schemes

simply allocating processes to processors at running time.

Mobility has been examined at different levels: from

thread or task-level mobility within multiprocessor

systems [6], and process or object mobility within a

distributed system [7] to host mobility within a discon-

nected network [8,9].

Process mobility is concerned with the relocation of

active processes between nodes within a distributed or

parallel system. One of the most important issues in process

mobility is that of state transferal. Process mobility can

offers improved performance over process allocation

schemes. By allowing the utilization of idle or lightly

loaded processors, dynamic load balancing across a group of

processors may be achieved. In addition to load balancing,

process mobility allows for small processes to be migrated

to sites of very large data files with improved reliability.

The granularity of mobility, however, can be reduced to a

language level object from the process. Work on object

mobility resembles most closely that on process mobility.

Mobility in distributed object systems is also useful as it can

provide such properties as load balancing, code to data

movement, fault tolerance, and migration to stable storage. In

a distributed system, these properties are important as they

can help alleviate latency issues and increase performance

within the system. Additionally, they provide more flexi-

bility in the programming of distributed systems by relaxing

static location restrictions. Location transparency removes

the need for client objects to explicitly know or define the

location of a server object when communicating.

Mobility can be implemented as a service provided by an

operating system [10]. However, this severely limits its

usefulness in a heterogeneous environment such as the

Internet. Another solution is to use a library such as Ajents

[11], which provides an application with all of the necessary

features.

Our focus is on heterogeneity and flexibility that come

with implementing mobility at the programming language

level. In our system, the application programmer can

implement new migration strategies by reconfiguring

the migration mechanism. One of the strengths of our

design is that migration is completely captured by the

semantics of the programming language. This makes it easy

0965-9978/$ - see front matter q 2004 Elsevier Ltd. All rights reserved.

doi:10.1016/j.advengsoft.2003.10.007

Advances in Engineering Software 35 (2004) 231–235

www.elsevier.com/locate/advengsoft

* Corresponding author.

to comprehend the program and troubleshoot it if it does not

behave as expected.

The paper is organized as follows: Section 2 provides a

brief introduction to JDPC metacomputing environment,

while Section 3 gives the basic conceptions about relocation

transparency. Section 4 describes and discusses how we

support migration of active objects in JDPC. Result from a

benchmake is presented in Section 5. A conclusion will be

given in Section 6.

2. The JDPC metacomputing environment

A huge gap, which forbids code reuse in order to build

distributed applications from multithreaded applications,

exists between multithreaded and distributed Java appli-

cations. Both Java RMI and Java IDL, two examples of

distributed object libraries in Java, put a heavy burden on

the programmer because they require deep modifications of

existing code in order to turn local objects into remote

accessible ones. In these systems, remote objects need to be

accessed through some specific interfaces. As a conse-

quence, these distributed objects libraries do not allow

polymorphism between local and remote objects, which is

required for a metacomputing framework. Such polymorph-

ism makes it possible for the programmer to concentrate

firstly on modeling and algorithmic issues rather than lower

level tasks such as object distribution, mapping and load

balancing. It has important consequences on the topology of

the application.

To meet the above requirements, JDPC is developed.

Unlike other metacomputing environment, we use a pure Java

language rather than inventing a new language with object

mobility primitives, and we require no any changes to the

Virtual Machine, standard runtime library, or operating

system. It is based on the RMI [12] Java standard library,

but offers many added features such as active objects,

asynchronous calls and multi-threaded, and distributed

programming etc.

In JDPC, we would like to transparently give a standard

Java object some new behaviors: location transparency,

activity transparency and advanced synchronization mech-

anism. Location transparency provides polymorphism

between local and remote objects. Activity transparency

hides the fact that methods invoked on an active object

actuallyexecute inaseparate thread. This is achieved byusing

transparent future objects. Advanced synchronization mech-

anisms allow an easy and safe implementation of potentially

complex synchronization policies. To add these new beha-

viors to a standard Java object, JDPC uses composition for

implementation of multiple behaviors while multiple inter-

face inheritance is used for declaring these behaviors.

In JDPC, any standard object (Fig. 1(a)) could be

extended through composition with a pair of objects: a

proxy and a body (Fig. 1(b)). The active objects are actually

composed of two objects: a proxy and a body: The main

responsibility of proxy is to generate future objects for

representing future values, transform calls into request

objects and perform deep copy of passive objects passed as

parameters. The proxy also often acts as a forwarder for

locating the mobile object and is a convenient place for

performing security-related actions. The body receives

these reified calls and stores them into a queue of pending

calls. It then executes them in an order specified by a given

synchronization policy. If none is provided, the body

defaults to a FIFO behavior.

3. Relocation transparency

One of the most important issues when dealing with

mobility within a distributed object system is that of locality

and reference management [7]. Objects within a mobile

object system may reference to other objects within the

system. When these objects move, it is important that any

references to them remain valid and that any referencing

objects always be able to contact the mobile object

regardless of the mobile object’s location.

Relocation transparency in distributed system means that

a reference to a mobile object is updated transparently when

the object migrates. A relocation transparent reference is

always valid regardless of the mobile object’s location.

As said above, JDPC is a Java library that utilizes Java

RMI for its communications mechanisms. It relies on the

naming models of Java RMI to perform its reference

management. As to Java RMI system, clients communicate

with servers using an intermediate registry that is able to

locate objects and store bindings between names and server

objects. Names within a java RNI system are in the form of

URLs, which contain information about the host, entry point

and object registry.

In JDPC, in order to easily implement and handle

relocation transparency, node, i.e. active object location, is

defined to host several active objects. It provides an

abstraction for the physical location of a set of active objects.

An active object can be bound to a node either at creation time

or as the result of a migration. It is possible to pass a third

Fig. 1. Standard and JDPC models of contrast.

B. Xu, A. Xu / Advances in Engineering Software 35 (2004) 231–235232

parameter on to the call to newActive in order to create the

new active object on a specific JVM which is identified using

a node object, possibly remote. If that parameter is not given,

the active object is created in the current JVM and is attached

to a default node. Once an active object is created, its activity

and its location are completely transparent. As a matter of

fact, any active object can be manipulated as if it were a

passive instance of the same class.

Additionally, each node is identified by a nodeURL,

which is formed using the hostname hosting the JVM where

the node located is and the name of the node. This URL is

then registered with rmiregistry. The node factory allows to

create or lookup nodes. The method newActive can carry a

parameter of nodeURL as a string or a node object that

points to an existing node.

Active objects, just like nodes, can also named in order to

be registered and subsequently located. An additional way

to register and locate nodes or active objects is to use the

Lookup Service of Jini. New participants will then be able to

dynamically discover nodes or active objects, and join an

on-going JDPC computation.

4. The migration of active object

As active objects, which perform their computations on

the physical nodes, carry out computation in JDPC we can

balance load between physical nodes by migrating active

object from heavily loaded nodes to lightly loaded nodes.

The migration of active objects provides an approach to load

balancing, which in the end results a balanced amount of

computation per processor, at minimizing inter-processor

communications or both.

4.1. The migration model

The migration model in JDPC is designed to support

active object migration between nodes. These services

include the dynamic creation of mobile active objects, and

migration and relocation services for mobile active object.

Migration is accomplished by check pointing objects

between invocations to provide intermediate views of

the state of the object. An object is only able to migrate

between method invocations. This is the model that is used

in the implementation of the JDPC. At present, JDPC

provides a default active object migration algorithm called

Deep-Lazy-Copy. On the one hand, when an object in a

subsystem calls a method on an active object, the

parameters of the call may be references on passive objects

of the subsystem, leading to shared passive objects. This

requests that passive objects passed as parameters of calls

on active objects are always passed by Deep-Copy. On the

other hand, the active object is only transferred from its

source host to destination host as requested, i.e. Lazy-Copy.

For Deep-Lazy-Copy, the following tasks are performed

when an active object is migrated:

1. The decision to migrate the active object is made;

2. The execution of the active object on the source host is

suspended at some point;

3. The entire state of the active object is transferred. This is

comprised of the active object itself, all its pending

requests, all its passive objects and all its future objects;

4. The entire state of the active object is reconstructed on

the destination host;

5. The execution of the active object on the destination

host is resumed.

In sum, the process of object migration is divided into

two stages: the first stage is object suspension. Before an

object can be migrated it must be suspended from accepting

further invocation requires. The state of suspension

continues until all previously executing invocations have

completed. All queued invocations are recorded in their

order of receipt. After suspension is complete, migration of

object from its current location to its destination location.

After both of these stages have completed successfully the

object has completed migration.

Fig. 2 shows all migration phases in detail. Migration

phases are numbered to indicate their execution order. As is

shown in Fig. 2, migration is initiated through a migrateTo()

method on the active object. A Future Object instance with a

quite similar structure as the active object is created when

Fig. 2. Migration phase.

B. Xu, A. Xu / Advances in Engineering Software 35 (2004) 231–235 233

the active object leaves a host. Then the original active object

is deleted. This Future Object acts as a placeholder for the

result of the not-yet-performed method invocation. As a

consequence, the calling thread can keep executing its code,

as long as it does not need to invoke methods on the migrated

object, in which case the calling thread is automatically

blocked if the result of the method invocation is not yet

available. Any call to a Future Object is reified in order to be

blocked if the Future Object is not yet available and later

executed on the result object. This is the inter-object

synchronization policy in JDPC. The above procedure is

fully transparent to the caller. And future object can be

considered as a distributed solution to the location problem.

Furthermore, contrary to the location server, in the absence of

network or host failure, a message will finally reach any

mobile object.

Of course, Deep-Lazy-Copy is conceptually a safe

migration algorithm, lending itself to a relatively straightfor-

ward implementation. Since the implementation of Deep-

Lazy-Copy relies on the serialization to send the object on the

network, i.e. it can be transported in a byte form that can be

successfully interpreted and converted back into object form.

However, not all the objects in the Java language are

serializable, some technologies should be adopted to deal

with the non-serializable attributes of the object. Our

approach to this problem is: When a Not Serializable

exception is thrown; we first identify the variable respon-

sible, i.e. the one that is not serializable. Then, in front of the

declaration of this variable, we put the keyword transient.

This indicates that the value of this variable should not be

serialized. After the first migration, this field will be set to

null since it has not been saved. So we have to rebuild it upon

arrival of the active object on its new location. Providing the

active object with the standard method can easily do this.

4.2. Migration example

Fig. 3 gives a before-and-after illustration of active

object mobility. In Fig. 3(a), active objects AO1 is on host A,

passive objects PO1 and PO2 are also on host A, whereas

active object AO2 resides on host B. Object AO1 is invoked

and passed on to host B. The migration of object AO1 to host

B involves all of its pending requests, its passive objects

and its future objects. These objects will be migrated

automatically when the active object AO1 is migrated. At the

same time, the reference relations among objects will be

maintained. For instance, on host B, we replace remote

reference with the local reference from passive object PO2 to

active object AO2 because they now reside in the same VM;

we replace local reference with the remote reference from

passive object PO1 to active object AO1 because they now

reside in the different VM. The state after migration is

shown in Fig. 3(b).

Here is a more detailed description about the creation and

migration of active object AO1.

1. To implement the migration of an active object in

IDPC, serialization technology, which relies on the

serialization to send the object on the network, is

adopted. Therefore, the given object must implement

the serializable interface so that the active object

created will be able to migrate. Codes look like this:

2. public class AO1 implements Serializable {

3. …

4. }

5. JDPC automatically creates a stub/skeleton pair for

active objects. When the stub is instanced on the remote

node, its constructor ascends the ancestor chains, thus

calling its parent constructor. So a no-args constructor

must be provided in the given object to avoid side

effects during the creation of active object. Codes look

like this:

6. public AO1() {

7. }

8. To migrate, the given object must have a method,

which contains a call to the migration primitive. This

call must be the last one in the method, i.e. the

method must return immediately. To make this

object move, it is necessary to call its moveTo()

method. Codes look like this:

9. public void moveTo(String t) {

10. try {

11. JDPC.migrateTo(t);

12. } catch (Exception e) {

13. e.printStackTrace();

14. }

15. }

Fig. 3. Object movement: (a) before migration; and (b) after migration.

B. Xu, A. Xu / Advances in Engineering Software 35 (2004) 231–235234

5. Performance

To measure the migration overhead of active object, we

designed a simple application which can make an active

object migrate, along with objects that are not serializable.

In the example, an active object creates a window and draws

a picture inside. It will migrate along with its window from

one host to another, always in the same order and always

ends where it first started, equivalent to the fact that a

mobile object makes one or more turns on a virtual ring of

computers. The object is initially out of the ring, and thus

has to migrate first before actually starting its journey.

We ran the experiment on a pair of Pentium IV PC, and

connected by a 10 Mbps 10 Base-T Ethernet. When an

active object migrates, the cost can be divided into three

segments: the cost of the method invocation, the cost in

migration itself, and the cost of relocation after the

migration is completed.

We have measured the time taken to go through the

whole itinerary, including the initial migration. The startup

time, where all objects are created, has not been taken into

account. Fig. 4 shows the average time of one migration

against the number of turns on the ring.

As time goes by, the average time consuming of a

migration actually decreases. This can easily be explained

by the fact that on the first round on the ring, all the JVMs

must load the class corresponding to the mobile object:

when benchmarking mobile objects system, one should not

forget that there is always a start up time if the host is visited

for the first time, even if all the class files are available

locally.

We can infer that the average migration time should be

around 300 ms on a LAN for some given network

conditions. However, these results are heavily dependent

on the commutating power. By the way, our other

experiments imply that performance of some applications

may be improved significantly by active object migration.

6. Conclusion

We have discussed the migration of active objects, which

are taken for granted as an essential part of the JDPC library

which extensions to the standard Java library. Our approach

does not require the use of a special language, nor does it

require changes in Java virtual machine, standard runtime

library. Moreover, the implementation enables active

objects to communicate using two-way asynchronous

message passing, which further provides better perform-

ances over other libraries for mobile computations. Our

experiences with JDPC tell that the library can sufficiently

support applications development of a wide variety.

Acknowledgement

Supported by RENCAI Research project of Beijing

Jiaotong University under grant no. 2003RC043.

References

[1] Chess DM, Harrison CG, Kershenbaum A. Mobile agents: are they a

good idea? Technical Report, IBM T.J. Watson Research Division;

March 1995.

[2] Eager DL, Lazowska ED, Zahorjan J. Adaptive load sharing in

homogeneous distributed systems. IEEE Trans Software Engng 1986;

12(5):662–75.

[3] Nuttall M. Survey of systems providing process or object migration.

Technical Report DoC 94/10, London: Imperial College; May 1994.

[4] Kremien O, Kramer J, Magee J. Scalable load-sharing for distributed

systems. In: Proceedings of HICSS-26, Hawaii; Jan. 1993. p. 632–41.

[5] Simon SH. Jove: a dynamic load balancing framework for adaptive

computations on an SP-2 distributed multi-processor. In: NJIT CIS

Technical Report, New Jersey; Nov. 1994.

[6] Jul E, levy H, Hutchinson N, Black A. Fine-grained Mobility in the

emerald system. ACM Trans Comput Syst Feb. 1988;4(1):109–33.

[7] Milojicic D, Douglis F, Wheeler R. Mobility: Processes, Computers,

and Agents. Reading, MA: Addison-Wesley; 1999.

[8] Awerbuch B, Peleg D. Tracking of mobile users. J ACM 1995;42(5):

1021–58.

[9] Ioannidis J, Maguire GQ. The design and implementation of a mobile

internetworking architecture. Proceedings of the USENIX Winter

Technical Conference; Jan. 1993. p. 491–502.

[10] Nuttall M. A brief summary off systems providing process or object

migration facilities. Operat Syst Rev 1994;28(4):64–80.

[11] Izatt M, Chan P, Brecht T. Ajents: towards an environment for

parallel, distributed and mobile java applications. Proceedings of the

ACM Symposium on Principles and Practice of Parallel Program-

ming; 1999.

[12] Sun Microsystems, Inc. Java Remote method invocation specification.

January 1998. available from http://www.sun.com/.

Fig. 4. Cost of one migration.

B. Xu, A. Xu / Advances in Engineering Software 35 (2004) 231–235 235