基于柔性業務流程的RESTful信息資源池研究和實現

王 帥，蔡鴻明

0 引言

對于每個企業來說，業務流程是最為核心的部分。隨著全球化經濟以及IT技術的不斷發展，企業的業務流程變得更靈活，更復雜。在企業將業務流程信息化的道路上有多個難題阻礙：如何實現柔性可配置的業務流程；業務流程的自動化部署與實施；如何訪問和管理業務流程涉及到的企業信息資源（數據庫表，結構化文檔等），如何集成其他信息平臺。

目前常見的解決方案主要是利用工作流引擎以及面向操作及流程組合的過程建模語言，如BPEL硬編碼實現。然而這種解決方案太過重量級，難于實現，耗時費力，缺乏靈活性，不適應流程經常動態改變的企業。另外隨著云計算時代的到來，這樣的系統缺乏擴展性和集成性，會使得企業信息化落于被動。工作流引擎作為系統訪問的中樞，難以處理大并發量的請求，會成為企業信息平臺的瓶頸，目前的分布式工作流引擎又沒有大規模的被實踐應用[1]。

為了能夠實現企業信息系統與異構平臺的集成，系統必須具有開放性，集成性，擁有統一的訪問與操作接口。目前主要有兩種解決方案：面向服務架構 SOA[2](Service Oriented Architecture)的 SOAP[3]服務(Simple Object Access Protocol)以及面向資源架構ROA (Resource Oriented Architecture)[4]的 REST[5]服務(REpresentational State Transfer)。相比面向操作的SOAP服務，面向資源的REST服務更適應以資源為中心的企業信息系統。因此資源池基于 RESTful理念實現。

在REST的流程實現方面，文章[6]提出了一種基于資源狀態的流程運行架構，通過對資源的狀態進行建模，利用狀態機實現資源的狀態轉換進而達到流程進行的目的。文章[7]提出了基于REST的BPEL流程建模語言，該文章通過BPEL for REST實現REST服務組合，然后利用服務組合來實現企業的業務流程運轉。在資源的運行與管理方面，文章[8]基于服務組合和WS-BPEL語言提出了一種重量級的柔性工作流解決方案。文章[9]通過基于企業基本信息單位的資源元模型構建了基于資源的集成系統平臺，該平臺利用工作流引擎將資源串聯成業務流程，并且使用了本體來定義和管理資源。

基于上述情況，本文提出了RESTful信息資源池。資源池以企業的流程為核心，以企業的信息資源為出發點，構建了一個能夠將企業流程自動信息化，資源實體化的中間件平臺。該平臺提供靈活的流程組合與拆分，能夠讓用戶實時的訪問與管理企業的業務流程及相應的信息資源，優化訪問請求并提供安全及事務保障。

1 RESTful信息資源池框架

資源池是企業業務流程以及信息資源的容器，負責它們整個生命周期的管理，如圖1所示：

圖1 資源池抽象架構

資源池在整個企業信息系統中所屬的層次。資源池屬于企業信息系統的中間件，它負責連接企業上層應用系統和底層數據庫，資源池將內部資源以REST服務的方式暴露給企業上層應用。

資源池的輸入是一些已經被業界采納為流程建模標準的語言（如BPMN, BPEL），通過流程轉換模塊，資源池將這些文件轉換為資源池可讀的格式文件。資源池根據這些文件的描述，在企業的數據庫中建立相應的表。

資源池中主要有兩類資源：流程資源以及業務實體資源。業務實體資源即與數據庫中的表對應，它是表的抽象，可以是表的一部分，也可能是由多個表通過關系（如包含，繼承）組合而成。資源間可以動態的進行組合和拆分，以達到多粒度的靈活性。流程資源是由一系列的實體資源組合而成，通過資源的狀態變化而相互連接，進而完成一整個業務流程。流程資源的核心是資源狀態表以及資源狀態機。資源狀態表記錄了資源所應有的狀態，狀態機則根據這些狀態判斷應該執行哪個子流程，應該接下來去操作哪些資源。資源池通過上述一整個步驟來實現業務流程的運轉。

為了應對企業業務流程的靈活性，資源池支持流程資源之間的組合與拆分，從而提供動態的業務流程控制。在下文中，將針對資源池中所含資源建模以及具體如何實現資源池上述特性進行展開。

2 資源池建模

2.1 業務實體資源元模型

實體資源是數據表的抽象。數據表包含了很多列來表現數據，數據表間可以通過諸如外鍵，一致性約束等方式建立與其他表的聯系，資源實現并擴展了這些特性。

