基于REST风格的资源化工作流引擎的研究.

谢凌奇，姜丽红，蔡鸿明

0 引言

工作流引擎是企业将其分散的应用连接并整合成一个完整流程应用的调度工具。随着云应用普及以及企业流程的愈加复杂化，企业不但需要能够复用的云应用，还需要能够复用的工作流，也就是说企业需要一个能够部署在云端，能够将工作流要素封装好并提供给客户使用，并能够与云端应用顺利交互的工作流引擎。

目前工作流引擎结构复杂，与应用耦合度较高，这种架构不利于在云端的部署，难以与不同结构远端服务进行交互。传统工作流引擎只能以流程为单位存储工作流要素，因此也无法以流程子节点的层次提供工作流要素给客户进行复用，难以满足客户对细节定制的需要。

常见的工作流引擎有集中式和分布式工作流引擎，Yang[1]等人利用J2EE分布式对象框架实现分模块的工作流引擎，但在各模块之间的交互上消耗过多的时间，也提高了出错几率。王明微[2]等人提出了一种“按需分配”的工作流任务分配方法，处理云端工作流引擎的协同处理问题。Bin[3]等人设计了面向SAAS应用的工作流引擎， Barker[4]等人提出了用编排模型优化工作流与服务之间的信息传输，但没有考虑异构数据的转换问题，Yu-Yen[5]等人设计了一个集成框架以实现 SOAP与 REST服务的转化，但是消耗过高，Prashant[6]提出了方法资源的概念，很好地解决 REST服务对于复杂操作支持度低的问题。

在此基础上设计了基于 RESTful风格的资源化工作流引擎，利用RESTful风格架构使其适应云端部署环境，利用RESTful服务中每个资源结点都可以发布并接受访问的特性，将流程、活动、实例等所有工作流要素都封装为REST的资源并建立元模型库，从而能够以流程节点的层次提供可复用的工作流要素。

1 工作流引擎的资源抽象

一个工作流引擎的实现分为流程设计、流程管理、应用调用和部署4个部分，如图1所示：

图1 资源化引擎设计框架

基于REST的资源化工作流引擎的设计思路，分为两步，第一步是鉴定出工作流中可以抽象为资源的要素，将流程定义、活动、任务、数据、角色等工作流要素归类为实体资源，把要素之间的关系界定为资源关系，把启动流程、挂起、终止等需要分多步调用资源的操作抽象为方法资源，然后建立资源元模型，并持久化到数据库中。第二步是将所有资源封装，构建为REST服务并以统一的WADL进行描述。

在引擎部署时，一个RESTful服务框架的工作流引擎能够很好的适应云端环境。能够以通用的标准接口在远端发布服务，并为客户提供调用方式。在流程设计和流程管理部分，封装为资源的每一个流程要素都能够独立的进行发布、创建、修改、复用等操作，客户可以灵活的操作和管理每个流程要素，且不用担心流程细节不能复用。在应用调度方面，RSET化的工作流引擎使用标准的HTTP访问方式，能够更顺畅地与Web服务进行交互。

1.1 工作流建模与实体资源抽象

构建资源化的工作流引擎，首先就是要将工作流中的部分要素抽象并封装为实体资源，流程的定义、活动、活动关系、逻辑规则等实体资源以及它们之间的关联。如图 2所示：

图2 资源模型

在图2中，W是工作流的抽象，工作流的所有内容都包含在W之中。PDe为流程定义的抽象，可定义为公式（1）

将 PDe封装为资源，并分配 URI Http://orips3.com/W/{W_ID}/PDe。

流程定义中包括了流程定义编号（PDe_ID）、活动（A）、活动关联（C）、逻辑节点（R）和流程状态（State）。其中A为所有活动的集合，A可定义为公式（2）

