CN103150164A - 一种事务规则驱动的敏捷sowf架构方法 - Google Patents

Abstract

本发明专利实现了一种事务规则驱动的敏捷SOWF架构方法，包括以下步骤：（1）将业务活动封装成具有相对独立业务功能的事务服务；（2）基于XML语言定义事务规则模版，包括结构规则、数据规则、事件规则，用于限定事务服务的交互规则和交互方法；（3）实现了基于事务规则驱动的SOWF架构，包括事务规则定义层、工作流引擎层、事务服务层、业务活动层。（4）在事务规则驱动下动态组合事务服务，构建灵活的软件业务系统。该方法克服了现有SOWF重写过程模型的缺点，缩短了开发周期，具有快速响应业务需求变化的能力。

Description

一种事务规则驱动的敏捷SOWF架构方法

技术领域

本发明涉及面向服务架构、服务组合、工作流等技术领域，实现了一种事务规则驱动的敏捷SOWF架构方法，该方法在事务规则驱动下能够动态组合不同的事务服务，构建灵活的软件业务系统，满足用户业务不断变化的需求，该方法可有效避免工作流过程模型重写，缩短开发周期，具有快速响应业务需求变化的能力。

背景技术

面向服务架构（Service-Oriented Architecture,SOA）作为一种分布式软件架构模式通过服务组合构建软件系统，使得软件各模块之间的耦合度更低，是今后主流的软件形态。工作流技术是一种重组和自动化企业信息流程的技术，它可以缩减因业务变动产生的额外开销，并快速响应业务过程调整。面向服务工作流（Service-Oriented Workflow,SOWF）结合了SOA思想与工作流技术，解决了传统工作流技术无法满足跨组织的业务与应用集成的问题。

SOWF的概念由Piccinelli,G.在2003年提出，并给出了一个面向服务的工作流框架。罗英伟等（北京大学，2007）对SOWF技术进行了研究，提出了一个三层服务工作流模型。邵虹等人（沈阳工业大学，2008）开发了面向服务的工作流管理系统，将工作流引擎以及各个协作模块封装为服务，并作为独立的服务层，实现了工作流管理系统的松耦合。

现有SOWF的工作流过程模型的建立都是通过相应的业务过程执行语言（如BPEL4WS）以预定义的形式进行的，当业务变化的时候，需要将之前定义的过程模型重新改写，并构建新的工作流过程以响应业务的变化，而重写过程模型不仅需要花费较大的成本（约站所有工作量的80%以上），而且对业务需求变化的响应变得非常迟钝，导致软件系统无法有效地支持业务的运转。

发明内容

为了克服已有的SOWF模型在需求变化时需要重写过程模型的不足，缩短开发周期，快速响应业务需求变化，本发明提出了一种事务规则驱动的敏捷SOWF架构方法，其步骤如下：

1）将业务活动基于Web服务技术封装成具有相对独立业务功能的模块，称为“事务服务”。

2）定义事务规则模版。事务规则定义了事务服务的交互规则和交互方法，它包含一组约束规则，用来描述事务服务的数据、结构以及事件必须满足的限定条件，并通过约束作用于过程模型，使模型中定义的事务服务发生动态的重组，避免手动修改过程模型。事务规则模版基于XML语言定义，包含了一组标签，这些标签用于定义事务规则中的各类规则。

2.1)定义结构规则。结构规则Structure_Rule=<flow,pattern>，flows是流，pattern∈{sequential,iteractive,parallel,if,trigger}是流执行的模式，用于处理复杂的业务流程，其定义的标签是<rule type=”pattern”>,pattern的值共有五种：(1)sequence：顺序结构定义标签，表示其中的流顺序执行。(2)iteractive：循环迭代结构定义标签，表示其中的流循环执行。(3)parallel：并行结构定义标签，表示其中的流可并行执行。(4)trigger：触发规则标签，当条件被触发时，将执行定义流或过程，可用于定时控制与状态监控。(5)if：条件控制标签，用于逻辑判断与过程流转。

2.2)定义数据规则。数据规则Data_Rule=<activity_i,activity_k,message>，activity_i与activity_k表示两个交互的活动，activity_i→activity_k；message是activity_i流向activity_k的数据的限定，message∈outputs_i，message∈outputs_k。其定义的标签是<rule type=”data”>包含以下子标签：(1)target：数据规则针对的目标，值是服务的名称，表明对那个服务进行规则限定；(2)input：输入参数的限定，与message元素关联；(3)output：输出参数的限定，与message元素关联。下面是一个数据规则的XML Schema。

