Mobile Objects in Java

{\it Mobile Objects in Java} provides support for object mobility in Java. Similarly to the RMI technique, a notion of client-side stub, called startpoint, is used to communicate transparently with a server-side stub, called endpoint. Objects and associated endpoints are allowed to migrate. Our approach takes care of routing method calls using an algorithm that we studied in. The purpose of this paper is to present and evaluate the implementation of this algorithm in Java. In particular, two different strategies for routing method invocations are investigated, namely {\it call forwarding} and {\it referrals}. The result of our experimentation shows that the latter can be more efficient by up to 19%.


Introduction
Over the last few years, mobile agents have emerged as a powerful paradigm to structure complex distributed applications.Intuitively, a mobile agent can be seen as a running software that may decide to suspend its execution on a host and transfer its state to another host, where it can resume its activity.Cardelli [5] argues that mobile agents are the right abstraction to develop applications distributed across "network barriers", e.g. in the presence of firewalls or when connectivity is intermittent.In Telescript [17], software migration is presented as an alternative to communications over a wide-area network, in which clients move to servers to perform computations.Lange [16] sees mobile agents as an evolution of the client-server paradigm, and enumerates several reasons for using software mobility.
It is a challenge to design and implement mobile agent applications because numerous problems such as security, resource discovery and communications, need to be addressed.Therefore, we introduce Mobile Objects in Java, a middleware that helps implement mobile agent systems by providing a concept of mobile object.Its specific contribution is a communication mechanism consisting of the invocation of methods on objects that may be mobile.
Our motivation has been driven by developments in distributed computing over the last couple of decades.Successive paradigms such as remote procedure calls (RPC) [3], method invocation in Network Objects [4] and remote method invocation (RMI) in Java [12], amongst others, abstract away from the reality of distribution.They successively provided programmers with new and more sophisticated abstractions.RPC provides homogeneity, by its marshalling and unmarshalling of data structures using data representation suitable for heterogeneous platforms.Network Objects offers memory uniformity because remote method invocations are syntactically identical to local ones and garbage collection takes care of local and distributed objects.Java RMI provide code propagation because the programmer no longer needs to replicate code to remote machines, but instead Java RMI is able to load code dynamically.
The next logical step is to hide the location and movement of objects.A similar approach has also been adopted by the network community, which devised the next generation of the IP protocol (IPv6) with support for mobile addresses [14].
There exists an incremental approach to introduce mobility into an infrastructure that is unaware of mobility [16,7].It consists of associating each mobile entity with a stationary home agent, which acts as an intermediary for all communications.While this approach preserves compatibility with an existing infrastructure, introducing an indirection to a home agent for every communication puts a burden on the infrastructure; this may hamper the scalability of the approach, in particular, in massively distributed systems, such as the amorphous computer [27] or the ubiquitous/pervasive computing environment [1].Free from any compatibility constraint, we adopted an algorithm to route messages to mobile agents that does not require any static location: the theoretical definition of this algorithm based on forwarding pointers and the proof of its correctness have been investigated in a previous publication [22].
The purpose of this paper is to present Mobile Objects in Java, an implementation of the algorithm, which offers transparent method invocation and distributed garbage collection for mobile objects.By transparent, we mean that mobile and non-mobile objects present a same interface, which is independent of the object location and its migratory status.Distributed garbage collection ensures that an object, whether mobile or not, can be reclaimed once it is no longer referenced.While implementing our algorithm, it became clear that two strategies could be adopted, which we named call forwarding and referrals; we present these strategies and evaluate their performance through a benchmark.
This paper is organised as follows.First, we provide more motivation for mobile agents by presenting two promising application domains in Section 2.Then, in Section 3, we summarise the algorithm we have investigated in [22].In Section 4, we describe its implementation in Java, providing a transparent interface to mobile objects.We then discuss two different methods for routing method invocations, namely forwarding and referrals, in Section 5.In order to compare these techniques, we devise a synthetic benchmark, and analyse results in Section 6.Finally, we compare our approach with related work in Section 7.

