6.3.3 Metapolicy Examples

In this subsection, examples of metapolicies and their structure are presented. Their enforcement guides the presentation of the enhancements of the NoCScontrol system.

Table  shows three passive metapolicies. The first one is taken from table , the second and third are taken from table . They were explained in detail in subsection  and in subsection .

Table 6.4: Passive metapolicy examples enforced by the Metapolicy Service Mobile Agent

The policies have the following structure:

• Each constraint for a policy appears on a separate line.

• Each line begins with a textual event identifier in the form described in  [Radi 98]. The event name follows a `:' and one body entry name of the event and a `='. After that, a real value or a `*' must be given. Next, a space follows as a separator. This specifies the triggering event used here to decide whether the passive metapolicy must be considered.

• The triggering event is followed by a valid constraint expression which can be processed by the Constraint Interpreter. In the constraint, a state of an object in the Object State Database is compared to a given value. Or, in the case of the Action Event Database values of action events can be used. Values in the constraint are referenced by the database name followed by a `:' and a reference key.

  In case of the Object State Database the `:' is followed by an object reference or a `*' as the reference key. In case of the Event Database, a triggering event, a `:' and one event body entry must be given. This references the first value. Then a `=' is specified followed by a real value or a second reference of a value. In case the reference key is omitted and only an event body is specified, the event body of the triggering event is used. The asterisk matches any value.

• All constraints for one triggering event are combined together by a logical AND. The metapolicy grants an action when all combined constraints evaluate to true. Therefore, the constraints must be stated in an appropriate form.

The first line of table  reads as follows: Add the constraint that `` PolicyX and PolicyY are not together enforced on the same target as'' to the constraint of granting PolicyX. The line next to the last is similar and may be read as: Add the constraint ``no enforcement of policies which are for nomadic systems in the domain NT'' to all policies. This shows that the `*' matches all policies. The last one specifies: ``No enforcement of policies with are in the state to_review.''

The first two lines are the refinement of one policy and both lines are necessary, because during the enforcement of a policy the metapolicy is retrieved by its policy name. The metapolicy is symmetric, therefore only PolicyX is exchanged by PolicyY.

Table 6.5: Active metapolicy example in PDL

The metapolicy in figure  is an active metapolicy. It is conforming to the PDL of the NoCScontrol system. As opposed to a normal policy, the subject is the Metapolicy Service Mobile Agent but could be any other management agent. It need not be a nomadic system. No new keyword such as METAPOLICY instead of POLICY was introduced to allow for reusing of the complete Policy Factory Mobile Agent without any modifications concerning the policy processing. Instead, the policy name is prefixed by MetaPolicy_.

The policy could be one of the policies resulting from refinement of the third metapolicy in figure . It says: When the action setOperPolDescription is executed by the PolicyFactoryMobileAgent on a policy, memorise the state of this policy as modified and as to_review.

In the next subsection, it is shown how these metapolicies are generally enforced.