2.3)定义事件规则。事件规则Event_Rule=<event,target,message,action>，其中event是事件的名称；target是事件作用的活动或流的对象集合；message是事件发生时产生的消息；action是事件的处理方法。其标签为<rule type=”event”>包含以下子标签：(1)target：事件规则影响的对象，值是服务的名称，表明对那个服务进行规则限定；(2)message：表明事件的参数信息，通过名称与已定义的message元素进行关联；(3)event：对事件的来源（source），触发信号（signal），回应行为（action）做出定义。

3）实现事务规则驱动的SOWF架构。该架构包括四层：事务规则定义层、工作流引擎层、事务服务层、业务活动层，下面对每层的组成及功能做一说明：

3.1)事务规则定义层主要包括流程管理器、过程模型编辑器与规则模板编辑器。流程管理器用于对流程进行管理，包括流程创建与终止；过程模型编辑器用于对过程模型库中的过程模型文件进行管理，包括定义活动、流、消息等要素，以及描述抽象业务过程；规则模板编辑器用于新建与编辑规则模板，包括规则模板的定义、规则模版库管理等。

3.2)工作流引擎层主要包括事务规则引擎、事务规则库、过程模型库。事务规则引擎负责规范工作流引擎的启动和执行，解析流程事务规则XML文件，依据事务规则组合事务服务来完成特定的业务需求；事务规则库用于存储规则模板，并提供给事务规则引擎，事务规则引擎根据读取规则库中的规则模板进行业务流程的组合与搭建。过程模型库提供基本的过程模型元素，用于支持业务流程的组合。

3.3)事务服务层为工作引擎层提供服务，是多个事务服务的集合。事务服务是由业务活动封装而成。业务活动被服务化后可以消除异构系统与平台的差异性，即服务层可以容纳跨系统跨部门的业务活动。

3.4)业务活动层由已存在的业务系统提供，多个活动可以属于同一个业务系统，也可以跨越不同的业务系统。

4)将事务规则模版作为SOWF架构的输入，其工作机制如下：

4.1)通过规则模板编辑器撰写事务规则模板。

4.2)通过流程管理器将描述了服务执行流程的事务规则模板输入到规则库中，事务规则模板以Key-Value的方式存储到NoSQL形式的事务规则库中。

4.3)解释器通过Key读取规则库里存储的规则模板，并进行翻译，将生成的经过优化并容易处理的中间代码提交给组合器。

4.4)组合器对中间代码进行解析及预处理操作。首先计算出所有的过程模型元素的引用，然后通过调度器发出调度指令，将这些引用映射为具体的业务实体，如服务和消息。接着经由绑定器将由调度器申请到的业务实体与上下文绑定在一起，进行服务实例以及资源的预分配。最后则将一系列动作产生的描述信息写回到中间代码中，并进行编译工作，输出可执行二进制代码，这样就完成了抽象的规则模板和过程模型描述到可执行流的映射。

4.5)处理完成之后，组合器将可执行流提交给执行器进行执行。执行器保证了组合过程中的资源分配与执行环境的可靠，同时监控工作流的执行状态。

本发明的优点是：可以克服现有SOWF在业务需求变化时需要重写过程模型的缺点，在事务规则驱动下通过动态组合事务服务构建软件业务系统，大大缩短开发周期，提高了快速响应用户业务需变化的能力。

附图说明

图1事务规则驱动的SOWF架构

图2SOWF架构工作过程

图3高级专业技术资格职称申报与评审流程

图4结构规则的定义方式

图5数据规则的定义方式

图6事件规则的定义方式

具体实施方案

参照附图，对本发明作进一步说明。

一种事务规则驱动的敏捷SOWF架构方法，包括以下步骤：

1）将业务活动基于Web服务技术封装成具有业务功能的事务服务。以图3的高级专业技术资格职称申报与评审流程举例，表1列出了其中的主要事务服务。

表1高级专业技术资格职称申报与评审的主要事务服务

2）定义事务规则模版，实现基于事务规则驱动的工作流动态构建目标，为了得到图3中的工作流过程，定义了以下规则：

2.1）定义结构规则。表2给出了所定义的每一个流的执行模式，流是由事务服务组合而成的。如SR1表示流将以触发模式（trigger）执行，触发的条件是当日日期为2013年的4月1日（expression=”today=2013/4/1”）。而SR2则表示流将以顺序模式（sequential）执行。结构规则定义方式见图4。

表2高级专业技术资格职称申报与评审的结构规则

2.2）定义数据规则。表3中的数据规则定义了服务之间传递消息的约束。如DR1表明，FillFormService与FormValidateService进行组合，那么FillFormService的输出中必须包含applicant,applyDate,qualification这三个参数，并且FormValidateService的输入中也必须包含以上参数，如此两个服务才能进行组合。数据规则定义方式见图5。

表3高级专业技术资格职称申报与评审的数据规则

2.3）定义事件规则。表4的事件规则定义了事件的影响范围及处理方式。如ER1表明，ConditionUnavailableEvent这个事件作用于四个服务。当事件响应时，将调用事件处理服务FormRejectService进行处理。事件规则定义方式见图6。