定義1：資源(Resource)定義: Resource = (URI, RP, OS,RS, RR)

資源主要由以下元組組成，統一資源標識符 URI，資源屬性集RP，資源操作集OS，資源狀態集RS和資源關系集RR組成。

根據REST的理念，每一個資源都由一個唯一的URI（Uniform Resource Identifier）來表示，URI使得網絡可以通過特定的協議(如 HTTP, FTP)找到該資源并與它進行交互。對于外部訪問請求，無論是訪問業務實體資源還是流程資源，在資源池中資源的URI都是唯一的標識和入口。

定義 2：資源屬性(Resource Property)定義：RP =(ResID, ResType, ResourceProps, TableProps)

ResID是對資源URI的引用，是資源屬性的唯一標識。ResType 表明該資源的類型，如果 RestType = ‘Simple’,說明該資源是針對一個數據表的抽象。如果 ResType = ’Compound’，表明該資源是由多個數據表或者多個資源通過資源關系建立而成，屬于復合資源。資源屬性ResourceProps與表屬性TableProps屬于對應關系，一個資源屬性可以看成由一個或多個表屬性組成的視圖。例如：如果訂單Order表有一個TableProps叫做 price表明訂單的金額，在把訂單表抽象成訂單資源時，可以為訂單資源增加一個叫做Sum_Price的資源屬性，它表示Sum_Price = Sum (price in every Order Table)。

定義3：資源操作集OS（Resource Operation Set）

REST建立在 HTTP基礎架構之上，其利用了 HTTP本身的元語操作來完成自身的功能，例如HTTP中的GET,POST, PUT, DELETE表示對資源的增刪改查功能。OS定義了針對該資源可以實行哪些HTTP操作，從而為資源池的權限和訪問管理模塊提供支持。

定義4：資源狀態集RS（Resource Status Set）定義：RS = (Statuses, Rules)

資源狀態集規定了該資源都具有哪些狀態，RS是資源池管理資源，控制資源的核心，也是業務流程資源進行流程運轉判斷時最重要的依據。Rules描述了該資源狀態間的跳轉規則。資源狀態集的例子表示，如圖2所示：

圖2 資源狀態遷移

圖中左邊顯示了訂單資源的狀態遷移過程。訂單資源總夠有9種資源狀態，從一種資源狀態跳轉到另外一種資源狀態都需要一定的條件，例如從 Planned狀態跳轉到Approved狀態需要查看訂單資源中金額屬性是否大于一個閥指，如果大于則跳轉到Approved狀態，如果小于則跳轉回Validated狀態，重新進行修改。該狀態機與圖右方發票資源的狀態機產生聯動效果，例如當發票資源狀態為Declined時，訂單資源狀態立即被修改為Failed，狀態機的聯動使得資源狀態轉移有了更為合理和細致的約束。上述過程實際上是完成了一個業務流程的運轉。該運轉是通過資源池與資源狀態集的交互實現的。

這一系列的針對資源的狀態轉移，正是 REST的設計哲學和核心所在，也是REST與SOAP最大的區別，與SOAP的面向操作不同，REST是面向資源的設計框架，它利用資源的狀態以及WEB這一虛擬狀態機完成業務流程的實現。

2.2 資源關系建模

定義 5：資源關系(Resource Relations)定義：RRi =(RelationType, Resources)

資源關系 RR用于為資源間建立聯系。在關系型數據庫中，關系是通過外鍵建立的。關系數據庫中表之間的關系主要有3種：一對一，一對多，多對多。在資源池的實體資源這一層，抽象了這3種關系，隱藏了這3種關系的細節。

在資源池中，用戶只需要考慮資源，而無需考慮資源所涉及的數據表。針對關系數據庫中的這3種關系，資源池將其抽象為一種關系RelationType = ‘Has’。例如：數據庫中有3張表School, Student, Course。School與Student是一對多的關系，Student與Course是多對多的關系。如果讓用戶自己編碼實現，耗時費力，且不好理解。資源池能夠替用戶完成這些工作（比如創建表，創建外鍵，創建中間表）。用戶無需考慮學生表與課程表具有什么關系，在資源這一層中，用戶只需知道學生資源擁有很多課程資源，課程資源也擁有很多學生資源。這樣的關系處理是符合人類語義的，更容易被理解。資源池將資源對應表的實現細節向用戶隱藏了。當用戶向資源池請求一個學校資源時，資源池會返回給用戶一個大粒度的信息資源，其中包含了該學校的數據，該學校包含的學生資源，各個學生資源擁有的課程資源。這樣的處理方式，尤其適合WEB前臺應用，返回的數據格式已經包含了數據關系，前臺就能根據數據所描述的關系，按層級展現前臺頁面。

