究竟什么才是真正的规则引擎

      可能很多人还不了解规则引擎是什么东西，或者不知道规则引擎究竟有什么用。我们都知道工作流引擎，也听说过JBoss下面有个Drools，或者我们知道 weblogic或者Oracle也有自己的Business Rule，我们可能还听说过ILOG被IBM收购了，如果我们研究微软的WWF，可能也知道其中有RuleSet等内容。国内的一些web快速开发平台，也提到了规则引擎。

      在我们的印象中，我们感觉规则引擎就是解决业务逻辑层的实现问题的。因此我们理所当然的觉得工作流中的某个节点的逻辑处理，应该可以用规则引擎来解决，那么工作流本身的逻辑也应该可以由规则引擎来解决。另外我们也会觉得，平时项目当中的业务逻辑应该都可以用规则引擎来解决。但是当我们在使用上述这些规则引擎，却发现很难和我们实际应用的业务逻辑层的业务逻辑实现相对应。

      我们以JBoss的Drools为例，由于其规则引擎使用了匹配规则的方式来进行，因此在应用这些规则引擎时。首先需要将我们具体应用中的业务逻辑做抽象，抽象成一条条规则之后，再打包成一个规则包。一个规则包相当于一个智能块。当数据传递给这个智能块后，系统会以匹配的方式应用满足条件的逻辑处理。当采用这种方式时，应该说逻辑更抽象了，在一个更高的层次加以抽象化的定义。但是也使得规则引擎的应用得到了很大的限制。首先这种抽象本身需要一个复杂的分析过程，这需要有很强的分析设计能力。另外我们平时具体应用中的业务逻辑层，大量的逻辑都是对实际数据的处理，很多时候还是一个批量数据的处理，甚至有些逻辑需要的参数我们并不能定义在规则中，而是在数据库表中进行配置。因此我们常见的业务逻辑层的开发，并不能先设计出一个数据模型，然后再在此基础上抽象逻辑。因此我们发现Drools等规则引擎很难用，根本不是我们所需要的那样。

     我们研究规则引擎也有一段时间了。有时候我们发现自己做的规则引擎并不是一个规则引擎。因为我们和像Drools这些规则引擎有很大的差别。但我们确实解决了业务逻辑层的业务逻辑配置问题。应该说我们的更实用一些。但是我们却没法去实现JSR94标准。我们不光处理业务逻辑，还把所有业务逻辑层需要处理的操作全部采用规则配置的形式，包括数据库处理逻辑等。

     接下来我们讲述一下Visual Rules Solution（后续介绍用：“VRS”代替“Visual Rules Solution”），是一个基于规则引擎实现的可视化定制业务逻辑的商业规则管理系统，同时又具有快速开发java软件项目的功能。VRS可以在程序外部对软件项目中所涉及的业务逻辑进行单独管理，并且提供多种语言的API接口供外部程序调用。VRS可以集成到现有的软件项目中，将软件中经常容易发生变化的部分，独立出来由规则库进行管理。可以用于直接开发web项目，Visual Rules可以为软件项目生成90%以上的程序代码，节约50%以上的软件开发时间以及减少80%以上的软件维护工作量。

     VRS是开发B/S结构软件项目的利器，特别适用于快速开发基于J2EE结构的软件项目。其原理是对于J2EE项目，一般其架构分为界面层、业务逻辑层和数据层。VRS提供了数据库管理器，可以生成几乎全部的数据库层代码；提供了规则编辑器可视化快速开发业务逻辑；提供了规则引擎可以动态加载和执行业务逻辑；提供了页面模版编辑器以及页面生成器可以生成大部分界面层代码；提供了在线的业务逻辑管理平台，可以直接供客户（包括非技术人员）直接修改软件项目中实现的业务逻辑。VRS优势在于可以解决了软件开发中一直以来业务逻辑层只能手工书写代码的问题，为业务逻辑层的实现提供了采用类自然语言（业务人员可以理解的语言）的可视化开发工具，以及在线方式的业务逻辑编辑工具直接供业务人员修改逻辑。