謝凌奇，姜麗紅，蔡鴻明

0 引言

工作流引擎是企業(yè)將其分散的應(yīng)用連接并整合成一個完整流程應(yīng)用的調(diào)度工具。隨著云應(yīng)用普及以及企業(yè)流程的愈加復(fù)雜化，企業(yè)不但需要能夠復(fù)用的云應(yīng)用，還需要能夠復(fù)用的工作流，也就是說企業(yè)需要一個能夠部署在云端，能夠?qū)⒐ぷ髁饕胤庋b好并提供給客戶使用，并能夠與云端應(yīng)用順利交互的工作流引擎。

目前工作流引擎結(jié)構(gòu)復(fù)雜，與應(yīng)用耦合度較高，這種架構(gòu)不利于在云端的部署，難以與不同結(jié)構(gòu)遠(yuǎn)端服務(wù)進(jìn)行交互。傳統(tǒng)工作流引擎只能以流程為單位存儲工作流要素，因此也無法以流程子節(jié)點(diǎn)的層次提供工作流要素給客戶進(jìn)行復(fù)用，難以滿足客戶對細(xì)節(jié)定制的需要。

常見的工作流引擎有集中式和分布式工作流引擎，Yang[1]等人利用J2EE分布式對象框架實(shí)現(xiàn)分模塊的工作流引擎，但在各模塊之間的交互上消耗過多的時間，也提高了出錯幾率。王明微[2]等人提出了一種“按需分配”的工作流任務(wù)分配方法，處理云端工作流引擎的協(xié)同處理問題。Bin[3]等人設(shè)計(jì)了面向SAAS應(yīng)用的工作流引擎， Barker[4]等人提出了用編排模型優(yōu)化工作流與服務(wù)之間的信息傳輸，但沒有考慮異構(gòu)數(shù)據(jù)的轉(zhuǎn)換問題，Yu-Yen[5]等人設(shè)計(jì)了一個集成框架以實(shí)現(xiàn) SOAP與 REST服務(wù)的轉(zhuǎn)化，但是消耗過高，Prashant[6]提出了方法資源的概念，很好地解決 REST服務(wù)對于復(fù)雜操作支持度低的問題。

在此基礎(chǔ)上設(shè)計(jì)了基于 RESTful風(fēng)格的資源化工作流引擎，利用RESTful風(fēng)格架構(gòu)使其適應(yīng)云端部署環(huán)境，利用RESTful服務(wù)中每個資源結(jié)點(diǎn)都可以發(fā)布并接受訪問的特性，將流程、活動、實(shí)例等所有工作流要素都封裝為REST的資源并建立元模型庫，從而能夠以流程節(jié)點(diǎn)的層次提供可復(fù)用的工作流要素。

1 工作流引擎的資源抽象

一個工作流引擎的實(shí)現(xiàn)分為流程設(shè)計(jì)、流程管理、應(yīng)用調(diào)用和部署4個部分，如圖1所示：

圖1 資源化引擎設(shè)計(jì)框架

基于REST的資源化工作流引擎的設(shè)計(jì)思路，分為兩步，第一步是鑒定出工作流中可以抽象為資源的要素，將流程定義、活動、任務(wù)、數(shù)據(jù)、角色等工作流要素歸類為實(shí)體資源，把要素之間的關(guān)系界定為資源關(guān)系，把啟動流程、掛起、終止等需要分多步調(diào)用資源的操作抽象為方法資源，然后建立資源元模型，并持久化到數(shù)據(jù)庫中。第二步是將所有資源封裝，構(gòu)建為REST服務(wù)并以統(tǒng)一的WADL進(jìn)行描述。

在引擎部署時，一個RESTful服務(wù)框架的工作流引擎能夠很好的適應(yīng)云端環(huán)境。能夠以通用的標(biāo)準(zhǔn)接口在遠(yuǎn)端發(fā)布服務(wù)，并為客戶提供調(diào)用方式。在流程設(shè)計(jì)和流程管理部分，封裝為資源的每一個流程要素都能夠獨(dú)立的進(jìn)行發(fā)布、創(chuàng)建、修改、復(fù)用等操作，客戶可以靈活的操作和管理每個流程要素，且不用擔(dān)心流程細(xì)節(jié)不能復(fù)用。在應(yīng)用調(diào)度方面，RSET化的工作流引擎使用標(biāo)準(zhǔn)的HTTP訪問方式，能夠更順暢地與Web服務(wù)進(jìn)行交互。

