孫笑笑，沈滬軍，楊思青，俞東進(jìn)+

(1.杭州電子科技大學(xué) 計(jì)算機(jī)學(xué)院，浙江 杭州 310018；2.復(fù)雜系統(tǒng)建模與仿真教育部重點(diǎn)實(shí)驗(yàn)室，浙江 杭州 310018)

0 引言

隨著業(yè)務(wù)流程的日益復(fù)雜化，一些需要跨組織協(xié)作的業(yè)務(wù)流程場(chǎng)景不斷涌現(xiàn)，如金融教育管理、醫(yī)療健康管理、資產(chǎn)管理、供應(yīng)鏈等[1]，對(duì)于這些跨組織的業(yè)務(wù)流程，組織間缺乏信任是其進(jìn)行業(yè)務(wù)協(xié)同的最大障礙。傳統(tǒng)的業(yè)務(wù)流程管理方法一般采用第三方權(quán)威機(jī)構(gòu)，如銀行、支付寶等作為中央控制者進(jìn)行信任委托，但這可能會(huì)帶來交易安全風(fēng)險(xiǎn)增加、效率低下、不可追溯等問題[2]。近年來，區(qū)塊鏈技術(shù)受到廣泛關(guān)注，它是分布式數(shù)據(jù)存儲(chǔ)、點(diǎn)對(duì)點(diǎn)傳輸、共識(shí)機(jī)制、加密算法等計(jì)算機(jī)技術(shù)的一種新型應(yīng)用模式，具有去中心化、不可篡改、開放自治、可追溯的特性。區(qū)塊鏈以太坊平臺(tái)使用智能合約來實(shí)現(xiàn)流程自動(dòng)化，不需要依賴任何集中的第三方權(quán)威機(jī)構(gòu)進(jìn)行組織間協(xié)作[3]。以保險(xiǎn)為例，無論飛機(jī)延誤險(xiǎn)、意外險(xiǎn)還是疾病險(xiǎn)，只要將保單及航班號(hào)、意外事故列表單、用戶的病歷單等上鏈，在達(dá)到智能合約自動(dòng)觸發(fā)的條件時(shí)(如飛機(jī)延誤)，保險(xiǎn)公司將自動(dòng)化理賠投保人的申請(qǐng)，既可減少糾紛，也能提高雙方的效率?，F(xiàn)有研究表明，在業(yè)務(wù)流程中引入?yún)^(qū)塊鏈技術(shù)，對(duì)解決跨組織業(yè)務(wù)流程的信任問題具有重要意義[1-2,4]。

近年來出現(xiàn)的一批通過智能合約控制復(fù)雜業(yè)務(wù)流程的方法或引擎如Caterpillar[5]，Lorikeet[6]等，普遍存在實(shí)例化成本高、靈活性差(如版本迭代困難)等問題，特別是這些方法或引擎都存在一個(gè)共同的缺點(diǎn)，即沒有在智能合約中適當(dāng)考慮時(shí)間或缺乏時(shí)間約束，而時(shí)間在跨組織業(yè)務(wù)流程中至關(guān)重要[7]。例如訂單業(yè)務(wù)中，客戶廠家間通過遵守訂單的截止日期和延遲交付日期來維持合作伙伴間共同的業(yè)務(wù)目標(biāo)。實(shí)際上，區(qū)塊鏈平臺(tái)目前并沒有有效表示時(shí)間、管理時(shí)間約束的方式。另外，由于智能合約由交易驅(qū)動(dòng)，其在封閉環(huán)境中執(zhí)行，無法訪問全局時(shí)間信息[7]，若能在智能合約中適當(dāng)引入時(shí)間約束，則可減輕跨組織業(yè)務(wù)流程中一些活動(dòng)因違反時(shí)間約束而導(dǎo)致過度消耗區(qū)塊鏈Gas的問題(例如提前終止或通知訂單業(yè)務(wù)中不滿足約定發(fā)貨時(shí)間約束的流程)，從而避免在組織間出現(xiàn)糾紛。

針對(duì)上述問題，本文提出一種基于賦時(shí)編排圖的區(qū)塊鏈業(yè)務(wù)流程引擎，將跨組織業(yè)務(wù)流程中的時(shí)間約束分為編排活動(dòng)的單次持續(xù)時(shí)間約束、編排活動(dòng)的最大持續(xù)時(shí)間約束和編排活動(dòng)的間隔時(shí)間約束3類，基于3類時(shí)間約束擴(kuò)展現(xiàn)有編排圖提出賦時(shí)編排圖的概念，旨在通過賦時(shí)編排圖解決跨組織業(yè)務(wù)流程中因違反時(shí)間約束導(dǎo)致的信任缺失問題，達(dá)到流程優(yōu)化的目的。另外，有別于Caterpillar等通用引擎部署時(shí)采用實(shí)例和智能合約一對(duì)一的編譯型部署方式，本文引擎采用基于元模型的解釋型部署方式，部署后的智能合約可被不同流程實(shí)例編排復(fù)用，大幅降低了對(duì)區(qū)塊鏈Gas的消耗。同時(shí)，引擎集成了基于投票機(jī)制的版本控制策略，可解決現(xiàn)有版本迭代難題，流程管理者通過版本信息可追溯同一版本的實(shí)例活動(dòng)信息。

1 相關(guān)工作

目前較早開源的區(qū)塊鏈業(yè)務(wù)流程管理引擎Caterpiller從輸入一個(gè)BPMN2.0(business process modeling notation)流程模型開始[5]，采用智能合約和實(shí)例一對(duì)一的編譯型方式進(jìn)行合約部署，可確保所有流程實(shí)例均符合流程參考模型，但其未對(duì)區(qū)塊鏈Gas成本消耗問題進(jìn)行優(yōu)化[8]。另外，Caterpillar在實(shí)例執(zhí)行過程中忽略了組織間的消息交互，即將跨組織業(yè)務(wù)流程視為組織內(nèi)部業(yè)務(wù)流程存在一定局限性。TRAN等[6]針對(duì)資產(chǎn)管理提出一種流程模型驅(qū)動(dòng)的區(qū)塊鏈業(yè)務(wù)流程執(zhí)行引擎Lorikeet，支持在資產(chǎn)注冊(cè)表數(shù)據(jù)模式中自動(dòng)生成智能合約，解決了在區(qū)塊鏈上進(jìn)行資產(chǎn)管理的難題，然而Lorikeet不支持限制級(jí)別的訪問控制，支持的功能也只限于資產(chǎn)管理。

現(xiàn)有的大部分研究，如Caterpillar[5]和Lorikeet[6]等，未涉及業(yè)務(wù)流程管理中至關(guān)重要的時(shí)間約束。KLINGER等[9]對(duì)時(shí)間約束進(jìn)行了概念級(jí)別的討論；ABID等[10]雖然對(duì)Caterpillar的時(shí)間約束進(jìn)行了擴(kuò)展，包括相對(duì)時(shí)間約束和絕對(duì)時(shí)間約束兩種，但是仍未解決Caterpillar本身存在的缺乏組織間消息交互、實(shí)例化成本高等問題；LADLEIF等[7]提出一套對(duì)現(xiàn)有區(qū)塊鏈平臺(tái)進(jìn)行時(shí)間度量的方法，并系統(tǒng)比較了它們的特性；HILDEBRANDT等[11]早期提出一種可用于描述跨組織定時(shí)業(yè)務(wù)流程的全局合同和每個(gè)組織本地合同的動(dòng)態(tài)定時(shí)圖結(jié)構(gòu)，可解決組織間的信任缺失問題，但其僅從概念級(jí)別進(jìn)行討論而缺乏實(shí)踐應(yīng)用；HAARMANN[12]討論采用模擬技術(shù)分析基于區(qū)塊鏈的跨組織業(yè)務(wù)流程的持續(xù)時(shí)間，但只停留于概念級(jí)別。

