Mobile objects in Java - Hindawi Publishing...

Scientific Programming 10 (2002) 91–100 91IOS Press

Mobile objects in Java

Luc Moreaua and Daniel Ribbensb

aElectronics and Computer Science, University of Southampton, SO17 1BJ Southampton, UKTel.: + 44 23 8059 4487; Fax: + 44 23 8059 2865; E-mail: [email protected] d’Informatique, University of Liege, 4000 Liege, BelgiumTel.: +32 4366 2640; Fax: +32 4366 2984; E-mail: [email protected]

Abstract: Mobile Objects in Javaprovides support for object mobility in Java. Similarly to the RMI technique, a notion ofclient-side stub, called startpoint, is used to communicate transparently with a server-side stub, called endpoint. Objects andassociated endpoints are allowed to migrate. Our approach takes care of routing method calls using an algorithm that we studiedin [22]. The purpose of this paper is to present and evaluate the implementation of this algorithm in Java. In particular, twodifferent strategies for routing method invocations are investigated, namely call forwarding and referrals. The result of ourexperimentation shows that the latter can be more efficient by up to 19%.

1. Introduction

Over the last few years, mobile agents have emergedas a powerful paradigm to structure complex distributedapplications. Intuitively, a mobile agent can be seenas a running software that may decide to suspend itsexecution on a host and transfer its state to another host,where it can resume its activity. Cardelli [5] arguesthat mobile agents are the right abstraction to developapplications distributed across “network barriers”, e.g.in the presence of firewalls or when connectivity is in-termittent. In Telescript [17], software migration ispresented as an alternative to communications over awide-area network, in which clients move to servers toperform computations. Lange [16] sees mobile agentsas an evolution of the client-server paradigm, and enu-merates several reasons for using software mobility.

It is a challenge to design and implement mobileagent applications because numerous problems suchas security, resource discovery and communications,need to be addressed. Therefore, we introduce MobileObjects in Java, a middleware that helps implementmobile agent systems by providing a concept of mobileobject. Its specific contribution is a communicationmechanism consisting of the invocation of methods onobjects that may be mobile.

Our motivation has been driven by developments indistributed 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 dis-tribution. They successively provided programmerswith new and more sophisticated abstractions. RPCprovides homogeneity, by its marshalling and unmar-shalling of data structures using data representationsuitable for heterogeneous platforms. Network Objectsoffers memory uniformitybecause remote method in-vocations are syntactically identical to local ones andgarbage collection takes care of local and distributedobjects. Java RMI provides code propagationbecausethe programmer no longer needs to replicate code toremote machines, but instead Java RMI is able to loadcode dynamically.

The next logical step is to hide the location andmovement of objects. A similar approach has also beenadopted by the network community, which devised thenext generation of the IP protocol (IPv6) with supportfor mobile addresses [14].

There exists an incremental approach to introducemobility into an infrastructure that is unaware of mobil-ity [7,16]. It consists of associating each mobile entitywith a stationary home agent, which acts as an inter-mediary for all communications. While this approachpreserves compatibility with an existing infrastructure,introducing an indirection to a home agent for every

ISSN 1058-9244/02/$8.00 2002 – IOS Press. All rights reserved

92 L. Moreau and D. Ribbens / Mobile objects in Java

communication puts a burden on the infrastructure; thismay hamper the scalability of the approach, in particu-lar, in massively distributed systems, such as the amor-phous computer [27] or the ubiquitous/pervasive com-puting environment [1]. Free from any compatibilityconstraint, we adopted an algorithm to route messagesto mobile agents that does not require any static loca-tion: the theoretical definition of this algorithm basedon forwarding pointers and the proof of its correctnesshave been investigated in a previous publication [22].

The purpose of this paper is to present Mobile Ob-jects in Java, an implementation of the algorithm,which offers transparent method invocation and dis-tributed garbage collection for mobile objects. Bytransparent, we mean that mobile and non-mobile ob-jects present a same interface, which is independent ofthe object location and its migratory status. Distributedgarbage collection ensures that an object, whether mo-bile or not, can be reclaimed once it is no longer ref-erenced. While implementing our algorithm, it be-came clear that two strategies could be adopted, whichwe named call forwarding and referrals; we presentthese strategies and evaluate their performance througha benchmark.