其中A_ID为活动的标识，A_Task为该活动需完成的任务的抽象，包含了指向待操作的Web服务的链接。A_Role是该活动中被分配任务的角色的抽象，A_Data是该任务将要处理的数据对象的抽象。最后将活动 A抽象为资源，并分配 URI即 Http://orips3.com/W/{W_ID}/PDe/{PDe_ID}/A/{A_ID}，将 A_Task、A_Role、A_Data同样抽象为资源，URI则按照层级规则放置在PDe之下，如A_Task的URI为Http://orips3.com/W/{W_ID}/PDe/{PDe_ID}/A/{A_ID}/A_Task。

R为流程定义中的逻辑节点抽象，可形式化表述为公式（3）

其中R_ID是逻辑节点的标识，R_Rout是逻辑节点类型，Rout∈（Sequence,Choice,Fork,Merge,Synchronization），R_Rule存储了逻辑节点的判断规则，R_Data存储了需要判断的数据。R的 URI为 Http://orips3.com/W/{W_ID}/PDe/{PDe_ID}/R。

流程定义中的C是对流程中活动之间的关联抽象，可形式化表述为公式（4）

其中C_Link存储了节点间的连接关系。C_rule描述了连接关系需要遵循的规则，State记录了流程的状态，具体有Pre，Runing，Hang-up，Stop， Terminated五种值。

1.2 资源关系建模

传统工作流引擎使用流程描述文档存储工作流要素之间的关系，资源化工作流引擎用资源元模型存储。图2中以流程定义以及其关联资源为例，解释了工作流中资源之间的关系以及其描述方式，具体的流程描述以一个流程定义的资源实例展示：

流程定义资源拥有ID、流程状态、活动、活动链接和逻辑节点5个个属性，后3个属性在引擎中已经被封装为实体资源，因此该资源实例在描述后3个属性时直接建立对这3个实体资源的引用链接，而活动节点资源会引用任务资源、角色资源和数据资源，任务资源又将引用需处理的Web服务。通过资源模型的层层引用，以及活动链接资源描述的节点顺序关系，描述了流程所需的一切信息，为资源建立了符合层次和语义的资源关系体系。

1.3 方法资源

对于工作流引擎中的实体操作，HTTP协议中规定的接口能够顺利完成，但是对于一些需要多步操作的复杂功能，标准接口就不能支持。为了解决这个问题，采用了定义方法资源，并将操作步骤记录在动作资源的属性中，由解析器解析后逐步执行的方式来解决问题的方式。

以挂起流程这个复杂操作作为范例阐述复杂资源的运作方式，如图3所示：

图3 方法资源模型

挂起操作被封装为一个方法资源，拥有 URI、参数和接口，参数中以伪代码定义了挂起的几个步骤以及涉及到的资源。在被访问时，解析器读取 Hug资源的参数，解析出对资源操作的多个步骤，然后按照顺序调用先以访问流程实例资源，获取其状态，判断该状态是否是RUNNING，如果是则继续用PUT方法调用流程实例资源，修改状态为HUG。

工作流引擎的其他操作也以同样方式抽象为方法资源并通过解析器运作，具体包括了流程的启动、挂起、终止、恢复、完成任务等流程调度操作。

1.4 资源持久化

在定义完工作流引擎的所有资源后，最后一步便是将这些资源持久化到数据库中。一个资源的持久化分为两部分，第一是保存资源元模型，每个资源只有一份，以XML文档形式存储在数据库中。第二是资源的数据持久化，每个资源匹配一张数据表，数据表的项与资源元模型的属性一一对应，每个资源可以创建无数条的数据，每条数据对应一个资源实例。

获取一个资源的持久化数据时，首先先查询该资源匹配的数据表，然后查找到该资源的元模型，并按照对应关系把数据的每一项填入元模型的属性中，若该元模型有关联其他资源，则会抽取多个相关数据表的数据，填入各自对应的元模型中，最终组成一个大的实例模型作为该资源的持久化数据。

2 REST服务封装

2.1 接口封装

按照 RESTful风格，将所有接口和访问方法限制在HTTP规范中，所有资源的拥有统一的接口，URI也按照统一层级定义了描述规范，外界通过URI以及HTTP标准接口对封装好的工作流引擎服务进行操作。

