Here are the notes I took during the second day with the ZB300 course for reference and further study:
Rules are executed within the Rule engine.
Rule engine can be run in embedded (integrated into any Java application) or managed (within Rule Execution Server) mode.
Business rules are what’s called in ILOG JRules a ruleset – a set of rules (as the name implies :)). Every ruleset is made up of rules that in turn are made up of two parts – a condition and an action.
Execution mode of rule engine can be RetePlus (default), Sequential and Fastpath that determines how rule instances are fired. Every rule (which in fact serves as a rule template) is instantiated into a rule instance which is (as far as I understand it) linked with the application that made the instance alive. I don’t know whether or not the rule instances are pooled for later use, but I guess they’re not since these instances are rules with the input parameters and the other objects from the working memory of the rule engine bound. Perhaps, it’s something you should be aware of while tuning the rule engine. The space where rule instances live is called the agenda. In the slide where RetePlus execution mode overview is laid down the lecturer said that the rule instances are removed from the agenda once they’re fired/evaluated. Since rule execution can add/update/remove objects in the working memory so it’s paramount to order when a rule instance is called, which is exactly what the execution (ordering) mode is all about.
Pattern matching of objects (rule set params or objects in the working memory) is what I used to call matching rules (or more specifically their condition part).
In the course, demonstration of how rules are executed are shown with accompanying pictures that makes their understanding easier to grasp. Each unit in the course concludes with a checkpoint with 3 or 4 questions about the newly acquired knowledge. The question about artifacts included in a Ruleset made me stunned as I don’t recall anything about it mentioned in the unit (!) As the question listed Rule Execution Server console as part of a ruleset (beside BOM, ruleset params, ruleflows, BOM2XOM mapping) it was quite easy to point out the correct answer. Gonna read about them in the InfoCenter.
The business object model (BOM) is the model upon which rules are written and executed. It is a business view of the model that defines the actions and the entities used in business rule artifacts. It can be verbalized, i.e. being associated with a natural language vocabulary for better rule management of policy managers and other non-technical users. The execution object model (XOM) is the model translated from a BOM for rule execution by the rule engine. While BOM uses natural language, XOM uses ILOG Rule Language (IRL). It’s paramount to keep these two models – BOM and XOM – consistent. BOM is (almost) a Java object model.
I liked the way BOM and XOM were compared – BOM is for rules to be written whereas XOM is for rules to be executed.
Depending on who creates a rule first – a business user or a rule developer – and the tools to be used determines whether XOM or BOM is created. On to the next slides and finally exercises. I haven’t had much time to do the exercises yet (mostly because of the unresponsiveness of Citrix image the tests are supposed to be run) and went through the material first. I think I won’t use Citrix any longer and run the samples locally (unless they need some special preparation like code base for the samples). On to the examples from tomorrow’s slides…