基于柔性業(yè)務(wù)流程的RESTful信息資源池研究和實(shí)現(xiàn)

王 帥，蔡鴻明

0 引言

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

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

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

在REST的流程實(shí)現(xiàn)方面，文章[6]提出了一種基于資源狀態(tài)的流程運(yùn)行架構(gòu)，通過對資源的狀態(tài)進(jìn)行建模，利用狀態(tài)機(jī)實(shí)現(xiàn)資源的狀態(tài)轉(zhuǎn)換進(jìn)而達(dá)到流程進(jìn)行的目的。文章[7]提出了基于REST的BPEL流程建模語言，該文章通過BPEL for REST實(shí)現(xiàn)REST服務(wù)組合，然后利用服務(wù)組合來實(shí)現(xiàn)企業(yè)的業(yè)務(wù)流程運(yùn)轉(zhuǎn)。在資源的運(yùn)行與管理方面，文章[8]基于服務(wù)組合和WS-BPEL語言提出了一種重量級的柔性工作流解決方案。文章[9]通過基于企業(yè)基本信息單位的資源元模型構(gòu)建了基于資源的集成系統(tǒng)平臺，該平臺利用工作流引擎將資源串聯(lián)成業(yè)務(wù)流程，并且使用了本體來定義和管理資源。

基于上述情況，本文提出了RESTful信息資源池。資源池以企業(yè)的流程為核心，以企業(yè)的信息資源為出發(fā)點(diǎn)，構(gòu)建了一個(gè)能夠?qū)⑵髽I(yè)流程自動信息化，資源實(shí)體化的中間件平臺。該平臺提供靈活的流程組合與拆分，能夠讓用戶實(shí)時(shí)的訪問與管理企業(yè)的業(yè)務(wù)流程及相應(yīng)的信息資源，優(yōu)化訪問請求并提供安全及事務(wù)保障。

1 RESTful信息資源池框架

資源池是企業(yè)業(yè)務(wù)流程以及信息資源的容器，負(fù)責(zé)它們整個(gè)生命周期的管理，如圖1所示：

圖1 資源池抽象架構(gòu)

資源池在整個(gè)企業(yè)信息系統(tǒng)中所屬的層次。資源池屬于企業(yè)信息系統(tǒng)的中間件，它負(fù)責(zé)連接企業(yè)上層應(yīng)用系統(tǒng)和底層數(shù)據(jù)庫，資源池將內(nèi)部資源以REST服務(wù)的方式暴露給企業(yè)上層應(yīng)用。

資源池的輸入是一些已經(jīng)被業(yè)界采納為流程建模標(biāo)準(zhǔn)的語言（如BPMN, BPEL），通過流程轉(zhuǎn)換模塊，資源池將這些文件轉(zhuǎn)換為資源池可讀的格式文件。資源池根據(jù)這些文件的描述，在企業(yè)的數(shù)據(jù)庫中建立相應(yīng)的表。

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

為了應(yīng)對企業(yè)業(yè)務(wù)流程的靈活性，資源池支持流程資源之間的組合與拆分，從而提供動態(tài)的業(yè)務(wù)流程控制。在下文中，將針對資源池中所含資源建模以及具體如何實(shí)現(xiàn)資源池上述特性進(jìn)行展開。

2 資源池建模

2.1 業(yè)務(wù)實(shí)體資源元模型

實(shí)體資源是數(shù)據(jù)表的抽象。數(shù)據(jù)表包含了很多列來表現(xiàn)數(shù)據(jù)，數(shù)據(jù)表間可以通過諸如外鍵，一致性約束等方式建立與其他表的聯(lián)系，資源實(shí)現(xiàn)并擴(kuò)展了這些特性。

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

資源主要由以下元組組成，統(tǒng)一資源標(biāo)識符 URI，資源屬性集RP，資源操作集OS，資源狀態(tài)集RS和資源關(guān)系集RR組成。

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

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

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

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

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

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

