Achieving Mobile Agent Systems interoperability throughsoftware layering q

Giancarlo Fortino *, Alfredo Garro, Wilma Russo

Dipartimento di Elettronica, Informatica e Sistemistica (DEIS), Universita della Calabria, Via P. Bucci, 87036 Rende (CS), Italy

Received 20 April 2006; received in revised form 5 February 2007; accepted 15 February 2007Available online 25 February 2007

Abstract

Interoperability is a key issue for a wider adoption of mobile agent systems (MASs) in heterogeneous and open distributed environ-ments where agents, in order to fulfill their tasks, must interact with non-homogeneous agents and traverse di!erent agent platforms toaccess remote resources. To date, while several approaches have been proposed to deal with di!erent aspects of MAS interoperability,they all lack the necessary flexibility to provide an adequate degree of interoperability among the currently available MASs. In this paper,we propose an application-level approach grounded in the software layering concept, which enables execution, migration and commu-nication interoperability between Java-based mobile agent systems, thus overcoming major setbacks a!ecting the other approaches cur-rently proposed for supporting MAS interoperability. In particular, we define a Java-based framework, named JIMAF, which relies onan event-driven, proxy-based mobile agent model and supports interoperable mobile agents which can be easily coded and adapted toexisting MASs without any modifications of the MAS infrastructures. Results from the performance evaluation of MAS interoperabilitywas carried by using JIMAF atop Aglets, Ajanta, Grasshopper, and Voyager, demonstrating that the high-level JIMAF approach o!ershigh e"cacy while maintaining overhead at acceptable levels for target computing environments.! 2007 Elsevier B.V. All rights reserved.

Keywords: Mobile Agent Systems; Interoperability; Agent Models; Proxy-based Communication; Frameworks; Software Layering

1. Introduction

Over the last decade, mobile agent paradigm and tech-nology [14,18,6] have shown high potential and flexibilityfor the design and implementation of general-purpose dis-tributed applications, particularly in dynamic environ-ments such as those based on the Internet. A mobileagent can be defined as an autonomous software entitywhich can migrate from one host to another to fulfill agoal-oriented task. Mobile agents are supported and man-

aged by distributed software platforms known as mobileagent systems (MASs). Although plenty of MASs are cur-rently available and several critical advantages derivingfrom the exploitation of mobile agents have clearly beendemonstrated by both academic and industrial researche!orts [21,14,6], the following major drawbacks still hinderthe widespread use of mobile agents: the lack of appropri-ate security mechanisms, the lack of interoperability, andthe lack of software development processes and modelinglanguages tailored for mobile agents.

In this paper, we focus on interoperability which isextremely important and necessary when heterogeneousMASs come into contact with each other. Such contactscan be very frequent in open systems or multi-domain envi-ronments whereby a mobile agent, in order to fulfill itsgoal, must cross several domains served by MASs of di!er-ent kinds to access remote resources and/or communicatewith non-homogeneous mobile/stationary agents.

0950-5849/$ - see front matter ! 2007 Elsevier B.V. All rights reserved.doi:10.1016/j.infsof.2007.02.016

q A preliminary version of this article, entitled ‘‘High-level Interopera-bility between Java-based Mobile Agent Systems’’ by G. Fortino and W.Russo, was presented at the 17th ISCA International Conference onParallel and Distributed Computing Systems (PDCS’04), San Francisco,CA, USA, pp. 367–374, 15–17 September 2004.* Corresponding author. Tel.: +39 0984 494063; fax: +39 0984 494713.E-mail addresses: g.fortino@unical.it (G. Fortino), garro@unical.it (A.

Garro), w.russo@unical.it (W. Russo).

www.elsevier.com/locate/infsof

Available online at www.sciencedirect.com

Information and Software Technology 50 (2008) 322–341

Interoperability between MASs can be defined as fol-lows: two MASs are interoperable if a mobile agent ofone system can migrate into the second heterogeneous sys-tem, execute on this system, and communicate with otherco-located or remote mobile agents [29]. According to thisdefinition, interoperability among MASs involves the fol-lowing issues:

- Execution: How to adapt the lifecycle of a mobile agentto di!erent MASs and how to enable a mobile agent toaccess resources of MASs.

- Inter-agent communication: How to adapt the messagetransport layers of di!erent MASs to one another andthe communication language among di!erent mobileagents.

- Mobility: How to adapt di!erent agent transport andagent encoding protocols among di!erent MASs.

- Security: How to authenticate mobile agents of di!erentMASs and appraise their behaviour.

To date several approaches have been proposed fortackling the interoperability issues which can be classifiedas specification-based, low-level, or high-level approaches.However, such approaches are still not satisfactory mainlydue to the following limitations: (i) only some of the afore-mentioned interoperability issues are addressed; (ii) lowe!ectiveness for delivering low-cost and flexible solutions.Moreover, such approaches lack documentation about per-formance overhead regarding how the MASs have beenmade interoperable.

In this paper, we propose a high-level approachgrounded on the well established concept of software layer-ing [20], which is able to provide interoperability of execu-tion, communication and migration, and overcome thelimitations of the currently available solutions. Moreoversecurity remains under the control of specific mechanismsof the MASs which are made interoperable. As ourapproach also relies on voluntary interoperability, MASswhich wish to interoperate must adopt a common solutionsuch as the use of a unifying framework or the exploitationof common supporting tools [29].

Software layering has been largely used for the develop-ment of communication protocol suites to hide networkheterogeneity; TCP/IP is the most notable example. There-fore to hide heterogeneity of Java-based MASs we havedesigned and implemented a software layer, the Java-basedInteroperable Mobile Agent Framework (JIMAF), whichcan be layered atop available Java-based MASs (seeFig. 1) without requiring any modifications to the underly-ing MASs.

In particular, the framework is structured in three sub-layers: (i) the Interoperable Mobile Agent Layer (IMAL),which supports the programming of mobile agents whichare independent from any specific MAS; (ii) the Adapta-tion Layer (AL), which adapts an interoperable mobileagent to a specific MAS; (iii) the Platform-dependentMobile Agent Layer (PMAL), which provides a set of

basic, platform-dependent mobile agents on which interop-erable mobile agents can be adapted via the AL. An inter-operable mobile agent therefore consists of a MAS-neutralhigh-level part which does not change throughout themobile agent lifecycle, and a low-level part which dependson the specific MAS in which the mobile agent is operatingand therefore changes after a heterogeneous migration,assuming the ‘‘shape’’ of the mobile agent of the new host-ing MAS. The high-level part of an interoperable mobileagent is programmed according to a programming modelbased on the concept of event-driven lightweight agent[9,10].

An application based on JIMAF is composed of (i) aninteroperable part written according to JIMAF (i.e. inter-operable mobile agents able to migrate, execute, and com-municate atop each platform actually and potentially madeinteroperable by JIMAF) and, possibly, (ii) a platform-dependent part written according to the specific platforms(i.e. Aglets agents, Voyager agents, etc.) and integratedwith the interoperable part through wrapper agents whichare special JIMAF agents wrapping platform-dependentagents which are thus capable of communicating with bothinteroperable agents and with specific platform-dependentagents. Thus, communication between an interoperablemobile agent and a platform-dependent mobile agent ismediated by wrapper agents, whereas communicationamong interoperable mobile agents is based on asynchro-nous messages. Moreover, migration of interoperablemobile agents between two heterogeneous MASs is enabledby special JIMAF agents called bridges which are softwareequivalents of network bridges.

Currently, the framework is layered atop the followingMASs: Aglets, Ajanta, Grasshopper and Voyager. TheseMASs were selected from the large number of availableJava-based MASs as they are widely cited and very welldocumented, robust and stable, very representative of on-going research and commercial e!orts, extensively usedfor developing a broad range of applications as well assophisticated programming systems.

In order to evaluate the performance of JIMAF over theMASs currently exploited, so to quantify performanceoverhead which an application-level approach inevitablyintroduces, several micro-benchmarks and a micro-kernelwere defined and run to evaluate the performances of

OS

JVM

Aglets Ajanta Voyager Grasshopper

Interoperable Mobile Agent Framework

otherMASs

Mobile Agent-based Applications

Dep

ends

on

Fig. 1. Software layers of an interoperable Java-based MAS.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 323

migration, lookup, message transmission, creation, androaming of the interoperable mobile agent and to comparethe results with those of the mobile agents of the MASsatop which JIMAF was layered. A contained performanceoverhead was found which is acceptable within Internet-based heterogeneous computing environments whereinteroperability is often more important than highperformances [9,14].

The main contributions of this paper are the following:

- The design and implementation of the model-drivenhigh-level framework, JIMAF, which renders Java-basedmobile agent systems interoperable without requiringtheir modification.

- The evaluation of the performance of JIMAF withrespect to those of the MASs made interoperable(Ajanta, Aglets, Grasshopper, and Voyager).

- The introduction and exploitation of a taxonomy topresent the state-of-the-art regarding MAS interopera-bility and discuss the JIMAF proposal.

The remainder of the paper is structured as follows. Sec-tion 2 introduces background concepts regarding MASsthrough a reference framework. Section 3 describes the fun-damentae of our approach: the interoperable mobile agentmodel, the communication infrastructure and the bridgingarchitecture. Section 4 details the Java-based interoperablemobile agent framework along with an example whichshows the main JIMAF features. The performance evalua-tion of JIMAF is reported in Section 5. Section 6 presentsrelated work in the area of MAS interoperability with ref-erence to the introduced taxonomy and discuss our pro-posal in the context of the high-level approaches. Finally,conclusions are drawn and directions of future work brieflydelineated.

2. Background

