云环境下以Artifact为中心的业务过程管理

方泽杭，蔡鸿明

(上海交通大学 软件学院，上海 200240)

云环境下以Artifact为中心的业务过程管理

方泽杭，蔡鸿明

(上海交通大学 软件学院，上海 200240)

针对云环境下BPM(业务过程管理)存在的数据管理问题，提出了一种以Artifact为中心的云环境业务过程管理方法.首先研究了Artifact业务过程模型，具体介绍了Artifact定义、活动定义和业务规则定义；然后针对该模型提出了云环境下的执行系统，研究了该系统的运行和监控机制；最后以一个购物流程为实例，验证了以Artifact为中心的BPM的可用性和灵活性，结果证明该方法能够有效地管理流程控制数据，满足云环境下BPM的需求.

业务过程管理；云计算；数据管理；Artifact；业务规则

业务过程管理[1](business process management, BPM)是传统工作流管理[2]的扩展，其为企业各种业务过程提供统一的建模、执行和监控环境.云计算的出现，降低了企业的成本，提高了企业应用的灵活性[3]，采用软件即服务模式能够大幅降低企业信息系统的开发、运行和维护的投入，所以越来越多的企业选择将自己的业务向云中迁移.一个业务流程执行过程会涉及到各种数据，它们生成并存在于流程的不同阶段，这些数据存储形式也不相同.随着数据和流程的增加，维护和管理也越来越困难.在多租户的BPM下，这个问题会更加明显，管理这些不同用户的数据，不仅降低了业务过程的效率和灵活性，而且会提高服务提供商的开发和维护成本.

上述问题的关键在于基于传统的工作流模型的流程引擎需要管理流程中的控制数据[4].其中流程控制数据是流程中涉及到的变量，决定了流程中的服务执行顺序，需要由流程引擎来维护.在传统的信息系统中，这种方式可以保证流程实例在因故停止后正常恢复.但是在云环境下，数据量变大时，会导致引擎庞大而且缺乏效率.另外在系统升级时，也会引入很多困难.

目前，已有不少针对云环境BPM数据管理的研究.文献[5]提出了一种基于BPEL(business process execution language)的多租户框架，该框架基于Apach ODE引擎进行修改，使其支持多租户的权限隔离，通过独立模块来保存和管理流程运行时涉及的上下文环境，实现BPEL流程引擎对多租户流程运行的支持.但是流程中涉及的管理数据还是由流程引擎维护，未能从根本上解决问题.文献[6]提出了一种流程分解的方法，根据流程涉及的数据敏感性不同，将流程分解成云端和客户端，两端分别管理各自需要的数据.该方法虽然将流程中涉及的部分控制数据交由用户端来管理，但是在应用时会比较复杂，存在灵活性比较差的问题. 文献[7]引入了Artifact业务建模方法，阐述了该方法的应用和特点，为业务流程中数据的建模和管理提供了参考和方法. 文献[8]提出了一个Artifact业务建模的框架，该框架涵盖了Artifact业务模型建模到执行的一些关键内容.文献[9]提出了ArtiFlow模型来描述Artifact业务过程模型，分析了Artifact业务建模过程涉及的关键要素.文献[10]介绍了一种新的Artifact生命周期描述方法，并分析了该方法在建模复杂流程时的优势.目前这些研究都未涉及云环境的内容，而且对于Artifact业务模型建模方法的描述也只是停留在概念层面.Artifact业务模型的执行还需要转换为BPEL模型，缺少流程监控的方法.

本文针对云环境下业务流程存在的数据管理问题，基于Artifact业务过程模型，提出了一种以Artifact为中心的云环境业务过程管理方法，对Artifact业务过程模型进行介绍，并研究了基于该方法建模的流程在云环境下的执行与监控机制.

1　Artifact业务过程管理方法

本文提出的以Artifact为中心的云环境业务过程管理方法主要涵盖BPM的建模、执行与监控3个阶段，基于该方法的框架由Artifact流程模型和云环境执行系统2部分组成,如图1所示.

图1　Artifact业务过程管理框架Fig.1　Framework for Artifact business process management

Artifact业务过程模型由Artifact定义、活动定义和业务规则定义3部分组成，是Artifact业务过程管理的建模阶段，为运行阶段提供流程定义.

云环境执行系统由流程管理层和执行层组成，为云环境下的Artifact流程定义的部署与运行提供支持.流程管理层为每个用户提供独立的模型管理、实例管理和流程监控功能，并管理流程运行时的上下文信息.其中，模型管理负责Artifact流程定义的管理，包括流程模型的存储和读取；实例管理负责流程实例运行时Artifact实例的管理；流程监控提供流程实例运行时的监控功能.流程执行层由流程引擎构成，负责执行来自不同用户的流程实例.

2　Artifact流程定义

