云環(huán)境下以Artifact為中心的業(yè)務(wù)過程管理

方澤杭，蔡鴻明

(上海交通大學(xué) 軟件學(xué)院，上海 200240)

云環(huán)境下以Artifact為中心的業(yè)務(wù)過程管理

方澤杭，蔡鴻明

(上海交通大學(xué) 軟件學(xué)院，上海 200240)

針對云環(huán)境下BPM(業(yè)務(wù)過程管理)存在的數(shù)據(jù)管理問題，提出了一種以Artifact為中心的云環(huán)境業(yè)務(wù)過程管理方法.首先研究了Artifact業(yè)務(wù)過程模型，具體介紹了Artifact定義、活動定義和業(yè)務(wù)規(guī)則定義；然后針對該模型提出了云環(huán)境下的執(zhí)行系統(tǒng)，研究了該系統(tǒng)的運行和監(jiān)控機(jī)制；最后以一個購物流程為實例，驗證了以Artifact為中心的BPM的可用性和靈活性，結(jié)果證明該方法能夠有效地管理流程控制數(shù)據(jù)，滿足云環(huán)境下BPM的需求.

業(yè)務(wù)過程管理；云計算；數(shù)據(jù)管理；Artifact；業(yè)務(wù)規(guī)則

業(yè)務(wù)過程管理[1](business process management, BPM)是傳統(tǒng)工作流管理[2]的擴(kuò)展，其為企業(yè)各種業(yè)務(wù)過程提供統(tǒng)一的建模、執(zhí)行和監(jiān)控環(huán)境.云計算的出現(xiàn)，降低了企業(yè)的成本，提高了企業(yè)應(yīng)用的靈活性[3]，采用軟件即服務(wù)模式能夠大幅降低企業(yè)信息系統(tǒng)的開發(fā)、運行和維護(hù)的投入，所以越來越多的企業(yè)選擇將自己的業(yè)務(wù)向云中遷移.一個業(yè)務(wù)流程執(zhí)行過程會涉及到各種數(shù)據(jù)，它們生成并存在于流程的不同階段，這些數(shù)據(jù)存儲形式也不相同.隨著數(shù)據(jù)和流程的增加，維護(hù)和管理也越來越困難.在多租戶的BPM下，這個問題會更加明顯，管理這些不同用戶的數(shù)據(jù)，不僅降低了業(yè)務(wù)過程的效率和靈活性，而且會提高服務(wù)提供商的開發(fā)和維護(hù)成本.

上述問題的關(guān)鍵在于基于傳統(tǒng)的工作流模型的流程引擎需要管理流程中的控制數(shù)據(jù)[4].其中流程控制數(shù)據(jù)是流程中涉及到的變量，決定了流程中的服務(wù)執(zhí)行順序，需要由流程引擎來維護(hù).在傳統(tǒng)的信息系統(tǒng)中，這種方式可以保證流程實例在因故停止后正常恢復(fù).但是在云環(huán)境下，數(shù)據(jù)量變大時，會導(dǎo)致引擎龐大而且缺乏效率.另外在系統(tǒng)升級時，也會引入很多困難.

