基于REST風格的資源化工作流引擎的研究.

謝凌奇，姜麗紅，蔡鴻明

0 引言

工作流引擎是企業(yè)將其分散的應用連接并整合成一個完整流程應用的調度工具。隨著云應用普及以及企業(yè)流程的愈加復雜化，企業(yè)不但需要能夠復用的云應用，還需要能夠復用的工作流，也就是說企業(yè)需要一個能夠部署在云端，能夠將工作流要素封裝好并提供給客戶使用，并能夠與云端應用順利交互的工作流引擎。

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

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

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

1 工作流引擎的資源抽象

一個工作流引擎的實現(xiàn)分為流程設計、流程管理、應用調用和部署4個部分，如圖1所示：

圖1 資源化引擎設計框架

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

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

1.1 工作流建模與實體資源抽象

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

圖2 資源模型

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

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

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

其中A_ID為活動的標識，A_Task為該活動需完成的任務的抽象，包含了指向待操作的Web服務的鏈接。A_Role是該活動中被分配任務的角色的抽象，A_Data是該任務將要處理的數(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é)點抽象，可形式化表述為公式（3）

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

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

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

1.2 資源關系建模

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

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

1.3 方法資源

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

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

圖3 方法資源模型

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

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

1.4 資源持久化

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

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

2 REST服務封裝

2.1 接口封裝

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

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

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

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

2.2 資源解析器

資源解析器負責對 URI、資源關聯(lián)、方法資源進行解析，并調用核心引擎進行實際處理，是REST服務接口與后臺之間的連接器。

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

另外，資源解析器擁有一張注冊表，里面記錄了 URI與后臺操作模塊的對應關系，當外界訪問資源接口時，由資源解析器調用后臺核心引擎進行具體操作。

2.3 異構信息轉換器

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

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

2.4 核心引擎

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

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

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

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

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

圖5 系統(tǒng)架構

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

3.2 系統(tǒng)驗證

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

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

圖6 流程設計器

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

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

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

3.3 評估對比

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

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

4 結論

針對企業(yè)對工作流復用的需求以及傳統(tǒng)工作流引擎對云端部署不適應的問題，提出了一個面向資源架構（ROA）的工作流引擎，該引擎能夠輕松在云端部署并提供服務，能夠靈活發(fā)布和復用工作流資源。基于對面向資源架構以及工作流結構的研究，將工作流細分為眾多獨立模塊，將引擎中的工作流要素、操作、關聯(lián)抽象為資源，賦予其URI，并進行元模型描述。然后以REST框架將所有資源封裝為一個服務，以統(tǒng)一接口對外提供調用，封裝后可以作為一個平臺為客戶提供工作流引擎服務，同時收集客戶定制的各種工作流要素并封裝為資源，形成資源庫以提供給客戶進行復用。整個資源化的工作流引擎擁有很好的云環(huán)境適應力，以及強大的工作流要素發(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]王明微， 周競濤. 敬石開面向云制造的按需工作流任務分配方法, [J]計算機輔助設計與圖形學學報, 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.