1.1 工作流建模與實(shí)體資源抽象

構(gòu)建資源化的工作流引擎，首先就是要將工作流中的部分要素抽象并封裝為實(shí)體資源，流程的定義、活動、活動關(guān)系、邏輯規(guī)則等實(shí)體資源以及它們之間的關(guān)聯(lián)。如圖 2所示：

圖2 資源模型

在圖2中，W是工作流的抽象，工作流的所有內(nèi)容都包含在W之中。PDe為流程定義的抽象，可定義為公式（1）

將 PDe封裝為資源，并分配 URI Http://orips3.com/W/{W_ID}/PDe。

流程定義中包括了流程定義編號（PDe_ID）、活動（A）、活動關(guān)聯(lián)（C）、邏輯節(jié)點(diǎn)（R）和流程狀態(tài)（State）。其中A為所有活動的集合，A可定義為公式（2）

其中A_ID為活動的標(biāo)識，A_Task為該活動需完成的任務(wù)的抽象，包含了指向待操作的Web服務(wù)的鏈接。A_Role是該活動中被分配任務(wù)的角色的抽象，A_Data是該任務(wù)將要處理的數(shù)據(jù)對象的抽象。最后將活動 A抽象為資源，并分配 URI即 Http://orips3.com/W/{W_ID}/PDe/{PDe_ID}/A/{A_ID}，將 A_Task、A_Role、A_Data同樣抽象為資源，URI則按照層級規(guī)則放置在PDe之下，如A_Task的URI為Http://orips3.com/W/{W_ID}/PDe/{PDe_ID}/A/{A_ID}/A_Task。

R為流程定義中的邏輯節(jié)點(diǎn)抽象，可形式化表述為公式（3）

其中R_ID是邏輯節(jié)點(diǎn)的標(biāo)識，R_Rout是邏輯節(jié)點(diǎn)類型，Rout∈（Sequence,Choice,Fork,Merge,Synchronization），R_Rule存儲了邏輯節(jié)點(diǎn)的判斷規(guī)則，R_Data存儲了需要判斷的數(shù)據(jù)。R的 URI為 Http://orips3.com/W/{W_ID}/PDe/{PDe_ID}/R。

流程定義中的C是對流程中活動之間的關(guān)聯(lián)抽象，可形式化表述為公式（4）

其中C_Link存儲了節(jié)點(diǎn)間的連接關(guān)系。C_rule描述了連接關(guān)系需要遵循的規(guī)則，State記錄了流程的狀態(tài)，具體有Pre，Runing，Hang-up，Stop， Terminated五種值。

1.2 資源關(guān)系建模

傳統(tǒng)工作流引擎使用流程描述文檔存儲工作流要素之間的關(guān)系，資源化工作流引擎用資源元模型存儲。圖2中以流程定義以及其關(guān)聯(lián)資源為例，解釋了工作流中資源之間的關(guān)系以及其描述方式，具體的流程描述以一個流程定義的資源實(shí)例展示：

流程定義資源擁有ID、流程狀態(tài)、活動、活動鏈接和邏輯節(jié)點(diǎn)5個個屬性，后3個屬性在引擎中已經(jīng)被封裝為實(shí)體資源，因此該資源實(shí)例在描述后3個屬性時直接建立對這3個實(shí)體資源的引用鏈接，而活動節(jié)點(diǎn)資源會引用任務(wù)資源、角色資源和數(shù)據(jù)資源，任務(wù)資源又將引用需處理的Web服務(wù)。通過資源模型的層層引用，以及活動鏈接資源描述的節(jié)點(diǎn)順序關(guān)系，描述了流程所需的一切信息，為資源建立了符合層次和語義的資源關(guān)系體系。

1.3 方法資源

對于工作流引擎中的實(shí)體操作，HTTP協(xié)議中規(guī)定的接口能夠順利完成，但是對于一些需要多步操作的復(fù)雜功能，標(biāo)準(zhǔn)接口就不能支持。為了解決這個問題，采用了定義方法資源，并將操作步驟記錄在動作資源的屬性中，由解析器解析后逐步執(zhí)行的方式來解決問題的方式。

