Java 数据库驱动的业务规则 - 设计思想？
我的企业应用程序当前在 Weblogic 10.3.4、Java 1.6 和 Spring 2.0.8 上运行。这是最近的升级，因此 Spring 尚未更新，并且一些 java 代码库仍然是旧的 1.4 风格。
目前，我们使用专有的规则引擎来运行我们的业务规则。然而，这有点过分了，因为我们没有使用任何推理引擎功能，而且我们无法再证明许可成本的合理性。计划是编写一个数据库驱动的规则引擎。
每个表单请求都将有任意数量的与其关联的规则，这些规则将使用一些基本数据库表进行配置。
到目前为止，我的设计是数据库中定义的每个规则都将通过 Spring 映射到 Singleton Stateless Spring bean。给定一个表单状态，每个规则将返回一个结果响应对象。请参阅下面的代码片段：
//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;
这听起来像是一个明智的解决方案吗？我热衷于实现一个“轻量级”解决方案，因此避开了 EJB，因为最终需要编写 500 多个规则。我主要担心的是，由于这些都是单例，并且对我的“规则引擎”有很大的需求，我是否需要考虑某种 bean 池？任何其他反馈都将受到欢迎。如果你愿意的话，就把我撕成碎片——我可以接受！
非常感谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
显然，在这种事情上有两个主要的工作要做。
第一个是确定要触发的规则，第二个是实际执行它们。
根据您的过滤和动态性，规则查询可能很容易被记住，因此查找成本可能会接近零。仔细想想，500 条规则其实并不算多。
接下来，就是实际执行。如果你所有的东西都是单例，那么你需要关心单例启动、线程安全等。
基本上，只需确保每个规则都有生命周期即可。 “开始”“运行”“停止”。如果它是一个真正的单例，从运行到运行都需要某种状态，那么启动和停止方法可能会包含逻辑。如果只是在输入上运行一些逻辑，那么可能不需要启动和停止（它们可以是空方法），或者根本不需要它是单例，所以只需创建一个新实例，然后启动它，然后把它扔掉。
您没有提到逻辑上的“规则”是什么。它们可以很容易地成为遵循此生命周期的简单 Java 类。添加 @SingeletonRule 注释，或实现 isSingleton，等等。
确实，在这个层面上，这种系统几乎没有什么火箭科学。魔力主要在于元数据和执行规则列表的实际创建。
简单的规则系统很简单。
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.