high-level interoperability between java-based

HIGH-LEVEL INTEROPERABILITY BETWEEN JAVA-BASED MOBILE AGENT SYSTEMS* Giancarlo Fortino and Wilma Russo Dipartimento di Elettronica, Informatica e Sistemistica (DEIS) University of Calabria Via P. Bucci, 87036 Rende (CS), Italy {g.fortino, w.russo}@unical.it Abstract One of the major setback preventing the mobile agent technology from being widely exploited is a lack of interoperability between heterogeneous mobile agent systems. In this paper we propose a Java-based framework which enables high-level interoperability between Javabased mobile agent systems. The framework relies on an event-driven, proxy-based mobile agent model and allows for supporting interoperable mobile agents which can be easily coded and adapted to existing mobile agent systems without any modifications of their infrastructures. We tested our framework for enabling interoperability among the Aglets, Ajanta, Grasshopper and Voyager systems. The experimentation results showed that high efficacy is obtained by keeping the efficiency overhead acceptable for heterogeneous computing environments. Keywords. Mobile Agents, Events, Proxy-based Coordination Model, Mobile Agent Interoperability, Agent Frameworks. 1.

INTRODUCTION

In the last few years mobile agent paradigm and technology [8, 9] have shown high potential and flexibility for designing and developing general-purpose distributed applications, particularly in heterogeneous and open environments like the Internet. Although plenty of Mobile Agent Systems (MAS) are currently available, the following major setbacks still affect mobile agents by preventing them from being widely employed: (i) lack of appropriate security mechanisms, (ii) lack of interoperability, and (iii) lack of software development processes and modeling languages. In particular, interoperability is highly required in case that heterogeneous MAS come into contact with each other. Such a contact is expected to be very frequent in open systems where a mobile agent to fulfill its goal has to traverse domains served by different MAS and communicate with non-homogeneous mobile agents. Interoperability between mobile agent systems can be defined as follows: two MAS are interoperable if a mobile agent of one system can migrate to the second system, the mobile agent can interact and communicate with other mobile agents on this system (or even with remote mobile

agents), the mobile agent can leave this system, and it can resume its execution on the next interoperable system [14]. Interoperability involves the following issues: - Execution: how to adapt the lifecycle of a mobile agent to different MAS and how to enable a mobile agent to access to resources of MAS. - Communication: how to adapt the message transport layers of MAS to one another and the communication language among different mobile agents. - Mobility: how to adapt the agent transport protocols and the agent encoding of the different MAS. - Security: how to authenticate mobile agents of different MAS and appraise their behavior. Approaches for providing interoperability roughly fall into three main classes: (i) specificationbased, (ii) low-level and (iii) high-level. The specification-based approach provides interoperability ruled by standard specifications such as MASIF (Mobile Agent Systems for Interoperability Facility) [12] and/or FIPA (Foundation of Intelligent and Physical Agents) [5].The MASIF specification contains a detailed conceptual model that was agreed upon by five MAS providers. Nevertheless, its focus is on the interoperability of MAS through the adoption of two main interfaces: MAF-AgentSystem, for agent transfer and management; MAF-Finder, for naming and location. Furthermore, MASIF was designed for the OMG, consequently it is tightly coupled to CORBA. The FIPA specifications are more focused on the standardization of agent systems than on mobile agent systems. However, most of the currently available MAS are compliant neither to MASIF nor to FIPA, so they should be heavily modified, both in their architecture and in their programming model, to comply with such standards. The low-level approach allows for interoperability by adding application-level adaptation layers to and/or modifying existing software components of the MAS to be made interoperable. Although, this approach is based on a voluntary interoperability, it often requires low-level modifications (i.e. at source code level) of the employed MAS. In [14] this kind of approach was experimented by providing interoperability of execution between the SeMoA mobile agent server and the Jade, Tracy and the Aglets agents. This experience delivered useful patterns which can be actually applied to other MAS only after a time-consuming customization phase.

* This work was partially funded by the University of Calabria in the framework of the Project “Giovane Ricercatore 2003” entitled “Development of a P2P infrastructure based on mobile agents for next generation Internet applications”.