以掛起流程這個復(fù)雜操作作為范例闡述復(fù)雜資源的運(yùn)作方式，如圖3所示：

圖3 方法資源模型

掛起操作被封裝為一個方法資源，擁有 URI、參數(shù)和接口，參數(shù)中以偽代碼定義了掛起的幾個步驟以及涉及到的資源。在被訪問時，解析器讀取 Hug資源的參數(shù)，解析出對資源操作的多個步驟，然后按照順序調(diào)用先以訪問流程實(shí)例資源，獲取其狀態(tài)，判斷該狀態(tài)是否是RUNNING，如果是則繼續(xù)用PUT方法調(diào)用流程實(shí)例資源，修改狀態(tài)為HUG。

工作流引擎的其他操作也以同樣方式抽象為方法資源并通過解析器運(yùn)作，具體包括了流程的啟動、掛起、終止、恢復(fù)、完成任務(wù)等流程調(diào)度操作。

1.4 資源持久化

在定義完工作流引擎的所有資源后，最后一步便是將這些資源持久化到數(shù)據(jù)庫中。一個資源的持久化分為兩部分，第一是保存資源元模型，每個資源只有一份，以XML文檔形式存儲在數(shù)據(jù)庫中。第二是資源的數(shù)據(jù)持久化，每個資源匹配一張數(shù)據(jù)表，數(shù)據(jù)表的項(xiàng)與資源元模型的屬性一一對應(yīng)，每個資源可以創(chuàng)建無數(shù)條的數(shù)據(jù)，每條數(shù)據(jù)對應(yīng)一個資源實(shí)例。

獲取一個資源的持久化數(shù)據(jù)時，首先先查詢該資源匹配的數(shù)據(jù)表，然后查找到該資源的元模型，并按照對應(yīng)關(guān)系把數(shù)據(jù)的每一項(xiàng)填入元模型的屬性中，若該元模型有關(guān)聯(lián)其他資源，則會抽取多個相關(guān)數(shù)據(jù)表的數(shù)據(jù)，填入各自對應(yīng)的元模型中，最終組成一個大的實(shí)例模型作為該資源的持久化數(shù)據(jù)。

2 REST服務(wù)封裝

2.1 接口封裝

按照 RESTful風(fēng)格，將所有接口和訪問方法限制在HTTP規(guī)范中，所有資源的擁有統(tǒng)一的接口，URI也按照統(tǒng)一層級定義了描述規(guī)范，外界通過URI以及HTTP標(biāo)準(zhǔn)接口對封裝好的工作流引擎服務(wù)進(jìn)行操作。

接口封裝定義的重點(diǎn)在于對關(guān)聯(lián)資源的接口關(guān)系處理，以及對方法資源接口的處理。以流程定義和其關(guān)聯(lián)資源為例展示了關(guān)聯(lián)接口的運(yùn)作方式，如圖4所示：

圖4 關(guān)聯(lián)接口模型

當(dāng)流程定義資源接到GET訪問時，解析器會查詢流程定義的資源元模型，獲取其中對于關(guān)聯(lián)資源的描述，根據(jù)描述中關(guān)聯(lián)資源的 URI以及關(guān)系信息，解析器會將其分解為多步操作，分別訪問其他資源的接口，最后將獲取到的信息打包并返回流程定義資源。而對于方法接口則以圖3為例，由解析器讀取方法資源中的動作描述，同樣分解為多步操作并調(diào)用相關(guān)資源，最終將信息打包返回方法資源。封裝好REST接口后，通過元模型的描述以及接口定義，以REST框架建立 WADL并對資源化的工作流引擎進(jìn)行描述和發(fā)布。

2.2 資源解析器

資源解析器負(fù)責(zé)對 URI、資源關(guān)聯(lián)、方法資源進(jìn)行解析，并調(diào)用核心引擎進(jìn)行實(shí)際處理，是REST服務(wù)接口與后臺之間的連接器。

