This document discusses the history and evolution of production rule systems from the 1970s to present. It covers early systems like OPS5 and CLIPS and how they introduced concepts like the Rete algorithm, modules, and object-oriented features. It then summarizes more recent systems like Drools and Jess. The document also proposes approaches for improving rule modularity and execution control, such as using rule units and life cycle annotations to better orchestrate rule firing. Overall it presents the continuing development of production rule technologies and opportunities for further modernization.
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
Rule Modularity and Execution Control
1. Mark Proctor
Distinguished Engineer II
Chief Architect - Rules, BPM and Optimisation
Red Hat
Modernising Production Rule Systems
Rule Modularity and Execution Control
9. Still Here Working
Memory
Modules
Inference Engine
Pattern
Matching
Agenda
“Today, I want to make clear that the future prospects for
production rule technology are diminishing..…
production rule technology is inadequate ”
(Paul Haley 2013)
http://haleyai.com/wordpress/2013/06/22/confessions-of-a-production-rule-vendor-part-1/
10. Still Here Working
Memory
Modules
Inference Engine
Pattern
Matching
Agenda
“Today, I want to make clear that the future prospects for
production rule technology are diminishing..…
production rule technology is inadequate”
(Paul Haley 2013)
http://haleyai.com/wordpress/2013/06/22/confessions-of-a-production-rule-vendor-part-1/
11. Still Here Working
Memory
Modules
Inference Engine
Pattern
Matching
Agenda
“It’s time to trade rule technology dating back to the 80’s for
state of the art AI.”
(Paul Haley 2018)
• http://haleyai.com/wordpress/2018/04/02/confessions-of-a-production-rule-vendor-part-2/
15. • Production system conflict resolution strategies (McDermott, Forgy 1976)
• Conflict Resolution + Control Token (Signals, GOTO)
• Mixes Control and Domain Logic in single rule
• This Pollution may be undesirable for readability and maintainability
• Does not guarantee rules for one token have fired before processing another token
• OPS MEA (Forgy 1981)
• Compares recency for the first pattern to find the dominant rule.
• Typically matches against a fact called a Context, Phase or Goal.
• Allows for goal-directed controlling of production systems which also introduces a
type of rule subroutine.
• Compares recency for the remaining elements
• LEX falls back on specificity and arbitrary.
Stylistic
16. • ROSIE (D. A. Waterman, 1979)
• Multiple data sets and rule sets.
• Only one ruleset and one data set can be active at a time.
• Eclips (NASA, 1991) PIE (NASA, 1988)
• Goal directed.
• Each goal has a context.
• Subroutine like.
• Clips Modules (NASA 1993)
• Push/Pop Stack
• No Context
• External Orchestration
• Rule Flow
Syntactic
18. • Rules and data are decoupled.
• Venus full hybrid C++ language.
• Single Root Module.
• Guard does not directly invoke Rule.
Instead it makes it legible for evaluation.
• Current consequence finishes,
before potential next module is entered.
• Module may have 1..n Support. Will
continue to evaluate, while it has support.
• If support is removed, module continues until it reaches fixed point (then it’s removed).
• Is single threaded a fair deterministic policy is used to help with selection,
which is controlled by the priority of the rule against its peers.
• Submitted module is identified by the combination of module name plus the passed
arguments.
Venus Rule Language
21. • ENTRY-BLOCK
• C-callable entry block
• Can have their own rules
• Implicitly activate
• May activate one or more rule Rule-Blocks
• RULE-BLOCK
• Allow for rules to be shared across ENTRY-BLOCKs
• May not call other ENTRY-BLOCKs or RULE-BLOCKs.
• External Orchestration
Rule Works
22. • ON-ENTRY: Before the match step of the first recognize- act cycle. This can be used for
tasks like data initialisation.
• ON-EVERY: After the act step of every cycle except the last one. This can be used for
tasks like printing out the rule count.
• ON-EMPTY: After the select step when the conflict set is empty. This can be used to
detect state and return error information.
• ON-EXIT: After the act step of the last cycle. This can be used for things like cleanup
actions.
Rule Works
23. Rule Works Life Cycles
ON-ENTRY ON-EVERY
Match Act
Select ON-EMPTY
ON-EXIT
Call to Entry
Block
Operating
System
Caller of Entry
Block
24. • Neither Venus or RuleWorks made it into industrial or academic mainstream.
• Business Rules have simple requirements.
• Often spreadsheet driven.
• Variations Rule Flow suffices.
• Academia is funding driven, interests change over time.
Recency and Relevance of Works
26. Units
package org.mypackage.myunit
public class AdultUnit implements RuleUnit {
private int adultAge;
private DataSource<Person> persons;
public AdultUnit( ) { }
public AdultUnit( DataSource<Person> persons, int age
) {
this.persons = persons;
this.age = age;
}
}
27. Units
package org.mypackage.myunit
public class AdultUnit implements RuleUnit {
private int adultAge;
private DataSource<Person> persons;
public AdultUnit( ) { }
public AdultUnit( DataSource<Person> persons, int age ) {
this.persons = persons;
this.age = age;
}
}
package org.mypackage.myunit
unit AdultUnit
rule Adult when
$p : /persons[age >= adultAge]
then
System.out.println($p.getName() +
" is adult and greater than " +
adultAge);
end
28. Units package org.mypackage.myunit
unit AdultUnit
rule Adult when
$p : /persons[age >= adultAge]
then
System.out.println($p.getName() +
" is adult and greater than " +
adultAge);
end
package org.mypackage.myunit
public class AdultUnit implements RuleUnit {
private int adultAge;
private DataSource<Person> persons;
public AdultUnit( ) { }
public AdultUnit( DataSource<Person> persons, int age ) {
this.persons = persons;
this.age = age;
}
@Override
public boolean onStart(RuleUnitInstance instance) {
System.out.println(getName() + " started.”);
return true;
}
@Override
public boolean onEnd(RuleUnitInstance instance) {
return true;
}
}
32. • PENDING: The unit is instantiated, but has not yet been started.
• RUNNING: The unit is evaluating and executing rules.
• DORMANT: The unit has either reached a fixed point and has no more work to
evaluate, or it has been requested
to stop further evaluation.
• YIELDED: The current executing unit has yielded (while
still having more work to do) to another unit that has
earlier scheduling.
States
33. Unit Life Cycles
RUNNINGDORMANT YIELDED
start
true
resume
true
yield
true
onSuspend
suspend
true
onResume
onStart
onEnd
onYield
onResume
PENDING
FINISHED
RuleUnitInstance
Created
CANCELLED
start
false
resume
true
resume
false
suspend
false
yeld
false
resume
false
resume
request
resume
request
suspend
request
yield
request
start
request
ON-ENTRY ON-EVERY
Match Act
Select ON-EMPTY
ON-EXIT
Call to Entry
Block
Operating
System
Caller of Entry
Block
35. • Depth first LIFO.
• Where the two guards exist for the same unit, the one that comes earlier in the rule
order has priority.
• Where the two guards are not from the same unit, but the path of one subsumes the
path of the other, the deepest unit has priority.
• Where the two guards are not from the same unit and one path does not subsume the
other, it will iterate the parent chain until it reaches the unit that is shared by both
Fairness
36. • Units as generic abstractions for runtimes
• Execution guards
• On every
• Inheritance
• Alternative orchestrations
• Refinements in rule execution
• @DataDriven / @Existence Driven
• @Incremental(<boolean>)
• @Sequential
Future Works
38. Mark Proctor
Distinguished Engineer II
Chief Architect - Rules, BPM and Optimisation
Red Hat
Modernising Production Rule Systems
Rule Modularity and Execution Control