資源池提供另外一種關系類型-繼承關系，RelationType = ‘Inheritance’。這種資源關系用于當資源是另一個資源的擴展時。例如“學生詳細信息”資源屬于“學生信息”的擴展，此時前者是后者的繼承資源。

2.3 業務流程資源元模型

業務流程資源屬于資源池的最核心資源，資源池通過流程資源實現業務流程的執行，動態組合與拆分。

定義6：流程資源(Process Resource)定義：PRi = (URI,ResourceList, StatusTransferTable)

流程資源也有一個唯一的URI作為標識，啟動或者更改一個流程就像訪問常見的REST資源一樣，它由多個業務實體資源聯合而成，StatusTransferTable中存儲了各個資源狀態轉換的順序以及規則。抽象實現，如圖3所示：

圖3 業務流程資源

Resource P是一個流程資源，它包含兩個業務實體資源R，S。當向該業務流程資源發送Get請求時，實際上執行了一個業務流程：首先調用資源R的PUT操作，當結果返回后再執行資源S的GET操作。這樣的表示方法將業務流程資源與業務實體資源聯系起來，形成了完整的順序流程。

上述實現例子只是業務流程資源的抽象實現，實際應用中還會涉及每個資源狀態的遷移等細節，將在下一章節具體展開。

2.4 資源管理數據

定義7：資源管理數據(Resource Management Data)

定義：RMDi = (Resource, CreateTime, LastOperateTime,AcessCount, RespondTime, LockType)

資源管理數據主要用于對資源的運行狀態進行記錄以方便資源池進行動態的管理。每條資源管理數據對應于一個資源，包括了資源的創建時間、上次操作的時間、訪問量、平均響應時間和資源鎖的類型。

資源池運用一些算法來實現對資源訪問的優化和管理，例如當上次操作時間-資源創建時間大于一個閥值后，表明該資源處于長期閑置狀態，資源池將會把該資源回收。當某資源訪問量過大，且響應時間過長時，資源池將會復制一個該資源，將請求分發到復制的該資源，以減輕原資源的訪問壓力。這樣的設計將有助于資源池的分布式部署實施，更適應云計算的大并發量要求。

3 資源池核心實現

資源池整個架構參照RESTful的理念進行設計，以資源為中心，對資源進行統一的動態配置與管理。具體實現架構，如圖4所示：

圖4 資源池實現架構

當用戶的HTTP請求發送到資源池，將經過資源池多個模塊的分析與處理，最終生成HTTP響應發還給用戶。

資源池中資源的控制，訪問，管理和業務流程資源的運轉主要是通過“資源訪問模塊”與“資源管理模塊”的交互實現的。資源訪問模塊主要包含兩個模塊：資源查找模塊和資源操作模塊。在進行資源查找時資源查找模塊會從資源關系庫中找出該資源所屬關系，如果該資源是個大粒度的資源，即包含了多個資源以及資源間的關系，該模塊將會從下一層的數據庫訪問模塊中得到多個資源的數據并進行整合。

資源管理模塊是資源池實現架構中的核心，主要包含4個模塊：資源關系庫、資源狀態表、訪問請求隊列和資源規則引擎。資源關系庫存儲了資源間的關系，資源狀態表存儲了每個資源所擁有的狀態，以及狀態之間的遷移規則。訪問請求隊列主要用于進行訪問控制，當某個資源訪問量過大時，請求會被放入該隊列等待執行。資源規則引擎模塊包含了每個業務流程資源執行的順序，資源間進行狀態轉換的規則，資源池通過該模塊實現業務流程的執行與控制。

3.1 資源池靜態映射模塊的實現

在資源池中，每一個業務實體資源都會與數據庫中的一張主表對應，資源”SchoolWithRelations”與表”School”對應，如圖5所示：

圖5 業務實體資源

屬性”isCompound”為真表明該資源是一個復合資源包含了與其他資源的關系。每一個屬性”property”都與表中的一列相對應。標簽”relations”說明該資源與另一個名為”StudentWithRelations”的資源存在叫做”has”的關系，語義上說明該學校資源擁有很多學生資源。