目前，已有不少針對云環(huán)境BPM數(shù)據(jù)管理的研究.文獻(xiàn)[5]提出了一種基于BPEL(business process execution language)的多租戶框架，該框架基于Apach ODE引擎進(jìn)行修改，使其支持多租戶的權(quán)限隔離，通過獨立模塊來保存和管理流程運行時涉及的上下文環(huán)境，實現(xiàn)BPEL流程引擎對多租戶流程運行的支持.但是流程中涉及的管理數(shù)據(jù)還是由流程引擎維護(hù)，未能從根本上解決問題.文獻(xiàn)[6]提出了一種流程分解的方法，根據(jù)流程涉及的數(shù)據(jù)敏感性不同，將流程分解成云端和客戶端，兩端分別管理各自需要的數(shù)據(jù).該方法雖然將流程中涉及的部分控制數(shù)據(jù)交由用戶端來管理，但是在應(yīng)用時會比較復(fù)雜，存在靈活性比較差的問題. 文獻(xiàn)[7]引入了Artifact業(yè)務(wù)建模方法，闡述了該方法的應(yīng)用和特點，為業(yè)務(wù)流程中數(shù)據(jù)的建模和管理提供了參考和方法. 文獻(xiàn)[8]提出了一個Artifact業(yè)務(wù)建模的框架，該框架涵蓋了Artifact業(yè)務(wù)模型建模到執(zhí)行的一些關(guān)鍵內(nèi)容.文獻(xiàn)[9]提出了ArtiFlow模型來描述Artifact業(yè)務(wù)過程模型，分析了Artifact業(yè)務(wù)建模過程涉及的關(guān)鍵要素.文獻(xiàn)[10]介紹了一種新的Artifact生命周期描述方法，并分析了該方法在建模復(fù)雜流程時的優(yōu)勢.目前這些研究都未涉及云環(huán)境的內(nèi)容，而且對于Artifact業(yè)務(wù)模型建模方法的描述也只是停留在概念層面.Artifact業(yè)務(wù)模型的執(zhí)行還需要轉(zhuǎn)換為BPEL模型，缺少流程監(jiān)控的方法.

本文針對云環(huán)境下業(yè)務(wù)流程存在的數(shù)據(jù)管理問題，基于Artifact業(yè)務(wù)過程模型，提出了一種以Artifact為中心的云環(huán)境業(yè)務(wù)過程管理方法，對Artifact業(yè)務(wù)過程模型進(jìn)行介紹，并研究了基于該方法建模的流程在云環(huán)境下的執(zhí)行與監(jiān)控機(jī)制.

1　Artifact業(yè)務(wù)過程管理方法

本文提出的以Artifact為中心的云環(huán)境業(yè)務(wù)過程管理方法主要涵蓋BPM的建模、執(zhí)行與監(jiān)控3個階段，基于該方法的框架由Artifact流程模型和云環(huán)境執(zhí)行系統(tǒng)2部分組成,如圖1所示.

圖1　Artifact業(yè)務(wù)過程管理框架Fig.1　Framework for Artifact business process management

Artifact業(yè)務(wù)過程模型由Artifact定義、活動定義和業(yè)務(wù)規(guī)則定義3部分組成，是Artifact業(yè)務(wù)過程管理的建模階段，為運行階段提供流程定義.

云環(huán)境執(zhí)行系統(tǒng)由流程管理層和執(zhí)行層組成，為云環(huán)境下的Artifact流程定義的部署與運行提供支持.流程管理層為每個用戶提供獨立的模型管理、實例管理和流程監(jiān)控功能，并管理流程運行時的上下文信息.其中，模型管理負(fù)責(zé)Artifact流程定義的管理，包括流程模型的存儲和讀取；實例管理負(fù)責(zé)流程實例運行時Artifact實例的管理；流程監(jiān)控提供流程實例運行時的監(jiān)控功能.流程執(zhí)行層由流程引擎構(gòu)成，負(fù)責(zé)執(zhí)行來自不同用戶的流程實例.

2　Artifact流程定義

Artifact流程模型是一種結(jié)合數(shù)據(jù)視角來描述業(yè)務(wù)過程的方法，流程定義由Artifact、活動和業(yè)務(wù)規(guī)則3部分組成，本節(jié)將通過一個實例來介紹Artifact流程各部分的內(nèi)容和作用.

該實例為一個訂單制造流程.買家提交制造訂單(order)給廠家，廠家收到訂單后，分析訂單中需要訂購的零部件(line item)，然后向不同的供應(yīng)商發(fā)送采購訂單(procurement).供應(yīng)商在接到采購訂單后，可以拒絕采購請求，也可以接收并且運送相應(yīng)的零部件以供廠家生產(chǎn).廠家在接收到拒絕后，將會更換供應(yīng)商.在所有的零部件采購?fù)瓿珊螅瑥S商開始生產(chǎn)產(chǎn)品并且交付買家，交付完成后則Artifact流程結(jié)束.

2.1Artifact定義

