在我们的项目中,我们需要一个规则引擎组件,经过短时间的研究后我发现.NET Workflow也有它的规则引擎..NET Workflow Rule Engine和其他人之间是否有任何完整的比较列表,例如NxBRE,Drool.NET ...非常感谢.
我是 drools 的新手，并给出了一个条件 (Condition) 和一个布尔变量 "a" ，我想用 drools 创建以下规则：
if (Condition)
{
a = true;
}
else
{
a = false;
}
最好的方法是什么？
目前我有两个选择：
1.用条件而不是条件创建2条规则（如果......那么......，如果不是......那么......）
rule "test"
where
$o: Object( Condition)
then
$o.a = true;
end
rule "test2"
where
$o: Object( not Condition)
then
$o.a = false
end
2.默认将变量a设置为false，然后触发规则
rule "test"
no loop
salience 100
where
$o: Object()
then
$o.a = false;
end
rule "test"
where
$o: Object( not Condition)
then
$o.a = true;
end
我的客户想要最终用户可配置的规则引擎.目前他们正在考虑BizTalk.他们应该考虑其他任何替代方案吗？
我正在开发一个相当复杂的规则引擎。因此，我决定借助任何 GNU 规则引擎并将其与我的应用程序集成。我发现CLIPS是一个很好的规则引擎。
现在，我的应用程序是用 C++ 编写的，我想要一个示例方式（Hello world 类型的程序），从中我可以学习如何将 .clp 规则引擎集成到我的 C++ 应用程序中。
问题
更新1：
您正在开发什么样的应用程序？
简而言之，我正在开发一个基于过滤器匹配的计数器。用户可以递增（NetworkID = XYZ，增量计数 = 7），（NetworkID = MNO，增量计数 = 934）...等。现在您收到 NetworkID = X * 的查询，然后我需要提供来自 XAA 的所有计数。 ..XZZ。它是在跨不同节点（分布式环境）的多进程、多线程中更新的。
为什么里面有专家系统规则，什么样的规则？
现在，我的平台/应用程序使用 C++（用户在其中进行递增/递减/查询）。现在我想使用规则引擎来帮助我完成这些工作。用 C/C++ 代码编写逻辑似乎会消耗更多所需的资源。
PS：与递增/递减/查询相关的关键代码均在优化的c代码中。一些包装器采用 C++ 代码。因此，我正在检查规则引擎来为我执行此操作，可以从我的平台/应用程序（在 C/C++ 代码中）调用它。
我一直在阅读一篇关于 Drools 性能的文章（JBoss Drools \xe2\x80\x93 Performance and Memory Internals），它解释了如何创建 Rete 树和节点，Drools 如何索引它们，以及为什么增加 Drools 中的对象数量几乎不会影响执行它所花费的总时间。\n以智能方式编写的规则可以大大减少 Rete Tree 中的节点数量，从而进一步提高性能。
\n\n我想知道是否有 Drools 规则编写最佳实践，这样我就可以以一种可以尽快执行的方式编写它们。
\n\n谢谢。
\n我们想使用Go来实现我们的业务逻辑，但是我们找不到Go的规则引擎/推理引擎的任何良好实现。有没有人有任何经验或建议？
我正在阅读文档中的矛盾内容.
一方面,这段经文似乎表明连续的计划变量是可能的:
计划值范围是计划变量的可能计划值的集合.该集合可以是离散的(例如,行1,2,3或4)或连续的(例如,在0.0和1.0之间的任何双倍).
另一方面,在定义计划变量时,必须ValueRangeProvider在字段上指定要用于值集的注释:
Solution实现具有返回Collection的方法.该集合中的任何值都是此计划变量的可能计划值.
这两个片段都在文档的相同部分(http://docs.jboss.org/drools/release/latest/optaplanner-docs/html_single/#d0e2518)
那么,这是什么？我可以使用full double作为我的计划变量,还是需要将其范围限制为特定值Collection？
看看实际的算法,我没有看到任何实际上适合优化连续变量的东西,所以我怀疑它是否可能,但是如果澄清并明确表示它会很好.
optimization rule-engine constraint-programming drools-planner optaplanner
我一直在研究规则引擎，这些规则引擎更适合在嵌入式系统上运行。系统将从传感器收集信息，并根据该信息进行特定的C / C ++调用。一个例子是：
IF RainSensor.value > RainSensor.threshold
THEN call( GarageWindow::close())
作为GarageWindow的C ++类，位于链接到规则引擎库的二进制文件中。
我不能对上述嵌入式系统的功能做出任何假设。要求是：
我需要根据其功能（在以后定义）中给出其他选择，这些假设是：
1）嵌入式系统不支持任何内容（不支持JVM，不支持python等）：
CLIPS作为C库或clipsmm作为C ++库。两者均可用于商业应用（clipsmm的GPL）。
优点：开源。很好的测试/记录。可移植，可在低内存占用情况下运行。可以从其RHS部分调用C或C ++函数。规则引擎很可能需要与C或C ++软件进行交互。
缺点：它不是线程安全的。它仅支持正向链接。
2）系统支持python：
PyClips：
到CLIPS的Python接口。功能保持与以前的情况相同。仅当需要在RHS部分中进行python调用时，使用此选项才有好处。我错过任何优点/缺点吗？
3）系统支持JVM：
杰西：
优点：与Java对象的良好集成。类似于CLIPS的脚本语言。向前和向后链接。自动侦听Java对象以修改插槽。
缺点：许可。只能在编译时定义新类。
流口水：
优点：开源。记录下来。Java集成。向前和向后链接。
缺点：它更适合在网络上工作（这是我的印象）。
在嵌入式环境中，Drools vs Jess有什么优势？
两者都只能在编译时添加新类。CLIPS可以在运行时。另一方面，如果更新剪辑实例的C ++代码很旧，则直接在CLIPS中创建的任何新类都不会与调用C ++代码中的任何其他类匹配。因此，重新编译Java选项的弊端并非如此。
还有其他我完全缺少的适用于嵌入式系统的引擎吗？
我们正处于构建物联网云平台项目的初期。有一些众所周知的部分可以实现完整的物联网平台解决方案。其中之一是实时规则处理/引擎系统，它需要了解流事件与最终用户以可读格式（SQL 或 Drools if/when/then 等）动态定义的任何规则相匹配。
我很困惑，因为互联网上有很多产品、项目（Storm、Spark、Flink、Drools、Espertech 等），所以考虑到我们有 3 人的开发团队（初级、中高级、高级），什么是最好的选择？
streaming rule-engine complex-event-processing iot flink-cep
我正在使用单线程 drools 项目作为第一匹配策略/条件评估引擎。我正在使用以下代码从 kieContainer 获取 kieSession，并根据条件评估谓词。
KieContainer currentContainer = kieContainer.get();
StatelessKieSession newKIESession = currentContainer.newStatelessKieSession();
newKieSession.execute(predicate);
对于给定的请求，评估大约需要 10 毫秒。但是，当我使用 10 个线程时，为了提高性能，这些请求中的每一个都开始花费大约 100 毫秒，有效地为我提供了相同的性能和更多的线程。
我应该为每个处理线程生成一个新容器，而不是从现有容器生成一个新会话吗？
//SEE LAST LINE BELOW
KieServices ks = KieServices.Factory.get();
KieRepository kr = ks.getRepository();
KieFileSystem kfs = ks.newKieFileSystem();
byte[] drlAsBytes = retrieveDRLResource();
kfs.write(ResourceFactory.newByteArrayResource(drlAsBytes).setTargetPath(DROOLS_DEFAULT_PATH));
KieBuilder kb = ks.newKieBuilder(kfs);
kb.buildAll(); // kieModule is automatically deployed to KieRepository if successfully built.
if (kb.getResults().hasMessages(Level.ERROR)) {
throw new PolicyServiceException("Build Errors:\n" + kb.getResults().toString());
}
//******* SHOULD THIS BE DONE FOR EACH PROCESSING …