Differences between revisions 10 and 11
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== Obligation Policies ==
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 mor conditios to be evaluated and one or more actions to be performed if the conditions are satisified.
= Obligation Policies =
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.
Line 8: Line 8:
s the [[Ponder2UsingEvents|Event Type]] that it will respond to, the event's arguments that it will use, optional conditions that must be satisfied and a set of actions to be performed. Obligation policies are created from the Event, Condition, Action [[http://www.ponder2.net/doc/pondertalk/ObligationPolicy.html|policy factory]]:
Line 10: Line 10:
{{{
#!java
newPolicy := root/factory/ecapolicy create.
}}}
== Event ==
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.

{{{
#!java
template := root/factory/event create: #( "monitor" "value" ).
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.

{{{
#!java
policy := root/factory/ecapolicy create.
policy event: root/event/monitor.
}}}
== Condition ==
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.{{{
#!java
policy condition: [ :value | value > 100 ].
}}}
== Action ==
{{{
#!java
policy action: [ :monitor :value | root print: "Monitor " + monitor + " has value " + value ].
}}}
{{{
#!java
policy active: true.
}}}
== Example ==
This probably looks a little better laid out using cascading messages:

{{{
#!java
policy := root/factory/ecapolicy create.
policy event: root/event/monitor;
       condition: [ :value | value > 100 ];
       action: [ :monitor :value |
            root print: "Monitor " + monitor + " has value " + value
       ];
       active: true.
}}}
###
Line 94: Line 142:
 CategoryPonder2Project CategoryUsingPonder2  . CategoryPonder2Project CategoryUsingPonder2

Obligation Policies

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.

Event

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.

Condition

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 ].

Action

   1 policy action: [ :monitor :value | root print: "Monitor " + monitor + " has value " + value ].

   1 policy active: true.

Example

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:

XSLT option disabled, please look at HelpOnConfiguration.
<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 ";"

Condition

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>

Action

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>


ObligationPolicies (last edited 2008-01-25 12:39:01 by KevinTwidle)