A Mobile Agent System (MAS) is a distributed softwaresystem responsible for supporting and managing mobileagents, i.e. autonomous software entities which canmigrate from one host to another to fulfill a goal-orientedtask. The research interest in MAS technology has largelybeen driven by the exploitation of Java as a commonlyavailable mobile code technology and platform [18]. Inaddition to code mobility, Java provides a security archi-tecture that is crucial in constructing solutions for securityproblems in MASs. A multitude of Java-based MASs havebeen built over the last few years and although all of themshare the same Java-enabled basic characteristics such asweak mobility, network class loading on demand, commu-nication mechanisms based on message passing, they aresignificantly di!erent and not interoperable.

In order to identify both the di!erences and the com-monalities among Java-based MASs, several MASs wereanalyzed; these MASs were selected according to the fol-lowing criteria: (i) widely cited; (ii) robust and stable; (iii)

very representative of on-going research and commerciale!orts; (iv) very well documented; (v) extensively used fordeveloping a broad range of applications and sophisticatedprogramming systems. This analysis provided architec-tural, programming, design patterns on which the JIMAFframework proposed in this paper was engineered. In par-ticular, the following MASs were considered:

1. Aglets Workbench 2.0.2 or simply ‘‘Aglets’’ [1,21] is aMAS developed by the IBM Tokyo Research Labora-tory, and is probably the most well-known MobileAgent System.

2. Ajanta 2.0 [2,33] is a MAS developed at the Universityof Minnesota whose main purpose is to serve as an infra-structure for research in secure distributed programmingusing mobile agents.

3. Grasshopper 2.2.4 [12], which was jointly developed byGMD Focus and IVK++ GmbH, is the first MASwhich is compliant with the OMG’s MASIF [24,25]and FIPA [11] specifications.

4. Voyager ORB 3.2 [27] is a full-fledged ORB systemdeveloped by ObjectSpace Inc. and, although not pri-marily designed as a MAS, it supports both mobileagents and mobile objects.

In the following subsections, a reference frameworkbased on the framework proposed in [30] was used for sur-veying the terminology and concepts, the main technicalfeatures, and the mobile agent programming models ofthese four MASs.

2.1. Terminology and concepts

Although the MASs analyzed and used have many com-mon or similar aspects, some important di!erences exist.The common aspects (see Table 1) of these MASs are:

- All require a server generically referred to as mobileagent server that supports the main functionalities of amobile agent, such as execution, communication andmigration.

- All provide mobile agents as autonomous and activecomponents (or mobile active objects) that can be auton-omous threads or groups of threads that are independentof the implementation level.

- All provide features to support distributed applicationsbased on the mobile agent paradigm which are indepen-dent of the complexity, richness and ease-of-use of theirrespective mobile agent models.

On the other hand, the main di!erences between thesefour MASs concern the following aspects:

- Terminology. Di!erent names are used to address thesame concepts (mobile agent, context and place):‘‘Mobile agents’’ are called ‘‘aglets’’, ‘‘agents’’, ‘‘mobileagents’’; ‘‘Contexts’’ (i.e. the public interfaces represent-

324 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

ing the MAS) are named di!erently and can be referredto by either a single or multiple interfaces; ‘‘Places’’ (i.e.logical locations where mobile agents run and locallyinteract) are only used by Grasshopper.

- Support level issues. There are basically two conceptualcomponents in all MASs: (i) the Agent Execution Sys-tem (AES), also called mobile agent server, is commonto all the MASs but its name as well as its architectureand functionalities are di!erent; (ii) the Agent ExecutionEnvironment (AEE), which is represented for all theMASs by the JVM, allows mobile agents and the AESto be executed in the same process.

- Management level issues. A set of tools (or managers) isprovided to support the management of users as well asresources such as mobile agents, agent classes, places,etc. In particular, the AES manager is directly availablein Aglets and Grasshopper, whereas, for the others, itcould be implemented ad hoc.

- Application level issues. All four MASs o!er support forhomogeneous mobile agent-based applications. Mobileagents are programmed using Java and proprietarymobile agent programming models of the respectiveMAS with agent communication mainly based on pro-prietary primitives of that MAS. It is worth noting thatGrasshopper also provides support for heterogeneousmobile agent-based applications since it is compliantwith the OMG’s MASIF [24], and Aglets o!ers aKQML Java-based package to exchange KQML mes-sages [19].

2.2. Technical features

Table 2 summarizes the main technical features of thereference MASs. The main focus is on the followingaspects:

- Naming. The type of naming of the mobile agent serverlocation is mainly based on URLs whereas that of themobile agent is centered on a location-independent name

which can have a string or an URL-based representa-tion. A proxy mechanism, used to refer to remote mobileagents, is o!ered by all the reference MASs. The lookupof mobile agents is distributed in Ajanta, Grasshopper,and Voyager, whereas it is enabled in the same local con-text in Aglets.

- Communication. All the reference MASs provide low-level communication primitives based on message trans-mission and compliant with the direct coordinationmodel. The semantics of the message transmission canbe synchronous, asynchronous or based on futures.Aglets, Grasshopper and Voyager o!er all three modeswhereas Ajanta only provides synchronous remotemethod invocations.

- Migration. The type of migration o!ered by all the refer-ence MASs is weak (or stateless) [18] with class transferoccurring mainly on-demand, even though Aglets cantransfer all the classes along with the agent. Class trans-fer in all four MASs is supported by the codebase whichcan be co-located with the agent server or placed on aremote web server. The transfer protocols are ATP(Agent Transport Protocol) in Aglets and Ajanta, andare proprietary or HTTP-based in the other MASs.

- Security. The most secure MASs are Ajanta and Grass-hopper which o!er several security mechanisms forauthorization, authentication, access control, privacyand integrity of the mobile agents and the agent server.Aglets and Voyager only provide basic mechanisms forspecifying access rights of local and remote mobileagents.

2.3. Mobile agent programming models

As pointed out in Section 2.1, significant di!erences existbetween the mobile agent programming models and theAPIs of the four reference MASs. In Table 3 the basicabstractions, the lifecycle methods, and the main basicprimitives are reported:

Table 1Terminology and concepts of the reference MASs

REFERENCE MODEL AGLETS AJANTA GRASSHOPPER VOYAGER

MOBILE AGENT Aglet AgentMobile/Stationary

Agent Agent

CONTEXT Aglet Context Agent Environment Agent System

Agency GUI

multiple interfaces TERMINOLOGY

PLACE none none yes none

AES Agletsd+Tahiti AjantaServer Agency VoyagerSUPPORT

LEVEL AEE JVM JVM JVM JVM

MANAGEMENT LEVEL

AES MANAGER

Tahiti none none

AGENT COMMUNICATION

Java+JAAPI Java Java+CORBA Java+CORBAAPPLICATION

LEVEL AGENT PROGRAMMING

LANGUAGE

Java+Aglets Programming Model

Java+Ajanta Programming Model

Java+Grasshopper Programming Model

Java+Voyager Programming Model

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 325

- Basic abstractions. While in Aglets, Ajanta and Grasshop-per a mobile agent is defined as a class which extends thebasic agent class, in Voyager an agent can be defined usingeither theAgent class or any class as anyobject canbe trans-formed into an agent at run-time. The context can beaccessed by a single direct reference of a specific type inAglets, Ajanta and Grasshopper, whereas in Voyager con-text is accessed through static methods of several classes.

- Lifecycle. The lifecycle model is di!erent for all the refer-ence MASs. The Aglets and Grasshopper lifecycles arebased on an event model according to which an agent isnotified through callbacks if specific events occur: (i) afteran agent creation the onCreation method in Aglets andthe init method in Grasshopper are invoked; (ii) beforeand after an agent migration the onDispatching and theonArrival methods in Aglets and the beforeMove and theafterMove methods in Grasshopper are respectivelyinvoked. The main activity of an agent is performed inthe run method in Aglets and in the live method in Grass-hopper. The Ajanta lifecycle is based on a chaining modelin which, after agent creation, the arrive, run and departuremethods are sequentially invoked. The Voyager lifecycle isevent-based if and only if the IMobile interface is imple-mented. However, the main activity of a Voyager mobileagent can be performed in any method.

- Main primitives. The main primitives of MASs are thosewhich allow an agent to create new agents, migrate to adestination agent server, communicate with other agents,and lookup local as well as remote agents. Althoughthese main primitives are provided by the API of everyMAS, they are obviously di!erent not only with respectto the primitive signature but also with respect to themodel on which the primitive is based. While creationand migration primitives of the reference MASs are allbased on a similar model, in some cases, the models onwhich the communication and lookup primitives arebased are significantly di!erent, as shown in Table 3.

3. The Interoperable Mobile Agent model

An Interoperable Mobile Agent (IMA) is represented bythe pair <HLP, LLP>, where:

- LLP is the Low-Level Part, which depends on the specificMAS where the mobile agent is operating and changesafter a heterogeneous migration, assuming the ‘‘shape’’of the mobile agent of the new hosting MAS.

- HLP is theMAS-neutralHigh-Level Part, which does notchange during the mobile agent lifecycle. HLP is centered

Table 2Main technical features of the reference MASs

REFERENCE MODEL AGLETS AJANTA GRASSHOPPER VOYAGER

TYPE URLs based on DNS names Location-independent globalnames

URLs based on DNS namesLocation-independent global

ID, as well as local proxy

Location-dependent global ID, as well as local proxy

AGENT SERVERLOCATION

atp://<hostname>:<port>/<context>

urn:ans:<hostname>/<username>/<servername>

<protocol>://<host>:<port>/ <agency>/<place> <hostname>:<port>

AGENT ID AgentID <<class>> urn:ans:<hostname>/<username>/<servername>/<agentname>

(String representation)<protocol>://<hostname>:

<port>/<agentname>

PROXY AgentProxy <<class>> Remote Interface/RMI Stub Proxy Objects Proxy Objects

NA

MIN

G

LOOKUP Local in the AgletContext Distributed enabled by theName Registry

Distributed enabled by the Region Registry

