Additional Algorithms for Rules Evaluation

[Clayton7510]

Rules Engine uses CoR for sequential rules evaluation. It works! And for many situations, it's serves the need. However, for more ambitious applications, it would be nice to have other algorithms for rules evaluation available. The catch is that other algorithms should have a sequential dependency component to provide predictable execution between dependent rules. In addition, rules evaluation algorithms should be pluggable - the library certainly allows for it.

This is not pressing. On the 1. Make it work 2. Make it good 3. Make it fast hierarchy, it's definitely in the 3rd category. And there are other things (like versioning and BDSL) that should take precedence. But this is something that will be needed at some point down the line.

[Clayton7510]

OK, here's the thought...
The focus should be on ease of use and predictable execution over raw performance. If a radical departure in thinking is needed or a different problem focus is required then, hey, there are existing algorithms (like Rete) and tools (like Drools) available that do exactly that.

So, the idea here is not to convert RuleBook to inference engine - it's a rules abstraction that focuses on predictable execution. The solution needs to allow for a [mostly] sequential rule chain execution while making optimizations where it can. However, for the application and the developer, no functional differences should be noticed. I have a few ideas involving parallel & out-of-order execution combined with some caching.

But I'm definitely open to other approaches.

[Clayton7510]

Extending that thought: I think I want to take some of the ideas from Rete and apply them to what looks like sequential execution. That way, performance benefits will be realized, but without turning this thing into an inference engine (different type of rules engine). Like Rete, when rules are completely independent then ordering doesn't matter. But unlike Rete, the order is taken into account when the same data is updated and then used in a sequential pair in the RuleBook. Instead of breaking everything apart and recompiling the dependencies, dependencies are maintained and then broken into independent rule chains when possible - kind of inverting the approach to accommodate (seemingly) sequential rule chains.

[Clayton7510]

OK, this on deck next after the 0.11 release (ETA next week). And some changes are necessary. If you are an old-skool user of RuleBook and you are using the Java Builder DSL and adding fact values directly to rules and invoking those rules using rule.invoke() then things are going to change a bit. I think the given() method in the builder is going to have to change to specify the facts declared for use in the rule. This probably won't affect hardly anyone using this since the CoRRuleBook discards any facts directly added to rules (for thread safety). But... this does mean if you've created custom rules, the Rule interface may change.

Why?

Well, I am adding a ReteRuleBook. And Rete-like algos match rules based on the facts each rule needs (or based on the facts used in LHS/condition, but I think I am going to equate declared facts to LHS/condition required facts).