資源狀態(tài)集規(guī)定了該資源都具有哪些狀態(tài)，RS是資源池管理資源，控制資源的核心，也是業(yè)務(wù)流程資源進(jìn)行流程運(yùn)轉(zhuǎn)判斷時(shí)最重要的依據(jù)。Rules描述了該資源狀態(tài)間的跳轉(zhuǎn)規(guī)則。資源狀態(tài)集的例子表示，如圖2所示：

圖2 資源狀態(tài)遷移

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

這一系列的針對資源的狀態(tài)轉(zhuǎn)移，正是 REST的設(shè)計(jì)哲學(xué)和核心所在，也是REST與SOAP最大的區(qū)別，與SOAP的面向操作不同，REST是面向資源的設(shè)計(jì)框架，它利用資源的狀態(tài)以及WEB這一虛擬狀態(tài)機(jī)完成業(yè)務(wù)流程的實(shí)現(xiàn)。

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

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

資源關(guān)系 RR用于為資源間建立聯(lián)系。在關(guān)系型數(shù)據(jù)庫中，關(guān)系是通過外鍵建立的。關(guān)系數(shù)據(jù)庫中表之間的關(guān)系主要有3種：一對一，一對多，多對多。在資源池的實(shí)體資源這一層，抽象了這3種關(guān)系，隱藏了這3種關(guān)系的細(xì)節(jié)。

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

資源池提供另外一種關(guān)系類型-繼承關(guān)系，RelationType = ‘Inheritance’。這種資源關(guān)系用于當(dāng)資源是另一個(gè)資源的擴(kuò)展時(shí)。例如“學(xué)生詳細(xì)信息”資源屬于“學(xué)生信息”的擴(kuò)展，此時(shí)前者是后者的繼承資源。

2.3 業(yè)務(wù)流程資源元模型

業(yè)務(wù)流程資源屬于資源池的最核心資源，資源池通過流程資源實(shí)現(xiàn)業(yè)務(wù)流程的執(zhí)行，動態(tài)組合與拆分。

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

流程資源也有一個(gè)唯一的URI作為標(biāo)識，啟動或者更改一個(gè)流程就像訪問常見的REST資源一樣，它由多個(gè)業(yè)務(wù)實(shí)體資源聯(lián)合而成，StatusTransferTable中存儲了各個(gè)資源狀態(tài)轉(zhuǎn)換的順序以及規(guī)則。抽象實(shí)現(xiàn)，如圖3所示：

圖3 業(yè)務(wù)流程資源

Resource P是一個(gè)流程資源，它包含兩個(gè)業(yè)務(wù)實(shí)體資源R，S。當(dāng)向該業(yè)務(wù)流程資源發(fā)送Get請求時(shí)，實(shí)際上執(zhí)行了一個(gè)業(yè)務(wù)流程：首先調(diào)用資源R的PUT操作，當(dāng)結(jié)果返回后再執(zhí)行資源S的GET操作。這樣的表示方法將業(yè)務(wù)流程資源與業(yè)務(wù)實(shí)體資源聯(lián)系起來，形成了完整的順序流程。

上述實(shí)現(xiàn)例子只是業(yè)務(wù)流程資源的抽象實(shí)現(xiàn)，實(shí)際應(yīng)用中還會涉及每個(gè)資源狀態(tài)的遷移等細(xì)節(jié)，將在下一章節(jié)具體展開。

2.4 資源管理數(shù)據(jù)

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

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

資源管理數(shù)據(jù)主要用于對資源的運(yùn)行狀態(tài)進(jìn)行記錄以方便資源池進(jìn)行動態(tài)的管理。每條資源管理數(shù)據(jù)對應(yīng)于一個(gè)資源，包括了資源的創(chuàng)建時(shí)間、上次操作的時(shí)間、訪問量、平均響應(yīng)時(shí)間和資源鎖的類型。