隨著區(qū)塊鏈業(yè)務(wù)流程管理研究的不斷發(fā)展，框架靈活性逐漸引起學(xué)者們的關(guān)注。LPEZ-PINTADO等[13]對(duì)Caterpillar進(jìn)行結(jié)構(gòu)調(diào)整，提出一種基于動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)的流程模型解釋器，允許流程參與者動(dòng)態(tài)修改流程模型，雖然提高了框架的靈活性，但是缺乏版本迭代策略，即對(duì)流程模型的版本控制。另外，針對(duì)跨組織業(yè)務(wù)流程的多方組織協(xié)作的特殊性，LADLEIF等[14]提出針對(duì)編排圖的操作語義，并通過以太坊智能合約在3個(gè)案例原型上進(jìn)行了概念驗(yàn)證；CORRADINI等[15]提出一種編排圖驅(qū)動(dòng)的區(qū)塊鏈業(yè)務(wù)流程引擎，將輸入的BPMN2.0編排圖轉(zhuǎn)化為特定的智能合約，并通過智能合約達(dá)到控制跨組織業(yè)務(wù)流程的目的，但其同樣采用智能合約和實(shí)例一對(duì)一的編譯型方式，存在缺乏靈活性和Gas消耗大等問題；2020年，LICHTENSTEIN等[16]提出一種區(qū)塊鏈上的編排方法，使生成的數(shù)據(jù)可被不同流程實(shí)例編排復(fù)用，從而降低區(qū)塊鏈Gas成本并保證數(shù)據(jù)的完整性，但其并未對(duì)訪問控制、時(shí)間約束等進(jìn)行討論；MERCENNE等[17]提出在Caterpillar上引入角色訪問控制策略，以提高框架靈活性和安全性，但僅停留于概念級(jí)別；LPEZ-PINTADO等[18]提出一種用于跨組織協(xié)作的角色動(dòng)態(tài)綁定模型和相應(yīng)的綁定規(guī)范，并將其工作集成到Caterpillar引擎中，然而動(dòng)態(tài)綁定模型的引入增加了角色授權(quán)的復(fù)雜性，也增加了在智能合約中進(jìn)行訪問控制的成本開銷。

綜上所述，現(xiàn)有的區(qū)塊鏈業(yè)務(wù)流程管理方法或引擎普遍存在缺乏時(shí)間約束、實(shí)例化成本高、靈活性差(如版本迭代困難)等問題，而且這些方法或引擎多停留在理論或概念階段，難以支持實(shí)際的生產(chǎn)流程?；谏鲜霰尘昂拖嚓P(guān)工作，本文致力于解決已有工作限制，在高效管理考慮時(shí)間約束的區(qū)塊鏈業(yè)務(wù)流程方面展開相關(guān)工作，提出一種基于賦時(shí)編排圖的業(yè)務(wù)流程管理引擎，并在真實(shí)跨組織業(yè)務(wù)流程中開展應(yīng)用。

2 預(yù)備知識(shí)和相關(guān)定義

2.1 編排圖

現(xiàn)有的區(qū)塊鏈業(yè)務(wù)流程管理方法或引擎普遍從BPMN模型圖著手研究，這些BPMN模型圖主要分為BPMN流程圖、BPMN協(xié)作圖和BPMN編排圖3類，其中協(xié)作圖和編排圖常被用于描述跨組織業(yè)務(wù)流程的執(zhí)行過程[19-20]。具體地，協(xié)作圖詳細(xì)描述了如何實(shí)現(xiàn)和管理不同組織間及組織內(nèi)的組件；編排圖主要從流程的全局視角出發(fā)，其更關(guān)注組織間如何交互而忽略組織內(nèi)不必要的細(xì)節(jié)。相比協(xié)作圖而言，編排圖對(duì)流程的描述更簡(jiǎn)潔也更能突出組織間的協(xié)作，因此本文采用編排圖進(jìn)行基于區(qū)塊鏈的跨組織業(yè)務(wù)流程建模。

定義1編排圖。編排圖用一個(gè)四元組G={Event,Gateway,Activity,Flow}表示。其中：事件Event僅包括編排活動(dòng)的開始事件、結(jié)束事件；網(wǎng)關(guān)Gateway用于控制編排流程中序列流的走向，包括排他網(wǎng)關(guān)、并行網(wǎng)關(guān)、事件網(wǎng)關(guān)；編排活動(dòng)Activity表示消息協(xié)作雙方進(jìn)行的活動(dòng)，包括編排活動(dòng)名稱、發(fā)送者、接收者、消息；序列流Flow用于連接編排元素，表示指定執(zhí)行的順序。

圖1所示為編排圖的常用元素，包括事件、網(wǎng)關(guān)、編排活動(dòng)和序列流，其中編排活動(dòng)根據(jù)其攜帶的消息數(shù)量分為單向活動(dòng)(One-Way)和雙向活動(dòng)(Two-Way)。

2.2 賦時(shí)編排圖

本文在編排圖的基礎(chǔ)上定義了若干時(shí)間約束的相關(guān)概念，并提出賦時(shí)編排圖的概念。

定義2編排活動(dòng)的活動(dòng)時(shí)間。T(ID)={TstartTime,TendTime}表示某個(gè)編排活動(dòng)中參與者雙方進(jìn)行消息交互的時(shí)間信息，其中TstartTime，TendTime分別為編排活動(dòng)的消息發(fā)送時(shí)間和消息確認(rèn)時(shí)間。

例如在提交訂單業(yè)務(wù)中，客戶作為消息發(fā)送者收到貨物以后發(fā)起一個(gè)收貨確認(rèn)消息，生產(chǎn)商作為消息接收者收到確認(rèn)消息，本次編排活動(dòng)即正常結(jié)束。

定義3編排活動(dòng)的單次持續(xù)時(shí)間約束。Tdura(ID)={Tmin,Tmax}表示編排活動(dòng)執(zhí)行一次的持續(xù)時(shí)間(即TendTime-TstartTime)需滿足的時(shí)間約束，其中Tmin為該編排活動(dòng)的單次最小持續(xù)時(shí)間約束，Tmax為該編排活動(dòng)的單次最大持續(xù)時(shí)間約束。編排活動(dòng)的單次持續(xù)時(shí)間約束滿足

Tmin≤TendTime-TstartTime≤Tmax。

(1)

例如在提交訂單業(yè)務(wù)中，訂單倉庫出庫需要在1 h內(nèi)完成，倉庫出庫花費(fèi)的時(shí)間需在管理者規(guī)定的時(shí)間內(nèi)，此即為編排活動(dòng)的單次最大持續(xù)時(shí)間約束。

定義4編排活動(dòng)的最大持續(xù)時(shí)間約束。Tcard(ID)={maxLoop(ID)·Tmax}表示編排活動(dòng)在多次執(zhí)行后最終執(zhí)行成功需滿足的時(shí)間約束，其中：Tmax為該編排活動(dòng)的單次最大時(shí)間約束，是編排活動(dòng)的單次持續(xù)時(shí)間約束Tdura(ID)的一部分；maxloop(ID)為某個(gè)編排活動(dòng)能夠執(zhí)行的最大次數(shù)，默認(rèn)值為1。

例如在提交訂單業(yè)務(wù)中，某編排活動(dòng)的消息接收者確認(rèn)消息后由于一些外部原因?qū)е孪G失，此時(shí)對(duì)該編排活動(dòng)設(shè)置一個(gè)大于1的maxloop(ID)閾值，即可激活對(duì)該編排活動(dòng)的重啟，從而避免流程終止。