接口封装定义的重点在于对关联资源的接口关系处理，以及对方法资源接口的处理。以流程定义和其关联资源为例展示了关联接口的运作方式，如图4所示：

图4 关联接口模型

当流程定义资源接到GET访问时，解析器会查询流程定义的资源元模型，获取其中对于关联资源的描述，根据描述中关联资源的 URI以及关系信息，解析器会将其分解为多步操作，分别访问其他资源的接口，最后将获取到的信息打包并返回流程定义资源。而对于方法接口则以图3为例，由解析器读取方法资源中的动作描述，同样分解为多步操作并调用相关资源，最终将信息打包返回方法资源。封装好REST接口后，通过元模型的描述以及接口定义，以REST框架建立 WADL并对资源化的工作流引擎进行描述和发布。

2.2 资源解析器

资源解析器负责对 URI、资源关联、方法资源进行解析，并调用核心引擎进行实际处理，是REST服务接口与后台之间的连接器。

资源解析器能够读取所有的资源模型并对其进行解析。在图3和图4有所提及资源解析器的运作方式，当外界访问某个资源的 URI以及接口时，由资源解析器读取该资源的元模型，然后判断该资源类型，如果是方法资源，则解析元模型中的命令，分多步反应到后台核心引擎进行操作。如果是实体资源则读取与其相关联的其他资源，并解析为多个命令反应到核心引擎。

另外，资源解析器拥有一张注册表，里面记录了 URI与后台操作模块的对应关系，当外界访问资源接口时，由资源解析器调用后台核心引擎进行具体操作。

2.3 异构信息转换器

资源化工作流引擎主要针对Web端的应用访问，而此类应用多为SOAP Web Service以及REST Web Service两种格式，因此需要对传输的信息进行格式的判断和转换。

转换器首先创建一个REST资源信息包，然后将SOAP服务的请求封装，将其存储在REST资源的属性中，最后以REST资源信息包的形式发送至工作流引擎，与其进行交互。而返回信息则是逆转，将REST消息中的SOAP消息提取，并以SOAP消息格式发送至服务中，从而实现了工作流引擎对不同格式服务的调用。

2.4 核心引擎

核心引擎负责实现流程调度、服务调度、数据持久化等核心功能，一切访问在经过资源解析器的解析后都在核心引擎中运行。这里以启动流程这个方法资源的运行过程来展示核心引擎的功能。

资源解析器解析启动流程这个方法资源后，列出 4个操作步骤，分别为查询流程、修改流程状态、获取流程起始活动、获取活动中任务与角色并分配。核心引擎被调用后，首先查询流程资源的持久化表格，找到需要启动的流程资源数据，修改流程状态数据为运行，然后根据流程资源所引用的活动连接资源找到起始节点，根据活动资源中引用的任务资源、数据资源和角色资源找到数据库中对应的各表格，并取得其对于服务的引用地址、数据格式、对应的角色数据。根据获取的信息由核心引擎建立与服务的连接，将服务对应的界面提供给角色进行操作，将操作结果根据数据格式打包后发送至服务，从而完成流程的启动过程。

3 系统实现与验证

3.1 系统实现

系统架构，如图5所示：

图5 系统架构

分为界面层、REST接口层、资源解析器、核心引擎、元模型库和数据存储层。用户界面层采用HTML5和EXTJS搭建了流程设计器，具体包括了界面上的要素控件、控件拖拽、任务角色定义、资源导入界面以及将可视化流程编译为XML文档的流程转换器。另外搭建了流程管理监控工具，用于监控流程运行状态以及控制流程调度。REST接口层和资源解析器中，搭建了HTTP服务器进行消息的收发，建立了 URI注册表和资源元模型库为资源解析器提供支持，解析器负责访问消息的解析以及通过 Spring框架调用核心引擎处理具体内容。核心引擎负责实现流程、服务、数据的操作和调度，包括一个异构服务消息转换器。数据存储层由XML文件管理和数据库管理组成，XML文件管理负责存储资源元模型，数据库中存储了资源匹配的数据表。

3.2 系统验证

