关于规则引擎在企业项目中的使用

规则引擎的出现使得商业决策逻辑和应用开发者的技术决策分离,增强了软件的柔韧性. Java规则引擎项目 Drools 被设计为可插入式的语言实现。目前规则能用Java, Python和Groovy实现。更为重要的是，Drools提供了声明式程序设计(Declarative Programming),并且使用域描述语言(Domain Specific Languages (DSL))－专为你的问题域定义了某种模式的Xml, 它已经足够灵活到可以用来描述你的问题域。DSLs包含的XML元素(Element)和属性(Attribute)代表了问题域中各种要素。

规则引擎有两种方式.一种是解析执行的方式,就是解析规则包文件,根据规则包中定义的逻辑解析执行.另一种方式是编译执行,就是直接将规则包文件中的逻辑编译成可执行的字节码,通过调用执行.

有人在项目中使用过Drools吗, 如果自己实现规则引擎, 具体该考虑哪些因素呢. 请使用过的朋友过来讲讲. 目前一般项目中有哪些使用规则引擎的例子.

正在做的一个项目涉及到了规则引擎，不过没有那么复杂，也没有使用到Drools。主要原因是感觉太复杂，不适用。
我们没考虑那么多理论上的东西，只要适用、满足我们的需求就可以。

使用了Groovy作为脚本语言来解释的。重点要解决的问题有
1、定制：规则的定制，复杂的js拼装。会考虑到加减乘除，大于小于等于，包含不包含之类的运算；
2、存储：转换为xml存储在数据库；同时生成Groovy脚本；
3、执行：解释执行；

其中最困难的是js的拼装。

基于rate的高效算法已经有现成的产品了：开源的是drools，商用的有ilog。
自己实现引擎？！你就能写的比它们还好？
不是一句两句说的清楚，简要提一下，还是要自己多看文档
规则引擎的适用场合：
规则引擎适用于规则会被 业务人员频繁修改的；规则需要被抽象的；规则复杂无法用常规方式解决或不好解决（比如排课，排位）
不合时宜的引入规则引擎到系统内，只会给自己找麻烦，增加培训费用和后期支持的痛苦。

理解规则引擎的适用范围和真实需求，衡量是否使用是重要的第一步，当然多数情况是拍板的人其实不懂找个
抽象 业务模型和规则模型，并在其间建立映射，业务模型将面对最终业务人员，规则模型为了matchdrools
定义业务规则，归类，制定规则流程
选用合适的drl，其实默认的就不错
实现自己的BRMS，drools自带的那个未免太太简陋了些
drools 目前的ruleflow功能很薄弱，但flow确实是很重要的功能

应该是基于RETE算法的规则引擎。

规则引擎首先要考虑到规则的表达方式，jamocha规则引擎利用了人工智能语言CLIPS来表达规则，其次就是考虑推理的算法，RETE、LEAPS、TREAT等都是为模式匹配所提出的算法。
RETE主要是将规则描述为内存中的rete网络，然后依据该网络，为到达该网络的事实根据推理算法进行模式匹配。
PS：我的博客上有关于模式匹配算法RETE的介绍。jamocha的圈子：http://jamocha.group.iteye.com/

看lz的理解还停留的美妙的销售语言中，还是先评估一下在做判断吧。
不是说规则引擎的坏话，技术本身是很棒的，如要应用起来就要考虑范围、方式了。
试考虑一下问题？
什么样的业务逻辑可以抽象出来作为规则逻辑处理？
规则引擎与系统的协作方式，如何定义明确的接口，特别是输入输出？
规则修改系统如何测试？