Motivation
In this Section, we provide further motivation for mobile agents.We describe two promising applications where mobile agents act semi-autonomously on behalf of users.The reasons for doing so, however, differ substantially in the two applications.
Digital Library Yan and Rana [30] present a highlevel service for a digital library of radar images of the Earth.The library is composed of a set of confidential images and associated annotations with attached ownership.They extend a Web-based client-server architecture with mobile agents that perform tasks on behalf of users and that are able to migrate to a predefined itinerary of hosts.
After being dispatched, agents migrate securely, with data, code and state to an itinerary of servers that may have relevant data and services.Agents become independent of the user who created them: they can survive intermittent or unreliable network connections.Mobile agents are beneficial for several reasons.(i) They avoid the delivery of large volume of scientific data required for data mining of images; (ii) They help maintain confidentiality and ownership of data, by being run through security checks, ensuring that they have the rights to access the data; (iii) They are allowed specific queries on the library according to the "security level" they were granted.

Mobile Users
The context of the Magnitude project [24] is the "ubiquitous computing environment" [27] where embedded devices and artifacts abound in buildings and homes, and have the ability to sense and interact with devices carried by people in their vicinity.Applications running on mobile devices interact with the infrastructure, and find and exploit services to fulfill the user's needs.However, communications between mobile devices and the infrastructure have some limitations, in the form of intermittent connectivity and low bandwidth.Fur-thermore, processing power and memory capacity of compact mobile devices remain relatively small.As a result, such an environment would prevent the large scale deployment of advanced services that are communication and computation intensive.
We adopt mobile agents as proxies for mobiles users.As illustrated by Figure 1, we utilise mobile agents, as semi-autonomous entities, which can migrate from mobile devices to infrastructure locations to take advantage of the resources their specific tasks require; mobile agents perform their tasks on the infrastructure, possibly involving further migration, and then return results back to mobile users.Summary Both scenarios use the idea of mobile agent, as a semi-autonomous proxy for a user.If granted the right to do so, mobile agents may migrate to new locations, where they can take advantage of local resources.

Message Routing Algorithm
In this section, we summarise the message routing algorithm for mobile agents that we formalised in [22].We consider a set of mobile objects and a set of sites (in our case JVMs) taking part into a computation.Each mobile object is associated with a timestamp, which is a counter incremented every time the object changes location.Each site keeps a record of the location where every mobile object known to the site is thought to be, and of the timestamp the object had at the time.Therefore, in a system composed of several sites, sites may have different information about a same mobile object (depending on how fast location information is propagated between sites).
The algorithm proceeds as follows.When a mobile object decides to migrate from a site to another site ¡ , it informs of its intention of migrating; a transportation service is used to transport the object to ¡ .When the mobile object arrives at ¡ , its safe arrival is acknowledged by informing its previous site of its new location and of its new timestamp; site can then update its local table with the mobile object's new position and timestamp.
Mobile objects delegate to sites the task of sending messages to other objects.When a site receives a request for sending a message to a mobile object, it searches its table in order to find the object location.If the object is local, the message is passed onto the object.
If the object is not local, but known to be at a remote location, the message is forwarded to the remote location.
As migration is not atomic, a mobile object may have left a site, but the acknowledgement of its safe arrival may not have been received by the site yet.In such a case, the site temporarily has to enqueue messages aimed at the object; as soon as the acknowledgement arrives, delayed messages may be forwarded.
Timestamps are used to guarantee that sites always update their knowledge about mobile objects with more recent information than the one they currently have.If a site receives information with a timestamp that is smaller than the timestamp in its table, the received information is discarded.Such a timestamp mechanism is mandatory to avoid cyclic routing of messages [22].
In the algorithm described so far, a mobile object leaves a trail of forwarding pointers during its migration.In order to reduce the length of the chain of forwarding pointers, routing information and associated timestamp may be propagated by any site to any site; timestamps are again used to guarantee that the most recent information is stored in routing tables.In the rest of the paper, we discuss an implementation of this abstract algorithm.