This paper is organised as follows. First, we providemore motivation for mobile agents by presenting twopromising application domains in Section 2. Then, inSection 3, we summarise the algorithm we have inves-tigated in [22]. In Section 4, we describe its imple-mentation in Java, providing a transparent interface tomobile objects. We then discuss two different methodsfor routing method invocations, namely forwarding andreferrals, in Section 5. In order to compare these tech-niques, we devise a synthetic benchmark, and analyseresults in Section 6. Finally, we compare our approachwith related work in Section 7.

2. Motivation

In this Section, we provide further motivation formobile agents. We describe two promising applicationswhere mobile agents act semi-autonomously on behalfof users. The reasons for doing so, however, differsubstantially in the two applications.

Digital libraryYan and Rana [30] present a high-level service for

a digital library of radar images of the Earth. The li-brary is composed of a set of confidential images andassociated annotations with attached ownership. They

extend a Web-based client-server architecture with mo-bile agents that perform tasks on behalf of users and thatare able to migrate to a predefined itinerary of hosts.

After being dispatched, agents migrate securely, withdata, code and state to an itinerary of servers that mayhave relevant data and services. Agents become inde-pendent of the user who created them: they can surviveintermittent or unreliable network connections. Mobileagents are beneficial for several reasons.

(i) They avoid the delivery of large volume of sci-entific data required for data mining of images;

(ii) They help maintain confidentiality and own-ership of data, by being run through securitychecks, ensuring that they have the rights toaccess the data;

(iii) They are allowed specific queries on the li-brary according to the “security level” they weregranted.

Fig. 1. Architecture.

Mobile usersThe context of the Magnitude project [24] is the

“ubiquitous computing environment” [27] where em-bedded devices and artifacts abound in buildings andhomes, and have the ability to sense and interact withdevices carried by people in their vicinity. Applicationsrunning on mobile devices interact with the infrastruc-ture, and find and exploit services to fulfill the user’sneeds.

However, communications between mobile devicesand the infrastructure have some limitations, in the formof intermittent connectivity and low bandwidth. Fur-thermore, processing power and memory capacity ofcompact mobile devices remain relatively small. Asa result, such an environment would prevent the largescale deployment of advanced services that are com-munication and computation intensive.

We adopt mobile agents as proxies for mobiles users.As illustrated by Fig. 1, we utilise mobile agents, as

L. Moreau and D. Ribbens / Mobile objects in Java 93

semi-autonomous entities, which can migrate from mo-bile devices to infrastructure locations to take advan-tage of the resources their specific tasks require; mobileagents perform their tasks on the infrastructure, possi-bly involving further migration, and then return resultsback to mobile users.

SummaryBoth scenarios use the idea of mobile agent, as a

semi-autonomous proxy for a user. If granted the rightto do so, mobile agents may migrate to new locations,where they can take advantage of local resources.

3. Message routing algorithm

In this section, we summarise the message routingalgorithm for mobile agents that we formalised in [22].We consider a set of mobile objects and a set of sites (inour case JVMs) taking part into a computation. Eachmobile object is associated with a timestamp, which isa counter incremented every time the object changeslocation. Each site keeps a record of the location whereevery mobile object known to the site is thought tobe, and of the timestamp the object had at the time.Therefore, in a system composed of several sites, sitesmay have different information about a same mobileobject (depending on how fast location information ispropagated between sites).

The algorithm proceeds as follows. When a mobileobject decides to migrate from a site A to another siteB, it informs A of its intention of migrating; a trans-portation service is used to transport the object to B.When the mobile object arrives at B, its safe arrivalis acknowledged by informing its previous site A ofits new location and of its new timestamp; site A canthen update its local table with the mobile object’s newposition and timestamp.

Mobile objects delegate to sites the task of send-ing messages to other objects. When a site receivesa request for sending a message to a mobile object, itsearches its table in order to find the object location.If the object is local, the message is passed onto theobject. If the object is not local, but known to be at a re-mote location, the message is forwarded to the remotelocation.

As migration is not atomic, a mobile object may haveleft a site, but the acknowledgement of its safe arrivalmay not have been received by the site yet. In sucha case, the site temporarily has to enqueue messages

