|
锁定老帖子 主题：规则引擎
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-03
:wink: 本人觉得：计算机应用的进一部发展，只能是应用一种新的开发语言。而这种语言不再是面向计算的，而是面向逻辑的。
 建议大家都学习一下：数理逻辑。
另外，最好是增加哲学方面的修为  。
|
| 返回顶楼 | |
|
发表时间：2005-10-17
大家对BRMS,特别是规则引擎将来的发展有什么看法呢?
|
| 返回顶楼 | |
|
发表时间：2005-10-18
不必特意用过于复杂的例子来否定规则引擎，如果这样的话，那么工作流引擎也一样，完全可以举出过于复杂的例子来否定工作流引擎的作用。
移动和电信的计费系统，都是相对的简单而大量的规则组成的规则库，其实都可以归结为规则引擎，而它们也都或者主动或者被动，走上规则引擎的领域。 乍看之下，规则引擎和工作流引擎似乎有相当的重叠，但仔细考虑，工作流引擎是纵向的，而规则引擎是横向的。有些系统，本身就是苗条型的，单用工作流足已；有些系统，本身就是肥胖型的，单用规则引擎足以；有些系统，可能就要工作流加规则引擎了。 |
| 返回顶楼 | |
|
发表时间：2006-01-10
先给大家贡献我收集到的JAVA的规则引擎实现。
一、Drools： Drools是一个Bob McWhirter开发的开源项目,实现了JSR94 Rule Engine API并提供了单元测试代码。 应用了Rete核心算法。Drools提供了三种语义模块――Python模块，Java模块和Groovy模块。 站点：http://drools.org/ Drools- 商务逻辑框架的选择： http://www.matrix.org.cn/resource/article/44/44046_Drools+Framework+Business.html 在你的企业级java应用中使用Drools： http://www.matrix.org.cn/resource/article/43/43782_Drools.html 详解Java规则引擎与其API http://www.360doc.com/showWeb/0/0/19281.aspx Ilog、Drools、Jess规则引擎的Rule Language 比对 http://it.13520.org/ArticleView/2005-9-5/Article_View_46215.Htm 二、Mandarax Mandarax是一个规则引擎的纯Java实现。它支持多类型的事实和基于反映的规则，数据库，EJB等等， 支持XML标准(RuleML 0.8)。它提供了一个兼容J2EE的使用反向链接的接口引擎。 站点：http://mandarax.sourceforge.net/ 三、JESS http://kb.csdn.net/java/Articles/200509/8c98bec5-aa3e-4307-8a2c-bed0ca3a7bcc.html 四、JLisa JLisa是一个利用java构建商业规则的强大框架。它实现了JSR94 Rule Engine API。 站点：http://jlisa.sourceforge.net/ 五、OpenRules OpenRules基于java完全开放源代码的商业规则管理框架。它有效的利用了MS Excel, Eclipse IDE 和其它java开源类库去构造，维护，部署，执行不同的复杂商业逻辑的规则引擎。 站点：http://openrules.com 六、JEOPS JEOPS(The Java Embedded Object Production System)是一个基于Java的演绎法(Forward-Chaining)规则引擎.这个规则引擎被用于在Java 应用服务器,Java客户端程序,和Servlets中通过规则来提高它们的商业处理能力. 站点：http://sourceforge.net/projects/jeops/ 七、InfoSapient InfoSapient是一个开源的规则引擎.它设计用来表达,执行和维护在同一个公司中商业规则.InfoSapient基于纯Java开发,使用到MVC,Visitor,Strategy,Facade,Factory Method,Observer,Iterator等设计模式. 八、Prova language Prova (from Prolog+Java) is a rule-based system for Java and agent scripting and information integration extending the Mandarax engine with a proper language syntax and enhanced semantics. The language breaks new ground in combining expressive and declarative programming. It combines natural syntax and typing of Java with Prolog-style rules and database wrappers. Java calls may include both constructor and method calls as wellas access to public variables in classes. Distributed and agent programming transported via JMS or JADE protocols is based on reaction rules specified in a natural syntax. The language makes it easy for agents to engage in concurrent conversations without starting new threads by using reaction and novel inline reaction rules in a very natural and ecoonomic syntax, directly capturing conversations as state machines. 站点：http://comas.soi.city.ac.uk/prova 九、Open Lexicon Open Lexicon is a business rules and business process management tool that rapidly develops applications for transaction and process-based applications. It includes a business rules metadata repository, a business rules engine, and a comprehensive web-based UI for managing and testing the busines rules. It also includes process management tools for orchestrating complex interactions within business rules and business objects. 站点：http://openlexicon.org 十、Prova A Language for Rule Based Java Scripting, Information Integration, and Agent Programming 站点：http://www.prova.ws/ 十一、Euler Euler is an inference engine supporting logic based proofs. It is a backward-chaining reasoner enhanced with Euler path detection. There is a 100% Java version, a C# version and a Python version. 站点：http://www.agfa.com/w3c/euler/ |
| 返回顶楼 | |
|
发表时间：2006-01-13
Trustno1 写道 其实，除了这种基于决策树的推理机，现在更加主流的是基于先验概率推理的方法，也就是我以前提到过的贝叶斯学派。对于数据分析数据挖掘来说，这种方法要比决策树更加有效。很多时候，我们需要得到的甚至是我们能够得到的只是某个事件的或然率.就实际应用来说，目前贝叶斯推理要比以Prolog为代表的古典的决策树系统应用更加广泛。Google的成功就是最好的例证。不过这个学派和通常的概率频率派在理论层面有着非常大的冲突，但是从工程面上讲各有各的用处。
这里是篇贝叶斯公式的介绍。虽然说贝叶斯推理源于这个公式，但是现在的贝叶斯 推理已经是面目全非了。 http://dev.csdn.net/Develop/article/39/39756.shtm 下面是一个非常简单的贝叶斯网络的介绍 不知道所谓的“更加主流”这个结论是如何而来，也许是因为google的名头吧，。就模糊推理而言，这种基于概率论的算法，至今仍然处于非常基础的理论研究阶段，几十年间进展缓慢，达到应用的水平更遥遥无期。前面帖子已经有人说明过，rule engine 是形式化的逻辑，基于模式匹配rete算法。gigix提到的每秒几万次的匹配量只是一个理论值，实际应用中感觉性能依然是主要考虑的因素，主要的rule engine实现应该差别不大，关键还是看性能能不能能够达到应用的水平。 |
| 返回顶楼 | |
|
发表时间：2006-01-13
armlinux-w 写道 谢谢。
gigix 写道： 引用 有N条规则与事实库匹配，就执行N条规则的行为
规则引擎会去执行 action。 我想相应的action 应该 是在我的代码中实现的。 我的意思是， 应该有从 RuleEngine 到我的 OO 代码中的action 的调用机制。 类似于回调。 是这样吗？如果有， 是怎么实现的？ reflect. |
| 返回顶楼 | |
|
发表时间：2006-01-13
ozzzzzz 写道 大概我在96-97年开始关注规则的问题,那个时候我还没有什么明显的开发方法的概念.即使到今天我对这个问题的研究也没有太多的答案,而是由太多太多的问题.既然大家讨论规则引擎,我就顺便把我对规则问题的思考和疑问介绍给大家.
首先明显的一点,使用规则会对你的需求了解的过程,造成深刻而无法预料的影响.因为使用了规则,所以你的程序中表达的业务就可以划分为业务数据对象和业务规则两个部分.需求分析阶段了解的主要部分则有传统的对于对于需求的全范围的建模变成对需求中的业务所表达的数据进行建模.而对于业务规则的建模在向后推延到实施阶段。 其次业务规则的定义将会给需求分析的方法带来根本性的改变。由于业务规则将成为一种可以动态调整的部分，从而在初期将这些部分从需求在程序中固化下来的部分进行区分就是完全必要的。而这些区分的原则将非常重要，并且也会非常微妙。这里我们可以分析一下前面那个例子： 引用 开车”的规则有说“如果绿灯亮，前进”，也有说“如果前方有人，停车”，那么既有绿灯又有行人时该怎么办呢？你就必须指定第二条规则优先级高。但这些都是在规则里面定义好的，你不应该在运行时干预规则引擎。
在这个例子中判断绿灯亮、前进、判断前方有人、停止、问候前方人的母亲，这些都是规则，但是这些部分基本不会发生变化，所以应该固化在程序内部。而实际上进一步，前方有人-停止和前方绿灯-前进，这两个规则也是基本不会被更改的，也是需要固化的。但是这种逻辑实际上还是有可能在某些情况下被更改的，这就需要对这些规则留下动态屏蔽的能力。而实际上经常进行改变的，是对于前面绿灯-前进和前面有人-停止，这两个规则优先次序的判断逻辑，这个部分无疑是应该完全用规则引擎来管理。然而实际应用的情况要复杂的多，比如一张订单可以包括10个货物栏。这个时候，首先我们要明确知道这个规定注定会影响数据的存储逻辑，而数据的存储逻辑实际上是应该放在数据访问层中的。下订单这个业务行为也非常难与定义为一种业务逻辑还是一种行为职责，也就是产生订单这个行为是用一个程序的动作去实现，还是用一个规则引擎的规则实现？当然你可以先使用一个程序的动作实现，然后确定一个屏蔽的方法调用。而实际上我们遇到的情况将比这个复杂的多，需要你作出非常多的权衡。而实际上确实存在这样的一种可能，也就是你的程序的业务层中将不会再有具体的业务行为的业务对象，而只是一些单纯的数据对象和一些的方法对象，而这两者之间的联系仅仅依靠规则引擎来连接。而我认为在这样的情况下kiss将是必须遵守的。
所以第一个问题的答案是：你不应该自己选择。如果你要自己选择，那不就回到了原来的做法、在程序里写一大堆if...else...吗？那还要规则引擎来干什么呢？还是用上面这个例子，你可以再加上一条规则：“如果（绿灯亮 并且 前方有人），问候车前行人的母亲”。 而实际上对于需求分析的影响将是使用规则引擎造成的一个最为值得关注的问题，需要使用更加新鲜的分析方法。原来的基于数据和过程的认识系统，必须将过程和过程中的逻辑判断区分开来，并且进一步将逻辑判断划分为规则和流程所自身私有的规则加以区分。实际上这就意味着工作流引擎应该和规则引擎互相的可以调用，也就是说在每一个流程的节点都可以植入一个规则引擎的接口。（而实际上我认为是有AOP来设计一种规则和流程公用的引擎将是一种思路。） 同时由于规则引擎的引入，将会给测试造成的影响也是非常多，这一点大家应该比较好理解。实际全面的应用规则引擎将给你的日记开发的全过程造成非常重要的影响，而首先要解决的问题就是你必须决定要把什么东西放到规则引擎去完成，基本上可以认为一个项目的成功与否在这样的情况下关键就在此。 强烈同意。 |
| 返回顶楼 | |
|
发表时间：2006-01-13
引用 所以第一个问题的答案是：你不应该自己选择。如果你要自己选择，那不就回到了原来的做法、在程序里写一大堆if...else...吗？那还要规则引擎来干什么呢？还是用上面这个例子，你可以再加上一条规则：“如果（绿灯亮 并且 前方有人），问候车前行人的母亲”。
我对象drools之类的专业规则引擎并没有深入的研究，所以不好说使用这些产品是不是就不需要if/else。 但是，我反对简单化地逃避if/else。为什么需要if/else？因为这是需求逻辑的一部分。用多态还是if/else并没有从本质上改变问题的性质。 一般来说，写在程序里的if/else有代码繁琐，不容器修改，扩展等问题。 但是，如果if/else操作的是纯粹的业务逻辑，而不是底层的实现数据结构，那么，代码繁琐问题就不存在，而修改，扩展问题也几乎可以忽略。 试想，我们有一个脚本语言，它可以让我们直接地描述业务逻辑： if 红灯 那么 停止 否则 如果 绿灯 那么前进 否则 如果 黄灯 那么小心 否则 如果灯坏了 那么 停车 此时，if/else直接作用于业务逻辑，而不是底层的实现代码，（也就是co的高阶逻辑），用if/else在我看来非常自然简单，根本没有必要去刻意避免，需要用的话用就是了。 |
| 返回顶楼 | |
|
发表时间：2006-02-17
ajoo 写道 引用 所以第一个问题的答案是：你不应该自己选择。如果你要自己选择，那不就回到了原来的做法、在程序里写一大堆if...else...吗？那还要规则引擎来干什么呢？还是用上面这个例子，你可以再加上一条规则：“如果（绿灯亮 并且 前方有人），问候车前行人的母亲”。
我对象drools之类的专业规则引擎并没有深入的研究，所以不好说使用这些产品是不是就不需要if/else。 但是，我反对简单化地逃避if/else。为什么需要if/else？因为这是需求逻辑的一部分。用多态还是if/else并没有从本质上改变问题的性质。 一般来说，写在程序里的if/else有代码繁琐，不容器修改，扩展等问题。 但是，如果if/else操作的是纯粹的业务逻辑，而不是底层的实现数据结构，那么，代码繁琐问题就不存在，而修改，扩展问题也几乎可以忽略。 试想，我们有一个脚本语言，它可以让我们直接地描述业务逻辑： if 红灯 那么 停止 否则 如果 绿灯 那么前进 否则 如果 黄灯 那么小心 否则 如果灯坏了 那么 停车 此时，if/else直接作用于业务逻辑，而不是底层的实现代码，（也就是co的高阶逻辑），用if/else在我看来非常自然简单，根本没有必要去刻意避免，需要用的话用就是了。 if,else的缺点是条件一多就不好控制了,此时应该用OO的思想来解决,可以参考jarkata的commons-collections这个项目,里面的functors包,可以用Predicate,Closure,Transformer来代替if,else,switch,for,while 就像hibernate里面,查询条件多了的话,用Criteria来代替hql一样 commons-collections在做规则匹配并且执行某些动作这个功能上可以代替规则引擎,但是规则引擎有一个很重要的功能,就是可以监测事实库的改变,并且把改变过的事实库再次放入规则引擎重新匹配,可以看看drools的fibonacci的例子,还有规则引擎会从事实库里面排列组合方式的取一定数量的对象来匹配规则,不需要自己去写算法,这些只是我对drools的一些了解,其他规则引擎就没接触过 |
| 返回顶楼 | |
|
发表时间：2006-02-21
引用 commons-collections在做规则匹配并且执行某些动作这个功能上可以代替规则引擎,但是规则引擎有一个很重要的功能,就是可以监测事实库的改变,并且把改变过的事实库再次放入规则引擎重新匹配,可以看看drools的fibonacci的例子,还有规则引擎会从事实库里面排列组合方式的取一定数量的对象来匹配规则,不需要自己去写算法,这些只是我对drools的一些了解,其他规则引擎就没接触过
打算学习下提到的这个包， if/else 只是对应到 规则引擎中的rule,那么规则引擎还包括的其它部分 rule editor, pattern, working memory , agenda, 这些概念不再这里一一介绍了。 working memoery 对应的就是楼上说的事实库，是一个操作对象的集合。简单地说。操作对象的改变可能导致pattern 重新匹配，匹配后可能产生新的规则集，新的规则集会到agenda中进行对比检查，已经存在和触发的规则不会再加入，其它的规则会根据规则的相关性和优先级进行排序后加入agenda。 可以说，整个过程具有很高的复杂度和不确定性，这也就是说，采用了规则引擎，整个系统的测试将是一场恶梦。说得很简单，大家有时间还是看看前面ozzz的文章把， |
| 返回顶楼 | |