定義5編排活動(dòng)的間隔時(shí)間約束。Tinter(ID)={AA,AAV}表示某個(gè)編排活動(dòng)和其他編排活動(dòng)的間隔時(shí)間約束集合。其中AA={ActivityID1,…,ActivityIDm}是與當(dāng)前活動(dòng)存在間隔時(shí)間約束的所有活動(dòng)的ID集合，AAV={Value1,…,Valuem}是與當(dāng)前活動(dòng)存在間隔時(shí)間約束的所有活動(dòng)的時(shí)間約束值。

例如在提交訂單業(yè)務(wù)中，客戶從訂單提交到取貨有一定期限要求，該期限即從訂單提交到收貨這兩個(gè)編排活動(dòng)之間的間隔時(shí)間約束。通過設(shè)置間隔時(shí)間約束可解決此類時(shí)間需求期限如“客戶需在一周內(nèi)取貨”的超時(shí)問題。

定義6時(shí)間約束的編排活動(dòng)。TOT={ActivityID,Participants,Tdura,Tcard,Tinter}表示考慮上述3種時(shí)間約束的編排活動(dòng)，其中ActivityID,Participants,Tdura,Tcard,Tinter分別表示編排活動(dòng)序號(hào)、編排活動(dòng)的參與者、編排活動(dòng)的單次持續(xù)時(shí)間約束、編排活動(dòng)的最大持續(xù)時(shí)間約束、編排活動(dòng)的間隔時(shí)間約束。

定義7編排圖消息。M=(Name,MesType,sender,receiver,TOT,Content)是編排活動(dòng)中消息的具體內(nèi)容，Name,MesType,sender,receiver,TOT,Content分別表示消息的名稱、類別、發(fā)送者地址、接收者地址、所對(duì)應(yīng)的時(shí)間約束的編排活動(dòng)、所帶的內(nèi)容。其中MesType包括發(fā)送者發(fā)送的消息Request和接收者確認(rèn)的消息Reply兩類。

定義8賦時(shí)編排圖。TM={E,M,D,T}表示考慮時(shí)間約束的編排圖，E,M,D,T分別為該賦時(shí)編排圖的元素(包括事件、網(wǎng)關(guān)和編排活動(dòng))、消息、決策條件、時(shí)間約束條件。其中元素E={EstartEvent,EendEvent,Gparallel,Gexclusive,TOT},EstartEvent為開始事件，EendEvent為結(jié)束事件，Gparallel為并行網(wǎng)關(guān)，Gexclusive為互斥網(wǎng)關(guān)，TOT為時(shí)間約束的編排活動(dòng)。

2.3 基于賦時(shí)編排圖的流程控制

賦時(shí)編排圖TM部署后，添加訪問控制組織CO和模型版本V得到元模型，元模型即流程實(shí)例執(zhí)行的參考模型。

定義9訪問控制組織。CO={U,R,UR}為包含所有業(yè)務(wù)流程參與者的組織結(jié)構(gòu)，其中U為訪問控制組織的參與者，R為訪問控制組織的角色，UR為訪問控制組織的參與者與角色的映射關(guān)系。

定義10模型版本。V=(VID,ListElement,ListMessage,StartEvent,Status)表示元模型的版本信息，是基于版本控制的一個(gè)通用元素部件。其中VID，ListElement，ListElement，ListMessage，StartEvent，Status分別為該版本部件中的版本號(hào)、元素版本數(shù)組、消息版本數(shù)組、版本的開始事件、版本的狀態(tài)(Init表示提出，Pass表示通過)。

定義11元模型。ML={E,M,D,T,CO,VID}是實(shí)例進(jìn)行創(chuàng)建和執(zhí)行的參考模型，其中E，M，D，T分別為賦時(shí)編排圖TM中的元素、消息、決策條件、時(shí)間約束條件，CO為訪問控制組織，VID為模型版本V的版本號(hào)。

以太坊上的流程實(shí)例通過調(diào)用智能合約的接口方法達(dá)到基于元模型創(chuàng)建和執(zhí)行的目的。具體地，本文包括3類智能合約，按部署順序分別為訪問控制合約、投票合約和腳手架合約，其中腳手架合約的代碼引用了訪問控制合約和投票合約，即將3個(gè)智能合約鏈接在一起。

定義12訪問控制合約。ACC={COaddressMap,RList,UList,ACClink}為一個(gè)用于對(duì)智能合約操作者進(jìn)行訪問授權(quán)的智能合約。其中COaddressMap存儲(chǔ)訪問控制組織CO的引用地址；RList={role1,…,rolem}存儲(chǔ)模型ML到合約翻譯過程中的所有角色；UList={user1,…,userm}為所有執(zhí)行實(shí)例的區(qū)塊鏈用戶賬號(hào)集合；ACClink為訪問控制合約部署后的合約引用地址。訪問控制組織CO={U,R,UR}是包含所有業(yè)務(wù)流程參與者的組織結(jié)構(gòu)，U為參與者，R為訪問控制組織的角色，UR為訪問控制組織的參與者與角色的映射關(guān)系。

定義13投票合約。VC={VP,ACClink,VClink}為發(fā)布提案并由參與者進(jìn)行投票的智能合約，其通過ACClink鏈接了訪問控制合約ACC。其中：提案VP={ID,SCaddress,VID,Voterequire,Votenow,State}，包括提案序號(hào)、腳手架地址、當(dāng)前版本號(hào)、提案通過需要的人數(shù)、提案當(dāng)前已經(jīng)通過的人數(shù)、提案狀態(tài)(包括發(fā)起狀態(tài)Init和通過狀態(tài)Pass);VClink為投票合約部署后的合約引用地址。

定義14腳手架合約。SC={TM,V,I,ACClink,VClink}是一個(gè)存儲(chǔ)業(yè)務(wù)流程賦時(shí)編排圖TM、模型版本V和實(shí)例I的智能合約，其通過ACClink和VClink分別鏈接訪問控制合約ACC和投票合約VC。其中業(yè)務(wù)流程賦時(shí)編排圖TM={E,M,D,T}，模型版本V={(E1,V1,M1,V1,D1,V1,T1,V1),…,(En,Vn,Mn,Vn,Dn,Vn,Tn,Vn)}，實(shí)例I={IE,IM,IG}，IE,IM,IG分別表示實(shí)例元素、實(shí)例消息內(nèi)容、實(shí)例全局?jǐn)?shù)據(jù)。

3 方法描述

3.1 引擎框架

3.1.1 主體引擎

如圖2所示為本文提出的基于賦時(shí)編排圖驅(qū)動(dòng)的業(yè)務(wù)流程管理引擎，分為鏈下部分和鏈上部分。鏈下的組件主要包括建模器、翻譯器和部署器，鏈上的組件主要包括智能合約、事件監(jiān)聽器和以太坊平臺(tái)。為保證本文的賦時(shí)編排圖能夠在以太坊上的智能合約中正確執(zhí)行，本文引擎的執(zhí)行步驟分別為流程梳理、流程建模、模型翻譯、模型部署、模型版本初始化、模型版本投票決議、創(chuàng)建新實(shí)例并執(zhí)行。圖中RPC表示遠(yuǎn)程過程調(diào)用(remote process call)。

3.1.2 鏈下部分

智能合約可以控制業(yè)務(wù)流程在鏈上的執(zhí)行過程，但在控制流程之前需對(duì)業(yè)務(wù)流程進(jìn)行建模并編寫和部署合約代碼，這些過程由流程管理者主導(dǎo)在鏈下完成。鏈下部分的步驟主要包括流程梳理、流程建模、模型翻譯、模型部署。

步驟1流程梳理。流程管理者從跨組織企業(yè)的日志文件中梳理跨組織業(yè)務(wù)流程和時(shí)間約束信息，即活動(dòng)單次持續(xù)時(shí)間約束Tdura(ID)、活動(dòng)最大持續(xù)時(shí)間約束Tcard(ID)、活動(dòng)間隔時(shí)間約束Tinter(ID)，為下一步的流程建模提供參考。

