Figure 1P-11 - Simple PolicySet

Both a PolicyGroup as well as a PolicyRule can act as intelligent containers. Therefore, the model abstracts this common capability and generalizes this into a common superclass, called PolicySet. A PolicySet can therefore be used to define common semantics for PolicyRules and PolicyGroups. <br/>The name “PolicySet” is kept to ensure backward compatibility with the IETF model (RFC 3060 and those derived from it). A PolicySet is a type of collection class. This makes sense, since PolicyRules and PolicyGroups are also collection classes. Specifically, a PolicyRule collects PolicyEvents, PolicyConditions, and PolicyActions, while a PolicyGroup collects PolicyRules and PolicyGroups. Thus, a PolicySet can capture the common semantics (attributes, methods, relationships, and constraints) for policy collection classes. <br/>Note that the composite pattern is not used. This is because the entities shown in Figure below are each collection, and therefore naturally have the ability to aggregate information.<br/>Instead, what is important about these classes is their ability to form nested relationships (i.e., a PolicyRule within a PolicyRule as well as a PolicyGroup within a PolicyRule). There are important semantics that come into play, especially in the field of networking, that mandate the ability to have a set of nested PolicyRules (e.g., a rule: sub-rule relationship) as well as the ability to have a group of PolicyRules execute within the context of another PolicyRule. Similarly, one can have a PolicyGroup contain another PolicyGroup (thereby forming a hierarchical group of containers) as well as a PolicyGroup contain a PolicyRule. Thus, instead of the standard composite pattern, the pattern shown in following Figure is used instead. This pattern will be repeated for other structures, including PolicyConditions and PolicyActions.<br/>