Mobile Active Objects for Highly Dynamic ... - Semantic Scholar

Mobile Active Objects for Highly Dynamic Distributed Computing Giancarlo Fortino1, Franco Frattolillo2, Wilma Russo1, Eugenio Zimeo2 1 DEIS – University of Calabria, 87030 Rende (CS), Italy 2 School of Engineering – University of Sannio, 82100 Benevento, Italy {g.fortino, w.russo}@unical.it, {frattolillo, zimeo}@unisannio.it Abstract The pervasiveness of Internet-based communication technologies is fostering new forms of distributed computing, namely, large-scale, highly decentralized computing and mobile computing. In this context, new application domains such as M-commerce, mobile multimedia, and cooperative information systems, demand for adaptive and flexible middlewares and frameworks which fully exploit logical mobility and support programmable coordination infrastructures. In this paper, we present a distributed computational model which extends an active object model by introducing the mobile active object concept in order to support a multi paradigm design approach. Mobile active objects are autonomous network-aware entities or mobile agents which coordinate to one another through on-demand installable interaction spaces featured by events. The model is embedded in ActiWare - our customizable Javabased framework for the development of highly dynamic distributed applications.

1: Introduction The widespread diffusion of computer networks and the exponential and ubiquitous growth of the Internet have aroused specific interests in network-centric programming and applications. As a consequence, new programming and design paradigms have been developed in order to support the construction of distributed applications. Most of the proposals integrate the wellestablished object-oriented technology into traditional design paradigms [7], such as client/server (C/S), remote evaluation (REV) and code on demand (COD). Moreover, distributed applications where the topology of their components is not assigned “a priori” and the interaction patterns are highly dynamic and mutable require new design paradigms fully exploiting code mobility and suitable coordination models. In particular, the mobile agents design paradigm [12] based on the concept of network-aware entities which fulfill their goaloriented task by computing and migrating among

different execution environments is gaining momentum and research focus. However, the real benefits of such a paradigm along with its supporting technology are not yet deeply understood and are being evaluated in several application domains [9]. We claim that, in order to cope with highly dynamic applications domains (e.g., M-Commerce, mobile multimedia, large-scale information retrieval systems), middlewares and frameworks supporting differentiated and integrated forms of logical mobility as well as multi coordination infrastructures are required. In addition, such middlewares should maintain both interoperability with existing “de facto” standard middlewares, such as CORBA and Java RMI, openness to new distributed multi-tier architectures (e.g., Java 2 Enterprise Ed.) and easy integration with legacy systems. In this paper, we propose the mobile active object model which allows for a multi paradigm approach to the construction of distributed applications. The model extends the Active Object one [3] by introducing mobile active objects (MAOs) which are mobile agent-like entities driven by events. A distinctive feature of a MAO is its dynamic behavior modeled using distilled statecharts which are a Statecharts-based visual formalism [10] we have purposely defined in order to support at high-level a programmable granularity of strong mobility. Such modeling makes it possible to exploit events as unifying model for system and interMAO coordination. The model is made available in a customizable and extensible Java-based framework – ActiWare – which currently extends the active object framework for wide-area distributed and parallel programming proposed in [3]. ActiWare seamlessly supports multiple local and remote interaction spaces based on different coordination models. In addition, it is designed according to an agentbased architecture complying with the FIPA (Foundation for Intelligent Physical Agents) specifications [5] so as to promote interoperability with FIPA-compliant mobile agent systems. The remainder of this paper is organized as follows. Section 2 presents the mobile active object model.

Section 3 shows a modeling example based on MAO concerning with a distributed information retrieval system. Section 4 describes a prototype definition of ActiWare and exemplifies some design paradigms. Finally conclusions and directions of future work are reported.

2: The mobile active object model The mobile active object model is a distributed, multi paradigm programming model. This model extends the Active Object one [3] by introducing strong mobility features in order to easily support the mobile agents paradigm and by exploiting an event-based model enabling multi coordination.

