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

我们正在使用ilog作为dotnet 并部署了一个试点项目。

以下是我们不成熟的规则体系结构的总结:

1. 所有数据访问都是在规则之外完成的。
2. 规则的部署方式与代码(源代码控制、发布过程、yada yada)相同。
3. 使用规则的项目(服务)引用 ILOG.Rules.dll 以及通过自定义池类创建的新规则引擎。因为将规则集绑定到规则引擎很昂贵,所以规则引擎被合并。
4. 几乎所有规则都是为预期的断言对象而编写的,而不是规则流参数。
5. 由于规则在相同的内存空间中运行,因此由规则修改的实例是 相同实例 在程序中——这是状态的即时传播。
6. 几乎所有规则都是通过规则流运行的(即使它是规则流中的单个规则步骤)。

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

我们所有规则工作的主要障碍是建模和规则创作技能集。

我从来都不喜欢集中论。这意味着所有的东西都被耦合到规则引擎中,这将成为系统中所有规则的垃圾场。很快你就不能改变任何事情,因为害怕未知:“我们会打破什么?”

我更喜欢遵循亚马逊的服务理念,将其作为独立的、自主的组件。我认为这意味着服务拥有他们的数据 以及他们的规则 .

这样做还有一个额外的好处,那就是对规则空间进行分区。随着规则集的增长,其维护变得更加困难;最好将其保持在可管理的大小。

如果规则集的某些部分是共享的,那么我更喜欢数据驱动的DI方法,在这种方法中,服务可以拥有自己的规则引擎实例,并在启动时从数据库加载公共规则。如果您的ILOG许可证使多个实例的成本过高,这可能是不可行的。在这种情况下,本应起到帮助作用的产品实际上可能在指挥将带来悲伤的体系结构选择。对于一个较便宜的替代方案(例如JavaLand中的JBASS规则)来说,这将是一个很好的论证。

数据驱动的决策树方法呢?重新测试规则引擎是否真的是必要的,o“企业工具”决策是否推动您的选择?

我会尝试设置规则引擎,使其尽可能与企业的其他部分分离。如果可以的话,我不会让它向数据库或服务发出呼叫。最好把责任交给要求作出决定的对象。让他们调用必要的Web服务和数据库来组装必要的数据,将其传递给规则引擎,并让它完成它的工作。耦合是你的敌人:试着设计你的系统来最小化它。保持规则引擎隔离是一种很好的方法。

关于“哪台服务器”的问题,我没有太多的话要说,但我会敦促您开发决策服务——可调用的服务,它使用规则进行决策,但不会改变业务状态。让调用应用程序/服务/流程决定由于调用决策服务而要进行哪些数据更改,并让调用组件实际启动决策服务建议的操作,从而更容易反复(跨通道、流程等)使用决策服务。决策服务越干净,与基础设施的其他部分联系越少,它就越能被重用和管理。 讨论 here on ebizQ 在这方面可能值得一读。

在我使用规则引擎的经验中,我们已经应用了一组非常基本的实践来管理与规则引擎的交互。首先,这些一直是商业规则引擎(ilog,cortin)而不是开源(drools),因此,由于许可成本的原因,本地部署到每个应用服务器从来都不是一个可行的选择。因此,我们一直使用集中化模型,尽管有两种主要的风格:

• 远程执行Web服务 -以您在问题中指定的相同方式,我们调用规则引擎产品提供的基于SOAP的服务。在Web服务领域中,我们有几个选项:(1)“boxcar”请求,允许应用程序将处理请求的规则排队并以块形式发送,而不是一次性消息;(2)调整供应商提供的线程和处理选项。这包括允许按功能分离决策服务,并分配每个W3wp和/或使用Web花园。你可以对boxcars、线程和进程进行大量的调整,而获得正确的组合更像是一个试验和错误的过程(了解你的规则集和数据),而不是一个精确的科学。
• 远程调用正在处理的规则引擎 -一个典型的批处理风格的技巧,以避免序列化和反序列化的开销。远程进行调用以触发对规则引擎的进程内调用。这可以按计划(如批量)或按需(即请求的“箱车”)完成。无论哪种方式,都可以通过直接与流程和数据库交互来避免服务调用的大量开销。这个过程的缺点是,您没有为您管理线程的IIS或EJB/servlet容器,您必须自己做。