資源解析器能夠讀取所有的資源模型并對其進(jìn)行解析。在圖3和圖4有所提及資源解析器的運(yùn)作方式，當(dāng)外界訪問某個資源的 URI以及接口時，由資源解析器讀取該資源的元模型，然后判斷該資源類型，如果是方法資源，則解析元模型中的命令，分多步反應(yīng)到后臺核心引擎進(jìn)行操作。如果是實(shí)體資源則讀取與其相關(guān)聯(lián)的其他資源，并解析為多個命令反應(yīng)到核心引擎。

另外，資源解析器擁有一張注冊表，里面記錄了 URI與后臺操作模塊的對應(yīng)關(guān)系，當(dāng)外界訪問資源接口時，由資源解析器調(diào)用后臺核心引擎進(jìn)行具體操作。

2.3 異構(gòu)信息轉(zhuǎn)換器

資源化工作流引擎主要針對Web端的應(yīng)用訪問，而此類應(yīng)用多為SOAP Web Service以及REST Web Service兩種格式，因此需要對傳輸?shù)男畔⑦M(jìn)行格式的判斷和轉(zhuǎn)換。

轉(zhuǎn)換器首先創(chuàng)建一個REST資源信息包，然后將SOAP服務(wù)的請求封裝，將其存儲在REST資源的屬性中，最后以REST資源信息包的形式發(fā)送至工作流引擎，與其進(jìn)行交互。而返回信息則是逆轉(zhuǎn)，將REST消息中的SOAP消息提取，并以SOAP消息格式發(fā)送至服務(wù)中，從而實(shí)現(xiàn)了工作流引擎對不同格式服務(wù)的調(diào)用。

2.4 核心引擎

核心引擎負(fù)責(zé)實(shí)現(xiàn)流程調(diào)度、服務(wù)調(diào)度、數(shù)據(jù)持久化等核心功能，一切訪問在經(jīng)過資源解析器的解析后都在核心引擎中運(yùn)行。這里以啟動流程這個方法資源的運(yùn)行過程來展示核心引擎的功能。

資源解析器解析啟動流程這個方法資源后，列出 4個操作步驟，分別為查詢流程、修改流程狀態(tài)、獲取流程起始活動、獲取活動中任務(wù)與角色并分配。核心引擎被調(diào)用后，首先查詢流程資源的持久化表格，找到需要啟動的流程資源數(shù)據(jù)，修改流程狀態(tài)數(shù)據(jù)為運(yùn)行，然后根據(jù)流程資源所引用的活動連接資源找到起始節(jié)點(diǎn)，根據(jù)活動資源中引用的任務(wù)資源、數(shù)據(jù)資源和角色資源找到數(shù)據(jù)庫中對應(yīng)的各表格，并取得其對于服務(wù)的引用地址、數(shù)據(jù)格式、對應(yīng)的角色數(shù)據(jù)。根據(jù)獲取的信息由核心引擎建立與服務(wù)的連接，將服務(wù)對應(yīng)的界面提供給角色進(jìn)行操作，將操作結(jié)果根據(jù)數(shù)據(jù)格式打包后發(fā)送至服務(wù)，從而完成流程的啟動過程。

3 系統(tǒng)實(shí)現(xiàn)與驗(yàn)證

3.1 系統(tǒng)實(shí)現(xiàn)

系統(tǒng)架構(gòu)，如圖5所示：

圖5 系統(tǒng)架構(gòu)

分為界面層、REST接口層、資源解析器、核心引擎、元模型庫和數(shù)據(jù)存儲層。用戶界面層采用HTML5和EXTJS搭建了流程設(shè)計(jì)器，具體包括了界面上的要素控件、控件拖拽、任務(wù)角色定義、資源導(dǎo)入界面以及將可視化流程編譯為XML文檔的流程轉(zhuǎn)換器。另外搭建了流程管理監(jiān)控工具，用于監(jiān)控流程運(yùn)行狀態(tài)以及控制流程調(diào)度。REST接口層和資源解析器中，搭建了HTTP服務(wù)器進(jìn)行消息的收發(fā)，建立了 URI注冊表和資源元模型庫為資源解析器提供支持，解析器負(fù)責(zé)訪問消息的解析以及通過 Spring框架調(diào)用核心引擎處理具體內(nèi)容。核心引擎負(fù)責(zé)實(shí)現(xiàn)流程、服務(wù)、數(shù)據(jù)的操作和調(diào)度，包括一個異構(gòu)服務(wù)消息轉(zhuǎn)換器。數(shù)據(jù)存儲層由XML文件管理和數(shù)據(jù)庫管理組成，XML文件管理負(fù)責(zé)存儲資源元模型，數(shù)據(jù)庫中存儲了資源匹配的數(shù)據(jù)表。

