Ruleset, working memory and agenda in ILOG JRules 7 – another day with ZB300 course

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…


4 responses to “Ruleset, working memory and agenda in ILOG JRules 7 – another day with ZB300 course

  1. Jace,

    Excellent summary, how do you connect the rules set to the process engine?


  2. I’m still learning the ILOG JRules vocabulary (don’t confuse it with *THE* ILOG JRules vocabulary) so I’m a bit confused with the term “the process engine” that appears to me like “a rule engine”? If so, the ruleset is deployed onto the rule engine during normal rule deployment (will describe it in the upcoming days). If “a process engine” is not “a rule engine” I must admit I don’t know the answer. Please collaborate to let me find the answer you’re after.

    • Do you have any performance comparison between embedded rule engine and managed rule engine (RES)?

      What are the recommendations? To use always RES?

      Currently I have a standalone Java application so I would prefer to leverage embedded rule engine but I am not sure whether this is right direction. In RES (Rule Execution Server) provides a lot of functionality like pooling in XU. So I am still wondering if there is no cons to embed rule engine inside my application.

      I would like to emphasize that this app must support high performance and high availability. It processes about 300 TPS (transactions per second).

      Any thoughts?

      • It’s something I’d have to figure out myself soonish. I don’t have any performance test results I could share. I have never run any application with embedded jrules either. Thought I knew much about JRules, but there’re more to find out yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s