aimed at the object; as soon as the acknowledgementarrives, delayed messages may be forwarded.

Timestamps are used to guarantee that sites alwaysupdate their knowledge about mobile objects with morerecent information than the one they currently have.If a site receives information with a timestamp that issmaller than the timestamp in its table, the receivedinformation is discarded. Such a timestamp mechanismis mandatory to avoid cyclic routing of messages [22].

In the algorithm described so far, a mobile objectleaves a trail of forwarding pointers during its migra-tion. In order to reduce the length of the chain of for-warding pointers, routing information and associatedtimestamp may be propagated by any site to any site;timestamps are again used to guarantee that the mostrecent information is stored in routing tables. In therest of the paper, we discuss an implementation of thisabstract algorithm.

4. Implementation in Java

In Java RMI [12], an object whose methods can beinvoked from another JVM is implemented by a remoteobject. Such a remote object is described by one ormore remote interfaces. Remote method invocation isthe action of invoking a method of a remote interfaceon a remote object. In practice, a stubacts as a client’slocal representative or proxy for a remote object. Thestub of a remote object implements the same interfaceas the remote object: when a method is called on thestub, arguments are serialised and communicated to theremote object,1 where the method can be called; itsresult is transmitted back to the stub and becomes themethod call result. A very desirable feature of thisapproach is that local and remote method invocationshare an identical syntax.

Now, we present an approach in which remote ob-jects are allowed to be mobile, but clients still use thesame stub-based method invocation mechanism, mak-ing them unaware of the location and movement of themobile object.

4.1. Startpoints and endpoints

Figure 2 displays the different entities of our imple-mentation. The right-hand side of the picture repre-

1Before Java 1.2, there was a notion of skeleton, which was aserver-side representative of the object, responsible for deserialisingthe arguments.


Fig. 2. Startpoint and endpoint.

sents the “server-side” on JVM2, composed of a mo-bile object; the left-hand side is concerned with the“client-side” on JVM1.

We adopt Nexus terminology [8], and we respec-tively name startpointand endpointthe client-side andserver-side representatives of a remote object. A mo-bile object is specified by an interface, which must alsobe implemented by its startpoints. Startpoints containan RMI stub representing the current location of a mo-bile object, and permit direct communication with theendpoint; the endpoint passes messages to the mobileobject. Additionally, the startpoint contains the mobileobject’s timestamp t. (The endpoint also has the sametimestamp t.)

Figure 3 displays the new configuration after themobile object has migrated to JVM3. There exists anew endpoint acting as a server-side representative atthe new location. Its timestamp is t + 1 following itsincrease after migration. The endpoint is referred to bya startpoint with timestamp t+1, which is sent to JVM2

as an acknowledgement to the safe arrival at JVM3.This startpoint is used by the endpoint on JVM2 as aforwarding pointer to the new object location. Whena method is activated on the startpoint on JVM1, thecall is still transmitted to JVM2, where the endpoint isaware that the object has moved to JVM3 and uses thesame mechanism to forward the call.

As opposed to simple message passing, a remotemethod invocation is expected to return a result.2 Ina first instance, our implementation is based on callforwarding and the result is propagated back along thechain to the initial startpoint where the method call wasinitiated.

In such an algorithm, it is important to reduce anychain of forwarding pointers in order to reduce the cost

2In the particular case of a procedure returning a type void, noresult is returned, but the method invocation terminates after the callhas been completed remotely; for the sake of presentation, we willno longer distinguish this case from normal return of values.

of method invocation, but also to make the system moreresilient to failures. In Fig. 3, when JVM2 has to for-ward a call to JVM3, JVM2 knows that informationon JVM1 is out of date. Therefore, when the result isreturned to JVM1, we can also return updated informa-tion about the mobile object location. To this end, wemade the remote interface implemented by endpointsdifferent from the interface implemented by mobile ob-jects: we return not only the “usual result”, but also thenew object location.

Returning updated location information at the sametime as returning results may not propagate informationsoon enough, because processing on the server may belong. Therefore, independently, we might like to in-form previous JVMs in the chain about the location ofthe mobile object. Since regular remote method invo-cation does not give any information about the methodcaller, we provide, as extra arguments, the stubs point-ing to the JVMs involved in the chain.