步驟2流程建模。流程管理者分析跨組織業(yè)務(wù)流程和時(shí)間約束信息，在chor-js建模器[21]中編排業(yè)務(wù)流程賦時(shí)編排圖TM。chor-js建模器支持BPMN2.0[8]規(guī)范的編排圖，能夠涵蓋并支持上文編排圖的所有常用元素，但chor-js建模器并不支持時(shí)間約束相關(guān)的擴(kuò)展功能，因此流程管理者在建模期間需要根據(jù)跨組織業(yè)務(wù)流程需求錄入時(shí)間約束信息，并在編排活動(dòng)的備注欄中錄入活動(dòng)單次持續(xù)時(shí)間約束Tdura(ID)、活動(dòng)最大持續(xù)時(shí)間約束Tcard(ID)或活動(dòng)間隔時(shí)間約束Tinter(ID)，最后導(dǎo)出BPMN格式表示的賦時(shí)編排圖TM。

步驟3模型翻譯。流程管理者將BPMN格式表示的賦時(shí)編排圖TM，通過本文基于Java語言實(shí)現(xiàn)的翻譯器解析出JSON格式表示的模型組件，用于下一步模型部署。該步驟的具體實(shí)現(xiàn)將在3.2.2節(jié)的算法1中闡述。

步驟4模型部署。流程管理者通過Remix平臺(tái)[22]按順序編譯投票合約VC、訪問控制合約ACC和腳手架合約SC，得到3個(gè)合約對(duì)應(yīng)的ABI(Application Binary Interface)文件。另外，流程管理者需按序在以太坊[23]平臺(tái)上部署投票合約VC、訪問控制合約ACC和腳手架合約SC，得到3合約地址，然后通過調(diào)用Web3.js[23]接口并傳入3個(gè)合約的ABI文件和合約地址，得到合約實(shí)例。 最后，通過合約實(shí)例獲取元模型的控制流信息和訪問控制組織CO，其中元模型的控制流信息包括賦時(shí)編排圖的元素E、消息M、決策信息D、時(shí)間約束信息T。賦時(shí)編排圖的具體部署過程將在3.2.3節(jié)的算法2中闡述。

3.1.3 鏈上部分

基于區(qū)塊鏈的業(yè)務(wù)流程管理引擎中，多方參與者一般是通過調(diào)用智能合約開放的接口來推動(dòng)流程的執(zhí)行。上文的鏈下部分主要進(jìn)行模型相關(guān)的準(zhǔn)備，本節(jié)主要闡述鏈上如何用模型驅(qū)動(dòng)。鏈上部分的步驟包括模型版本初始化、模型版本投票決議、創(chuàng)建新實(shí)例并執(zhí)行。

步驟5模型版本初始化。在驗(yàn)證通過角色訪問控制權(quán)限后，通過調(diào)用腳手架合約SC的接口對(duì)模型的版本進(jìn)行初始化，默認(rèn)初始化版本號(hào)為1；然后基于訪問控制組織CO將本地以太坊私鏈Ganache默認(rèn)的10個(gè)賬號(hào)綁定元模型的角色權(quán)限。

步驟6模型版本投票決議。在模型版本投票決議階段，版本發(fā)起人發(fā)布的新版本號(hào)相當(dāng)于投票合約中的一個(gè)投票提案VP，新版本號(hào)經(jīng)過所有參與者投票表決通過后得到元模型ML，基于元模型ML可進(jìn)行實(shí)例創(chuàng)建和執(zhí)行。圖3所示為鏈上版本控制示意圖，包括發(fā)布新版本、模型和版本綁定、實(shí)例版本控制3部分。其中，發(fā)布新版本主要包括版本提交、投票決策、版本發(fā)布3個(gè)過程，模型每部署一次都要求發(fā)布一個(gè)新版本，得到新版版本號(hào)后需將新版本集成到版本部件V；另外，根據(jù)已有的賦時(shí)編排圖TM、訪問控制組織CO、發(fā)布的新版本號(hào)或舊版本號(hào)可得元模型ML，元模型ML是實(shí)例進(jìn)行創(chuàng)建和執(zhí)行的參考模型，其中綁定了版本信息；最后，基于元模型創(chuàng)建新實(shí)例并執(zhí)行實(shí)例，實(shí)例的執(zhí)行過程需基于版本號(hào)，從而達(dá)到版本控制實(shí)例的效果。

步驟7創(chuàng)建新實(shí)例并執(zhí)行。模型版本投票表決通過后，新版本號(hào)將集成到本文引擎的腳手架合約SC的版本部件V中，創(chuàng)建新實(shí)例需攜帶版本號(hào)。在創(chuàng)建實(shí)例元素過程中，本文采用延遲元素實(shí)例的方法，僅當(dāng)元素被啟用時(shí)才在鏈上創(chuàng)建對(duì)應(yīng)元素，即未被啟用的實(shí)例元素不在鏈上添加數(shù)據(jù)，從而減少冗余數(shù)據(jù)，降低區(qū)塊鏈Gas消耗。另外，由于編排圖的業(yè)務(wù)流程是基于消息驅(qū)動(dòng)的，違背消息交互順序的請(qǐng)求會(huì)被腳手架合約SC拒絕，并通過事件監(jiān)聽器將監(jiān)聽到的事件信息通知給具體的用戶，從而保證正確執(zhí)行流程實(shí)例。進(jìn)一步地，正確執(zhí)行的消息被接受后會(huì)自動(dòng)觸發(fā)消息所屬元素的狀態(tài)轉(zhuǎn)化函數(shù)，激活下一個(gè)元素的執(zhí)行狀態(tài)。訪問控制合約ACC貫穿于整個(gè)流程執(zhí)行過程，所有涉及權(quán)限的操作都會(huì)基于ACC中的方法進(jìn)行權(quán)限驗(yàn)證，無對(duì)應(yīng)角色權(quán)限的參與者將無法在鏈上執(zhí)行編排活動(dòng)。本文將在3.2.4節(jié)具體闡述實(shí)例在時(shí)間約束下執(zhí)行編排活動(dòng)的過程，實(shí)例執(zhí)行過程中的區(qū)塊鏈Gas消耗等分析將在第4章實(shí)驗(yàn)分析部分詳細(xì)闡述。

3.2 賦時(shí)編排圖驅(qū)動(dòng)的業(yè)務(wù)流程執(zhí)行過程

本節(jié)進(jìn)一步詳細(xì)介紹賦時(shí)編排圖在整個(gè)引擎框架中的具體實(shí)現(xiàn)過程，主要包括賦時(shí)編排圖的建模、賦時(shí)編排圖的解析、賦時(shí)編排圖的部署、基于賦時(shí)編排圖的流程控制。

3.2.1 賦時(shí)編排圖的建模

賦時(shí)編排圖建模期間，流程管理者重點(diǎn)根據(jù)跨組織業(yè)務(wù)流程需求錄入3類時(shí)間約束信息，完成編排后導(dǎo)出BPMN格式表示的賦時(shí)編排圖TM文件F。具體地，本文基于賦時(shí)編排圖建立一個(gè)示例的跨組織業(yè)務(wù)流程模型，圖4所示為該賦時(shí)編排圖中的一個(gè)編排活動(dòng)，稱為“收貨確認(rèn)”，其中添加3類時(shí)間約束的過程如下：

(1)添加活動(dòng)單次持續(xù)時(shí)間約束Tdura(ID) 如圖4所示，流程管理者對(duì)“收貨確認(rèn)”編排活動(dòng)添加Tmin和Tmax兩個(gè)單次持續(xù)時(shí)間約束，分別表示該活動(dòng)的單次最小持續(xù)時(shí)間約束和單次最大持續(xù)時(shí)間約束。

