a statecharts-based methodology for the simulation of multi-agents

A STATECHARTS-BASED METHODOLOGY FOR THE SIMULATION OF MOBILE AGENTS Giancarlo Fortino and Wilma Russo DEIS – Dipartimento di Elettronica, Informatica e Sistemistica Università della Calabria Via P. Bucci cubo 41C, Rende (CS) Italy E-mail: {g.fortino, w.russo}@unical.it

KEYWORDS Distilled Statecharts, Mobile Agents, Java, Discrete-Event Simulation. ABSTRACT Mobile agent paradigm and technology are profitably being applied for the construction of a wide range of applications and systems in several areas encompassing e-business, telecommunications, meta-computing and military simulations. Such systems are usually complex so requiring methodologies and tools for an in-depth understanding of their dynamics and for their validation. This paper presents and exemplifies a methodology for modeling and validation through simulation of mobile agents based systems and applications. Mobile agents are modeled as asynchronous, event-driven single threaded entities whose behavior is specified using Distilled Statecharts. A distilled statechart, which embeds both the activity and the interactions a mobile agent performs during its lifecycle, can be easily translated into a Java composite object using the mobile active object framework. In order to analyze an agent-based system, a discrete-event, reflective simulation framework which allows for concurrency, timing and meta-level customization, is used. A case study is also provided which highlights the main features of the proposed methodology. INTRODUCTION Recently there has been a growing interest in designing and building distributed systems and applications in heterogeneous environments using the mobile agent paradigm and technology. Mobile agents are autonomous software components migrating within a network of execution environments to fulfill a goal-oriented task. They have been applied to several application areas ranging from telecommunications to e-business, from metacomputing to information retrieval over Internet (Gray et al. 2002). Such trials have shown the suitability and the potential benefits of mobile agents but, to date, their actual exploitation is rather limited. The main reason is that current mobile agent systems are still research prototypes so the majority of applications and systems developed using mobile agents can be developed using more traditional techniques. Indeed mobile agents allows for conservation of bandwidth, reduction in total completion time, reduction in latency, support for disconnected operation, support for load balancing and support for dynamic deployment, which are strengths

uniquely shared only by mobile agents (Gray et al. 2002). In order to acquire a deeper understanding of the dynamics of mobile agent-based systems, applications, and basic technology before their actual development and deployment, simulation can be exploited. In particular, flexible simulation methodologies and tools are required which should be able to model, analyze, and validate: (i) the activity (computations, interactions, and migrations) of mobile agents; (ii) the basic mechanisms of the distributed architectures supporting mobile agents, namely mobile agent systems; (iii) the behavior of applications and systems based on mobile agents. Although several approaches and systems for the simulation of mobile agents are widely available (Uhrmacher et al. 2000; Theodoropoulos and Logan 1999), this research area is still young and prone to be further investigated. In this paper, a methodology for flexible modeling and simulation of mobile agents is proposed. Modeling relies on Distilled Statecharts (DSCs) (Fortino et al. 2002) purposely derived from UML Statecharts (OMG 2001) which allow to specify the behavior of both mobile agents and stationary agents. Mobile agents are represented by asynchronous, event-driven and single-threaded entities which fulfill their goal-directed activity by alternating computations, interactions, and migrations. In particular computations and interactions are performed within a specific agent server (or location) whereas migrations are carried out across a network. Conversely stationary agents are not able to migrate and their main task is to grant secure access to the resources of their locations. At high level a complete agent-based system is modeled by a set of distilled statechart specifications associated either to mobile agents or to stationary agents. A DSC specification is translated into a composite object by means of the mobile active object framework, which is currently implemented in Java (Fortino et al. 2003). The simulation phase is enabled by a specialization of a discrete-event, reflective simulation framework exploited for the simulation of multimedia systems (Fortino and Nigro 2000) which embeds the composite objects obtained from a system specification by associating them to specific locations interconnected by a logical network. The simulation framework provides object execution through interleaving of timed and untimed events dispatching and meta-level customization by filtering of events generated by agents.