Conversely, in the high-level approach, application-level adaptation layers are added to make MAS interoperable without any modifications of the MAS. In [6] an high-level approach is briefly documented which provides an Abstraction Layer able to allow for interoperability of migration among Grasshopper, Voyager and Aglets. Another branch of noteworthy research focuses on the interoperability of interaction between mobile agents through agent communication languages (ACLs). In [10] a study of the integration of ACLs (e.g., KQML and FIPA ACL) into mobile agent frameworks was reported. Obviously, this integration would lead to an upgrade of the existing MAS. The solutions developed to date are still not satisfactory since they only address some of the aforementioned interoperability issues; furthermore, no performance evaluation of such solutions have been provided. In this paper, we propose a framework, based on a fully high-level approach, which enables interoperability of execution, migration and communication among heterogeneous Java-based MAS. The framework is structured in three layers: (i) the Interoperable Mobile Agent Layer (IMAL), which allows to program mobile agents which are independent from any specific MAS; (ii) the Adaptation Layer (AL), which adapts an interoperable mobile agent to a specific MAS; (iii) the Platformdependent Mobile Agent Layer (PMAL), which provides a set of basic, platform-dependent mobile agents on which interoperable mobile agents are adapted by means of the AL. An interoperable mobile agent therefore consists of a MAS-neutral high-level part, which does not change during the mobile agent lifecycle, and a low-level part, which depends on the specific MAS in which the mobile agent is operating and changes after a heterogeneous migration by assuming the “shape” of the mobile agent of the new hosting MAS. While execution and communication interoperability is directly furnished by the framework, heterogeneous migration is enabled by mobile agent bridges, which allow for crossing interoperable mobile agents from one MAS to another. In order to quantify the performance overhead which an application-level layered approach inevitably introduces, we compared the performances of the basic mechanisms (lookup, message transmission, migration) of the interoperable mobile agent and of the mobile agents of the employed MAS. The results showed a contained performance overhead which is acceptable within massively heterogeneous computing environments like the Internet where interoperability and openness are more important than high performances [3, 8]. The remainder of the paper is structured as follows. In section 2 the employed mobile agent systems are overviewed and compared. Section 3 describes the interoperable mobile agent model on which the interoperability framework relies. In section 4 the framework is presented and its performance evaluation

described in section 5. Finally, conclusions are drawn and directions of future work briefly discussed. 2.

THE REFERENCE JAVA-BASED MOBILE AGENT SYSTEMS

The research interest in mobile agent technology was largely driven by the exploitation of Java as a universally available mobile code technology [9]. In addition to code mobility, Java provides a security architecture that helps in constructing solutions for the security problems in MAS. A MAS is a system responsible for supporting and managing mobile agents, i.e. autonomous software entities which can migrate from one host to another to fulfill a goal-oriented task. A multitude of Java-based MAS have been built in the last few years. Although, all of them share the same Javaenabled basic characteristics such as weak mobility, network class loading on demand, communication mechanisms based on message passing, they are significantly different. In order to individuate and define both the differences and the commonalities among Javabased MAS, the Aglets Workbench 2.0.2, Ajanta 2.0, Grasshopper 2.2.4, and Voyager 4.7 systems were analyzed in depth. Aglets Workbench or simply Aglets [1, 11] is a MAS conceived at the IBM Tokyo Research Laboratory, that is probably the most famous agent system among the chosen systems. Ajanta [2, 16] is a MAS developed at the University of Minnesota whose main purpose is to server as an infrastructure for research in secure distributed programming using mobile autonomous agents. Grasshopper [7] is a MAS jointly developed by the GMD Focus and the IVK++ GmbH. It is the first MAS which is compliant to the OMG’s MASIF and FIPA specifications. Voyager ORB [17] is a full-fledged ORB system developed by ObjectSpace Inc. Although it was not primarily designed as a MAS, it supports both mobile agents and mobile objects. These reference MAS were selected over many candidates mainly for the following reasons: (i) widely cited; (ii) robust and stable; (iii) very representative of the on-going research and commercial efforts; (iv) very well documented; (v) extensively used for developing a broad range of applications and sophisticated programming systems. The analysis of the reference MAS allowed to gain insights into and extract architectural, design and programming patterns on the basis of which the framework proposed in this paper was engineered. Their analysis is presented, in the following, using the framework proposed in [15] for surveying concepts, terminology, and the main technical features of MAS. 2.1

Terminology and concepts

Although the analyzed and used MAS have many common or similar aspects, they also exhibit important