(2)添加活動(dòng)最大持續(xù)時(shí)間約束Tcard(ID) 因?yàn)榫W(wǎng)絡(luò)故障、區(qū)塊鏈服務(wù)故障、流程參與者誤操作等會(huì)導(dǎo)致“收貨確認(rèn)”不成功，使流程非正常終止，而流程非正常終止往往需要基于元模型重新創(chuàng)建新實(shí)例并執(zhí)行，所以如圖4所示，流程管理者對(duì)編排活動(dòng)“收貨確認(rèn)”設(shè)定maxLoop(ID(“收貨確認(rèn)”))=3，表示該活動(dòng)最大可以重發(fā)3次，以確保流程按順序執(zhí)行下去，避免流程非正常終止。

(3)添加活動(dòng)間隔時(shí)間約束Tinter(ID) 由于部分特定客戶有類似“需在一周內(nèi)取貨”的需求，流程管理者需添加從“訂單提交”到“收貨確認(rèn)”兩個(gè)編排活動(dòng)之間的時(shí)間間隔約束。具體如圖4所示，流程管理者在當(dāng)前編排活動(dòng)中錄入所有與其存在間隔時(shí)間約束的活動(dòng)集合和約束值集合。

3.2.2 賦時(shí)編排圖的解析

引擎執(zhí)行步驟3的模型翻譯階段，部署器通過支持方法Bpmn.readFile翻譯在模型建模期間輸出的BPMN文件F，并輸出JSON格式表示的元模型ML部件。算法1描述了賦時(shí)編排圖解析的詳細(xì)過程。具體地，第4～8行解析了該編排圖的序列流，即將當(dāng)前編排活動(dòng)及其前驅(qū)活動(dòng)數(shù)組和后繼活動(dòng)數(shù)組綁定。在解析時(shí)間約束時(shí)，本文將輸入的序列分為活動(dòng)內(nèi)時(shí)間約束MapObjectIntra和活動(dòng)間時(shí)間約束MapObjectInter兩類，其中活動(dòng)內(nèi)時(shí)間約束MapObjectIntra包括從活動(dòng)的單次持續(xù)時(shí)間約束Tdura(ID)和活動(dòng)的最大持續(xù)時(shí)間約束Tcard(ID)得到的信息體，而活動(dòng)間時(shí)間約束MapObjectInter指與活動(dòng)的間隔時(shí)間約束Tinter(ID)相關(guān)的所有信息體。第17～25行描述如何從MapObjectIntra中解析出活動(dòng)內(nèi)時(shí)間約束的相關(guān)信息并寫入元模型ML部件，第26～30行描述如何從MapObjectInter中解析出活動(dòng)間時(shí)間約束的相關(guān)信息并寫入元模型ML部件。

算法1賦時(shí)編排圖的解析。

輸入：業(yè)務(wù)過程編排者采用建模器建模期間輸出的BPMN格式的賦時(shí)編排圖文件F。

輸出：JSON格式表示的元模型ML的部件(E,M,D,T)。

01:FUNCTION parseChoregraphy(BPMN2.0-ChorType-File F)

03: FOREACH sequenceFlow IN CollectionSequenceFlowDO:

04: //遍歷當(dāng)前元素，綁定前驅(qū)和后繼元素?cái)?shù)組

05: FlowNow←parseNowFlow(squenceFlow)

06: PreElements←equenceFlow.sourceElement

07: NextElements←equenceFlow.targetElement

08: M←addBandingChildElement(FlowNow,PreElements,NextElements)

09: END FOR

10: RETURN M

11: END FUNCTION

12: FUNCTION addBandingChildElement(FlowNow,PreElements,NextElements)

13: //如果當(dāng)前元素的類型是編排活動(dòng)

14: IF typeOf(FlowNow).equals("Task") DO:

15: MapObjectIntra←JSONObject.parseObject(FlowNow)

16: MapObjectInter←JSONObject.parseObject(FlowNow)

17: FOREAC Hentry IN MapObjectIntra DO://活動(dòng)內(nèi)時(shí)間約束

18: IF entry.getKey.equals("maxTime") DO:

19: M.setMaxTime(entry.getValue.parseToInt());

20: ELSE IF entry.getKey.equals("minTime") DO:

21: M.setMinTime(entry.getValue.parseToInt());

22: ELSE IF entry.getKey.equals("maxLoop") DO:

23: M.setMaxLoop(entry.getValue.parseToInt());

24: ELSE:

25: …

26: FOREACH entry in MapObjectInter DO:

27: IF entry.getKey.equals("pre_TaskId_array") DO:

28: M.setPreTaskIdArray(entry.getValue.ToList);

29: ELSE IF entry.getKey.equals("pre_Task_durationArray") DO:

30: M.setPreTaskDurataionArray(entry.getValue.ToList);

31: RETURN ML

32: END FUNCTION

3.2.3 賦時(shí)編排圖的部署

模型部署階段主要是將3.2.2節(jié)賦時(shí)編排圖解析得到的元模型ML部件部署到以太坊上，輸出包含元模型控制流信息的腳手架合約SC。具體地，第5～7行通過將Remix部署后的合約的ABI文件導(dǎo)入并調(diào)用Web3.js提供的接口獲取部署在以太坊上的合約實(shí)例；第8～13行從JSON表示的元模型ML的部件中取出Solidity語言數(shù)據(jù)結(jié)構(gòu)表示的角色列表RList、元素列表ElementList、消息列表MessageList、決策列表DecisionList、時(shí)間約束列表TOTList；第15～16行調(diào)用ACC合約方法給操作者用戶user綁定模型的角色；最后第17～18行進(jìn)行版本V初始化和模型實(shí)例版本的綁定。

算法2將解析后的元模型部件和初始化數(shù)據(jù)部署到以太坊。

輸入：JSON格式表示的元模型ML的部件、部署者的賬號(hào)user、腳手架合約SC、訪問控制合約ACC、投票合約VC編譯后的文件集合ABI以及對(duì)應(yīng)Remix部署后的地址集合ADD。

輸出：合約SC。

01: M=(E,M,D,T);E={EstartEvent,EendEvent,Gparallel,Gexclusive,TOT}

02: ABI=(ABISC,ABIACC,ABIVC);ADD=(SCaddress,ACCaddress,VCaddress)

03: FUNCTION deployAndImportData(M,user,ABI,ADD)

04: //根據(jù)合約的ABI文件和合約地址獲取區(qū)塊鏈上的合約實(shí)例

05: accInstance←web3.eth.Contract(ABIACC,ACCaddress)

06: voteInstance=web3.eth.Contract(ABIVC,VCaddress)

07: chorInstance=web3.eth.Contract(ABISC,SCaddress)

08: //將元模型ML的部件數(shù)據(jù)導(dǎo)入合約SC

09: RList←getRList(M,E)

10: ElementList←getElementList(M)

11: MessageList←getMessageList(M)

12: DecisionList←getDecisionList(M)

13: TOTList←getTOTList(M,E)

14: //調(diào)用ACC合約方法給操作者用戶user綁定元模型的角色

15: FOREACH role in RList DO:

16: allocateRoleToUser(role,user)

17: //初始化版本V結(jié)構(gòu)和綁定版本

18: SC.V←addVersion(SC)

19: FOREACH tot in TOTList DO:

20: IF tot NOT IN SC.M DO:

21: SC.M←addTime(SC,tot)

23: END IF

24: END FOR

25: …//元素、消息、決策部署同第18～23行

26: RETURN SC

27: END FUNCTION

3.2.4 基于賦時(shí)編排圖的流程控制

