A FRAMEWORK FOR DESIGN AND IMPLEMENTATION OF MOBILE ACTIVE OBJECTS Giancarlo Fortino1, Wilma Russo1, Eugenio Zimeo2 DEIS, University of Calabria, Via P. Bucci, Rende (CS), Italy 2 RCOST, Dept. of Engineering, University of Sannio, Corso Garibaldi, Benevento, Italy {g.fortino, w.russo}@unical.it,
[email protected] 1
Abstract This paper describes the design and the implementation of the mobile active object framework whose aim is to support a methodology for developing event-driven lightweight mobile agents. Starting from a visual specification of the dynamic agent behavior based on Distilled StateCharts, the framework provides the rules by which to obtain an object-oriented design directly implementable as a composite object into a target language. Currently, the framework is implemented in Java in order to exploit the myriad of existing Java-based mobile object and agent systems for supporting execution, migration and interaction of mobile active objects.
Key Words Distilled StateCharts, Frameworks.
Mobile
Agents,
Patterns,
1. Introduction The growing worldwide interest in mobile computing and notably, from a software perspective, in mobile agents featured applications is promoting agent oriented programming (AOP) to be one of the most interesting programming paradigm for developing the next generation of mobile, highly dynamic and reconfigurable distributed systems and applications. AOP [1] can be seen as an improvement of the object-oriented programming on which AOP itself could be mapped to be actually implemented. More recently, due to the explosion of multi-agent and mobile agents systems, technology and models [2, 3], and the consolidation of the research area on Software Agents, a new term, namely Agent Oriented Software Engineering (AOSE) [4], is gaining resonance. The main purpose of AOSE [5] is to envisage methodologies, tools and approaches enabling a wellsupported development (modeling, analysis and implementation) and low-cost maintenance of agentbased software. In the context of this young research field, great efforts are currently being devoted to proposing high-level methodologies, design methods and languages supporting both the micro (agent structure) and
the macro level (agent society and organizations) of the agent-based development over heterogeneous computing environments like the Internet. Moreover, further issues related to agent mobility, dynamic coordination among agents, and security complicate such development. This paper presents the mobile active object framework which supports the object-oriented design and implementation phases of the development process of event-driven lightweight mobile agents (also called mobile active objects). A mobile active object (MAO) [6] is an autonomous, reactive and proactive entity whose behavior is modeled using Distilled StateCharts and its interactions performed according to an asynchronous event model. Distilled StateCharts [6] are a visual formalism purposely derived from UML Statecharts [7] to model the dynamic behavior of event-driven, singlethreaded entities. A distilled statechart specification is translated into a design object using the Distilled StateChart pattern. The MAO framework, which is obtained as refinement of the Distilled StateChart pattern, allows obtaining design objects of mobile active object specifications. The actual implementation of a MAO behavior design object is fully supported by a Java library obtained by translation of the MAO framework into Java code. Thus the development process of the behavior of mobile active objects can be outlined as follows: (i) visual specification of the MAO dynamic behavior using Distilled StateCharts; (ii) object-oriented design of the visual specification according to the MAO framework; (iii) implementation of design objects using the Javabased MAO framework package. It is worth noting that a mobile active object at implementation level is a composite object which can be easily mapped onto any Java-based mobile object and agent system in order to be actually executed, migrated and enabled to interact. The rest of the paper is organized as follows. §2 summarizes the mobile active object model by proposing a reference example. §3 shows the design of the MAO framework by using a typical Pattern-based approach. §4 discusses the implementation of the MAO framework as a
Java library. Finally, conclusions are drawn and directions of further work elucidated.
2. Mobile active objects A mobile active object (MAO) [6] is an event-driven, single-threaded executing agent which can migrate within a logical network of execution environments or Active Servers (AS) to fulfill a goal-oriented task. Migration is transparent and can be autonomous if the MAO itself decides whether, when and where to move, or passive if the MAO is moved not on its own choosing but by the execution environment hosting it. A MAO is both reactive and proactive, i.e., it doesn’t simply act in response to stimuli produced by its execution environment, but also it is able to exhibit goal-directed behavior by taking the initiative [2]. Basically a MAO is characterized by: (i) a globally unique, not changeable identifier established at the MAO’s creation; (ii) a dynamic behavior modeled using the Distilled StateChart formalism. It embodies the state and the activity (computations, interactions, and migrations) which a MAO is equipped of during its lifecycle; (iii) an asynchronous event-based interaction model which allows a MAO to self-trigger its activity (proactiveness), to request a service to its Active Server, and to coordinate with other MAOs.
Figure 1 depicts the FIPA-compliant Distilled StateChart template providing the basic structure on which the dynamic behavior of a MAO can be built. The ACTIVE macrostate models the MAO’s active behavior, i.e., the state where the MAO performs its activity when it is running within an AS. 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 Move event can have been generated either by the MAO itself for autonomous migration or by another component (AS or another MAO) for passive migration. The TRANSIT state is a transitory state in which the MAO rests till its migration is completed. The other states and their related transitions should be selfexplanatory and the meaning can be found in [9]. Every MAO is forged according to this basic structure which can be enhanced by introducing an active Distilled StateChart inside ACTIVE. The ACTIVE state is always entered through 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 StateChart properties and the structure of the template assure 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. TOP STATE Resume
2.1 Modeling the Dynamic Behavior ACTIVE
INITIATED
The dynamic behavior is modeled as a set of consistent states and transitions, and is driven by events. It embodies both the state and the activity which a MAO is equipped of during its lifecycle. In particular the behavior is modeled by Distilled StateCharts (DSCs) [6] which further provide clean semantics for enabling a coarse grained strong mobility at high-level. Distilled StateCharts derive from UML Statecharts [7] and their semantics adhere to the state machine execution semantics that retain the basic flavor of the operational semantics of Statecharts [8], while adding new features to make the semantics suitable for software development purposes. DSCs inherit from UML Statecharts the following characteristics: hierarchy, inter-level state transitions, default and history entrances, and “run-tocompletion” execution semantics. The constraints imposed by DSCs with respect to UML Statecharts are: (i) states must be empty, i.e., they do not include entry/exit actions, activity and internal transitions; (ii) transitions (apart from default and history entrances) are always labeled by an event; (iii) each composite state has a default entrance which can only be labeled by an action expression for initialization purposes.
Invoke
SUSPENDED Suspend
H*
Wake_UP
Execute Active Distilled StateChart TRANSIT
WAITING Move
Wait Quit
Destroy
Figure 1. The MAO’s dynamic behavior template.
2.2 The asynchronous interaction model
event-based
The MAO’s interaction model is based on local events, first-class objects by which three possible kinds of interactions can be formulated: (i) intra-MAO interactions (or self-triggers), by means of internal events that the MAO sends to itself in order to proactively drive its computations; (ii) inter-MAO interactions, by means of coordination events that allow MAOs to interact and synchronize among themselves according to a low-level, specific coordination model;
(iii) MAO-AS interactions (or service requests), by means of management events that allow MAOs to ask the AS for services (e.g., MAO’s creation) or resources. Indeed a MAO directly can interact only with the AS hosting it by the asynchronous generation of events (or out-events) toward the hosting AS using the primitive generate(Event) and the implicit reception of events (or in-events) generated by the AS.
2.3 A reference example In the following a MAO behavior is proposed which is used as reference example throughout the rest of the paper. The Active Distilled StateChart (ADSC) of the MAO behavior is depicted in Figure 2. The MAO’s state variables are reported in Table 1. REQUEST / ac1
DataReply / ac3
Step / ac2 DataReply / ac3
DATA REQUEST
Step / ac2
DATA REPLY Reply / ac5
H
PROCESS
VAR
DESCRIPTION
N
Number of requests the MAO issues to other MAOs List of Active Servers to be visited List of identifiers of interacting MAOs Collector of the data coming from the replying MAOs Index of the last AS visited Number of replies received in a request cycle Temporary variable
itinerary recipients data next count
Process [!g] Request
the reception of all the DataReply coordination events), the internal Reply event is generated. • Data processing, which is performed upon reception of the Reply event and realized by means of the process method. It can also occur upon reception of the Process coordination event sent by another MAO if data are enough (the guard g holds), otherwise the MAO returns in the substate of REQUEST which abandoned most recently. process and enough depend on the specific agent behavior. • Migration, which depends on the data processing which, if successful, enables the MAO to autonomously migrate to another site according to its itinerary; otherwise, the monitoring process is reexecuted. In addition, parameter e refers to the instance of the received event and the method self() returns the MAO identifier.
i Process [g] / ac4
Action |expressions: ac1:count=0; generate(new Step(0)); generate(new DataRequest(recipients[0], 0)); ac2:i=((Step)e).getI(); if (i
