Hi Mike, I have been working with Drools for only a few months now and am still rather new to it, but we've have made the same experience, switching from rules only to rules with flow, and I'm certain it's the right way to go.
The performance implications you mention depend mainly on the way the rules are set up, I guess. That is, if you have expensive RHS expressions like eval() you might indeed profit from keeping your glucose-level condition at the beginning of the rules which would prevent those expressions from being reevaluted, as far as I understand. If you don't I can hardly imagine that activating the rules makes up a noticeable fraction of the overall time of your process. We here have a scenario where some rules may be activated only if the user starting the session has got corresponding privileges. Since determining the priviliges is not always trivial we definitely wanted to have that logic in one place. The first thing to do was to use inference (http://docs.codehaus.org/display/LOGICABYSS/Policy+Encapsulation) but still already with a few dozen rules and including other constraints the rule RHsides became rather cluttered. Moreover it was getting increasingly complex to control the order in which the rules fired, maintanance being another issue. Using a rule flow we have achieved really good separation of concerns: A rule's RHS mostly contains exactly those conditions that apply to its intent, none of the cross-concerns or technicalities. (Hey, what about an AspectDrools implementation? ;-) ) I am confident that OO lessons apply here, too: If you have a clean design and performance problems start to show up you are much more likely to solve them than if you have a tangled web of dependencies. Greetings, Gerret _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
