规则引擎

业务规则之间没有交互和通信。规则仅仅是模式匹配而已。还是那个开车的例子，绿灯亮可以开车前进，车前有人必须停车，这两条规则有交互和通信吗？没有。这里只有模式匹配和优先级。第二条规则的优先级高，所以车还停着；等人走过去了，第二条规则匹配不到，第一条规则起作用，车就向前走。正因为规则之间没有交互，各条规则才可以并行地、互不影响地发展，而不会变成像procedure programming那样一大堆纠缠不清的if...else...。所以要玩规则引擎，你首先就得忘记某些面向对象的东西。你面前就是一个规则库、一个事实库，以及两者之间的模式匹配。

正在写一篇关于规则引擎的文章，这边的讨论对我也满有价值的，谢谢各位。

我想规则是业务逻辑的一个组成部分。  业务逻辑应该还是以过程为主线来组织。 业务规则是组成部分， 但不适合作为主线。

等着看你的文章， 建议给一个较完整的代码例子。
另外， OMG 的 对象限制语言（OCL) 可以用来定义规则， 而且是标准啊， JESS 可能不支持吧。

这不一定的。有些业务逻辑确实是以过程为主线，比如公文流转、事务审批。但有些业务确实就是以规则为主的。譬如说手机话费，说穿了就是匹配一大堆规则，看看你有没有这个优惠那个套餐，从中找一个合适的来扣你的钱。这里唯一重要的就是如何操作这一大堆规则，让它可以稳定运转并且灵活维护。对于一般的应用来说，大概就是工作流和规则引擎两样声明性功能，流程怎么运转在工作流里配置，每个步骤做什么事在规则引擎里配置。



我不熟悉OCL。不过JESS采用的是CLIPS语法，CLIPS是以前大学里做人工智能、专家系统之类毕设的必备道具，想来应该是这方面比较权威的一个语言。不过到我上大学那会，这些东西已经销声匿迹了，我们学校计算机系的也没几个人知道。

这不一定的。有些业务逻辑确实是以过程为主线，比如公文流转、事务审批。但有些业务确实就是以规则为主的。譬如说手机话费，说穿了就是匹配一大堆规则，看看你有没有这个优惠那个套餐，从中找一个合适的来扣你的钱。这里唯一重要的就是如何操作这一大堆规则，让它可以稳定运转并且灵活维护。对于一般的应用来说，大概就是工作流和规则引擎两样声明性功能，流程怎么运转在工作流里配置，每个步骤做什么事在规则引擎里配置。
quote]

我赞成。某些情况适合按规则来组织。 这和著名的 黑板模式（blackboard pattern) 感觉是很类似。

gigix，我怎么感觉你把规则引擎理解成了工作流引擎啊？这两者是有区别的啊。
   规则引擎是指将逻辑表达（包括关系逻辑，运算逻辑）转义为计算机软件系统可以识别的计算处理顺序。一般最常见的就是公式规则（计算机算是最简单的运算逻辑）和逻辑规则（与、或、异或以及逻辑门）。
   规则引擎中涉及的规则和业务规则是两码事，业务规则是实际生活中业务逻辑，包括对数据处理，包括工作流程，更包括政策法规。不能混淆一谈的。
   像gigix理解的问题，如代替if else还有什么优先级，顺序（当然规则中肯定有优先级的），是有些偏向工作流的范围了，工作流中路由的跳判断需要规则引擎参与的，我不深入，不过有兴趣的朋友可以看看相关文章。
   规则引擎很早就有beanshell了，金碟也出了自己的商业组件，至于其他新的，我不太了解了。

to 风物黄羊
gigix对于规则引擎的理解还是很深入的，他的这几句估计你没看到：

你这个理解肯定不对的。就说我前面举那个例子，现在汽车停在红灯路口，绿灯亮起来了，下面该怎么办，你能拿工作流来描述吗？你描述不了，描述出来也就是一大堆夹杂不清的if...else...。因为这里的关键不是流程，而是执行流程的条件。你说过个路口有什么流程呢？你只有两种选择，要么开车，要么别动。但究竟选择开车还是不开车，需要判断的条件太多，多到你没办法用一种procedual的方式来描述。

另：beanshell是一种脚本语言，跟python、groovy差不多。

工作流引擎的核心用规则引擎来做非常合适

不用找文章了，规则引擎的理论基础就是专家系统，国内很早就翻译了一本非常经典的专家系统书

现在规则引擎一般采用Rete2算法，Drools自己扩展了一下称为Rete-oo，不过道理是一样的。

在应用系统中，一般规则引擎的作用就是用来表达业务规则的，我1998年前的时候自己试着用delphi写过一个简单的规则引擎，但后来希望用比较商业化的产品，就和ILog公司的新加坡人谈了半年左右，他们的规则引擎中大量的用于ERP排程、医院排班、价格计算、工艺编排方面的简单例子，后来由于他们的收费太高，最后还是没有使用。

简单的说，一个规则引擎有3部分组成，一部分是
1。Facts：所有的事实，应用系统中已经存在的事实
2。知识库：一系列规则，通常以if then 方式来表达，规则的左边是模式，右边是动作，左边称为左部，右边称为右部
3。推理机，推理引擎

首先有一个应用的规则集，包含很多规则。推理引擎用规则左边的模式去匹配facts列表中的fact，如果有匹配成功的话，这条规则就被激活，放到议程（已激活的规则集合）中去。最后所有的规则都匹配完成后，规则引擎就开始触发这些规则，规则引擎根据规则左边的匹配执行右边的动作，这些动作执行的过程中规则引擎会根据优先级和一定的算法根绝左边匹配的事实放入到右边的上下文中。也就是指针对匹配的事实执行右部的动作。
举个CLIPS的例子(从书上摘的）：


定义结构（在oo里面可以用好的办法）

(deftemplate person
  (slot name);
  (slot address););

(deftemplate moved
  (slot name);
  (slot address););

规则：

(defrule process-moved-information
  ?f1 <- (moved(name ?name);
                        (address ?address););
  ?f2 <- (person(name ?name););

=> 
   (retract ?f1);
   (modify ?f2(address ?address);););

定义facts

 (deffacts example
   (person (name "John Hill");
                (address "25 Mulberry Lane"););
   (moved (name "John Hill");
               (address "37 Cherry Lane");););

规则process-moved-information的第一个模式
f1 <- (moved(name ?name)
                        (address ?address))

确定地址移动是否需要处理

第二个模式
?f2 <- (person(name ?name))
用来匹配人的名字

facts的moved被f1匹配：
(moved (name "John Hill") -----?name已经被匹配为"John Hill"
               (address "37 Cherry Lane")))----?address被匹配为"37 Cherry Lane"
facts的person被f2匹配：
(person (name "John Hill")。。。。))-----?name已经被匹配为"John Hill"
因此规则中的两个模式都被匹配，执行的结果就是右边

  (modify ?f2(address ?address)))即

(person (name "John Hill)
             (address "37 Cherry Lane"))

  (retract ?f1)是为了防止死循环的，因为规则一旦被执行，修改了person以后，生成了一条新的fact，这样f1就会被再次激活，等等