本文引擎中實(shí)例可復(fù)用元模型的數(shù)據(jù)。具體地，實(shí)例通過模型部署后的智能合約調(diào)用合約的接口方法來訪問元模型信息，如模型控制流信息、訪問控制組織、版本號(hào)。在本文流程實(shí)例執(zhí)行過程中，主要執(zhí)行基于元模型的流程和填充元模型數(shù)據(jù)流信息。另外，本節(jié)重點(diǎn)介紹基于賦時(shí)編排圖的流程控制，引擎通過消息傳遞推動(dòng)業(yè)務(wù)流程的執(zhí)行，即一個(gè)消息的正確執(zhí)行需要發(fā)送者調(diào)用sendMessage方法且確認(rèn)調(diào)用ackMessage方法后才算結(jié)束。canSendMessage方法是sendMessage方法體最開始的一部分，用于判斷當(dāng)前是否滿足發(fā)送消息的條件，如消息發(fā)送者和消息接收者是否擁有執(zhí)行消息的角色權(quán)限、序列流順序是否正確、消息綁定的編排活動(dòng)是否處于激活狀態(tài)、網(wǎng)關(guān)的決策類別和決策值是否正確等。本文將編排活動(dòng)的單次持續(xù)時(shí)間約束判斷邏輯放在ackMessage方法中，將編排活動(dòng)的最大持續(xù)時(shí)間約束和活動(dòng)間的間隔時(shí)間約束放在下一個(gè)活動(dòng)的sendMessage方法中，以保證時(shí)間約束邏輯控制流程實(shí)例執(zhí)行的正確性。

算法3描述編排活動(dòng)單次持續(xù)時(shí)間約束的Solidity代碼邏輯。具體地，第8～11行判斷當(dāng)前活動(dòng)執(zhí)行一次的持續(xù)時(shí)間是否符合本文活動(dòng)的單次持續(xù)時(shí)間約束Tdura，其中now為Solidity獲取當(dāng)前區(qū)塊的時(shí)間，ts.startTime為當(dāng)前活動(dòng)的開始時(shí)間，因此now-ts.startTime表示實(shí)例當(dāng)前活動(dòng)的持續(xù)時(shí)間。ts.minTime和ts.maxTime為參考元模型的最小持續(xù)時(shí)間約束和最大持續(xù)時(shí)間約束，emit為Solidity語言支持的事件回調(diào)機(jī)制，本文用其通知流程參與者違反了時(shí)間約束，并傳遞當(dāng)前活動(dòng)的名稱、違反的時(shí)間約束類型等信息。

算法3編排活動(dòng)的單次持續(xù)時(shí)間約束。

01: //確認(rèn)消息時(shí)判斷持續(xù)時(shí)間約束

02: FUNCTION ackMessage(uinti_id, uintm_id, InstanceMessageStatus status){

03: ……//如果滿足當(dāng)前的消息回復(fù)狀態(tài)、角色權(quán)限、編排活動(dòng)的狀態(tài)

04: Instance storage i=instanceMap[i_id];

05: MessageStruct storage ms=messageMap[m_id];

06: TimeStruct storage ts=timeMap[ms.task].versionMap[i.versionId];

07: //編排活動(dòng)的單個(gè)持續(xù)時(shí)間約束

08: IF ((now-ts.startTime>ts.maxTime)||(now-ts.startTimets.minTime)){

09: emit notifyToUser(“當(dāng)前活動(dòng)名稱X”，“不滿足活動(dòng)單次持續(xù)時(shí)間約束”);

10: RETURN false;

11: }

12: }

算法4描述編排活動(dòng)最大持續(xù)時(shí)間約束的Solidity代碼邏輯。如定義3所述，編排活動(dòng)的最大持續(xù)時(shí)間約束Tcard(ActivityID)={maxLoop(ActivityID)·Tmax}，其中Tmax為算法3中設(shè)置的編排活動(dòng)對(duì)應(yīng)的ts.maxTime，即最大單次持續(xù)時(shí)間；maxLoop為最大重發(fā)次數(shù)，該值已在賦時(shí)編排圖建模期間錄入。MainChoreography是本文腳手架SC合約的主體，其代碼引用訪問控制合約ACC和投票合約VC，即將3個(gè)合約鏈接在一起。canSendMessage會(huì)在發(fā)送消息之前判斷當(dāng)前活動(dòng)在規(guī)定的最大重發(fā)次數(shù)下的持續(xù)時(shí)間是否符合本文活動(dòng)最大持續(xù)時(shí)間約束Tcard(ID)。具體地，第13～14行通過當(dāng)前的編排活動(dòng)序號(hào)獲取序列流的上一個(gè)編排活動(dòng)序號(hào)；第18～21行是該時(shí)間約束的主要邏輯部分，不符合時(shí)間約束的消息將以Solidity的事件回調(diào)機(jī)制emit通知流程參與者。

算法4編排活動(dòng)的最大持續(xù)時(shí)間約束。

輸入：實(shí)例instanceID、消息的messageID。

01: CONTRACT MainChoreography {

02: //訪問控制合約

03: AccessControlaccessControl;

04: //投票合約

05: VoteContractvoteContract;

06: …//腳手架合約中包括賦時(shí)編排圖TM中除時(shí)間約束T以外的元素和版本V等

07: //最大持續(xù)時(shí)間約束

08: FUNCTION canSendMessage(uinti_id, uintm_id, string reveiver, string[] valType) {

09: Instance storage i=instanceMap[i_id];//獲取當(dāng)前的實(shí)例

10: MessageStruct storage ms=messageMap[m_id];

11: //獲取當(dāng)前編排活動(dòng)ID

12: uint storage now_es_id=ms.task;

13: //獲取序列流的上一個(gè)編排活動(dòng)ID

14: uint storage pre_es_id=elementMap[ms.task].versionMap[i.versionId].preElement;

15: …//角色權(quán)限、序列流順序、決策類別和值是否滿足參考模型的參數(shù)等

16: TimeStruct storage pre_ts=timeMap[pre_es_id].versionMap[i.versionId];

17: TimeStruct storage now_ts=timeMap[now_es_id].versionMap[i.versionId];

18: IF (now-pre_ts.endTime>pre_ts.maxLoop * pre_ts.maxTime){

19: emit notifyToUser(“當(dāng)前活動(dòng)名稱X”，“不滿足最大持續(xù)時(shí)間約束”);

20: RETURN false;

21: }

22: RETURN true;

23: }

24:}

算法5描述編排活動(dòng)間隔時(shí)間約束的Solidity代碼邏輯。編排活動(dòng)的間隔時(shí)間約束Tinter(ID)根據(jù)當(dāng)前活動(dòng)和其他活動(dòng)之間的間隔時(shí)間是否滿足參考元模型設(shè)定的值來調(diào)整活動(dòng)的執(zhí)行狀況。具體地，第9～13行為編排活動(dòng)間隔時(shí)間約束的主要邏輯部分，其中ts.pre_taskId_array，ts.pre_taskId_durationArray分別為與當(dāng)前活動(dòng)有間隔時(shí)間約束的活動(dòng)序號(hào)的集合列表、與當(dāng)前活動(dòng)有間隔時(shí)間約束值的集合列表。算法5遍歷ts.pre_taskId_array列表，逐一判斷當(dāng)前活動(dòng)和列表中活動(dòng)的間隔時(shí)間是否滿足ts.pre_taskId_durationArray列表中對(duì)應(yīng)的值，若不滿足，則以Solidity的事件回調(diào)機(jī)制emit通知給流程參與者。

算法5編排活動(dòng)的間隔時(shí)間約束。

01: //下一個(gè)活動(dòng)發(fā)送消息之前判斷間隔時(shí)間約束