表4高级专业技术资格职称申报与评审的事件规则

3）开发事务规则驱动的SOWF架构。该架构如图1所示，包括四层：事务规则定义层、工作流引擎层、事务服务层、业务活动层，下面对每层的组成及功能逐一说明：

3.1)事务规则定义层主要包括流程管理器、过程模型编辑器与规则模板编辑器。流程管理器用于对流程进行管理，包括流程创建与终止；过程模型编辑器用于对过程模型库中的过程模型文件进行管理，包括定义活动、流、消息等要素，以及描述抽象业务过程；规则模板编辑器用于新建与编辑规则模板，包括规则模板的定义、规则模版库管理等。

3.2)工作流引擎层主要包括事务规则引擎、事务规则库、过程模型库。事务规则引擎负责规范工作流引擎的启动和执行，解析流程事务规则XML文件，依据事务规则组合事务服务来完成特定的业务需求；事务规则库用于存储规则模板，并提供给事务规则引擎，事务规则引擎根据读取规则库中的规则模板进行业务流程的组合与搭建。过程模型库提供基本的过程模型元素，用于支持业务流程的组合。

3.3)事务服务层为工作引擎层提供服务，是多个事务服务的集合。事务服务是由业务活动封装而成。业务活动被服务化后可以消除异构系统与平台的差异性，即服务层可以容纳跨系统跨部门的业务活动。

4）将事务规则文件作为SOWF架构的输入，该架构包括事务规则定义层、工作流引擎层、事务服务层、业务活动层四层。该模型的工作步骤如图2所示，具体如下：

4.1)通过规则模板编辑器撰写事务规则模板。

4.2)通过流程管理器将描述了服务执行流程的事务规则模板输入到规则库中，事务规则模板以Key-Value的方式存储到NoSQL形式的事务规则库中。

事务规则库的存储方式并非使用关系数据库存储，而是通过NoSQL方式存储，因此可以支持松散的数据结构，尤其适合存储XML文件，拥有极强的灵活性与易用性。每一个规则模板都用唯一的key来标识，通过key可以对规则模板进行增删改查。

事务规则库中的记录可进行如下形式化：

记录Record=(key,value)，其中key是主键，value是存储的内容，value=(template,instances)，template表示事务规则模板的结构化存储，instances表示应用该规则模板的实例集合。

由于NoSQL支持松散数据结构的特性，因此每一条记录都可以存储不同结构的template。如我们在key=”sr11536”的记录中存储了一条结构规则，template内容用JSON描述如下：

{

"type":"sequence",

"flow":{

"services":[“serivce1”,“serivce2”,“serivce3”]

}

}

而在key=”dr2398”的记录中存储了一条数据规则：

{

"type":"data",

"from":"serivce1",

"to":"service2"

"message":"message1"

}

4.3)解释器通过Key读取规则库里存储的规则模板，并进行翻译，将生成的经过优化并容易处理的中间代码提交给组合器。

4.4)组合器对中间代码进行解析及预处理操作。首先计算出所有的过程模型元素的引用，然后通过调度器发出调度指令，将这些引用映射为具体的业务实体，如服务和消息。接着经由绑定器将由调度器申请到的业务实体与上下文绑定在一起，进行服务实例以及资源的预分配。最后则将一系列动作产生的描述信息写回到中间代码中，并进行编译工作，输出可执行二进制代码，这样就完成了抽象的规则模板和过程模型描述到可执行流的映射。

由于组合器同时承担着调度、绑定、输出可执行流的功能，因此组合器的设计较为复杂与庞大。为了降低组合器的复杂性与模块的耦合程度，调度器与绑定器作为相对独立的模块分离开来，各自提供了一系列统一的接口供组合器进行调用，从而隐藏了实现细节，简化了组合器的设计。因此组合器可以通过这些接口协调调度器与绑定器共同工作。

调度器主要提供了以下接口：

a)Service mapService(Element ele)：将过程模型元素映射为具体的服务对象。

b)Message mapMessage(Element ele)：将过程模型元素映射为具体的消息对象。

c)bool isAvailable(Element ele)：判断该元素对应的服务或消息对象是否可供调度。

绑定器主要提供了以下接口：

a)void bindService(Context cxt,Service svc)：将服务对象与上下文进行绑定。

b)void bindMessage(Context cxt,Service svc)：将消息对象与上下文进行绑定。

4.5)处理完成之后，组合器将可执行流提交给执行器进行执行。执行器保证了组合过程中的资源分配与执行环境的可靠，同时监控工作流的执行状态。

Claims (1)

1.一种事务规则驱动的敏捷SOWF架构方法，其步骤如下：

