基于柔性业务流程的RESTful信息资源池研究和实现

王 帅，蔡鸿明

0 引言

对于每个企业来说，业务流程是最为核心的部分。随着全球化经济以及IT技术的不断发展，企业的业务流程变得更灵活，更复杂。在企业将业务流程信息化的道路上有多个难题阻碍：如何实现柔性可配置的业务流程；业务流程的自动化部署与实施；如何访问和管理业务流程涉及到的企业信息资源（数据库表，结构化文档等），如何集成其他信息平台。

目前常见的解决方案主要是利用工作流引擎以及面向操作及流程组合的过程建模语言，如BPEL硬编码实现。然而这种解决方案太过重量级，难于实现，耗时费力，缺乏灵活性，不适应流程经常动态改变的企业。另外随着云计算时代的到来，这样的系统缺乏扩展性和集成性，会使得企业信息化落于被动。工作流引擎作为系统访问的中枢，难以处理大并发量的请求，会成为企业信息平台的瓶颈，目前的分布式工作流引擎又没有大规模的被实践应用[1]。

为了能够实现企业信息系统与异构平台的集成，系统必须具有开放性，集成性，拥有统一的访问与操作接口。目前主要有两种解决方案：面向服务架构 SOA[2](Service Oriented Architecture)的 SOAP[3]服务(Simple Object Access Protocol)以及面向资源架构ROA (Resource Oriented Architecture)[4]的 REST[5]服务(REpresentational State Transfer)。相比面向操作的SOAP服务，面向资源的REST服务更适应以资源为中心的企业信息系统。因此资源池基于 RESTful理念实现。

在REST的流程实现方面，文章[6]提出了一种基于资源状态的流程运行架构，通过对资源的状态进行建模，利用状态机实现资源的状态转换进而达到流程进行的目的。文章[7]提出了基于REST的BPEL流程建模语言，该文章通过BPEL for REST实现REST服务组合，然后利用服务组合来实现企业的业务流程运转。在资源的运行与管理方面，文章[8]基于服务组合和WS-BPEL语言提出了一种重量级的柔性工作流解决方案。文章[9]通过基于企业基本信息单位的资源元模型构建了基于资源的集成系统平台，该平台利用工作流引擎将资源串联成业务流程，并且使用了本体来定义和管理资源。

基于上述情况，本文提出了RESTful信息资源池。资源池以企业的流程为核心，以企业的信息资源为出发点，构建了一个能够将企业流程自动信息化，资源实体化的中间件平台。该平台提供灵活的流程组合与拆分，能够让用户实时的访问与管理企业的业务流程及相应的信息资源，优化访问请求并提供安全及事务保障。

1 RESTful信息资源池框架

资源池是企业业务流程以及信息资源的容器，负责它们整个生命周期的管理，如图1所示：

图1 资源池抽象架构

资源池在整个企业信息系统中所属的层次。资源池属于企业信息系统的中间件，它负责连接企业上层应用系统和底层数据库，资源池将内部资源以REST服务的方式暴露给企业上层应用。

资源池的输入是一些已经被业界采纳为流程建模标准的语言（如BPMN, BPEL），通过流程转换模块，资源池将这些文件转换为资源池可读的格式文件。资源池根据这些文件的描述，在企业的数据库中建立相应的表。

资源池中主要有两类资源：流程资源以及业务实体资源。业务实体资源即与数据库中的表对应，它是表的抽象，可以是表的一部分，也可能是由多个表通过关系（如包含，继承）组合而成。资源间可以动态的进行组合和拆分，以达到多粒度的灵活性。流程资源是由一系列的实体资源组合而成，通过资源的状态变化而相互连接，进而完成一整个业务流程。流程资源的核心是资源状态表以及资源状态机。资源状态表记录了资源所应有的状态，状态机则根据这些状态判断应该执行哪个子流程，应该接下来去操作哪些资源。资源池通过上述一整个步骤来实现业务流程的运转。

为了应对企业业务流程的灵活性，资源池支持流程资源之间的组合与拆分，从而提供动态的业务流程控制。在下文中，将针对资源池中所含资源建模以及具体如何实现资源池上述特性进行展开。

2 资源池建模

2.1 业务实体资源元模型

