The system manager is the component that decides when adaptation actions should be invoked according to the changes reported by the application managers. As it was dis- cussed in section 4.3, the system manager is based on a policy management system where adaptation policies are expressed through a policy language. In the following sections an overview of prevalent policy specification languages is presented. Follow- ing this background section, a discussion about the design of the system manager as a policy management component is given.
4.6.1
Background
Policy Management systems have been widely used in the areas of network and system management. In the following section two popular policy languages that were designed
as general purpose policy language are presented.
4.6.1.1 Ponder
The Ponder policy language [Damianou01], developed at Imperial College London, is a declarative, object-oriented language for specifying security and management poli- cies for distributed object systems. It defines a set policy classes with different charac- teristics. Specifically Ponder provides authorisation, delegation, information filtering,
refrain and obligation policies.
The general assumptions for all policies in Ponder is that they all refer to objects with interfaces defined in terms of methods using an interface definition language. The model assumed by Ponder includes subject objects (users, principals or automated man- ager components) that have management responsibility and target objects (resources or service providers) that are accessed by the subjects. Domains provide a means of group- ing objects to which policies apply and can be used to partition the objects in a large system according to geographical boundaries, object type, responsibility and authority or for the convenience of human managers.
Authorisation policies define what activities a subject object can perform on the set of target objects. A positive authorisation policy defines the actions that subjects are permitted to perform on target objects. A negative authorisation policy specifies the actions that subjects are forbidden to perform on target objects.
Information filtering policies define the type of information transformations that should be performed based on the characteristics of the subject object. For example, a location service might only permit access to detailed location information, such as whether a person is in a specific room, to users within the department.
Refrain policies define actions that subject objects must not perform on a subject even if they are actually permitted to perform the action (based on authorisation poli- cies). The main difference between a refrain policy and a negative authorisation policy is that the former are implemented by the subjects themselves rather than a policy manage- ment component. Refrain policies are used for situations where negative authorisation policies are inappropriate because the targets are not trusted to enforce the policies.
Delegation policies are used in order to support the temporary transfer of access control rights from one object to another. These policies are required in order for this
transfer of access rights to be managed by the policy management system.
Obligation policies specify the actions that must be performed by managers within the system when certain events occur and provide the ability to respond to changing conditions. Obligation policies are event-triggered and define the activities subjects must perform on objects in the target domain. Events can be simple, i.e. an internal timer event, or an external event notified by monitoring service components.
In addition to this set of policies the Ponder policy language defines policy con- straints: a set of conditions that specify which policies are valid. These constraints can either be basic policy constraints that apply to specific policies or meta-policies that apply to a group of policies.
With this extensive set of policy types Ponder can support a wide range of man- agement and security systems. Concrete examples have been presented for the use of Ponder in distributed network management, storage systems, application and service management and enterprise-wide security polices [Lupu99].
4.6.1.2 PDL
The PDL (Policy Description Language) is a domain independent declarative policy language [Lobo99, Chomicki00]. In PDL there are no assumptions about the underlying system that should be managed by the specified policies. The policy rules defined in PDL follow the event-condition-action scheme:
event causes action if condition
Intuitively a rule of this form says that if the event occurs at a time when the condi-
tion is true the action should be performed.
PDL consists of three basic classes of symbols: primitive event symbols, action symbols and function symbols. The primitive event symbols include system defined event symbols and user defined event symbols. Action and function symbols are pre- defined and are given to the user that defines the policies.
The aforementioned classes of symbols can be better described by example [Lobo99]: consider the case of an Internet provider that has a pool of modems that accept dial-up
connections. In this example the internet provider wants to limit the number of simul- taneous connections for a specific customer (i.e. with the phone number 5559991) to 5 connections during the night. The event that should be monitored for such a policy is time. A symbol called CoarseTimeEvent is associated with this event. This partic- ular symbol is defined to have an attribute Time with the enumerated type “morning”, “noon”, “evening”, “midnight”. The policy rule in PDL that implements such a policy is:
CoarseTimeEvent
causes ModemPoolAssignment(5559991, 5) if (CoarseTimeEvent.Time = “morning”)
PDL also defines how simple events can be combined through logical expressions of the form e1&e2&. . .&en or e1|e2|. . .|en to define composite events that should or should not take place at the same time. PDL does not specify how events or actions should be defined. These are considered to be system dependent features.
4.6.2
Policy Manager
As discussed in section 4.3 the system manager is the component that evaluates adapta- tion policies and triggers adaptation when required. Here a policy manager component, realising the functionality of the system manager is presented.
The policy manager is the component responsible for deciding when adaptation is required using a set of adaptation policy rules. In more detail, the decision mechanism is driven by a set of policy rules including the default policies installed by the applications (possibly modified by the user) and any new policy rules defined by the user.
Specifically, when an application is installed on the system a set of default policies are added to the policy repository. These policies are parsed by the policy manager and are used for handling adaptation for the running applications. The policy repository is always available to the current user for modifications and addition of new rules. This way the active set of policy rules can be modified by the user to meet their personal needs.
The evaluation of policy rules is driven by events delivered by the event manager. Each of these events is related to the values of the state variables of the running appli- cations (Section 4.7.3).
In order to identify the policy language that best satisfies the requirements of this platform it is necessary to further analyse the specifics of this platform and identify the features of the policy language that should be used. Specifically, the policy language that will be used should satisfy the following requirements:
1. The policy language should be able to operate in an event-driven environment. The input given to the system manager is the set of state variables reported by applications. As described in section 4.4.3, as the values of these state variables change, the corresponding applications fire events that notify the platform about their new values.
2. The platform is required to handle the conditions under which an adaptive reac- tion should take place in a uniform manner, irrespective of the type of adaptation. More specifically, the decision mechanism should be a general purpose mecha- nism that will handle adaptation policies relating to a variety of adaptation types such as network based adaptation or physical context related adaptation.
3. The specification of policy rules should be flexible enough to allow the specifi- cation of fine grained temporal relationships between events. In most cases con- flicts or instabilities in adaptive systems occur due to time dependencies between changes that take place or the time between adaptive mechanisms being invoked. The policy language should allow the fine tuning of adaptation mechanisms to allow the resolution of such types of conflicts.
Section 4.7.1 discusses the applicability of existing policy languages with respect to these requirements and section 4.7.3 proposes a new language based on the Event Calculus logic programming formalism.