資源池運(yùn)用一些算法來實(shí)現(xiàn)對資源訪問的優(yōu)化和管理，例如當(dāng)上次操作時(shí)間-資源創(chuàng)建時(shí)間大于一個(gè)閥值后，表明該資源處于長期閑置狀態(tài)，資源池將會把該資源回收。當(dāng)某資源訪問量過大，且響應(yīng)時(shí)間過長時(shí)，資源池將會復(fù)制一個(gè)該資源，將請求分發(fā)到復(fù)制的該資源，以減輕原資源的訪問壓力。這樣的設(shè)計(jì)將有助于資源池的分布式部署實(shí)施，更適應(yīng)云計(jì)算的大并發(fā)量要求。

3 資源池核心實(shí)現(xiàn)

資源池整個(gè)架構(gòu)參照RESTful的理念進(jìn)行設(shè)計(jì)，以資源為中心，對資源進(jìn)行統(tǒng)一的動態(tài)配置與管理。具體實(shí)現(xiàn)架構(gòu)，如圖4所示：

圖4 資源池實(shí)現(xiàn)架構(gòu)

當(dāng)用戶的HTTP請求發(fā)送到資源池，將經(jīng)過資源池多個(gè)模塊的分析與處理，最終生成HTTP響應(yīng)發(fā)還給用戶。

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

資源管理模塊是資源池實(shí)現(xiàn)架構(gòu)中的核心，主要包含4個(gè)模塊：資源關(guān)系庫、資源狀態(tài)表、訪問請求隊(duì)列和資源規(guī)則引擎。資源關(guān)系庫存儲了資源間的關(guān)系，資源狀態(tài)表存儲了每個(gè)資源所擁有的狀態(tài)，以及狀態(tài)之間的遷移規(guī)則。訪問請求隊(duì)列主要用于進(jìn)行訪問控制，當(dāng)某個(gè)資源訪問量過大時(shí)，請求會被放入該隊(duì)列等待執(zhí)行。資源規(guī)則引擎模塊包含了每個(gè)業(yè)務(wù)流程資源執(zhí)行的順序，資源間進(jìn)行狀態(tài)轉(zhuǎn)換的規(guī)則，資源池通過該模塊實(shí)現(xiàn)業(yè)務(wù)流程的執(zhí)行與控制。

3.1 資源池靜態(tài)映射模塊的實(shí)現(xiàn)

在資源池中，每一個(gè)業(yè)務(wù)實(shí)體資源都會與數(shù)據(jù)庫中的一張主表對應(yīng)，資源”SchoolWithRelations”與表”School”對應(yīng)，如圖5所示：

圖5 業(yè)務(wù)實(shí)體資源

屬性”isCompound”為真表明該資源是一個(gè)復(fù)合資源包含了與其他資源的關(guān)系。每一個(gè)屬性”property”都與表中的一列相對應(yīng)。標(biāo)簽”relations”說明該資源與另一個(gè)名為”StudentWithRelations”的資源存在叫做”has”的關(guān)系，語義上說明該學(xué)校資源擁有很多學(xué)生資源。

具體的資源搜索與發(fā)現(xiàn)算法如下，該算法是一個(gè)遞歸算法。

3.2 資源池動態(tài)管理模塊的實(shí)現(xiàn)

動態(tài)管理模塊主要分為兩部分：資源運(yùn)行時(shí)管理和業(yè)務(wù)流程資源控制。

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

對于業(yè)務(wù)流程資源控制，資源池通過資源狀態(tài)遷移以及規(guī)則引擎的協(xié)同來實(shí)現(xiàn)。具體的業(yè)務(wù)流程資源描述模板，如圖6所示：

圖6 業(yè)務(wù)流程資源模板

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

業(yè)務(wù)規(guī)則庫中存儲的是對每個(gè)業(yè)務(wù)流程資源的狀態(tài)轉(zhuǎn)換的規(guī)則。例如：