In summary, a startpoint implements the same inter-face as a mobile object. An endpoint has a derived in-terface passing extra routing information, both duringthe forward call and during the return of a result. TheRMI-stub encapsulated in the startpoint implements thesame interface as the endpoint.

For the sake of illustration, let us consider the methodtalk specified in the interface Talker implementedby a mobile object.

interface Talker {int talk(int v, String s);

}

A startpoint associated with such a mobile ob-ject also implements the interface Talker. Theendpoint of such a mobile object implements theEndpoint TalkerI interface containing a methodtalk:

interface _Endpoint_TalkerI {_int_Result talk (List from,


Fig. 3. Mobile object migration.

int _v, String _s);}

The extra argumentfrom is a list of RMI stubs to theJVMs that were involved in the passing of the currentmethod call. The type int Result encapsulates anint as well as new routing information. We have im-plemented a stub compiler which takes care of gener-ating such interfaces. It also creates the definitions ofthe startpoint and endpoint classes.

4.2. Object migration

We provide a new abstract classUnicastMobile-Object, which encapsulates the behaviour common toall mobile objects. A mobile object must be defined asa subclass of UnicastMobileObject, from whichtwo methods can be inherited:

protected void migrate(String url,Serializable state)

protected void install(Object state)

A mobile object can initiate its migration to anotherJVM, identified by a RMI-style URL, using the methodmigrate. The current object content will be serial-ized in conjunction with an extra argument. Upon anobject’s arrival, the method install is activated withthe state argument passed to migrate. Both methodsare defined as “protected” to guarantee that they areinvoked only under the object’s control.

The Java object model does not make any guaran-tee regarding which thread executes remote methods.Therefore, for a single object, there may be severalthreads executing in parallel when a request for mi-grating is issued by one of them. As Java does notsupport thread migration, it is not possible to suspendthe execution of all threads in order to resume them atthe destination. Instead, we allow an object to migratewhen there is only one thread executing a method ofthis object. It is therefore the programmer’s respon-sibility to synchronize and terminate threads currently

executing in parallel, and, if necessary, to save theirstate in a serializable field of the object.

Mobile Objects in Javaalso introduce the concept of“platform”, a JVM that runs mobile objects securely. Aplatform is a RMI UnicastRemoteObject whichadvertises 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 asa first argument by migrate. Hooks are providedto perform security checks before executing objects intheir sandbox [20].

4.3. Startpoint deserialisation

In our system, on a given platform, there is at mostone instance of a startpoint that refers to a given mobileobject. In order to preserve this invariant, each platformmaintains a table of all the startpoints it knows, whichis updated when startpoints are deserialised. (We usethe Java method doReadResolve [13] to overridethe object returned from the stream.)

A desirable consequence of this implementation isthat all objects using a specific startpoint share the ben-efit of the most recent routing information for that start-point. The table of startpoints is a hash table, using aunique name given to mobile objects as a hashing key.This table uses weak references[11] to guarantee thatstartpoints do not remain accessible longer than neces-sary. As a result, we ensure that mobile objects may beproperly garbage collected.

4.4. Clearing routing information

Routing information has to be cleared when it is nolonger needed. Indeed, platforms run for a long periodof time and host many visiting mobile objects, whichleave forwarding pointers as they migrate to their nextdestination. We need to ensure that routing tables do notbecome filled with unnecessary routing information.

We have observed [22] that the task of clearing rout-ing tables is equivalent to the distributed termination


problem [25]. A forwarding endpoint is allowed tobe cleared if it can be proved that no other platformwill ever forward method calls to it. This may be im-plemented using a distributed reference counting algo-rithm [23,25]. In particular, RMI provides a methodUnreferenced for remote objects which is calledwhen there is no remote reference to this object [12].When this method is called on an endpoint, it may beunexported, and the reference to the next startpoint inthe chain may be lost. Note that this mechanism canonly work if tables of startpoints contain weak refer-ences to these. Otherwise, if startpoints remain live,the RMI-stubs they contain will also remain live, whichwill prevent the call of the Unreferenced methodon the associated endpoints.

