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;
}

规则引擎将上面的代码替换为如下代码：

ruleEngine.applyRules(product);

由您决定是否将规则管理控制台交给非技术人员是好事:)

我应该使用规则引擎中的更多详细信息吗？，为什么要使用规则引擎？，有关确定是否使用规则引擎以及Google上的一些指南。

还有其他玩家吗？

其他参与者包括JRules，Corticon（JRules是最著名的IMO-并不代表最好的）。

他们如何在易用性，性能，与代码的集成程度等其他方面进行比较？

不能准确地告诉你，我对Drools的经验很少（积极）。但是您会从诸如JBoss Drools与ILog JRules之类的博客帖子中获得一些反馈-一个轶事（一定要读懂）或从JRules角度使用Drools。我敢肯定，您可以在Google上找到更多这样的工具（但我会尝试Drools的）。

我们正在评估与我们的应用程序服务器一起使用的规则。我们遇到过OpenRules，它很容易与Java集成，并且据我们的测试显示，它足够快。OpenRules优于其他规则的主要优点是修改和处理规则的方式。这一切都发生在Excel表中，这是非程序员最简单的方法。涉及的每个人，甚至是非技术人员，都对所有内容都非常了解：-)

我们还集成了流口水，但是由于它是一种更具编程性的方法，因此规则的理解变得更加复杂。这就是为什么我们（很可能）会坚持使用OpenRules。

我们也有类似的问题，我们最终选择了Drools，如果您有以下情况，应该使用Drools：

• 您认为业务逻辑因各种场景而变得混乱不堪
• 您将越来越需要增加复杂性
• 业务逻辑更改将很频繁（一年也将频繁更改1-2次）
• 您的服务器具有足够的内存，因为它是内存不足的工具，它以内存为代价提供性能

在以下URL上有更多详细信息

只是补充说，许多人正在寻找类似于管理是否满足某些条件以启用或禁用应用程序中某些功能的东西。

我厌倦了到处走遍一遍又一遍地重新实现相同的模式，因此我决定为其创建一个名为Roolie的OSS项目http://sourceforge.net/projects/roolie/

我只是对其进行过Maven化处理，由于自2010年发布以来未报告任何错误，因此我将其升级到v 1.0，除了在Maven Central托管它所需的操作外，没有其他更改（我正在这样做） ）。

基本上，JSR-94在大多数情况下都是多余的，并且当前的产品具有巨大的学习曲线和开销。如果那是您想要的，那很好。但是，如果您只想将用Java编写的简单规则与XML链接在一起以维护状态测试，那么Roolie是一种非常快速的方法。没有依赖性，也没有学习曲线。

当我们需要规则引擎时，我们决定推出自己的规则引擎，因为对于我们的简单任务而言，可用的规则太过复杂了。如果您甚至对使用用户可能会使用的解析表达式有一定的经验，这也不是一件很难的事。在我们的案例中，大多数规范都是由XSD处理的，只有少数字段会被进一步解析。