Remote-accessible Local Namespace

SEMANTICS Synch/Asynch/Future Synch Synch/Asynch/Future Synch/Asynch/Future

CO

MM

S

LOCALITY Local/ Remote Local/ Remote Local/ Remote Local/ Remote

TYPE Weak Weak Weak Weak CLASS TRANSFER On-demand/Bundle On-demand On-demand On-demand

ATP Manager atp://<host>:<port>/<path>

Agency File System: file:/<driveletter>:/<directory

-path>

MIG

RA

TIO

N

CODEBASE

http://<host>/<path>

Ajanta ServerHTTP Server

http://<domain-name>/<path>

Voyager-enabled HTTP Server

http://<voyagerservername>

AUTHORIZATION ANDACCESS CONTROL

Statically specified accessrights, based on two securitylevels: Trusted and Untrusted

Credentials-based resourceaccess. Authorization based on

agent’s owner.

Access control policies based on authetication/authorization

Statically specified access rights, based on two securitylevels: Native and Foreign

AGENT PRIVACY ANDINTEGRITY

noneDES / ElGamal protocol.Detection of tampering of

agent state and code.

SSL(Secure Socket Layer) /MAC (Message

Authentication Codes) none

AGENT AND SERVERAUTHENTICATION

none Public-key Cryptography X.509 certificates noneSEC

UR

ITY

METERING, CHARGING,AND PAYMENTMECHANISMS

none none none none

326 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

on an event-driven lightweight mobile agent model anduses a proxy-based communication infrastructure. HLPis adapted to LLP through an interface o!ering basic ser-vices to the HLP which are implemented by the LLP.

In the next subsections we describe the mobile agentmodel on which the HLP of an IMA is based, the architec-tural model of the communication infrastructure amongIMAs and the bridging architecture model which allowsan IMA to cross from one heterogeneous MAS to another.

3.1. The event-driven lightweight mobile agent model

An event-driven lightweight mobile agent is representedby the tuple <Id, S, Beh, Tc, Eq>, where Id is the uniqueagent identifier, S is the agent state, Beh is the agent behav-iour, Tc is the thread of control associated to the agent, Eqis the queue of the events received and to be handled by theagent. An event is defined by the tuple EVT = <Source,Target, Type, Args>, where Source and Target are respec-tively the source and the target of the event, Type repre-sents the type of event and Args is a list of parameterswhich the event can contain.

The agent executes the Event Processing Cycle (EPC)(see Fig. 2a) which consists of the cyclically dequeuingand processing of an event according to its state and behav-iour. During event processing, the agent can perform oneof the following actions:

- Computations which can directly a!ect the agent state,creations of agents by invoking the primitive create,and/or transmissions of events by means of the primitivesend.

- Migration by using the primitive migrate.

An event processed by an agent can be generated eitherby the agent itself (self-event) or by another agent (external

event). While the generation of self-events is a proactivemechanism by which an agent is able to autonomouslydrive its activity, external events are a means of interaction.At the end of the event processing, the agent is either in anew, fully defined active state (i.e. ready to react to the nextevent) or in the transit state, in which the agent remainsuntil migration is completed. The migration is asynchro-nous in that it is requested by means of the transmissionof the Move self-event, which is queued at the head ofthe EQ and, when processed, induces the actual agentmigration [9,10].

The event handling and state evolution of an exampleagent are shown in Fig. 2b and c. The example agent is ableto react to the events Move, Reply, and Terminate. In par-ticular, the handling of the Reply event triggers the execu-tion of the following sequence of actions: invocation of thecompute method which performs computations a!ectingthe internal state of the agent, creation of agent Y, trans-mission of the EvtX event to a target agent, and transmis-sion of the Move event to itself. After this execution, theagent is in the state XSj, in which it receives the Move eventthat actually triggers agent migration to the targetdestination.

3.2. The proxy-based communication infrastructure

Inter-agent communication relies on a message-basedcoordination model which allows for asynchronous trans-mission and reception of events between mobile agents.The communication infrastructure is based on Proxieswhich ensure agent location transparency. A mobile agentis always associated to its Proxy: <MA, P>, where MA isthe Mobile Agent and P is the Proxy of MA. The ProxyP is composed of N components: P = <P1, . . .,PN>, oneper agent server that the mobile agent has visited. The com-ponent Pi is a tuple <Id,FW,MBX>, where Id is the iden-tifier of the Proxy component, FW is the forwarder, i.e., the

Table 3Abstractions, lifecycle, and main primitives of the mobile agent programming models of the reference MASs

REFERENCE MODEL AGLETS AJANTA GRASSHOPPER VOYAGER

AGENT Aglet <<class>> Agent <<class>> MobileAgent <<class> Any class/Agent <<class>>

BA

SIC

AB

STR

AC

TIO

N

CONTEXT AgletContext <<class>> AgentEnv <<class>> IAgentSystem <<interface>> set of interfaces

INIT onCreation <<constructor>> init <<constructor>>

ACTIVITY run Any method ( run by default) live Any method

onDispatching departure beforeMove pre/postDeparture

LIF

E

CY

CL

E

MIGRATIONonArrival arrive afterMove pre/postArrival

CREATE createAglet create/launch createAgent Factory.create / new MIGRATE dispatch go move/moveAgent moveTo

RMI sendMessage

Sync RMI with dynamic proxy generation Sync.invoke

sendAsyncMessage OneWay.invoke SEND

sendOnewayMessage

Remote Method

Invocation Future Async RMI with dynamic proxy generation Future.invoke C

OM

MS

RECEIVE handleMessage Remote Interface method Remote Interface method Remote Interface method

AG

EN

T PR

OG

RA

MM

ING

MA

IN P

RIM

ITIV

ES

LOOKUPgetAgletContext().

getAgletProxy (agletID); host.getNameReg().

lookup(partnerURN); regionProxy.

listAgents( null, filter); Namespace.

lookup(agentURL);

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 327

Id of the chained Proxy component, and MBX is the asso-ciated mailbox, which bu!ers events during the migrationof the MA.

In order to send an event to a partner, an MA shouldknow at least the Id of one of the Proxy components ofthe partner MA. Upon the reception of an event, the Proxycomponent inserts the event either into the event queue ofthe MA, if the MA is present, or in the MBX, if the FW isnot active; otherwise, the event is forwarded to the chainedProxy component (see Fig. 3).

Once the MA completes its migration, its proxy compo-nent recovers the events which may be archived in theMBX. The delivery policy of the events can be pro-grammed as follows:

1. Sync MBX retrieval. The proxy component synchro-nously gets the MBX from the previous chained proxycomponent. FW is activated as soon as the getMBXrequest is received. MA is started once the MBX hasbeen received (see Fig. 4a).

2. Async MBX retrieval. The proxy component requests theMBX of the previous chained proxy component. FW isactivated as soon as the requestMBX is received. MBX isthen transmitted ‘‘all together’’ to the requesting chainedproxy component. MA is started after the MBX hasbeen requested (see Fig. 4b).

3. Active MBX forwarding. The proxy component activatesthe FW of the previous chained proxy component. FWis activated as soon as the forward request is received.Afterwards, the MBX is transmitted ‘‘event by event’’to the requesting chained proxy component. MA isstarted after the forward request has been transmitted(see Fig. 4c).

3.3. Bridging mobile agents

Within a network of homogeneous MASs the migra-tion of the IMA is fully supported by its LLP. Con-

versely, in order to move between two heterogeneousMASs, the IMA makes use of mobile agent bridges(MABs). A MAB is a reactive software infrastructurewhich is able to receive an IMA from one MAS andinject it into the target heterogeneous MAS. MABs areto mobile agents as LAN bridges are to network packets.However, LAN bridges are active while MABs are reac-tive, i.e. they provide the bridging service upon requestof the IMA.

Let IMA = <HLP,LLPSOURCE> be an interoperablemobile agent that wishes to migrate from a SOURCEMAS of the X type to a TARGET MAS of the Y type,where X „ Y; the migration schema is as follows(Fig. 5):

EPC:while (!terminated){ e=dequeue(EQ) handleEvent(e) }

handleEvent(e:EVT){ if (Type(e)==’Move’) migrate(Destination(e)) else if (Type(e)==’Reply’){ compute() create(Ys) send(new EvtX(target)) send(new Move(self())) } else if (Type(e)==’Terminate’) terminated=true; }

EVTEQ

XSi

Reply

YS0

<create>

<send>

EvtX

XSj<ready>

Move

<send>

1. 3.Move

XSj<transit>

XSi Agent X with S=Si

External Event

Self-Event

Agent X with S=Sj in Transit

Event delivery

State transitionReaction

2. 4.

<migrate>

<compute>

XSj

Fig. 2. (a) The Event Processing Cycle; (b) event handling method of an example agent in pseudo-code; (c) evolution of the state and basic actions of theexample agent.

MAX

PXi

Agent Server #q

MAY

PYj

Agent Server #p

1.Evt 2. Evt

MAX

PXi

Agent Server #q

MAY

PYj

Agent Server #p

1.Evt

MAY

PYw

Agent Server #t

3. EvtFW_on

2. Evt

0.migrate

MAX

PXi

Agent Server #q

MAY

PYj

Agent Server #p

1.Evt

MBX

2. Evt

0.migrate

FW_off

Fig. 3. Mobile agent interaction: (a) basic, (b) forwarding, and (c)mailbox-mediated event transmission.

328 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

- IMA contacts (step 1) a MAB (MABX fi Y), which pro-vides the bridging from X to Y, by passing its HLPalong with the identifier of the TARGET MAS.

- After receiving the HLP, the MABX fi Y creates (step 2)a new LLP specific to Y (LLPTARGET), adapts (step 3)HLP to LLPTARGET so obtaining the IMA* = <HLP,LLPTARGET>, and homogeneously migrates (step 4)the IMA* to the TARGET MAS.