Artifact是流程運行過程中涉及的關(guān)鍵業(yè)務(wù)實體，例如上述訂單制造中涉及的訂單、零部件和采購單都屬于該流程中的Artifact.

圖2描述了上述流程中涉及的3個Artifact的信息模型和生命周期模型，3個Artifact分別是制造訂單(order)、訂單所需零部件(line item)和采購訂單(procurement).左側(cè)圓角矩形描述的是Artifact的信息模型，右側(cè)通過狀態(tài)機(jī)的方式描述了該Artifact的生命周期模型，其中黑線圓圈是初始狀態(tài)，粗線矩形是結(jié)束狀態(tài).

圖2　訂單制造流程中的ArtifactsFig.2　Artifacts in order-manufacture process

2.2活動定義

例如圖2訂單制造流程中的分析訂單(analysis order)活動中，order作為服務(wù)的輸入，返回需要采購的零件和對應(yīng)數(shù)目，根據(jù)相應(yīng)的返回結(jié)果創(chuàng)建多個line item Artifact實例，并將對應(yīng)的order由created狀態(tài)轉(zhuǎn)換為wait for items狀態(tài).

2.3業(yè)務(wù)規(guī)則定義

業(yè)務(wù)規(guī)則負(fù)責(zé)將Artifact和活動關(guān)聯(lián)起來，業(yè)務(wù)規(guī)則模型采用ECA(event-condition-action，事件-條件-活動)的方式描述.其中事件可以由Artifact屬性或者狀態(tài)的變化觸發(fā)，也可以由業(yè)務(wù)活動操作觸發(fā)，還可以由外來的消息觸發(fā)，該消息可以是一個請求；在接收到事件后，需要首先驗證是否滿足后續(xù)條件，該條件一般是判斷相應(yīng)的Artifact屬性或者狀態(tài)是否符合要求；如果條件的執(zhí)行結(jié)果為真，那么將觸發(fā)后續(xù)的活動.

例如采購單中的零件由供應(yīng)商運輸完成后，該采購單的狀態(tài)將由接收(received)轉(zhuǎn)換為已運輸(shipped)狀態(tài)，該轉(zhuǎn)換會產(chǎn)生一個采購單已運輸?shù)氖录?由于該事件是由業(yè)務(wù)規(guī)則T6處理，該業(yè)務(wù)規(guī)則將會檢查對應(yīng)的采購單狀態(tài)是否真的到達(dá)了已運輸狀態(tài)，并且對應(yīng)的零件是還未準(zhǔn)備(not ready)的狀態(tài).如果這些條件都成立，該業(yè)務(wù)規(guī)則就會執(zhí)行后續(xù)的活動，該活動并不需要調(diào)用其他活動，而僅僅把訂單中對應(yīng)的零件狀態(tài)改為已經(jīng)準(zhǔn)備就緒(ready)狀態(tài).訂單狀態(tài)由未就緒轉(zhuǎn)換為就緒將會產(chǎn)生一個訂單就緒的事件，該事件將會被后續(xù)的業(yè)務(wù)規(guī)則處理，從而驅(qū)動整個流程的運行.

每個流程都會包含多個業(yè)務(wù)規(guī)則，表1給出部分業(yè)務(wù)規(guī)則和相應(yīng)活動的描述.例如業(yè)務(wù)規(guī)則T2由事件order created觸發(fā)，然后驗證該order狀態(tài)是否為created，如果滿足將會執(zhí)行后續(xù)活動.活動以order Artifact實例作為參數(shù)調(diào)用服務(wù)的analysisOrder()方法，獲取返回結(jié)果aoResponse.根據(jù)返回結(jié)果內(nèi)容內(nèi)容創(chuàng)建多個line item實例，并將order狀態(tài)轉(zhuǎn)變成wait for item.

表1　部分業(yè)務(wù)規(guī)則和活動描述Table 1　The description for part of business rules and activities

3　Artifact業(yè)務(wù)流程執(zhí)行與監(jiān)控

