商业规则引擎
ILOG JRules
Ckrule规则引擎
百度知道
旗正规则引擎
......
网文学习（joeyshi）
......
如何在工作流等开发平台中集成规则引擎 2009-05-12
如何在规则引擎中集成数据库操作 2010-07-13
业务规则分类 2010-07-15
Rete算法的缺陷 2011-05-02
旗正规则引擎设计思路 2011-05-03
华为公司博士招聘交流会
IBMOperational Decision Manager 是一种功能齐全、易于使用的平台，用于捕获、自动执行和治理频繁出现的重复性业务决策。它包含两个组件 - IBM Decision Center 和 IBM Decision Server。它们构成管理和执行业务规则和业务事件的平台，帮助用户更快地做出决策，提高反应能力，降低风险，抓住商机。
IBM Operational Decision Manager 有助于提高与事务和流程相关的决策的质量，同时帮助确定与客户、合作伙伴和内部人员互动的行动方针。它能够改进业务洞察和结果，帮助您发现商机和风险。它还能帮助您实施、测试并部署决策变更，了解如何做出决策，以及如何在流程和应用中一致应用这些决策。
IBM Decision Center 提供了一个集成的存储库以及多个管理组件，使特定领域的专家能够保存和管理自己的业务决策。
IBM Decision Server 提供使决策逻辑自动化的运行时组件，支持基于交互环境检测业务情况并进行准确响应。
~、请问一下Ckrule规则引擎的作用是什么？
CKRule是一个业务规则管理和复合事件处理的综合性引擎，可以将企业管理策略的定义，部署，管理和维护工作从核心代码中分离。企业将深入的业务决策整合到程序，并把市场变化因素以业务规则的形式进行更新。
基于web应用来说，通常分为三部分：界面层、业务逻辑层和持久层。在制作开发平台是，我们都是在这三方面做工作。由于这三层的特点有些不同，因此我们会采用不同的实现方式来实现。
界面层，强调的是操作界面，因此我们注重采用所见即所得的方式来调整界面布局以及界面样式。更多的我们可以会做一个表单设计器。
业务逻辑层，我们强调逻辑调整的便利性，我们会采用动态语言或者规则引擎来实现逻辑的配置。
在持久层，我们会采用领域模型，根据定义MetaData来定义结构，从而实现和持久层的访问。当然持久层不全代表是数据库。
所有的开发平台都是在这三方面做工作，本文主要研究业务逻辑层的实现，我们在国内出现的开发平台中，看到基本都是用代码来实现业务逻辑层的。不过是动态语言还是连接外部程序。比如工作流中一些前续事件和后续事件等。很少看到采用规则引擎来实现业务逻辑的配置。
究其原因就是基于推理方式的规则引擎并不适合普通业务逻辑的编写。
因此我们需要制作一个不采用推理方式的规则引擎，而采用我们传统的编码逻辑方式的规则引擎。我们可以称之为简单规则引擎。
没有了冲突推理后的规则系统，将更加简单的来实现业务逻辑。因此其不用再考虑规则优先级，冲突、关联之类的事情，无需再担心某处的一个简单的改变带来了大量无发确定的后果。实现了易用以及灵活性的完美结合。
由于目前并没有成熟的开源项目来满足这类需求，因此我们需要自己来实现这类引擎。
如何来实现呢，我们可以从当前已经实现的基于语言的配置入手。
当前我们已经实现编写脚本来实现业务逻辑。我们现在要做的就是规则的配置界面，可以自动生成这类脚本。
因此，第一步，我们需要建立一个业务语言和脚本语言的映射，如果我们是基于java的项目，就可以直接采用java语言作为脚本语言，然后利用java的动态加载机制，实现规则实时应用。
第一个java中的对象和业务语言的对应，这在目前各类商业的规则引擎已经做的很好，可以参考。实现BOM和XOM的对应关系。
然后我们只要做一个配置界面，可以来定义调用这些java的对象，由于已经建立了java对象和业务语言的对应关系。因此配置后的逻辑界面其描述就是以业务语言来描述。
最后，我们就是将配置的逻辑，存储到我们的业务系统中，供工作流的某个节点调用。工作流的节点中只要指定了规则名称以及需要传递的对象，就可以将数据传递到规则中进行处理。
如果能够将当前工作流的脚本编辑界面直接替换成规则的开发界面，当然更加好一些。
在一般的项目开发中，用的最多的是基于数据库的管理系统，虽说现在对关系型数据库出来了很多的替代方案，但是在实际正式的项目中，我们基本上还是使用关系型数据库来进行开发。
在项目开发的过程中，我们主要是抓住几个关键的地方。一个就是数据库结构的设计，以及操作该数据库的SQL语句。虽说现在Hibernate等可以不用再书写SQL语句来进行开发，但是对于高级设计人员来说，SQL语句还是最简洁和快速的开发方法。书写一个复杂一些的SQL语句，可以极大的提高性能和减少开发工作量。
第二个关键的地方是对数据的处理逻辑，现在做系统喜欢组件化、服务化。就是说我一个服务，或者说一个数据处理逻辑，我可以开放不同的接口供不同来源的客户端调用。比如可以通过HTTP提交的方式来调用，可以通过SOAP的服务来调用，可以通过Ajax的提交来调用，可以通过SOCKET通讯来调用等等。因此保证数据处理逻辑的正确稳定，是最关键的，这个涉及的系统的安全性和稳定性。
第三个关键的地方就是用户操作界面，用户操作界面目前用的最多的还是DHTML和Javascript，当然有些应用中用到Flex等技术，但相对应用还是比较少。用户操作界面的改进要求，表面上看是最不重要的，但是确实用户最关心的，也是用户意见最大的地方，也是最消耗程序员工作量的地方。
现在的系统开发，不希望重复制造轮子，因此有很多现有的技术可以用。比如在数据库层，用了Hibernate或者IBatis等，在业务逻辑层，用到Spring，Struts等，在前端界面层用到了Ext，JQuery等。
但这些只是一些底层的框架，在此基础上，还需要在封装一些平台或者组件。现在主流的就是工作流平台。目前的工作流很多时候，已经不完全是专门为工作流服务的了，都或多或少带了一些快速开发平台的功能。因为在做工作流的过程中，除了处理了核心的流程控制、权限控制、表单设计、数据结构之外，都会觉得其实大部分的应用开发，都可以采用工作流的这些表单设计以及流程控制来走。因此就在此基础上，扩展了相应的功能。
但是由于工作流主要侧重在于流程的控制，当很多应用都通过工作流引擎来处理时，发现性能是个很大的瓶颈。或者说有些功能，工作流实现起来非常麻烦，又要扩展工作流，使得功能变得太复杂，难以维护。
因此在工作流平台的实现中，就会希望将一些非流程控制的部分，和流程控制部分分离出来。这就是规则引擎的初衷，希望规则引擎能单独处理非流程控制部分，并且处理好性能。
但是目前主流的一些规则引擎其初衷并不是去处理这些部分，而是管理复杂、雷同、数据结构稳定的业务规则。因此只有在规则引擎中集成了数据库操作，才能满足工作流引擎中，处理非流程控制部分。
要实现在规则引擎中集成数据库操作，首先必须使得数据库层是动态的。比如像现有的Hibernate等就不能支持动态的特性，因为Hibernate需要根据XML说明需要重新生成Java类，而这些类的应用必须重新启动服务器。因此首先需要开发一批能够动态变更的数据库层。在此基础上，在规则编辑器中，增加对数据库结构的动态获取支持，也就是说可以直接去读取数据库中的表结构等，对应的得到相应的数据库层。
只有在这两个基础上，规则引擎集成数据库层才真正有用。规则引擎来实现业务逻辑控制时，才真正的体现出大量的节约的开发工作量，也使得业务逻辑层的实现变得简单。
这样，就可以将更多的精力集中在数据库结构的设计以及用户操作界面的改进。
最近几年，在很多的产品中越来越重视业务规则引擎的实现。比如IBM目前主推的一些产品线中，单独针对业务规则进行了强化。但是在实际的项目应用中，却发现究竟哪些应用，或者那些规则适合采用业务规则引擎来进行实现，而其他的一些规则适合采用工作流引擎或者报表引擎来进行实现。
这个问题，其实和不同规则引擎的适用面有关。一般的规则引擎，最适合是那些数据结构确定的业务规则的处理。特别是这些规则是非常雷同的，可以说是平级的，然后反复的对同一批数据进行匹配处理。比如电信计费规则，是针对用户的使用数据，有很多同级的套餐规则，然后将这些数据，用所有的套餐规则算一遍。这些套餐规则，基本都是平级的，偶尔有些具有先后顺序的，也只是采用一些标记来进行控制。
就这类业务规则引擎来说，规则引擎的应用还是非常单一的。如果规则非常少，或者说和数据结构的关系比较紧密，就不适合采用规则引擎来做。这类业务规则，可以在工作流引擎中，有些直接就采用sql语句等解决，或者说采用脚本语言来进行解决。因为规则引擎的应用反而显得非常累赘。
业务规则引擎经过扩展功能后，需要加上对数据结构的变更支持，特别是支持数据库结构的变更。这样的话，业务规则引擎就不仅仅只是对数据处理逻辑的实现，而且是数据层的处理实现。
这类业务规则引擎，就可以将绝大部分的项目中需要用到的后台逻辑采用业务规则引擎来进行实现。如此一来工作流引擎的压力就会大大减少，其只需要处理表单、流程控制等，其他的一概都可以交给规则引擎来进行实现。工作流就只需要处理流程相关的一些数据结构，即使一些业务数据，也只需要事先传给工作流实例就行了，而不需要再去考虑业务相关的其他一些数据结构等。
在此类业务规则引擎的基础上，就可以对业务规则进行一个分类。不同的分类采用不同的管理方式。
某一类业务规则，是纯粹和数据库结构相关的。比如增、删、改、查的逻辑等。这类业务规则侧重于数据的类型转化，或者一些简单的处理，大量的都是数据库操作的SQL语句等。这类业务规则一般都由技术人员来进行维护，因此在采用规则引擎进行实现时，这类规则就没有必要放到业务规则管理系统中，进行一些权限控制、版本控制等。而是有技术人员通过自身的配置管理技术来进行维护。在处理这类业务规则时，特别需要注意的是减少数据操作的次数。因此数据尽可能在规则中处理完，然后再交给数据库去处理。
另一类业务规则，是业务人员比较关心的，特别是一些表格类的规则，比如像一些决策表，或者一些参数表，基础数据表。这些表业务人员一般情况下，喜欢采用Excel来进行维护。对于这类规则，就需要将这类表格还是采用Excel来进行维护，同时在规则引擎的实现中，将Excel表格数据进行集成。这类规则需要采用业务规则管理系统进行管理，供业务人员查阅和修改。
在后台的业务规则处理中，基本上分为这两类业务规则。因此在具体的实现中，要注意加以区分。
目前的规则引擎厂家大量采用rete算法来作为规则引擎的核心技术，但是rete算法其出发点是为了人工智能的应用使用，并不适用于一般意义上理解的企业信息化系统中的商业规则管理。
就规则引擎来说，主要涉及几块：
1、数据对象：在采用rete算法的规则引擎中，数据对象就是需要采用规则处理的数据。因为rete算法只能对类对象进行匹配处理，因此在执行时，必须先为其准备好基础数据。必须已经汇总好的数据，或者已经统计好的一些数据。
2、规则语言：一般规则语言都是采用一种类java语言来定义，其实相当于一种动态语言。
3、解析运行：基于rete算法的规则引擎一般都会将采用规则语言编辑的规则，直接导入到内存中，然后通过内存的匹配来对数据对象进行。
采用上述技术，面对几个问题：
1、数据准备工作量大。在将一些数据进行处理时，需要准备大量的已经计算好的数据。这样的话，像数据过滤逻辑、预处理逻辑、数据转换逻辑、存取数据逻辑等就必须采用编写程序的方式来进行。工作量很大。
2、数据结构变化时，不能像规则一样动态变化。规则引擎使用的目的是为了企业系统将来在修改业务规则时，不再需要去修改程序。但是采用rete算法，使得只有规则能够动态变化。而数据结构的变化却不能，因此这限制了规则引擎的应用。
3、规则语言编写太多专业。规则语言其实比写java代码简化不了多少，工作量仍然很大。
4、消耗资源多，性能较差：采用rete算法的规则引擎在处理共享的资源时，消耗资源太大。性能比较差。
很多人都有疑惑，既然已经有很多成熟的规则引擎产品，并且开源的规则引擎产品也有很多，应用也很广泛，又何必去搞一个商业的规则引擎产品呢。在国内的环境下，并不认同这类商业的中间件产品，特别是国产的。
但是国际上的规则引擎产品实在太贵，因此旗正最初的想法也是希望能够使用开源的规则引擎产品进行改造。
规则引擎有一套约定俗成的标准，就是基于rete算法。特别是出来了JSR94标准之后，虽然说JSR94标准中只是约定了接口，并没有规定算法。但是JSR94标准的接口是事实上承认了基于rete算法的实现机制的一种应用。因此很多时候会感觉没有rete算法好像就不是规则引擎产品一样。很多规则引擎厂商从一开始介绍自己产品，都是先介绍rete算法的原理，以及说明自己的算法有多么先进。
按照这些通用标准，旗正也走了很长时间的弯路。利用开源的规则引擎来实现rete算法，然后在此基础上，制作规则编辑器。但是做了这些扩展之后，发现基于rete算法的规则引擎是非常的不灵活。应用面也很小，特别是在一些通用的管理系统中，根本就没有什么用武之地。而且性能也很差，异步调用时经常出现资源共享的问题。
因此在此前提下，不得不对规则引擎的算法本身进行改进。经过长时间的实践之后发现，其实没有rete算法的规则引擎反而更好。很多国际上的产品，其实都类似的使用了没有rete算法的规则引擎，但是并没有冠以规则引擎产品在单独销售。因此旗正公司最终决定研发没有rete算法的规则引擎。
在此前提下，发现其实规则引擎的路更宽了，而且在性能、应用面、易用性等各方面都可以比一般的规则引擎产品做得更好。
经过长时间的产品研发和项目应用之后，回过头发现其实不采用rete算法的决策是正确的，虽然说这需要挑战国际标准的权威，但毕竟事实证明了不采用rete算法的规则引擎更好用，也更加实用。
由于原理的不同，与采用rete算法的引擎相比，以下一些指标优势非常明显：
1、性能：比采用rete算法的规则引擎，速度至少快100倍，特别在批量的数据处理性能上。同时消耗的内存以及CPU资源更好。
2、易用性：由于不采用rete算法，这样制作更多可控的规则配置界面，在操作界面的制作上，更加灵活。而且不采用rete算法，就不用培训和理解此算法，因此学习曲线也更低。
3、应用面：基于rete算法的规则引擎，基本上还是只适用推理类的规则。对于数据校验、数据预处理、数据存取、数据转换等规则，却根本不能用。而不采用rete算法的规则引擎，也可以来配置这些规则，这样使得应用面也更广。
如果希望将系统中涉及的业务规则全部采用规则引擎来进行管理，那么rete算法将是一个障碍。摒弃rete算法，提高实用性，是规则引擎产品研发正确的方向。
招聘领域：
算法设计与应用、系统与结构、编译优化、软件工程、数据库、计算与应用数学等专业 复杂事件处理研究工程师
岗位要求：
1、算法设计与应用、系统与结构、编译优化、软件工程、数据库、计算与应用数学等专业
2、深刻理解状态机、规则引擎的运行机制及实现方法，有使用算法解决大型复杂问题的经验
3、动手能强，具有Esper、Storm、S4、SASE等开源技术的实践经验
4、至少精通一门编程语言，例如 Java、C/C++
岗位职责：
1、从事ESP和CEP的语言设计，编译优化，复杂事件状态表示机制等相关技术的研究开发
2、从事高性能ESP与CEP系统的分布化技术研究，包括匹配算法设计，并行状态机，状态机重分配等
3、从事复杂事件处理系统集群管理，内存管理，数据迁移，数据本地化等技术的研究开发
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