Although the LLP is substituted, the HLP, which con-tains the activity of the mobile agent, is preserved, makingthe bridging process completely transparent.

4. The java-based interoperable mobile agent framework

The Java-based Interoperable Mobile Agent Framework(JIMAF) is designed and implemented to hide heterogeneityof Java-based MASs and can actually be layered atop avail-able Java-based MASs without requiring any modificationsof the underlying MASs; to date JIMAF has been success-fully layered atopAglets,Ajanta,Grasshopper andVoyager.In the following subsections, we describe the structureand the main dynamics of JIMAF and use an example toillustrate the main features of JIMAF.

4.1. Structure and dynamics

The structure of JIMAF consists of three software layers(see Fig. 6):

- The Interoperable Mobile Agent Layer (IMAL), whichimplements the HLP of the IMA according to the event-driven mobile agent model and the Proxy-based commu-nication infrastructure (see Section 3). In particular, theProxy-based communication infrastructure is imple-mented through the Java RMI middleware. IMAL iscomposed of: (i) the InteroperableAgent class, which isthe abstract class implementing the basic event-drivenmobile agent, and the WrapperAgent and BridgeAgentclasses which extend the InteroperableAgent class andsupport the implementation of the wrapping and bridgingmechanisms; (ii) the AgentDescriptor class, whichencloses the agent identifier as well as the agent locationwhich is represented by the Location class; (iii) the EventandEventQueue classes, which are the classes representingevents and event queues, respectively; (iv) theAgentProxyand EventForwarder classes, which are the classes imple-menting agent proxy components and event forwarders.An AgentProxy is an RMI-enabled remote object.

- The Adaptation Layer (AL), which is an adaptinginterface (IAgent) declaring the following set ofmethods used by the HLP and implemented by theLLP of the IMA: (i) create, which creates a newIMA; (ii) migrate, which uses the platform-dependentmigration primitive to migrate an IMA; (iii) send,which uses a platform-dependent transmission primi-tive to send an event to a target IMA with homoge-neous LLP; (iv) lookup, which uses the platform-dependent lookup service to search for an IMA withhomogeneous LLP.

- The Platform-dependent Mobile Agent Layer (PMAL),which consists of an extendible set of mobile agent clas-ses representing the di!erent LLPs of an IMA. Currentlythe available set consists of the AgletsAgent, Ajanta-Agent, GrasshopperAgent, and VoyagerAgent classeswhich extend the base classes of their respective refer-ence MAS (see Section 2.3).

In the following subsections the structure and the maindynamics of JIMAF are presented.

MAY

PYw

MAY

PYj

Agent Server #p

getMBX

MBX

Agent Server #t

MBX MBX

0. migrate

1.

3. 4.FW on2.

MAY

PYw

MAY

PYj

Agent Server #p

requestMBX

MBX

Agent Server #t

MBX MBX

0. migrate

1.

3. 4.FW on2.

MAY

PYw

MAY

PYj

Agent Server #p

ForwardON

MBX

Agent Server #t

Evti Evti

0. migrate

1.

3. 4.FW on2.

Fig. 4. Mailbox retrieval policies: (a) synchronous, (b) asynchronous, and(c) active-forwarding.

MAS X MAS Y

ASxi ASyj

HLPLLPX

HLPLLPY

MABX!Y

HLP

LLPY2.

3.4.

1.

Fig. 5. Bridging interoperable mobile agents from an agent server of theMAS X to an agent server of the MAS Y where X „ Y.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 329

4.1.1. Lifecycle managementThe creation of an IMA, that can be carried out by a

server application or by another IMA by using the createmethod, consists of the following steps:

1. Creation of an AgentDescriptor that contains the uniqueagent identifier that is independent of the LLP of anIMA and never changes during its lifecycle. The string-based structure of the identifier is:<HostName>-<UserName>-<AgentServerName>-<AgentName>-<Port>, where: <HostName> is the name of the host

where the IMA was created, <AgentServerName> and<Port> are, respectively, the name of the agent serverand the port number of the LLP where the IMA wascreated, <AgentName> is the name of the agent, and<UserName> is the name of the user owning the agent.For example, pards1.deis.unical.it-gfortino-server1-aja1-4095 is the agent identifier of anIMA created atop Ajanta.

2. Creation of the HLP of the IMA by passing the createdAgentDescriptor to the constructor of the Interoperable-Agent class.

InteroperableAgent

+Int eropeableAgent(:AgentDescriptor)+onArrival()+run()+onDeparture()-createProxy()#handleEvent(:Event)+dis patch(:Even t)+send(:Event)+lookup(:String):Location+getMyInfo():AgentDescrip tor+getCurrentLocation():Location+set IAgent(:IAgent)

Location-userName:String-hostName:String-type:String-port:String-agentServerName:String

AgentDescriptor- agName:String- agType:String- us erName:String- id:String- proxyURL:String- homeLocation:Location- currentLocation:Location- previousLocat ion:Location

+ update(:Locat ion)

1*

Event-URLSender:String-URLReceiver:String-tag:St ring-args:Object

EventQueue

+get():Event+put(:Event)

1

*

EventForwarder

+run()

AgentProxy

-teq:Vector-prevURL:String-nextURL:String-temp:boolean

1

*

IEventQueue<<interface>>

+get():Event+put(:Event)

IAgentProxy<<interface>>

+rebind(:InteroperableAgent)+send(:Event)+getTemporaryQueue():Vector+getCurrentLocat ion():Location+setURL(:String)+getNextURL():St ring

1

IAgent<<interfac e>>

+migrate(.Location)+create(:InteroperableAgent, :boolean)+lookup(:Object ):String+send(:Object, :Event)

1

1

AjantaAgent AgletsAgent GrasshopperAgent VoyagerAgent

IMA

LA

LP

MA

L

1

11

1

1

Agent<< from ajanta.agent >>

MobileAgent<<from de.ikv.grasshopper.agency >>

Thread

m yInfo

Aglet<<from com.ibm.aglet >>

WrapperAgent

#translate(:Event):Object#cons tructReply(:Object):Event

BridgeAgent

Fig. 6. The UML class diagram of JIMAF.

330 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

3. Creation of the LLP by passing the created HLP to theLLP constructor; this operation depends on the MASAPI of the LLP (e.g., see the Creation primitives in Table3, Section 2.3).

4. Invocation, carried out by the LLP, of the method setI-Agent (see Fig. 6) of the InteroperableAgent class toadapt the HLP to the LLP.

The lifecycle of an IMA (see Fig. 7), which goes from itscreation to termination and is driven by its LLP in the con-text of which it is always executed (i.e. the LLP lends itsthread to the HLP), is enclosed in the onArrival, run andonDeparture methods of the HLP which are invoked bythe LLP in the following order:

1. onArrival is invoked just after the IMA is created andevery time it arrives at a new agent server. This con-tains the code for creating the proxy component andfor binding or rebinding the IMA to such a proxycomponent.

2. run, which contains the basic code implementing theEPC (see Section 3.1). The processing of events is carriedout through the handleEvent method (see Fig. 6). TheEPC is exited after processing the ‘‘migrate’’ or the ‘‘ter-minate’’ event.

3. onDeparture, which contains the code for handling themigration process of the IMA. If no migration is carriedout during the execution of this method, the IMAterminates.

4.1.2. Communication between interoperable agentsCommunication between IMAs is based on events as

described in Section 3.2. In particular, to communicatewith a partner, an IMA must know the URL of a Proxycomponent of the partner. This information is includedin the AgentDescriptor of the agent partner. The URL for-mat is as follows: rmi://<HostName>:<Port>/

<AgentID>, where: <HostName> and <Port> are respec-tively the name of the host and the port where the Proxycomponent is located, and <AgentID> is the identifier ofthe IMA.

The following steps are carried out by an IMA to trans-mit an external event to a target IMA or a self-event:

1. Creation of the event by using the URL of its currentproxy component (URLSender), the URL of a proxycomponent of the receiving agent (URLReceiver), theevent type (tag), and the list of the event parameters(args).

2. Invocation of the send method (see Fig. 6) by passing thecreated event as parameter.

The send method operates as follows: if URLSender isequal to URLReceiver, the event is directly inserted intothe EQ of the transmitting agent itself; otherwise, theAgentProxy component of the receiving agent is lookedup by using the RMI Naming.lookup method and the sendmethod of the looked-up AgentProxy component isinvoked by passing the event as a parameter. The Agent-Proxy component of the receiving IMA passes the eventto the agent by invoking the dispatch method (seeFig. 6) if the agent is present; otherwise, it queues theevent into the agent mailbox or activates an EventFor-warder component to forward it. Fig. 8 shows an UMLinteraction diagram describing all the steps involved inthe transmission of an event from the interoperablemobile agent IAx to the migrating remote interoperablemobile agent IAy which, after its migration, is bound tothe AgentProxy Py2 which is in turn linked to the Agent-Proxy Py1.

Interactions between IMAs with homogeneous LLPs(i.e. operating on MASs of the same type) can also exploitthe specific communication mechanisms of the hostingplatforms through the lookup and send methods definedin the IAgent interface (see Fig. 6).

onArrival run onDeparture

Found?Yes No

Exit?

Yes

No

Migration?Yes

No

Lookup the ProxyComponent

Rebind to the oldProxy component

Create and Bind to thenew Proxy component

Dequeue the nextavailable Event

Handle the EventMigrate to a

new Destination

Fig. 7. The lifecycle of the InteroperableAgent.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 331

4.1.3. WrapperAgents enabling communication betweeninteroperable agents and platform-dependent agents

