Policies are the Event Condition Action rules of the Ponder2 system. An obligation policy is a Managed Object that is instantiated and given the event it should be expecting, zero or more conditions to be evaluated and one or more actions to be performed if the conditions are satisfied.
Obligation policies are created from the Event, Condition, Action policy factory:
1 newPolicy := root/factory/ecapolicy create.
Once created, the policy must be given the information it needs to perform its function. We have to give the policy the Event Template we want it to respond to and the conditions and actions it must use when an event of that type is generated. Here an event template is created first to be used in the following examples.
1 template := root/factory/event create: #( "monitor" "value" ). 2 root/event at: "monitor" put: template.
This event template may be used by a monitoring system to generate events. Each event will have the monitor name and the value from that monitor as attribute values. Once the event template managed object has been created it can be given to the policy as the expected event type.
1 policy := root/factory/ecapolicy create. 2 policy event: root/event/monitor.
Policies may have zero or more conditions. If it is desired that the policy's actions are to be executed every time hat event occurs then no condition need be specified otherwise conditions are required. Each condition is simply a PonderTalk block that will be executed when the event occurs. The PonderTalk block must return a boolean. If there is more than one condition then all the conditions are executed and the logical AND of all the conditions is taken to be the final result. If the result is true then the action(s) is/are performed. NB. There is no guaranteed order to the execution of multiple conditions, nor whether they are run concurrently nor whether they are all evaluated if one condition returns false. If you are worried about any of these issues then use one more complex condition.
1 policy condition: [ :value | value > 100 ].
1 policy action: [ :monitor :value | root print: "Monitor " + monitor + " has value " + value ].
1 policy active: true.
This probably looks a little better laid out using cascading messages:
1 policy := root/factory/ecapolicy create. 2 policy event: root/event/monitor; 3 condition: [ :value | value > 100 ]; 4 action: [ :monitor :value | 5 root print: "Monitor " + monitor + " has value " + value 6 ]; 7 active: true.
Anatomy of a Policy
A policy, called /policy/testpolicy, that uses testevent can be described as follows:
<use name="/policy"> <add name="testpolicy"> <use name="/template/policy"> <create type="obligation" event="/event/testevent" active="true"> <arg name="colour"/> <arg name="intensity"/> <condition> <and> <eq>!colour;<!-- -->red</eq> <gt>!intensity;<!-- -->34</gt> </and> </condition> <action> <!-- Add one to a counter managed object --> <use name="/dom1/counter"> <inc/> </use> </action> </create> </use> </add> </use>
Breakdown of Policy XML
Create a new Policy called /Policy/testpolicy
<use name="/policy"> <add name="testpolicy"> <use name="/template/policy"> <create ...> ... </create> </use> </add> </use>
The policy will be an ECA type policy ("obligation") and it will respond to events of type /event/testevent, described here. The policy will become active as soon as it is created.
<create type="obligation" event="/event/testevent" active="true"> ... </create>
The policy will make use of two named arguments that the event provides:
<create event="/event/testevent" ...> <arg name="colour"/> <arg name="intensity"/> ... </create>
Named arguments are substituted as text before the XML action is evaluated by enclosing the name inside the two characters "!" and ";"
The optional condition can contain simple boolean statements comparing string and integer values. In this case we are checking whether the colour is red and the intensity is greater than 34. Conditions can contain any combination of and, or, not, eq, ne, gt, ge, lt or le. And and or take any number of XML sub-elements, not takes one, the others all take two. Note the string substitution of the arguments colour and intensity. Note also that the arguments for the comparisons have been separated by XML comments to ensure that they are separate XML elements.
<condition> <and> <eq>!colour;<!-- -->red</eq> <gt>!intensity;<!-- -->34</gt> </and> </condition>
The action part of the ECA policy is mandatory. It simply consists of Ponder2 XML, the only difference being that execution of the XML is delayed until the policy's event and condition parts are satisfied.
<action> <!-- Add one to a counter managed object --> <use name="/dom1/counter"> <inc/> </use> </action>