5. Forwarding vs referrals

In our theoretical algorithm [22], messages arerouted individually; a reply would be regarded as a sep-arate message to be routed independently. The viewthat we have adopted for Mobile Objects in Javadiffersslightly because it is based on the remote method invo-cation paradigm: methods are invoked and are expectedto produce a result. In the previous section, we showedthat the result could be propagated backwards along thechain of forwarding pointers left by the mobile object.

Long chains of remote method invocations offer toolittle resilience to failures of intermediary nodes. In-stead of forwarding a method call, an endpoint couldthrow an exception indicating that the mobile objecthas migrated. The exception could contain the newstartpoint pointing at the mobile object location.

The approach consisting of throwing an exceptioncontaining a new startpoint, instead of forwarding acall, is similar to the referral mechanism [9] used indistributed search systems such as Whois++ [26] andLDAP [28]. It then puts the onus on the method in-voker to re-try the invocation with the next location ofthe object; once the object has been reached, the resultmay then be returned to the caller directly. In our im-plementation, the startpoint is in charge of re-trying amethod invocation until it becomes successful. There-fore, from the programmer’s viewpoint, there is no syn-tactic difference between the two approaches. An op-tion passed as argument to the stub compiler specifieswhether code has to be generated for referrals or forcall forwarding. In the rest of the paper, we comparethe performance of the two approaches.

6. Benchmark

The scientific programming community has a tra-dition of adopting benchmarks to evaluate the perfor-mance of computers; for instance, the Linpack Bench-mark is a numerically intensive test used to measurefloating point performance. Unfortunately, we lackbenchmarks specifically suited to evaluate routing al-gorithms for mobile objects. This may be explainedby the relative novelty of the concept of mobile ob-ject, and the inexistence of widely accepted applica-tions for mobile agents. In a previous paper [23], weobserved that there was no recognised benchmark forevaluating distributed garbage collectors; therefore, wedesigned some synthetic benchmarks for such a type ofdistributed algorithms. We propose to adopt a similarapproach here.

A synthetic benchmark is an abstraction of a realprogram, where routing of messages may have an im-pact on the performance of the computation. In ourbenchmark, we measure the cost of invoking a methodon a mobile object that has changed location since thelast time the method was invoked on it. In the con-text of the Magnitude architecture of Section 2, such abenchmark is reminiscent of the communications onemay have with a mobile agent visiting several locationsto perform a task.

Figure 4 summarises the “Itinerary Benchmark”. AnItinerary consists of N platforms P0, . . . , PN−1 to bevisited by a mobile object. A platform P , not part ofthe itinerary, is used to initiate invocations of a methodm on the remote mobile object. Every method invoca-tion takes as argument a list of J platform identifiersthat the mobile object has successively to migrate to; anitinerary is completed when the mobile object returnsto the first platform P0. As method m is invoked on themobile object, it spawns a thread responsible for mi-grating the mobile object to J platforms, while methodm terminates in parallel. On platform P , we measurethe time taken to perform all method calls necessary tocomplete an itinerary.

Figure 5 illustrates the execution of the Itinerarybenchmark over 10 platforms (5 rather heavily loadedworkstations/servers each running 2 JVMs), connectedby a local area network. Each method call forced theobject to migrate to one new location. We ran the samebenchmark using both the call forwarding and the re-ferrals techniques. We can see that in this specific in-stance, referrals are on average 9% faster than call for-warding, over 200 itineraries. We should observe theabnormal duration of the first itinerary in Fig. 5: in-


Fig. 4. Itinerary Benchmark.

deed, it can be up to an order of magnitude slower thanthe others since it forces object byte-code to be loadeddynamically as the mobile object visits each platformfor the first time.

In Fig. 6, we summarise our results,which we discussnow. Several variants of the Itinerary benchmark wereconsidered.

(i) We always ran the Itinerary benchmark on 10platforms. In one case, the platforms executedon 5 rather heavily loaded workstations/serverseach running 2 JVMs) connected by a 100Mblocal area network (Notation: LAN). In theother case, the platforms executed on 5 nodesof a cluster (Linux 2.2, 450 Mhz) with dedi-cated 100Mb network, with each node running2 JVMs (Notation: Cluster).

