Re: [drools-user] Drools recommendations.
Edson Tirelli <tirelli <at> post.com>
2006-06-12 12:40:54 GMT
Hi Subin,
Just a few comments:
1. There is no problem in using salience as an ordering criteria.
Usually we don't advise to use it because sometimes people abuse it and
try to do procedural development in the form of rules, what is really
bad because you force the engine to work in a way that may not be the
most efficient way. But if you write your rules correctly and make use
of salience only where it is really needed for semanthic purposes (not
"programing" purposes), there will be no problem. Regarding the garantee
of fire-order, you need to understand the concept of agenda: each tuple,
for each rule, that matches the RHS (right hand side, a.k.a. the "when"
part) go into the agenda as an activation. Then, the engine uses
"conflict resolution" strategies to decide wich activation to fire
first. You can change the conflict resolution if you need to, but the
default is a composed strategy where the first criteria is salience. So
the highest salience rules fires first by default.
Usually you don't need to worry about that. Just write your rules with a
"rule concept" in mind and it shall work just fine.
2. For maintanence purposes, I would say it is always better to split
the rules in multiple DRL files. There is no "runtime" performance
implications. I'm not sure if there is "loading" time impacts in
separating the rules in multiple files, but the recommended approach is
always to load the rule base once, cache it, and create as many working
memories as you need to work with it. Working this way, loading time has
a minimal impact on the whole application performance. Also, the rule
base is serializable, so you can even load it once, serialize it (to
disk, JNDI, database, or whatever is best for you), and use the
serialized version that avoids the "rule compilation" time if your rules
don't change too often.
3. I would go with the second approach no doubt. Functions are simply
blocks of code that are like black boxes for the engine. The engine can
do nothing about them, except execute them. But if you express your
knowledge as rules, the engine can do its magic. I'm not aware of any
advice against asserting objects in the LHS of a rule, and in fact, that
is the way rule engines work. Of course, if your application can assert
all objects directly, without the need of a rule whose only purpose is
to assert objects, that is a much better approach, but in case you
don't, go for the rules.
Hope it helps,
Edson
Subin P wrote:
> Hi,
>
> I am new to drools and I guess myself to be a little biased to the
> procedural way of doing things.
>
> I am trying to author some rules for my application and am a bit
> confused as to :
>
> 1.) Is there a problem in making use of salience or other attributes
> so as to order the execution of rules (for eg: there are some
> validations that need to be performed in a particular order. ) Are we
> always guaranteed that the rules will be fired in that order. Won’t
> this ordering have a dependency while new rules are added? What are
> your recommendations ?
>
> 2.) Do you recommend a single .drl file with all the rules or
> splitting the rules into multiple drl files. Are there any performance
> implications ?
>
> 3.) Please comment on the following approach :
>
> Say I have a “Claim” object which has a collection of LaborDetails. I
> need to make a validation on each of these LaborDetail. My initial
> instinct was to write a function to iterate through the collection and
> make the validations. (And I began to wonder what the rule engine was
> doing :) ). My next approach was to have a separate rule for the
> LaborDetail class and then from one of my previous rules, I iterate
> the laborDetails collection and assert it in the “then” part of the
> rule. This obviously ties the two rules together. Plus, I read
> somewhere in the Drools manual that it is not advisable to assert
> objects in the “then” part of a rule that forces the
>
> Rule engine to invoke yet another rule. Why is that ? What would you
> recommend in such a scenario ?
>
> I shall be grateful for any tips on the effective usage of the rule
> engine (especially tips outside of the manual.) Thanks in advance.
>
> Thanks,
> Subin
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
RSS Feed