与规则引擎交互的首选方法

Question

我即将深入研究一个面向规则的项目（使用 ILOGs Rules for .NET - 现在是 IBM）。我已经阅读了一些关于如何设置规则处理以及如何与规则引擎交互的不同观点。

我看到的两个主要想法是集中规则引擎（到它自己的服务器群中）并通过 Web 服务 API（或者在 ILOG 的情况下通过 WCF）针对该群进行编程。另一方面是在每个应用程序服务器上运行规则引擎的实例，并在本地与其交互，每个实例都有自己的规则副本。

集中化的好处是可以轻松地将规则部署到集中位置。规则根据需要进行扩展，而不是在每次扩展应用程序服务器配置时进行扩展。从购买许可证的角度来看，这减少了浪费。这种设置的缺点是增加了进行服务调用的开销、网络延迟等。

本地运行规则引擎的优点/缺点与集中式配置的优点/缺点完全相反。没有缓慢的服务调用（快速的 API 调用），没有网络问题，每个应用程序服务器都依赖于它自己。管理规则的部署变得更加复杂。每次将节点添加到应用程序云时，您都需要更多规则引擎许可证。

在阅读白皮书时，我看到亚马逊正在为每个应用程序服务器配置运行规则引擎。他们似乎在缓慢部署规则，并认识到规则发布的滞后是“可接受的”，即使业务逻辑在给定时间段内不同步。

问题： 根据您的经验，对于尚未在规则驱动的世界中工作的商店来说，开始将规则集成到基于 .net 的 Web 应用程序中的最佳方法是什么？

Answer 1

我们正在使用 ILOG For DotNet 并部署了试点项目。

以下是我们不成熟的规则架构的总结：

1. 所有数据访问均在规则之外进行。
2. 规则的部署方式与代码相同（源代码控制、发布流程、yada yada）。
3. 使用规则的项目（服务）有参考 ILOG.Rules.dll 以及通过自定义池类的新规则引擎。RuleEngine 被池化，因为将 RuleSet 绑定到 RuleEngine 的成本很高。
4. 几乎所有规则都是为了期望断言对象而不是 RuleFlow 参数而编写的。
5. 由于规则运行在相同的内存空间中，因此被规则修改的实例就是 相同的实例 在程序中 - 这是状态的立即传播。
6. 几乎所有规则都通过 RuleFlow 运行（即使它是 RuleFlow 中的单个 RuleStep）。

我们将 RuleExecutionServer 视为托管平台，并将 RuleTeamServerForSharePoint 视为规则源的主机。最终，我们将在代码发布过程之外将规则部署到生产中。

我们所有规则努力的主要障碍是建模和规则编写技能。

Answer 2

我从来不喜欢的集中参数。这意味着，一切都耦合到规则引擎，其成为的倾销地为系统中的所有规则。很快你不能对未知的恐惧改变什么：“我们会怎样打破”

我更喜欢下列服务是孤立的，独立的组件亚马逊的想法。我解释这意味着服务拥有自己的数据的和他们的规则的。

这具有将所述规则空间的附加益处。规则集变得越来越难维护，因为它生长;更好地保持它们到可管理的尺寸。

如果规则集的部分是共享的，我宁愿数据驱动，DI方法，其中一个服务可以具有其自己的规则引擎的实例，并从上启动一个数据库加载共同规则。如果您的ILOG许可证使得多个实例的成本过高，这可能是不可行的。这将是其中一个本应产品，可以帮助可能实际上被支配的架构选择，将带来悲痛的情况下。这将是一个较便宜的替代（例如，规则的JBoss在Java的土地）。

良好的参数

有关数据驱动的决策树方法是什么？是的Rete规则引擎真的有必要，O是“企业工具”的决定驾驶你的选择吗？

我想尝试建立规则引擎，它是从企业尽可能的休息脱钩。我不会把它呼唤数据库或服务，如果我能。更好地使这些对象的责任要求的决定。让他们打电话到必要的Web服务和数据库汇集必要的数据，将其传递给规则引擎，并让它做它的事。耦合是你的敌人：尝试设计您的系统，以尽量减少它。保持规则引擎隔离是做到这一点的好办法。

Answer 3

我没有太多的“哪个服务器”的问题说，但我促请你制定决策服务 - 使用规则做出决定调用服务，但不改变业务的状态。让调用应用程序/服务/进程决定作出什么样的数据变化调用决策服务，并具有调用组件的结果却发起行动（S）由决策服务建议可以更容易地反复使用决策服务再次（跨渠道，处理等）。清洁，少依赖于基础设施的其余部分决策服务的可重用性和可管理性也将是。 讨论这里ebizQ 可能是值得一读在这方面

Answer 4

根据我使用规则引擎的经验，我们应用了一组非常基本的实践来管理与规则引擎的交互。首先，这些一直是商业规则引擎（iLog、Corticon）而不是开源（Drools），因此由于许可成本，本地部署到每个应用程序服务器从来都不是真正可行的选择。因此，我们始终采用集中式模型，尽管有两种主要风格：

• Web服务的远程执行 - 按照您在问题中指定的相同方式，我们调用规则引擎产品提供的基于 SOAP 的服务。在 Web 服务领域，我们遇到了几种选择：(1) “Boxcar”请求，允许应用程序对处理请求的规则进行排队，并以块的形式发送它们，而不是一次性消息；(2) 调整供应商提供的线程和进程选项。这包括允许按功能分离决策服务并为每个服务分配 W3WP 和/或使用网络花园。您可以对 Boxcar、线程和流程进行大量调整，而获得正确的组合更多的是一个反复试验的过程（并了解您的规则集和数据），而不是一门精确的科学。
• 远程调用进程中的规则引擎 - 经典的批处理风格技巧，可避免序列化和反序列化的开销。远程进行调用，启动对规则引擎的进程内调用。这可以按计划完成（例如批次）或根据需求（即请求的“棚车”）。无论哪种方式，都可以通过直接与进程和数据库交互来避免服务调用的大量开销。此过程的缺点是您没有 IIS 或 EJB/Servlet 容器来为您管理线程，您必须自己执行此操作。