我计划引入Java规则，目前正在评估Drools，以从物理上和逻辑上从应用程序外部化业务规则。
由于这些业务规则经常由企业使用，因此我希望企业通过GUI对规则进行必要的更改。
我已经通过Google搜索集成了Java Web应用程序+ Drools + Guvnor，但我一无所获。
我的问题:
关于集成Java应用程序+ Drools + Guvnor的简单实现的任何其他建议都很好。
任何指向教程的指针也将为我做这件事。
最佳答案
我正在做类似于您想做的事情。
警告警告警告!!!一个普遍的误解是，只要有GUI，非程序员都可以使用它。那不是我得出的结论。它有帮助，但是编程的难点不是写代码，而是针对正确的问题提出了很好的解决方案。我敢肯定，一些更聪明，技术上更偏向商务的人可以用Guvnor做些事情，但是不要指望它是通向“极乐世界”的黄砖路。您仍然必须为业务人员提供一个理智的数据模型和API，使他们可以执行所需的工作，但可以防止他们偶然地执行不需要的操作。
好吧，“轻量级”是个讨论的话题，但是Guvnor的表现相当不错，不需要浏览器，因此我认为还可以。
好了，一旦Guvnor启动并运行，连接您的应用程序以使用KnowledgeAgent连接到Guvnor并侦听新规则更新就不是特别困难。
不幸的是，一般来说Drools尤其是Guvnor都有很多怪癖，您可能需要解决(例如，您必须分解Guvnor WAR文件并编辑WEB-INF/beans.xml中的文件才能设置非默认配置...)。但是一旦您弄清楚了，我认为它会很好地工作。
至于文档，Javadocs有时可能会比较稀疏，但是web site有一些不错的东西，其中包括几本书。
总而言之，Drools和Guvnor是功能强大的工具，但让它们正常工作并非易事。如果您确实需要他们所提供的功能，那么他们是值得的，但是也可能值得考虑是否需要一个更简单的脚本解决方案。
现在，如果您发现自己确实需要Drools，这是我的首要建议-为数据库和规则保留单独的数据模型。这确实意味着要编写许多无聊的转换代码，但这是值得的。
我正在使用的应用程序将JPA用于数据库事务，并且在我们的规则中使用该数据模型并不是很令人愉快。几个原因:
适合您的数据层不一定适合Drools，反之亦然。
我们有一个树结构，在JPA中自然是与父节点列表中的子节点的@OneToMany关系。在Drools中使用列表非常麻烦，因此我们将其展平为一个结构，在该结构中插入一个ParentNode对象和一堆ChildNode对象，这比使用起来容易得多。
敢于重构。
规则的数据模型也需要存在于Guvnor中-这意味着如果重命名实体类或类似的东西，则可能会破坏所有规则。规则的单独数据模型意味着您可以毫无困难地重构数据库内容。
向他们展示他们需要看的东西。
数据库可能会变得相当复杂，但是规则通常不需要关心其中的许多复杂性。将这些复杂性暴露给人们编辑规则可能会导致很多不必要的困惑。例如，我们发现对于我们的场景，绝对没有必要让规则编写者暴露于多对多关系(事实证明，在Drools中处理起来非常复杂)-因此，我们使它们看起来像一对多，一切都会变得更加自然。
保护。
我们已经将大多数规则设计为像以下伪代码一样工作:
rule "Say hello to user"
when
user : User
then
insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end
...因此，对于每个规则包，都明确定义了您可以插入哪些响应命令以及它们的作用。在我们的应用程序中运行规则之后，我们会选择由规则插入到 session 中的对象并对其执行操作(visitor pattern已被证明非常有用，可以避免较长的
if instanceof/else if instanceof/else链)。我很高兴我们这样做，而不是让规则编写者做他们想对我们的JPA对象做的任何事情。
无论如何，希望这会有所帮助。