A mobile agent can be modeled as an event-driven lightweight agent and represented by the following tuple: EA = , where: • ID is the unique identifier of the agent. • DSM is a Distilled Statechart Machine object representing the dynamic agent behavior. Distilled StateCharts (DSCs) (Fortino et al. 2002) are a visual formalism derived from UML statecharts (OMG 2001) and purposely suited for event-driven single-threaded entities. A distilled statechart specifies the agent activity as a chain of atomic actions executed during specific state transitions triggered by internal and external stimuli (or events). • CONTEXT is the basic agent class encompassing specific agent methods, references to the execution environment, and (possibly) data. In particular, it provides the primitive generate(()), which allows to asynchronously generate self-triggering events or interaction events targeting other agents. • EQ is the event queue buffering the received events. • TC is the thread of control supporting the agent execution. In particular, an agent computation can be defined in terms of processing of the events serially extracted from its queue. An agent computation step, which is cyclically repeated till the agent termination, consists of: (i) removing an event, if any, from the event queue; (ii) reacting to the event according to its dynamic behavior; (iii) (possibly) changing its local state. During (ii), an agent can generate zero, one or more events.

Object-oriented design and implementation of eventdriven lightweight agents The MAO (Mobile Active Object) framework (Fig. 2), which is purposely derived from the Statecharts Pattern (Yacoub and Ammar 1998) and currently implemented in Java, is used to translate the DSC specification of a dynamic agent behavior first into a design object and then into an executable composite object (Harel and Gery 1997). DSC

AState

currentState

MAOBehavior

parentState +changeState(AState):void +startState():AState +handler(Event):int

+changeState(AState):void +dispatch(Event):void

SimpleState

+generate(Event):void +self():MAOId

MAOInitiatedState

MAOWaitingState

CompositeState +addState(int, AState):void +getState(int):AState +shallowHistory:AState +deepHistory:AState #getDefaultEntrance():AState

TopState

MAOSuspendedState MAOStateTemplate

MAOTransitState MAOActiveState +buildSubActiveStates():void

Agent migration

Figure 2. The UML class diagram of the MAO Framework

A mobile agent initiates a migration operation by generating the Move(Destination) event targeting itself for autonomous migration or targeting another agent for passive migration. In both cases, the actual migration can occur only after receiving and processing the Move event. In order to enable transparent migration according to a coarse-grained strong mobility model (Karnik and Tripathi 1998), the agent DSM is based on the agent mobility template (Fig. 1). ACTIVE

Execute

TRANSIT

exactly in the same state it left off before migrating. In addition the agent mobility is of coarse-grained strong type since the agent can migrate only at specific points of its execution, i.e., after completing the reaction to an event.

compositeStates

A REFERENCE MODEL FOR MOBILE AGENTS AND ITS IMPLEMENTATION

H*

Active Distilled StateChart

Move

Figure 1: The Agent Mobility Template. Such a template assures that every time the agent migrates, i.e., it goes from the Active to the Transit state, and then it is restored at the destination site, i.e., it turns back from the Transit to the Active state, the agent execution is restored

The MAO framework (Fortino et al. 2003) defines a FIPAcompliant architecture (FIPA 2002) for the dynamic behavior of lightweight agents and provides the basic building block to create them. Its frozen spots define the overall architecture of a MAO characterized by classes which remain unchanged in any instantiation of the framework (concrete classes in Figure 2), whereas its hot spots are to be adapted to the needs of the specific agent under development. To achieve adaptability it is necessary to subclass the abstract class MAOActiveState in order to define the specific active behavior of the MAO. In addition the following rules should be followed in order to design and implement the Active Behavior DSC: • the classes of the specific substates transitively nested in the active state should extend either SimpleState or CompositeState

• the introduced substate classes should be linked, using a composition association, to one another and to the specific active state class according to their hierarchical structure

MAOBehavior

GenericAgent + GenericAgent(MAOBehavior, MAOId, MAOQueue) + generate(MAOEvent):void + receive(MAOEvent):void + getMAOId():MAOId + run()