根據(jù)前文Artifact流程定義可知，整個流程的建模圍繞Artifact定義而展開.其中業(yè)務(wù)規(guī)則由Artifact狀態(tài)改變觸發(fā)，業(yè)務(wù)活動使用Artifact作為參數(shù).本節(jié)將從Artifact實例的管理出發(fā)，給出云環(huán)境下Artifact流程的執(zhí)行與監(jiān)控方法.

3.1流程管理機(jī)制

3.1.1流程管理

流程管理為用戶提供模型管理和實例管理的功能，其中，模型管理為不同用戶提供靜態(tài)流程定義的存儲與讀取服務(wù)，可以采用常規(guī)的云環(huán)境多租戶隔離方案解決.

用戶在定義完自己的Artifact流程后，模型管理負(fù)責(zé)保存用戶的流程定義文件.在部署運行該流程時，會從模型管理處讀取該流程定義，模型管理將解析該流程定義并創(chuàng)建流程運行時實例，并將該運行時實例交由實例管理來管理.

3.1.2實例管理

實例管理負(fù)責(zé)管理該租戶運行時的流程實例，并且為流程引擎提供流程實例加載功能.

流程實例是流程監(jiān)控和運行的關(guān)鍵，它保存了Artifact業(yè)務(wù)流程執(zhí)行時的上下文信息.流程實例由Artifact實例、活動實例和業(yè)務(wù)規(guī)則實例3部分組成，各個實例所包含的內(nèi)容和實例之間的關(guān)系如圖3所示.

圖3　運行時實例間關(guān)系Fig.3　Class relationship of run time instance

流程實例：系統(tǒng)將會先創(chuàng)建一個流程實例，并為其設(shè)定一個唯一標(biāo)識ID，并且調(diào)用實例管理將此ID存儲到租戶的流程實例庫中，然后去加載對應(yīng)的Artifact定義、活動定義和業(yè)務(wù)規(guī)則定義.此ID可以用于跟蹤和監(jiān)控流程執(zhí)行的過程，為執(zhí)行中的產(chǎn)生事件匹配正確的流程實例.流程實例是該流程運行時涉及的其他實例的容器，流程實例維護(hù)著事件與業(yè)務(wù)規(guī)則的映射關(guān)系，保存著流程執(zhí)行時上下文需要的所有信息和流程中的業(yè)務(wù)規(guī)則.

Artifact實例：根據(jù)流程定義中的Artifact定義來創(chuàng)建，該定義是一個xml文件，描述了Artifact實例創(chuàng)建所需的所有信息.Artifact實例可以在流程啟動執(zhí)行后創(chuàng)建，也可以由活動來創(chuàng)建，新創(chuàng)建的Artifact實例將會被賦予一個唯一的標(biāo)識符，所有的Artifact實例共同描述著該流程實例執(zhí)行的狀態(tài).

活動實例：在流程實例創(chuàng)建后，系統(tǒng)會根據(jù)其所包含的活動定義信息創(chuàng)建活動實例.每個活動定義對應(yīng)著一個活動實例，活動實例中存儲了活動涉及的服務(wù)調(diào)用信息，以及該服務(wù)調(diào)用結(jié)束后對Artifact的操作，操作通過腳本的方式來描述.

業(yè)務(wù)規(guī)則實例為根據(jù)業(yè)務(wù)規(guī)則定義，在流程實例創(chuàng)建后創(chuàng)建，該實例中存儲了業(yè)務(wù)流程模型中的業(yè)務(wù)規(guī)則和該規(guī)則的觸發(fā)事件，在接收到相應(yīng)事件后開始執(zhí)行對應(yīng)規(guī)則，在規(guī)則執(zhí)行結(jié)果為真時觸發(fā)執(zhí)行后續(xù)的活動.

3.2流程執(zhí)行機(jī)制

3.2.1流程引擎架構(gòu)

流程引擎負(fù)責(zé)執(zhí)行不同租戶的流程實例,調(diào)用流程中涉及的活動,本文基于事件驅(qū)動和面向服務(wù)的架構(gòu)，給出了執(zhí)行Artifact流程模型的流程引擎架構(gòu)，如圖4所示.

