Policy Controlled Mobility Antonio Corradi, Rebecca Montanari Emil Lupu Dip. di Elettronica, Informatica e Sistemistica Department of Computing Università di Bologna Imperial College Viale Risorgimento 2, Bologna, Italy 180 Queen’s Gate, London, UK {acorradi, rmontanari}@deis.unibo.it
[email protected] ABSTRACT The mobility of software components seems an interesting solution for the deployment of web services and applications in the Internet global infrastructure and also in mobile ad-hoc networks. The network infrastructure already supports several forms of code mobility to make possible to dynamically reconfigure bindings between code fragments and locations where they are to be executed. However, more work is still to be done to facilitate the specification and the enforcement of the mobility behaviour of software components. The traditional approach to embed the migration strategy into the component at design time can not suit the dynamicity of the new network scenarios. Mobile components should instead be enhanced with the possibility to adapt their mobility behaviour to evolving application and environment conditions and to react to unforeseen events. To reach this goal, the paper proposes the adoption of policy based systems to abstract away the specification of migration strategies from the component code. This approach permits to change the mobility behaviour of components without intervention on the component code. We have experienced the dynamicity and flexibility of the proposed approach in the framework obtained by integrating a policy-based management system in a mobile agent environment. Keywords: Mobility, Migration Policies, Adaptation Mobile Agents, Reconfiguration. 1 INTRODUCTION The mobility of software components can change the way distributed applications are designed, realised, and deployed [1]. Mobility is attracting attention both in the Internet community and in the field of mobile ad-hoc networks. In the former area the final goal is pervasive computing, where mobile users can access web services anywhere [2]. In the latter area mobility is a peculiar characteristic, with devices that can frequently move in new network environments, where they need to be reconfigured to operate properly [3]. In both scenarios, the mobility of software components should address the dynamic changes that can take place in both application requirements and environment state. The challenge is to express an adaptive mobility behaviour to face these changes. Adaptive mobility behaviour of components is essential in an environment where users are mobile and where it is not reasonable to assume fixed logical and physical network boundaries, and node availability. In this context, a static migration control is not
Cesare Stefanelli Dip. di Ingegneria Università di Ferrara Via Saragat 1, Ferrara, Italy
[email protected]
viable because it lacks flexibility. In fact, new migration strategies need to be re-established from scratch at any change of application requirements and environment state, since programmers cannot know this information at design time, and any a priori assumption is unlikely to hold during component execution. How to address dynamicity and flexibility in the mobility specification and enforcement is still an open research issue. With regard to the computation of dynamic and flexible migration strategies, the challenge is to enable mobile applications programmers to optimise the relocation of components onto the set of available environment nodes based on both environment state and application requirements, such as, for instance, total execution time, fault tolerance, and load balancing. The complexity of the task seems to call for intelligent systems to automatically compute adaptive migration strategies. Along this direction, a possible approach is to exploit AI reactive planning methods that synthesise the sequence of actions to achieve a given goal in unpredictable and dynamic environments [4]. In the case of mobility, for instance, an AI planner can find the best sequence of sites where to relocate components, the so-called migration plan, that minimises the expected time to complete the application tasks [5]. However, producing adaptive migration strategies is worthless if the underlying programming framework cannot handle migration changes at run-time. There is the need to develop mechanisms for enforcing migration strategies that allow for run-time changes of mobility behaviour without any impact on component implementation. The traditional approach of hardwiring the set of migration rules into the component code requires component reengineering to address the evolution of application requirements and environment state. The development of mobile applications may benefit in terms of flexibility and dynamicity from the adoption of a programming paradigm that assumes the explicit separation of mobility specifications from code. The research on mobile software architectures is beginning to recognise the opportunity of this separation [6], [7]. Within this framework, the paper investigates a policycontrolled approach to mobility, where programmers specify the mobility behaviour in terms of declarative highlevel policies decoupled from the application logic. Dynamic modification of component mobility behaviour requires to change only policy specifications, whereas the control and enforcement of migration is delegated to the underlying policy support, transparently to the application
code. The policy support is also in charge of preserving the consistency of the component that has to be relocated. The feasibility of the policy controlled mobility approach is demonstrated by the integration of the Ponder policy language within the Java-based SOMA mobile agent [8], [9]. The Ponder language defines and controls agent mobility strategies and the SOMA programming framework offers the needed services for the support of policy-driven mobile agents applications. 2 POLICY CONTROLLED MOBILITY Most systems that support some forms of mobility exhibit rigid control schemes. The primary limitation derives from the fact that the rules for governing entity mobility are hard-coded into components at design time. This approach does not allow applications to adapt to the evolving condition of a mobile scenario, with roaming users and terminals, and with possibly discontinuous interconnection. Another source of rigidity derives from the assumption about the unit of mobility, i.e. the part of the component that has to move. For instance, the remote evaluation and the code on demand models provide for the shipping/fetching of code only, whereas in the Mobile Agent (MA) paradigm the agent code moves together with the state [1]. Application designers, instead, could benefit from schemes with a finer grain of mobility control. To overcome these drawbacks, this work proposes to rule component migration by means of policies separated from component code. A policy is a set of rules governing the behaviour of the system [10], [11]. In our context, policies describe the mobility behaviour of components. Policycontrolled mobility can benefit from the research carried out in the field of policy-based management for distributed systems [11]. The main advantage of policy adoption is the increased flexibility and dynamicity in the control and change of the mobility behaviour of components. The clean separation between the mobility policy and the coding of components permits to dynamically introduce new migration strategies without impact on component implementation. A policy-based approach to mobility should provide a clear policy model specifying how mobility policies can be expressed and represented and an enforcement model that determines how to map policy specifications into low-level implementable policies. Since mobility policies and mobile components to which policies apply, are separated modules, the enforcement model is responsible for integrating them in a consistent and coherent manner. 2.1 Event-Triggered Policies for Controlled Mobility Among the various types of policies, we decided to model mobility in terms of event-triggered policies, i.e. policies triggered by event occurrences. The concept of eventtriggered policies has been generally used in the field of policy-based management for distributed systems to handle automated management tasks, such as configuration and security tasks.
In the case of mobility, event-triggered policies specify the migration actions that must be performed when specific events occur. Events can be defined as generic state changes in the system and can uniformly model different changes in application and environment conditions. Some examples of the former case are the completion of an application task and the arrival/departure of new components in/from an execution context. For the latter case, consider the CPU and the memory usage, and the bandwidth occupation. Event-triggered policies require underlying support services for the registration, detection and notification of events. The exploitation of event-triggered policies facilitates the development of mobile components capable to adapt to system evolution. Events provide an indication when migration actions should take place within the overall execution flow of components and, therefore, offer an integrated solution that reduces the difficulties of introducing dynamic changes in the mobility behaviour of components [12], [13]. 2.2 Policy Language Requirements Expressing mobility policies in large-scale mobile environments requires to design an expressive policy language solution that can facilitate the specification of the mobility behaviour of components by providing at the same time a feasible and effective implementation model. A policy definition language for mobility should satisfy several requirements. A primary one is to adopt a declarative policy language, to separate the specification of the migration strategy from its enforcement on mobile components at run-time. The migration strategy is described in terms of declarative rules specifying who, must migrate, when, and where. The policy enforcement infrastructure is responsible for the notification of the event to the component and is in charge also of forcing migration actions. Another advantage deriving from the exploitation of a declarative policy language is the increased simplicity of policy analysis for potential conflicts and inconsistencies. A policy definition language should permit the expression of all basic elements involved in mobility. First of all, the specification of the entity that is in charge of triggering the mobility strategy, i.e. the policy subject, and the entity which is targeted by relocation, i.e. the policy target. A policy subject could be either a mobile component or the current execution environment. In the first case, the mobile component autonomously decides to migrate, whereas in the second case it is the hosting execution environment that forces the migration, for instance to improve load balancing. With regard to policy subject/target, the policy language should permit programmers to specify the desired unit of mobility with a fine-grained approach. For instance, the specified unit of mobility can be the whole mobile component, or just parts of its code or of its data depending on application and environment conditions. The policy
language should be also designed to model the events relevant for triggering migration changes, the set of mobility actions to perform at event occurrence, and the location where mobile components need to move. In addition, it could be useful to define the conditions to be checked before the actual activation of mobility actions. These conditions act as constraints for the applicability of a mobility policy and can depend on dynamic attributes, such as the state of the resources that the component is accessing. Finally, a policy language for mobility should not assume a particular implementation platform (Java, TCL, ..); rather it should map to, and co-exist with, one or more existing underlying mobility-aware platforms. 2.3 Open Issues in Policy-controlled Mobility There are several interesting open issues for the enforcement of event-triggered mobility policies. The migration of a component should preserve its consistency. To this purpose, the policy infrastructure should be designed to enforce a mobility policy only when the application logic of the component is in a consistent state. For instance, the policy infrastructure could check whether the component is currently engaged in a transaction. As soon as the transaction is completed, the policy should be activated, the event reaction should be performed as an atomic action, and all the resources to which the component is bound should be consistently released or updated [3]. Similar issues emerge in the field of dynamic change management of distributed applications [14]. Another source of possible inconsistencies derives from the conflicts that inevitably arise in any large policycontrolled system at both specification and run-time. For example, it could happen to have two different policies that oblige and refrain the same policy subject to perform the same migration action on the same policy target. A runtime policy conflict can arise, for instance, when different events trigger a set of policies that contain conflicting actions. Therefore, a paramount issue for policy-driven mobility is how to detect and resolve conflicts and the research already carried out in the field of policy conflicts can offer valuable solutions [15], [16]. 3 A POLICY-CONTROLLED MA FRAMEWORK We have studied and applied the policy-controlled approach to mobility in the context of an MA system that exploits a policy language for governing agent behaviour. The MA system is called SOMA and it is a programming framework with a rich set of services for the development of secure and interoperable MA applications [9]. SOMA agents are controlled via policies expressed in the Ponder language. Ponder is a declarative object-oriented language that supports expressive specification of several types of management policies for distributed systems and provides structuring techniques for policies to cater for the complexity of policy administration in large enterprise information systems [8]. In this work, we focus on a subset
of Ponder policies, i.e. obligation policies, that are eventtriggered policies that permit to mobile agents to adapt their mobility behaviour to dynamic changes. 3.1 Ponder Obligation Policies for Mobility Ponder obligation policies define the actions that policy subjects must perform on target objects when specific events occur. Let us introduce a simple example to illustrate Ponder obligation policies. In Table 1 the P1 policy states that the Buyer agent is obliged by the System component to migrate to a different node, called G1, when the current node becomes overloaded. The migration action is triggered by the CPU usage exceeding 90%, and the Buyer agent is forced to move to G1 and there to perform the run() method, if G1 is reachable. Policy P2 differs from P1 because it is the Buyer agent that decides to migrate and in this case the agent is both the subject and the target of the policy. When subject and target coincides, there is no need in Ponder to explicitly specify the target. Note that the triggering event specification follows the on keyword and that it can include events of any type, such as excessive CPU usage, by simply defining the event name and parameters. Event expressions can also be used to combine basic events into more complex ones, to allow to model any sequence of events. Multiple actions can follow the do keyword. In this case, the policy obligation language provides several concurrency operators to specify whether actions should be executed sequentially or in parallel. For instance, t.a1 -> s.a2 means that the action a2 on the object s must follow the action a1 on the object t. In addition, Ponder obligations can include a when clause to let programmers specify the set of conditions for the policy to be considered valid, e.g., the reachability of the G1 node in p1 and p2. These conditions must be explicit in the policy specification and act as constraints for the applicability of a policy. Ponder constraints are expressed in terms of a predicate, which must be true for the policy to apply. inst oblig P1 { on CPU(load,90) ; subject s = System ; target t = agents/Buyer; do t.go(G1.toString, run()) when G1.isReachable()
inst oblig P2 { on CPU(load,90) ; subject s = agents/Buyer do s.go(G1.toString, run()) when G1.isReachable()
Table 1. Ponder Obligation Policies
3.2 Ponder-controlled SOMA Agents Let us consider the simple example of a mobile shopping agent to show the advantages resulting from our policybased approach to mobility. The agent is dispatched in order to buy a flight ticket at the most convenient price and has an initial list of air-travel sites to visit that can be dynamically modified at run time. The agent visits all the listed sites and reports back to its owner the best collected offer. Figure 1 shows two alternative programming
methodology in this application scenario. In the traditional approach adopted for developing MA applications, the logic ruling the mobility behaviour is statically embedded into the agent code at development time. As an example, Figure 1a reports a code fragment of the SOMA agent called Agent1 that is implemented as a Java passive object of the CheckTicketFlight class and extends the abstract Agent class that defines the basic methods for controlling agent life and migration. The Figure 1a shows that the actions allowing the SOMA agent to migrate (the go() method with the destination site and the task to execute at site arrival as parameters) are interleaved in a sequential and predefined order with the actions allowing the agent both to achieve its application goals (collectTicketOffers() and compareOffers()) and to maintain up to date the travel plan encapsulated in the Itinerary object (removeNext()). In particular, the example assumes that the agent migrates to a next listed node when either it completes its task or the node is overloaded. In the latter case, the agent has to constantly check the CPU load status (the getCpuLoad() method). In the Ponder-based approach only the application logic that is unlikely to change throughout the whole agent execution is embedded into the agent code. The agent mobility behaviour, that is likely to evolve with environment conditions, is abstracted away and modelled by means of Ponder obligation policies. In particular, Figure 1b reports the agent code that is executed at each
intermediate node. In this case the SOMA agent class extends the abstract ObligationAgent class that provides agents with the methods to react to event occurrence accordingly to the specified mobility policies. Figure 1c shows how agent migration strategies are expressed in terms of Ponder obligation policies. Ponder obligation policies include the set of actions needed not only to change the migration strategy of agents, but also to manage the overall agent travel plans. All these actions are triggered by the occurrence of events that derive from changes in the status of both the agent and the ticketinformation service at each air travel agency site. In particular, MobPol1 induces the agent to migrate to the next listed site at the TaskCompletion event occurrence. The TaskCompletion event occurs at completion of the agent run() method and activates the migration if the current travel agency is not yet the twentieth visited site. It is up to MobPol2 to force the agent to go back after the visit of twenty nodes. In addition, MobPol3 is introduced to oblige the agent to move to the successive node in its itinerary if the current hosting site is overloaded. Ponder obligation policies provide also a fine grain of control on the unit of mobility. It is possible to force the migration of only the core agent code, for instance to save the bandwidth in the case of low-bandwidth links. All other agent classes are downloaded on demand if necessary.
Traditionally Programmed Mobile Agent: Policy-controlled Mobile Agent: b public class CheckTicketFlight extends Agent{ public abstract class ObligationAgent extends Agent { AgentSystem env; //the execution enviornment ……. Mailbox mailbox=null; public class CheckTicketFlight extends ObligationAgent { a CPULoad(load,90) int VisitedNodes; …. Itinerary itineraryPath; void run() { String home; List collectedOff=this.collectTicketOffers(); Offer bestOffer; bestOffer=this.compareOffers(collectedOff); void run() { VisitedNodes=VisitedNodes+1; Value(VisitedNode,20) //the agent checks whether the CPU load can } support local computation. ….} TaskCompletion if (env.getCpuLoad()>90) {Node newNode=itineraryPath.getNext(); itineraryPath.removeNext(); MobPol3 MobPol2 MobPol1 this.go(newNode.toString, run)} else { on CPULoad(load,90) on Value(VisitedNode, 20) on TaskCompletion List collectedOff=this.collectTicketOffers(); subject Agent1 subject Agent1 subject Agent1 if (env.getCpuLoad()>90) target itineraryPath target itineraryPath do {Node newNode=itineraryPath.getNext(); Agent1.go (home, showResults) do itineraryPath.getNext() -> do itineraryPath.removeNext(); itineraryPath.removeNext() -> itineraryPath.getNext() -> this.go(newNode.toString, run); Agent1.go(newNode.toString, itineraryPath.removeNext() -> bestOffer=this.compareOffers(collectedOff); run) Agent1.go(newNode.toString, run) //update the number of visited nodes when VisitedNodes
