您所在位置：主题：规则引擎Visual Rules特点价值
p635343
[专家分：0] 发布于 2010-12-17 08:56:00
VisualRules是在规则引擎基础上发展出来的一款产品，其秉承了规则引擎可以使业务逻辑的变化可以独立于程序之外的特点，同时结合国内软件项目的特点，为数据库层和界面层也提供了独立于程序之外配置的特点，因此本产品不光是一个业务规则管理系统，还是一个基于规则引擎的web快速开发平台。与国际上其他的业务规则管理系统相比，本产品具有以下特点：
顺序执行的规则引擎算法
传统的业务规则管理系统，其规则引擎的算法基本上会采用reta算法，其基本原理是运行阶段判断哪些规则符合条件，然后去决定其执行轨迹，这类似于人工智能的思想，当然其最初出发点也是为了人工智能判断。由于业务系统业务逻辑的频繁变动，因此希望可以利用规则引擎来实现业务规则的配置，因此也就自然将reta算法作为业务系统中业务逻辑的执行算法。但是这两者其实是不一致的，业务系统中的逻辑一般是确定的，有着明确指定的执行先后顺序的。而reta算法是动态决定顺序的，因此在用reta算法描述业务逻辑时，往往显得非常琐碎，并且其速度也比纯粹用程序描述要慢很多。VisualRules不再采用难以描述业务逻辑的reta算法，而采用顺序执行的算法来描述业务逻辑。这样描述业务逻辑和并平时用流程图和文本来描述业务逻辑就没有多少区别。可以最简单话的配置业务逻辑，同时其速度和手写程序的速度是一致的。VisualRules是真正的为业务系统中业务逻辑的实现而设计的，是软件项目业务逻辑实现的最佳选择。
公共规则、循环规则、关联决策表
由于规则执行算法基于顺序执行的算法，因此在描述业务逻辑上比reta算法有更多的展现形式，特别是可以通过规则集来定义多个规则的共同条件以形成执行的分支，或者用来描述循环运行的一组规则。另外在决策表的支持方面也有三种方式，二维决策表、多维决策表以及关联决策表，以更方便的形式来描述逻辑。同时规则还支持否则如果(elseif)方式的条件，进一步增强了规则描述业务逻辑的能力。
动态的参数接口、数据库接口和Excel接口
传统的规则引擎如JSR94描述的规则引擎调用接口采用Java类来传递值，这种方式使得接口的数据结构不能像规则一样变动。VisualRules通过Map来传递值，因此其接口的数据结构是可变的。同时传统的规则引擎一般可以通过设置来直接调用Hibernate等外部数据库对象，这样其实就是通过类和XML来定义了数据库的调用接口，这种方式就不能使数据库对象不能像规则一样灵活变动。因此VisualRules采用List来定义数据库对象接口，这种方式使得数据库对象也是可变的。传统的规则引擎一般不能直接操作Excel数据，但是在实际的业务逻辑的应用中，部分数据并没有存储在数据库中，或者需要用Excel来展现数据。VisualRules可以直接来操作Excel文件。
内存表格
业务系统的业务逻辑实现有个特点，就是基本都是批量处理的处理，并且很多数据存储在数据库中。但是如果在实现业务逻辑时，频繁的去访问数据库，会使得整个业务逻辑的实现效率很低。因此VisualRules设计了内存表，可以将数据库中的数据先取出后放到内存表中，然后通过内存表相互之间做匹配或汇总处理。这样极大的提高了执行效率，而且也增强了业务逻辑层实现的功能。
最小化规则引擎
做开发平台最关键是运行时的稳定和性能。因此VisualRules采用最小化的规则引擎，规则引擎只处理规则包的加载和调用，不处理规则语法以及规则解析工作。在开发规则时，开发平台根据规则语法将规则包静态编译成可执行的java代码，这样最大限度的保证的规则运行平台的稳定。同时将规则的开发平台和运行平台分离，使得运行平台不会随着规则语法以及功能的增强而变化。
基于模板的页面配置开发
在页面表现层的实现上，当前最流行的技术就是采用Ajax来实现界面的表现。但是在表现逻辑的实现上，一般情况下，我们会基于一套框架（比如Ext、Dojo、JQuery等），然后再通过javascript来编写具体的逻辑代码。但是这些表现逻辑代码其实是非常晦涩难写的，而且也不能体现所见即所得的效果。VisualRules将基于框架的组件配置信息单独提出来，通过图形化界面来设定所需要的参数，然后根据模板生成对应的代码。这种方式类似于代码生成器方式来生成界面层的代码，其开发工作量是最小的。
VisualRules可以取代当前业务逻辑层和数据层所有的操作代码，准确的说，可以取代从Struts、Spring、Hibernate这些相关的代码。Ajax直接通过通用的Servlet来访问规则包。这种取代方式，极大的简化了后台代码的开发，同时也使得业务逻辑层更加快速适应业务需求的变化。规则引擎可以有效的和当前主流的Ajax框架进行交互，也可以在Jsp中，通过java代码来访问。页面层代码可以通过页面配置器来根据模板生成，也可以手工编写。
基于以上这些特点，使用VisualRules可以为用户带来一些这些价值：
软件系统随需而变
软件系统最大的价值就是体现在系统运行的过程中，随着用户业务的变化，软件能够快速的加以适应，而不是成为业务发展的障碍。因此软件变更的响应时间以及影响，是衡量软件价值的关键。VisualRules使得软件系统可以“零时间”响应用户需求的变化，真正的做到了软件系统随需而变。
降低软件成本
采用VisualRules开发软件系统，可以减少项目开发所需要的人员数量，同时也减少了每个人的工作量，使得项目的周期缩短。因此visualRules可以减少软件开发的成本和缩短软件开发的时间。同时由于VisualRules提供了方便的配置工具，可以在软件项目后期维护阶段快速适应需求的变化，因此软件的维护阶段，当有需求变更时，不再需要安排程序员去维护。而是一般的技术支持人员甚至客户本身就可以实现变更工作。这使得安排一个技术支持人员就可以同时支持多个项目的维护工作。而不像原先那样，当维护时需要安排原先的程序员来进行对应。因此使得软件项目整个成本属于完全可控的范围以内。
提高软件复用
VisualRules来实现业务逻辑时，是脱离程序语言来实现。因此其实现的业务逻辑可以供不同的语言来进行调用，也可以供不同的框架来进行调用。特别是当前基于web浏览器的富客户端技术不断发展的今天，富客户端框架很有可能会有新的框架进行取舍。因此业务逻辑脱离这些框架的实现显得尤为关键。当技术更新时，在新的技术框架的实现下，可以调用原先的业务逻辑代码，这最大限度的保证了原先软件项目的投资。
顺序执行的规则引擎算法
传统的业务规则管理系统，其规则引擎的算法基本上会采用reta算法，其基本原理是运行阶段判断哪些规则符合条件，然后去决定其执行轨迹，这类似于人工智能的思想，当然其最初出发点也是为了人工智能判断。由于业务系统业务逻辑的频繁变动，因此希望可以利用规则引擎来实现业务规则的配置，因此也就自然将reta算法作为业务系统中业务逻辑的执行算法。但是这两者其实是不一致的，业务系统中的逻辑一般是确定的，有着明确指定的执行先后顺序的。而reta算法是动态决定顺序的，因此在用reta算法描述业务逻辑时，往往显得非常琐碎，并且其速度也比纯粹用程序描述要慢很多。VisualRules不再采用难以描述业务逻辑的reta算法，而采用顺序执行的算法来描述业务逻辑。这样描述业务逻辑和并平时用流程图和文本来描述业务逻辑就没有多少区别。可以最简单话的配置业务逻辑，同时其速度和手写程序的速度是一致的。VisualRules是真正的为业务系统中业务逻辑的实现而设计的，是软件项目业务逻辑实现的最佳选择。
公共规则、循环规则、关联决策表
由于规则执行算法基于顺序执行的算法，因此在描述业务逻辑上比reta算法有更多的展现形式，特别是可以通过规则集来定义多个规则的共同条件以形成执行的分支，或者用来描述循环运行的一组规则。另外在决策表的支持方面也有三种方式，二维决策表、多维决策表以及关联决策表，以更方便的形式来描述逻辑。同时规则还支持否则如果(elseif)方式的条件，进一步增强了规则描述业务逻辑的能力。
动态的参数接口、数据库接口和Excel接口
传统的规则引擎如JSR94描述的规则引擎调用接口采用Java类来传递值，这种方式使得接口的数据结构不能像规则一样变动。VisualRules通过Map来传递值，因此其接口的数据结构是可变的。同时传统的规则引擎一般可以通过设置来直接调用Hibernate等外部数据库对象，这样其实就是通过类和XML来定义了数据库的调用接口，这种方式就不能使数据库对象不能像规则一样灵活变动。因此VisualRules采用List来定义数据库对象接口，这种方式使得数据库对象也是可变的。传统的规则引擎一般不能直接操作Excel数据，但是在实际的业务逻辑的应用中，部分数据并没有存储在数据库中，或者需要用Excel来展现数据。VisualRules可以直接来操作Excel文件。
内存表格
业务系统的业务逻辑实现有个特点，就是基本都是批量处理的处理，并且很多数据存储在数据库中。但是如果在实现业务逻辑时，频繁的去访问数据库，会使得整个业务逻辑的实现效率很低。因此VisualRules设计了内存表，可以将数据库中的数据先取出后放到内存表中，然后通过内存表相互之间做匹配或汇总处理。这样极大的提高了执行效率，而且也增强了业务逻辑层实现的功能。
最小化规则引擎
做开发平台最关键是运行时的稳定和性能。因此VisualRules采用最小化的规则引擎，规则引擎只处理规则包的加载和调用，不处理规则语法以及规则解析工作。在开发规则时，开发平台根据规则语法将规则包静态编译成可执行的java代码，这样最大限度的保证的规则运行平台的稳定。同时将规则的开发平台和运行平台分离，使得运行平台不会随着规则语法以及功能的增强而变化。
基于模板的页面配置开发
在页面表现层的实现上，当前最流行的技术就是采用Ajax来实现界面的表现。但是在表现逻辑的实现上，一般情况下，我们会基于一套框架（比如Ext、Dojo、JQuery等），然后再通过javascript来编写具体的逻辑代码。但是这些表现逻辑代码其实是非常晦涩难写的，而且也不能体现所见即所得的效果。VisualRules将基于框架的组件配置信息单独提出来，通过图形化界面来设定所需要的参数，然后根据模板生成对应的代码。这种方式类似于代码生成器方式来生成界面层的代码，其开发工作量是最小的。
VisualRules可以取代当前业务逻辑层和数据层所有的操作代码，准确的说，可以取代从Struts、Spring、Hibernate这些相关的代码。Ajax直接通过通用的Servlet来访问规则包。这种取代方式，极大的简化了后台代码的开发，同时也使得业务逻辑层更加快速适应业务需求的变化。规则引擎可以有效的和当前主流的Ajax框架进行交互，也可以在Jsp中，通过java代码来访问。页面层代码可以通过页面配置器来根据模板生成，也可以手工编写。
基于以上这些特点，使用VisualRules可以为用户带来一些这些价值：
软件系统随需而变
软件系统最大的价值就是体现在系统运行的过程中，随着用户业务的变化，软件能够快速的加以适应，而不是成为业务发展的障碍。因此软件变更的响应时间以及影响，是衡量软件价值的关键。VisualRules使得软件系统可以“零时间”响应用户需求的变化，真正的做到了软件系统随需而变。
降低软件成本
采用VisualRules开发软件系统，可以减少项目开发所需要的人员数量，同时也减少了每个人的工作量，使得项目的周期缩短。因此visualRules可以减少软件开发的成本和缩短软件开发的时间。同时由于VisualRules提供了方便的配置工具，可以在软件项目后期维护阶段快速适应需求的变化，因此软件的维护阶段，当有需求变更时，不再需要安排程序员去维护。而是一般的技术支持人员甚至客户本身就可以实现变更工作。这使得安排一个技术支持人员就可以同时支持多个项目的维护工作。而不像原先那样，当维护时需要安排原先的程序员来进行对应。因此使得软件项目整个成本属于完全可控的范围以内。
提高软件复用
VisualRules来实现业务逻辑时，是脱离程序语言来实现。因此其实现的业务逻辑可以供不同的语言来进行调用，也可以供不同的框架来进行调用。特别是当前基于web浏览器的富客户端技术不断发展的今天，富客户端框架很有可能会有新的框架进行取舍。因此业务逻辑脱离这些框架的实现显得尤为关键。当技术更新时，在新的技术框架的实现下，可以调用原先的业务逻辑代码，这最大限度的保证了原先软件项目的投资。