实体资源是数据表的抽象。数据表包含了很多列来表现数据，数据表间可以通过诸如外键，一致性约束等方式建立与其他表的联系，资源实现并扩展了这些特性。

定义1：资源(Resource)定义: Resource = (URI, RP, OS,RS, RR)

资源主要由以下元组组成，统一资源标识符 URI，资源属性集RP，资源操作集OS，资源状态集RS和资源关系集RR组成。

根据REST的理念，每一个资源都由一个唯一的URI（Uniform Resource Identifier）来表示，URI使得网络可以通过特定的协议(如 HTTP, FTP)找到该资源并与它进行交互。对于外部访问请求，无论是访问业务实体资源还是流程资源，在资源池中资源的URI都是唯一的标识和入口。

定义 2：资源属性(Resource Property)定义：RP =(ResID, ResType, ResourceProps, TableProps)

ResID是对资源URI的引用，是资源属性的唯一标识。ResType 表明该资源的类型，如果 RestType = ‘Simple’,说明该资源是针对一个数据表的抽象。如果 ResType = ’Compound’，表明该资源是由多个数据表或者多个资源通过资源关系建立而成，属于复合资源。资源属性ResourceProps与表属性TableProps属于对应关系，一个资源属性可以看成由一个或多个表属性组成的视图。例如：如果订单Order表有一个TableProps叫做 price表明订单的金额，在把订单表抽象成订单资源时，可以为订单资源增加一个叫做Sum_Price的资源属性，它表示Sum_Price = Sum (price in every Order Table)。

定义3：资源操作集OS（Resource Operation Set）

REST建立在 HTTP基础架构之上，其利用了 HTTP本身的元语操作来完成自身的功能，例如HTTP中的GET,POST, PUT, DELETE表示对资源的增删改查功能。OS定义了针对该资源可以实行哪些HTTP操作，从而为资源池的权限和访问管理模块提供支持。

定义4：资源状态集RS（Resource Status Set）定义：RS = (Statuses, Rules)

资源状态集规定了该资源都具有哪些状态，RS是资源池管理资源，控制资源的核心，也是业务流程资源进行流程运转判断时最重要的依据。Rules描述了该资源状态间的跳转规则。资源状态集的例子表示，如图2所示：

图2 资源状态迁移

图中左边显示了订单资源的状态迁移过程。订单资源总够有9种资源状态，从一种资源状态跳转到另外一种资源状态都需要一定的条件，例如从 Planned状态跳转到Approved状态需要查看订单资源中金额属性是否大于一个阀指，如果大于则跳转到Approved状态，如果小于则跳转回Validated状态，重新进行修改。该状态机与图右方发票资源的状态机产生联动效果，例如当发票资源状态为Declined时，订单资源状态立即被修改为Failed，状态机的联动使得资源状态转移有了更为合理和细致的约束。上述过程实际上是完成了一个业务流程的运转。该运转是通过资源池与资源状态集的交互实现的。

这一系列的针对资源的状态转移，正是 REST的设计哲学和核心所在，也是REST与SOAP最大的区别，与SOAP的面向操作不同，REST是面向资源的设计框架，它利用资源的状态以及WEB这一虚拟状态机完成业务流程的实现。

2.2 资源关系建模

定义 5：资源关系(Resource Relations)定义：RRi =(RelationType, Resources)

资源关系 RR用于为资源间建立联系。在关系型数据库中，关系是通过外键建立的。关系数据库中表之间的关系主要有3种：一对一，一对多，多对多。在资源池的实体资源这一层，抽象了这3种关系，隐藏了这3种关系的细节。

在资源池中，用户只需要考虑资源，而无需考虑资源所涉及的数据表。针对关系数据库中的这3种关系，资源池将其抽象为一种关系RelationType = ‘Has’。例如：数据库中有3张表School, Student, Course。School与Student是一对多的关系，Student与Course是多对多的关系。如果让用户自己编码实现，耗时费力，且不好理解。资源池能够替用户完成这些工作（比如创建表，创建外键，创建中间表）。用户无需考虑学生表与课程表具有什么关系，在资源这一层中，用户只需知道学生资源拥有很多课程资源，课程资源也拥有很多学生资源。这样的关系处理是符合人类语义的，更容易被理解。资源池将资源对应表的实现细节向用户隐藏了。当用户向资源池请求一个学校资源时，资源池会返回给用户一个大粒度的信息资源，其中包含了该学校的数据，该学校包含的学生资源，各个学生资源拥有的课程资源。这样的处理方式，尤其适合WEB前台应用，返回的数据格式已经包含了数据关系，前台就能根据数据所描述的关系，按层级展现前台页面。