(ii) The partitioning of the platforms may be de-terministic or non-determinisic. In the formercase, the object systematically visits platformsin the same order (Notation: Sequential). In thelatter case, the order of platforms is decided ran-domly for each itinerary (Notation: Random).

(iii) We ran the Itinerary benchmark using both thecall forwarding (Notation: CF) and the referralstechniques (Notation: Ref).

(iv) When a mobile object migrates to successive lo-cations, its new position can be acknowledgedto all its previous locations (Notation: EagerAcknowledgement), or to its directly previous

location only (Notation: One Acknowledge-ment).

In order to reduce some of the non-deterministic na-ture of the benchmark, we have introduced a delay be-tween each method call to the mobile object, whichgave time to the object to migrate to its location. Sucha delay is not included in the results.

In the first table of Fig. 6, eager acknowledgementof object migration resulted in methods calls to be for-warded at most once. This is confirmed by the aver-age duration of a method call, which does not incurany significant variation as J , the number of migra-tions associated with a method call, increases. We alsoobserve that there is no significant difference betweensequential and random itineraries. Finally, the referralstechnique appears to be marginally more efficient thancall forwarding.

In the second table of Fig. 6, acknowledgements ofobject position is back-propagated to the object’s pre-vious location only. Therefore, as we increase J , thenumber of platforms that the mobile object has to mi-grate to for each method call, we observe that methodcalls have to be forwarded further. Again, we do notobserve any significant difference between sequentialand random itineraries. However, the referrals tech-nique becomes significantly more efficient than call for-warding: its efficiency is in the range [11%–19%] for aLAN, whereas its in the range [6%–11%] for a cluster.

Instrumenting the Itinerary benchmark turned out tobe more difficult than anticipated. Indeed, many ele-


2048

4096

8192

0 20 40 60 80 100 120 140 160 180 200

Tim

e in

ms

(log

scal

e)

Number of itineraries

Comparison of Call forwarding and Referrals [sequential (eager ack) 200 1]

Call Fowarding ( Itinerary Average: 2657.99, Method Average: 265.799)Referral Style ( Itinerary Average: 2431.27, Method Average: 243.127)

Fig. 5. An illustration of call forwarding vs referrals (LAN).

Fig. 6. Average duration of a method call to a mobile object.

ments, not in our control, interact with our implemen-tation. In particular, platform to platform communi-cations were implemented with Java RMI, which usesBirrel’s distributed garbage collector [4]. Such a dis-tributed GC introduces synchronisations every time astub is communicated by a remote method invocation;in particular, such synchronisations occur in the bench-mark when an object migration is acknowledged, orwhen stubs are piggybacked. An alternative would beto use another algorithm [23] which does not introducesuch synchronisations. Our rationale for comparingsequential and random itineraries was to test whether acost was incurred because new connections needed tobe opened. Java RMI hides the implementation detailsin a totally opaque manner, and we have no control overthe management of these resources in our implementa-tion.

DiscussionCall forwarding requires two interventions of each

intermediary platform for forwarding the call and theresult, whereas referrals require only one such inter-vention. We believe that this element is the principalexplanation for the superior performance of referralsin the presence of heavily loaded platforms (as in ourLAN). We anticipate that such a configuration is similarto the environment in which mobile agents are likely tobe deployed (cf. Section 2).

At the beginning of our investigation, we debatedwhether referrals would be penalised by having to opennew connections between the benchmark platform anditinerary platforms. In all likelihood, such connectionshad to be opened for distributed GC purpose in bothvariants of the algorithm, and therefore no significantchange of performance could be attributed to this as-pect. Tools to instrument resources used within theJVM would be extremely valuable in this context.


7. Related work and conclusion

We have presented Mobile Objects in Javaa libraryable to route method invocations to mobile objects. Wehave discussed two ways of forwarding calls, namelycall forwarding and referrals; the latter turned out tobe more efficient in our benchmark. There is a thirdmethod where the caller explicitly passes a referenceto itself, which is used by the callee to return the re-sult. Such a method discussed in [8,21] allows theresult to “short-cut” the chain of forwarding calls. Amore extensive study is required to investigate the per-formance of these three methods (as well as the homeagent approach) in various scenarios.