To enable communication between interoperable agentsand platform-dependent agents, so allowing for communi-cation interoperability between IMAs and platform-depen-dent agents, wrapping techniques can be exploited [11]. Inparticular, JIMAF exploits the Wrapper Agents (WAs),special JIMAF-based agents which wrap platform-depen-dent agents and act as mediators capable of interactingboth with IMAs by using JIMAF-based events and withplatform-dependent agents by using platform-dependentcommunication mechanisms. This allows for the use/reuseof platform-dependent code and functionalities in the con-text of a JIMAF-based application which is thus consti-tuted by both JIMAF-based agents (IMAs and WAs)and platform-dependent agents.

A JIMAF-based Wrapper Agent is a stationary IMAwhose HLP is constituted by a class which extends theWrapperAgent abstract class (see Fig. 6) and whose LLPdepends on the hosting platform. In particular, the Wrap-perAgent must be extended by overriding:

- the translate method to support the adaptation of thecommunication content from JIMAF-based events toplatform-dependent formats;

- the constructReply method to support the adaptation ofthe communication content from platform-dependentformats to JIMAF-based events;

- the handleEvent method to handle the JIMAF-basedevents sent by an IMA to request services o!ered byplatform-dependent agents.

Fig. 9 shows a general interaction between an IMA and aplatform-dependent agent (PMA), mediated by a WA, in

which the interaction initiator is the IMA. In particular,the IMA sends its request (evtReq) to the WA that, in turn,translates its content into a platform-dependent formatthrough the translate method and incorporates this contentinto a platform-dependent request which is sent to the PMA.As soon as the WA obtains the reply from the PMA, it con-structs the reply event (evtRep) through the constructReplymethod and sends this event to the IMA.

4.1.4. Bridge agents: enabling heterogeneous migrationHeterogeneous migration is enabled by MABs (Mobile

Agent Bridges), which are currently implemented as sta-tionary BridgeAgents that extend the InteroperableAgent.To enable migration between MASs made interoperable,at least one MAB for each MAS must be developed anddeployed. An IMA with the LLP of type X, which is goingto migrate to an agent server of type Y (X „ Y), can sendan event of migration request (migrRequest) to any MABof type Y. A migrRequest contains the HLP of the IMAalong with the Location of the target agent server. The con-tacted MAB therefore creates a new LLP, adapts the HLPof the incoming IMA to it and performs the homogeneousmigration of the obtained IMA towards the target agentserver (see Section 3.3).

4.2. Programming an application through JIMAF

The main features of JIMAF are illustrated bydescribing a JIMAF-based solution for retrieving infor-mation from remote data repositories which are man-aged by agents operating on heterogeneous agentplatforms. This problem could be e!ectively approachedthrough the mobile agent paradigm by employing amobile agent which migrates to the locations of data

IAx : InteroperableAgent Py1 : AgentProxy Py2 : AgentProxy IAy : InteroperableAgent

send(evt:Event) teq.add(evt)

getTemporaryQueue()

dispach(evt:Event) queue.put(evt)

ev=queue.get(0)

handleEvent(ev)

Fig. 8. Sequence diagram of the transmission of an event to a migrating interoperable mobile agent.

332 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

repositories to retrieve requested data by interacting withthe agents which manage these data repositories. Asdemonstrated in the literature [28], such a solution isparticularly e!ective for reducing the time necessary tocomplete the distributed information retrieval task.However, if data repositories are managed by agentsoperating on heterogeneous agent platforms, the exploi-tation of this solution requires that the mobile agentperforming the information retrieval task is capable ofmigrating among heterogeneous agent platforms, execut-ing on these platforms and interacting with the plat-form-dependent agents developed and deployed for themanagement of data repositories. As discussed in Sec-tion 6, to date, JIMAF is the only high-level approachwhich provides full support for the programming ofsuch a roaming mobile agent which satisfies all theaforementioned requirements.

The JIMAF-based solution, which exploits the alreadyavailable platform-dependent local agents (DataAgents)managing the data repositories (in Fig. 10 such an agentfor an Aglet platform is shown), relies on the definitionand implementation of:

- an IMA (RoamingDataAccessor) which, according to agiven itinerary, roams through the heterogeneous agentplatforms where the data repositories are managed bythe DataAgents, retrieves the desired data and departsfor the next location;

- a set of local wrapper agents (DataWrapperAgents), onefor each di!erent type of platform, which may beincluded in the itinerary. Each DataWrapperAgent medi-ates the communication between the RoamingDataAc-cessor and a local DataAgent by using the wrappingtechniques illustrated in Section 4.1.3. In particular, ateach location of the itinerary, the RoamingDataAccessorinteracts through JIMAF-based events with the localDataWrapperAgent, which, in turn, interacts with thelocal DataAgent through the interaction methods pro-vided by the specific platform.

In the following subsections, the utilization of the mostimportant JIMAF features are highlighted by describingthe programming of the RoamingDataAccessor and aDataWrapperAgent. The complete code of the JIMAF-based application can be requested from the JIMAF web-site [17].

4.2.1. Programming the RoamingDataAccessorThe behaviour of the RoamingDataAccessor was speci-

fied through the definition of its HLP (see Section 4.1.1)

IA : InteroperableAgent WA : WrapperAgent PMA :PlatformDependentMobileAgent

send(evtReq:Event)translate(evtReq)

specificMethod

send(evtRep:Event) evtRep=constructReply()

Fig. 9. Sequence diagram of the interaction between an interoperable mobile agent (IA) and a platform-dependent mobile agent (PMA), mediated by awrapper agent (WA).

Fig. 10. The AgletsDataAgent class.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 333

whereas the LLP, which depends on the agent platformswhich host the RoamingDataAccessor during its roamingtask, is already provided by JIMAF for the platformswhich have been made interoperable (see Section 4.1). Inparticular, the definition of the HLP, whose code is shownin Fig. 11, was carried out by overriding:

- the onArrival method to specify the behaviour of theagent after its creation or migration. In particular, afterits creation, the agent migrates onto the first platform ofthe assigned itinerary and after each subsequent migra-tion the agent constructs an event to be sent to theDataWrapperAgent which is active on the current host-ing platform; this event contains the URL of the proxyof the RoamingDataAccessor (URLSender), the URLof the proxy of the DataWrapperAgent (URLReceiver),the event type (DataRequest), and the event content(evtArgs) related to the query for retrieving the desireddata. When the agent completes its itinerary and returnsto the starting location (startingLocation), it analyzes thegathered data through the analiseData method.

- the handleEvent method to specify how the events thatcan be received by the agent are to be handled. In partic-ular: (i) to handle the DataReply event, the agent addsthe data extracted from the content of the event whichis sent by a DataWrapperAgent to its gathered data; inaddition, if the itinerary is not fulfilled, the agent gener-ates a migrate event with itself as target (URLSend-er = URLReceiver) and the next location of theitinerary as content, otherwise, the agent generates andsends a Finish event to itself; (ii) to handle the Finishevent the agent generates a migrate event for triggeringits migration to the startingLocation on which the gath-ered data will be analysed.

The following relevant JIMAF features are highlightedfrom the given description of the RemoteDataAccessor: (i)event-based programming of IMAs which allow for theproactive driving of the IMA behaviour (see migrate andfinish events) and communication with other IMAs (seeDataRequest and DataReply events); (ii) transparent pro-gramming of heterogeneous migrations through the gener-ation of events of the migrate type which are automaticallymanaged by the JIMAF-based bridge infrastructure.

4.2.2. Programming the DataWrapperAgentsFor each type of platform on which the Roam-

ingDataAccessor can migrate, a DataWrapperAgent, whichadapts the communication mechanism of JIMAF to that ofthe specific type of platform, must be defined (see Section4.1.3). Each specific DataWrapperAgent implements: (i)the translate and constructReply methods to support thetranslation of the communication content from/toJIMAF-based events to/from platform-dependent formats;(ii) the handleEvent method to handle the communicationrequests sent by the RoamingDataAccessor (see Section4.2.1). Fig. 12 shows the extension of the DataWrapper-

Agent class for the Aglets platform (AgletsDataWrapper-Agent); similar extensions for the Ajanta, Grasshopper,and Voyager were also developed by exploiting the interac-tion mechanisms specific for such platforms (see Section2.2).

In the following, the above mentioned methods of theAgletsDataWrapperAgent class (see Fig. 12) are described:

- the translate method extracts the event content (i.e. thequery for data retrieving) and returns an Aglets-specificMessage;

Fig. 11. The RoamingDataAccessor class.

334 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

- the ConstructReply method generates a DataReply eventwith the content extracted from the data which has beenprovided by the AgletsDataAgent (see Fig. 10);

- the handleEvent method handles the DataRequest eventby invoking the translate method so obtaining anAglets-specific Message (msg), transmitting it to theAgletsDataAgent (through the synchronous sendMes-sage method of Aglets), constructing the DataReplyevent (evtRep) through the constructReply method, andsending it to the RemoteDataAccessor.

The interaction between the RemoteDataAccessor andthe AglestDataAgent mediated by the AgletsDataWrapper-Agent is shown in Fig. 13.

The following relevant JIMAF features are highlightedfrom the given description of the AgletsDataWrapperAgent:

(i) communication between interoperable mobile agentsand platform-dependent agents (RoamingDataAccessorand AglestDataAgent) mediated by wrapper agents(AgletsDataWrapperAgent) to request services o!ered byplatform-dependent agents (see Section 4.1.3); (ii) use/reuseof platform-dependent code and functionalities in the con-text of a JIMAF-based application which is thus constitutedby interoperable mobile agents (RoamingDataAccessor),wrapper agents (e.g. AgletsDataWrapperAgent) and plat-form-dependent agents (e.g. AgletsDataAgent).

5. Performance evaluation

