8:00 – 4:00 CSIP

• Drools JBoss Rules 5.0 Developer’s Guide
• It is not only difficult to represent business logic in a imperative programming style language, but also hard to differentiate between code that represents the business logic and the infrastructure code that supports it.
• We declare rules in pretty much the same way as the business analyst does the requirements—as a group of if-then statements. The rule engine can then take these rules and execute them over our data in the most efficient way. Rules, which have all of their conditions true, have their then part evaluated. This is different from imperative style programming languages where the developer has to specify how it needs to be done explicitly (with a sequence of conditionals and loops).
• rule represents one requirement. This is more readable and maps to business requirements more naturally.
• Well, having the right resource makes a difference. I have compiled and run a simple set of rules against multiple objects!
• eval is a catch-all solution. It allows execution of any Java/MVEL code (according to the selected dialect) that returns true or false. It should be used only as a last resort when all other options have failed. This is because the rule engine cannot optimize eval. The expression is evaluated every time there is a change in the current rule’s condition (a fact is added, modified, or removed). They don’t have to return time-constant values. Writing eval as the last condition in a rule is a good practice.
• How to get a reference to the current class being evaluated: $a:Account ( balance < 100, name != “Ted”). The ‘$’ is convention and not required

Lunch meeting to go over Noveta changes