与规则引擎进行交互的首选方法 [英] Prefered methods for interacting with a rules engine

问题描述

我将深入研究面向规则的项目(使用.NET的ILOGs Rules-现在为IBM).我已经阅读了关于如何设置规则处理以及如何与规则引擎交互的两种不同观点.

I am about to dive into a rules oriented project (using ILOGs Rules for .NET - now IBM). And I have read a couple different perspectives regarding how to set up the rules processing and how to interact with the rule engine.

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

The two main thoughts I have seen is to centralize the rule engine (into its own farm of servers) and program against the farm via a web service API (or in ILOG's case via WCF). The other side is to run an instance of the rule engine on each of your app servers and interact with it locally with each instance having its own copy of the rules.

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

The up side to centralization is the ease of deployment of the rules to a centralized location. The rules scale as they need to rather than scaling each time you expand your application server configuration. This reduces waste from a purchased license perspective. The down side to this set up is the added overhead of making service calls, network latency, etc.

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

The upside/downside to locally running the rule engine is the exact opposite of the centralized configuration's upside/downside. No slow service calls (fast API calls), no network issues, each app server relies on it self. Managing deployment of rules becomes more complex. Each time you add a node to your app cloud you will need more licenses for rule engines.

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

In reading white papers I see that Amazon is running the rule engine per app server configuration. They appear to do a slow deployment of rules and recognize that the lag in rule publishing is "acceptable" even though business logic is out of a sync for a given period of time.

问题:根据您的经验，对于尚未花很多时间在规则驱动的世界中工作的商店，开始将规则集成到基于.net的Web应用程序中的最佳方法是什么?/p>

Question: From your experiences, what is the best way to start integrating rules into a .net based web app for a shop that has not yet spent much time working in a rules driven world?

推荐答案

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

We're using ILOG For DotNet and have a deployed pilot project.

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

Here's a summary of our immature Rules Architecture:

1. 所有数据访问都超出规则.
2. 规则的部署方式与代码(源代码控制，发布过程，yada yada)相同.
使用规则的
3. 项目(服务)通过自定义池类对ILOG.Rules.dll和新的RuleEngines进行了引用.将RuleEngines合并是因为将RuleSet绑定到RuleEngine的开销很大.
4. 几乎所有规则都编写为期望有Assert'd对象，而不是RuleFlow参数.
5. 由于规则在相同的内存空间中运行，因此被规则修改的实例是程序中的相同实例-状态会立即传播.
6. 几乎所有规则都是通过RuleFlow运行的(即使它是RuleFlow中的单个RuleStep).

1. All data-access done outside of rules.
2. Rules are deployed the same way as code (source control, release process, yada yada).
3. Projects (services) that use Rules have a reference to ILOG.Rules.dll and new-up RuleEngines via a custom pooling class. RuleEngines are pooled because it is expensive to bind a RuleSet to a RuleEngine.
4. Almost all rules are written to expect Assert'd objects, rather than RuleFlow parameters.
5. Since the rules run in the same memory space, instances that are modified by the rules are the same instances in the program - which is immediate propagation of state.
6. Almost all rules are run via RuleFlow (even if it is a single RuleStep in the RuleFlow).

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

We're looking at RuleExecutionServer as an hosting platform as well as RuleTeamServerForSharePoint to be the host for rules source. Eventually, we will have Rules deployed to production outside of the code release process.

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

The primary obstacle in all our Rule endeavors is Modeling and Rule Authoring skillsets.

这篇关于与规则引擎进行交互的首选方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！