To evaluate the performance of JIMAF for the currentlyexploited MASs and quantify the performance overheadwhich a high-level approach inevitable introduces, severalmicro benchmarks and a micro kernel were implementedand executed to measure performance indexes defined adhoc. In particular, the micro benchmarks Ping-Pong,Lookup, Message-Transmission, and Creation were usedto test the performance of simple activities implementedby the basic elements of an agent platform. The micro ker-nel Roam was chosen from the di!erent micro kernelswhich have been proposed in the literature [8] for testingthe important JIMAF feature of heterogeneous migration.

The experimentation phase was carried out on a localtestbed consisting of a set of high performance PCs con-nected through a switched Fast Ethernet. Moreover, thesoftware environment was enabled by Windows XP Profes-sional and the Java 2 Standard Edition v.1.4.1.

5.1. Micro Benchmarks

The implemented micro benchmarks Ping-Pong,Lookup, Message-Transmission, and Creation respectivelycapture the overhead of agent migration, agent lookup,message transmission between two agents, and local agentcreation. In particular, the defined micro benchmarks allowfor the evaluation of the following performance indexes(see Table 4 for notation):Fig. 12. The AgletsDataWrapperAgent class.

RDA : RoamingDataAccessor ADWA :AgletsDataWrapperAgent

ADA: AgletsDataAgent

send(evtReq:Event) msg=translate(evtReq)

rs=sendMessage(msg)

send(evtRep:Event) evtRep=constructReply(rs)

sendReply(rs)

Fig. 13. The UML Sequence diagram of the example application w.r.t. Aglets.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 335

1. PPT (Ping-Pong Time), which indicates the timerequired by IAp (NAp) to migrate from Hp

x to Hpr and

return to Hpx. PPT was calculated by executing the

Ping-Pong benchmark for the following three scenarios:- (PP1) Ping-Pong with Caching and Local ClassLoading: the code of NAp and IAp is located on bothHp

x and Hpr , and the measurements are acquired with-

out rebooting p on Hpx and Hp

r .- (PP2) Ping-Pong with No Caching and Local ClassLoading: the code of NAp and IAp is located on bothHp

x and Hpr , and the measurements are acquired by

rebooting p on Hpx and Hp

r for each trial to avoid classcaching e!ects.- (PP3) Ping-Pong with No Caching and Remote ClassLoading: the code of NAp and IAp is located only onHp

x, and the measurements are acquired by rebootingp on Hp

x and Hpr for each trial to avoid class caching

e!ects.2. LKT (LooKup Time), which represents the time that

IApa (NAp

a), created on Hpx, takes for determining the

location of another agent IApb (NAp

b), created on Hpx

and migrated from Hpx to Hp

y and from to Hpy, with the

assumption that IApa (NAp

a) only knows the first locationHp

x of IApb (NAp

b).3. MTT (Message Transmission Time), which is the time

between the transmission of a message from IApa to

IApb (from NAp

a to NApb), hosted respectively on Hp

x

and Hpy, and reception of the acknowledgement, sent

from IApb NAp

b). MTT was calculated in the followingtwo scenarios by the execution of theMessage-Transmis-sion benchmark:

- (MT1) One-Way Message Transmission: IApa !NAp

a"simply sends a message to IAp

b !NApb".

- (MT2) Service Request: IApa !NAp

a" requests an echoservice from IAp

b !NApb" which consists of printing a

received string on its shell and returning the string.4. CRT (CReation Time), which represents the time which

is taken for the local creation of IAp (NAp).

Some results obtained by executing the micro bench-marks are reported in Tables 5 and 6 which show the mostsignificant outcomes regarding: (i) the maximum perfor-mance overhead OH%of the IA for the defined performanceindexes and the platform on which such overhead was mea-sured (Table 5); (ii) the maximum and minimum average

times of the IA for the defined performance indexes andthe platform on which such times were measured (Table 6).

In particular, OH% is calculated as !PIXpIA= PIXp

NA#1" $ 100, where PIXp

IA is the performance index related toIAp while PIXp

NA is the same performance index related toNAp. In addition, each performance index was obtained byaveraging over a sample of 50 measurements.

The analysis of the results shows that, although theoverhead is higher for the highest performance platform,this inevitable overhead is nonetheless contained. More-over, for each performance index, the performance of theIA is comparable with the performance of the lowest per-formance platform.

In particular:

• The maximum OH% for the PPT performance indexwas obtained on Aglets (see Table 5) due to its high per-formance migration mechanism. Moreover, the best per-formance for the PPT (PP3) index was obtained onAglets, whereas the worst performance was obtainedon Grasshopper (see Table 6), which is the lowest per-formance platform with respect to agent migration.

• The maximum OH% for the LKT performance index wasobtained on Ajanta (see Table 5) due to the very fast regis-try-based lookup mechanism of the Ajanta system. More-over, since the lookup mechanism of the IA is independentof the platforms on which the IA operates, the LKT perfor-mance index calculated was the same for all the platforms(see Table 6) and comparable with the lookup performanceof the lowest performance platform (Voyager).

• The maximum OH% for the MTT (MT2) performanceindex was obtained on Voyager (see Table 5) which isthe system providing the highest performance mecha-

Table 4Notation used for the definition of the performance indexes

Symbol Definition

AP A set of Agent Platforms

p 2 AP An Agent Platform

Hp A host running an instance of p

IAp An Interoperable Agent running on an instance of p

NAp A Native Agent programmed using the API of the platform pand running on an instance of p

Table 5Maximum performance overhead of the Interoperable Agent, for eachperformance index, related to the platform on which the overhead wasmeasured

PPT (PP3) LKT MTT (MT2) CRT

OH% 133 288 606 2140

Platform Aglets Ajanta Voyager Voyager

Table 6Maximum and minimum average times measured for the InteroperableAgent for each performance index, related to the platform on which thetimes were measured

PPT (PP3) LKT MTT(MT2)

CRT

Maximum average time(ms)

2465.00 46.50 28.25 790.75

Platform Grasshopper ALL ALL Ajanta

Minimum average time(ms)

2125.30 46.50 28.25 28.00

Platform Aglets ALL ALL Voyager

336 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

nisms for message transmission. Moreover, since themessage transmission mechanism of the IA is indepen-dent of the platforms on which it operates, the MTT(MT2) performance index calculated is the same for allthe platforms (see Table 6) and comparable with themessage transmission performance of the lowest perfor-mance platform (Ajanta).

• The maximum OH% for the CRT performance indexwas obtained on Voyager (see Table 5) due to its highperformance mechanism for agent creation whichadopts thread pooling to improve agent creation.Moreover the best performance for the CRT indexwas obtained on Voyager whereas the worst perfor-mance was obtained on Ajanta (see Table 6) whichis the lowest performance platform with respect toagent migration since Ajanta introduces additionalsecurity data structures in the agent at creation timeand registers a newly created agent into a name regis-try server.

5.2. Micro Kernel

The implemented micro kernel Roam allows for the eval-uation of the following performance index:

- RMT (RoaMing Time). Given the agent platforms p1,. . .,pn, running respectively on Hp1

1 ; . . . ;Hpnn , and, IApi

created on pi (with 1 6 i 6 n), RMT is defined as thetime that IApi takes for returning to the starting host(Hpi

1 ) after visiting only once, all the other hosts Hpij

(with 1 6 j 6 n and j „ i); this path is defined as Com-pletely Heterogeneous Itinerary (CHI). Given a CHI con-sisting of n hosts, the RMT for a number of CHI equalto k is defined as the time that IApi takes for repeatingthe CHI k times.

The Roam micro kernel was executed with p1 = Ajanta,p2 = Aglets, p3 = Grasshopper, p4 = Voyager and fork = {1,2,10,50,100,500,1000}. Fig. 14 shows the averageRMT obtained by varying k and calculated by averagingover a sample of 50 measurements. It is worth pointingout that, when k increases, the average RMT decreases;the reason is that after the first CHI it is possible to exploitthe beneficial e!ects of class caching and local class loadingof the agent platforms employed.

6. Related work

Several approaches have been proposed in the literaturefor enabling interoperability among heterogeneous MASs.The taxonomy, shown in Fig. 15, classifies such approachesinto three further-specializable main classes: specification-based, low-level and high-level. Each class is described inthe following subsections, with a more detailed discussionof the high-level approaches to which the JIMAF approachproposed in this paper belongs.

6.1. Specification-based approaches

Specification-based approaches provide interoperabilityruled by standard specifications such as MASIF (MobileAgent Systems for Interoperability Facility) [25] and/orFIPA (Foundation for Intelligent and Physical Agents)[11].

The MASIF specification contains a detailed conceptualmodel that was agreed upon by five MAS providers (Crys-taliz/MuBot, IBM/Aglets, the Open Group/MOA, GMDFocus/JMAF-Magna, and General Magic/Odyssey) underthe umbrella of OMG. Nevertheless, its focus is on theinteroperability of MASs through the adoption of twomain interfaces: MAF-AgentSystem, for agent transferand management; MAF-Finder, for naming and location.Furthermore, as designed under the umbrella of OMG,MASIF is tightly coupled to CORBA. It is worth notingthat the MASs developed by the MASIF promoters werenot made interoperable through MASIF.

The FIPA specifications focus more on the standardiza-tion of agent systems than on mobile agent systems eventhough the design of an interface between FIPA-basedand MASIF-based agent systems has been defined.

A CORBA-based approach that combines the FIPAcommunication standard with MASIF was proposed in [3].

Despite such standardization e!orts, most of the cur-rently available MASs are compliant to neither MASIFnor FIPA, so must be heavily modified, both in their archi-tecture and programming model so to comply with suchstandards. Therefore, although the benefit of such anapproach involves compliance with standards, the necessityto modify too many already existing MASs which are notcompliant with such standards makes this approach hardlyimpracticable for providing MAS interoperability (seeTable 7).

6.2. Low-level approaches

Low-level approaches support interoperability by addingapplication-level adaptation layers to and modifying theexisting software components of the MASs to be madeinteroperable.

0500

10001500200025003000350040004500500055006000