具體的資源搜索與發現算法如下，該算法是一個遞歸算法。

3.2 資源池動態管理模塊的實現

動態管理模塊主要分為兩部分：資源運行時管理和業務流程資源控制。

對于資源運行時管理的實現，本文定義了六種資源運行狀態：created, runnable, waited, deleted, aggregated, separated.前4種是最基本的資源生命周期狀態分別對應：創建，運行，等待，刪除。后兩種狀態用于資源池動態的進行實體資源粒度控制。資源池通過與日志記錄模塊的交互，會定期檢查哪些資源會經常被一同調用，并分析這些資源間的關系，如果發現資源間存在包含關系，便會將資源狀態轉變為aggregated，動態管理模塊發現為 aggregated狀態的多個資源，便會將它們按照關系組裝起來，形成一個更大粒度的資源。同理 separated狀態是用于分解大粒度的資源。通過這樣的方式，資源池實現了動態的，智能的資源粒度控制。

對于業務流程資源控制，資源池通過資源狀態遷移以及規則引擎的協同來實現。具體的業務流程資源描述模板，如圖6所示：

圖6 業務流程資源模板

該模板描述了對流程資源的每一個操作（Get, Put,Delete, Post）都會涉及到哪些其他的實體資源，執行實體資源的哪些操作和執行順序。

業務規則庫中存儲的是對每個業務流程資源的狀態轉換的規則。例如：

當用戶向流程資源”BookingOrder”發送一個GET請求時，資源管理模塊首先查看該流程資源的描述文件，讀取出onGet中的執行步驟，然后依次執行。執行一步之后，會根據資源返回的狀態從業務規則庫中判斷下一步可選的步驟。資源的返回信息，如圖7所示：

圖7 資源返回信息

返回的信息顯示，該資源的目前狀態為”created”，業務規則庫中返回的可選步驟如下：”Validate Order”代表檢查該訂單，”Cancel Order”代表取消訂單，”Reject Order”代表拒絕訂單。每一個可選步驟都跟隨一個代表該步驟的 URI鏈接，用戶通過訪問不同的 URI來實現流程的執行以及資源狀態的切換。

上述基于資源狀態遷移的流程轉換正是 REST的核心設計理念，不同于重量級的工作流引擎，資源池通過資源狀態表與輕量級的業務規則引擎的結合實現了業務流程的運行，由于它不像工作流引擎需要維護大量的狀態信息和流程實例，因此資源池能承受的訪問并發量比工作流引擎多。基于資源的 RESTful的設計理念也更適應于分布式的部署和云計算環境[10]。

4 實現驗證

本章節將通過某貨運公司信息系統的實例來說明資源池如何使用以及如何作為中間件為上層系統服務。

以下是該貨運公司的基本情況：

該公司之前的業務流程是通過Web Service + 工作流引擎硬編碼實現的，但由于貨運行業的特殊性，該公司業務流程經常變動，一經變動，就需要重新修改源代碼。

該公司已經通過多視圖建模的方法，為企業的流程和信息資源建立了模型文件。

該公司需要經常添加新流程以適應業務需求。

為了便于集成，應用系統對其他模塊部件的訪問都是通過Web Service的方式。

基于上述情況，該公司現在需要一個輕量級的，易于使用部署的中間件平臺，能夠連接底層數據庫與上層應用系統，并提供流程支持。該中間件平臺能夠支持動態的流程變動，減少IT人員二次編碼的工作量。

該平臺需要能夠承受大并發量的訪問，能夠進行動態的流程和數據監控與管理。

步驟一：將多視圖建模的模型文件導入資源池

資源池的輸入是一些業界標準的業務建模模型，這其中多視圖建模模型最適合于轉化為面向資源的RESTful架構，因為多視圖建模包含的建模對象最為全面，包括領域實體模型，基于狀態的信息資源模型和業務流程模型。流程分析與轉換器將會解析這些模型。資源池根據領域實體模型及實體關系生成數據庫表及外鍵關聯。解析信息資源模型和業務流程模型，解析后的輸出是針對每個實體資源的資源狀態表，每個業務流程模型都會生成一個對應的業務流程資源，其中包含了業務流程執行順序及業務規則語句。

經過步驟一后，資源池中已經存在了多種業務實體資源和業務流程資源，并且這些資源都能夠通過REST的方式進行訪問。資源池現在已經可以為上層應用提供服務。

步驟二：上層應用系統與資源池的交互

