Figure 1P-13 - Common Evaluation Semantics for PolicyGroups and PolicyRules

Prioritization among policy rules provides a basic mechanism for resolving policy conflicts.<br/>Common behavior for PolicyGroups and PolicyRules (in this view, this is shown as common attributes; in the system view, it includes other common artifacts) is defined using a PolicySet. One of the most important common behaviors that is defined for a PolicySet is its ability to treat PolicyRules and PolicyGroups in a common way when evaluating a decision tree.<br/>For example, Figure below shows an example where nodes are made up of both PolicyGroups as well as PolicyRules<br/><font color="#29313b">The figure shows three hierarchies of PolicySets. The first hierarchy consists of PolicyRuleA, PolicyGroup1, PolicyGroup2, and PolicyRuleB. The second hierarchy consists of PolicyRule1-1, PolicyRule1-2, PolicyGroup1A, and PolicyRule2-1. The third hierarchy consists of PolicyRule1A-1.</font><br/><font color="#29313b">PolicySets are evaluated in hierarchies, with the highest priority (e.g., the PolicySet that is most important to the business, or the PolicySet that should be executed in the event of a conflict) being executed first. In other words, the absolute priority of a given Policyset isn’t important initially – we instead look at the priorities of the PolicySets at the same level in the hierarchy. Therefore, in our first hierarchy, the execution order is PolicyRuleA, PolicyGroup1, PolicyRuleB, and PolicyGroup2, because they are all at the same hierarchy, and their priorities are 10, 7, 5, and 3, respectively.</font><br/><font color="#29313b">PolicyRuleA will execute first. Next in priority is PolicyGroup1. Since it is a PolicyGroup, we must stop and look into its contents to figure out what should be executed in what order, since a PolicyGroup can’t be executed by itself. Note that the contents of PolicyGroup1 will all execute before the contents of PolicyGroup2 or PolicyRuleB, even though PolicyGroup2 and PolicyRuleB are both on the first level of the policy hierarchy.</font><br/><font color="#29313b">Looking at the contents of PolicyGroup1, we see that the execution order is PolicyRule1-2, PolicyGroup1A, and PolicyRule1-1. Note that PolicyRule2-1 wasn’t considered. This is because although it is at the second level of the hierarchy, it is contained within a PolicyGroup whose priority was lower than that of the PolicyGroup that we are currently evaluating. Since PolicyGroup1A is a group, its contents will be executed before PolicyRule1-2 is executed. This effectively moves the execution of PolicyRule1A-1 between PolicyRule1-2 and PolicyRule1-1.</font><br/><font color="#29313b">Finally, PolicyRuleB will execute, followed by PolicyGroup2, which means that PolicyRule2-1 will be the last to execute.</font><br/><font color="#29313b">This example shows the following key points:</font><br/><ul>
<li><font color="#29313b">Grouping compares the priority of PolicySets at the same level</font></li><li><font color="#29313b">Whenever a new hierarchy is entered through a PolicyGroup, its PolicySets are compared with each other at that level of the hierarchy, before further evaluation of the previous hierarchy is continued</font></li><li><font color="#29313b">The absolute priority of a PolicySet has nothing to do with its final execution order – it only serves to determine when it will be executed with respect to other PolicySets of its same hierarchy level. PolicySets do not have associated specifications, since they are abstract containers, and serve only to facilitate the grouping of PolicyRules and PolicyGroups.</font></li></ul>
<font color="#29313b">It is important to note that the semantics of a PolicyRule in a PolicyGroup are different than those of a PolicyRule in a PolicyRule. However, this is beyond the scope of a business view. The business reader should realize, however, that this model is very generic, and can support any type of execution strategy desired.</font><br/>