Figure 1P-09 - PolicyRule

Like all SID entities, PolicyRules are built from PolicyRuleSpecifications (called PolicyRuleSpec in the model). A PolicyRuleSpec acts as a mechanism to specify the invariant (i.e., non-changeable) features and behavior that makes up a Policy. Thus, all PolicyRules use the attributes, methods, constraints, and relationships that are contained in the PolicyRuleSpec from which they are derived. A PolicyRuleSpec has two important attributes that all PolicyRules have, called executionStrategy and sequencedActions.<br/>The executionStrategy attribute is an enumerated integer that defines the strategy to be used when executing the sequenced actions aggregated by this PolicyRule. Defined execution strategies include:<br/>        • 1:  Do Until Success<br/>        • 2:  Do All<br/>        • 3:  Do Until Failure<br/>        • 4:  Do All Without Failure or Do Nothing<br/>“Do Until Success” means that actions should be executed according to their predefined priority, until successful execution of a single action. At that point, the process should stop (even if there are additional actions that could be executed).<br/>“Do All” means that all actions should be executed that are part of the set, according to their predefined priority. This should continue, even if one or more of the actions fails.<br/>“Do Until Failure” means that all actions should be executed according to their predefined priority until an action fails to execute. At that point, the entire sequence should be stopped.<br/>Finally, “Do All Without Failure or Do Nothing” means that all actions specified should be performed. However, if a failure occurs, then NONE of the actions should be performed. This implies EITHER the ability to look-ahead and ensure that the actions will be able to be performed successfully, or the ability to perform a rollback of that action and all previous actions in the PolicyRule when an error is encountered.<br/>The sequencedActions attribute is an enumerated integer that defines how the ordering of the PolicyActions associated with this PolicyRule is to be interpreted. Values include:<br/>        • 1: Mandatory<br/>        • 2:  Recommended<br/>        • 3:  Best Effort<br/>Mandatory means that the actions must be done in the indicated order, or else don’t do them at all. Recommended means that the actions should be done in the indicated order if possible; if this is not possible, then it is permissible for them to be done in another order. Best effort means that the actions should be done irrespective of whether they can be done in the specified order.<br/>The combination of the executionStrategy and the sequencedActions attributes enables the behavior of PolicyActions to be specified. Note that this is a special case, compared to how PolicyConditions and PolicyEvents are handled. From the perspective of the PolicyRule, a single clause (i.e., a set of expressions) is used to represent conditions as well as events. For the case of the PolicyCondition, the PolicyRule need only check to see if the condition clause evaluated to TRUE – if it evaluated to FALSE, then no action need be taken . For the case of the PolicyEvent, the PolicyRule sees a trigger to start the evaluation of its condition clause. It usually doesn’t care which event or how many events triggered the evaluation of the condition – it simply cares that something happened and now a check needs to be made to see if this PolicyRule is applicable or not.<br/>There are three other important attributes of a PolicyRuleSpec. These are the policyEventSelectCriteria, policyConditionSelectCriteria, and policyActionSelectCriteria attributes. These attributes contain OCL expressions to prescribe any limitations on the types of PolicyEvents, PolicyConditions, and PolicyActions that can be used with any PolicyRules that are derived from this particular PolicyRuleSpec. This enables a PolicyRuleSpec to be built that defines what types of PolicyEvents, PolicyConditions, and PolicyActions can be used to build a particular set of PolicyRules. This in turn ensures that a given set of PolicyRules carry standard functionality. (Nothing further will be said about these three attributes, as they come into play more in the system view).<br/>Conceptually, Figure below shows a more detailed view of the PolicyRuleSpec and PolicyRule.<br/>The PolicyRule entity itself is therefore very simple. It defines two attributes, isCNF and hasSubRules. PolicyConditions can be represented in two different forms, called Conjunctive Normal Form (an AND of Ors) and Disjunctive Normal Form (an OR of ANDs). The isCNF attribute defines which one of these forms the PolicyCondition clause is to be represented in.<br/>The hasSubRules attribute is for querying convenience. As we will soon see, a PolicyRule can contain other PolicyRules. Nested PolicyRules have slightly different evaluation and action execution semantics. This attribute enables the user of a PolicyRule to quickly determine if this is a simple PolicyRule, or if this PolicyRule has nested PolicyRules.<br/>The PolicyRuleSpec was built so that external entities, such as Policy Servers, could build a particular type of PolicyRule dynamically. To see how this works, imagine that a set of Policy components, including one or more PolicyConditions, PolicyActions, and PolicyEvents, exist in a PolicyRepository. Now, given a PolicyRuleSpec, a PolicyRule can be built dynamically that has the exact behavior that is desired by using the three criteria attributes of the PolicyRuleSpec (i.e., policyActionSelectCriteria, policyConditionSelectCriteria, and policyEventSelectCriteria).<br/>