圖4　Artifact流程引擎架構(gòu)Fig.4　Architecture for Artifact process engine

流程控制器：負(fù)責(zé)流程實例運行過程的調(diào)度，是流程引擎的核心.流程控制器會接收來自Artifact管理器、活動管理器、流程實例管理器和業(yè)務(wù)規(guī)則引擎的事件，并且根據(jù)事件內(nèi)容，通知對應(yīng)模塊執(zhí)行.流程控制器可以調(diào)用業(yè)務(wù)規(guī)則引擎執(zhí)行業(yè)務(wù)規(guī)則實例，或者通知Artifact管理器更新Artifact實例.

業(yè)務(wù)規(guī)則引擎：負(fù)責(zé)執(zhí)行流程實例中的業(yè)務(wù)規(guī)則實例.當(dāng)流程控制器接收到事件時，將會根據(jù)事件信息，找到相關(guān)的流程實例，然后加載對應(yīng)的業(yè)務(wù)規(guī)則實例放入到規(guī)則引擎中執(zhí)行，業(yè)務(wù)規(guī)則引擎將會把執(zhí)行的結(jié)果返回給流程控制器，流程控制器將會根據(jù)它來更新Artifact或者調(diào)用活動.

流程實例管理器：管理流程引擎中運行的所有流程實例的副本，可以根據(jù)流程控制器的請求從租戶的實例管理中加載對應(yīng)的流程實例.

活動管理器：負(fù)責(zé)執(zhí)行流程實例中的活動實例，調(diào)用活動實例中的web服務(wù)，根據(jù)活動對Artifact實例的操作通知Artifact管理器修改對應(yīng)Artifact實例.

Artifact管理器：負(fù)責(zé)處理流程實例運行時對Artifact實例的修改，任何對流程實例的Artifact實例的修改請求都由Artifact管理器來處理，Artifact管理器將會根據(jù)處理的結(jié)果產(chǎn)生相應(yīng)的Artifact實例狀態(tài)改變事件.

3.2.2流程執(zhí)行過程

流程實例的執(zhí)行過程是流程實例在Artifact流程引擎的協(xié)調(diào)下完成的，其中活動實例的執(zhí)行順序由流程控制器和業(yè)務(wù)規(guī)則引擎共同協(xié)作完成，活動實例的執(zhí)行操作由活動管理器來完成.

流程啟動后，流程實例管理器將會從實例管理中加載并注冊對應(yīng)的流程實例，并產(chǎn)生create order事件，事件中包含了對應(yīng)流程實例的ID，流程控制器根據(jù)該ID匹配到對應(yīng)的流程實例，然后根據(jù)消息名稱獲取對應(yīng)的業(yè)務(wù)規(guī)則實例.然后流程控制器會以該流程實例作為上下文環(huán)境，將該業(yè)務(wù)規(guī)則實例交給業(yè)務(wù)規(guī)則引擎執(zhí)行.業(yè)務(wù)規(guī)則引擎把執(zhí)行的結(jié)果以消息的形式傳遞給流程控制器，流程控制器根據(jù)執(zhí)行的結(jié)果來調(diào)用活動控制器執(zhí)行對應(yīng)的活動實例.活動控制器在接收到事件后，會執(zhí)行該活動實例，并且根據(jù)返回結(jié)果通知Artifact管理器執(zhí)行后續(xù)的更新操作，Artifact管理器將會更新Artifact實例內(nèi)容，并根據(jù)Artifact實例狀態(tài)變化產(chǎn)生對應(yīng)的狀態(tài)改變事件.

3.2.3流程監(jiān)控機(jī)制

根據(jù)前文流程執(zhí)行過程的介紹，可以發(fā)現(xiàn)流程實例運行的狀態(tài)可以由其包含的Artifact實例狀態(tài)來確定.通過監(jiān)控該流程涉及的所有Artifact實例狀態(tài)，可以實現(xiàn)對該流程運行過程的監(jiān)控.