Implementation in Java
In Java RMI [12], an object whose methods can be invoked from another JVM is implemented by a remote object.Such a remote object is described by one or more remote interfaces.Remote method invocation is the action of invoking a method of a remote interface on a remote object.In practice, a stub acts as a client's local representative or proxy for a remote object.The stub of a remote object implements the same interface as the remote object: when a method is called on the stub, arguments are serialised and communicated to the remote object 1 , where the method can be called; its result is transmitted back to the stub and becomes the method call result.A very desirable feature of this approach is that local and remote method invocation share an identical syntax.Now, we present an approach in which remote objects are allowed to be mobile, but clients still use the same stub-based method invocation mechanism, making them unaware of the location and movement of the mobile object.

Startpoints and Endpoints
Figure 2 displays the different entities of our implementation.The right-hand side of the picture represents the "server-side" on JVM , composed of a mobile object; the left-hand side is concerned with the "client-side" on JVM¡ .
We adopt Nexus terminology [8], and we respectively name startpoint and endpoint the client-side and serverside representatives of a remote object.A mobile object is specified by an interface, which must also be implemented by its startpoints.Startpoints contain an RMI stub representing the current location of a mobile object, and permit direct communication with the endpoint; the endpoint passes messages to the mobile object.Additionally, the startpoint contains the mobile object's timestamp ¢ .(The endpoint also has the same timestamp ¢ .) Figure 3 displays the new configuration after the mobile object has migrated to JVM£ .There exists a new endpoint acting as a server-side representative at the new location.Its timestamp is ¢ ¥¤ §¦ following its increase after migration.The endpoint is referred to by a startpoint with timestamp ¢ ¨¤ ©¦ , which is sent to JVM as an acknowledgement to the safe arrival at JVM£ .This startpoint is used by the endpoint on JVM as a forwarding pointer to the new object location.When a method is activated on the startpoint on JVM ¡ , the call is still transmitted to JVM , where the endpoint is aware that the object has moved to JVM£ and uses the same mechanism to forward the call.
As opposed to simple message passing, a remote method invocation is expected to return a result 2 .In a first instance, our implementation is based on call forwarding and the result is propagated back along the chain to the initial startpoint where the method call was initiated.
In such an algorithm, it is important to reduce any chain of forwarding pointers in order to reduce the cost of method invocation, but also to make the system more resilient to failures.In Figure 3, when JVM has to forward a call to JVM£ , JVM knows that information on JVM¡ is out of date.Therefore, when the result is returned to JVM ¡ , we can also return updated information about the mobile object location.To this end, we made the remote interface implemented by endpoints differ-ent from the interface implemented by mobile objects: we return not only the "usual result", but also the new object location.
Returning updated location information at the same time as returning results may not propagate information soon enough, because processing on the server may be long.Therefore, independently, we might like to inform previous JVMs in the chain about the location of the mobile object.Since regular remote method invocation does not give any information about the method caller, we provide, as extra arguments, the stubs pointing to the JVMs involved in the chain.
In summary, a startpoint implements the same interface as a mobile object.An endpoint has a derived interface passing extra routing information, both during the forward call and during the return of a result.The RMIstub encapsulated in the startpoint implements the same interface as the endpoint.
For the sake of illustration, let us consider the method talk specified in the interface Talker implemented by a mobile object.The extra argument from is a list of RMI stubs to the JVMs that were involved in the passing of the current method call.The type int Result encapsulates an int as well as new routing information.We have implemented a stub compiler which takes care of generating such interfaces.It also creates the definitions of the startpoint and endpoint classes.

Object Migration
We provide a new abstract class UnicastMobileObject, which encapsulates the behaviour common to all mobile objects.A mobile object must be defined as a subclass of UnicastMobileObject, from which two methods can be inherited: A mobile object can initiate its migration to another JVM, identified by a RMI-style URL, using the method migrate.The current object content will be serialized in conjunction with an extra argument.Upon an object's arrival, the method install is activated with the state argument passed to migrate.Both methods are defined as "protected" to guarantee that they are invoked only under the object's control.
The Java object model does not make any guarantee regarding which thread executes remote methods.Therefore, for a single object, there may be several threads executing in parallel when a request for migrating is issued by one of them.As Java does not support thread migration, it is not possible to suspend the execution of all threads in order to resume them at the destination.Instead, we allow an object to migrate when there is only one thread executing a method of this object.It is therefore the programmer's responsibility to synchronize and terminate threads currently executing in parallel, and, if necessary, to save their state in a seri-alizable field of the object.
Mobile Objects in Java also introduce the concept of "platform", a JVM that runs mobile objects securely.A platform is a RMI UnicastRemoteObject which advertises its presence by binding itself with a RMI-style URL (specified at construction time) in a RMI-registry.This is such a URL which is expected as a first argument by migrate.Hooks are provided to perform security checks before executing objects in their sandbox [20].

