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

Question

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

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

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

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

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

问题:根据您的经验,开始将规则集成到基于.net的Web应用程序中的最佳方法是什么？这个商店还没有花费太多时间在规则驱动的世界中工作？

Answer 1

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

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

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

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

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