融合规则的工作流学习笔记一
规则引擎由推理引擎发展而来，一般指一种在运行时生产环节中执行一个或多个业务规则的软件系统。业务规则系统允许这些规则的决策者或开发者对这些业务策略等规则进行定义、测试、执行和维护。通常支持规则、事实、优先级（评分）、互斥、先决条件和其他功能等等。
规则管理系统架构
规则引擎通常作为一个业务规则管理系统的一个组成部分，为业务规则管理系统提供以下功能：
1、登记、定义、分类和管理所有规则
2、验证规则定义的一致性
3、定义不同规则之间的关系
4、将规则与需要调用这些规则或者可能被这些规则的结果所影响的IT应用相关联
规则管理系统由规则引擎核心（Rule Engine Core)、规则库(Rules Repository)、规则引擎接口（Rules Engine APIs）、规则引擎接口连接的规则授权环境（Rules Authoring Environment)、外部组件（External Component）和外部应用(External Application)构成。
Drools规则引擎与规则语言
Drools是基于RETE算法的开源规则引擎。可帮助业务负责人将复杂多变的规则以脚本的形式存放在文件中，便于查看、编辑和更新业务规则，而不需要进行重新修改代码等操作。支持四种规则表示方法：The Rule Language,Domain Specific Language,Decision Tables和XML Rule Language。其中The Rule Language是Drools的原生规则语言，这种语言格式对标点符号没有强限制，通过"expanders"机制来支持Domain Specific Language等语言。一条Drools规则结构如下：
rule "name"
attributes
when
LHS(condition)
then
RHS(result)
end
属性（attributes）：通过一些如no-loop,lock-on-active等关键字来控制规则的执行方式，比如no-loop控制是否可以重复执行。
条件(LHS)：Left Hand Side，表示规则被触+发的条件，需遵循Drools语法，又称为规则前件。
结果（RHS）：Right Hand Side缩写，代表规则执行的结果，又称规则后件，RHS可按Drools语法，也支持直接写Java代码，可以直接通过调用Fact对象的方法来进行操作。
基于ECA规则的工作流模型
ECA（Event-Condition-Action）规则起源于主动数据库技术。在基于ECA规则的工作流执行中，事件和活动总是相互触发和关联，若干个事件触发了符合触发需求的若干活动，这些活动完成时又作为事件来触发后续的活动，所以可以用事件触发活动、活动产生事件这种关系来实现工作流的动态性质。ECA规则以集合定义为：
Rules={{Events},{Conditions},{Actions}}
Rules为规则集，Events为触发规则的事件集，Conditions为条件集，Actions为操作集，因此可规范表述为：
Rules=（On
事件event触发时，如果满足条件condition，则按动作集合actions执行流程。
基于ECA规则的工作流模型语言描述如下：
WHEN Events
IF Conditions THEN
Action
ENDIF
ENDWHEN
以订单审核为例分析缺陷：
缺陷：
1、ECA规则面向开发者而不是业务人员，实现方式落后。ECA的思想核心为根据业务规则激活事件，因此基于ECA规则的工作流模型中，对规则的理解和建模集中在开发阶段，规则的实现和初始化由开发者完成，依然是一种面向开发者的建模方式，依然需要通过对该业务规则对应的ECA实现代码进行修改来实现业务规则的逻辑变化。
2、低内聚，高耦合，维护成本高。在基于ECA的工作流建模中存在的一个潜在风险是，除了事件触发之外，工作流中还存在着一些与事件无关、但是对业务流程有影响的业务逻辑信息，比如流程业务的数据对象自身的数据关联等。这部分业务逻辑的代码往往与流程代码、规则代码一同存储在系统中，一旦业务逻辑发生变化，难于精确定位，也难以基于ECA规则去解决问题和保持实现的一致性。
3、规则抽象程度不够，系统复杂性高。业务规则中，有些节点有相同的数据处理规则，却因为有着不同的流转规则（反之亦然），在基于ECA的工作流建模中需分为两部分，虽然能良好解决路由灵活性，但是业务规则的复用程度低，系统冗余。同时，同一规则有多个实现也为工作流系统增加了巨大的复杂性，这些规则一旦发生更改，难以维护。
基于对象规则的工作流建模
对象规则，即工作流业务中与该对象有关的业务逻辑，包含数据操作、判断条件和关联规则等等，往往正好对应着业务人员在实际业务中需要进行修改的业务内容范畴，是一种基于规则数据化的工作流建模基础。
基于对象规则的工作流建模思想的主体流程为：
1、设计人员基于成熟的工作流和业务规则的建模方法，基于面向对象的思想，按一些特定层次抽象出各层的流程和规则，并组成通用的融合规则的工作流模型；
2、开发人员依据此通用模型，并结合SaaS技术实现支撑组件、路由流程、规则以及两者融合三部分组成，搭建SaaS级应用服务。
3、服务的使用者——业务人员，在经过基本指引后即可在对SaaS服务的实际应用中使用自然的、非技术的定义方式，去定义和更改业务中的规则逻辑，并使用这些规则逻辑在业务流程的运行过程中被满足条件的节点激发，并发挥规则应有的效用。
对象规则的思想看，通过描述实际业务中某个业务涉及到的元素，来表达一项业务规则。对象规则的描述对象是该业务规则中涉及到的各项属性。工作流中对象规则的特征有：
1、独立性。对象规则可以单独被定义管理，与对象流程定义无关。
2、逻辑关联。已经运行过的对象规则实例对事实数据进行的操作可能影响到后续待运行的对象规则的运行情况，使对象规则间产生连锁反应。
3、自然语言。对象规则负责人通过类自然语言的方式定义对象规则，解释为规则引擎编程语言后才能产生效用。
4、定义与调用分离。定义阶段，对象规则负责人定义的对象规则经过解释为规则引擎语言后存储到规则引擎的规则库中。调用阶段，流程将规则所需的事实数据传给规则引擎，规则引擎将事实与规则库中的规则进行匹配并得出匹配结果。
基于对象规则的工作流模型设计
为了工作流定义的一致性、标准化，使不同工作流系统中的工作流可以相互协作，WFMC提出了一种通用的工作流定义模型——Workflow Meta Model，即工作流元模型，来描述工作流定义中的对象、对象关系和属性，作为工作流信息交换的标准化格式的集合。
Workflow Process Definition：工作流流程定义。定义一个工作流程，由一系列活动（Activity）组成，且拥有自己的工作流相关数据（Workflow Relevant Data)。工作流流程的定义内容包括工作流名称、版本号、流程起始和终止条件、安全数据、评审数据以及其他控制数据。
Activity：活动。工作流操作的最小单元，通过为角色（Role）提供了完成该活动所需的可调用应用（Invoked application），使角色在活动要求下对工作流相关数据（Workflow Relevant Data）做出合理的操作来完成一次活动。活动的定义内容包括活动名称、活动类型、活动前序和后序条件、其他调度约束等等。
Workflow Relevant Data:工作流相关数据。该工作流需要的，流程中各活动涉及到的系统数据对象。工作流相关数据的定义内容包括：数据名称、路径和数据类型等；
Invoked Application:调用应用。与工作流活动紧密相关的，供角色（或自动地）对工作流相关数据进行处理的流程相关外部应用。调用应用的定义内容包括：类属性/名称、执行参数、定位/访问路径等等；
Role：指流程活动对应的人员或组织单元，直接限定人员在流程中的权限和职责。角色定义内容包括：角色名、组织架构实体等等。
Transition Condition:转移条件。流程活动所需的，实现不同活动间转移关系的条件与动作，在实际流程运转中，与工作流相关数据一同决定活动流程。转移条件定义内容包括流转条件、执行条件等等。
参考文献：《SaaS平台下融合规则引擎的工作流服务的设计与实现 》