Artifact流程模型是一种结合数据视角来描述业务过程的方法，流程定义由Artifact、活动和业务规则3部分组成，本节将通过一个实例来介绍Artifact流程各部分的内容和作用.

该实例为一个订单制造流程.买家提交制造订单(order)给厂家，厂家收到订单后，分析订单中需要订购的零部件(line item)，然后向不同的供应商发送采购订单(procurement).供应商在接到采购订单后，可以拒绝采购请求，也可以接收并且运送相应的零部件以供厂家生产.厂家在接收到拒绝后，将会更换供应商.在所有的零部件采购完成后，厂商开始生产产品并且交付买家，交付完成后则Artifact流程结束.

2.1Artifact定义

Artifact是流程运行过程中涉及的关键业务实体，例如上述订单制造中涉及的订单、零部件和采购单都属于该流程中的Artifact.

图2描述了上述流程中涉及的3个Artifact的信息模型和生命周期模型，3个Artifact分别是制造订单(order)、订单所需零部件(line item)和采购订单(procurement).左侧圆角矩形描述的是Artifact的信息模型，右侧通过状态机的方式描述了该Artifact的生命周期模型，其中黑线圆圈是初始状态，粗线矩形是结束状态.

图2　订单制造流程中的ArtifactsFig.2　Artifacts in order-manufacture process

2.2活动定义

例如图2订单制造流程中的分析订单(analysis order)活动中，order作为服务的输入，返回需要采购的零件和对应数目，根据相应的返回结果创建多个line item Artifact实例，并将对应的order由created状态转换为wait for items状态.

2.3业务规则定义

业务规则负责将Artifact和活动关联起来，业务规则模型采用ECA(event-condition-action，事件-条件-活动)的方式描述.其中事件可以由Artifact属性或者状态的变化触发，也可以由业务活动操作触发，还可以由外来的消息触发，该消息可以是一个请求；在接收到事件后，需要首先验证是否满足后续条件，该条件一般是判断相应的Artifact属性或者状态是否符合要求；如果条件的执行结果为真，那么将触发后续的活动.

例如采购单中的零件由供应商运输完成后，该采购单的状态将由接收(received)转换为已运输(shipped)状态，该转换会产生一个采购单已运输的事件.由于该事件是由业务规则T6处理，该业务规则将会检查对应的采购单状态是否真的到达了已运输状态，并且对应的零件是还未准备(not ready)的状态.如果这些条件都成立，该业务规则就会执行后续的活动，该活动并不需要调用其他活动，而仅仅把订单中对应的零件状态改为已经准备就绪(ready)状态.订单状态由未就绪转换为就绪将会产生一个订单就绪的事件，该事件将会被后续的业务规则处理，从而驱动整个流程的运行.

每个流程都会包含多个业务规则，表1给出部分业务规则和相应活动的描述.例如业务规则T2由事件order created触发，然后验证该order状态是否为created，如果满足将会执行后续活动.活动以order Artifact实例作为参数调用服务的analysisOrder()方法，获取返回结果aoResponse.根据返回结果内容内容创建多个line item实例，并将order状态转变成wait for item.

表1　部分业务规则和活动描述Table 1　The description for part of business rules and activities

3　Artifact业务流程执行与监控

根据前文Artifact流程定义可知，整个流程的建模围绕Artifact定义而展开.其中业务规则由Artifact状态改变触发，业务活动使用Artifact作为参数.本节将从Artifact实例的管理出发，给出云环境下Artifact流程的执行与监控方法.

3.1流程管理机制

3.1.1流程管理

流程管理为用户提供模型管理和实例管理的功能，其中，模型管理为不同用户提供静态流程定义的存储与读取服务，可以采用常规的云环境多租户隔离方案解决.

用户在定义完自己的Artifact流程后，模型管理负责保存用户的流程定义文件.在部署运行该流程时，会从模型管理处读取该流程定义，模型管理将解析该流程定义并创建流程运行时实例，并将该运行时实例交由实例管理来管理.

3.1.2实例管理

实例管理负责管理该租户运行时的流程实例，并且为流程引擎提供流程实例加载功能.

流程实例是流程监控和运行的关键，它保存了Artifact业务流程执行时的上下文信息.流程实例由Artifact实例、活动实例和业务规则实例3部分组成，各个实例所包含的内容和实例之间的关系如图3所示.

图3　运行时实例间关系Fig.3　Class relationship of run time instance

流程实例：系统将会先创建一个流程实例，并为其设定一个唯一标识ID，并且调用实例管理将此ID存储到租户的流程实例库中，然后去加载对应的Artifact定义、活动定义和业务规则定义.此ID可以用于跟踪和监控流程执行的过程，为执行中的产生事件匹配正确的流程实例.流程实例是该流程运行时涉及的其他实例的容器，流程实例维护着事件与业务规则的映射关系，保存着流程执行时上下文需要的所有信息和流程中的业务规则.