1 2 10 50 100 500 1000K

RMT(

ms)

for a

sin

gle

CHI

Fig. 14. Average RMT by varying the number of CHI (k).

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 337

The concept of the universal server, able to host amobile agent coming from any MAS, and the use of soft-ware converters between MASs, which are capable of con-verting a mobile agent coming from a source MAS to amobile agent of a target MAS, are research e!orts belong-ing to this class. In particular, the actualization of the uni-versal server concept has been presented in [29] where theagent server of the SeMoA mobile agent system is able tohost mobile agents coming from JADE [4], Tracy [6] andAglets [1,21]. Although this proposal provides usefuldesign and architectural patterns, their application to otherMASs require time-consuming customization.

The use of converters has been reported in [32] in whichthe authors present a way of converting an Aglets agentinto a Voyager agent (and vice versa), so that the agentcan migrate between the Aglets and Voyager platforms.Generally, the use of converters implies the implementationof a converter for each pair of MASs.

Although these approaches are based on voluntaryinteroperability, they require low-level modifications (i.e.at source code level) of the employed MAS which can alterbackward compatibility and thus require MASs sourcecode to be open, which is unlikely in commercial systems(see Table 7).

6.3. High-level approaches

In contrast to specification-based and low-levelapproaches, high-level approaches o!er interoperabilityby means of application-level adaptation layers which areadded to the MAS without modifying the MAS and with-out requiring access to the MAS source code. The defini-tion of a universal agent, able to run on any MAS, andthe creation of a generic interface (also known as the mid-dleware approach) are research e!orts belonging to thisclass. The former has been exploited in [26], whereas thelatter in [16,23,15,7,5].

In particular, [26] uses the metaphor of a ‘‘head’’ that con-tains the agent logic or abstracted mission, and a ‘‘body’’ that

serves to translate migration, communication, and lookupcalls for the specific platform in question. The agent headwould need a di!erent body for each di!erent MAS. Thisapproach only allows for the migration of the ‘‘MONADS’’agents to di!erent agent platforms (currently Grasshopper,JADE, and Voyager), as the head is a MONADS agent.

In [16] a high-level approach is briefly documented whichprovides an ‘‘Abstraction Layer’’ able to allowing for inter-operability of migration and execution among Aglets,Grasshopper, and Voyager.

In [23] the Guest proposal is presented which requires themobile agent to bewritten so to use aGuest interfacewhich islayered on top of the native interface of each mobile-agentplatform. Existing mobile agents must be rewritten to usethe Guest interface. The Guest approach only deliversmigration and execution interoperability between thefollowing MASs: Aglets, Grasshopper, and Voyager.

In [15] GMAS (Grid Mobile-Agent System) is proposed,which, in its simplest version, requires existing mobileagents to be rewritten to use a standard interface. GMAS,however, builds on this simpler functionality and allowsexisting agents to run unchanged atop di!erent mobile-agent platforms. Each agent uses the native interface ofits ‘‘home’’ platform, and ‘‘adaptors’’ (Foreign2GMAS

InteroperabilityApproaches

Specification-based

Low-Level High-Level

ConvertersFIPA MASIF CORBA-based

Middlewareapproach

UniversalAgent

Voyager/Aglets

SEMOA GMAS

GUEST Kalong

JIMAF MONADS

UniversalServer

AbstractionLayer

Fig. 15. Taxonomy of the available approaches for MAS interoperability.

Table 7General comparison of the available approaches for MAS interoperability

Classes Pros Cons

Specification-based

Compliance tostandards

Too many already existingMASs which arenon-compliant with suchstandards

Low-level Reuse of existing MASand voluntaryinteroperability

Source code required.Modifications can alterbackward compatibility

High-level Reuse of existing MASwith no modifications ofthe MAS themselves;high flexibility

The addition of softwarelayers atop already existingMAS could impair e"ciency

338 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

and GMAS2Native) translate the agent from one nativeinterface to another when the agent is visiting a foreignplatform. The adaptors first translate one native interfaceinto a common interface, and then from the common inter-face to the target interface. Such dual translation preventsthe combinatorial explosion in the number of adaptors.GMAS avoids the need for source code access, and usesonly the public interfaces of each mobile-agent system. Inparticular, the Gateway component, used by foreign agentsto move to other GMAS-capable MASs, serves as a con-duit to the agent transport mechanism (discovery, marshal-ing and movement) at the source, while the Launchercomponent handles incoming launch requests, unmarshal-ling, and execution support for newly arrived agents.GMAS provides migration and execution interoperabilitywhereas communication interoperability is deemed to beof minor importance. In particular, GMAS currentlygrants interoperability between D’Agents [13], Nomads[31] and EMAA [22]. Indeed, the actual application ofGMAS required one change to the existing implementa-tions of each used native platform: a fallback mechanismwas introduced to try the Gateway if the native transferprotocol failed. For this reason, the GMAS approach isclassified between the low-level and the high-levelapproaches.

In [7,5] the authors propose a mobility service, namedKalong, which was designed to be independent of anyexisting agent toolkit and only requires that mobile agentclasses implement the Java Serializable interface. Kalongwas integrated into Tracy [5] and, currently, also intoJADE [7]. In particular, the integration of Kalong as anew mobility service into JADE was straightforward with-out requiring any changes to Kalong or JADE. In addition,the migration performance of JADE agents can be signifi-cantly improved using Kalong. This innovative approachis, however, only able to provide migration and limited exe-cution interoperability among MASs and has currentlybeen applied to grant interoperability only between Tracyand JADE.

JIMAF belongs to the class of high-level approachesand, in particular, uses both the concept of universal agentand the middleware approach (see Fig. 15). The universalagent represented by the HLP of the IMA is adaptedthrough the AL interface to the LLP of a given MAS(see Sections 3 and 4.1). This allows for execution interop-erability at low-cost as the process of adapting HLP onto anew MAS is straightforward; in fact, the development of anew LLP is required – that is, a mobile agent class whichextends the specific mobile agent class of the new MASand implements the IAgent interface (see Section 4.1).The middleware approach is used for the communicationand migration interoperability. RMI middleware (see Sec-tions 3.2 and 4.1.2) is used to support communicationinteroperability whereas the migration is based on a bridg-ing infrastructure capable of receiving an IMA from asource MAS and injecting it into a di!erent target MAS(see Sections 3.3 and 4.1.4). The bridging infrastructure

concept is similar to the Gateway-based architecture pro-posed by GMAS but is implemented without any modifica-tions of the MASs used. JIMAF is therefore e!ective toprovide interoperability of execution, migration, and com-munication. Moreover, to enable communication betweeninteroperable mobile agents and platform-dependentagents, wrapper agents are provided which act as mediatorscapable of interacting both with IMAs by using JIMAF-based events, and with platform-dependent agents by usingplatform-dependent communication mechanisms (see Sec-tion 4.1.3).

In conclusion, in light of the strengths and drawbacks ofthe currently available high-level approaches, the reuse ofexisting MASs without any modifications o!ers a greatadvantage. In fact, although e"ciency may be impairedby the addition of software layers atop MASs (see Table7), the JIMAF approach can provide high flexibility alongwith backward compatible solutions.

6.3.1. ComparisonWe hereby compare the pros and cons of the JIMAF

approach with respect to the aforementioned high-levelapproaches on the basis of the following criteria (see Table8):

(i) Interoperability type: JIMAF and MONADS grantinteroperability of execution, migration and commu-nication whereas Kalong is only focused on migra-tion interoperability and the others o!er onlyexecution and migration interoperability.

(ii) Ease-of-use: JIMAF and MONADS are verystraightforward to make new MASs interoperablewhereas GMAS requires some modifications of theMASs which, however, also call for the deep knowl-edge of such MASs at source code level. The integra-tion of Kalong into new MASs requires the deep ofknowledge of both Kalong and the new MASs atthe API level.

(iii) Availability: currently, only JIMAF, GMAS andKalong are publicly available on the Web.

(iv) Performance: only JIMAF, GMAS and Kalonghave documented performance overheads withrespect to the MASs made interoperable. In partic-ular, Kalong and GMAS only provided documen-tation of migration performance: the maximumperformance overhead measured for GMAS is6500% on D’Agents, the maximum performanceoverhead measured for JIMAF is 133% on Aglets,whereas, Kalong, being basically a mobility service,is able to boost the performance of slow mobilityservice layer (as demonstrated for JADE [7]).Moreover, the performance of JIMAF in messagetransmission and lookup can be improved whenan IMA interact with another IMA having thesame type of LLP. Such an IMA can actually usethe specific platform-based send and lookup primi-tives provided by its LLP.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 339

(v) Application reuse:AsGMAS, JIMAFallows for the use/reuse of platform-dependent code and functionalities. Inparticular, JIMAF o!ers reuse through wrapping tech-niques which allow for the communication betweeninteroperable mobile agents and platform-dependentagents (see Sections 4.1.3 and 4.2). These features arenot provided by any other high-level approaches.

7. Conclusions

As widely agreed, the exploitation and di!usion ofmobile agents would undoubtedly increase if mobile agentsystems were interoperable. Although several standardiza-tion and research e!orts have been devoted to enablinginteroperability among MASs, the majority of the availableMASs are, to date, not interoperable.

In this paper, we have presented a high-level approachfor MAS interoperability which is enabled by JIMAF(Java-based Interoperable Mobile Agent Framework)which supports the interoperability of execution, migrationand communication between heterogeneous Java-basedmobile agent systems. The main advantages provided byJIMAF are the following:

- programmers can develop mobile agents independentlyof any particular MAS which will support them, thusenabling mobile agent-based computing across a rangeof computing domains which are based on heteroge-neous MASs;

- new or other already existing MASs can be easily madeinteroperable by (i) further specializing the PMAL so toobtain new low-level parts of the interoperable mobileagents, and (ii) developing mobile agent bridges for suchMASs;