2.1: The Active Object model The Active Object model relies on three main concepts: Threads, Global Objects (GO) and Active Objects (AO). Threads are the computation active entities. GOs are objects globally accessible in a distributed computing environment and allow threads, dislocated on remote hosts, to communicate and synchronize. AOs are mobile objects (single-hop or multi-hop) each equipped with a handler which is automatically invoked when the AO arrives at destination node. They enable threads to interact with each other. In fact, threads are not given an identity; so, they can interact only by accessing GOs. Both AOs and GOs are hosted by Active Servers (ASs), which can be considered as abstract places providing all services needed to implement the execution environment required by the computation entities. On each AS, the interaction between incoming AOs and local GOs is enabled by a Global Name Space (GNS), which is a distributed collection of Local Name Spaces (LNSs), each one allocated on an AS. In order to access a GO, a thread asynchronously sends an AO to the AS hosting the GO implementation. The AO is provided with the GO’s name (GN), a globally unique name that represents the key value to query the LNS for the retrieval of the corresponding GO implementation.

2.2: The mobile active objects A mobile active object (MAO) is an addressable executing unit which can autonomously migrate within a logical network of ASs to fulfill a goal-oriented task. It is both reactive and proactive, i.e., MAOs don’t simply act in response to their environment, but they are able to exhibit goal-directed behavior by taking the initiative

[22]. The goal-oriented behavior of a MAO is achieved through an activity which includes elaboration, interaction and migration phases. In particular, migration is transparent and can be induced by the system, by other MAOs or by the MAO itself. A MAO is basically characterized by an identity, a dynamic behavior, and interaction mechanisms. MAOs are identified by globally unique, not changeable names established at the MAO’s creation. To locate a MAO, a location service is used. Such a service can be based either on local proxies (or forwarders) [17], which encapsulate the current locations of remote MAOs, or on global names [13], which are supported by a name server mapping a symbolic name to the current location of the named MAO. In the following subsections the adopted solutions for the modeling of the MAO’s behavior and the interaction model are presented. 2.2.1: Behavior modeling to support mobility. In order to support the strong mobility, the MAO’s execution environment is to be captured. Two different approaches can be exploited: (i) capturing the execution environment at low-level, such as at the level of the run-time support; (ii) capturing the execution environment at high-level, i.e., at programming level. In the latter, modifications to the runtime support are not required, so that portability of the application software can be guaranteed. In particular, the MAO’s mobility supported by our model adheres to a coarse-grained strong mobility whose granularity is under control of the MAO’s programmer. Programming the execution state capturing granularity at high-level may be simplified by using a modeling tool of the MAO’s behavior which allows the conditions (or states) enabling migration to be easily identified. To this purpose, our modeling approach relies on Statecharts [10], which are a visual formalism currently used in UML [21] for modeling complex systems. The behavior is thus modeled as a set of consistent states and transitions, and is driven by events. Statecharts extends the flat finite state machines (FSM) by introducing new characteristics encompassing: • OR-decomposition of states in hierarchies of states. From time to time a MAO can find itself into one of a set of disjoint states. However, state hierarchy implies that at a given instant in time a MAO resides in a (sub) state and all of its enclosing (super) states up to the top state. • inter-level state transitions that can originate from or lead to nested states on any level of the hierarchy; • default and history entrances. The history entrance, depicted by the H connector, captures an additional way to enter a group of states. The meaning is to

enter the most recently visited substate of this group. The H connector indicates that when the enclosing superstate is exited and reentered, the last active substate will be entered. The default entry within a state S indicates the state to be entered in the absence of history when S is visited. • “run-to-completion” semantics for the execution model of the action-expression labeling the transition. The corresponding actions must be executed entirely before any other actions are considered. In particular, to assure state consistency with respect to migration, the “distilled statecharts” are introduced. They comply with the following semantics: when a transition T from a state Sold to a state Snew is fired, the “action chain” represented by the Sold exit action, the action-expression hooked to T, Snew entry action and Snew activity is considered to be atomically executed. In order to obtain this, the action chain is attached to the transition T so making the states empty, i.e., with no activity, entry and exit actions. In addition, distilled statecharts requires that transitions are always labeled by an event. This semantics implies that a MAO is ready to receive and elaborate the next event only when it is fully stabilized, i.e., at the termination of the execution of the action chain associated to the fired transition.

WAITING