资源池提供另外一种关系类型-继承关系，RelationType = ‘Inheritance’。这种资源关系用于当资源是另一个资源的扩展时。例如“学生详细信息”资源属于“学生信息”的扩展，此时前者是后者的继承资源。

2.3 业务流程资源元模型

业务流程资源属于资源池的最核心资源，资源池通过流程资源实现业务流程的执行，动态组合与拆分。

定义6：流程资源(Process Resource)定义：PRi = (URI,ResourceList, StatusTransferTable)

流程资源也有一个唯一的URI作为标识，启动或者更改一个流程就像访问常见的REST资源一样，它由多个业务实体资源联合而成，StatusTransferTable中存储了各个资源状态转换的顺序以及规则。抽象实现，如图3所示：

图3 业务流程资源

Resource P是一个流程资源，它包含两个业务实体资源R，S。当向该业务流程资源发送Get请求时，实际上执行了一个业务流程：首先调用资源R的PUT操作，当结果返回后再执行资源S的GET操作。这样的表示方法将业务流程资源与业务实体资源联系起来，形成了完整的顺序流程。

上述实现例子只是业务流程资源的抽象实现，实际应用中还会涉及每个资源状态的迁移等细节，将在下一章节具体展开。

2.4 资源管理数据

定义7：资源管理数据(Resource Management Data)

定义：RMDi = (Resource, CreateTime, LastOperateTime,AcessCount, RespondTime, LockType)

资源管理数据主要用于对资源的运行状态进行记录以方便资源池进行动态的管理。每条资源管理数据对应于一个资源，包括了资源的创建时间、上次操作的时间、访问量、平均响应时间和资源锁的类型。

资源池运用一些算法来实现对资源访问的优化和管理，例如当上次操作时间-资源创建时间大于一个阀值后，表明该资源处于长期闲置状态，资源池将会把该资源回收。当某资源访问量过大，且响应时间过长时，资源池将会复制一个该资源，将请求分发到复制的该资源，以减轻原资源的访问压力。这样的设计将有助于资源池的分布式部署实施，更适应云计算的大并发量要求。

3 资源池核心实现

资源池整个架构参照RESTful的理念进行设计，以资源为中心，对资源进行统一的动态配置与管理。具体实现架构，如图4所示：

图4 资源池实现架构

当用户的HTTP请求发送到资源池，将经过资源池多个模块的分析与处理，最终生成HTTP响应发还给用户。

资源池中资源的控制，访问，管理和业务流程资源的运转主要是通过“资源访问模块”与“资源管理模块”的交互实现的。资源访问模块主要包含两个模块：资源查找模块和资源操作模块。在进行资源查找时资源查找模块会从资源关系库中找出该资源所属关系，如果该资源是个大粒度的资源，即包含了多个资源以及资源间的关系，该模块将会从下一层的数据库访问模块中得到多个资源的数据并进行整合。

资源管理模块是资源池实现架构中的核心，主要包含4个模块：资源关系库、资源状态表、访问请求队列和资源规则引擎。资源关系库存储了资源间的关系，资源状态表存储了每个资源所拥有的状态，以及状态之间的迁移规则。访问请求队列主要用于进行访问控制，当某个资源访问量过大时，请求会被放入该队列等待执行。资源规则引擎模块包含了每个业务流程资源执行的顺序，资源间进行状态转换的规则，资源池通过该模块实现业务流程的执行与控制。

3.1 资源池静态映射模块的实现

在资源池中，每一个业务实体资源都会与数据库中的一张主表对应，资源”SchoolWithRelations”与表”School”对应，如图5所示：

图5 业务实体资源

属性”isCompound”为真表明该资源是一个复合资源包含了与其他资源的关系。每一个属性”property”都与表中的一列相对应。标签”relations”说明该资源与另一个名为”StudentWithRelations”的资源存在叫做”has”的关系，语义上说明该学校资源拥有很多学生资源。

具体的资源搜索与发现算法如下，该算法是一个递归算法。