以實際托運貨物業務流程為例,該流程主要包含以下步驟：用戶填寫托運貨物信息->貨運公司審核訂單->司機填寫運送單->收件人填寫收貨單。流程圖，上層系統應用界面和執行順序，如圖8所示：

圖8 資源池與上層系統交互

上層系統首先發送一個HTTP Get請求到該業務流程資源的 URI: http://localhost:8080/cargocompany/carryprocess。當資源池收到這個GET請求后，查看該業務流程資源的規則描述，返回一個新的貨物資源給系統。上層系統便得知第一步是要填寫貨物信息并將填寫后的貨物信息 Post回給資源池，此時第一步完成，貨物資源的狀態修改為 created。資源池收到請求，再次查看狀態遷移規則描述，下一步指向訂單資源。第二步返回訂單資源給系統，由貨運公司來更改訂單的狀態，這時規則引擎產生作用，它有如下語句：if(order.permitted == true)goto validated; else goto canceled;這條語句的作用是檢查訂單的審核屬性是否為真，如果為真，訂單審核批準，如果為假，訂單取消，流程結束。

從上述步驟可以看出，資源池與上層應用系統的交互都是通過REST的方式，上層應用系統并不知道自己正在使用一個流程，應用系統所要做的只是通過 URI訪問資源，根據資源的HTTP響應，繼續通過下一個URI訪問另外的資源。這一系列資源訪問的過程實際就是一個業務流程。

步驟三：資源配置與監控管理

資源池中的業務實體資源和業務流程資源可以在運行時動態的修改。用戶可以動態的配置資源間的關系。由于資源池業務流程的執行是通過資源的狀態遷移完成的，因此對于流程更改，流程拆分和合并，只需要修改相應流程資源的狀態表和規則描述，即可完成運行時的動態改變。資源池資源監控和管理界面如圖9所示：

圖9 資源管理

本章最后給出了資源池與傳統中間件解決方案的整體比較，如表1所示：

表1 中間件解決方案比較

5 結論

本文提出了一種自動化的基于資源的柔性業務流程解決方案，該方案不同于普通工作流引擎的重量級實現，采用了資源狀態遷移與規則引擎協作的輕量級方法實現業務流程的執行與管理。首先從面向資源及資源狀態的視角對業務流程及其相關實體進行了建模。其次基于該模型提出了資源池的整體實現架構，并詳細闡述了涉及到的核心算法與設計思路。最后使用了一個實際案例來驗證資源池的可行性，并將資源池與普通的中間件解決方案做了詳細對比。結果表明資源池通過自動化實現的方式提升了效率，資源池提供的柔性業務流程運行和管理環境能夠滿足企業流程頻繁改變的需求。

[1]Jian Cao, Haiyan Zhao, Minglu Li. A Fuzzy Rule Based Load Balancing Model for a Distributed Service Process Engine. [C]Grid and Pervasive Computing Workshops,2008.

[2]Gottschalk, K. Graham, S. Kreger, H. and Snell. J. Introduction to Web services architecture. [J]IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002.

[3]Martin Gudgin, Marc Hadley, Noah Mendelsohn,Jean-Jacques Moreau. Simple Object Access protocal 1.2.[G]W3C Recommendation. 27 April 2007.

[4]Overdick, H.Hasso Plattner Inst for IT Syst. Eng., Potsdam. The Resource-Oriented Architecture. Services, [J]2007 IEEE Congress. 9-13 July 2007.

[5]Roy T. Fielding. Architectural styles and the design of network-based software architectures. PhD thesis, [M]Dept. of Information and Computer Science, Universityof California, Irvine, 2000.

[6]Kumaran, S. Rong Liu; Dhoolia, P.; Heath, T.; Nandi, P.;Pinel, F. A RESTful Architecture for Service-Oriented Business Process Execution. [J]E-Business Engineering,2008. ICEBE ’08.

[7]Cesare Pautasso. RESTful Web service composition with BPEL for REST. [M]Data&Knowledge Engineering,Sep. 2009.

[8]Weske. M Business Process Management Architectures.[M]Business Process Management Springer, 2012.

[9]Hongming Cai, Dominik Englert, HaoYu. ORIPS: An Open Resource-based Integrated Platform System for business process execution. [J]IEEE International Conference on Systems, Man, and Cybernetics, 2009.

[10]Al-Zoubi, K; Wainer, G. Performing distributed simulation with RESTful Web-services. Simulation Conference,[C]Proceedings of the 2009 Winter.