Java规则引擎的优缺点

采用Java规则引擎JESS和Drools有什么优点和缺点? 还有其他玩家吗?

我知道Drools是开源的,JESS不是,但是他们在其他方面比如易用性,性能,与代码集成度如何呢?

采用Java规则引擎JESS和Drools有什么优点和缺点?

如果需要将业务规则与应用程序逻辑分开,请使用规则引擎。 您的项目是否需要规则引擎文章有一个很好的例子:

例如,典型的店面系统可能涉及计算折扣的代码:

if (product.quantity > 100 && product.quantity < 500) { product.discount = 2; } else if (product.quantity >= 500 && product.quantity < 2000) { product.discount = 5; } else if (product.quantity >= 2000) { product.discount = 10; } 

规则引擎用以下代码replace上面的代码:

 ruleEngine.applyRules(product); 

由你决定是否将一个规则pipe理控制台放在非技术人员的手中是好事还是不行

更多细节我应该使用规则引擎吗? 为什么使用规则引擎? ,以及决定是否使用规则引擎和Google上的一些准则 。

还有其他玩家吗?

其他球员包括JRules,Corticon(JRules是最着名的IMO – 这并不意味着最好的)。

他们在其他方面如何比较,如易用性,性能,与您的代码整合程度?

不能准确地告诉你,我只有一点点(正面)的经验与Drools。 但是,你会从JBoss Drools和ILog JRules等博客文章中获得一些反馈- 一个轶事故事 (请务必阅读)或从JRulesangular度使用Drools 。 我相信你可以在Google上find更多的(但是我会给Drools一个尝试)。

我们现在正在评估规则,以便与我们的应用服务器一起使 我们已经遇到了OpenRules ,它很容易与Java集成,就我们的testing显示,足够快。 OpenRules的主要优势在于规则被修改和处理的方式。 这一切都发生在Excel表格中,这是非程序员最简单的方法。 每个参与者,即使是非技术人员,都能理解一切:-)

我们也将stream口水融合在一起,但是这些规则更加复杂,因为这是一种更为程序化的方法。 这就是为什么我们很可能会坚持使用OpenRules。

我们和我们有类似的问题,我们终于拿起了Drools,如果你有以下的话,应该使用Drools:

  • 由于各种情况,您认为业务逻辑会因多个条件而变得混乱
  • 你将会有越来越多的复杂性需求
  • 业务逻辑的变化是频繁的(每年1-2次也会频繁发生)
  • 你的服务器有足够的内存,因为它是一个内存饥饿的工具,它提供了性能,成本的内存

在下面的URL中有更多的细节

只是增加了许多人正在寻找更类似于pipe理是否满足某些条件来启用或禁用应用程序中的某些function的东西。

我厌倦了重复执行相同的模式,所以我决定做一个名为Roolie的OSS项目http://sourceforge.net/projects/roolie/

我刚刚发明了这个软件,而且自2010年发布以来没有任何漏洞报告,我将其升级到1.0版,除了在Maven Central(我正在)。

基本上,JSR-94对于大多数事情来说都是过度的,而且目前的产品还有一个巨大的学习曲线和开销。 这很好,如果这是你想要的。 但是如果你只是想用Java编写简单的规则和XML来维护你的状态testing,Roolie是一个非常快速的方法。 没有依赖性,没有学习曲线。

当我们需要一个规则引擎时,我们决定推出自己的规则引擎,因为可用的对于我们简单的任务来说太复杂了。 如果你甚至对用户可能放入的parsingexpression式有远程的经验,这不是很难做到。 在我们的例子中,大多数规范都是通过XSD来处理的,只有less数几个字段被进一步parsing。