A Policy-Definition Language and
Prototype Implementation Library for
Policy-based Autonomic Systems
Richard John Anthony
University of Greenwich
[email protected]
Introduction
This work is towards a generic policy toolkit to support the implementation
of autonomic computing systems in which the policies themselves can be
adapted dynamically and automatically.
Clearly identifiable need for powerful, easy to deploy tools to facilitate policybased self-managing behaviours in a very-wide range of application domains.
A generic solution must:
• Be flexible to enable a diverse set of behaviours to be defined;
• Be sufficiently expressive to capture both simple and complex business
logic;
• Support re-use of behaviour to reduce policy development time;
• Be accessible to non autonomics-expert software developers working in a
diverse range of application fields;
• Facilitate integration with legacy applications.
Richard Anthony University of Greenwich ICAC 2006
1
Background
Policies identified as a key concept for implementation of AS
(At least 50% of papers at ICAC 2006 use or advocate policies)
(Current state of policy technology a Key identified shortcoming)
Developed self-config, self-opt Parallel Processing application early 2005
(eventually supported by 5 separate policies, addressing various aspects of
business logic – dynamic adjustment of granularity, resource management etc).
• An exploration exercise
• Policies directly embedded into application
• Policies ranged in complexity and functionality
• Each policy required some common, and some unique features
• Simple self-adaptation achieved in some policies
• Developer time split evenly between:
Business logic and mechanisms, and
Self management / policy aspects
There must be a better way …
Richard Anthony University of Greenwich ICAC 2006
2
Direction
Current policy-based systems can exhibit self-adaptive behaviour by embedding
a policy which itself is static at run-time.
→ Policy changes typically require open-loop adaptation.
This work is concerned with future policy-based systems:
• Able to ‘evolve’ because the policy can adapt itself.
• Embed a suite of policies and use a meta-policy to dynamically select based
on environment / context.
It will be possible for several dimensions of adaptation to occur concurrently:
• Fine-grained policy-static control,
• Medium-grained optimisation achieved through policy self-adaptation,
• Coarse grained behavioural shifts achieved through meta-policy high-level
governance.
Richard Anthony University of Greenwich ICAC 2006
3
Interpretation of the term ‘policy’
• A set of configuration values that parameterise a rule-based decision engine
- in this work referred to as a Template.
• A set of rules that are applied to determine the behaviour of the system
given certain inputs.
Polices thus contain the configuration parameters and the actual decision
rules externally to the embedded mechanism.
Templates and policies are ideal entry-level techniques for embedding
adaptive behaviours into applications.
→ Current schemes usually provide only initiation-time configuration,
i.e. - configuration remains static at run-time, or
- run-time behaviour scoped within pre-set bounds.
Complex systems with wide potential behaviour space do not lend themselves
well to governance by a single policy.
→ Better to have a collection of policies and use a Meta-policy to select.
Richard Anthony University of Greenwich ICAC 2006
4
Current State-of-Practice in Policy-based Autonomics
Three distinct levels of sophistication are found in current approaches:
1. Policy rules are statically embedded. The template configuration is
exposed and can be modified between executions.
2. Policy updates are open-loop. An external entity (usually a human)
identifies, or is alerted to, potential configuration optimisations, which
can be applied between executions.
3. Closed-loop adaptation, where the policy dynamically and automatically
adapts its own rule-base or template settings during execution.
(Few schemes target or achieve this level at present).
Richard Anthony University of Greenwich ICAC 2006
5
Pictographic representation of policy life-cycles found in current practice
(a)
(c)
(b)
P
P
T
M
P
T
(d)
TT
(f)
T
T
P
M
(e)
P
PP
P
Manual configuration
Template configuration
T
P
Policy (rule based)
P
Library of templates
Meta policy
M
Library of policies
Direct configuration / control
Controlled system
Feedback / monitoring / update
State propagation
TT
T
P
PP
Persisted state
Richard Anthony University of Greenwich ICAC 2006
6
Extending the state of the art
The new policy language and library support self-adaptive policy behaviour:
The policy is able to adapt its own behaviour as well as adapting the
controlled system.
This gives rise to a number of envisioned policy-system configurations
beyond current practice.
Richard Anthony University of Greenwich ICAC 2006
7
Advanced policy configurations beyond the current state of practice
(g)
T
M
P
(i)
(h)
T
P
P
T
Manual configuration
T
M
T
P
PP
Policy (rule based)
P
Library of templates
Meta policy
M
Library of policies
(j)
Template configuration
P
PP
Direct configuration / control
Controlled system
Feedback / monitoring / update
State propagation
TT
P
TT
T
P
PP
Persisted state
Richard Anthony University of Greenwich ICAC 2006
8
Differential between existing and proposed approaches (V. generalised)
Manager
State of
Practice ?
Policy
Controlled
component
Manager
MetaPolicy
Proposed /
Targeted
Policy
PolicyPolicy
Controlled
component
Some governance delegated to meta-policy
Richard Anthony University of Greenwich ICAC 2006
9
The Policy Definition Language
Extends the state of the art in policy languages:
Explicit support for dynamic self-adaptation of policies over both short
and long term through persisted configuration changes.
Policy suites, in which a particular type of policy can have many
differently-geared instances (e.g. cautious and aggressive versions).
Suites of templates for a given policy-type allow different initial
configurations to be used, depending on circumstances.
Meta-policies can be used to select amongst many policy-instances
and templates at initiation time.
Meta-policies can automatically ‘hot-swap’ between instances
of the same type of policy at run-time.
Features to support bounded behaviour and enhance stability.
Facilitates policy-object reuse.
Richard Anthony University of Greenwich ICAC 2006
10
Overview of the policy definition language features (1)
Object oriented. Objects represent policies, rules, actions etc.
OO approach facilitates re-use of behaviour, through reusing tested objects.
A polymorphic Variable-type (PolicyObject) facilitates referencing of policy
objects within the policy rules and actions themselves.
Hierarchical support for three levels of ‘policy’:
1. Templates provide configuration parameters which are used to
initialise the other types of policy.
2. Normal policies contain the low-level autonomics logic.
3. Meta-policies provide higher-level adaptation.
A single policy script may contain all three types forms of ‘policy’.
Meta-policies can be used to perform an initial configuration decision, and / or
can operate continuously. In this latter mode, meta-policies support ‘hotswapping’ between normal policy instances.
Richard Anthony University of Greenwich ICAC 2006
11
Overview of the policy definition language features (2)
Reinforces natural semantic differences between:
• Variables that convey external information to the policy,
• Variables used to maintain internal policy state.
External variables cannot be modified, configured in a template, or
persisted. Must be passed into the policy via the library interface each
time the policy is invoked.
Dynamic state represented by internal variables can be persisted to
enable longer-term adaptation.
Separating variables into 2 classes reinforces type-safety and semantic
checking. E.g. an external variable may only occur on the RHS of an
assignment operation.
Template configuration of internal variables supports specification of various
attributes, which include: upper and lower value limits,
increment and decrement amounts.
(Attributes can be dynamically adjusted at run-time)
Policies are formatted in XML which enforces a standard general syntax and
facilitates portability and deployment in heterogeneous systems.
Richard Anthony University of Greenwich ICAC 2006
12
Class Hierarchy
CPolicyObject
CTemplate
strName
Evaluate()
CRule
CPolicy
CAction
CVariable
CInternalVariable
CExternalVariable
Richard Anthony University of Greenwich ICAC 2006
13
Language structure and components (1)
ExternalVariable: Variables that are passed in to the policy at the point of policy
evaluation. These variables represent environmental or contextual conditions.
InternalVariable: Variables used internally by a policy (e.g. counters and flags).
Variables can be of three basic types: Long, Boolean and PolicyObject.
Strong validation is used to ensure correct usage.
Template: A collection of InternalVariable configuration statements that apply
to a particular policy-type.
ReturnValue: Named Numerical return codes for use within the policy script.
Action: A grouped sequence of activities.
A particular Action may occur when a Rule evaluates to either true or false,
or when a ToleranceRangeCheck evaluates to either in-zone or not-in-zone.
Rule: A statement that evaluates to either true or false.
Rules have separate Actions for the evaluate true and evaluate false cases.
Richard Anthony University of Greenwich ICAC 2006
14
Language structure and components (2)
ToleranceRangeCheck: A specialized rule that is used to implement fuzzy
variable comparison, as well as dead-zones. Separate Actions can be
specified for the In-Zone and Not-in-Zone evaluation cases.
Policy: A sequence of Rules and ToleranceRangeChecks that implement the
self-management business logic.
MetaPolicy (special case of Policy): A sequence of Rules and
ToleranceRangeChecks that can be used to dynamically select the current
policy and template configuration.
PolicySuite: A collection of Policies of the same ‘type’ (i.e. concerned with a
certain aspect of business logic).
Richard Anthony University of Greenwich ICAC 2006
15
The Policy Library
Easy integration with legacy code:
Provides internal support for many powerful language-support features.
Clear demarcation between internally managed and externally maintained
aspects of policy behaviour.
Supports use by non-autonomics-experts:
Simplifies mapping of business logic into policy specifications, through
features such as:
• Powerful library-internal validation and semantic checking,
• Distinction between internal and external variables,
• Automatic restriction of low-level adaptation within higher-level
expressed bounds,
• Silent conflict / violation handling.
Generic applicability to a wide range of problem domains:
Flexible methods for defining application-to-policy interface objects such as
ExternalVariables and ReturnValues in programming-language-neutral ways.
Richard Anthony University of Greenwich ICAC 2006
16
Case Example 1: Self-optimisation in parallel processing
Conforms to configuration (f) in the policy taxonomy.
This example is one of several policies deployed in an exploratory
self-managing parallel processing application.
This particular policy dynamically optimises Round-Trip Time (RTT)
measurement activity (as part of the embedded discovery and dynamic
optimisation capabilities).
The optimisation is in terms of achieving a balance between saving network
bandwidth and processing by cutting out some calibration messages, and yet
performing sufficient measurements to keep track of the variability of
communication latency between components.
Richard Anthony University of Greenwich ICAC 2006
17
Policies operate at several logical levels
Business-level policy
(expression of user intent)
“Optimise costs of calibration”,
“I don’t care whether a specific calibration event is skipped or not”,
“No more than 5 consecutive calibration measurements should be skipped”
System-Level policy
(lower-level behaviour rules)
Attribute values govern manipulation of specific variables, e.g.
Variable: CalibrateInterval
Attributes: InitialValue="1" MaxValue="5" IncrementAmount="1“ …
One object (such as a variable) can directly impact the evaluation of another
object (such as a rule) – obvious case.
But also (for example) a rule can impact the manipulation of a variable by
changing its attributes
Richard Anthony University of Greenwich ICAC 2006
18
Case Example 1: Self-optimisation in parallel processing (Outline operation)
A variable that governs the current number of calibration messages that can
be skipped (the soft limit) is initialised to 1, and has a MaxValue attribute set to
5 (the hard limit).
The policy keeps track of variability in RTT measurements, allowing
calibrations to be skipped when the communication latency is stable.
During prolonged periods of stability the policy gradually ramps up the soft limit
value – until eventually it reaches the hard limit.
Further increment requests can be made, but the library mechanisms ignore
any requests that violate the variable’s attribute settings.
When the communication latency becomes more volatile the soft limit is
dropped back to its initial value.
Summary:
One set of rules maintain configuration parameters that govern
the behaviour of other rules.
Richard Anthony University of Greenwich ICAC 2006
19
The RTT policy Script (abridged) Part 1
<!-- Policy Definition XML file: Policy Language version 1.0 -->
<!-- Application: Self-Management in Cooperative Distributed Problem Solving -->
<PolicyConfiguration> <!-- PolicyTypeName=RTT Measurement Policy -->
<EnvironmentVariables> <Variable Name="E_iCurrentSample" Type="long"/> </EnvironmentVariables>
<InternalVariables>
<Variable Name="I_iCalibrateInterval" Type="long"/>
<Variable Name="I_iSimilarSampleCountThreshold" Type="long"/>
</InternalVariables>
Soft Limit
<Templates>
<Template Name="DefaultTemplate">
<Assign Variable="I_iCalibrateInterval" InitialValue="1" MinValueValid="true" MinValue="1"
MaxValueValid="true" MaxValue="5" IncrementAmount="1"/>
<Assign Variable="I_iSimilarSampleCountThreshold" InitialValue="3“ MinValueValid="true"
MinValue="1" MaxValueValid="false" MaxValue="0“ IncrementAmount="1"/>
</Template>
Hard Limit
</Templates>
<ReturnValues> <ReturnValue Name="YES_Forced" Value="1"/>
</ReturnValues>
<Actions>
<Action Name="A_ContinueAfterInterval">
<Increment Variable="I_iCalibrateInterval"/>
<Assign Variable="I_bCanSkipCalibrationUnlessIntervalReached" Value="true"/>
<Assign Variable="I_iSkippedCount" Value="0"/>
Externally
<Assign Variable="I_iPrevSample" Value="E_iCurrentSample"/>
configured
<Return ReturnValue="NO_Stable"/>
</Action>
values
</Actions>
Richard Anthony University of Greenwich ICAC 2006
20
The RTT policy Script (abridged) Part 2
<Rules>
<Rule Name="R_ContinueAfterInterval" LHS="I_bStable_CanSkipAfterCalibrateInterval“
Operator="EQ" RHS="true" ActionIfTrue="A_ContinueAfterInterval" ElseAction="Null"/>
<Rule Name="R_SkipIntervalReached" LHS="I_iSkippedCount" Operator="LT"
RHS="I_iCalibrateInterval" ActionIfTrue="A_CanSkipCalibration"
ElseAction="A_MustPerformIntervalCalibration"/>
</Rules>
<ToleranceRangeChecks>
<ToleranceRangeCheck Name="C_CurrentSampleStable“
CheckVariable="E_iCurrentSample"
CompareAgainstVariable="I_iPrevSample"
ToleranceRangePercentSpecifier="I_iSampleTolerancePercent"
ActionIfInZone="A_CurrentSampleStable"
ActionIfOutsideZone="A_CurrentSampleNotStable"/>
</ToleranceRangeChecks>
<Policies>
<Policy Name="DefaultPolicy" PolicyType="NormalPolicy">
<Initialise CurrentTemplate="DefaultTemplate"/>
<Evaluate Rule="R_OptimisationAllowed"/>
<Evaluate Rule="R_CanSkipCalibrationUnlessIntervalReached"/>
<Evaluate ToleranceRangeCheck="C_CurrentSampleStable"/>
<Evaluate Rule="R_ContinueAfterInterval"/>
<Evaluate Rule="R_SameCountSufficient"/>
</Policy>
</Policies>
</PolicyConfiguration>
Externally
configured
values
Richard Anthony University of Greenwich ICAC 2006
21
Sample results: the RTT policy in action
RTT Current Sample
RTT variability (moving average)
'Calibrate Interval' threshold
180
5
4
RTT measurements (mS)
140
120
3
100
80
2
60
40
1
'Calibrate Interval' threshold value
160
20
0
0
0
50
100
150
200
Sample number
250
300
350
Richard Anthony University of Greenwich ICAC 2006
22
Case Example 2: A multi-policy stock trading scheme (1)
Conforms to configuration (i) in the policy taxonomy
(beyond current state of practice).
This example illustrates the use of meta-policies and the advantage of
dynamic switching between instances of business policies.
The stock system is representative of many real-world problems that have:
Highly complex behaviour,
Sensitivity to several sources of environmental volatility,
Non-linear sensitivity to some environmental parameters,
Many dimensions of freedom.
For a system with any of these characteristics, it is not realistic to closely track
the system over its entire behaviour range with a single policy.
Richard Anthony University of Greenwich ICAC 2006
23
Case Example 2: A multi-policy stock trading scheme (2)
Trading decisions are subject to influences such as price behaviour trends,
the rate of change in traded volumes and the rate of change in price, etc.
A single, generalised (and thus coarse) policy could lead to significant
sub-optimality across a wide spectrum of behaviours.
One solution is to divide the application behaviour space into several zones.
Each zone requires a stock-price-based trading strategy, contextualised by
a given range of rate of change in traded volumes and in price.
Rate of
Price
change
Zone # 2
Zone # 4
Zone # 1
Zone # 3
Rate of Volume Traded change
The policies have different configuration but are of the same ‘type’ since they
address the same business decision (but arrive at their decisions differently).
Richard Anthony University of Greenwich ICAC 2006
24
Case Example 2: A multi-policy stock trading scheme (3)
Each policy is configured such that its operational envelope
(that over which it guarantees safe and desirable behaviour)
is tuned to map closely onto its ‘zone’.
A self-adaptive policy may adjust its own thresholds over time,
or these might be supplied externally.
Price
Policy
maintained
thresholds
Policy
Time
Richard Anthony University of Greenwich ICAC 2006
25
Case Example 2: A multi-policy stock trading scheme (4)
Individual policies need not be aware of the delimitation of their zones.
A MetaPolicy is employed to select between the different business policies.
The MetaPolicy monitors the behaviour of the target system and determines
which policy should be employed at any given moment.
Meta
Policy
Policy
maintained
thresholds
Price
Policy
Time
Richard Anthony University of Greenwich ICAC 2006
26
Case Example 2: A multi-policy stock trading scheme (5)
There is a risk of instability if simple cut-off points are used to determine the
policy selection.
If the behaviour of the monitored system is close to one of the cut-offs there is
a possibility that the policies will be switched to and fro, causing extra work for
the system.
The ToleranceRangeCheck language object facilitates easy configuration of
dead-zones, enhancing stability (localised oscillatory behaviour in the target
system is not mirrored in the behaviour of the MetaPolicy).
Volume rate-change dead-zone
Rate of
‘Price’
change
Policy # 2
Policy # 4
Policy # 1
Policy # 3
Price
rate-change
dead-zone
Rate of ‘Volume Traded’ change
Richard Anthony University of Greenwich ICAC 2006
27
The stock-trading multi-policy script (abridged) Part 1
<PolicyConfiguration> <!-- PolicyTypeName= Stock-Trading Policy -->
<EnvironmentVariables>
<Variable Name="E_iCurrentPriceRateChange" Type="long"/>
<Variable Name="E_iCurrentVolumeRateChange" Type="long"/>
</EnvironmentVariables>
<InternalVariables>
<Variable Name="I_iPriceRateChangeDeadZone" Type="long"/>
<Variable Name="I_iVolumeRateChangeDeadZone" Type="long"/>
<Variable Name="I_iDeadZoneTolerancePercent" Type="long"/>
</InternalVariables>
<Templates>
<Template Name="MetaTemplate">
<Assign Variable="I_pCurrentPolicy" InitialValue="Policy1"/>
<Assign Variable="I_iPriceRateChangeDeadZone" InitialValue="60"/>
<Assign Variable="I_iVolumeRateChangeDeadZone" InitialValue="50"/>
<Assign Variable="I_iDeadZoneTolerancePercent" InitialValue="10"/>
</Template>
</Templates>
<ReturnValues>
</ReturnValues>
<Actions>
<Action Name="A_DeterminePolicyBasedOnPriceRateChange">
<Evaluate Rule="R_CurrentPriceRateChange"/>
</Action>
<Action Name="A_DeterminePolicyBasedOnVolumeRateChange">
<Evaluate Rule="R_CurrentVolumeRateChange"/>
</Action>
</Actions>
Externally
configured
values
Richard Anthony University of Greenwich ICAC 2006
28
The stock-trading multi-policy script (abridged) Part 2
<Rules>
<Rule Name="R_CurrentPriceRateChange" LHS="E_iCurrentPriceRateChange" Operator="LT"
RHS="I_iPriceRateChangeDeadZone" ActionIfTrue="A_SelectLowPriceRateChangePolicy"
ElseAction="A_SelectHighPriceRateChangePolicy"/>
</Rules>
<ToleranceRangeChecks>
<ToleranceRangeCheck Name="C_PriceRateChangeDeadZone"
CheckVariable="E_iCurrentPriceRateChange"
CompareAgainstVariable="I_iPriceRateChangeDeadZone"
ToleranceRangePercentSpecifier="I_iDeadZoneTolerancePercent" ActionIfInZone="Null"
ActionIfOutsideZone="A_DeterminePolicyBasedOnPriceRateChange"/>
</ToleranceRangeChecks>
<Policies>
Externally
<Policy Name="Meta_Policy" PolicyType="MetaPolicy">
configured
<Initialise CurrentTemplate="MetaTemplate"/>
values
<Evaluate ToleranceRangeCheck="C_PriceRateChangeDeadZone"/>
<Evaluate ToleranceRangeCheck="C_VolumeRateChangeDeadZone"/>
</Policy>
<Policy Name="Policy1" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy>
<Policy Name="Policy2" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy>
<Policy Name="Policy3" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy>
<Policy Name="Policy4" PolicyType="NormalPolicy"> <!-- Detail omitted --> </Policy>
</Policies>
</PolicyConfiguration>
Richard Anthony University of Greenwich ICAC 2006
29
Conclusion
Meta-policies represent a meta-state transition in policy computing; bringing
greater flexibility and a hierarchical aspect that helps control complexity.
The policy language supports several dimensions of adaptability:
- Low-level changes enforced by a particular policy;
- Dynamic adjustments to internal state variables (e.g. including the
parameters that define the position and width of dead-zones).
- Automatic switching of policies to ensure that the current policy
always remains within its optimal operational envelope;
- Longer-term adaptation by dynamically updating template
configurations and persisting their state.
The direct support for dead-zones enables stability despite a potentially high
extent of adaptability.
The library mechanisms automatically enforce adherence to constraints
such as maximum value for a given variable (these attributes are
themselves dynamically re-configurable).
The library facilitates integration into legacy code - many applications in
current use need self-management, without complete re-development.
Richard Anthony University of Greenwich ICAC 2006
30
(Lots of) Further work
Further development of language specification
• Support for utility functions (CUtility) and fuzzy comparisons are planned,
• Richer attribute sets on objects.
Further development of library and interface
• Flexible persistence support,
• Internal logging / trace facility,
• An instrumentation interface for external monitoring.
Development of a suite of demonstrator / validator applications
Richard Anthony University of Greenwich ICAC 2006
31