Startpoint Deserialisation
In our system, on a given platform, there is at most one instance of a startpoint that refers to a given mobile object.In order to preserve this invariant, each platform maintains a table of all the startpoints it knows, which is updated when startpoints are deserialised.(We use the Java method doReadResolve [13] to override the object returned from the stream.) A desirable consequence of this implementation is that all objects using a specific startpoint share the benefit of the most recent routing information for that startpoint.The table of startpoints is a hash table, using a unique name given to mobile objects as a hashing key.This table uses weak references [11] to guarantee that startpoints do not remain accessible longer than necessary.As a result, we ensure that mobile objects may be properly garbage collected.

Clearing Routing Information
Routing information has to be cleared when it is no longer needed.Indeed, platforms run for a long period of time and host many visiting mobile objects, which leave forwarding pointers as they migrate to their next destination.We need to ensure that routing tables do not become filled with unnecessary routing information.
We have observed [22] that the task of clearing routing tables is equivalent to the distributed termination problem [25].A forwarding endpoint is allowed to be cleared if it can be proved that no other platform will ever forward method calls to it.This may be implemented using a distributed reference counting algorithm [23,25].In particular, RMI provides a method Unreferenced for remote objects which is called when there is no remote reference to this object [12].When this method is called on an endpoint, it may be unexported, and the reference to the next startpoint in the chain may be lost.Note that this mechanism can only work if tables of startpoints contain weak references to these.Otherwise, if startpoints remain live, the RMI-stubs they contain will also remain live, which will prevent the call of the Unreferenced method on the associated endpoints.

Forwarding vs Referrals
In our theoretical algorithm [22], messages are routed individually; a reply would be regarded as a separate message to be routed independently.The view that we have adopted for Mobile Objects in Java differs slightly because it is based on the remote method invocation paradigm: methods are invoked and are expected to produce a result.In the previous section, we showed that the result could be propagated backwards along the chain of forwarding pointers left by the mobile object.
Long chains of remote method invocations offer too little resilience to failures of intermediary nodes.Instead of forwarding a method call, an endpoint could throw an exception indicating that the mobile object has migrated.The exception could contain the new startpoint pointing at the mobile object location.
The approach consisting of throwing an exception containing a new startpoint, instead of forwarding a call, is similar to the referral mechanism [9] used in distributed search systems such as Whois++ [26] and LDAP [28].It then puts the onus on the method invoker to re-try the invocation with the next location of the object; once the object has been reached, the result may then be returned to the caller directly.In our implementation, the startpoint is in charge of re-trying a method invocation until it becomes successful.Therefore, from the programmer's viewpoint, there is no syntactic difference between the two approaches.An option passed as argument to the stub compiler specifies whether code has to be generated for referrals or for call forwarding.In the rest of the paper, we compare the performance of the two approaches.