differences. The common aspects that all MAS support are: - all require some kind of server (generically called mobile agent server) that supports the main functionalities; - all provide mobile agents as autonomous and active components (or mobile active objects) that can be autonomous threads or groups of threads, which are independent of the implementation level; - all provide features to support the same kind of applications: distributed applications based on the mobile agent paradigm which are independent of the complexity, richness and ease-of-use of their respective mobile agent model. On the other hand, the main differences are based on: - Terminology. Different names are used to address the same concept. For instance, mobile agents are called “aglets”, “agents”, “mobile agents”; contexts (i.e. the public interfaces representing the MAS) are differently named and can be referred by a single or multiple interfaces; places (i.e. logical locations where mobile agents execute and locally interact) are only used by Grasshopper. - Support level issues. There are basically two conceptual components in all MAS: (i) the Agent Execution System (AES), also called mobile agent server, which is common to all the MAS but its name as well as its architecture and functionalities are different; the Agent Execution Environment (AEE), which is represented for all the MAS by the JVM, allows executing mobile agents and the AES in the same process. - Management level issues. A set of tools (or managers) should be provided to support management of users as well as resources such as mobile agents, agent classes, places, etc. In particular, the AES manager is directly available in Aglets (Tahiti) and Grasshopper (Agency GUI), whereas, for the others, it should be ad-hoc implemented. - Application level issues. All the analyzed MAS offer support for homogeneous mobile agent-based applications. Mobile agents are programmed using Java and the proprietary mobile agent programming models of the MAS. The agent communication language of the MAS is mainly based on proprietary primitives. It is worth noting that Grasshopper also provides support for heterogeneous mobile agent-based applications since it is compliant to the OMG’s MASIF [13], and Aglets offers a KQML Java-based package to exchange KQML messages [10]. 2.2

Technical features

In the following the main technical features of the reference MAS are described: - Naming. The naming type of the mobile agent server location is mainly based on URLs whereas that of the mobile agent is centered on a location-independent

name which can have an URL-based or a string representation. A proxy mechanism, used to refer to remote mobile agents, is offered by all the reference MAS. The lookup of mobile agents is distributed in Ajanta, Grasshopper, and Voyager, whereas it is enabled in the same local context in Aglets. - Interaction. All the reference MAS provide low-level communication primitives, based on message transmission compliant with the direct coordination model. The semantics of the message transmission can be synchronous, asynchronous, or based on futures. Aglets, Grasshopper and Voyager offer all three kinds, whereas Ajanta only provides synchronous remote method invocations. - Migration. The type of migration offered by all the reference MAS is weak (or stateless) [9]. The class transfer is mainly on-demand, even though Aglets can transfer all the classes along with the agent. Class transfer is supported by the codebase which can be colocated with the agent server or placed on a remote web server. The transfer protocol is the ATP (Agent Transport Protocol) in Aglets and Ajanta, proprietary or HTTP-based in the other MAS. - Security. The most secure MAS are Ajanta and Grasshopper, which offer several security mechanisms for authorization, authentication, access control, privacy and integrity of the mobile agents and the agent server. Aglets and Voyager only provide basic mechanisms for specifying the access rights of local and remote mobile agents. 2.3

Mobile agent programming models

As pointed out in §2.1, significant differences exist between the mobile agent programming models and APIs of the reference MAS. In the following the basic abstractions provided by the MAS and the lifecycle model of mobile agents are discussed: - Basic abstractions. While in Aglets, Ajanta and Grasshopper a mobile agent is defined as a class extending a basic agent class, in Voyager an agent can be defined using either the Agent class or any class since any object can be transformed into an agent at run-time. The context can be accessed by a single direct reference of a specific type in Aglets, Ajanta and Grasshopper, whereas in Voyager it is accessed through static methods of several classes. - Lifecycle. The lifecycle model is different for all the reference MAS. The Aglets and Grasshopper lifecycles are based on an event model according to which an agent is notified through callbacks if specific events occur: (i) after an agent creation is invoked the onCreation method in Aglets and the init method in Grasshopper; (ii) before and after an agent migration are respectively invoked the onDispatching and the onArrival methods in Aglets and the beforeMove and the afterMove methods in Grasshopper. The main

activity of an agent is performed in the run method in Aglets whereas in the live method in Grasshopper. The Ajanta lifecycle is based on a chaining model in which, after the agent creation, the arrive, run and departure methods are consecutively invoked. The Voyager lifecycle is event-based if the IMobile interface is used. However, the main activity of a Voyager mobile agent can be performed in any method.

the agent is either in a new, fully defined state, ready to react to the next event, or in the Transit state, in which the agent remains until the migration is completed. The migration is asynchronous in that it is requested by means of the transmission of the Move event, which is enqueued in the EQ and, when processed, induces the actual agent migration [3, 4]. 3.2

3.

THE INTEROPERABLE MOBILE AGENT MODEL

An Interoperable Mobile Agent (IMA) is represented by a pair , where: - LLP is the Low-Level Part, which depends on the specific MAS where the mobile agent is operating and changes after a heterogeneous migration by assuming the “shape” of the mobile agent of the new hosting MAS. - HLP is the MAS-neutral High-Level Part, which does not change during the mobile agent lifecycle. HLP is centered on an Event-driven Lightweight Mobile Agent Model and uses a Proxy-based Asynchronous Message Infrastructure. HLP is adapted to LLP through an interface offering basic services to the HLP which are implemented by the LLP. 3.1

The Event-driven Lightweight Mobile Agent Model

