[rules-users] Rules packaging and (binary?) reuse: searching for best practices

Ansgar Konermann ansgar.konermann at googlemail.com
Tue May 11 19:31:20 EDT 2010


Hi all,

I'm in search of a better way to package rules into a binary format 
before they get deployed - one that eases rules reuse more than the 
technique currently in use at my employer.

We're using drools expert to perform risk assessment and feasibility 
checks for mortgage loans of a significant number of different lenders 
(say, we have N lenders). Each lender has its own set of rules, but 
large parts of these rulesets are quite similar (e. g. compliance with 
customer protection laws). Of course we don't want to maintain N 
complete rulesets, because this would mean each bug  in the common rules 
has to be done N times. We're already doing refactoring towards reusable 
subsets of these rules, however we feel as if we were running into some 
limitations of the drools compiler and/or our packaging.

Regarding the skills of our team: we're all at least senior java 
developers with a fad for cool java technology. No need to enable 
busines analysts to write rules here.

What we tried so far:

1) binary reuse: put related subsets of rules into their own pkg file 
(say: common.drl into common.pkg, plus for each lender-<N>.drl into 
lender-<N>.pkg) and load both the (one) common package and one 
lender-specific rule package into the rulebase at runtime. This leads to 
problems when using declared fact types. Imagine each lender computes 
the value of all the pledged securities a little different, but it is a 
common rule that the loan amount must not exceed 100% of this value. So 
we declare 'SecuritiesSum' in a separate file, but compile it into both 
drl files. The lender-specific rules can compute the value, add a fact 
of this type to the working memory and the common ruleset can issue a 
"maximum loan sum exceeded" message if the threshold is exceeded. Sounds 
nice, but did not work out for us: both rule packages contain their 
*own* compiled bean class for the 'SecuritiesSum' declared fact, each 
managed by a different classloader. So, we *cannot* pass parameters 
between rulesets using declares.

2) source code reuse: "simply" put all the source files that are 
required to form a complete ruleset for each lender into a fileset and 
compile this fileset into a pkg file. There are several problems with this:
a) the ruleset is large and takes in the order of minutes to compile, 
even if you change only a single rule file. We really hate long 
turnaround times, this magnitude is not acceptable for us.
b) dealing with the large number of rule files and managing them (which 
file belongs to which ruleset) becomes too complex. In reality, the 
ruleset for lender N contains not two files, but in the order of a few 
hundred. We're lacking a level of abstraction to group rules which 
relate to each other from a business point of view (e. g. 'securities 
assessment', 'consumer loan history checks', 'sum of yearly 
obligations'). Our hope was to achieve this with binary reuse (see above 
for why we failed).

Questions:
* can anyone of you report any best practices which have proven useful 
in an environment like this?
* are there any plans to support maven as the primary build tool for 
rule artifacts? is maven the right tool to package rules?
* does Guvnor have a silver bullet solution for our packaging problem? 
Could we improve the situation by switching to Guvnor?

I'd be very glad if some of you could give some advice how to do better...

Thanks in advance, best regards

Ansgar





More information about the rules-users mailing list