Mobile Objects in Javais an integral part of a mobileagent system that we use to support mobile users inthe Magnitude project [24]. From a software engineer-ing viewpoint, such a library provides a separation ofconcern between higher-level interactions and messagerouting. We are adopting such a communication modelin three different circumstances.

(i) User-driven communication to their mobileagents;

(ii) Return of results from a mobile agent to a mo-bile personal digital assistant;

(iii) Communications between mobile agents.

There are a number of other systems that supportmobile computations, but they adopt a different philos-ophy. Emerald [15] supports migration of an object, in-cluding threads running in parallel. In Kali Scheme [6],continuations may be migrated between address spaces.None of them provides the transparent routing of mes-sages, as described in this paper. Other approaches relyon a stationary entity to support communications be-tween mobile objects, including Aglets [16], NomadicPict [29], April [18] and the InterAgent Communica-tion Library [19]. Jumping Beans [2] is a commercialproduct offering support for mobile applications, butrequires a server to be visited by mobile agents dur-ing each agent migration. Stationary and central loca-tions put an extra burden on the infrastructure whichwe wanted to avoid in our implementation.

Our investigation has highlighted a number of dif-ficulties concerning the evaluation of algorithms formobile agents.

(i) In high-level implementations such as ours, inparticular above Java RMI, the lack of toolsto instrument low-level resources (connections,distributed garbage collection) makes it some-what difficult to explain observed behaviours.

(ii) The absence of widely recognised benchmarksdoes not ease comparison with other authors.

(iii) In mobile computing, social human behavioursdictate the patterns of physical mobility; thesecan be extensively used in simulations. Becausewe lack widely accepted applications of mobileagents, we also lack accepted models of theirmobility.

It is this specific problem that Huet [10] addressesby looking at a formal modelisation of routing algo-rithms as stochastic processes. In particular, he com-pares a centralised forwarder with distributed forward-ing pointers. From the slides that were accessible to us,we were enable to establish the patterns of mobility headopted, and whether call forwarding or referrals wereconsidered. A challenging issue is to define simula-tions that are refined enough to take into account otheractivities such as distributed garbage collection, whichitself also lacks recognised benchmarks.

In the future, we wish to investigate strategies forpropagating information about object’s locations inde-pendently of remote method invocation. Such a studywill have to consider new benchmarks, ideally derivedfrom real applications, and should also include alter-native routing algorithms. Furthermore, other require-ments and their implications on performance need tobe investigated, such as security and robustness of di-rectory services.

Acknowledgements

David De Roure pointed out an analogy between thedirectory service described in this paper and the notionof referrals used in distributed search systems and in“query routing”. Thanks to Omer Rana for discussionson their agent-based Digital Library system, and toDanius Michaelides for his comments on the paper.This research is funded in part by EPSRC and QuinetiQproject “Magnitude” reference (GR/N35816).

References

[1] S. Adams and D. DeRoure, A Simulator for an AmorphousComputer, in: Proceedings of the 12th European SimulationMulticonference(ESM’98), Manchester, UK, June 1998.

[2] Ad Astra, Jumping beans, Technical report, White Paper,1999, http://www.JumpingBeans.com/.

[3] A.D. Birrell and B.J. Nelson, Implementing Remote ProcedureCalls, ACM Transactions on Computer Systems2(1) (February1984), 39–59.


[4] A. Birrell, G. Nelson, S. Owicki and E. Wobber, Network Ob-jects, Technical Report 115, Digital Systems Research Center,February 1994.

[5] L. Cardelli, Abstractions for Mobile Computation, in: SecureInternet Programming: Security Issues for Distributed andMobile Objects, J. Vitek and C. Jensen, eds, Vol. 1603 ofLecture Notes in Computer Science, 1999.

[6] H. Cejtin, S. Jagannathan and R. Kelsey, Higher-order dis-tributed objects, ACM Transactions on Programming Lan-guages and Systems17(5) (September 1995), 704–739.

[7] J. Dale and F.G. McCabe, Agent Management Support forMobility, Fipa’98 draft specification, Fujitsu Laboratories ofAmerica, 1998.