Artifact实例：根据流程定义中的Artifact定义来创建，该定义是一个xml文件，描述了Artifact实例创建所需的所有信息.Artifact实例可以在流程启动执行后创建，也可以由活动来创建，新创建的Artifact实例将会被赋予一个唯一的标识符，所有的Artifact实例共同描述着该流程实例执行的状态.

活动实例：在流程实例创建后，系统会根据其所包含的活动定义信息创建活动实例.每个活动定义对应着一个活动实例，活动实例中存储了活动涉及的服务调用信息，以及该服务调用结束后对Artifact的操作，操作通过脚本的方式来描述.

业务规则实例为根据业务规则定义，在流程实例创建后创建，该实例中存储了业务流程模型中的业务规则和该规则的触发事件，在接收到相应事件后开始执行对应规则，在规则执行结果为真时触发执行后续的活动.

3.2流程执行机制

3.2.1流程引擎架构

流程引擎负责执行不同租户的流程实例,调用流程中涉及的活动,本文基于事件驱动和面向服务的架构，给出了执行Artifact流程模型的流程引擎架构，如图4所示.

图4　Artifact流程引擎架构Fig.4　Architecture for Artifact process engine

流程控制器：负责流程实例运行过程的调度，是流程引擎的核心.流程控制器会接收来自Artifact管理器、活动管理器、流程实例管理器和业务规则引擎的事件，并且根据事件内容，通知对应模块执行.流程控制器可以调用业务规则引擎执行业务规则实例，或者通知Artifact管理器更新Artifact实例.

业务规则引擎：负责执行流程实例中的业务规则实例.当流程控制器接收到事件时，将会根据事件信息，找到相关的流程实例，然后加载对应的业务规则实例放入到规则引擎中执行，业务规则引擎将会把执行的结果返回给流程控制器，流程控制器将会根据它来更新Artifact或者调用活动.

流程实例管理器：管理流程引擎中运行的所有流程实例的副本，可以根据流程控制器的请求从租户的实例管理中加载对应的流程实例.

活动管理器：负责执行流程实例中的活动实例，调用活动实例中的web服务，根据活动对Artifact实例的操作通知Artifact管理器修改对应Artifact实例.

Artifact管理器：负责处理流程实例运行时对Artifact实例的修改，任何对流程实例的Artifact实例的修改请求都由Artifact管理器来处理，Artifact管理器将会根据处理的结果产生相应的Artifact实例状态改变事件.

3.2.2流程执行过程

流程实例的执行过程是流程实例在Artifact流程引擎的协调下完成的，其中活动实例的执行顺序由流程控制器和业务规则引擎共同协作完成，活动实例的执行操作由活动管理器来完成.

流程启动后，流程实例管理器将会从实例管理中加载并注册对应的流程实例，并产生create order事件，事件中包含了对应流程实例的ID，流程控制器根据该ID匹配到对应的流程实例，然后根据消息名称获取对应的业务规则实例.然后流程控制器会以该流程实例作为上下文环境，将该业务规则实例交给业务规则引擎执行.业务规则引擎把执行的结果以消息的形式传递给流程控制器，流程控制器根据执行的结果来调用活动控制器执行对应的活动实例.活动控制器在接收到事件后，会执行该活动实例，并且根据返回结果通知Artifact管理器执行后续的更新操作，Artifact管理器将会更新Artifact实例内容，并根据Artifact实例状态变化产生对应的状态改变事件.

3.2.3流程监控机制

根据前文流程执行过程的介绍，可以发现流程实例运行的状态可以由其包含的Artifact实例状态来确定.通过监控该流程涉及的所有Artifact实例状态，可以实现对该流程运行过程的监控.

表2所示流程监控表是流程实例运行状态和对应的Artifact实例状态的映射关系.例如，order处于wait for items，则流程实例处于还在采购零部件的过程中.对于某个处于initial状态的line item Artifact实例，若其关联的procurement实例是rejected，那么意味着之前该line item的采购请求被拒绝，新的采购请求在进行中；如果line item是not ready状态，而关联的procurement处于received状态，那么意味着该零部件已经采购到，还在运输的过程中.

表2　流程监控表Table 2　Table for process monitoring

4　系统开发及实例验证

4.1系统开发

在前文研究的基础上，这里开发了一个基于Artifact业务过程管理技术的系统.该系统采用Java开发，后台使用restlet框架，前台利用Dagre D3的d3.js库，业务规则解析采用Drools规则引擎，测试用的web服务采用了axis 2框架开发，目前已经完成了系统的执行和实例监控功能.

一个网上购物运输流程在BPM下的建模描述如图5所示.