将以较为典型的订单创建流程为例，实现工作流要素的复用并调用Web服务完成流程的运行。

假设用户原有流程中已经拥有订单创建节点，现在需要新增成品库房、零件清单、库存清单、采购清单的管理。操作界面，如图6所示：

图6 流程设计器

用户进入流程设计器界面，打开资源导入窗口，此时前台界面将访问活动资源的 URI即 Http://www.orips3.com/W/PDe/A，解析器解析请求后将所有资源返回前台。用户选择成品库房资源、零件清单资源、库存清单资源、采购清单资源导入流程中形成可视化控件，然后连接所有控件形成新的流程。核心引擎将创建该资源元模型并存储为XML文档。用户启动流程，则该方法资源被访问，核心引擎解析流程信息找到订单创建活动元模型并获取待操作的Web服务引用和任务角色，然后将服务界面发送给用户操作，核心引擎负责与服务的连接，若是SOAP服务则用异构信息转换器将报文包装为REST格式。用户完成任务后，该方法资源被访问，核心引擎记录流程进度并将下一个任务服务发送给用户，最终用户完成所有任务，该流程资源实例改状态为终止，如图7所示：

图7 流程监控工具

通过流程管理监控工具可查看流程运行的各个步骤以及对应的状态，通过对监控结果的查询证明了流程在引擎中的顺利运行，确保资源化的工作流引擎达到了要求。

3.3 评估对比

在对资源化的工作流引擎与传统工作流引擎进行测试和对比之后，验证了资源化工作流引擎在云端部署与工作流资源复用时有着明显优势，表1为传统工作流引擎和资源化的工作流引擎的对比图表，如表1所示：

表1 资源化工作流引擎与传统引擎的对比

4 结论

针对企业对工作流复用的需求以及传统工作流引擎对云端部署不适应的问题，提出了一个面向资源架构（ROA）的工作流引擎，该引擎能够轻松在云端部署并提供服务，能够灵活发布和复用工作流资源。基于对面向资源架构以及工作流结构的研究，将工作流细分为众多独立模块，将引擎中的工作流要素、操作、关联抽象为资源，赋予其URI，并进行元模型描述。然后以REST框架将所有资源封装为一个服务，以统一接口对外提供调用，封装后可以作为一个平台为客户提供工作流引擎服务，同时收集客户定制的各种工作流要素并封装为资源，形成资源库以提供给客户进行复用。整个资源化的工作流引擎拥有很好的云环境适应力，以及强大的工作流要素发布与复用的功能。

[1]Yang Liu,Yan Ma,et al. Design and Implementation of Distributed Workflow Engine Based [C]on Java EE Platform,Wuhan, pp.1-4, Dec.25-26 2010.

[2]王明微， 周竞涛. 敬石开面向云制造的按需工作流任务分配方法, [J]计算机辅助设计与图形学学报, Vol 24,No.3, Mar.2012

[3]D-OSyRIS: A Self-Healing Distributed Workflow Engine Based on Java EE Platform,Information Engineering and Computer Science (ICIECS), [C]Cluj Napoca,pp.1-4,July.6-8 2011.

[4]Bin Wu, Shuiguang Deng,et al. Reference Models for Saas Oriented Business Workflow Management Systems,Services Computing (SCC), [c]Washington, DC,pp.242-249, July 4-9 2011.

[5]Barker, A., Weissman, J.B.,et al. Reducing Data Transfer in Service-Oriented Architectures: The Circulate Approach,IEEE Transactions [J]on Services Computing,Vol.5, No.3, pp.437-449, Aug.2012.

[6]Yu-Yen Peng,Shang-Pin Ma,et al. REST2SOAP: A framework to integrate SOAP services and RESTful services,Service-Oriented Computing and Applications [J](SOCA),Taipei,pp.1-4,Feb.08 2010.

[7]Haibo Zhao;Prashant Doshi, Towards Automated REST-ful WebService Composition, Service-Oriented Computing and Applications (SOCA), [C]Los Angeles, CA,pp.189-196,July.31 2009.