The POEMA middleware is designed according to a layered architecture as shown in Figure 1. The policy layer contains the main services to support the deployment of Ponder obligation and authorisation policies. Obligation policies guide application reconfiguration, while authorisation policies control who can read/write reconfiguration policies. The POEMA basic layer exports environment awareness to applications. In particular, it provides the services needed for observing the status of the application operating environment and for notifying application components about relevant environment variations. The POEMA middleware is built on top of SOMA to exploit its naming service that associates mobile agents with globally unique identifiers, its migration service that supports the migration of agents that should change their execution allocation and its communication service that provides tools for coordination and communication between MAs.

Figure 1. The POEMA layered architecture.

More in details, the policy layer includes the following services:

The Specification Service (SS) provides several tools to facilitate the editing, updating, removing and browsing of both reconfiguration and authorisation policy specifications. SS also offers tools for syntactic and semantic analysis of policy specifications and for transforming high-level policy specifications into policy representations that can be interpreted at run-time. In particular, SS automatically generates a Java object for each Ponder policy; policy objects act as simple policy information container and can be accessed by other services to determine the subject, the target and other policy elements.

the Repository Service (RS) stores policies and can be queried to retrieve policies. In particular, the RS is currently organised as a distributed directory service that maintains policies in directory entries. Every directory entry is associated with a unique name that corresponds to the policy name and contains both the Ponder and the Java-based policy representations.

The Policy Management Service (PMS) coordinates policy lifecycle management operations. In particular, the PMS keeps track of whether policies are enabled or disabled, distributes enabled policies to the interested entities, i.e., to policy subjects in the case of obligation policies and to the policy targets in the case of authorisation policies, and informs policy subjects/targets to remove policies when they are disabled;

The Reconfiguration Enforcement Service (RES) is responsible for enforcing obligation policies when relevant events for reconfiguration occurs. In particular, when an event occurs the RES retrieves and interprets triggered policies and activates reconfiguration actions according to the policy specifications. Note that inconsistencies could potentially arise during application reconfiguration, for instance when an event forces one application component to migrate while it is executing an atomic segment of code (a critical section). This is because the Java technology, used to implement the POEMA framework, does not preserve the execution state of active application components upon migration. To this purpose, the RES preserves the consistency of application components execution by ensuring that application component migration can take place only when the execution of the critical section terminates.

The Security Enforcement Service (SES) interprets and enforces the Ponder authorisation policies that developers use to control reconfiguration. Note that Ponder authorisation policies define what actions a subject is either permitted or forbidden to perform on a set of target objects and under which circumstances and that are enforced by access controllers typically co-located with policy targets. The SES serves as a distributed access controller. In particular, when policies are specified the SES ensures that only authorised users can read, edit, and remove reconfiguration policies. Since reconfiguration policies are implemented as objects, authorisation policies may also apply to those objects. At run-time, when a relocation action is triggered, the SES controls whether the CC is allowed to perform it; this is, for example, particularly useful to prevent unauthorised CCs from activating illegitimate relocation of other CCs.

At the basic layer, the Monitoring Service (MS) detects modifications in both application and environment state and the Event Service (ES) receives state information from the MS and manages the notification of events. Any policy subject can register its interest to one or more specific events and the ES is responsible for dispatching registered events to interested policy subjects. As a key feature, the ES is designed to take into account the mobility of CCs in order to notify events to interested CCs even in case of migration.