+ MAOBehavior(GenericAgent, MAOActiveState) + generate(MAOEvent):void + self():M AOId + start()

MAOQueue +enqueue(MAOEvent):void +dequeue():M AOEvent

MAOId +getName():String +getHomeLocation():String +getCurrLocation():String

Figure 3. The Agent Adaptation Framework Although the goal of this paper is mainly oriented to mobile agents simulation, the obtained event-driven lightweight agent is independent from any real or simulation context and can seamlessly be adapted to real mobile agent systems. In particular, it can be either supported by an ad-hoc built agent platform as in (Fortino et al. 2002) or mapped onto any mobile agent or object system for real executions. In fact, every currently available mobile agent system (Gray et al. 2002) provides a specific mobile agent programming abstraction along with coordination primitives, naming, and other facilities through which a mobile agent can be actually implemented.

A DISCRETE-EVENT, REFLECTIVE SIMULATION FRAMEWORK A mobile agent-based system or application can be seen as a set of stationary or mobile event-driven lightweight agents, which are obtained using the approach described in the previous section. In order to simulate them, agents are embedded into a Java-based simulation framework which basically provides: (i) execution of agents by interleaving their event processing, (ii) interchange of events among agents, (iii) migration of agents, and (iv) clustering of agents into networked locations. Virtual Global Clock Global System Timer-Queue

• state variables should be declared in state classes at a certain level of the hierarchy according to their scope • events labeling transitions of the visual specification are classes extending MAOEvent • action expressions and guards should be enclosed in methods • transitions are masked inside the method handler of each specific state. In particular, a transition originating in a given state should be realized within the handler of that state. Thus, a MAOBehavior object is a composite object encapsulating the dynamic behavior of an agent. It is activated through the following steps: (i) its constructor receives the specific MAOActiveState object, creates the MAOStateTemplate object and passes it the reference to the specific active state. (ii) the start method is invoked on the MAOBehavior object, which sets its current state to MAOInitiatedState. A generic event-driven lightweight agent (GenericAgent) is obtained by associating and adapting a MAOBehavior object to an agent class further encompassing an identity object, a queue object, and generally a thread. Figure 3 shows a UML class diagram of the agent adaptation framework. The run method cyclically extracts the next available event to be processed from MAOQueue until MAOBehavior reaches the final state. A dequeued event drives MAOBehavior through the dispatch method. The receive method is invoked either by the execution environment (or agent server) or by the agent itself when an event targeting a GenericAgent is generated. The generate method directly enqueues a MAOEvent if it is a self-trigger, otherwise uses the specific coordination mechanisms of GenericAgent to route the event toward its final destination.

Global System Event Queue enqueue

dequeue

set Meta-Agents receive fire

generate

Selector/ Dispatcher

route

EVENT ROUTER

Simulation Engine receive

Agents LOC1

Agents

LOC2

generate

Agents

LOCn

Virtual Network

Figure 4. The Simulation Framework Architecture The architecture of the framework is reported in Figure 4. Its basic components are: • Global System Event Queue (GSEQ), which stores all the untimed system events to be delivered. An event is an instance of MAOEvent which contains the MAOIds of the event source and target, and (possibly) data objects. • Global System Timer Queue (GSTQ), which stores all the system timers. A timer is an object encapsulating a MAOEvent and a timeout. The event is delivered at the timeout expiration. The timeout refers to a virtual simulation time. • Virtual Global Clock (VGC), which represents the virtual global time under the hypothesis of clock synchronization among networked nodes. It is incremented every time that a timer expires. • Simulation Engine (SE), which drives the execution of a simulation. It is further composed of: o a set of Meta-Agents, which are stationary agents installed on a group of agents which filter their event generations. When Meta-Agents act as Synchronizers (Fortino and Nigro 2000), they can capture an event and schedule its actual delivering to occur after a timeout by setting a Timer. o Event Router (ER), which receives the events generated by the agents and insert them into GSEQ if they are not subjected to meta-level customization; otherwise ER routes the events to their associated meta-agents.