rests till its migration is completed. The other states and their related transitions should be self-explanatory. The ACTIVE state must be re-entered using the deep history entrance in order to guarantee that the substate in which the MAO is restored is the last visited before migrating, no matter which components (MAO or AS) generated the Move event. The distilled statecharts semantics (particularly the property to have only empty states) ensures that a MAO’s execution environment is reactivated exactly in the same conditions it was before the migration. Thus, the MAO's migration is transparent and can occur in any substate of the ACTIVE state. In order to increase the MAO’s reactivity, the programmer should split heavy action chains associated to given transitions and map them onto more transitions by introducing additional states and triggering events. 2.2.2: The event-based interaction model. The proposed model relies on events, first-class objects formalizing both intra-MAO and inter-MAO interactions, and MAO-AS service requests. In particular, a MAO directly interacts only with itself and the AS hosting it by generating and receiving events. Events incorporate information for their handling, which allows to identify when the event can be processed and what actions should be performed by the event handler (or final handler) in response to the event delivery.

SUSPENDED

Wake_UP

Event

Suspend

Wait

Internal

Resume

ACTIVE

External

H*

Management

Move

Execute

Invoke

TRANSIT

INITIATED

Destroy

Coordination

Create

Quit

Create

Move

Clone

Direct

AsynchMsg

Tuple

PublishSubscribe

SynchMsg

Figure 1. Basic MAO’s template.

Figure 2. The event class hierarchy diagram.

In figure 1 the distilled statechart regarding the basic template (or lifecycle) which any MAO complies with is shown. The ACTIVE macrostate models the MAO’s active behavior. The Move event brings a MAO from the ACTIVE to the TRANSIT state whereas the Execute event turns the MAO back to the ACTIVE state. The TRANSIT state is a transitory state in which the MAO

An event can be either synchronous or asynchronous with respect to the time to process it. The synchronous events should be processed by preserving the mutual order of their generation, whereas the asynchronous ones can be processed at any time. Depending on the actions to be performed events can be classified as:

• Internal, which are generated by the MAO and have the MAO itself as final handler, i.e., they enable intra-MAO interactions. • External, which are generated by the MAO and have an AS component as final handler, i.e., they enable MAO-system and inter-MAO interactions. They can be specialized on the basis of the specific services provided by the AS in: o Management, by which requests for MAO management services can be issued, such as creation (local and remote), migration, cloning of MAOs, and discovery of MAOs supporting specific services; o Coordination, which are tied to an abstract coordination model and further specializable in order to support specific, well-known coordination models as well as new user-defined ones. An internal event is always synchronous whereas an external event is synchronous only if its handling actions operate on the MAO that generated it. For example, Move and Clone are synchronous events when they ask the AS for moving or cloning their generating MAO. This event classification can be further extended starting from the hierarchy sketched in figure 2 to make it available new services. 2.2.3: Events handling. Each MAO is provided with: (i) an internal state (S) which the MAO response to the events depends on; (ii) an event queue (MEQ), which contains all the events delivered at the MAO; (iii) a proxy entity (MP) which cyclically extracts and processes an event from the MEQ; (iv) a primitive for generating events (generate(Event)). An internal event is directly delivered to its generating MAO by inserting it in the tied MEQ. An external event is first delivered to the AS’s toplevel handler (TLH) which then routes it toward the final handler. To this end, an AS is organized as a collection of loosely-coupled components interacting by means of publish/subscribe channels on which events can be routed in order to reach their final handler. Such architectural design induces a strong uncoupling between a MAO and the services provided by the hosting AS so as to allow the AS’s services to be easily extended or modified. In order to support both concurrency and scalability inside an AS, event handlers are organized according to a hierarchical topology mirroring that one of the event hierarchy. Thus, at each level of the hierarchy, a handler dispatches the incoming events to one of the lower-level handlers on the basis of their inheritance-based type. In particular, the Management events are dispatched to the handler of the MAO Management System (MMS) component, which additionally provides naming and

location discovery services. The Coordination events are dispatched to the handler of the Coordination Context (CXT) component which can support multiple coordination models such as Direct [15] (e.g., asynchronous messaging, session-oriented, etc.), Blackboard [4], Meeting [1], Tuple spaces [2] (e.g., reactive tuples) and Publish/Subscribe [20] The CXT embeds specific event handlers, called Local Interaction Spaces (LISs), which a MAO can refer to in order to interact with other MAOs. Each LIS is an ondemand installable component, hierarchical arranged inside the handler organization, which provides facilities to implement a specific coordination model. This way, a MAO can communicate and synchronize by exploiting different coordination infrastructures (i.e., LISs). In addition, remote and homogeneous LISs can be linked with each other so as to enable global interaction spaces (GISs). In particular, when the interaction between two MAOs is based on events, an event generated by a MAO is directly propagated through the event-based LIS of the AS hosting the sending MAO to the event-based LIS of the AS hosting the target MAO, discovered by using the event notification service. Thus, a variety of differentiated and programmable coordination policies are possible, which enable inter-agent interactions spanning from global and coupled to local and uncoupled patterns. It is worth noting that a MAO can really exploit a given coordination model if and only if the system allows for it within its coordination context, that is, if the specific LIS is installed within the CXT.

