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.
In case of problems, or if you find any bug, please contact us.