基于SaaS的业务流程与规则引擎的应用

基于SaaS的规则引擎在企业流程中的应用引言规则引擎原理流程应用基于saas的模式意义
1、引言
目前，B2B电子商务平台发展了大量的中小企业用户，提供具有共性的信息管理服务，但是这些服务对于特定用户来说，无法根据该用户的业务流程来构造与其自身业务相匹配的管理过程；同时，平台亦无法应对会员企业将来发展带来的管理过程的不断变化。

在这种情况下，为中小企业用户提供个性化的服务，对企业的意义是非常重大的。

尽管现在有些软件开发商为企业提供量身定制的功能需要，但这种方式开发成本很高，而且基本上是按照当时或者用户可以预见的方式进行开发，不可避免的出现一些弊端：（1）需要安装专门的管理系统软件，维护困难；
（2）功能的灵活性较小，只能符合某些行业的特点，不符合B2B电子商务平台上广大行业的需求；
（3）功能的配置操作复杂，不利于中小企业用户的使用；
（4）功能维护和修改的成本高。

为了解决上述弊端，基于SaaS的业务规则引擎的方法被提了出来，这种方法充分利用了SaaS（软件即服务）的特点，不需要在中小企业的计算机上安装任何软件，把系统的日常维护工作都交给软件服务运营商；而且使用成本低廉，符合中小企业的信息化成本要求。

同时通过企业业务流程与规则引擎的结合应用，把商业规则与应用开发代码，让中小企业的工作人员能在运行时可以动态地管理和修改商业规则，保证了软件系统的柔性和自适应性，使电子商务平台为中小企业用户提供个性化的服务打下了良好的基础。

2、业务流程与规则引擎
2.1 业务流程与流程引擎
业务流程属于工作流的范畴。

工作流指全部或者部分由计算机自动处理的业
务过程。

而工作流管理系统是这样的一个系统：详细定义、管理并执行“工作流”，系统通过运行一些软件来执行工作流，这些软件的执行顺序由工作流逻辑的计算机表示形式（流程定义）来驱动。

工作流系统与业务系统的关系如下图所示：
国际标准化组织WFMC（工作流管理联盟）发布了一个通用的工作流系统实现模型，这个模型可以适用于市场上的大多数产品，因此为开发协同工作的工作流系统奠定了基础。

把工作流系统中的主要功能组件，以及这些组件间的接口看成抽象的模型。

考虑到会有许多其他的具体实现不同于这个抽象模型，因此，特定的接口在不同的平台中会采用不同的技术，有不同的实现方式。

而且并不是所有的开发商都会暴漏功能组件间的每一个接口，具体的规范会定义接口之间的相互操作功能，不同的厂商必须支持这些开放接口才能实现不同工作流之间的协作。

通用的工作流系统实现参考模型如下所示：
不同的厂商必须支持5类开放接口才能实现不同工作流之间的协作。

a)过程定义工具（Process Definition Tool）
过程定义是用来创建一个计算机可以处理的形式的过程描述。

可能要以形式过程定义语言、对象关系模型、简单的系统、脚本、或者在参与者间进行信息传递的路径集为基础。

工作流定义工具，可能作为工作流产品的一部分、也可能作为业务过程分析产品的一部分来提供给用户，作为业务过程分析产品一部分，会有其他的组件来负责处理业务过程的分析或者模型，这时，必须要有兼容的转换格式，与运行时期的工作流软件进行过程定义的相互转换。

b)过程定义（Process Definition）
过程定义包含，工作流执行软件运行过程所需的过程所有详细信息。

包括过程的开始和结束条件、组成活动、在活动间进行导航的规则、需执行的用户任务、可能会被调用的应用程序、所有工作流相关数据的定义等。

过程定义可能会涉及到一个组织/角色模型，模型包含组织结构和组织中的角色等信息。

从而使过程定义在，与具体活动或信息对象相关的组织实体和角色功能方面，十分详细。

工作流执行服务器负责把工作流运行环境中的参与者与相应的组织实体或角色联系起来。

c)工作流执行服务器（Workflow Enactment Service）
工作流执行服务器软件负责：解释过程定义、控制过程实例、安排活动的执行顺序、向用户工作表中添加工作项目、调用应用工具。

