规则引擎在基础软件，或者在很多系统中已经不是稀奇的玩意，最近这几年，国内不断兴起很多的规则引擎，至于什么是规则引擎，在这篇文章中，就不做介绍了，我想能看以下内容的，多少对规则引擎也都有所了解了。
国内在2003年的时候，出了第一款商业规则引擎—旗正商业规则引擎（VisualRules），为什么这么说呢，因为再此之前，国内所用的规则引擎，都是国外产品，或者开源产品，纯自主研发旗正是第一款，直至目前为止，纯自主研发的规则引擎少之又少。那么旗正商业规则引擎到底怎样？今天，给大家介绍一下，顺便，我们拿出和DROOLS和其它几款规则引擎跑出的数据来一起看看。
我们通过实际测试操作,让旗正规则引擎（VisualRules）和其它几款主流规则引擎进行性能分析对比,并展示处理速度,内存占用,正确率等各项指标,分别来观察规则引擎的综合性能。
一、本地化
1.中文化需求
VisualRules相关的各个软件以及相关的培训和帮助材料等，以全部中文化的方式进行描述，在各个词汇以及功能的设计上，都是从中文的特点来出发进行设计的。
这一点在规则引擎的核心功能（业务语言描述业务逻辑）上体现的特别明显，VisualRules采用全中文化的语言来描述业务逻辑。不像JRules等采用纯英文（TRL是纯英文、培训和教程为全英文）、BRL（一般是英文，通过处理可以是翻译后的中文）等方式来描述业务逻辑，在表述上总会有一些牵强。
2.对使用者的要求
由于VisualRules从中文出发来设计和实现，并且从一开始就考虑了业务人员使用的要求，因此学习曲线非常低，对使用者的要求低。在业务规则的查阅以及修改方面，普通的有大专以上水准的人就可以快速的学会使用。在业务对象的设置以及业务规则的建立方面，学过计算机高级语言的人都可以快速学习掌握。这在用户培训上占用很大的优势，大大的节约了培训的成本。
而JRules等产品，一般除了要求用户有较高的英文水平之外，还需要学习其专业的规则语言，需要经过一个比较长时间的培训才能掌握。
二、安全性
1.政治风险
旗正公司是完全的国内企业，而且得到了国际科技部和财政部的创新基金支持，不存在政治风险。而国际公司会受到外国*的关于高新技术出口政策的限制，会有一定程度上的政治风险。
2.泄密风险
业务规则管理系统不像数据库，是一个完全独立成熟的产品，可以不涉及业务。业务规则管理系统的行业型特色非常强，总是需要针对行业的特点做一些完善和优化。特别在实现一些特殊需求或者涉及到性能优化等问题时，肯定需要规则引擎厂家的支持。由于国家税务是涉及国家安全的东西，因此如果采用国际产品，泄密的可能性会增加。
3.源代码
考虑到国税系统的安全性考虑，旗正公司可以根据国税部门的需要开放与业务规则运行相关的源代码，以保证国税系统可以安全放心地用规则引擎来执行各业务规则和政策。
而国际产品一般不会提供规则引擎的源代码，这样由于国税部门的特殊性，使用后可能会存在一定的风险。
三、性能测试对比
场景说明：准备10万条基础数据，生成中间数据300万条，执行20条规则，写入数据库20万条，通过不同的几款主流规则引擎对比，可以看出旗正规则引擎的优势。
1.规则执行速度
VisualRules从一开始就关注性能的问题，目前已经将规则的执行，从解析执行发展到编译后执行，这样的执行速度在所有的规则引擎的实现中是最快的。JRules等产品，虽然目前也做了此方面的优化，但是只是做到了部分编译后执行，因此在速度方面并不具有优势。
2.内存占用
为了能让性能发挥更好，我们在软件开发之初就制定了高标准要求，经过多年的不断研发和改善，旗正规则引擎在内存使用上成功超越了其它主流产品，这也是保证了我们产品拥有更好的稳定性。
3.CPU使用率
4.数据处理正确率
四、服务和支持
由于旗正公司是完全的国内企业，在服务以及技术支持上会更加的便利。
1.二次开发，业务系统集成性
由于业务规则管理系统不同于数据库等产品，业务规则管理系统肯定会根据具体业务规则的特点，在管理上会有所不同。因此管理系统会需要和业务系统结合，以满足业务系统的需要。
旗正公司可以派核心的开发人员和业务系统的开发人员一起制作和完善特定行业的规则管理系统。并且将规则管理系统和业务系统更好的集成。
2.服务价格，维护升级
由于旗正公司为完全的国内公司，在服务价格上会明显的低于国际公司。而且在后期维护升级上，也会优先考虑国税部门的需求。
而国际产品可能会优先考虑自己国家的要求，并不会像旗正公司一样重视国税部门的需求。
五、易用性
VisualRules从产品最初设计开始，就非常关注如何使用户使用简便，减少用户的工作量。
在用户的操作界面上，VisualRules对不同的操作员针对性的提供一些特定的功能。比如为开发人员提供了生成开发人员所熟悉的java语言，让开发人员可以用自己熟悉的语言更加深入的理解业务逻辑；为业务人员和管理人员提供了业务语言和流程图，可以用业务人员自己的语言来理解业务逻辑。另外VisualRules还提供了规则树的功能，就是可以以树状的形式定义了相关规则的相互关系，包括公共条件关系、循环关系、先后关系等。让用户在编辑规则阶段，就清晰的指导了规则执行的流向。
VisualRules针对国内项目基本都是基于数据库系统的特点，集成了数据库层，并且实现了数据库层的随时变更。还增加了大量的向导功能，以帮助用户可以非常方便的在规则中操作数据库。另外又可以让用户可以直接在编辑界面执行规则，这些规则执行的数据可以是测试数据。同时又提供了数据查阅的功能，可以直接在编辑界面就可以看到原始数据和规则执行后的结果数据。这些功能都使得用户可以非常方便的定制规则。
VisualRules针对规则变化时，可能导致规则包接口的变化。将接口采用map方式来存储，这样就使得所有规则包的接口都可以随时修改。同时结合了代码生成技术，可以为技术人员生成其他相关的程序代码，包括jsp代码、以及其他的java类代码。这样可以让技术人员仅仅通过配置页面，就可以生成一个完成的调用规则的应用。
VisualRules针对不同的用户，提供了不同的版本，下面讲述具体版本中VisualRules有具有的优点。针对技术人员，VisualRules提供了规则编辑器开发人员版，开发版有如下优点：
1.单个文件集中管理规则包相关的所有规则和业务对象
开发人员可以在同一个规则包中，处理和此规则服务相关的所有参数、数据来源、技术和业务词汇、业务规则。
而JRules等产品，却需要在不同的地方定义XOM、BOM、RULESET、RULE等，你很难在一个统一的地方全面的把握住该规则服务所需要的所有的业务规则和业务对象。集中统一的管理，可以极大地为用户提供便利，减少开发工作。
2.面向规则包的版本控制
同时集中统一的管理也为规则包的整体版本控制提供了可能。很多实际业务要求，同一规则服务，会在不同的时间段或者不同的条件下，会调用不同的版本（也就是具体其中某几个规则会有所不同），而这几个版本可能是同时都要有效的。因此需要针对规则包进行统一的版本控制。
而目前像JRules等产品，只能提供规则级别的版本控制，不能做到整个规则包级别的版本控制。
3.规则分值、循环类规则
在实际的业务规则实践中，总是会出现某些规则是只有满足某个公共条件才触发的，也会出现某些规则是在某个循环中的。VisualRules可以在规则集中设置公共条件或者是循环条件，以满足规则集下面的所有规则必须满足公共条件才能执行，或者是循环执行的。
而像JRules等产品的规则集，不能设置工作条件和循环条件，因此JRules不能对规则的执行进行有效的分支控制。很多时候其需要通过为每个规则设置大量的条件或者通过临时变量等变通的方式来解决，这样的解决方式非常牵强，就不能体现业务语言表述业务逻辑的特点了。
4.编辑阶段的java代码对照生成
由于技术人员使用规则编辑器，其更多的关注实际业务逻辑对应的技术映射是否正确，因此技术人员更加关注业务逻辑对应生成的java程序代码，而技术人员如果已经有java语言的基础的话，那么查看生成的java代码会比看中文化业务逻辑更加直观和便于理解。其原因也显而易见，因为中文描述的业务逻辑，同样一句话可能在不同的环境下，是不同的技术实现。因此如果要关注具体的实现细节，则需要查看实际的代码。VisualRules可以自动实时的生成对应的java代码，这会在测试以及查错方面给予很大的帮助。
而JRules等产品，只能看到TRL语言，这就要求技术人员重新学习一种新的语言，也不好理解。
5.规则包整体测试
VisualRules可以在编辑环境下，直接对规则包进行整体测试。测试时只需输入所需的参数的值，就可以查看到输出结果，以及可以看到整个规则执行路径以及对应的数据变化情况。这样就可以非常方便的对规则包进行测试检查，或者对下面的某个规则或者规则集单独进行检查。
而JRules等产品必须要在eclipse等开发工具下，单独编写相应的java程序来驱动规则包的执行以及进行调试测试，这使得测试等工作变得非常困难（比当初采用编码方式实现业务逻辑进行调试一样困难）。
6.规则集、规则的单元测试
VisualRules可以在编辑环境下，对规则集、规则、决策表等进行单元测试。这样就使分块查错变得非常容易。
而JRules等产品根本不支持单元测试等操作，除非另外增加一个只包含需要测试的规则的规则包来进行测试，这样就变得非常困难。
7.规则执行轨迹跟踪
当规则包被调用时，有时候用户需要知道这次调用到底**了那些规则，他们的先后执行顺序，以及调用此规则时，对业务对象的修改情况（进规则之前，业务对象什么状态，经过规则执行之后，业务对象变成了什么状态）。VisualRules可以将所有当次运行的这些规则执行轨迹记录下来，供用户进行查阅，或者存储在数据库中，供以后查阅。这在用户进行规则的查错时非常有用，可以马上定位到底是运行到那个规则时，发生了错误。
而JRules等没有提供这方面的功能。他只能通过调试来实现。
8.规则异常处理
VisualRules可以针对规则定义多种异常处理方式，通过设置规则属性就可以。这样就可以在规则内部处理异常情况。
而JRules等只能在规则包级别进行异常的处理情况。
9.动态的规则包调用接口
VisualRules支持外部调用直接以数值、字符串、类对象等多种方式将参数传入到规则包中，这样就使得接口的参数动态化。特别是当采用规则服务方式时，如果变动接口，不用去修改原先调用它的各个程序。
而JRules等必须要以类属性的方式来传递参数，这样就使得参数的传递不能动态化，规则服务接口不能方便的发生变化。
10.动态or映射
VisualRules从一开始就充分考虑基于数据库的项目的特点，大量的规则判断依据（比如参数以及原始数据、或者结果数据）都需要来源于数据库，因此VisualRules在业务规则处理的业务对象中，无缝集成了数据库层的操作。让规则操作数据库中的数据就像处理一个普通的业务对象一样方便，并且让数据库对象也像规则一样，可以随时改变。
而JRules等产品，却通过类对象来访问数据库，这样就不能使得数据库对象不能轻易进行变动，也使得操作和访问数据库变得非常困难。
11.基于JSP的业务系统操作界面自动生成
VisualRules可以在规则编辑界面配置生成调用此规则包的JSP页面，这样就可以轻松的完成操作界面的生成工作。这有点类似工作流中的表单设计器。只不过工作流中的表单设计器，相对参数比较固定，格式也统一。而VisualRules的页面配置器，却可以根据模板设计的不同，而生成针对不同项目特点的页面。JSP页面的生成使得测试规则变得更加容易，甚至可以用此功能轻松的开发完成一个完整的基于数据库的管理系统。
而JRules等工具却并不提供这类功能。
VisualRules专门针对业务人员提供了 规则配置器编辑人员版，编辑版具有如下特点：
12.带有用户身份认证的完整的规则编辑功能
编辑版由业务人员进行使用，必须经过用户名和密码的身份认证。这种身份认证可以和业务系统结合。并且通过规则的权限分配，用户只能查看和修改自己具有权限的规则。这就保证了规则修改的安全性。
而像JRules等工具并不能为业务人员直接提供一个完整的具有严格的身份认证的规则编辑器。其只能通过其自身的规则管理系统来进行操作。这就使得技术人员和业务人员的操作界面等不一致，增加了沟通的难度。
13.支持业务人员直接测试规则包和规则
对于规则包的整体测试，或者对于规则、规则集的单元测试，也在编辑版中提供。这样就使得业务人员直接可以在修改规则的过程中测试规则设定的正确性。
而JRules等产品需要通过调试等手段来检验规则的正确，这样就只能由技术人员才能测试规则以及验证其正确性。
14.编辑阶段可查看来源数据
编辑版不能对对象库中的数据库层进行操作，也就是说不能直接操作数据库。但是可以提供功能供用户直接查看来源数据，这样业务人员在编辑规则时，如果需要查询数据，就不需要通过报表系统去查询，直接在编辑界面就可以查看对应的数据库中的来源数据，这样可以大大减轻开发的工作。
而JRules等产品，并不提供这类功能。
15.支持多种样式的决策表
VisualRules针对国内决策表的特殊情况，设计了多种决策表，包括表格类决策表、多维决策表、关联决策表。当然也可以根据业务系统的实际需要进行扩展。这些不同类型的决策表，使得业务人员可以更加简单方便的表述业务逻辑。
而JRules只提供了一种决策表的实现，而且这种决策表在描述国内的业务需求时，并不能很好的进行描述。
16.支持规则包的流程图显示
VisualRules可以在编辑阶段直接生成一个包含了全部业务逻辑以及流向的流程图，这个流程图可以导出成html，发送给相关的人员查阅或者审批。这使得业务人员可以在一副图中，看到所有相关的信息，非常符合中国人的思路，易于国人理解。在具体的流程显示时，还可以将只有技术人员才关心的一些规则隐藏起来，让流程图只显示和业务相关的逻辑。
而JRules只能提供局部流向图，并不能将具体的规格内容包含在其中，也不能在一副图中描述整个流向图。
17.支持用户修改轨迹记录
VisualRules在规则编辑阶段，在修改用户的信息记录在被修改的规则文件中。这样就可以跟踪到某个规则，在什么时候被谁进行了修改。
而JRules等产品，却并没有对编辑用户的信息进行记录。
总的来说，VisualRules针对国内用户的特点以及基于数据库项目的特点，增加了很多易用性方面的功能。这些功能大大的简化了用户的工作，真正的将业务规则的编写可以由业务人员来设定和审阅。另外VisualRules可以针对国税系统的情况，完善国税系统所需要的各项功能，以求最大限度地满足国税系统的需要。