An event-driven lightweight mobile agent is represented by the tuple , where Id is the unique agent identifier, S is the agent state, Beh is the agent behavior, Tc is the thread of control associated to the agent, Eq is the queue of the events received and to be handled by the agent. An event is defined by the tuple EVT=, where Source and Target are respectively the source and the target of the event, Type represents the type of the event, Args is a list of parameters which the event can contain. The agent executes the Event Processing Cycle (EPC) which consists of cyclically dequeuing and processing an event according to its state and behavior. During the event processing, the agent can do one of the following: - computations which directly can affect the agent state, creations of agents by invoking the create primitive, and transmissions of events by means of the send primitive; - a migration by using the migration primitive. An event processed by an agent can be generated either by the agent itself (self-event) or by another agent (external event). While the generation of self-events is a proactive mechanism by which an agent is able to autonomously drive its activity, external events are a means of interaction. At the end of the event processing,

The Proxy-based Asynchronous Coordination Infrastructure

The coordination model is of the Direct type and allows for asynchronous transmission and reception of events among mobile agents. The infrastructure supporting the coordination model is based on Proxies which provide agent location transparency. A mobile agent is always associated to its Proxy: , where MA is the Mobile Agent and P is the Proxy of MA. The Proxy P is composed of N components: P=, one per each agent server the mobile agent visited. The component Pi is a tuple , where Id is the identifier of the Proxy component, FW is the forwarder, i.e., the Id of the chained Proxy component, and MBX is the associated mailbox, which buffers events during the migration transitory of the MA. In order to send an event to a partner, an MA should know at least the Id of one of the Proxy component of the partner MA. Upon the reception of an event, the Proxy component inserts the event either into the event queue of the MA, if the MA is present, or in the MBX, if the FW is not active; otherwise, the event is forwarded to the chained Proxy component. Once the MA completes its migration, its proxy component recovers the events possibly archived in the MBX. 3.3

Bridging Mobile Agents

Within a network of homogeneous MAS the migration of the IMA is fully supported by its LLP. Conversely, in order to move between two heterogeneous MAS, the IMA makes use of mobile agent bridges (MAB). A MAB is a reactive software infrastructure which is able to receive an IMA from one MAS and to inject it into the target heterogeneous MAS. MAB are to mobile agents as LAN bridges are to network packets. However, LAN bridges are active while MAB are reactive, i.e. they provide the bridging service upon request of the IMA. Let IMA= be an interoperable mobile agent that wishes to migrate from a SOURCE MAS of the X type to a TARGET MAS of the Y type, where X Y; the migration schema is as follows: 1. IMA contacts a MAB (MABX Y), which provides the bridging from X to Y, by passing its HLP along with the identifier of the TARGET MAS.

After receiving the HLP, the MABX Y performs the following steps: 2. creates a new LLP specific to Y (LLPTARGET) 3. adapts HLP to LLPTARGET so obtaining the IMA*= 4. homogeneously migrates the IMA* to the TARGET MAS. Although the LLP is substituted, the HLP, which contains the activity of the mobile agent, is preserved so making the bridging process completely transparent. IAgentProxy

AgentDescriptor

Location +getHostName():String +getPort():String +getAgentServerName():String

-userName:String -type:String -name:String -ID:String -proxyURL:String -currentLocation:Location -previousLocation:Location -homeLocation:Location -proprietaryID:Object

+rebind(:InteroperableAgent):void +setForwarder(:String ):void +getForwarder():String +setForwardingOn():void +setForwardingOff():void +getMBX():Vector +sendMBX():void +getCurrentLocation():Location +send(:Event):void

+update(:Location)

IEventQueue

uses

dequeue():Event enqueue(:Event)

owns

bound

Thread

EventForwarder

InteroperableAgent 1

+InteroperableAgent(:AgentDescriptor) +setIAgent(:IAgent):void +onArrival():void +run():void uses +onDeparture():void Event -createProxy(:String):void -URLSender:String -lookUp(:String):Location -URLReceiver:String -send(:Event):void -tag:String -handleEvent(:Event):void -args:Object +dispatchEvent(:Event):void +getURLSender():String +getAgentInfo():AgentDescriptor +getCurrentLocation():Location +getURLReceiver():String

contains

dequeue(:int):Event {concurrent} enqueue(:Event) {concurrent}

*

+run():void

EventQueue

+getTag():String +getArgs():Object

* bound

activates 1 AgentProxy

-nextURL:String -prevURL:String -mailbox:IEventQueue -active:boolean

adaptedTo

IMAL

IAgent migrate(:Location):void create(:InteroperableAgent, :boolean):void lookup(:Object):String send(:Object, :Event):void

AjantaAgent

GrasshopperAgent