- the reuse of platform-dependent code is easily providedthrough wrapper agents.

JIMAF was experimented to make interoperableAglets, Ajanta, Grasshopper, and Voyager. The perfor-mance evaluation carried out with respect to the MASsmade interoperable has shown that the expected over-head, which a high-level approach inevitably introduces,is acceptable in open, heterogeneous computing environ-

ments like those based on the Internet, where opennessand interoperability are more important than high-perfor-mance. We have also compared our approach, on thebasis of selected criteria, with other high-level approachescurrently available in the literature and have shownthat, overall, the JIMAF approach is more e!ective thanthe others for providing interoperability of execution,migration and communication.

The growing interest on MASs interoperability of indus-trial and academic communities is demonstrated by thenew FIPA (Foundation for Intelligent and PhysicalAgents) initiative, which is being re-launched under theumbrella of IEEE, to promote a working group on mobileagents, to which the authors of this paper are contributingand whose main objective is to establish standard architec-tures and protocols for complete MASs interoperability ofexecution, migration, communication, and security. On-going research e!orts are therefore devoted to: (i) makinginteroperable Tracy, Semoa and JADE; (ii) decentralizingthe bridging infrastructure; (iii) designing a security infra-structure for interoperability.

References

[1] Aglets mobile agent system, documentation and software. Availablefrom http://aglets.sourceforge.net/, 2002.

[2] Ajanta mobile agent system, documentation and software. Availablefrom http://www.cs.umn.edu/Ajanta/, 2003.

[3] P. Bellavista, A. Corradi, C. Stefanelli, Corba solutions for interoperabilityin mobile agent environments, in: Proceedings of the 2nd InternationalSymposium on Distributed Objects and Applications (DAO 2000), 21–23September, Antwerp, The Netherlands, 2000, pp. 283–292.

[4] F. Bellifemine, A. Poggi, G. Rimassa, Developing multi-agent systemswith a FIPA-compliant agent framework, Software – Practice andExperience 31 (2) (2001) 103–128.

[5] P. Braun, I. Muller, S. Geisenhainer, V. Schau, W.R. Rossak, Agentmigration as an optional service in an extendable agent toolkit architec-ture, in: A. Karmouch, L. Korba, E. Madeira (Eds.), Proceedings of the1st International Workshop on Mobility Aware Technologies andApplications (MATA 2004), 20–22 October 2004, Florianopolis, Brazil,LNCS 3284, Springer Verlag, Berlin, 2004, pp. 127–136.

[6] P. Braun, W.R. Rossak, Mobile Agents–Basic Concept, MobilityModels, and the Tracy Toolkit, Morgan Kaufmann Publishers,2005.

[7] P. Braun, D. Trinh, R. Kowalczyk, Integrating a new mobilityservice into the Jade agent toolkit, in: A. Karmouch, S. Pierre(Eds.), Proceedings of the 2nd International Workshop on MobilityAware Technologies and Applications (MATA 2005), 17–19

Table 8Comparison of the available high-level approaches for MAS interoperability

High-level approach Comparison criteria

Interoperability type Easy-to-use Availability Migration performance overhead% Applications reuse

GMAS Migration/Execution Low Yes 6500 Yes

GUEST Migration/Execution Medium No N/A No

Abstraction layer Migration/Execution N/A No N/A No

MONADS Migration/Execution/Communication High No N/A No

Kalong Migration Medium Yes #40 N/A

JIMAF Migration/Execution/Communication High Yes 133 Partial

340 G. Fortino et al. / Information and Software Technology 50 (2008) 322–341

October 2005, Montreal, Canada, LNCS 3744, Springer Verlag,Berlin, pp. 354–363.

[8] M. Dikaiakos, M. Kyriakou, G. Samaras, Performance evaluation ofmobile-agent middleware: A hierarchical approach, in: J.P. Picco(Ed.), Proceedings of the 5th IEEE International Conference onMobile Agents, 2–4 December 2001, Atlanta, Georgia, LNCS 2240,Springer Verlag, Berlin, 2005, pp. 244–259.

[9] G. Fortino, F. Frattolillo, W. Russo, E. Zimeo, Mobile ActiveObjects for highly dynamic distributed computing, in: Proceedings ofthe IEEE IPDPS’02, Workshop on Java for Parallel and DistributedComputing, 15–19 April, Fort Lauderdale, FL, 2002, pp. 1–8.

[10] G. Fortino, W. Russo, E. Zimeo, A Statecharts-based softwaredevelopment process for mobile agents, Information and SoftwareTechnology 46 (13) (2004) 907–921.

[11] Foundation for Intelligent and Physical Agents, documentation andspecifications. Available from http://www.fipa.org, 2004.

[12] Grasshopper mobile agent system, IKV++ GmbH, documentationand software. Available from http://www.grasshopper.de/, 2003.

[13] R.S. Gray, G. Cybenko, D. Kotz, R.A. Peterson, D. Rus, D’Agents:Applications and performance of a mobile-agent system, Software –Practice and Experience 32 (6) (2002) 543–573.

[14] R. Gray, D. Kotz, G. Cybenko, D. Rus, Mobile Agents: Motivationsand State of the Art Systems, Technical Report TR2000-365,Dartmouth College, Hanover, N.H., April 2000.

[15] A. Grimstrup, R. Gray, D. Kotz, M. Breedy, M. Carvalho, T. Cowin,D. Chacon, J. Barton, C. Garret, M. Hofmann, Toward interoper-ability of mobile-agent systems, in: Proceedings of the 6th IEEE Int’lConference on Mobile Agents, 22–25 October 2002, Barcelona,SpainLNCS 2535, Springer Verlag, Berlin, 2002, pp. 106–120.

[16] T. Gschwind, Comparing object oriented mobile agent systems, in:Proceedings of the 6th ECOOPWorkshop on Mobile Object Systems,June 13, Sophia Antipolis, France, 2000.

[17] JIMAF (Java-based Interoperable Mobile Agent Framework), doc-umentation and software. Available from http://lisdip.deis.unical.it/software/jimaf/, 2006.

[18] N.M. Karnik, A.R. Tripathi, Design issues in mobile-agent program-ming systems, IEEE Concurrency 6 (3) (1998) 52–61.

[19] Y. Labrou, T. Finin, Y. Peng, The interoperability problem: Bringingtogether mobile agents and agent communication languages, in:Proceedings of the IEEE Hawaii Int’l Conference on System Sciences,5–8 January, Maui, Hawaii, 1999.

[20] J. Lakos, Large Scale C++ Software Design, Addison-Wesley, 1996.[21] D. Lange, M. Oshima, Programming and Deploying Java Mobile

Agents with Aglets, Addison-Wesley, 1998.

[22] R.P. Lentini, G.P. Rao, J.N. Thies, J. Kay, EMAA: An extendablemobile agent architecture, in: Proceedings of the AAAI Workshop onSoftware Tools for Developing Agents, 26–27 July 1998, Madison,Wisconsin, AAAI Press, 1998, pp. 133–134.

[23] L. Magnin, V.T. Pham, A. Dury, N. Besson, A. Thiefaine, Our guestagents are welcome to your agent platforms, in: Proceedings of theSymposium on Applied Computing (SAC’02), 10–13 March, Madrid,Spain, 2002, pp. 107–114.

[24] MASIF (Mobile Agent System Interoperability Facility) specification,OMG TC Document orbos/98-03-09. Available from ftp://ftp.om-g.org/pub/docs/orbos/98-03-09.pdf, 1998.

[25] D.Milojicic,M.Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman,K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagrisw-aran, J. White, MASIF: The OMGmobile agent system interoperabil-ity facility, Personal Technologies 2 (3) (1999) 117–129.

[26] P. Misikangas, K. Raatikainen, Agent migration between incompat-ible agent platforms, in: Proceedings of the 20th Int’l Conference onDistributed Computer Systems, IEEE Computer Society Press, 10–13April, Taipei, Taiwan, 2000, pp. 4–10.

[27] Objectspace Voyager, documentation and software. Available fromhttp://www.recursionsw.com/products/voyager, 2003.

[28] G. Picco, Mobile agents: An introduction, Journal of Microproces-sors and Microsystems 25 (2) (2001) 65–74.

[29] U. Pinsdorf, V. Roth, Mobile agent interoperability patterns andpractice, in: Proceedings of 9th Annual IEEE Int’l Conference andWorkshop on the Engineering of Computer-Based Systems (ECBS),8–12 April, Lund, Sweden, 2002, pp. 238–244.

[30] A.R. Silva, A. Romao, D. Deugo, M. Mira da Silva, Towards areference model for surveying mobile agent systems, AutonomousAgent and Multi-Agent Systems 4 (3) (2001) 187–231.

[31] N. Suri, J.M. Bradshaw, M.R. Breedy, P.T. Groth, G.A. Hill, R.Je!ers, Strong mobility and fine-grained resource control inNOMADS, in: Proceedings of the Joint Symposium ASA/MA2000,13–15 September 2000, Zurich, SwitzerlandLNCS 1882, SpringerVerlag, Berlin, 2000, pp. 2–15.

[32] D. Tjung, M. Tsukamoto, S. Nishio, A converter approach for mobileagent systems integration: A case of Aglets to Voyager, in: Proceed-ings of the 1st International Workshop on Mobile Agents forTelecommunication Applications (MATA 1999), 6–8 October,Ottawa, Canada, 1999, pp. 179–195.

[33] A.R. Tripathi, N.M. Karnik, T. Ahmed, R.D. Singh, A. Prakasah, V.Kakani, M.K. Vora, M. Pathak, Design of the Ajanta System formobile agent programming, Journal of Systems and Software 62 (2)(2002) 123–140.

G. Fortino et al. / Information and Software Technology 50 (2008) 322–341 341