當(dāng)用戶向流程資源”BookingOrder”發(fā)送一個(gè)GET請求時(shí)，資源管理模塊首先查看該流程資源的描述文件，讀取出onGet中的執(zhí)行步驟，然后依次執(zhí)行。執(zhí)行一步之后，會根據(jù)資源返回的狀態(tài)從業(yè)務(wù)規(guī)則庫中判斷下一步可選的步驟。資源的返回信息，如圖7所示：

圖7 資源返回信息

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

上述基于資源狀態(tài)遷移的流程轉(zhuǎn)換正是 REST的核心設(shè)計(jì)理念，不同于重量級的工作流引擎，資源池通過資源狀態(tài)表與輕量級的業(yè)務(wù)規(guī)則引擎的結(jié)合實(shí)現(xiàn)了業(yè)務(wù)流程的運(yùn)行，由于它不像工作流引擎需要維護(hù)大量的狀態(tài)信息和流程實(shí)例，因此資源池能承受的訪問并發(fā)量比工作流引擎多?；谫Y源的 RESTful的設(shè)計(jì)理念也更適應(yīng)于分布式的部署和云計(jì)算環(huán)境[10]。

4 實(shí)現(xiàn)驗(yàn)證

本章節(jié)將通過某貨運(yùn)公司信息系統(tǒng)的實(shí)例來說明資源池如何使用以及如何作為中間件為上層系統(tǒng)服務(wù)。

以下是該貨運(yùn)公司的基本情況：

該公司之前的業(yè)務(wù)流程是通過Web Service + 工作流引擎硬編碼實(shí)現(xiàn)的，但由于貨運(yùn)行業(yè)的特殊性，該公司業(yè)務(wù)流程經(jīng)常變動，一經(jīng)變動，就需要重新修改源代碼。

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

該公司需要經(jīng)常添加新流程以適應(yīng)業(yè)務(wù)需求。

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

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

該平臺需要能夠承受大并發(fā)量的訪問，能夠進(jìn)行動態(tài)的流程和數(shù)據(jù)監(jiān)控與管理。

步驟一：將多視圖建模的模型文件導(dǎo)入資源池

資源池的輸入是一些業(yè)界標(biāo)準(zhǔn)的業(yè)務(wù)建模模型，這其中多視圖建模模型最適合于轉(zhuǎn)化為面向資源的RESTful架構(gòu)，因?yàn)槎嘁晥D建模包含的建模對象最為全面，包括領(lǐng)域?qū)嶓w模型，基于狀態(tài)的信息資源模型和業(yè)務(wù)流程模型。流程分析與轉(zhuǎn)換器將會解析這些模型。資源池根據(jù)領(lǐng)域?qū)嶓w模型及實(shí)體關(guān)系生成數(shù)據(jù)庫表及外鍵關(guān)聯(lián)。解析信息資源模型和業(yè)務(wù)流程模型，解析后的輸出是針對每個(gè)實(shí)體資源的資源狀態(tài)表，每個(gè)業(yè)務(wù)流程模型都會生成一個(gè)對應(yīng)的業(yè)務(wù)流程資源，其中包含了業(yè)務(wù)流程執(zhí)行順序及業(yè)務(wù)規(guī)則語句。

經(jīng)過步驟一后，資源池中已經(jīng)存在了多種業(yè)務(wù)實(shí)體資源和業(yè)務(wù)流程資源，并且這些資源都能夠通過REST的方式進(jìn)行訪問。資源池現(xiàn)在已經(jīng)可以為上層應(yīng)用提供服務(wù)。

步驟二：上層應(yīng)用系統(tǒng)與資源池的交互

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

圖8 資源池與上層系統(tǒng)交互

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

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

步驟三：資源配置與監(jiān)控管理

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

圖9 資源管理

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

表1 中間件解決方案比較

5 結(jié)論

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

[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.