3.2 资源池动态管理模块的实现

动态管理模块主要分为两部分：资源运行时管理和业务流程资源控制。

对于资源运行时管理的实现，本文定义了六种资源运行状态：created, runnable, waited, deleted, aggregated, separated.前4种是最基本的资源生命周期状态分别对应：创建，运行，等待，删除。后两种状态用于资源池动态的进行实体资源粒度控制。资源池通过与日志记录模块的交互，会定期检查哪些资源会经常被一同调用，并分析这些资源间的关系，如果发现资源间存在包含关系，便会将资源状态转变为aggregated，动态管理模块发现为 aggregated状态的多个资源，便会将它们按照关系组装起来，形成一个更大粒度的资源。同理 separated状态是用于分解大粒度的资源。通过这样的方式，资源池实现了动态的，智能的资源粒度控制。

对于业务流程资源控制，资源池通过资源状态迁移以及规则引擎的协同来实现。具体的业务流程资源描述模板，如图6所示：

图6 业务流程资源模板

该模板描述了对流程资源的每一个操作（Get, Put,Delete, Post）都会涉及到哪些其他的实体资源，执行实体资源的哪些操作和执行顺序。

业务规则库中存储的是对每个业务流程资源的状态转换的规则。例如：

当用户向流程资源”BookingOrder”发送一个GET请求时，资源管理模块首先查看该流程资源的描述文件，读取出onGet中的执行步骤，然后依次执行。执行一步之后，会根据资源返回的状态从业务规则库中判断下一步可选的步骤。资源的返回信息，如图7所示：

图7 资源返回信息

返回的信息显示，该资源的目前状态为”created”，业务规则库中返回的可选步骤如下：”Validate Order”代表检查该订单，”Cancel Order”代表取消订单，”Reject Order”代表拒绝订单。每一个可选步骤都跟随一个代表该步骤的 URI链接，用户通过访问不同的 URI来实现流程的执行以及资源状态的切换。

上述基于资源状态迁移的流程转换正是 REST的核心设计理念，不同于重量级的工作流引擎，资源池通过资源状态表与轻量级的业务规则引擎的结合实现了业务流程的运行，由于它不像工作流引擎需要维护大量的状态信息和流程实例，因此资源池能承受的访问并发量比工作流引擎多。基于资源的 RESTful的设计理念也更适应于分布式的部署和云计算环境[10]。

4 实现验证

本章节将通过某货运公司信息系统的实例来说明资源池如何使用以及如何作为中间件为上层系统服务。

以下是该货运公司的基本情况：

该公司之前的业务流程是通过Web Service + 工作流引擎硬编码实现的，但由于货运行业的特殊性，该公司业务流程经常变动，一经变动，就需要重新修改源代码。

该公司已经通过多视图建模的方法，为企业的流程和信息资源建立了模型文件。

该公司需要经常添加新流程以适应业务需求。

为了便于集成，应用系统对其他模块部件的访问都是通过Web Service的方式。

基于上述情况，该公司现在需要一个轻量级的，易于使用部署的中间件平台，能够连接底层数据库与上层应用系统，并提供流程支持。该中间件平台能够支持动态的流程变动，减少IT人员二次编码的工作量。

该平台需要能够承受大并发量的访问，能够进行动态的流程和数据监控与管理。

步骤一：将多视图建模的模型文件导入资源池

资源池的输入是一些业界标准的业务建模模型，这其中多视图建模模型最适合于转化为面向资源的RESTful架构，因为多视图建模包含的建模对象最为全面，包括领域实体模型，基于状态的信息资源模型和业务流程模型。流程分析与转换器将会解析这些模型。资源池根据领域实体模型及实体关系生成数据库表及外键关联。解析信息资源模型和业务流程模型，解析后的输出是针对每个实体资源的资源状态表，每个业务流程模型都会生成一个对应的业务流程资源，其中包含了业务流程执行顺序及业务规则语句。

经过步骤一后，资源池中已经存在了多种业务实体资源和业务流程资源，并且这些资源都能够通过REST的方式进行访问。资源池现在已经可以为上层应用提供服务。

步骤二：上层应用系统与资源池的交互

