规则引擎

Drools还是很有用处的
可就是不知道规则解析的效率如何？

在drools里面如何指定规则的优先级呢

我刚接触规则引擎，想请教两个问题：
1.规则引擎和专家系统有什么区别。有资料上说规则引擎是在基于规则的专家系统上发展起来的，我看二者的结构图和原理很像，那二者的区别是什么呢？
2.到哪下载DROOLS呢，是不是应该是个安装文件呢。我在labs.JBoss.com下了两个drools-2.5-final-javadoc.tar，drools-2.5-final-src文件，不知道有没有用，有什么用。
期待回覆，万分感谢！

说来话长，还是拿文档慢慢看吧。
http://labs.jboss.com/portal/jbossrules/docs

还有要提问题，重开贴，别再人家贴子里回

比如有多种促销方案,
第一个方案是两个产品A+一个产品B,整单打8.2折,结果便宜10元
第二个方案是两个产品B+一个产品C,整单打8折, 结果便宜12元
                  
现在买了两个产品A,一个产品B,一个产品C,规则引擎能够推理得出要执行方案2么?

package com.sample
 
import com.sample.DroolsTest.*;
 
rule "sales promotion-1"
	salience 10
	when
		a : A(varCountA : count -> ((varCountA.intValue()>=2)));
		b : B(varCountB : count -> ((varCountB.intValue()>=1)));
	then
		System.out.println( "整单打8.2折,结果便宜10元" ); 
		a.setCount(varCountA.intValue()-2);
		b.setCount(varCountB.intValue()-1);
		modify( a );
		modify( b );
end

rule "sales promotion-2"
	salience 20
	when
		b : B(varCountB : count -> ((varCountB.intValue()>=2)));
		c : C(varCountC : count -> ((varCountC.intValue()>=1)));
	then 
		System.out.println( "整单打8折,结果便宜12元" ); 
		b.setCount(varCountB.intValue()-2);
		c.setCount(varCountC.intValue()-1);
		modify( b );
		modify( c );
end

大概我在96-97年开始关注规则的问题,那个时候我还没有什么明显的开发方法的概念.即使到今天我对这个问题的研究也没有太多的答案,而是由太多太多的问题.既然大家讨论规则引擎,我就顺便把我对规则问题的思考和疑问介绍给大家.
首先明显的一点,使用规则会对你的需求了解的过程,造成深刻而无法预料的影响.因为使用了规则,所以你的程序中表达的业务就可以划分为业务数据对象和业务规则两个部分.需求分析阶段了解的主要部分则有传统的对于对于需求的全范围的建模变成对需求中的业务所表达的数据进行建模.而对于业务规则的建模在向后推延到实施阶段。
其次业务规则的定义将会给需求分析的方法带来根本性的改变。由于业务规则将成为一种可以动态调整的部分，从而在初期将这些部分从需求在程序中固化下来的部分进行区分就是完全必要的。而这些区分的原则将非常重要，并且也会非常微妙。这里我们可以分析一下前面那个例子：在这个例子中判断绿灯亮、前进、判断前方有人、停止、问候前方人的母亲，这些都是规则，但是这些部分基本不会发生变化，所以应该固化在程序内部。而实际上进一步，前方有人-停止和前方绿灯-前进，这两个规则也是基本不会被更改的，也是需要固化的。但是这种逻辑实际上还是有可能在某些情况下被更改的，这就需要对这些规则留下动态屏蔽的能力。而实际上经常进行改变的，是对于前面绿灯-前进和前面有人-停止，这两个规则优先次序的判断逻辑，这个部分无疑是应该完全用规则引擎来管理。然而实际应用的情况要复杂的多，比如一张订单可以包括10个货物栏。这个时候，首先我们要明确知道这个规定注定会影响数据的存储逻辑，而数据的存储逻辑实际上是应该放在数据访问层中的。下订单这个业务行为也非常难与定义为一种业务逻辑还是一种行为职责，也就是产生订单这个行为是用一个程序的动作去实现，还是用一个规则引擎的规则实现？当然你可以先使用一个程序的动作实现，然后确定一个屏蔽的方法调用。而实际上我们遇到的情况将比这个复杂的多，需要你作出非常多的权衡。而实际上确实存在这样的一种可能，也就是你的程序的业务层中将不会再有具体的业务行为的业务对象，而只是一些单纯的数据对象和一些的方法对象，而这两者之间的联系仅仅依靠规则引擎来连接。而我认为在这样的情况下kiss将是必须遵守的。
而实际上对于需求分析的影响将是使用规则引擎造成的一个最为值得关注的问题，需要使用更加新鲜的分析方法。原来的基于数据和过程的认识系统，必须将过程和过程中的逻辑判断区分开来，并且进一步将逻辑判断划分为规则和流程所自身私有的规则加以区分。实际上这就意味着工作流引擎应该和规则引擎互相的可以调用，也就是说在每一个流程的节点都可以植入一个规则引擎的接口。（而实际上我认为是有AOP来设计一种规则和流程公用的引擎将是一种思路。）

同时由于规则引擎的引入，将会给测试造成的影响也是非常多，这一点大家应该比较好理解。实际全面的应用规则引擎将给你的日记开发的全过程造成非常重要的影响，而首先要解决的问题就是你必须决定要把什么东西放到规则引擎去完成，基本上可以认为一个项目的成功与否在这样的情况下关键就在此。