表2所示流程監(jiān)控表是流程實例運行狀態(tài)和對應(yīng)的Artifact實例狀態(tài)的映射關(guān)系.例如，order處于wait for items，則流程實例處于還在采購零部件的過程中.對于某個處于initial狀態(tài)的line item Artifact實例，若其關(guān)聯(lián)的procurement實例是rejected，那么意味著之前該line item的采購請求被拒絕，新的采購請求在進(jìn)行中；如果line item是not ready狀態(tài)，而關(guān)聯(lián)的procurement處于received狀態(tài)，那么意味著該零部件已經(jīng)采購到，還在運輸?shù)倪^程中.

表2　流程監(jiān)控表Table 2　Table for process monitoring

4　系統(tǒng)開發(fā)及實例驗證

4.1系統(tǒng)開發(fā)

在前文研究的基礎(chǔ)上，這里開發(fā)了一個基于Artifact業(yè)務(wù)過程管理技術(shù)的系統(tǒng).該系統(tǒng)采用Java開發(fā)，后臺使用restlet框架，前臺利用Dagre D3的d3.js庫，業(yè)務(wù)規(guī)則解析采用Drools規(guī)則引擎，測試用的web服務(wù)采用了axis 2框架開發(fā)，目前已經(jīng)完成了系統(tǒng)的執(zhí)行和實例監(jiān)控功能.

一個網(wǎng)上購物運輸流程在BPM下的建模描述如圖5所示.

圖5流程中存在訂單(order)、運單(shipment)和發(fā)票(invoice)這3個Artifact. 根據(jù)研究內(nèi)容給出了該流程基于Artifact的流程定義，然后將該xml定義文件部署到系統(tǒng)中運行，圖6給出了該系統(tǒng)運行過程中的監(jiān)控結(jié)果.從該結(jié)果中可以看到每個Artifact實例包含的內(nèi)容和所處狀態(tài)，從而方便地對流程進(jìn)行監(jiān)控，上述結(jié)果顯示目前該流程實例還處于訂單審核中.

圖5　網(wǎng)上購物運輸流程Fig.5　Online ordering shipment process

圖6　流程監(jiān)控結(jié)果Fig.6　Process monitoring results

4.2結(jié)果討論

文獻(xiàn)[5]中Milinda方法基于常見的BPEL建模方法，通過對引擎的修改，實現(xiàn)不同租戶流程實例的分離管理.表3給出了本文提出的方法與Milinda方法的對比.

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

由表3對比可知，雖然本文提出的方法建模和系統(tǒng)實現(xiàn)難度比較高，但是引擎不需要維護(hù)運行時數(shù)據(jù)，相比較而言更加靈活且易于維護(hù)，在數(shù)據(jù)量增加時也不會影響引擎的效率，適合云環(huán)境的需求.

5　結(jié)　語

本文針對目前云環(huán)境下傳統(tǒng)業(yè)務(wù)流程存在的問題，研究了基于Artifact業(yè)務(wù)過程模型的解決方法.在已有研究的基礎(chǔ)上，首先分三部分給出了Artifact業(yè)務(wù)建模方法的主要定義；然后結(jié)合云環(huán)境提出了能夠執(zhí)行該模型業(yè)務(wù)流程的系統(tǒng)架構(gòu)，研究了該系統(tǒng)下的執(zhí)行與監(jiān)控的機(jī)制；最后通過原型系統(tǒng)和實例驗證了本文方法的可行性.從驗證和對比的結(jié)果來看，本文提出的業(yè)務(wù)過程管理框架，能夠很好地解決云環(huán)境下業(yè)務(wù)過程管理存在的數(shù)據(jù)管理問題，為云環(huán)境下的業(yè)務(wù)過程管理提供一種高效、靈活和易維護(hù)的解決方法.

[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

國家自然科學(xué)基金資助項目(61373030)；國家高技術(shù)發(fā)展計劃資助項目(2008AA04Z126)

方澤杭(1990—)，男，湖北黃岡人，碩士研究生，研究方向為工作流管理. E-mail: rinascere@sjtu.edu.cn

蔡鴻明(聯(lián)系人),男，副教授, E-mail: hmcai@sjtu.edu.cn

TP 319

A