这需要一个或者多个协同工作的工作流机来完成这些职责，工作流机管理各种过程的一个单独实例。

工作流执行服务器维护内部控制数据，这些数据或者集中于一个工作流机中，或者分布在一个工作机集合中；这些工作流控制数据包括与各种过程、或者正执行的活动实例相关的内部状态信息，也包括工作流机用来合作或者从失败中进行恢复的检查点、恢复/重新启动信息。

过程定义与（运行时期）工作流相关数据协作，一同用来控制过程中活动的导航、提供活动的进入与退出条件、不同活动的并行执行、顺序执行选项、用户任务、与每个活动相关的IT应用程序等。

如果过程定义包括组织模型/角色实体类型，那么完成以上任务，需要访问组织/角色模型数据。

工作流机也包括调用一些形式的应用工具的能力，来激活必要的应用程序执行相关活动。

这种调用机制间有很大的不同，在一些简单的系统中，也许只提供对单一的固定工具调用（例如，文本编辑器），然而在工作流系统中可能提供调用本地与远程的大范围内工具的方法。

d)工作流相关数据和应用数据（Workflow Relevant Data and Application
Data）
过程导航判断或工作流机中的其他控制操作，都以工作流应用程序产生或者更新的数据为基础，这些数据可以被工作流机和条件工作流相关数据（也成为情况数据）所访问；这是工作流机唯一可访问的应用程序数据。

尽管，工作流机负责在应用程序间传递工作流应用程序数据，但工作流应用程序数据直接由被调用过程操作。

不同的应用程序由工作流过程内的不同活动调用。

e)任务表（Worklists）
过程执行中需要用户交互的地方，工作流机把任务添加到任务表中，以便任务表处理器对其处理，任务表处理器管理与工作流参与者的交互。

这个过程对工作流参与者可能是不可见的，任务表在工作流软件中维护，把用户需要执行的下一个任务提供给他。

在其他系统中，任务表可能对用户是可见，用户自己从任务表中选择执行任务，任务表也用来指示任务的完成。

f)任务表处理器用户接口（Worklist Handler & User Interface）
任务表处理器是一个软件组件，管理工作流参与者与工作流执行服务器间的交互。

任务表处理器负责请求用户关心的进展中的任务，并负责通过任务表与工作流执行服务器进行交互。

在一些系统中，只是使用一个桌面应用程序来提供一个简单的任务进入，等待用户注意。

在其他一些系统中，任务表的处理可能更成熟，控制任务在一些用户间进行分配，
并考虑到转载平衡、任务重分配等。

另外的一些任务表处理功能，工作
流机典型支持与客户端应用程序大范围的交互，包括工作流参与者的签
到和退出、请求过程实例的开始、任务排队等候特殊的参与者等。

在工
作流参考模型中，更广泛的使用“客户端应用程序”这个词，而不是“任
务表处理器”，从而反映其潜在的广大使用范围，其包含任务表处理功能
的同时也包含过程控制功能。

在上图中，用户接口是一个单独的软件组件，负责提示和处理用户对话
框，并控制本地用户的本地接口。

在某些系统中，用户接口可能会与任
务表处理器组合到一起，构成一个简单的功能实体。

我们希望一些客户
端应用程序能够和几个不同的工作流服务器进行交互，从而把服务器中
的任务整理成统一的格式，通过公共用户接口提供给用户。

可能会调用本地应用程序，来支持用户完成特殊的任务，这由任务表处
理器来负责，或者由用户负责，在用户接口使用简易通用工具来安装适
当的支持程序。

在任务表处理器/用户接口中调用应用程序与工作流执行
软件直接调用应用程序，有明显的不同。

g)管理操作（Supervisory Operations）
工作流系统中有许多的管理功能；这些管理功能以工作站点或者用户的
管理权限为基础。

这些管理功能使得管理者可以修改任务分配规则、确
定过程中组织角色的参与者、跟踪遗漏的最终期限报警或根据其他事件、跟踪某一过程实例的运行历史、查询任务吞吐量或其他统计信息等。

使
用分布式工作流机的地方，可能需要特殊的命令来在不同的工作流机间
传递控制操作或者（局部）响应，从而提供一个单一的管理接口。