1）将业务活动基于Web服务技术封装成具有相对独立业务功能的模块，称为“事务服务”。

2）定义事务规则模版。事务规则定义了事务服务的交互规则和交互方法，它包含一组约束规则，用来描述事务服务的数据、结构以及事件必须满足的限定条件，并通过约束作用于过程模型，使模型中定义的事务服务发生动态的重组，避免手动修改过程模型。事务规则模版基于XML语言定义，包含了一组标签，这些标签用于定义事务规则中的各类规则。

2.1)定义结构规则。结构规则Structure_Rule=<flow,pattern>，flows是流，pattern∈{sequential,iteractive,parallel,if,trigger}是流执行的模式，用于处理复杂的业务流程，其定义的标签是<rule type=”pattern”>,pattern的值共有五种：(1)sequence：顺序结构定义标签，表示其中的流顺序执行。(2)iteractive：循环迭代结构定义标签，表示其中的流循环执行。(3)parallel：并行结构定义标签，表示其中的流可并行执行。(4)trigger：触发规则标签，当条件被触发时，将执行定义流或过程，可用于定时控制与状态监控。(5)if：条件控制标签，用于逻辑判断与过程流转。

2.2)定义数据规则。数据规则Data_Rule=<activity_i,activity_k,message>，activity_i与activity_k表示两个交互的活动，activity_i→activity_k；message是activity_i流向activity_k的数据的限定，message∈outputs_i，message∈outputs_k。其定义的标签是<rule type=”data”>包含以下子标签：(1)target：数据规则针对的目标，值是服务的名称，表明对那个服务进行规则限定；(2)input：输入参数的限定，与message元素关联；(3)output：输出参数的限定，与message元素关联。下面是一个数据规则的XML Schema。

2.3)定义事件规则。事件规则Event_Rule=<event,target,message,action>，其中event是事件的名称；target是事件作用的活动或流的对象集合；message是事件发生时产生的消息；action是事件的处理方法。其标签为<rule type=”event”>包含以下子标签：(1)target：事件规则影响的对象，值是服务的名称，表明对那个服务进行规则限定；(2)message：表明事件的参数信息，通过名称与已定义的message元素进行关联；(3)event：对事件的来源（source），触发信号（signal），回应行为（action）做出定义。

3）实现事务规则驱动的SOWF架构。该架构包括四层：事务规则定义层、工作流引擎层、事务服务层、业务活动层，下面对每层的组成及功能做一说明：

3.1)事务规则定义层主要包括流程管理器、过程模型编辑器与规则模板编辑器。流程管理器用于对流程进行管理，包括流程创建与终止；过程模型编辑器用于对过程模型库中的过程模型文件进行管理，包括定义活动、流、消息等要素，以及描述抽象业务过程；规则模板编辑器用于新建与编辑规则模板，包括规则模板的定义、规则模版库管理等。

3.2)工作流引擎层主要包括事务规则引擎、事务规则库、过程模型库。事务规则引擎负责规范工作流引擎的启动和执行，解析流程事务规则XML文件，依据事务规则组合事务服务来完成特定的业务需求；事务规则库用于存储规则模板，并提供给事务规则引擎，事务规则引擎根据读取规则库中的规则模板进行业务流程的组合与搭建。过程模型库提供基本的过程模型元素，用于支持业务流程的组合。

3.3)事务服务层为工作引擎层提供服务，是多个事务服务的集合。事务服务是由业务活动封装而成。业务活动被服务化后可以消除异构系统与平台的差异性，即服务层可以容纳跨系统跨部门的业务活动。

3.4)业务活动层由已存在的业务系统提供，多个活动可以属于同一个业务系统，也可以跨越不同的业务系统。

4)将事务规则模版作为SOWF架构的输入，其工作机制如下：

4.1)通过规则模板编辑器撰写事务规则模板。

4.2)通过流程管理器将描述了服务执行流程的事务规则模板输入到规则库中，事务规则模板以Key-Value的方式存储到NoSQL形式的事务规则库中。

4.3)解释器通过Key读取规则库里存储的规则模板，并进行翻译，将生成的经过优化并容易处理的中间代码提交给组合器。

4.4)组合器对中间代码进行解析及预处理操作。首先计算出所有的过程模型元素的引用，然后通过调度器发出调度指令，将这些引用映射为具体的业务实体，如服务和消息。接着经由绑定器将由调度器申请到的业务实体与上下文绑定在一起，进行服务实例以及资源的预分配。最后则将一系列动作产生的描述信息写回到中间代码中，并进行编译工作，输出可执行二进制代码，这样就完成了抽象的规则模板和过程模型描述到可执行流的映射。

4.5)处理完成之后，组合器将可执行流提交给执行器进行执行。执行器保证了组合过程中的资源分配与执行环境的可靠，同时监控工作流的执行状态。

Images