规则引擎系列：规则引擎发展（如何在工作流等开发平台中集成规则引擎）

基于web应用来说，通常分为三部分：界面层、业务逻辑层和持久层。

所有的开发平台一般都是在这三方面做工作。由于这三层的特点有些不同，因此我们会采用不同的实现方式来实现。
界面层：强调的是操作界面，注重采用所见即所得的方式来调整界面布局以及界面样式。更多的我们可以会做一个表单设计器。
业务逻辑层：强调逻辑调整的便利性，一般采用动态语言或者规则引擎来实现逻辑的配置。
持久层：采用领域模型，根据定义MetaData来定义结构，从而实现和持久层的访问。当然持久层不全代表是数据库。

国内出现的开发平台中，看到基本都是用代码来实现业务逻辑层的。不过是动态语言还是连接外部程序。比如工作流中一些前续事件和后续事件等。很少看到采用规则引擎来实现业务逻辑的配置。
究其原因就是基于推理方式的规则引擎并不适合普通业务逻辑的编写。
          制作一个不采用推理方式的规则引擎，而采用我们传统的编码逻辑方式的规则引擎。我们可以称之为简单规则引擎。没有了冲突推理后的规则系统，将更加简单的来实现业务逻辑。因此其不用再考虑规则优先级，冲突、关联之类的事情，无需再担心某处的一个简单的改变带来了大量无发确定的后果。实现了易用以及灵活性的完美结合。
由于目前并没有成熟的开源项目来满足这类需求，因此我们需要自己来实现这类引擎。
如何来实现呢，我们可以从当前已经实现的基于语言的配置入手。
首先实现编写脚本来实现业务逻辑，其次规则的配置界面，可以自动生成这类脚本。
第一步，建立一个业务语言和脚本语言的映射，如果我们是基于java的项目，就可以直接采用java语言作为脚本语言，然后利用java的动态加载机制，实现规则实时应用。
第一个java中的对象和业务语言的对应，这在目前各类商业的规则引擎已经做的很好，可以参考。实现BOM和XOM的对应关系。
第二步，做一个配置界面，可以来定义调用这些java的对象，由于已经建立了java对象和业务语言的对应关系。因此配置后的逻辑界面其描述就是以业务语言来描述。
第三步，将配置的逻辑，存储到我们的业务系统中，供工作流的某个节点调用。工作流的节点中只要指定了规则名称以及需要传递的对象，就可以将数据传递到规则中进行处理。
如果能够将当前工作流的脚本编辑界面直接替换成规则的开发界面，当然更加好一些。