[8] I. Foster, C. Kesselman and S. Tuecke, The Nexus Approachto Integrating Multithreading and Communication, Journal ofParallel and Distributed Computing37 (1996), 70–82.

[9] N. Gibbins and W. Hall, Scalability issues for query routingservice discovery. in: Proceedings of the Second Workshop onInfrastructure for Agents, MAS and Scalable MAS, May 2001.

[10] F. Huet, Distribution and localisation, http://www.irit.fr/ACTIVITES/PLASMA/PRO-Toulouse2001/LesPropositions/LesTransparents/pro-huet.pdf.

[11] Java Reference Objects, http://java.sun.com/j2se/1.3/docs/guide/refobs/.

[12] Java Remote Method Invocation Specification, November1996.

[13] Java Object Serialization Specification, November 1998.[14] D.B. Johnson and C. Perkins, Mobility Support in IPv6, In-

ternet draft, IETF Mobile IP Working Group, 1999. draft-ietf-mobileip-ipv6-09.txt.

[15] E. Jul, Migration of light-weight processes in Emerald, Op-erating Systems Technical Committee Newsletter3(1) (1989),25–30.

[16] D.B. Lange and M. Ishima, Programming and Deploying JavaMobile Agents with Aglets, Addison-Wesley, 1998.

[17] General Magic, Telescript Technology: Mobile Agents, 1996.[18] F.G. McCabe and K.L. Clark, APRIL – Agent Process Interac-

tion Language, in: Proc. of ECAI’94 Workshop on Agent The-ories, Architectures and Languages, Springer-Verlag, 1995.

[19] F.H. McCabe, InterAgent Communications Reference manual,Technical report, Fujitsu Laboratories of America, 1999.

[20] G. McGraw and E.W. Felten, Securing Java, Wiley, 1999.[21] D. Michaelides, L. Moreau and D. DeRoure, A Uniform Ap-

proach to Programming the World Wide Web, Computer Sys-tems Science and Engineering14(2) (1999), 69–91.

[22] L. Moreau, Distributed Directory Service and Message Routerfor Mobile Agents, Science of Computer Programming39(2–3) (2001), 249–272.

[23] L. Moreau, Tree Rerooting in Distributed Garbage Collection:Implementation and Performance Evaluation, Higher-Orderand Symbolic Computation, To appear.

[24] L. Moreau, D. De Roure, W. Hall and N. Jennings, MAG-NITUDE: Mobile AGents Negotiating for ITinerant Users inthe Distributed Enterprise, http://www.ecs.soton.ac.uk/˜lavm/magnitude/, 2001.

[25] G. Tel and F. Mattern, The Derivation of Distributed Termina-tion Detection Algorithms from Garbage Collection Schemes,ACM Transactions on Programming Languages and Systems15(1) (January 1993), 1–35.

[26] C. Weider, J. Fullton and S. Spero, Architecture of Whois++Index Service, Request for comments 1913, Internet Engineer-ing Task Force, 1996.

[27] M. Weiser, Some Computer Science Problems in UbiquitousComputing, Communications of the ACM36(7) (July 1993),74–84.

[28] M. Whalh, T. Howes and S. Kille, Light Weight DirectoryAccess Protocol (v3), Request for comments 2251, InternetEngineering Task Force, 1997.

[29] P. Wojciechowski and P. Sewell, Nomadic Pict: Language andInfrastructure Design for Mobile Agents, in: First Interna-tional Symposium on Agent Systems and Applications/ThirdInternational Symposium on Mobile Agents(ASA/MA’99), Oc-tober 1999.

[30] Y. Yang, O.F. Rana, C. Georgousopoulos, D.W. Walker andR.D. Williams, Mobile agents and the sara digital library,in: Proceedings of IEEE Advances in Digital Libraries 2000,Washington, DC, May 2000, pp. 71–77.

Submit your manuscripts athttp://www.hindawi.com

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttp://www.hindawi.com

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation http://www.hindawi.com Volume 2014


Applied Computational Intelligence and Soft Computing

Advances in

Artificial Intelligence


Advances inSoftware EngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

http://www.hindawi.com Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in


Mobile objects in Java - Hindawi Publishing...

Documents

Transcript of Mobile objects in Java - Hindawi Publishing...