Benchmark
The scientific programming community has a tradition of adopting benchmarks to evaluate the performance of computers; for instance, the Linpack Benchmark is a numerically intensive test used to measure floating point performance.Unfortunately, we lack benchmarks specifically suited to evaluate routing algorithms for mobile objects.This may be explained by the relative novelty of the concept of mobile object, and the inexistence of widely accepted applications for mobile agents.In a previous paper [23], we observed that there was no recognised benchmark for evaluating distributed garbage collectors; therefore, we designed some synthetic benchmarks for such a type of distributed algorithms.We propose to adopt a similar approach here.
A synthetic benchmark is an abstraction of a real program, where routing of messages may have an impact on the performance of the computation.In our benchmark, we measure the cost of invoking a method on a mobile object that has changed location since the last time the method was invoked on it.In the context of the Magnitude architecture of Section 2, such a benchmark is reminiscent of the communications one may have with a mobile agent visiting several locations to perform a task.
Figure 4 summarises the "Itinerary Benchmark".An Itinerary consists of platforms ¡ £¢ ¥¤ §¦ ¨¦ §¦ ©¤ ¡ ¡ to be visited by a mobile object.A platform ¡ , not part of the itinerary, is used to initiate invocations of a method m on the remote mobile object.Every method invocation takes as argument a list of platform identifiers  that the mobile object has successively to migrate to; an itinerary is completed when the mobile object returns to the first platform ¡ ¢ .As method m is invoked on the mo- bile object, it spawns a thread responsible for migrating the mobile object to platforms, while method m terminates in parallel.On platform ¡ , we measure the time taken to perform all method calls necessary to complete an itinerary.Figure 5 illustrates the execution of the Itinerary benchmark over 10 platforms (5 rather heavily loaded workstations/servers each running 2 JVMs), connected by a local area network.Each method call forced the object to migrate to one new location.We ran the same benchmark using both the call forwarding and the referrals techniques.We can see that in this specific instance, referrals are on average 9% faster than call forwarding, over 200 itineraries.We should observe the abnormal duration of the first itinerary in Figure 5: indeed, it can be up to an order of magnitude slower than the others since it forces object byte-code to be loaded dynamically as the mobile object visits each platform for the first time.
In Figure 6, we summarise our results, which we discuss now.Several variants of the Itinerary benchmark were considered.
(i) We always ran the Itinerary benchmark on 10 platforms.In one case, the platforms executed on 5 rather heavily loaded workstations/servers each running 2 JVMs) connected by a 100Mb local area network (Notation: LAN).In the other case, the platforms executed on 5 nodes of a cluster (Linux 2.2, 450 Mhz) with dedicated 100Mb network, with each node running 2 JVMs (Notation: Cluster).
(ii) The partitioning of the platforms may be deterministic or non-determinisic.In the former case, the object systematically visits platforms in the same order (Notation: Sequential).In the latter case, the order of platforms is decided randomly for each itinerary (Notation: Random).
(iii) We ran the Itinerary benchmark using both the call forwarding (Notation: CF) and the referrals techniques (Notation: Ref ).
(iv) When a mobile object migrates to successive locations, its new position can be acknowledged to all its previous locations (Notation: Eager Acknowledgement), or to its directly previous location only (Notation: One Acknowledgement).
In order to reduce some of the non-deterministic nature of the benchmark, we have introduced a delay between each method call to the mobile object, which gave time to the object to migrate to its location.Such a delay is not included in the results.
In the first table of Figure 6, eager acknowledgement of object migration resulted in methods calls to be forwarded at most once.This is confirmed by the average duration of a method call, which does not incur any significant variation as , the number of migrations asso- ciated with a method call, increases.We also observe that there is no significant difference between sequential and random itineraries.Finally, the referrals technique appears to be marginally more efficient than call forwarding.
In the second table of Figure 6, acknowledgements of object position is back-propagated to the object's previous location only.Therefore, as we increase , the number of platforms that the mobile object has to migrate to for each method call, we observe that method calls have to be forwarded further.Again, we do not observe any significant difference between sequential and random itineraries.However, the referrals technique becomes significantly more efficient than call forwarding: its efficiency is in the range [11%-19%] for a LAN, whereas its in the range [6%-11%] for a cluster.
Instrumenting the Itinerary benchmark turned out to be more difficult than anticipated.Indeed, many elements, not in our control, interact with our implementation.In particular, platform to platform communications were implemented with Java RMI, which uses Birrel's distributed garbage collector [4].Such a distributed GC introduces synchronisations every time a stub is communicated by a remote method invocation; in particular, such synchronisations occur in the benchmark when an object migration is acknowledged, or when stubs are piggybacked.An alternative would be to use another algorithm [23] which does not introduce such synchronisations.Our rationale for comparing sequential and random itineraries was to test whether a cost was incurred because new connections needed to be opened.Java RMI hides the implementation details in a totally opaque manner, and we have no control over the management of these resources in our implementation.