02: FUNCTION sendMessage(uinti_id, uintm_id, address _receiver, string[]_valName, string[]_valValue){

03: …//如果滿足消息回復(fù)狀態(tài)、角色權(quán)限和編排活動(dòng)狀態(tài)

04: Instance storage i=instanceMap[i_id];

05: MessageStruct storage ms=messageMap[m_id];

06: TimeStruct storage ts=timeMap[ms.task].versionMap[i.versionId];

07: …//最大持續(xù)時(shí)間約束部分

08: //間隔時(shí)間約束

09: FOR (var i=0;i

10: IF (now-timeMap[ts.pre_taskId_array[i]].versionMap[i.versionId]>ts.pre_taskId_durationArray[i]) {

11: {

12: EMIT notifyToUser(“當(dāng)前活動(dòng)名稱X”，”不滿足間隔時(shí)間約束”);

13: RETURN false;

14: }

15: …//其他非時(shí)間約束

4 實(shí)驗(yàn)分析

為驗(yàn)證本文所提基于賦時(shí)編排圖的區(qū)塊鏈業(yè)務(wù)流程管理引擎的效果，本章以一家助聽器企業(yè)的商品訂購流程為例，建立相應(yīng)的業(yè)務(wù)流程模型，并采用本文方法將其部署在區(qū)塊鏈上執(zhí)行，然后對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析和評(píng)估。

4.1 實(shí)驗(yàn)準(zhǔn)備

4.1.1 實(shí)驗(yàn)環(huán)境

本文實(shí)驗(yàn)環(huán)境如下：操作系統(tǒng)為Windows 10專業(yè)版，64位；處理器為英特爾第七代酷睿i5-7500(3.40 GHZ，四核四線程)；內(nèi)存為16 GB；JDK版本為1.8.0_181；Solidity版本為0.4.22；Node.js版本為10.13.0；Ganache版本為v2.5.4；部署器為Remix；以太坊JavaScript API為Web3.js[23]；編排圖建模器為chor-js[21]；對(duì)比引擎為ChorChain[15]。

4.1.2 實(shí)驗(yàn)案例

采用本文所提業(yè)務(wù)流程賦時(shí)編排圖對(duì)該助聽器企業(yè)的商品訂購流程進(jìn)行編排，如圖5所示，流程主要涉及4個(gè)流程參與者(即門店客戶、生產(chǎn)商、物流商、發(fā)貨承運(yùn)商)、9個(gè)編排活動(dòng)、12條消息、4個(gè)決策網(wǎng)關(guān)和5個(gè)事件，是一個(gè)典型的跨組織業(yè)務(wù)流程。采用本文所提基于賦時(shí)編排圖驅(qū)動(dòng)的業(yè)務(wù)流程管理引擎，可解決該跨組織業(yè)務(wù)中由于消息差錯(cuò)或延遲產(chǎn)生的信任問題。具體地，當(dāng)圖中的發(fā)貨承運(yùn)商和生產(chǎn)商產(chǎn)生利益糾紛時(shí)，發(fā)貨承運(yùn)商和生產(chǎn)商可通過區(qū)塊鏈追溯過程實(shí)例的具體信息來解決該矛盾，不需要第三方權(quán)威機(jī)構(gòu)介入；而在引入時(shí)間約束后，可以有效解決由于生產(chǎn)商產(chǎn)品生產(chǎn)過慢、物流商產(chǎn)品交付時(shí)間延遲等帶來的經(jīng)濟(jì)處罰問題。

基于所提出的引擎，在以太坊私鏈上對(duì)該商品訂購跨組織業(yè)務(wù)流程案例對(duì)10個(gè)實(shí)例執(zhí)行過程進(jìn)行模擬實(shí)驗(yàn)，相關(guān)實(shí)例覆蓋圖中包含的所有元素、消息和決策信息。其中商品訂購流程的賦時(shí)編排圖通過Remix部署于以太坊私鏈上，以太坊私鏈由以太坊節(jié)點(diǎn)仿真器Ganache搭建，并選取其中10個(gè)以太坊賬戶作為流程參與者。

4.2 區(qū)塊鏈Gas消耗分析

本文引擎在以太坊節(jié)點(diǎn)仿真器Ganache搭建的本地私有鏈上執(zhí)行。值得注意的是，以太坊上的交易不是免費(fèi)的，需向挖礦的礦工支付加密貨幣作為手續(xù)費(fèi)，而需要支付的手續(xù)費(fèi)即Gas總成本由衡量操作復(fù)雜性的Gas數(shù)量和Gas單價(jià)的乘積決定，即

Cgas=GasUsed·GasPrice。

(2)

式中：Cgas為在區(qū)塊鏈上執(zhí)行某項(xiàng)操作或某個(gè)智能合約部署、調(diào)用合約方法等所需計(jì)算資源的Gas總成本；GasUsed為Gas的數(shù)量；GasPrice為Gas的單價(jià)。

在本文所提基于賦時(shí)編排圖的區(qū)塊鏈業(yè)務(wù)流程管理引擎中，Gas總成本主要由合約部署成本Cdeploy、數(shù)據(jù)導(dǎo)入與版本初始化成本Cinit、實(shí)例創(chuàng)建和執(zhí)行成本CinstancecreaAndExe3部分組成，即

CALL=Cdeploy+Cinit+CinstancecreaAndExe。

(3)

4.2.1 合約部署

表1所示為本文引擎的部署成本Cdeploy，主要分為訪問控制合約ACC的部署成本ACCdeploy、投票合約VC的部署成本VCdeploy和腳手架合約SC的部署成本SCdeploy3部分，即

Cdeploy=ACCdeploy+VCdeploy+SCdeploy。

(4)

表1 合約部署Gas消耗

4.2.2 數(shù)據(jù)導(dǎo)入與版本初始化

合約部署完成后，需要在創(chuàng)建實(shí)例之前導(dǎo)入數(shù)據(jù)并進(jìn)行版本初始化，表2所示為數(shù)據(jù)導(dǎo)入和版本初始化的Gas消耗。本文采用Ganache中的10個(gè)以太坊賬戶作為實(shí)驗(yàn)評(píng)估測(cè)試的過程參與者，addParticipant表示初始化導(dǎo)入10個(gè)賬戶；addRole表示將元模型ML解析后的所有角色列表導(dǎo)入腳手架合約SC對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中；addMessage，addElement，addDMN，addVersion分別表示往腳手架合約SC中導(dǎo)入對(duì)應(yīng)的消息M、元素E、決策D和時(shí)間T，相關(guān)描述如算法2所示；vote表示版本初始化過程中的投票決策。

表2 數(shù)據(jù)導(dǎo)入與版本初始化的Gas消耗

4.2.3 實(shí)例創(chuàng)建和執(zhí)行

在完成合約部署和數(shù)據(jù)導(dǎo)入與版本初始化后，流程管理者即可基于腳手架合約SC創(chuàng)建基于版本V的流程實(shí)例，實(shí)例通過引用腳手架合約SC中通用的數(shù)據(jù)結(jié)構(gòu)進(jìn)行編排活動(dòng)的消息交互，來執(zhí)行流程實(shí)例。實(shí)例創(chuàng)建和執(zhí)行總成本

(5)

式中：Cinstancecrea，Cinstanceexe分別為單個(gè)實(shí)例創(chuàng)建和執(zhí)行的Gas成本。

本文基于圖5模擬了10個(gè)實(shí)例的創(chuàng)建和執(zhí)行過程，表3所示為創(chuàng)建和執(zhí)行流程實(shí)例的Gas消耗結(jié)果，包括newInstance(創(chuàng)建新實(shí)例)，sendMessage(發(fā)送編排活動(dòng)中的消息)，ackMessage(確認(rèn)編排活動(dòng)中的消息)，completeTask(激活并啟用事件或網(wǎng)關(guān))4個(gè)實(shí)例方法的調(diào)用次數(shù)、平均Gas消耗和Gas消耗合計(jì)。

表3 實(shí)例創(chuàng)建和執(zhí)行Gas消耗

4.3 與現(xiàn)有工作的比較

4.3.1 定性比較

本節(jié)將本文所提基于賦時(shí)編排圖的區(qū)塊鏈業(yè)務(wù)流程管理引擎與現(xiàn)有方法或引擎進(jìn)行比較，包括LPEZ-PINTAD等[5]提出的Caterpillar引擎、LADLEIF等[14]提出的針對(duì)編排圖的操作語義、LICHTENSTEIN等[16]提出的區(qū)塊鏈上降低Gas消耗的編排方法、AMAL ABID等[10]針對(duì)Caterpillar提出的時(shí)間約束擴(kuò)展方法、CORRADINI等[15]提出的ChorChain原型引擎。本文主要從訪問控制、版本控制、時(shí)間控制、實(shí)例化成本和執(zhí)行成本5個(gè)角度對(duì)這些方法進(jìn)行定性評(píng)估和比較，如表4所示，表中★越多表示在相關(guān)方面越具優(yōu)勢(shì)。

表4 相關(guān)原型或方法的定性比較

(2)版本控制 本文引擎集成并實(shí)現(xiàn)了基于投票機(jī)制的版本控制策略，是一種比較新穎的方式，也是目前區(qū)塊鏈結(jié)合業(yè)務(wù)流程領(lǐng)域少數(shù)提供版本控制的原型引擎，其中實(shí)例基于版本進(jìn)行歸檔或追溯，可以解決現(xiàn)有版本迭代困難的問題。

(3)時(shí)間控制 AMAL ABID等針對(duì)Caterpillar擴(kuò)展了時(shí)間約束的功能，用于支持多個(gè)活動(dòng)間時(shí)間約束和活動(dòng)內(nèi)時(shí)間約束，如流程活動(dòng)的開始和完成時(shí)間[10]，并分別給出相應(yīng)的定義和Solidity代碼來實(shí)現(xiàn)，但是仍未解決Caterpillar本身存在缺乏組織間消息交互、實(shí)例化成本高等問題，也未給出實(shí)例驗(yàn)證。不同于Caterpillar引擎用BPMN流程圖驅(qū)動(dòng)流程，本文基于編排圖擴(kuò)展了時(shí)間約束，提出集成了編排活動(dòng)單次時(shí)間約束、活動(dòng)最大時(shí)間約束和活動(dòng)間隔時(shí)間約束的賦時(shí)編排圖，實(shí)現(xiàn)了對(duì)鏈上業(yè)務(wù)流程有效時(shí)間的管理。另外，本文通過一家助聽器行業(yè)的實(shí)際業(yè)務(wù)流程進(jìn)行了實(shí)驗(yàn)驗(yàn)證。

4.3.2 定量比較

本節(jié)將對(duì)成本進(jìn)行定量比較。本文采用CORRADINI等[15]提出的ChorChain原型引擎作為對(duì)比，因?yàn)镃horChain引擎與本文引擎類似，均通過編排圖驅(qū)動(dòng)鏈上的業(yè)務(wù)流程，不同的是ChorChain引擎采用實(shí)例和合約一對(duì)一的編譯型方式進(jìn)行部署，其部署的合約是單一實(shí)例獨(dú)占的，所以合約部署與實(shí)例創(chuàng)建同時(shí)完成，而本文引擎先進(jìn)行合約部署、數(shù)據(jù)導(dǎo)入與版本初始化這兩個(gè)過程得到元模型，再基于參考的元模型創(chuàng)建和執(zhí)行實(shí)例。

如上文所述，本文引擎的執(zhí)行總成本主要分為合約部署成本、數(shù)據(jù)導(dǎo)入與版本初始化成本、實(shí)例創(chuàng)建和執(zhí)行成本3部分，其中合約部署、數(shù)據(jù)導(dǎo)入與版本初始化兩個(gè)部分只需消耗Gas一次，即這兩部分成本不會(huì)隨流程實(shí)例數(shù)量的增加而增加，而實(shí)例創(chuàng)建和執(zhí)行消耗的Gas成本則隨實(shí)例數(shù)量的增加而增加。ChorChain的執(zhí)行成本主要分為實(shí)例創(chuàng)建成本和實(shí)例執(zhí)行成本兩部分，這兩部分的Gas成本會(huì)同時(shí)隨流程實(shí)例數(shù)量的增加而增加。

圖6所示為本文引擎和ChorChai引擎[15]的Gas執(zhí)行總成本對(duì)比。ChorChain引擎由于沒有合約部署、數(shù)據(jù)導(dǎo)入與版本初始化這兩個(gè)過程帶來的額外成本，在沒有實(shí)例或?qū)嵗龜?shù)量少于7的情況下，其執(zhí)行總成本(圖中第3條柱狀圖的總高度)相對(duì)較低，優(yōu)于本文引擎(圖中第2條柱狀圖的總高度)。然而隨著實(shí)例數(shù)量的增加，由于ChorChain引擎需要為每個(gè)實(shí)例創(chuàng)建一個(gè)合約后再執(zhí)行，平均每次將帶來約7 903 213的Gas總開銷(其中實(shí)例創(chuàng)建占總成本60%左右，實(shí)例執(zhí)行占40%左右)，其執(zhí)行總成本明顯增加。本文引擎雖然比ChorChain引擎多了合約部署、數(shù)據(jù)導(dǎo)入與版本初始化兩個(gè)部分的執(zhí)行成本，但是因?yàn)檫@兩個(gè)部分只需執(zhí)行一次，所以隨著實(shí)例數(shù)量的增加，其執(zhí)行總成本增加得比較緩慢。在實(shí)例數(shù)量大于7時(shí)，本文引擎的執(zhí)行總成本開始少于ChorChain引擎，可見本文引擎在大量實(shí)例下更具優(yōu)勢(shì)。 另外，相比無時(shí)間約束，在本文引擎中添加時(shí)間約束平均增加17%的總執(zhí)行成本，這是在編排活動(dòng)中集成時(shí)間約束判斷帶來的不可避免的Gas消耗。