3.2 系統(tǒng)驗(yàn)證

將以較為典型的訂單創(chuàng)建流程為例，實(shí)現(xiàn)工作流要素的復(fù)用并調(diào)用Web服務(wù)完成流程的運(yùn)行。

假設(shè)用戶原有流程中已經(jīng)擁有訂單創(chuàng)建節(jié)點(diǎn)，現(xiàn)在需要新增成品庫房、零件清單、庫存清單、采購清單的管理。操作界面，如圖6所示：

圖6 流程設(shè)計(jì)器

用戶進(jìn)入流程設(shè)計(jì)器界面，打開資源導(dǎo)入窗口，此時前臺界面將訪問活動資源的 URI即 Http://www.orips3.com/W/PDe/A，解析器解析請求后將所有資源返回前臺。用戶選擇成品庫房資源、零件清單資源、庫存清單資源、采購清單資源導(dǎo)入流程中形成可視化控件，然后連接所有控件形成新的流程。核心引擎將創(chuàng)建該資源元模型并存儲為XML文檔。用戶啟動流程，則該方法資源被訪問，核心引擎解析流程信息找到訂單創(chuàng)建活動元模型并獲取待操作的Web服務(wù)引用和任務(wù)角色，然后將服務(wù)界面發(fā)送給用戶操作，核心引擎負(fù)責(zé)與服務(wù)的連接，若是SOAP服務(wù)則用異構(gòu)信息轉(zhuǎn)換器將報(bào)文包裝為REST格式。用戶完成任務(wù)后，該方法資源被訪問，核心引擎記錄流程進(jìn)度并將下一個任務(wù)服務(wù)發(fā)送給用戶，最終用戶完成所有任務(wù)，該流程資源實(shí)例改狀態(tài)為終止，如圖7所示：

圖7 流程監(jiān)控工具

通過流程管理監(jiān)控工具可查看流程運(yùn)行的各個步驟以及對應(yīng)的狀態(tài)，通過對監(jiān)控結(jié)果的查詢證明了流程在引擎中的順利運(yùn)行，確保資源化的工作流引擎達(dá)到了要求。

3.3 評估對比

在對資源化的工作流引擎與傳統(tǒng)工作流引擎進(jìn)行測試和對比之后，驗(yàn)證了資源化工作流引擎在云端部署與工作流資源復(fù)用時有著明顯優(yōu)勢，表1為傳統(tǒng)工作流引擎和資源化的工作流引擎的對比圖表，如表1所示：

表1 資源化工作流引擎與傳統(tǒng)引擎的對比

4 結(jié)論

針對企業(yè)對工作流復(fù)用的需求以及傳統(tǒng)工作流引擎對云端部署不適應(yīng)的問題，提出了一個面向資源架構(gòu)（ROA）的工作流引擎，該引擎能夠輕松在云端部署并提供服務(wù)，能夠靈活發(fā)布和復(fù)用工作流資源?；趯γ嫦蛸Y源架構(gòu)以及工作流結(jié)構(gòu)的研究，將工作流細(xì)分為眾多獨(dú)立模塊，將引擎中的工作流要素、操作、關(guān)聯(lián)抽象為資源，賦予其URI，并進(jìn)行元模型描述。然后以REST框架將所有資源封裝為一個服務(wù)，以統(tǒng)一接口對外提供調(diào)用，封裝后可以作為一個平臺為客戶提供工作流引擎服務(wù)，同時收集客戶定制的各種工作流要素并封裝為資源，形成資源庫以提供給客戶進(jìn)行復(fù)用。整個資源化的工作流引擎擁有很好的云環(huán)境適應(yīng)力，以及強(qiáng)大的工作流要素發(fā)布與復(fù)用的功能。

[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]王明微， 周競濤. 敬石開面向云制造的按需工作流任務(wù)分配方法, [J]計(jì)算機(jī)輔助設(shè)計(jì)與圖形學(xué)學(xué)報(bào), 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.