Multi-coordination of Mobile Agents: a Model and a Component-based Architecture Giancarlo Fortino
Wilma Russo
DEIS – Università della Calabria Via P. Bucci cubo 41c 87036 Rende (CS) +39.0984.494063
DEIS – Università della Calabria Via P. Bucci cubo 41c 87036 Rende (CS) +39.0984.494691
[email protected]
[email protected]
ABSTRACT This paper proposes a model along with a reference software architecture enabling multi-coordination between distributed and mobile software agents. Multi-coordination allows agents to choose among a variety of different coordination spaces and patterns which best fit their dynamic communication and synchronization needs. It can be fruitfully exploited by agents in heterogeneous and dynamic environments like the Internet where the mutable conditions of communications and computing usually affect both the currently agreed workflow and the performances of agent-based applications. The proposed model centers on highlevel events which can be locally emitted and/or received by agents and which unify access to and exploitation of underlying coordination spaces and agent server resources. The model is supported by a component-based architecture which provides agent management and notably agent coordination through a coordination context dynamically assembled with a set of different local and/or global coordination spaces. A prototypical implementation of the architecture was also carried out using Java and the Voyager ORB middlewares.
Categories and Subject Descriptors D.3.3 [Programming Languages]: Language Constructs and Features; C.2.4 [Distributed Systems]: Distributed Applications.
General Terms: Design, Languages Keywords Coordination Model, Mobile Agents, Events, Component-based Architecture, Middleware.
1. INTRODUCTION It is widely recognized that nowadays the Internet is no longer used only as a simple communication infrastructure or queryable information repository but notably as a global distributed computing platform. In fact, communication, computation and information are strictly intertwined in several emerging Internet Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’05, March 13-17, 2005, Santa Fe, New Mexico, USA. Copyright 2005 ACM 1-58113-964-0/05/0003…$5.00.
application domains such as e-Commerce, content-based information retrieval, and Computer Supported Cooperative Work (CSCW). Although Internet morphology favors the rapid introduction and use of new applications and services, its intrinsic heterogeneity and dynamicity are important factors affecting design and efficiency of Internet applications. Currently emerging paradigms and technologies such as GRID and Agents can deal with such issues since they possess the potential to provide effective as well as efficient solutions. While the GRID’s focus is more on computing-intensive applications, the Agent paradigm and technology [16] is advocated to be more suitable for engineering Internet-based applications in the context of the aforementioned application domains. Agents featured by mobility (or simply mobile agents), as widely claimed [15, 20], allow for conservation of bandwidth, reduction of latency, protocol encapsulation, asynchronous and autonomous distributed execution, dynamic adaptation, seamless integration of heterogeneous system, robustness and fault tolerance. Mobility per se is a strategic feature in the Internet but mobile agents need to coordinate particularly in complex application scenarios. Thus coordination among mobile agents and between mobile agents and distributed resources is a main issue to be tackled for the development of efficient and robust Internet applications based on mobile agents. Several proposals have to date been done ranging from traditional coordination models and related infrastructures (e.g. Direct, Meeting-oriented, Blackboard, Tuple-based [4]) to more advanced and programmable ones such as MARS [4, 5], TucSon [17], Lime [19], and Jedi [8]. However, we believe that single-model-based coordination, even if programmable, might not be effective for satisfying all needs of Internet applications; thus we propose the exploitation of multicoordination which can facilitate application design, improve efficiency, and enable adaptability in dynamic and heterogeneous environments like the Internet. Multi-coordination allows agents to choose among a variety of different coordination spaces and patterns which best fit their dynamic communication and synchronization needs. The proposed multi-coordination model centers on high-level events which can be locally emitted and/or received by eventdriven agents and which unify access to and exploitation of underlying coordination spaces and agent server resources. An agent, that wishes to coordinate using a specific coordination model, generates a high-level event which formalizes an operation to be performed on the coordination media according to the specific model. Reception of incoming high-level events, which formalize asynchronous notifications sent by the agent itself, by
the agent server or by another agents, is asynchronous and implicit. The model is supported by a purposely defined component-based architecture, called ACTIWARE, which provides management of mobile agents and, notably, agent coordination through a coordination context which is dynamically assembled with a set of different local and/or global coordination spaces. Moreover, a prototype implementation of ACTIWARE was carried out using Java and the Voyager ORB. The remainder of this paper is structured as follows. Section 2 presents basic concepts of coordination models for mobile agents and introduces a reference example. In section 3, the proposed multi-coordination model is first detailed and, then, exemplified by scripting the reference example. Section 4 describes ACTIWARE and discusses its current implementation. Finally, conclusions are drawn and on-going research activities briefly reported.
2. COORDINATION AMONG MOBILE SOFTWARE AGENTS Generally speaking, coordination can be defined as the process of building programs by gluing together active pieces [6]. Coordination basically implies the definition of a coordination model and a related coordination architecture or a related coordination language. An agent coordination model is a conceptual framework which should cover the issues of creation and destruction of agents, communications among agents, and spatial distribution of agents, as well as synchronization and distribution of their actions over time. In particular, the coordinables are the coordinated entities (or agents) whose mutual interaction is ruled by the model, the coordination media are the abstractions enabling the interaction among the agents, and the coordination laws are the rules governing the interaction among agents through the coordination media as well as the behavior of the coordination media itself [3]. A coordination architecture is a software infrastructure supporting and implementing a coordination model. A coordination language is “the linguistic embodiment of a coordination model” [6], which should orthogonally combine two languages: one for coordination (inter-agents) and one for computation (intra-agent). While coordination among distributed, even mobile, objects in closed and stable environments has been widely explored and well-understood, coordination of mobile agents operating on the Internet, which is characterized by mutable communication paths, intermittency of hardware and software resources, and heterogeneity, is still an open and interesting issue. Several coordination models for mobile agents have been to date proposed. In [4], a taxonomy for Internet-based mobile agent coordination was introduced, which allows for the classification of coordination models on the basis of the degrees of spatial and temporal coupling induced by the coordination models. Spatial coupling requires that the entities to be coordinated share a common name space or, at least, know the identity of their interaction partners; conversely, spatial decoupling allows for anonymous interaction, i.e. there is no need for an acquaintance relationship. Temporal coupling implies synchronization of the interacting entities whereas temporal decoupling allows for asynchronous interactions. On the basis of this taxonomy the
following coordination models were classified: Direct, Meetingoriented, Blackboard-based and Linda-like. In Direct coordination models, agents usually coordinate using RPC-like primitives or asynchronous message passing. The former coordination method implies temporal and spatial decoupling whereas the latter implies only spatial coupling, temporal decoupling can be obtained using message reception queues. The majority of the Java-based mobile agent systems [20], particularly the most famous ones, namely Aglets, Voyager, Ajanta and Grasshoppers, relies on this model. In Meetingoriented models, agents coordinate using implicit or known meeting points which allow for partial spatial decoupling. In Blackboard-based models, agents coordinate via shared data spaces to store and retrieve information under the form of messages so providing temporal decoupling. In Linda-like models, agents coordinate through tuple spaces which allow for insertion of tuples and retrieval of tuples using associative patternmatching; this enables both spatial and temporal decoupling. Recently new coordination models which can be classified as spatially and temporally decoupled are emerging in the context of Internet applications: the reactive tuple space models which enable programmable coordination spaces [5, 17] and the Publish/Subscribe event-based models [8, 18, 7]. The reactive tuple space model extends the simple tuple space model by introducing computational capability inside the coordination media under the form of programmable reactions, triggered by operations on the tuple space or by other reactions, which can influence the behavior of agent interactions. This model also allows for the separation of concerns between agent computation and coordination issues. In the Publish/Subscribe event-based model, agents coordinate through asynchronous publication and notification of events so enabling temporal and spatial decoupling. In order to be notified by an event, an agent has to subscribe to an event type; as soon as an event of the subscribed event type occurs, the agent is notified. These two new models have been advocated as very suitable for Internet applications and, in our opinion, they really are. But what about the others? Are they really unnecessary? Are a single coordination model and related infrastructures, even if programmable, really enough to deal with the needs of any Internet application? Although any mobile agent-based application can be developed according to a single, even classical, coordination model as to date demonstrated by a lot of successful trials, we believe that an integrated exploitation of different coordination models, namely multi-coordination, can facilitate application design and improve efficiency. As a reference example of the advantages that multicoordination can bring, the following application scenario concerning with distributed information retrieval is proposed. A User Agent searches for specific information over remote networked (or federated) locations by creating and launching a task force of information Searcher Agents; as soon as a Searcher Agent finds the desired information, it stops all the others and finally reports the found information to its owner, i.e. the User Agent. The strategic choices which are enabled by multicoordination so facilitating application design are the following: (i) to avoid duplicate search of the same information by different agents on a given location, Searcher Agents locally
(iii) to report the found information to the User Agent, the Searcher Agent, instead of coming back home, sends an asynchronous message containing the found information to its owner. This is done to avoid the migration of the agent along with the found information, which would very likely take longer time. A sketched implementation of the reference example is reported in section 3.5.
3. A MULTI-COORDINATION MODEL The proposed Multi-Coordination Model (MCM) allows for the unification of the access to and of the exploitation of both currently available and to-be-defined coordination models so that agents can easily coordinate with each other using the most appropriate model among the available ones. Thus MCM incorporates all the features of the currently available coordination models and allows for the embodiment of coordination models which could be defined in the future. MCM can be defined by the triple: ; EA represents the Event-driven Agents (the coordinables), i.e. agents whose activity is driven by events; CM represents the Coordination Media which are virtually represented by high-level local events and concretely consist of the set of coordination media related to the exploited coordination models; CL are the Coordination Laws which consist of (i) the coordination laws of the exploited coordination models, (ii) the laws of the eventdriven agent model, and (iii) additional laws which can be dynamically programmed and imposed using meta-agents. A graphical representation of MCM is portrayed in Figure 1 in which different coordination media are represented by different shapes.
«CL»
CM1 «CLCM1»
EA2
the agent, Beh is the set of behaviors, DS is the data space, TC is the set of threads of control supporting execution, and EQ is the set of queues which contain incoming events. Each behavior is defined to react to a specific set of events. A reaction can produce either computations, which can affect the DS , and/or generation of one or more events, or a migration. A thread of control can support one or more behaviors so allowing for parallel and/or concurrent behaviors. While the reception of incoming events (or IN-events) is implicit and decoupled by the EQ , the transmission of events is explicitly carried out by means of the generate(()) primitive which allows to asynchronously raise outcoming events (or OUT-events). The execution semantics of an event-driven agent are defined by specifying the Event Processing Cycle (EPC): cyclically, when the next available event is fetched, it is passed to the behavior/s which can handle it so triggering one or more reactions. The policies of event fetching and event handling should be so carefully defined. For instance, in case of lightweight event-driven agents [10, 13] (i.e. agents with single behavior, thread of control and event queue), the execution semantics are as follows: as soon as the current reaction terminates, the next available event is dequeued from EQ and passed to Beh. Moreover, it is worth noting that the agents provided by the currently available mobile agent systems [20] can be easily transformed in lightweight event-driven agents as shown in [12] for the Ajanta, Voyager, Aglets, and Grasshopper systems. Another example of lightweight eventdriven agents with multiple behaviors are the JADE agents [2].
Table 1. Classes and Types of High-Level Events Class
CMn «CLCMn»
Figure 1. The Abstract View of MCM. In the following sections, after introducing the event-driven agent model, defining the high-level event classes along with their
INTERNAL Event Type
MANAGEMENT Event Type CREATE
EAm
HIGH-LEVEL EVENTS
CM2 «CLCM2»
A general event-driven agent can be represented by the tuple Id , Beh, DS , TC , EQ , where Id is the unique identifier of
IN-event
EA1
3.1 The Event-driven Agent Model
CLONE
To be programmed
(ii) to stop the Searcher Agents, a mobility-aware, Publish/Subscribe event-based service [8, 18] is used. This allows a Searcher Agent to emit a stop event as soon as it finds the desired information;
semantics, and providing an object-oriented design of the classified events, we discuss event handling and meta-agent-based customization of the agent behaviors and sketch an implementation of the reference example (see Sect. 2).
OUT-event
coordinate using a local tuple space [4]. Before searching for the information on a given location, the Searcher Agent tries retrieving from the tuple space the signaling tuple which could have been left by another Searcher Agent that has already visited the location. If the signaling tuple is not present, the Searcher Agent can search for the information; otherwise, it can either migrate to a new location or quit;
MOVE-REQUEST
agent lifecycle management
COORDINATION Model Event Type MSG-REQUEST DIRECT RPC-INVOKE RPC-RESULT TUPLE-BASED IN, OUT, RD SUBSCRIBE, P/S_EVENT-BASED UNSUBSCRIBE PUBLISH
CREATE-NOTIFY
MSG DIRECT
RPC-REQUEST, RPC-RETURN
MOVE
TUPLE-BASED
RETURN-TUPLE
agent lifecycle management
P/S_EVENT-BASED
EVT-NOTIFICATION
CLONE-NOTIFY
3.2 Event Classification and Semantics High-level OUT- and IN-events can formalize a request to or a notification from the hosting agent server (or management events), a coordination act (or coordination events), or a selftriggering event (internal events). Only an IN-event can trigger an agent reaction so driving the agent lifecycle. Table 1 reports an
event classification, which can be further extended to account for new management services and coordination models. In particular: (i) internal events can be defined at programming level for self-triggering active and/or proactive behavior. In the case of internal events, IN and OUT events coincide. In fact, an emitted internal event or OUT-event is received as IN-event by the emitting agent itself. (ii) management events include requests and notifications of services at agent server level such as agent lifecycle management, creation, cloning, and migration. In particular: - the agent lifecycle management events are the IN-events driving the agent lifecycle which can be only emitted by the agent server. In particular, they were defined according to the standard FIPA specifications for the agent lifecycle management [9]: INVOKE, SUSPEND, RESUME, WAKE_UP, WAIT, MOVE, EXECUTE, QUIT, DESTROY; - the creation of one or more agents of the same type is requested by the OUT-event CREATE, which embodies the type and the number of agents to be created, the agent server locations where to create the agents, and a possible creation notification request. The creation with notification request implies that the agent server, after accomplishing the creation request, notifies the requesting agent through the IN-event CREATE-NOTIFY which contains the identifiers of the created agents; - the cloning of an agent is requested by the OUT-event CLONE, which embodies the agent server location where to clone the agent and a possible creation notification request (see creation semantics); - the migration of an agent is requested by the OUT-event MOVE-REQUEST, which embodies the agent to be migrated and the agent server location where to migrate. The agent server actually promotes the agent migration by inserting the INevent MOVE into the target agent’s queue. (iii) coordination events enable coordination acts between agents according to a specific coordination model. The considered coordination models are the Direct, the Tuple-based, and the Publish/Subscribe event-based models. In particular:
- the Linda-like Tuple-based model is enabled by the OUTevents IN, OUT, and RD, and by the IN-event RETURN-TUPLE. IN, OUT, and RD formalize the corresponding Linda primitives: insertion, extraction and reading of a tuple, respectively. OUT and RD can be either synchronous or asynchronous whereas IN is asynchronous. RETURN-TUPLE embodies the tuple/s associated to a previously submitted OUT or RD event; - the Publish/Subscribe event-based model is supported by the OUT-events SUBSCRIBE, UNSUBSCRIBE, and PUBLISH, and by the IN-event EVT-NOTIFICATION. SUBSCRIBE and UNSUBSCRIBE respectively formalize subscription and unsubscription to given events, PUBLISH embodies a generated event, and EVTNOTIFICATION contains an event notification.
3.3 Object-oriented Design of Events According to the object oriented approach an event is a programming language specific object including a set of attributes and possibly a set of methods. Figure 2 shows the designed event class diagram; for the sake of brevity, methods as well as FIPAcompliant agent lifecycle management events are not reported. Event -source -target -out : bool
Internal
Management
Create Direct
P_S
-agentClass -nAgents -nLocations -notify : bool
Tuples
MoveRequest
RPCInvoke -idEntity -methodName -params
Publish MSGRequest
-eventName -data
In
RPCResult
Subscribe
-returnValue
-eventName MSG
Clone
-serviceDescr
RPCReturn -returnValue
Rd -tupleMatch -sync
-data +getData()
Unsubscribe -eventName
-destLocation
-tuple
-data
RPCRequest
- the Direct model is supported by the OUT-event MSG-REQUEST and the IN-event MSG for asynchronous message passing, and by the pairs of OUT/IN events (RPC-INVOKE, RPC-RESULT) and (RPC-REQUEST, RPC-RETURN) for synchronous, RPC-like interactions. MSG-REQUEST contains the actual message to be sent along with the agent target whereas MSG contains the message to be delivered to the target agent. RPC-INVOKE contains the information (identifier of the remote entity, name of the method to be invoked, and list of parameters) of the remote procedure call (or remote method invocation) to be invoked on a remote or local entity, whereas RPC-RETURN embodies the return value, if any, of the invoked method. RPC-REQUEST formalizes a synchronous request directed to a target agent and contains the description of the service to be accomplished by the receiving agent. When the receiving agent accomplishes the requested service, it replies using RPC-RESULT which contains the return value, if any;
Coordination
-cloneLocation -notify : bool
CreateNotify -agentIDs
Out -tupleMatch -sync
CloneNotify -agentID
EVTNotification -eventName -data
ReturnTuple -tuples
Move -destLocation
Figure 2. The Event Class Diagram. The discriminator of IN or OUT event is the boolean out attribute in the abstract root class (Event) which is introduced to make more efficient the identification of the IN and OUT events at runtime: if out is true the event is OUT, otherwise the event is IN. The meaning of the other attributes can be easily inferred by the previous section. It is worth noting that other techniques and approaches such as those XML-based can be used to define events.
3.4 Event Handling and Meta Customization Each event is sequentially handled by one or more event-specific handlers. This sequential event handling forms the Event Handler Chain (EHC). The initial handler of the EHC is called router, the last handler is called final handler, and the others are called middle handlers. The final handler of an IN-event is its receiving agent. Conversely, the final handler of an OUT-event is: (i) the agent generating it, if the OUT-event is of the internal class; (ii) the agent server, if the OUT-event is of the management class; (iii) the event-specific coordination media, if the OUT-event is of the coordination class. MCM naturally allows for meta customization; in fact, abstracting agent computation in terms of events decouples agent behavior from the handling of events. In particular agents need not be specifically aware of the manner in which events are handled provided that event processing semantics are preserved. This independence can be exploited for customizing agent behavior and transparently replacing system behavior with equivalent mechanisms for handling events. In particular, customization is operated by means of the so called Meta-Agents [1], i.e. agents capable of transparently filtering events generated or received by other agents. Transparent event filtering is obtained by statically or dynamically inserting meta-agents inside the EHC as middle handlers (or filters). For example, agent coordination through asynchronous message passing can be customized by installing a meta-agent capable of filtering the MSGREQUEST and MSG events. Once installed, a meta-agent assumes responsibility for intercepting and processing events of specific classes generated and/or received by the customized agent (or base-agent). As an example of how agents can be customized, consider the encryption of messages between two remote agents Agx and Agy. An encryption meta-agent (Encrypt) is installed on MSGREQUEST events generated by Agx whereas a decryption meta-agent (Decrypt) is installed on the MSG events received by Agy. Encrypt filters any MSGREQUEST event generated by Agx before reaching its final handler (i.e. the Direct coordination media), by encrypting the data object contained in the event. Decrypt filters any MSG event targeting Agy by decrypting the data object contained in the event.
3.5 Scripting the reference example Figure 3 reports the Java-like scripts of the behaviors of the User Agent and of the Searcher Agent referring to the reference example introduced in section 2. The User Agent reacts to two IN-events: INITIATE, which is received just after creation, and REPORT, which signals a report sent by a Searcher Agent. The reaction to INITIATE allows for the creation without notification of n Searcher Agents in n different starting locations, whereas the reaction to REPORT allows for the processing of the received information. The Searcher Agent reacts to the following events: - INITIATE: the agent first subscribes to the notification event for stopping the information search and, then, submits the information retrieval query to a servant agent wrapping the information source; -QUERYRESULT: the agent analyses the query result and, if the information has been found, publishes the stop search notification and sends the information to the User Agent;
otherwise the agent either moves to the next available location, if any, or quits by generating the QUITREQUEST event; the TEST event is generated by the agent itself to proactively restart activity on the next location (provided by the nextLocation() method); - TEST: the agent asynchronously submits a request to check if the tuple signaling that the location has been already visited by a sibling agent is present; - EVTNOTIFICATION: the agent quits since it has received the notification event for stopping the information search; - RETURNTUPLE: if the tuple check is negative, the agent leaves the signaling tuple and generates the internal SUBMITQUERY event to drive the query submission; otherwise, the agent, if an available location exists, requests a migration to the next available location and generates the internal TEST event driving its activity on the target location; otherwise, the agent quits; - SUBMITQUERY: the agent submits the query to the servant agent. With reference to the scripts, the self() method returns the invoking agent identifier whereas the evt variable refers to the received event instance. User Agent INITIATE: generate(new Create(self(), “SearcherAgent”, n_agents, locations, false);
REPORT:
Object information = ((Report)evt).getData();
process(information)
Searcher Agent INITIATE:
generate(new Subscribe(stopSearch)); generate(new Query(self(), servant, query)); QUERYRESULT: Object result = ((QueryResult)evt).getData(); if (analyze(result)==INFO_FOUND){ generate(new Publish(stopSearch)); generate(new Report(self(), owner, info)); } else { if (nextLocation()!=null) { generate(new MoveRequest(self(), nextLocation())); generate(new Test(self())); } else generate(new QuitRequest(self())); } TEST: generate(new Rd(matchingTuple, false));
EVTNOTIFICATION:
generate(new QuitRequest(self()));
RETURNTUPLE:
if ((ReturnTuple(evt)).getTuple()==null) { generate(new In(signalingTuple)); generate(new SubmitQuery(self())); } else if (nextLocation()!=null) { generate(new MoveRequest(self(), nextLocation())); generate(new Test(self())); } else generate(new QuitRequest(self())); SUBMITQUERY: generate(new Query(self(), servant, query));
Figure 3. The Scripts of the behaviors of the Event-driven Agents for distributed information retrieval.
4. ACTIWARE: A COMPONENT-BASED ARCHITECTURE SUPPORTING MULTICOORDINATION The ACTIWARE’s architecture is designed according to the FIPA specifications [9] in order to promote interoperability with FIPAcompliant mobile agent systems. The component-based architecture of ACTIWARE is reported in Figure 4 which discloses the following main components: (i) the Mobile Agent (MA), which represents a lightweight event-driven mobile agent. It is equipped with: (i) a composite object (Beh) which represents the mobile agent behavior; (ii) the event queue (EQ), which contains all the received IN-events to be handled by MA; (iii) a thread (TC) which cyclically extracts an event from EQ and passes it to Beh. the Mobile Agent Management System (MMS), which (ii) registers event-driven mobile agents using a White Pages (WP) service, handles the management events (see Sect. 3.2), and also incorporates agent naming and location discovery services based on programmable proxies (PX) [12]; (iii) the Coordination conteXT (CXT), which embeds specific final handlers, called Coordination Spaces (CS), which MAs can transparently exploit by the generation of high-level events (see Sect. 3). A CS is an on-demand installable component, hierarchical arranged inside the handler organization, which implements a specific (local or global) interaction or coordination model. In particular, each CS component is able to: (a) interpret and translate received OUT-events into specific operations on the coordination media (e.g. a MSGREQUEST event into the actual message transmission); (b) translate incoming coordination media-specific objects into IN-events to be dispatched to the target MAs (e.g. an actual tuple reading into the RETURNTUPLE event); (iv) the Event Handler System (EHS), which routes events to their final handlers. OUT-events are routed to their final handlers (MA, MMS or CXT components) according to the event type. IN-events are routed into the EQ of their respective recipient agents. EHS is composed by event channels connected by the following basic handlers: a Top Level Handler (TLH) and a set of intermediate handlers (Hs). TC
ID#X
MAs EQ
BEH
EVENT-IN
Proxy Ref
EVENT-OUT
MA ID
DIRECT
MMS
ID#1
CXT
EHS H TUPLES H
P/S
PX
ID#2
H H
TLH
H
WP
NAMING LOCATION DISCOVERY
PORTING INTERFACE
MESSAGING
PROXY
NAMESPACE
MOBILITY
FACTORY
VOYAGER ORB SYSTEM
Figure 4. The Voyager-featured architecture of ActiWare.
4.1 Java and Voyager-based implementation ACTIWARE is currently prototyped atop the Voyager ORB system; a former version, which only included a Direct coordination space, was reported in [10]. A porting interface (Fig. 4) clearly separates the ACTIWARE’s basic components, which are Voyagerindependent, from those realized using the Voyager API. Such separation allows for an easy mapping onto other Java-based mobile agent systems (e.g., Ajanta, Grasshoppers, Aglets) [12, 20]. The Voyager ORB [21] is a Java distributed computing platform that can be used to quickly produce high-impact systems since embodies a great number of innovative features with respect to other ORBs and mobile agent systems. It allows exploiting regular message syntax to construct remote objects and send them messages. More importantly, Voyager enables objects to be moved among networked programs. Voyager-enabled programs are supported by the Voyager server, which is located by means of a URL (typically a pair ). It basically supports objects with naming and location discovery services, provides communications facility to send and receive messages and additionally integrates a Web server for remote class loading on demand. In order to keep minimal the dependencies from Voyager, in the ACTIWARE prototyping phase we only exploited the following basic, yet powerful, Voyager’s features: - Remote-enabling of classes. Java classes do not need to be modified in any way in order to remote enable them. In fact, they are remote-enabled at run-time and no additional files are created. In particular, remote objects are created using Factory, are accessible through virtual object proxies (Proxy), and can be bound to Namespace by means of URLs so as to be globally and easily looked-up; - Mobility. Any serializable object can be moved between programs at run-time. The mobility model implemented by Voyager is of the weak-mobility type [20]. In order to manually save and restore execution state, a mobile object can be notified during a migration phase by means of the preDeparture, preArrival, postArrival, and postDeparture callbacks; - Advanced Messaging. Voyager provides synchronous remote method calls, asynchronous one-way message passing, and future messages. Figure 4 highlights the dependencies, appositely filtered by the porting interface, between the ACTIWARE’s basic components (MA, CXT, MMS, and TLH) and the Voyager’s functional blocks (Messaging, Factory, Proxy, Namespace, Mobility). The EQ and Beh components of an MA are completely Voyagerindependent; they are pure Java-based serializable objects. In particular, Beh is constructed using the Java-based Mobile Active Object Framework [13] which allows to implement this component as a hierarchical state machine called Distilled StateChart. TC is a Voyager remote-enabled object which transports EQ and Beh as cargo and can be moved by the MMS from one Voyager server to another using Mobility.
The MMS, CXT and TLH components are also remote-enabled objects bounded to Namespace by means of the locators /mms, /cxt, /tlh, respectively. The MMS exploits Factory to locally and remotely create and clone MAs. Registration and deregistration of MAs are supported by the whitepages (WP) object. Naming and location discovery of MAs are currently based on proxies (PX) and implemented in a Voyager-independent manner. A PX is a triple , where MAOId is an object representing an MA identifier, ASUrl is an object encapsulating the Voyager server locator where the agent has migrated, and MBX is a mailbox object buffering incoming events during the migration transitory of the MA. In particular, if an incoming event targeting a specific MA on a given location cannot be delivered since the target MA is currently on another location due to a previous migration, the event is temporarily stored in the MBX if and only if the event has a global scope; otherwise, it is discarded. Stored events can be retrieved according to different forwarding policies (synchronous retrieval, asynchronous retrieval, and active forwarding) as reported in [12]. The CS components (Direct, Tuples and P/S) are themselves remote-enabled composite objects which can be downloaded ondemand from a Voyager-enabled code repository or uploaded by a manager application. The local/global Direct coordination space uses Messaging to transmit asynchronous and synchronous messages using the OneWay.invoke and the Sync.invoke methods, respectively. Remote messages are exchanged among remote Direct components which, upon reception, translate them into the corresponding IN-events and route them up to target MAs. The global P/S event-based coordination space is based on the Voyager's publish/subscribe mechanism. In particular, the global coordination space is implemented as an interconnection of Voyager’s Subspaces (built using the connect primitive of Subspace) located on different Voyager servers. Publication of events is based on the Publish.invoke method, which allows for the insertion of an event of a given Topic into the global space. The event subscription is based on the subscribe method of Subspace whereas a possible event notification is based on the asynchronous callback of the publishedEvent method on the event listener component of the coordination space which implements the PublishedEventListener interface. The local Tuples coordination space is based on JavaSpace [14]. In particular, each Tuples coordination space component, as soon as it is initiated, creates a Java space object implementing the JavaSpace interface and binds it to a JavaSpace server, potentially enabling a global tuple space. Any basic rd, out, and in operations are performed by a coordination space component on this object through the methods read, take and write, respectively.
5. CONCLUSIONS This paper has proposed a model based on high-level events for the multi-coordination of distributed and mobile software agents. The model is specifically suitable for Internet applications since it allows agents to choose among a variety of coordination spaces to cope with the dynamicity and heterogeneity of the Internet
environment. This claim has also been corroborated by a distributed information retrieval example highlighting that multicoordination can allow for cleaner application design and performance improvements. The use of high-level events for an integrated and homogeneous access to multiple and different coordination spaces also allows for easy extendibility (i.e. introduction of new coordination spaces) with respect to the use of traditional API-based approaches in which the introduction of a new operation implies changing the API itself. Moreover it has been described ACTIWARE, a component-based software architecture purposely defined for supporting the multicoordination model, which provides a software infrastructure for actually experimenting with multi-coordination. Currently ACTIWARE is implemented using Java and the Voyager ORB and provides three different types of local and global coordination spaces: Direct, Tuple-based and Publish/Subscribe event-based. On-going research efforts are being devoted to: - experimenting and evaluating multi-coordination in emerging Internet application domains with respect to single model-based coordination; the evaluation is being conducted both by developing and evaluating real applications and by simulating application scenarios using the methodology reported in [11]; - developing and integrating in ACTIWARE other coordination space components based on Lime, MARS, and Siena; - defining and implementing a meta-level architecture for static and dynamic meta-customization. As a final remark, it is worth highlighting that, although the achievement of high flexibility often brings performance penalties, the exploitation of multi-coordination as proposed in this paper has the potential to boost distributed application performances while keeping bounded possible overheads induced by the local event handling. This conjecture is supported by results reported in [12], which presents the performance evaluation of a similar high-level, event-based agent framework built atop currently available mobile agent systems.
6. REFERENCES [1] Astley, M., and Agha, G.A., Customization and composition of distributed objects: middleware abstractions for policy management. In Proceedings of the 6th Int’l Symp. on the Foundations of Software Engineering (FSE-6, SIGSOFT’98), (Orlando, FL, USA, Nov, 1998). [2] Bellifemine, F., Poggi, A., and Rimassa, G., Developing multi-agent systems with a FIPA-compliant agent framework. Software - Practice And Experience, 31, (2001), 103-128. [3] Ciancarini, P., Coordination models and languages as software integrators. ACM Computing Surveys, 28, 2 (Jun. 1996), 300-302. [4] Cabri, G., Leonardi, L., and Zambonelli, F., Mobile-agent coordination models for internet applications. IEEE Computer, 33, 2 (2000), 82-89. [5] Cabri, G., Leonardi, L., and Zambonelli, F., Engineering Mobile Agent Applications via Context-dependent
Coordination. IEEE Transactions on Software Engineering, 28, 11 (Nov. 2002), 1040-1056. [6] Carriero, N., and Gelernter, D., Coordination languages and their significance. Communications of ACM, 35, 2 (Feb. 1992), 97-107. [7] Carzaniga, A., Rosenblum, D.S., and Wolf, A., Design and evaluation of a wide-area event notification service. ACM Transactions on Computer Systems, 19, 3 (2001), 332-383. [8] Cugola, G., Di Nitto, E., and Fuggetta, A., The Jedi eventbased infrastructure and its application to the development of the OPSS WFMS. IEEE Transactions on Software Engineering, 27, 9 (2001), 827-850. [9] FIPA Agent Management Specification. Document identifier (Mar. 2004). SC00023K. http://www.fipa.org/specs/fipa00023/SC00023K.html [10] Fortino, G., Frattolillo, F., Russo, W., and Zimeo E., Mobile active objects for highly dynamic distributed computing. In Proceedings of IEEE IPDPS’02, Workshop on Java for Parallel and Distributed Computing, (Fort Lauderdale, FL, April, 2002). IEEE Computer Society, 2002, 1-8. [11] Fortino, G., Garro, A., and Russo, W., From modeling to simulation of multi-agent systems: an integrated approach and a case study. In Proceedings of 2nd German Conf. on Multiagent System Technology (MATES’04), (Erfurt, Germany, Sept. 29-30, 2004). Springer-Verlag, LNAI 3187, 2004, 213-227. [12] Fortino, G., and Russo, W., High-level interoperability between Java-based mobile agent systems. In Proceedings of the 17th ISCA International Conference on Parallel and Distributed Computing Systems (PDCS'04), (San Francisco, CA, USA, Sept. 15-17, 2004). [13] Fortino, G., Russo, W., and Zimeo, E., A Statecharts-based Software Development Process for Mobile Agents.
Information and Software Technology, 46, 13 (Oct. 2004), 907-921. documentation and software, [14] JavaSpacesTM, http://java.sun.com/products/javaspaces/, 2004.
at
[15] Lange, D.B., and Oshima, M., Seven good reasons for Mobile Agents. Communications of the ACM, 42, 3 (1999), 88-89. [16] Luck, M., McBurney, P., and Preist, C. Agent technology: enabling next generation computing: A roadmap for agentbased computing. AgentLink Report, 2003. Available from www.agentlink.org/roadmap. [17] Omicini, A., and Zambonelli, F., Tuple centres for the coordination of internet agents. In Proceedings of ACM Symp. on Applied Computing (SAC’99), special track on Coordination Models, Languages and Applications, (San Antonio, TX, USA, Feb 28-Mar 2, 1999). ACM Press, New York, NY, 1999. [18] Padovitz, A., Loke, S.W., Zaslavsky, A., Using the publish/subscribe genre for mobile agents. In Proceedings of 1st German Conf. on Multiagent System Technology (MATES’03), (Erfurt, Germany, Sept. 29-30, 2003). Springer-Verlag, LNAI 2831, 2003, 180-192. [19] Picco, G.P., Murphy, A.L., and Roman, G.C., Lime: Linda meets mobility. In Proceedings of the 21st Int’l Conf. on Software Engineering (ICSE'99), (Los Angeles, CA, USA, May 1999). [20] Silva, A.R., Romao, A., Deugo, D., and Mira da Silva, M., Towards a reference model for surveying mobile agent systems. Autonomous Agent and Multi-Agent Systems, 4, 3 (2001), 187-231. [21] Objectspace Voyager, documentation and software, at http://www.recursionsw.com/products/voyager/voyager.asp, 2003.
