What are the pros and cons to adopting the Java rules engines JESS and Drools?
Use a rule engine if you need to separate the business rules from the application logic. The Does Your Project Need a Rule Engine article has a good example:
For example, a typical storefront system might involve code to calculate a discount:
We are evaluating rules now for use with our application server. We have come across OpenRules, which is easy to integrate with Java and, as far as our testing has shown, fast enough. The main advantage of OpenRules above the others is the way the rules are modified and handled. It all happens in Excel tables, which is the easiest way for non-programmers. Everybody involved, even the non-technical people, understood everything perfectly :-)
We also have drools integrated, but the rules are way more complicated to understand as it is a more programmatic approach. That's why we - most likely - will stick to OpenRules.
我只是对它进行了 maven 化，因为自 2010 年发布以来没有报告任何错误，所以我将其升级到 v 1.0，没有进行任何其他更改比在 Maven Central 托管它所需的数量（我正在做的过程中）。
基本上，JSR-94 对于大多数事情来说都是大材小用，而且当前的产品还存在巨大的学习曲线和开销。如果这就是你想要的，那很好。但是，如果您只想将用 Java 编写的简单规则与 XML 链接在一起来维护状态测试，那么 Roolie 是一种非常快速的方法。没有依赖性，也没有学习曲线。
Just adding that many people are looking for something more akin to managing whether certain conditions are met to enable or disable certain features in an application.
I grew tired of re-implementing the same pattern over and over everywhere I went, so I decided to make an OSS project for it called Roolie http://sourceforge.net/projects/roolie/
I just maven-ized it and since there have been no bugs reported since 2010 when it was released, I upgraded it to v 1.0 with no changes other than those required to host it at Maven Central (which i'm in the process of doing).
Basically JSR-94 is overkill for most things, and there is a huge learning curve and overhead that go along with the current offerings. That's fine if that's what you want. But if you just want to chain simple rules written in Java together with XML to maintain your state tests, Roolie is a very fast way to do it. No dependencies and no learning curve.
When we needed a rules engine, we decided to roll our own, because the available ones were far too complicated for our simple tasks. If you are even remotely experienced with parsing expressions users may put in, this is not very hard to do. In our case, most of the spec is handled by an XSD and only a few of the fields are parsed further.
发布评论
评论（5）
如果需要将业务规则与应用程序逻辑分开，请使用规则引擎。 您的项目是否需要规则引擎文章有一个很好的例子：
由您决定将规则管理控制台交给非技术人员是否是一件好事:)
更多详细信息，请参见 我应该使用规则引擎吗？, 为什么使用规则引擎？, 一些决定是否使用规则引擎的指南以及谷歌。
其他播放器包括 JRules、Corticon（JRules 是 IMO 中最著名的 - 这并不意味着最好的）。
不能准确地告诉你，我对 Drools 只有一点（积极的）经验。但是您会从 JBoss 等博客文章中获得一些反馈Drools 与 ILog JRules - 轶事故事（请务必阅读）或从 JRules 角度使用 Drools。我相信你可以在 Google 上找到更多（但我会尝试 Drools）。
Use a rule engine if you need to separate the business rules from the application logic. The Does Your Project Need a Rule Engine article has a good example:
Up to you to decide whether putting a rule admin console in the hands of non-technical people is a good thing or not :)
More details in Should I use a Rules Engine?, Why use a Rule Engine?, Some Guidelines For Deciding Whether To Use A Rules Engine and on Google.
Other players include JRules, Corticon (JRules is the most famous IMO - which doesn't mean the best).
Can't tell you precisely, I only have a little (positive) experience with Drools. But you'll get some feedback from blog posts like JBoss Drools vs ILog JRules - an anecdotal story (be sure to read it) or Working with Drools from a JRules perspective. I'm sure you can find more of them on Google (but I would give Drools a try).
我们现在正在评估与我们的应用程序服务器一起使用的规则。我们遇到了 OpenRules，它很容易与 Java 集成，而且据我们的测试显示，速度足够快。 OpenRules 优于其他规则的主要优点是修改和处理规则的方式。这一切都发生在 Excel 表格中，这对于非程序员来说是最简单的方法。每个参与的人，甚至是非技术人员，都完美地理解了一切:-)
我们也集成了流口水，但规则更难以理解，因为它是一种更加程序化的方法。这就是为什么我们很可能会坚持 OpenRules。
We are evaluating rules now for use with our application server. We have come across OpenRules, which is easy to integrate with Java and, as far as our testing has shown, fast enough. The main advantage of OpenRules above the others is the way the rules are modified and handled. It all happens in Excel tables, which is the easiest way for non-programmers. Everybody involved, even the non-technical people, understood everything perfectly :-)
We also have drools integrated, but the rules are way more complicated to understand as it is a more programmatic approach. That's why we - most likely - will stick to OpenRules.
我们也遇到了类似的问题，我们最终选择了 Drools，如果您有以下情况，则应该使用 Drools：
更多详细信息请参见以下 网址
We had similar question with us, we finally picked up Drools, one should use drools if you have following:
Have more details at following URL
只是补充一点，许多人正在寻找更类似于管理是否满足某些条件以启用或禁用应用程序中的某些功能的东西。
我厌倦了在我去过的所有地方一遍又一遍地重新实现相同的模式，所以我决定为其创建一个 OSS 项目，名为 Roolie http://sourceforge.net/projects/roolie/
我只是对它进行了 maven 化，因为自 2010 年发布以来没有报告任何错误，所以我将其升级到 v 1.0，没有进行任何其他更改比在 Maven Central 托管它所需的数量（我正在做的过程中）。
基本上，JSR-94 对于大多数事情来说都是大材小用，而且当前的产品还存在巨大的学习曲线和开销。如果这就是你想要的，那很好。但是，如果您只想将用 Java 编写的简单规则与 XML 链接在一起来维护状态测试，那么 Roolie 是一种非常快速的方法。没有依赖性，也没有学习曲线。
Just adding that many people are looking for something more akin to managing whether certain conditions are met to enable or disable certain features in an application.
I grew tired of re-implementing the same pattern over and over everywhere I went, so I decided to make an OSS project for it called Roolie http://sourceforge.net/projects/roolie/
I just maven-ized it and since there have been no bugs reported since 2010 when it was released, I upgraded it to v 1.0 with no changes other than those required to host it at Maven Central (which i'm in the process of doing).
Basically JSR-94 is overkill for most things, and there is a huge learning curve and overhead that go along with the current offerings. That's fine if that's what you want. But if you just want to chain simple rules written in Java together with XML to maintain your state tests, Roolie is a very fast way to do it. No dependencies and no learning curve.
当我们需要一个规则引擎时，我们决定推出自己的规则引擎，因为可用的规则引擎对于我们的简单任务来说太复杂了。如果您对解析用户可能输入的表达式有一定的经验，那么这并不是很难做到的。在我们的例子中，大部分规范由 XSD 处理，只有少数字段被进一步解析。
When we needed a rules engine, we decided to roll our own, because the available ones were far too complicated for our simple tasks. If you are even remotely experienced with parsing expressions users may put in, this is not very hard to do. In our case, most of the spec is handled by an XSD and only a few of the fields are parsed further.