图5流程中存在订单(order)、运单(shipment)和发票(invoice)这3个Artifact. 根据研究内容给出了该流程基于Artifact的流程定义，然后将该xml定义文件部署到系统中运行，图6给出了该系统运行过程中的监控结果.从该结果中可以看到每个Artifact实例包含的内容和所处状态，从而方便地对流程进行监控，上述结果显示目前该流程实例还处于订单审核中.

图5　网上购物运输流程Fig.5　Online ordering shipment process

图6　流程监控结果Fig.6　Process monitoring results

4.2结果讨论

文献[5]中Milinda方法基于常见的BPEL建模方法，通过对引擎的修改，实现不同租户流程实例的分离管理.表3给出了本文提出的方法与Milinda方法的对比.

表3　本文方法与Milinda的方法对比Table 3　This paper’s method compared with Milinda’s method

由表3对比可知，虽然本文提出的方法建模和系统实现难度比较高，但是引擎不需要维护运行时数据，相比较而言更加灵活且易于维护，在数据量增加时也不会影响引擎的效率，适合云环境的需求.

5　结　语

本文针对目前云环境下传统业务流程存在的问题，研究了基于Artifact业务过程模型的解决方法.在已有研究的基础上，首先分三部分给出了Artifact业务建模方法的主要定义；然后结合云环境提出了能够执行该模型业务流程的系统架构，研究了该系统下的执行与监控的机制；最后通过原型系统和实例验证了本文方法的可行性.从验证和对比的结果来看，本文提出的业务过程管理框架，能够很好地解决云环境下业务过程管理存在的数据管理问题，为云环境下的业务过程管理提供一种高效、灵活和易维护的解决方法.

[1] WESKE M. Business process management architectures[C]//Business Process Management. Heidelberg: Springer -Verlag, 2012: 333-371.

[2] HOLLINGSWORTH D, HAMPSHIRE U K. Workflow management coalition the workflow referencemodel[EB/OL].(1994-11-29)[2014-12-11].http://citeseerx.ist.psu.edu/viewdoc/download? doi=10.1.1.198.5206&rep=rep1&type=pdf.

[3] DUIPMANS E, PIRES L F. Business process management in the cloud: Business process as a service(BPaaS)[EB/OL].(2012-4-1)[2014-12-04].http://www.utwente.nl/ewi/trese/graduation_projects/2012/RT-001.pdf.

[4] SUN Y, SU J, YANG J. Separating execution and data management: A key to business-process-as-a-service (BPaaS)[C]//Business Process Management. Heidelberg: Springg-Verlag, 2014: 374-382.

[5] PATHIRAGE M, PERERA S, KUMARA I, et al. A multi-tenant architecture for business process executions[C]//Web Services (ICWS), 2011 IEEE International Conference on. 2011: 121-128.

[6] HAN Y. A cloud-based BPM architecture with user-end distribution of non-compute-intensive activities and sensitive data[J]. Journal of Computer Science and Technology, 2010, 25(6): 1157-1167.

[7] LIU R, BHATTACHARYA K, WU F Y. Modeling business contexture and behavior using business artifacts[C]//Advanced Information Systems Engineering. Heidelberg: Springer-Verlag, 2007: 324-339.

[8] BHATTACHARYA K, HULL R, SU J. A data-centric design methodology for business processes[M].Hershey:Information Science Reference, 2009: 503-531.

[9] LIU G, LIU X, QIN H. Automated realization of business workflow specification[C]//Service-Oriented Computing. ICSOC/ServiceWave 2009 Workshops. Heidelberg: Springer-Verlag, 2010: 96-108.

[10] HULL R, DAMAGGIO E, FOURNIER F, et al. Introducing the guard-stage-milestone approach for specifying business entity lifecycles[C]//Web Services and Formal Methods. Heidelberg: Springer-Verlag, 2011: 1-24.

Artifact-Centric Business Process Management in the Cloud

FANGZe-hang,CAIHong-ming

(School of Software, Shanghai Jiaotong University, Shanghai 200240, China)

In order to solve the data management problem for BPM (business process management) in the cloud, an Artifact-centric business process management approach in the cloud is proposed. Firstly, the Artifact business process modeling method is studied. And the definition of Artifact, activity and business rule are discussed. Secondly, a cloud business process management system is proposed for that model. And the execution and monitoring mechanism are studied. Finally, an online shopping process is used to verify the usability and flexibility of this approach. The result shows that this approach can manage process control data effectively, and meet the requirement of business process management in the cloud.

business process management; cloud computing; data management; Artifact; business rule

1671-0444(2015)04-0478-07

2014-12-26

国家自然科学基金资助项目(61373030)；国家高技术发展计划资助项目(2008AA04Z126)

方泽杭(1990—)，男，湖北黄冈人，硕士研究生，研究方向为工作流管理. E-mail: rinascere@sjtu.edu.cn

蔡鸿明(联系人),男，副教授, E-mail: hmcai@sjtu.edu.cn

TP 319

A