The POEMA Framework

Together with researchers of the DSE Group of the Imperial College we have designed and implemented at LIA - DEIS - University of Bologna the POEMA (POlicy Enabled Mobile Applications) framework for supporting the design, development and deployment of adaptive MC applications. As a key feature, POEMA adopts a policy-based paradigm to guide and enforce dynamic application reconfiguration.

For the definition of reconfiguration policies POEMA uses Ponder, a policy language evolved out of work on policy-based management at Imperial College over the past 10 years. Ponder allows developers to specify all the basic elements involved in reconfiguration decisions, i.e., conditions relevant for triggering reconfiguration, units of mobility, destination locations for migrating components, and the subjects responsible for mobility decisions. In addition, Ponder permits us to specify reconfiguration policies for MC applications implemented with any kind of technology, such as Java.

POEMA provides several middleware facilities to support policy lifecycle management: policies can be dynamically introduced, modified, checked for correctness, installed and evaluated. Policy enforcement consists in interpreting policy specifications and in transforming them into low-level management actions that drive application reconfiguration. It is worth outlining that the POEMA middleware ensures also the consistency and the security of all policy lifecycle management tasks. On the one hand, POEMA preserves the normal processing of applications both while reconfiguration policies are applied and subsequent to policy enforcement: reconfiguration cannot lead applications toward an error state. On the other hand, POEMA permits only authorised users to define reconfiguration policies and to enact changes in the application behaviour and layout at run-time.

Currently, the POEMA framework is implemented on top of the Secure and Open Mobile Agent (SOMA) programming environment that offers the basic services needed to support run-time execution of MA applications with guarantees of interoperability and security. It is worth noting that the POEMA middleware could easily integrate with other MC systems with slight modifications to its current implementation.

Programming Reconfiguration Policies in POEMA

To facilitate the definition of reconfiguration strategies we advocate the adoption of an high-level policy language. Our specification model for reconfiguration strategies relies on the Ponder language. Ponder has several features that make it suitable for policy-controlled reconfiguration. Ponder provides the means to explicitly specify all the elements involved in reconfiguration decisions. In addition, it is a declarative language that simplifies the task of policy specification and can support policy analysis and verification for potential conflicts and inconsistencies that inevitably arise in large-scale agent systems. Ponder also provides encapsulated and reusable policy modules and supports structuring techniques that are essential to facilitate the specification of policies relating to collections of agents.

For policy-controlled reconfiguration we adopt a subset of Ponder policies, i.e. obligation policies. Ponder obligation policies are event-triggered policies that permit to adapt reconfiguration strategies to dynamic changes occurring at both application and environment level. Generic state changes can be modelled in terms of events. More in detail, obligation policies define the actions that policy subjects must perform on target entities when specific relevant events occur. Ponder uses the term subject to refer to users and principals which have management responsibility, i.e., have the authority to initiate a management decision. A subject can operate on target entities by invoking methods of the target interface.

Let us introduce a simple example to illustrate the use of Ponder obligation policies for programming reconfiguration strategies. The case of an Mobile Agent-based application is considered. In Table 1 the policy named P1 allows to specify the migration of an agent named agents/Manager to the G1 node when the current execution node becomes overloaded. The triggering event specification (CPULoad(90)) follows the on keyword. Event specification can include events of any type and can use event expressions to combine basic events into more complex ones, to allow to model any sequence of events. For instance, events can be either simple events or composite ones such as E1 -> E2 for event E1 followed by event E2. Events can also be parameterized and the parameters used in invoked actions. In the P1 policy, the migration action (the go() method) is triggered by a CPU usage exceeding 90% and is executed by the agent itself. The migration method takes the destination execution node (G1) and the name of the method to perform (run()) as input parameters. The migration action can be performed only if G1 is reachable and has the resources needed for agent computation (as monitored by an underlying monitoring system). Note that migration decisions can be activated only if specific deployment conditions hold at event occurrence. Ponder permits programmers to specify these conditions that act as policy constraints. Constraints are expressed in terms of a predicate which must be true for the policy to apply (the when clause).


inst oblig P1
on CPULoad (90)
s = agents/Manager do s.go(G1.toString(), "run")
when MonitoringSystem.getReachabilityStatus(G1)==true and MonitoringSystem.hasResources(G1, resources)==true

Table 1. An example of Ponder obligation policy.

In case of problems, or if you find any bug, please contact us.