Home/ Questions/Q 4244304
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T03:41:25+00:00

My enterprise application is currently Running on Weblogic 10.3.4, Java 1.6 and Spring 2.0.8.

  • 0

My enterprise application is currently Running on Weblogic 10.3.4, Java 1.6 and Spring 2.0.8. It’s a recent upgrade hence Spring is yet to be updated and some of the java code base is still in old 1.4 style.

At the moment we use a propriatory rules engine to run our business rules. However, this is overkill as we use none of the inference engine functionality and we can no longer justify the license costs. The plan is to write a database driven rules engine.

Each form request will have any number of rules associated with it, which wiull be configured using a few basic database tables.

My design so far is that each rule defined in the database will map via Spring to a Singleton Stateless Spring bean. Given a form state each rule will return a Result respose object. See code snippet below:

 //get List of rules for form from database
 List<RuleConfiguration>  rules = RulesService.getRulesForFormRuleset(formType, filingMethod, rsName, document);

    IssueDocument issues = new IssueDocumentImpl();

     for (RuleConfiguration ruleConfig : rules) {


         //create a rule instance from the Spring Bean Factory
         Rule rule = (Rule) beanFactory.getBean(ruleConfig.getRule().getRuleBeanName());
         RulesIssue issue = rule.runRule(document, ruleConfig);

            if (issue != null)  {  //Issue has been populated rule must have fired
                issues.addNewIssue(issue);
            }
     }

    return issues;

Does this sound like a sensible solution? I was keen to implement a “light-touch” solution so steered clear of EJB as there are over 500 rules that will eventually have to be written. My main concern is that as these are all singletons and there will be a heavy demand on my “rules engine” do I need to consider some sort of bean pooling? Any other feedback would be most welcome. Rip me to shreds if you like – I can take it!

Many Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Clearly there are two gross areas of work to do in this kind of thing.

    The first is to identify the rules to fire, and the second is to actually execute them.

    Depending on your filtering and the dynamism, the rule queries can likely be readily memoized, so likely the cost of the lookup will approach zero. 500 rules isn’t really a lot, when you think about it.

    Next, is actual execution. If all of your things are singletons, then you’ll need to be concerned about singleton startup, thread safety, etc.

    Basically, just make sure each of your rules has a lifecycle. “start” “run” “stop”. If it’s a true singleton that needs some state from run to run, then the start and stop methods will likely have logic in them. If it’s just a bit of logic to run on the inputs, then there’s probably no need to have start and stop (they can be empty methods), or for it to be a singleton at all, so just make a new instance, fire it, and throw it away.

    You don’t mention what a “rule” is in terms of logic. They can easily be simple Java classes that follow this lifecycle. Add a @SingeletonRule annotation, or implement isSingleton, whatever.

    Really, at this level there’s little rocket science to this kind of system. The magic is mostly in the meta data and the actual creating of the list of rules for execution.

    Simple rule systems are simple.

    • 0