4.3 Enhanced Policy Life Cycle

As can be seen in chapter  by looking at the examples of the different policy approaches, each policy passes a number of similar steps. In section , the processes which take part in these steps were generally described. Different policy approaches handle some of the functionality of the supporting processes in a different fashion, or a policy-based management system may simply omit some, such as the test process when it is not possible to integrate it. A policy life cycle is, therefore, restricted by the management system.

Because of these reasons, an enhanced policy life cycle is presented here. It can be seen as best practice for a policy-based management system, and it is not contrary to any of the previously presented policy approaches. It shows the steps when a policy is created, modified, transformed, enforced, etc.

The enhanced policy life cycle considers all the aspects of the previously presented life cycles, and introduces new aspects such as testing and conflicts, showing all possible transitions from a state, and which processes are related to these states.

In the following we give an overview of the enhanced policy life cycle as shown in figure :

Figure: The enhanced policy life cycle

refinement

In this phase, the initial high-level policy describing the principle is already formulated. With this description, a decision must be made with respect to two areas: to whom the policy will be delegated for refinement, and what aspects of the policy are to be refined.

Even after a policy has passed this refinement state, it may return to this state from any other state because of testing problems or enforcement failures, or for the purpose of auditing. For reasons of clarity, these edges have been omitted in the graph.

When the refinement process is finished, the high-level policy should be deployable as a set of low level policies.

deployable

The policy is fully refined and ready to use in this state. All objects in the policy can be mapped to the management system. As mentioned in subsection , some modifications, or customising for the policy destination may be made by the distribution process, but these changes must not change the semantics of the deployable policies.

The policies, therefore, can be distributed and, when they arrive at their destination, enforced. The policies in the entire refinement process are stored in a repository for the purpose of reuse and review, and would be retained until explicitly deleted. The next step is to integrate the policy, i.e. its low-level policies, into the system.

distributed

For integration purposes, policies are distributed and stored in the local policy repository. During the distribution process, the destination systems are selected for each policy. The process is finished after the whole set of low level policies refined from a high-level policy is distributed and stored in an appropriate repository. The distribution process has to be completed before entering the test phase because with potential dependencies between policies, each policy will be required to be in place in order to be tested.

tested

The distributed policies are tested to show their conformity with the initial intention as far as possible. This is done at this phase of the life cycle, where the system has access to the real world and can instantiate objects in the policy description and simulate them in a running system. The testing process depends on the policy; i.e., different policies can have different testing processes, which themselves can vary because of different environments/contexts in which the policies are enforced. Here, conflicts or other run time constraints, which lead to unwanted behaviour, can be discovered through simulating the enforcement of the policy. Activation and deactivation strategies are also tested, to detect possible problems in the integration process. These problems force one or more policies to return to the refinement state where the problems must be resolved. Otherwise, the test ends and the policy becomes ``ready'', or inactive.

inactive

In this state, a policy is inactive, meaning it is integrated in the system and has no effect on the system, but is ready to become active through the activation process or to be removed from this particular system. A policy in this state has already been distributed to a hosting system, so the removal of a policy affects only this system and does not necessarily mean that the policy is deleted from the whole management system.

active

Having activated the policy enables the system to enforce the policy, when there is an event which concerns the policy.

enforcement

At this step the policy is finally enforced triggered by an appropriate event. Normally, after enforcement the policy goes back the active state again. If a conflict with another policy occurs, or an unforeseen exception happens, the policy will have to go the refinement state in which to get the problem resolved.

Review of policies is possible in and from every state. This is not shown in the diagram for the purpose of clarity. Reviewing as part of the refinement and delegation processes is in most cases a parallel process to the normal states in the life cycle. Actions initiated by the review need to conform with the policy life cycle. When a review leads to the conclusion that a policy has to change, then necessary actions are taken.

For example, if a new policy instance is created incorporating the changes made, then it must be (re)distributed. Even when only minor alterations are made, the policy must pass through all states in the life cycle to ensure its orderly (re)integration. On the other side, all instances of the previous version of the policy should be deactivated and then removed from all systems.