4.2.2 Functional Model

In figure , the functional model of the supporting processes used in the remainder of this thesis is depicted in OMT^4.1 style notation [RBP$^$ 91]. It focuses on the processing of policy descriptions and policy objects. Other data objects additionally used by the processes, as mentioned in section , are not shown in the figure. It does not show any architecture, nor does it make any assumptions about it. The processes are looked upon as functional units, not as architectural components and may be implemented as separate components. This functional model provides the basis for the enhanced policy life cycle which will be introduced in section .

Figure: Functional model of the supporting processes

Figure  shows two types of policy data stores, a policy repository and a local policy repository. In the first one, all existing policies are stored. It serves as a global policy library and will be used by the refinement process, the delegation process, and distribution process. Not considered here, although necessary, is a mechanism to query and retrieve a policy by certain keys or characteristics, e.g., security policies, domain specific policies, etc.

The other type of policy stores contains policies in an enforceable representation and is used by the enforcement process and the test process. They are local, i.e., near the enforcement processes, because potentially the managed objects are widely distributed. Therefore, the enforcement processes and test processes are created close to the managed objects. Another reason for having them is that certain enforcement processes need a different policy representation. Such respresentation may be generated during the distribution process and stored at a local policy repository for these enforcement processes.

The grey area enclosed by the broken line depicts the processes and data stores involved in the integration of the policies.

Processes and constraints which would be involved in policy interchanges are not considered, because little is known about them. Exchanging policies over policy domain boundaries will add additional complexity as it will require a unification, or translation of the entities the policies use. This is necessary, because there will be no assurance that the entities exist, or that they are organised in the same structure as in the initial domain for which the policy was created. Another aspect adding complexity is the possibility of multi-domain conflicts, which are conflicts resulting of the integration of a policy from a ``foreign'' policy domain.

In the following subsections each supporting process is described in more detail.