o Selector & Dispatcher (SD), which cyclically extracts an untimed event from GSEQ and dispatches it to the target agent. If no events are present in GSEQ, SD forces a timer (the one with the lowest timeout) to fire and dispatches the associated event to its target. • Agents, which are the computational entities, stationary or mobile, of an agent-based system. They can only perform computational tasks, i.e., computations, interactions and migrations. Agents are stored into the global system white pages table (GSWP) whose entry is a tuple . An agent is an instance of SimulationGenericAgent which adapts GenericAgent to the simulation environment. It contains a reference to SE which supports the agent execution and makes it available the generate method. The run method and the MAOQueue are disabled. • Virtual Network, which is the virtual network infrastructure, realized by means of specific meta-agents, connecting the Virtual Agent Locations (VALs). VAL is implemented as a symbolic name which can be referred by the home location and current location attributes of the MAOId of an agent. Meta-level Customizations: Network Events and Migration Meta-level customization allows for separation of concerns: computational agents are unaware of network and timing issues and only perform functional tasks whereas meta-agents impose timing constraints to generated events according to network and system dependent parameters (Fortino and Nigro 2000). Network events are events whose source and target agents are on different VALs. Their transmission is supported by the Network Meta Agent (NMA) which captures and constrains them to occur after a timeout set according to network parameters (e.g., link delay) and event size. The agent migration process supported by the Migration Meta Agent (MMA) involves the following steps: 1. MMA captures the Execute event, generated as a consequence of the transition from Active to Transit, and creates a timer, containing the event itself, whose timeout is set to the instant in time of migration completion according to network connection parameters and agent dimension (code and data). 2. MMA sets the current location to the new agent location in the MAOId of the migrating agent. Events delivered to an agent during its migration, if local to the new agent destination, are buffered into a temporary event queue (TEQ) associated to the migrating agent; otherwise, events are handled as network events and directed through a forwarder (FW) to the future agent location. 3. After the timer expiration, the Execute event is delivered to the agent and its processing restores the agent back into the Active state and inserts all the events contained in TEQ into GSEQ. Both the NMA and MMA refer to a specific-format file which contain the network topology description. By default, the network topology is modeled as a completely connected peer-to-peer network of VALs, even though other topologies can be easily constructed.

A CASE STUDY The case study refers to the analysis of the dynamics and strategies of an agent-based electronic market (Bredin et al. 1998). The agents of the electronic market are: • Traveling SalesAgent (TSA), which represents a traveling salesperson whose goal is to look for a specific product that meets the needs of its customer. It moves across the network to locate all the vendors of the required product by interacting with a distributed system of yellow pages (YP) which offers the catalog of vendors. After retrieving a list of vendors, TSA moves to the vendor sites in order to buy the most convenient product. In order to pay for the YP service and to buy a product, TSA is equipped with a wallet containing a limited amount of e-cash. • YellowPage Agent (YPA), which represents an entry point of the YP distributed service. YPA is queried by TSA for information on vendors of specific products. YPA returns either the requested info or the location of another YPA. Each query costs a fixed amount of e-cash. • Vendor Agent (VA), which represents the vendor of specific products. In order to buy a specific product, TSA asks VA for the product price and decides to buy it or to move to another VA location. • Bank Agent (BA), which represents a reference bank of TSA, VA, or YPA. Bills owned by such agents are unique, cryptographically signed documents issued by one of the accredited banks (set of BA). A bill is a few bytes of information containing: the name of the bank (or BA), the amount of the bill, the unique bill identifier, and the bank’s signature needed to check the authenticity of the bill. When TSA buys a specific product or submits a searching query, it has to pay VA or YPA for a given amount of bills. Under the hypothesis that each bill has the same value and that each product price is equal to an integer number of bills, the money transaction between two agents (Buyer and Seller) runs as follows: Buyer gives the bills to Seller which adds the bills to its wallet whereas Buyer removes them from its wallet. The bills should be validated by Seller in order to prevent their duplicated use by Buyer. The active dynamic behavior of TSA is reported in figure 5. In the SEARCH4VENDORS state, TSA searches for vendors by navigating across the yellow pages distributed system. Before submitting the queryvendor to a YPA, TSA pays 1 bill for the requested service in the PAYFOR state. Afterwards, it analyzes the obtained result using the enoughVendors method. If TSA has collected a sufficient number of vendor identifiers or no more available YPAs exist, TSA moves to the chosen next vendor location for contracting with a VA. In the CONTRACTING state, TSA first asks VA for the product price; then, on the basis of the evaluation of the received offer made by the price_is_ok method, it can decide to buy the product or to move to the next VA or to search for new VAs. When TSA purchases a product, it comes back to its home location and notifies the transaction result to its owner. Table 1 reports, for sake of clarity, the meaning of state variables, methods and interaction events of Figure 5. Moreover, for sake of simplicity, Figure 5 does not highlight the exceptional cases of unsuccessful purchase.