Discussion.
Call forwarding requires two interventions of each intermediary platform for forwarding the call and the result, whereas referrals require only one such intervention.We believe that this element is the principal explanation for the superior performance of referrals in the presence of heavily loaded platforms (as in our LAN).We anticipate that such a configuration is similar to the environment in which mobile agents are likely to be deployed (cf.Section 2).
At the beginning of our investigation, we debated whether referrals would be penalised by having to open new connections between the benchmark platform and itinerary platforms.In all likelihood, such connections had to be opened for distributed GC purpose in both variants of the algorithm, and therefore no significant change of performance could be attributed to this as-

Related Work and Conclusion
We have presented Mobile Objects in Java a library able to route method invocations to mobile objects.We have discussed two ways of forwarding calls, namely call forwarding and referrals; the latter turned out to be more efficient in our benchmark.There is a third method where the caller explicitly passes a reference to itself, which is used by the callee to return the result.Such a method discussed in [21,8] allows the result to "short-cut" the chain of forwarding calls.A more extensive study is required to investigate the performance of these three methods (as well as the home agent approach) in various scenarios.
Mobile Objects in Java is an integral part of a mobile agent system that we use to support mobile users in the Magnitude project [24].From a software engineering viewpoint, such a library provides a separation of concern between higher-level interactions and message routing.We are adopting such a communication model in three different circumstances.(i) User-driven communication to their mobile agents; (ii) Return of results from a mobile agent to a mobile personal digital assistant; (iii) Communications between mobile agents.
There are a number of other systems that support mobile computations, but they adopt a different philosophy.Emerald [15] supports migration of an object, including threads running in parallel.In Kali Scheme [6], continuations may be migrated between address spaces.None of them provides the transparent routing of messages, as described in this paper.Other approaches rely on a stationary entity to support communications between mobile objects, including Aglets [16], Nomadic Pict [29], April [18] and the InterAgent Communication Library [19].Jumping Beans [2] is a commercial product offering support for mobile applications, but requires a server to be visited by mobile agents during each agent migration.Stationary and central locations put an extra burden on the infrastructure which we wanted to avoid in our implementation.
Our investigation has highlighted a number of difficulties concerning the evaluation of algorithms for mobile agents.(i) In high-level implementations such as ours, in particular above Java RMI, the lack of tools to instrument low-level resources (connections, distributed garbage collection) makes it somewhat difficult to explain observed behaviours.(ii) The absence of widely recognised benchmarks does not ease comparison with other authors.(iii) In mobile computing, social human behaviours dictate the patterns of physical mobility; these can be extensively used in simulations.Be-cause we lack widely accepted applications of mobile agents, we also lack accepted models of their mobility.
It is this specific problem that Huet [10] addresses by looking at a formal modelisation of routing algorithms as stochastic processes.In particular, he compares a centralised forwarder with distributed forwarding pointers.From the slides that were accessible to us, we were enable to establish the patterns of mobility he adopted, and whether call forwarding or referrals were considered.A challenging issue is to define simulations that are refined enough to take into account other activities such as distributed garbage collection, which itself also lacks recognised benchmarks.
In the future, we wish to investigate strategies for propagating information about object's locations independently of remote method invocation.Such a study will have to consider new benchmarks, ideally derived from real applications, and should also include alternative routing algorithms.Furthermore, other requirements and their implications on performance need to be investigated, such as security and robustness of directory services.

¡
Presented at PADDA'2001, the International Workshop on Performance-oriented Application Development for Distributed Architectures Perspectives for Commercial and Scientific Environments April 19-20, 2001, University of Technology, Munich.To appear in PADDA'2001 Special Issue of Scientific Programming.
Figure 1: Architecture interface Talker { int talk(int v, String s); } A startpoint associated with such a mobile object also implements the interface Talker.The endpoint of such a mobile object implements the Endpoint TalkerI interface containing a method talk: interface _Endpoint_TalkerI { _int_Result talk (List from, int _v, String _s); }

Figure 5 :
Figure 5: An Illustration of Call Forwarding vs Referrals (LAN)