规则引擎系列：规则引擎发展 读后感

读过了moon66sun在csdn上的文章《规则引擎系列：规则引擎发展（如何在工作流等开发平台中集成规则引擎） 》，原文如下

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

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

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

前面写的真好，分析的透彻入木三分，但个人认为业务语言的引入会增加理解的复杂性和学习成本，其实这些业务语言就是一种语义严谨的另一种编程语言，相当于为了解决java代码难学的问题，又引入了另一种晦涩的语言来作为java语言的中间语言，且不说这个翻译过程有无必要，就说这中间语言就够晦涩了。

这个做法有些背离了规则引擎的初衷，虽然可以做到项目中变化的部分和不可变部分的分离，但无法做到让不懂编程的业务专家来自己修改业务逻辑，以适应业务需求快速变化的目的。个人认为与其这样，不如让客户直接使用存储过程来的简单直接。起码客户只要懂sql就可以解决业务问题了，不必另学一种或两种编程语言。

个人认为以后规则引擎的趋势是用一种具有某种规则和语法的类似自然语言的描述和文字来解决复杂业务问题，比如“我希望金额大于二千的报销需要总经理审批，并且财务要签字”，当然了这并不容易，还有很长的路要走，但这是趋势，机器也在越来越聪明不是吗。