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。