以实际托运货物业务流程为例,该流程主要包含以下步骤：用户填写托运货物信息->货运公司审核订单->司机填写运送单->收件人填写收货单。流程图，上层系统应用界面和执行顺序，如图8所示：

图8 资源池与上层系统交互

上层系统首先发送一个HTTP Get请求到该业务流程资源的 URI: http://localhost:8080/cargocompany/carryprocess。当资源池收到这个GET请求后，查看该业务流程资源的规则描述，返回一个新的货物资源给系统。上层系统便得知第一步是要填写货物信息并将填写后的货物信息 Post回给资源池，此时第一步完成，货物资源的状态修改为 created。资源池收到请求，再次查看状态迁移规则描述，下一步指向订单资源。第二步返回订单资源给系统，由货运公司来更改订单的状态，这时规则引擎产生作用，它有如下语句：if(order.permitted == true)goto validated; else goto canceled;这条语句的作用是检查订单的审核属性是否为真，如果为真，订单审核批准，如果为假，订单取消，流程结束。

从上述步骤可以看出，资源池与上层应用系统的交互都是通过REST的方式，上层应用系统并不知道自己正在使用一个流程，应用系统所要做的只是通过 URI访问资源，根据资源的HTTP响应，继续通过下一个URI访问另外的资源。这一系列资源访问的过程实际就是一个业务流程。

步骤三：资源配置与监控管理

资源池中的业务实体资源和业务流程资源可以在运行时动态的修改。用户可以动态的配置资源间的关系。由于资源池业务流程的执行是通过资源的状态迁移完成的，因此对于流程更改，流程拆分和合并，只需要修改相应流程资源的状态表和规则描述，即可完成运行时的动态改变。资源池资源监控和管理界面如图9所示：

图9 资源管理

本章最后给出了资源池与传统中间件解决方案的整体比较，如表1所示：

表1 中间件解决方案比较

5 结论

本文提出了一种自动化的基于资源的柔性业务流程解决方案，该方案不同于普通工作流引擎的重量级实现，采用了资源状态迁移与规则引擎协作的轻量级方法实现业务流程的执行与管理。首先从面向资源及资源状态的视角对业务流程及其相关实体进行了建模。其次基于该模型提出了资源池的整体实现架构，并详细阐述了涉及到的核心算法与设计思路。最后使用了一个实际案例来验证资源池的可行性，并将资源池与普通的中间件解决方案做了详细对比。结果表明资源池通过自动化实现的方式提升了效率，资源池提供的柔性业务流程运行和管理环境能够满足企业流程频繁改变的需求。

[1]Jian Cao, Haiyan Zhao, Minglu Li. A Fuzzy Rule Based Load Balancing Model for a Distributed Service Process Engine. [C]Grid and Pervasive Computing Workshops,2008.

[2]Gottschalk, K. Graham, S. Kreger, H. and Snell. J. Introduction to Web services architecture. [J]IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002.

[3]Martin Gudgin, Marc Hadley, Noah Mendelsohn,Jean-Jacques Moreau. Simple Object Access protocal 1.2.[G]W3C Recommendation. 27 April 2007.

[4]Overdick, H.Hasso Plattner Inst for IT Syst. Eng., Potsdam. The Resource-Oriented Architecture. Services, [J]2007 IEEE Congress. 9-13 July 2007.

[5]Roy T. Fielding. Architectural styles and the design of network-based software architectures. PhD thesis, [M]Dept. of Information and Computer Science, Universityof California, Irvine, 2000.

[6]Kumaran, S. Rong Liu; Dhoolia, P.; Heath, T.; Nandi, P.;Pinel, F. A RESTful Architecture for Service-Oriented Business Process Execution. [J]E-Business Engineering,2008. ICEBE ’08.

[7]Cesare Pautasso. RESTful Web service composition with BPEL for REST. [M]Data&Knowledge Engineering,Sep. 2009.

[8]Weske. M Business Process Management Architectures.[M]Business Process Management Springer, 2012.

[9]Hongming Cai, Dominik Englert, HaoYu. ORIPS: An Open Resource-based Integrated Platform System for business process execution. [J]IEEE International Conference on Systems, Man, and Cybernetics, 2009.

[10]Al-Zoubi, K; Wainer, G. Performing distributed simulation with RESTful Web-services. Simulation Conference,[C]Proceedings of the 2009 Winter.