綜上所述，通過定量分析實(shí)驗(yàn)可知，雖然本文引擎需在實(shí)例創(chuàng)建和執(zhí)行之前付出額外的代價(jià)用于合約部署、數(shù)據(jù)導(dǎo)入與版本初始化，而且實(shí)例的執(zhí)行平均成本高于ChorChain引擎，但是本文引擎在執(zhí)行大量流程實(shí)例時(shí)總體上表現(xiàn)更優(yōu)。

5 結(jié)束語

針對(duì)現(xiàn)有區(qū)塊鏈業(yè)務(wù)流程管理引擎實(shí)例化成本過高、版本迭代困難、缺乏時(shí)間約束等問題，本文提出一種基于賦時(shí)編排圖的業(yè)務(wù)流程管理引擎。引擎引入活動(dòng)單次持續(xù)時(shí)間約束、活動(dòng)最大持續(xù)時(shí)間約束和活動(dòng)間隔時(shí)間約束3類時(shí)間約束，在鏈上對(duì)時(shí)間敏感的業(yè)務(wù)流程進(jìn)行高效管理。另外，引擎采用基于元模型的解釋型部署方式，部署后的智能合約可被不同流程實(shí)例編排復(fù)用，從而大幅降低區(qū)塊鏈Gas消耗。引擎還提供了基于投票機(jī)制的元模型版本控制策略，解決了版本迭代困難的問題。

未來將嘗試在引擎中集成支持編排子過程和標(biāo)記等更多功能的建模器，同時(shí)嘗試結(jié)合版本控制進(jìn)行實(shí)例動(dòng)態(tài)遷移，并對(duì)實(shí)例相關(guān)資源進(jìn)行更細(xì)致地評(píng)估和擴(kuò)展。在跨組織業(yè)務(wù)流程中，業(yè)務(wù)流程時(shí)間相關(guān)的預(yù)測(cè)，如供應(yīng)鏈中商品到貨時(shí)間預(yù)測(cè)等研究較少，未來將結(jié)合時(shí)間信息和機(jī)器學(xué)習(xí)方法進(jìn)行鏈上時(shí)間預(yù)測(cè)。