CONTRACTING

SEARCH4VENDORS / ac1; ac2

/ ac5

Interact

SEARCH

SQuery / ac3

SQuery / ac3

WAIT

QPRICE

Interact

Offer / ac6

Result / ac4 ANALIZE

Search / ac2

• Fixed-trials. TSA first searches for VAs providing a specific product and then visits such VAs one by one. After a fixed number of trials (or received offers), TSA moves to the location of the VA which offered the best price and buys the product. • Random-trials. Similar to fixed-trials but using a random number of trials uniformly distributed between a minimum and a maximum number.

ANALIZE

Table 1. State Variables, Methods and Events related to TSA

H Pay / ac8

Search / ac31 Pay / ac7

PAYFOR

TResult2User / ac12

/ ac9 PAY

DONE

TComplete / ac10

Paid / ac11 PAID ac1 :int nextYP=0; ac2 :YPAtarget=(MAOId)yp.elementAt(nextYP++); generate(new MAOMove(self(),YPAtarget.getCurrLocation())); generate(new Pay(self())); ac3 :generate(new QueryVendor(self(),YPAtarget,queryvendor)); ac31:generate(new SQuery(self())); ac4 :Result r = (Result)e; if (r.getAvailableVendors()) { addVendors(r.getVA()); ac41(); else { addYPA(r.getYPA()); ac2(); } ac41:if (enoughVendors()) { VAtarget=(MAOId)va.getNext(); generate(new MAOMove(self(),VAtarget.getCurrLocation())); generate(new Interact(self())); } else ac2(); ac5 :generate(new QueryPrice(self(),VATarget,queryprice)); ac6 :Offer o = (Offer)e; prodcost = o.getPrice(); if (price_is_ok(prodcost)) generate(new Pay(self())); else if (enoughVendors()) { VAtarget=(MAOId)va.getNext(); generate(new MAOMove(self(),VAtarget.getCurrLocation())); generate(new Interact(self())); } else (generate(new Search(self())); ac7 :amount = 1; bills = prepareBills(amount); ypflag=true; target = YPATarget; ac8 :amount = prodcost; bills = prepareBills(amount); ypflag=false; target = VATarget; ac9 :generate(new PayFor(self(), target, bills); ac10:nbills = nbills – amount; if (ypflag) generate(new Search(self())); else generate(new Paid(self())); ac11:generate(new MAOMove(self(),self().getHomeLocation())); generate(new TResult2User(self())); ac12:reportTR();

Figure 5. The Active DSC of TSA The strategies that TSA uses to search for and buy products are embedded basically in its dynamic behavior and specifically in the methods enoughVendors and price_is_ok. It is worth noting that TSA buys a product if and only if the product price is equal to or less than Pmax. The implemented strategies are the following: • Minimum Price. TSA first searches for all the possible VAs providing a specific product and, then, interacts with all the found VAs to find out the best price for the product. Finally, it moves to the location of the VA which offered the best price and buys the product. • First-shot. TSA first searches for VAs providing a specific product and then visits such VAs one by one. As soon as a VA offers an acceptable price (i.e.,