用于与规则引擎交互的优选方法

Question

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

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

集中化的优势在于易于将规则部署到集中位置。规则按需要扩展，而不是每次扩展应用程序服务器配置时进行扩展。这减少了购买许可证的浪费。这种设置的缺点是增加了服务调用，网络延迟等的开销。

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

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

问题：根据您的经验，开始将规则集成到基于.net的网络应用程序中的最佳方式是什么？这个网站尚未花费太多时间在规则驱动的世界中工作？< / p>

Answer 1

我从不喜欢集中化论点。这意味着所有内容都耦合到规则引擎中，后者成为系统中所有规则的倾倒场。很快你就不会因为害怕未知而改变任何东西：“我们会破坏什么？”

我更喜欢将亚马逊的服务理念视为孤立的自主组件。我将其解释为服务拥有其数据及其规则。

这具有划分规则空间的额外好处。随着规则集的增长，规则集变得越来越难以维护;更好地将它们保持在可管理的大小。

如果规则集的某些部分是共享的，我更喜欢数据驱动的DI方法，其中服务可以拥有自己的规则引擎实例，并在启动时从数据库加载通用规则。如果您的iLog许可证使多个实例成本过高，则这可能不可行。那将是一个应该帮助的产品可能实际上决定将带来悲伤的建筑选择的情况。对于较便宜的替代方案（例如，Java-land中的JBoss Rules），这将是一个很好的论据。

数据驱动的决策树方法怎么样？ Rete规则引擎是否真的有必要，o是推动您选择的“企业工具”决策吗？

我尝试设置规则引擎，以便尽可能地与企业的其他部分分离。如果可以的话，我不会呼吁数据库或服务。更好地使对象的责任要求做出决定。让他们调用必要的Web服务和数据库来组合必要的数据，将其传递给规则引擎，并让它做它的事情。耦合是你的敌人：尝试设计你的系统以最小化它。保持规则引擎隔离是一种很好的方法。

Answer 2

我对“哪个服务器”问题没什么好说的，但我会敦促你们开发决策服务 - 使用规则做出决策但不改变业务状态的可调用服务。让调用应用程序/服务/进程决定由于调用决策服务而使调用组件实际启动决策服务建议的操作而进行的数据更改，这使得更容易一遍又一遍地使用决策服务再次（跨渠道，流程等）。更清洁，与基础设施的其他部分联系更少，决策服务将更加可重用和可管理。 在这方面，讨论here on ebizQ可能值得一读。

Answer 3

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

以下是我们不成熟的规则架构的摘要：

1. 所有数据访问均在规则之外完成。
2. 规则的部署方式与代码相同（源代码管理，发布流程，yada yada）。
3. 使用规则的项目（服务）通过自定义池类引用ILOG.Rules.dll和新增的RuleEngines。合并RuleEngine是因为将RuleSet绑定到RuleEngine是很昂贵的。
4. 几乎所有规则都是为了期望Assert'd对象而不是RuleFlow参数。
5. 由于规则在相同的内存空间中运行，因此规则修改的实例是程序中的相同实例 - 这是状态的立即传播。
6. 几乎所有规则都是通过RuleFlow运行的（即使它是RuleFlow中的单个RuleStep）。

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

我们所有规则工作的主要障碍是建模和规则编写技能组合。

Answer 4

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

• 远程执行Web服务 - 与您在问题中指定的方式相同，我们调用规则引擎产品提供的基于SOAP的服务。在Web服务领域，我们有几种选择：（1）“Boxcar”请求，允许应用程序排队处理请求的规则并以块的形式发送它们而不是一次性消息; （2）调整供应商提供的线程和流程选项。这包括允许按功能分离决策服务并分配每个W3WP和/或使用网络花园。你可以用箱子，线程和流程进行大量的调整，并且正确的混合更像是一个试验和错误的过程（并且知道你的规则集和数据），而不是精确的科学。
• 远程调用正在处理的规则引擎 - 经典的批处理样式技巧，以避免序列化和反序列化的开销。远程拨打一个电话，激活对规则引擎的进程内调用。这可以按计划（例如批量）或基于需求（即请求的“箱式车”）完成。无论哪种方式，通过直接与进程和数据库交互，可以避免服务调用的大量开销。此过程的缺点是您没有IIS或EJB / Servlet容器为您管理线程，您必须自己完成。