3: Modeling a distributed application using mobile active objects In order to exemplify the use of MAOs and events a modeling example concerning with a distributed information retrieval system has been implemented [8]. Several Database Management Systems (DBMSs) are distributed over a set of Active Servers and identified by the pair . Each DBMS manages a table with the fields keyword (an identifier of an entity) and data, i.e., some kind of information related to the entity denoted by the keyword or the identifier of another DBMS that may contain additional information about the corresponding keyword. The Search Engine is composed of two kinds of MAO: • Mobile Searcher (MOS) that roams through the locations of the DBMSs in order to collect information about a given keyword. • Manager (MAN) that creates a set of MOSs and assigns to them initially and upon successive

requests generated from the MOSs themselves disjoint lists of DBMSs to be visited. In figure 3, the distilled statechart concerning the active behavior of a MOS is depicted. The Search Engine’s task is described as follows. While the DBMS to be visited list (tbvl) assigned to each MOS is not empty, the MOS extracts the first DB identification pair (DBCoordinate id_pair) and uses the ID_AS (id_pair.getAS()) to migrate. Once the MOS arrives at the destination AS, it searches (driven by the DBSearch event) in the DBMS. When its tbvl is emptied, the MOS asks the MAN for a new list by issuing the RequestForCommand event. If the list (carried by the NewList event) is provided by the MAN, the MOS keeps searching according to the new list, otherwise the MAN can enforce (by generating the TurnBack event) the MOS to return back to the MAN’s AS (which can also be different from the AS on which the MAN created the MOSs) for data collection.

H*

/A1

WAIT_FOR_SEARCH DBSearch / A2 NewList / A3; A1 SEARCHED TurnBack / A4 DBSearch / A2

Collect / A5

A1:

A2:

A3: A4: A5:

DATA_PROVISION