h)外部和内部接口（Exposed and Embeded Interfaces）
上述的体系结构适用于大多数工作流产品，但是并不是所有的产品在每
个不同的系统功能组件间，都提供外部接口；一些产品把几个功能组件
作为一个逻辑实体来实现了，并把接口包含在了软件组件的内部，导致
无法被第三方产品使用。

WFMC规范定义了每个接口在实现多工作流系统
协同工作中的作用，因此，可以鉴别单独的产品是否符合协同工作标准。

2.2 规则引擎
规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。

与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。

1)信息元（Information Unit）
信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。

这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类
型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。

2)信息服务（Information Services）
信息服务产生信息元对象。

每个信息服务产生它自己类型相对应的信息元对象。

即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。

需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。

但无论如何，每个信息服务只产生它自己类型相对应的信息元。

3)规则集（Rule Set）
顾名思义，规则集就是许多规则的集合。

每条规则包含一个条件过滤器和多个动作。

一个条件过滤器可以包含多个过滤条件。

条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。

在程序运行时，动作将会在条件过滤器值为真的情况下执行。

除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。

前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。

4)队列管理器（Queue Manager）
队列管理器用来管理来自不同信息服务的信息元对象的队列。

下面将研究规则引擎的这些相关构件是如何协同工作的。

如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。

图2 处理过程协作图
3、规则引擎的工作机制
下面专门研究规则引擎的内部处理过程。

如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定义顺序检查信息元所带规则集中的规则。

如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下一条规则。

如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。

该信息元中的所有规则执行完毕后，信息元将被销毁，然后从队列管理器接收下一个信息元。

在这个过程中并未考虑两个特殊动作：放弃动作（Discard Action）和包含动作（Include Action）。

放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。

包含动作其实就是动作中包含其它现存规则集的动作。

包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。

这一过程将递归进行。

图3 规则引擎工作机制
Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。

Java规则引擎对提交给引擎的Java数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。

这些实例将在引擎接到执行指令时、依照某种优先序依次执行。

一般来讲，Java规则引擎内部由下面几个部分构成：工作内存（Working Memory）即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。

Java规则引擎的结构示意图如图4所示。

图4 Java规则引擎工作机制
当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。

于是就产生了一种“动态” 的规则执行链，形成规则的推理机制。

这种规则的“链式”反应完全是由工作区中的数据驱动的。

任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。

规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。

1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。

目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。

3、业务流程与规则引擎的融合
作为企业IT基础设施的关键部分，业务流程管理越来越重要了。

在BPM产品套件平台上，可以建模、部署、执行和监视企业的业务流程，业务流程可以包含业务规则。

例如，在银行的账户验证过程中，评估客户资格或确定价格的业务策略很复杂，而且在快速发展的市场中常常会变动。

把这些策略硬编码在过程中是不合适的，因为很难在运行时管理和维护业务规则。

通过把业务规则和业务流程分隔开，单独地执行和管理它们，可以提高整个业务流程的敏捷性和扩展性。

ILOG的JRules在融入到IBM的WebSphere套件体系后，在架构层面和技术层面充分体现了这种业务流程与业务规则分离的思想，如下图所示：
ILOG JRules是先进的业务规则管理系统（Business Rule Management System，BRMS），提供编写、部署和管理业务规则等业务功能，支持高效地修改策略和快速部署策略。

ILOG JRules提供一种建模、实现和部署业务规则的系统化方法。

它支持以有秩序的高效的方式进行协作。

它包含的工具针对不同用户的技能和知识优化过，因此策略经理、业务分析师和开发人员都可以获得所需的支持，可以尽可能发挥BRMS的价值。

4、重要意义
企业管理者对企业级IT系统的开发有着如下的要求：
1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂；
2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更
新；
3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序-
而项目开发人员则碰到了以下问题：
4程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型；
5软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中；
6对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。

基于规则的专家系统的出现给开发人员以解决问题的契机。

规则引擎由基于规则的专家系统中的推理引擎发展而来。

规则引擎技术为管理多变的业务逻辑提供了一种解决方案。

规则引擎既可以管理应用层的业务逻辑又可以使表示层的页面流程可订制。

这就给软件架构师设计大
型信息系统提供了一项新的选择。

而Java规则引擎在Java社区制定标准规范以后必将获得更大发展。