需求分析
随着企业中信息化程度的不断深入，越来越多企业中的部门开始使用信息化管理系统来满足其日常的工作，同时企业的各项业务开展也越来越依赖其使用的信息化管理系统。在此背景下，信息化管理系统除了需要能够满足企业当前的业务需求之外，如何适应企业的发展以及业务扩展的需要，不断的 调整信息化管理系统，以适应新形势下的企业竞争需要，是目前信息化项目所面临的最大挑战。
由于传统技术的限制，目前我们经常可以看到以下的现象：
1、 企业在应用一个信息的管理系统时，并不十分清楚到底需要哪些功能和需求。随着项目实施的深入，需求会不断的加以修正和完善。最终使得项目实施的进度失控，甚至最终实施失败。
2、 信息化系统成功实施后，随着企业对信息化认识的不断加深，用户希望增加更多的功能以及和其他新增的系统做对接，这就需要对现有的系统进行改动。但是由于传统技术的限制，一般都不会对现有的系统进行，而是直接做一个全新的版本升级，这就使得原先的技术投入完全的废弃了。
3、 随着企业信息化项目的增多，各个系统相互独立，所用技术五花八门。除了形成一个个信息孤岛之外，还很难加以维护。各个系统资源也不能很好的加以共享。企业对信息系统维护成本也是越来越高。
这些现象的出现，都是由于企业需求发生了变化，而传统的软件开发模式，当需求发生变化时，必须修改程序，因此使得软件很难适应新的需求变化。
为了信息化项目能够适应新的软件需求，需要尽可能分离业务需求以及技术实现。因此采用配置方式进行实现，而不采用程序编码方式来实现，是有效解决业务逻辑变更的实现方式。
在一般的信息化项目中，每个软件功能的实现都分为操作界面、业务逻辑和数据库层代码。当需求变化时，主要就是这些方面的代码变化，因此我们需要采用配置方式来自动生成操作界面的代码、业务逻辑的代码以及数据库层的代码。
在自动生成代码的基础上，我们又将代码自动进行编译，并且实现动态的加载，所生成的代码无需在进行修改，直接应用到系统中。这样就彻底的实现了全配置、无编码的实现。
规则引擎是一个业务逻辑的解析器。规则引擎需要结合规则编辑器、规则包来完成业务逻辑的解析。一个基于数据库的信息系统从根本上来说是对数据的处理，因此业务逻辑层的操作其实是对界面传入的数据进行运算以及存储等操作。规则引擎系统通过对象库来定义传给规则需要处理的数据，通过规则标记语言来定义处理这些数据的逻辑并将其存储在规则包中。外部程序则需要通过规则引擎来解析执行规则包中的业务逻辑
规则包执行原理
外部程序通过规则引擎调用规则包，每个规则包都包括接口、规则逻辑和数据对象。
基于XmL的规则库
规则库其实是一个规则包的文件存储系统，一般采用xml形式的规则标记语言定义了规则包中的对象以及相应的操作逻辑。规则库中的规则包文件通过规则编辑器进行编辑，编译成可执行文件后通过规则引擎进行调用
规则引擎结构
Visual Rules规则引擎是用于外部程序来调用规则包的一批java类库，将一个规则引擎嵌入到应用程序中的方法与添加任何其他Java类的方法一样。在java的项目中，需要调用规则引擎来执行规则包，只需实现一个类（RuleEngine）就可以了。通过RuleEngine类就可以实现调用某个规则包，以及传递需要处理的业务数据。
每个规则包配置完成后，会生成一个继承RuleContext的类，并且将这个类自动编译发布到java的class path的路径中。外部程序通过RuleEngine接口，根据需要调用规则包的名称，加载对应的RuleContext类并且执行其excuteRule()方法。
数据库对象
规则支持对数据库对象的动态调用，这些数据库对象包括：数据库表、查询、视图、存储过程。因此在具体的实现中，当规则包读取数据库的表结构信息时，系统会动态生成实现Table接口的类，其中表结构信息、结构集都采用List来进行存储。因此表结构是可以在规则包中进行调整，对应的实现也会动态的更新List结构。
Web方式调用规则包原理
在规则配置器中，可以添加一个web方式调用规则包的测试页面，这个测试页面采用jsp程序，其中根据规则包的接口数据结构，自动生成文本输入框。同时根据数据结构的类型，自动生成解析request中提交的数据，并且传递到规则引擎中，并且执行对应规则包，最后取出返回结果，在显示到页面中。以上过程完整的再现了java程序如何通过规则引擎调用规则包的实现方式。用户可以通过自动生成的jsp代码查看具体的实现。原理如下：
Jsp＋规则引擎＋规则包是一种MVC的架构模式，其中jsp中体现了View，规则引擎体现了Control，规则包体现了Model的结构。
Jsp层包括html部分和页面逻辑部分。为了保证系统的完全runtime，页面逻辑集成到jsp的头部，用于jsp字段和规则引擎的交互。Html部分采用jsp标签来处理jsp字段显示到html。
规则引擎只处理jsp字段和规则包的交互，规则引擎将jsp中字段传递给规则包，等规则包执行处理完数据后，再将处理后的规则包传递给jsp层。
规则包中设置了数据库对象、数据对象和业务逻辑，业务逻辑实现对数据对象和数据对象的处理。
规则配置器
规则配置器是提供给开发人员和业务人员新建和修改规则包的工具，因此规则配置器可以打开规则库中的规则包，并且可以设置规则包可以调用的商业数据对象（BOM）以及处理逻辑（规则或决策表），同时可以在配置器中测试规则包的执行，查看规则包的执行轨迹等。
规则配置器的主要功能特点如下：
多种方式存取规则包
通过规则配置器可以新建规则包，新建的规则包可以存储在本地硬盘或者通过网络存储到数据库中。存储到数据库中时，只需要通过采用HTTP协议开放的规则服务，存储到服务器的数据库中，并不需要服务器开发数据库端口。 同时当规则包存储在数据库中，可以设置规则包的权限。用户可以通过规则配置器直接登录，并且只能操作自己具有权限的规则包。
规则包版本控制
规则修改需要进行版本控制，新建的规则包的版本缺省情况下是1.00，其中整数部分的版本为规则的大版本，小数部分为规则小版本。每次修改并保存新版本时，都会自动添加0.01，依次递增。
当规则包每审核一次，都会进行规则包大版本的递增，用于区分规则的审核情况。规则的小版本，在具体的规则编辑过程中，可以选择递增，用于区分对规则包的修改情况。当规则包开发完成之后，上传到数据库服务器中，分为两种类型，一种是开发类规则包，另外一种是管理类规则包。管理类规则包才能进行规则的审核等操作，以及进行大版本的递增。开发类规则包只能进行小版本的变动。
规则权限控制
目前C/S结构的规则编辑工具，有两个版本，一个是开发版，一个是编辑版。
开发版可以对开发类规则包和管理类规则进行操作。对于开发类规则包，只有开发人员才能打开，开发人员打开后，会记录该版本的打开人以及打开时间。开发人员打开后，可以对规则包进行任何操作，包括设置规则、对象库、jsp页面等。对于管理类规则包，当开发人员打开时，可以进行任何操作，当编辑人员打开时，只能对规则包中的规则和决策表进行操作，编辑版只能对管理类规则包进行操作。打开编辑类的规则包时，用户必须输入用户名和密码，当用户名和密码不通过时，不能进行登陆。用户打开管理类的规则包时，只能修改规则和决策表，不能对对象库和jsp页面等进行操作
规则修订痕迹跟踪
规则修改时，需要跟踪规则包的修改情况，目前只记录规则和决策表的修改情况。当用户在开发过程中，可以对规则包设置修订点。当设置了修订点之后，规则包会记录一个当前所有规则的编辑状态。以后进行规则的修改时，可以查看到规则的变化情况，并且可以同时看到当前规则和修订点规则的对比情况。用户还可以选择某个版本的规则进行比较，比较时可以看到每个规则的修改情况。
规则执行轨迹记录
规则执行完毕之后，需要记录规则的执行轨迹。当前记录所有满足条件的规则的执行情况，并且记录规则进入时的数据值以及执行 完之后的数据值。
目前在C/S结构的规则编辑器中，当使用了规则包的测试功能之后，会记录当前规则包执行的执行规则，用户可以打开进行查看。
规则执行时，首先会对整个规则包记录一个执行轨迹根。然后执行规则集时，会在此根下面新建一个执行轨迹。当执行规则时，会在父的执行轨迹下面再新建一个执行规则。新建时，记录了规则的名称，以及进行相关的变量，以及执行前值和执行后值的情况。
在B/S结构的规则包进行执行时，会将执行完毕之后的轨迹对象存储到数据库中。在进行查看时，就可以看到规则包的执行执行树状结构。
规则本地测试
规则包编辑时，可以进行本地的测试。本地测试分为两种方式，一种是直接使用规则包的测试功能，执行是系统会将规则包先进行编译，然后再调用此规则包进行执行。
另外一种做法是通过jsp页面进行测试。每个规则包可以新建多个jsp页面，每个jsp页面可以导出到本地的tomcat服务器中，进行调用执行。
规则执行日志
规则包中可以设置日志输出，日志分为错误、警告、提示、调试等多种信息。可以通过注册日志记录服务，来实现日志的多种方式导出。
日志输出时可以包括以下信息：规则包名、执行时间、日志类型、日志信息、输入参数、输出参数等。
通过对日志的输出，可以有效的了解和记录所有规则包的执行情况。
业务规则管理系统
业务规则管理系统用于管理规则配置器存储在数据库中的规则包，对规则包进行权限控制、在线查看、审核发布、在线执行等操作。
规则库数据结构
规则库主要有以下几个表组成：
| 实体名 | 实体描述 | 表名 | 表描述 |
| r_editstate | 规则编辑状态 | r_editstate | 规则编辑状态 |
| r_rule | 规则 | r_rule | 规则 |
| r_ruledefault | 规则参数缺省值 | r_ruledefault | 规则参数缺省值 |
| r_rulelog | 规则执行日志 | r_rulelog | 规则执行日志 |
| r_ruletype | 规则类别 | r_ruletype | 规则类别 |
| r_ruleuser | 规则用户权限 | r_ruleuser | 规则用户权限 |
| r_ruleversion | 规则版本 | r_ruleversion | 规则版本 |
| r_state | 规则版本编辑状态 | r_state | 规则版本编辑状态 |
| r_table | 规则相关基础表 | r_table | 规则相关基础表 |
| r_tablefield | 规则相关基础表字段 | r_tablefield | 规则相关基础表字段 |
| r_tablewhere | 规则相关基础表条件 | r_tablewhere | 规则相关基础表条件 |
| r_where | 规则执行条件 | r_where | 规则执行条件 |
| sys_depart | 机构表 | sys_depart | 机构表 |
| sys_lanmu | 菜单栏目 | sys_lanmu | 菜单栏目 |
| sys_log | 系统日志 | sys_log | 系统日志 |
| sys_page | 菜单 | sys_page | 菜单 |
| sys_resource | 组件资源 | sys_resource | 组件资源 |
| sys_restype | 资源类别 | sys_restype | 资源类别 |
| sys_role | 角色 | sys_role | 角色 |
| sys_roleresource | 资源角色分配 | sys_roleresource | 资源角色分配 |
| sys_roletype | 角色类别 | sys_roletype | 角色类别 |
| sys_roleuser | 角色用户 | sys_roleuser | 角色用户 |
| sys_user | 用户 | sys_user | 用户 |
业务规则管理系统功能
规则管理系统用于管理上传到数据库中的规则包。可以对存在于数据库中的规则包进行查询，以及对其中的各个版本进行在线的查看和修改。可以为规则包分配用户权限，设置哪些人可以有查看、修改、开发、审批、执行、发布权限。可以对规则包的某个版本进行申请审核、审核、测试、执行和发布利益等操作。在具体的规则执行中，可以执行规则的源数据结构以及结果数据结构，可以查看规则的原始数据和最终结果数据。
对于规则的权限控制，分为对规则的开发、修改、执行、审核、发布、管理等权限。
规则的开发权限，可以用C/S结构的规则编辑工具进行规则包的新建以及修改。可以对规则包中的对象库、数据库对象以及规则等进行设置，可以新建jsp测试页面来利用本地的web服务器进行规则包的测试工作。可以将建立好的规则包，上传到数据库中。
规则的修改权限，可以用C/S结构的规则编辑工具对规则包进行打开修改。只能修改规则包中的规则等，不能修改对象库、数据库对象以及jsp测试页面。修改完之后，可以将修改之后的规则包，上传到数据库中。也可以用B/S结构的规则编辑功能对规则包进行修改，修改后直接保存。
规则的执行权限，可以在B/S结构的规则管理中，执行某个规则包的版本。执行完之后，可以看到执行的结果。
规则的审核权限，可以在B/S结构的规则管理中，对申请审核的规则进行审核操作。规则包申请审核后，会锁定规则包。
规则的发布权限，可以在B/S结构的规则管理中，执行以及审核通过的规则包并且发布。
规则的管理权限，可以在B/S结构的规则管理中，分配规则的权限。设置规则的各种属性。
如果外部系统要直接调用规则库，可以采用统一认证的方式。外部系统有自己的用户管理系统，C/S结构的规则编辑工具运行时，通过独立的用户系统进行用户和密码的认证。B/S结构的规则管理系统运行时，通过.NET系统的用户统一认证，通过传递加密的url自动进行用户登陆过程。