id_pair = (DBCoordinate)tbvl.nextElement(); generate(new Move(this, id_pair.getAS())); generate(new DBSearch()); connectToDB(id_pair.getDB()); Object data = queryDB(keyword); if (data instanceof Data) info.add(data); else if (!tbvl.present(data)) generate(new DBAddress(data, ID_MAN)); if (tbvl.empty()) generate(new RequestForCommand(ID_MAN)); else A1; tbvl.add((NewList)e.getList()); generate(new Move(this, (TurnBack)e.getAS()); generate(new Collect()); generate(new DataReply(info, ID_MAN));

Figure 3. Active behavior of a MOS. Searching in a DBMS can either enrich the information content related to the entity to be searched, or result in the communication (by the DBAddress event) of a DBMS location to the MAN, in case the data field contains a reference to another DBMS which is not already present among them available to the MOS. As soon as the MAN aggregates a new list of DBMS to be searched, it sends such list to a “waiting for searching” MOS which issued a list request. Finally, when all the

MOS have completed their task, the MAN calls them back to the home AS. It’s worth noting that the variable e (of type Event at compile-time) refers the event which triggered the fired transition. Besides, the events DBSearch and Collect are internal, whereas the events RequestForCommand, NewList and TurnBack are of type AsynchMsg.

4: ActiWare: a multi paradigm Java-based framework The mobile active object model has been integrated in ActiWare, a multi paradigm framework. ActiWare is currently built on top of a messageoriented, Java-based middleware, called Moka [3], which implements the basic active object model presented in §2.1. ActiWare inherits from Java the peculiar, mobilityoriented features of the underlying Java Virtual Machine, i.e., dynamic class loading, code verification and security, multithreading and interoperability. In addition, ActiWare borrows from Moka: (i) code transfer from the network through a class on-demand loading scheme promoted by servers; (ii) communication and synchronization mechanisms; (iii) a multi-protocol transport support. In particular, communications rely on asynchronous and deferred synchronous messaging based on the exchange of Active Objects, whereas the synchronization can be guaranteed by Global Objects and the built-in synchronization mechanisms provided by Java. At low-level, communications are enabled by a multi-protocol transport layer able to exchange AOs on networks supporting both de facto standard protocols, such as TCP and UDP, and high performance ones, such as FM (Fast Messages) [16], thanks to a unified communication interface whose semantics is based on the one-sided communication model. ActiWare also provides the MAO programming abstraction and its related components, described in § 2, necessary to support the mobile agent paradigm (Figure 4). In particular, these components are designed according to the FIPA specifications [5] in order to promote interoperability with FIPA-compliant mobile agent systems. MAOs can thus migrate across Agent Platforms (APs). The AP is the sandbox which provides a protected agent execution environment along with migration, coordination and host resource access services. The AP consists of the machine, operating system, MAO support software, FIPA MAO management components (MAO Management System – MMS, Message Transport System – MTS, MAO

Communication Channel – MCC, and (possibly) Directory Facilitator - DF), and agents (MAO). The MAO support software encompasses a JVM and an Active Server (AS) based on the Moka features. The MMS embeds the functionality to support the MAO naming and location service. The solution currently adopted is based on location-transparent names and uses local proxies for remote MAOs, which encapsulate their current location [11]. The MMS can rely on a federation of MMSs distributed over the network to accomplish remote management tasks (e.g. remote creation). The MCC allows to exchange messages among MAOs under the form of AOs. The FIPA compliant components along with the CXT are implemented as GOs and installed by using AOs at configuration time. All the other components can be dynamically installed when necessary, by using the ondemand loading scheme. Legenda:

H Active Object

Mobile Active Object

Global Object

Local Name Space

GO Reference

Code

Handler

Active Server - AS MAO

CXT P/S

Direct

H

H

MMS

WP

S

MAO_ID

MP

event MEQ

Tuple H

H

event H

Naming service

TLH MCC

AO

LNS

GO_impl GO_id

+

MAO MTS

Dynamic Class Loader JVM O.S.

Figure 4: The basic architecture of ActiWare. Thanks to the integration of GOs, AOs, Events and MAOs, ActiWare enables a multi paradigm design approach to the development of highly dynamic distributed applications. Therefore, in addition to the agent paradigm illustrated in the previous section, ActiWare supports other distributed programming

paradigms (i.e., C/S, REV and COD), which are discussed and exemplified in the following subsections.

4.1: RMI paradigm The integration of the dynamic code loading and the active object model allows to easily implement both C/S and REV paradigms, under the form of extended RMI interactions. In particular, remote services are provided by GOs, while remote method invocations and code transfer are performed by using specific AOs. Differently from Java-RMI [19], which provides a centralized directory service based on the RMIregistry, ActiWare supports a distributed directory service, characterized by a collection of local registries (LNSs introduced in §2.1) each one allocated on an AS. Each registry stores only the GOs physically allocated on the AS hosting the registry, while the mapping GO-AS is statically stored in the GNs associated to GOs. GNs can be distributed among ASs in order to enable the sharing of the referred GOs. Therefore, the invocation of a GO method can be performed by sending an AO, which stores in its state the GN of the interested GO, to the AS hosting the GO implementation, whose reference is retrieved from the GN. In particular, at the destination the handler of the AO uses the GN to look up the GO implementation on which the method to be invoked is called. import actiware.*; import java.lang.reflect.*; class InvokeMethod implements ActiveObject { private GlobalUid gid; private String meth; private Object[] params; public InvokeMethod(GlobalUid g, String m, Object pm) { gid = g; meth = m; params = new Object[] { pm }; } public void handler(LocalNameSpace lns) { Object obj = lns.lookup(gid); Class[] paramTypes = new Class[params.length]; for(int i = 0; i < params.length; i++) paramTypes[i] = params[i].getClass(); try { Method m = obj.getClass().getDeclaredMethod(meth, paramTypes); m.invoke(obj, params); } catch (NoSuchMethodException e) { … } catch (IllegalAccessException e) { … } catch (InvocationTargetException e) { … } } } … ActiWare.request(new InvokeMethod( guid, "add", new Integer(3)), guid.node());

Figure 5: RMI-based interaction with ActiWare. The code in fig. 5 shows: (i) the implementation of the class InvokeMethod (obtained using the reflective

features offered by Java), whose instances are AOs used to invoke methods on GOs; (ii) the sending of an instance of InvokeMethod to remotely add the constant 3 to the state of the GO referred by guid.

4.2: REV paradigm The REV paradigm can be used to remotely process data, which can be stored either in a GO or in an external database, by sending the necessary code to the AS hosting the data to be processed. This scheme reduces the number of distributed interactions necessary to obtain a result from raw, remote data. So, REV can be seen as an extension of RPC and RMI, which adds flexibility and reduces communications for some classes of applications. To implement the REV paradigm in ActiWare, the code which is to be remotely executed is inserted into the handler of an AO. In particular, if the remote processing has to produce a result, the AO must be an instance of a class implementing the ActiveObjectCall interface provided by the ActiWare library, which makes it available a method handler with a return value. An instance of ActiveObjectCall is sent by using the primitive ActiWare.call(), which asynchronously transmits the active object and immediately returns a reference to an object of the class Promise. This object represents a place holder (future variable) for the return value of the active object: the caller activity can proceed concurrently with the called activity until the method Promise.getValue() is invoked. At this point, if the place holder does not contain data, the caller is suspended waiting the expected data, otherwise the caller receives the returned data and continues its execution. In the following, we show an example of the REV paradigm application to remotely calculate the power of a square matrix stored in an abstract data type (implemented as a GO) providing only simple operations, such as addition, subtraction and multiplication of matrices. The power is calculated by successive squaring whereas the code necessary to process the matrix is inserted in a private method of an AO, as reported in the figure 6. Such a solution performs the operation by sending only two messages (the request and the resulted matrix) instead of a varying number of messages depending on the value of the exponent, such as in case of RMI. An analogous scheme can be used to perform related operations on different remote objects located on the same node in order to reduce bandwidth consumption and improve efficiency because of the limited number of RTTs necessary to complete the operations.

import actiware.*; class REV_CalculatePower implements ActiveObjectCall { private GlobalUid mat; private int exp; public REV_CalculatePower(GlobalUid g, int e) { mat = g; exp = e; } public Object handler(LocalNameSpace lns) { Matrix m = (Matrix)lns.lookUp(mat); return power(m, exp); } private Matrix power(Matrix m, int e) { // calculates m**e by successive squaring Matrix square = m; Matrix res; while (p > 0) { if (p % 2 == 1) res = square.multiply(res); square = square.multiply(square); p /= 2; } return res; } } … Promise p = ActiWare.call(new REV_CalculatePower(mat, 8), mat.node()); … Matrix pm = (Matrix)p.getValue();

Figure 6: REV-based interaction with ActiWare.

4.3: COD paradigm To enable the adoption of COD paradigm, ActiWare is provided with a specific class loader, which is used by the system to retrieve (pull model) from the network (of ASs) the code of the system or application components not installed during the configuration phase. For example, when during a computation a MAO generates a coordination event requiring an uninstalled interaction scheme, the related LIS component will be loaded from the network and installed in the CXT component so as that the generated event can be correctly handled. To this purpose, the CXT must be implemented by exploiting the COD paradigm to allow the services provided by an active server to be extended at run-time.

5: Conclusions Highly dynamic distributed computing can greatly benefit from the exploitation of mobility-oriented application design paradigms and multiple, (possibly) programmable coordination models. This paper has presented and exemplified the mobile active object model, a distributed multi paradigm programming model. The model is an extension of the Active Object model which makes it also available the concept of mobile active object (MAO). A MAO is an autonomous entity which acts within a network of active servers by performing computations and interacting

according to a unifying event model which also enables multi coordination. The proposed model has been integrated in ActiWare a Java-based framework which enables the development of highly dynamic distributed applications in heterogeneous environments. This work doesn’t aim at developing another mobile agent system, such as the myriad already available on the research and commercial horizon [12, 14, 9] but it claims to deliver a customizable framework that, by supporting several distributed application design paradigms, can facilitate the construction of new applications in the context of a scenario where computing is increasingly decentralized, decoupled, and dynamically reconfigurable. On-going work aims at: (i) completing ActiWare by integrating multiple LISs using differentiated coordination models. (ii) evaluating the performances of the ActiWare framework. (iii) supporting MAO’s programming by a graphical tool [6] which allows the programmer to sketch the MAO’s statechart diagram, define events and insert code. After the modeling phase, the obtained graphical specification can be automatically transformed into code according to simple generation rules. (iv) exploiting µCode [18], a light-weight, flexible, and Java-based mobile code toolkit, to implement an adaptive and distributed class management system able to use the most efficient and reliable class loading model (Pull or Push) on the basis of system information.

6: References [1] J. Baumann, F. Hohl, N. Radouniklis, K. Rothermel, M. Strasser, “Communication concepts for Mobile Agent Systems,” Proc. of the 1st Int’l Workshop on Mobile Agents (MA’97), Berlin, Germany, LNCS 1219, pp. 123-135, April 1997. [2] G. Cabri, L. Leonardi and F. Zambonelli, “Mobile-Agent Coordination Models for Internet Applications,” IEEE Computer, 33(2), pp. 82-89, 2000. [3] M. Di Santo, F. Frattolillo, W. Russo, and E. Zimeo, “An Approach to Asynchronous Object-Oriented Parallel and Distributed Computing on Wide-Area Systems,” Proc. of the Int’l Workshop on Java for Parallel and Distributed Computing, Cancun, Mexico, May 2000. [4] P. Domel, A. Lingnau, and O. Drobnik, “Mobile Agent interaction in Heterogeneous Environment,” Proc. of the 1st Int’l Workshop on Mobile Agents (MA’97), Berlin, Germany, LNCS 1219, pp. 136-148, April 1997. [5] FIPA Agent Management Specification. Document number XC00023H. Aug. 2001. http://www.fipa.org.

[6] G. Fortino, L. Nigro, F. Pupo, and D. Spezzano, “Super Actors for Real Time,” Proc. of the 6th IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS’01), Rome, January 2001. [7] A. Fuggetta, G.P. Picco, and G. Vigna, “Understanding Code Mobility”, IEEE Trans. on Software Engineering, 24(5), pp. 342-361, 1998. [8] C. Ghezzi and G. Vigna, “Mobile Code Paradigms and Technologies: A Case Study,” Proc. of the 1st Int’l Workshop on Mobile Agents (MA’97), Berlin, Germany, LNCS 1219, pp. 39-49, April, 1997. [9] R. Gray, D. Kotz, G. Cybenko, and D. Rus, “Mobile Agents: Motivations and state of the art systems”, in Jeffrey Bradshaw, editor, Handbook of Agent Technology, AAAI/MIT Press, 2001, to appear. [10] D. Harel, “Statecharts: a visual formalism for complex systems,” Science of Computer Programming, 8, pp. 231-274, 1987. [11] Y.-B. Lin and W.-N. Tisai, “Location Tracking with Distributed HLRs and Pointer Forwarding,” IEEE Trans. on Veh. Techn., 47(1), pp. 58-64, 1998. [12] N. M. Karnik and A.R. Tripathi, “Design Issues in Mobile-Agent Programming Systems,” IEEE Concurrency, pp. 52-61, Jul-Sept. 1998. [13] N. Karnik and A. Tripathi, “Agent Server Architecture for the Ajanta Mobile-Agent System,” Proc. of the Int’l Conf. Parallel and Distributed Processing Techniques and Applications (PDPTA’98), CSREA Press, pp. 63-73, 1998. [14] J. Kiniry and D. Zimmerman, “A hands-On Look at Java Mobile Agents,” IEEE Internet Computing, 1(4), 1997. [15] D. B. Lange and M. Oshima, “Programming and Deploying Java Mobile Agents with Aglets,” Addison-Wesley, August 1998. [16] S. Pakin, V. Karamcheti, and A.A. Chien, “Fast Messages: Efficient, Portable Communication for Workstation Clusters and MPPs,” IEEE Concurrency, pp. 60-73, April-June, 1997. [17] E. Pitoura and G.Samaras, “Locating Objects in Mobile Computing,” IEEE Trans. on Knowledge and Data Engineering, 13(4), pp. 571-592, 2001. [18] G. P. Picco, “µCode: A light-weight and flexible mobile code toolkit,” Proc. of the 2nd Int’l Workshop on Mobile Agents (MA’98), Stutgart, Germany, LNCS 1477, pp. 160-171, Sept. 1998. [19] Java Remote Method Invocation, http:/java.sun.com/products/jdk/rmi/index.html. [20] Rosemblum and Wolf, “A Design Framework for Internet-Scale Event Observation and Notification,” Proc. of 6th ESEC / ACM SIGSOFT 5th FSE, Zurich, Switzerland, Sept. 1997. [21] OMG Unified Modeling Language Specification (N. formal/01-09-67), v. 1.4, Sep. 2001. [22] M. Wooldridge and N.R. Jennings, “Intelligent Agents: Theory and Practice,” Knowledge Engineering Review, 10(2), 1995.