王　暢

（江蘇教育學院　運河分院，江蘇　邳州　221300）

SOA（Service Oriented Architecture）技術(shù)是近年來比較流行并且支持跨平臺的技術(shù)，互聯(lián)網(wǎng)技術(shù)的發(fā)展也在不斷為SOA提供支持，在眾多專家、學者和研究機構(gòu)的努力下，SOA技術(shù)不斷完善和發(fā)展，有著比較廣闊的前景和研究價值.

將SOA與傳統(tǒng)的工作流技術(shù)結(jié)合起來，能夠支持分布異構(gòu)環(huán)境下的服務使用者和服務提供者之間的交互，將這種交互變成與平臺無關(guān)、與環(huán)境無關(guān)，使信息、數(shù)據(jù)等資源實現(xiàn)共享變得更加簡單，有效地解決了企業(yè)“信息孤島”的問題，對跨企業(yè)、跨地域的業(yè)務流程管理、業(yè)務架構(gòu)提供了強大的支持[1].

于是，在這樣的背景下設計出了一種基于SOA的工作流管理系統(tǒng)，增加了Web服務接口，將業(yè)務活動封裝為Web服務，有效地克服了傳統(tǒng)工作流無法滿足動態(tài)業(yè)務活動組合和交互的缺陷.

1　系統(tǒng)的框架設計

1.1　設計目標

結(jié)合此前對SOA與工作流技術(shù)結(jié)合的可行性和優(yōu)越性的分析，充分發(fā)揮SOA架構(gòu)的優(yōu)勢，此工作流管理系統(tǒng)設計的目標主要表現(xiàn)在以下幾個方面：

（1）將原本系統(tǒng)內(nèi)或系統(tǒng)間相互獨立的功能封裝為Web服務，實現(xiàn)支持異構(gòu)環(huán)境下的業(yè)務集成.

（2）在分布、異構(gòu)環(huán)境下參與交互的各節(jié)點通過SOAP實現(xiàn)消息的傳遞，通過Web服務描述互相理解對方，并實現(xiàn)節(jié)點間的交互.

（3）將應用程序與服務相分離，利用已有的數(shù)據(jù)資源構(gòu)建各種服務，并利用BPEL技術(shù)對服務重新組合和連接，從而構(gòu)建出更為多樣、復雜的業(yè)務流程.

（4）能夠?qū)崿F(xiàn)統(tǒng)一的數(shù)據(jù)訪問，即通過規(guī)范統(tǒng)一的接口實現(xiàn)數(shù)據(jù)共享.這種訪問無需考慮各數(shù)據(jù)庫的內(nèi)部細節(jié)，對于各種異質(zhì)數(shù)據(jù)庫來說，仍然可以實現(xiàn)數(shù)據(jù)集成.

圖1　基于SOA的工作流管理系統(tǒng)的總體結(jié)構(gòu)

1.2　總體結(jié)構(gòu)

在SOA的體系結(jié)構(gòu)基礎(chǔ)之上，建立了如圖1所示的基于SOA的工作流管理系統(tǒng)的總體結(jié)構(gòu)，它較為詳細地呈現(xiàn)了不同層次內(nèi)部的構(gòu)件組成以及層與層之間的通信方式.

從圖中可以看出此系統(tǒng)結(jié)構(gòu)主要由基礎(chǔ)設施層、數(shù)據(jù)層、服務層、業(yè)務邏輯層和用戶界面（表現(xiàn)層）組成，下面對每一層次的組成構(gòu)件、功能和工作方式作簡要說明.

（1）基礎(chǔ)設施層.基礎(chǔ)設施層是系統(tǒng)能夠得以運行的基礎(chǔ)平臺.

（2）數(shù)據(jù)層.數(shù)據(jù)層主要包括數(shù)據(jù)源、數(shù)據(jù)的加工處理（ETL功能）、數(shù)據(jù)中轉(zhuǎn)區(qū)、數(shù)據(jù)倉庫等部分，主要完成對數(shù)據(jù)的管理.數(shù)據(jù)是從業(yè)務系統(tǒng)到數(shù)據(jù)集市（數(shù)據(jù)倉庫）流動，數(shù)據(jù)層是整個分析系統(tǒng)的基礎(chǔ).

（3）服務層.服務層由公共服務和業(yè)務服務組成，各種服務之間的互操作基于ESB標準.

（4）業(yè)務邏輯層.在業(yè)務處理層，用戶通過WSDL或者通過UDDI服務注冊中心獲取了Web服務描述之后，便可以通過SOAP發(fā)出服務請求，最后通過Web服務接口獲取所要調(diào)用的服務.

（5）表現(xiàn)層.表現(xiàn)層用于實現(xiàn)用戶與管理系統(tǒng)的交互，主要通過瀏覽器來獲取系統(tǒng)提供的各種服務，并且通過在Web頁面中嵌入Applet程序段或者腳本程序（JavaScript、Jscript）實現(xiàn)對前端邏輯的控制或者內(nèi)容的表現(xiàn).此外，除了請求和調(diào)用靜態(tài)的服務以外，也可以直接訪問UDDI服務注冊中心，從中調(diào)用所需要的某種服務.

2　模型設計

2.1　系統(tǒng)模型設計

經(jīng)過此前的分析，可以發(fā)現(xiàn)SOA與工作流相結(jié)合可以克服傳統(tǒng)工作流管理系統(tǒng)中出現(xiàn)的種種問題.圖2為一種SOA架構(gòu)下的工作流管理系統(tǒng)模型[2].

圖2　基于SOA的工作流管理系統(tǒng)模型

從圖2可以發(fā)現(xiàn)，與傳統(tǒng)的工作流管理系統(tǒng)相比，SOA架構(gòu)的工作流管理系統(tǒng)增加了Web服務接口、UDDI注冊中心[3]等，具備面向?qū)ο蟮奶匦?下面對此模型作簡要說明.

2.1.1Web服務接口

在此模型中，將Web服務接口加入在工作流執(zhí)行服務組件中，可以將工作流引擎封裝為Web Service，然后和其他工作流執(zhí)行服務中的工作流引擎進行交互[4]，保證多個工作流引擎協(xié)同執(zhí)行工作流實例.此外，在服務提供者組件中，也加入了Web服務接口，實例運行過程中需要調(diào)用的應用程序（包含異構(gòu)應用程序）都封裝成Web Service[5]，以供服務請求者直接調(diào)用.

2.1.2UDDI

英文全稱是Universal Description Discovery and Integration，可以譯為通用描述、發(fā)現(xiàn)與集成服務.通過UDDI注冊中心可以實現(xiàn)web服務的發(fā)布和實現(xiàn).對于一個Web服務調(diào)用者來說，一種方法是通過Web服務描述語言（WSDL）獲取例如函數(shù)接口、參數(shù)、返回值等Web服務信息；另一種方法就是通過UDDI注冊中心，從中獲取已注冊的相關(guān)Web服務信息[6].有了這些，才能夠構(gòu)造SOAP報文來調(diào)用該Web服務的某個函數(shù)接口.

2.1.3請求與響應

在SOA架構(gòu)下，一旦查找到了合適的服務，服務請求者與服務提供者之間的通訊，可以通過SOAP協(xié)議和XML建立和完成，以此實現(xiàn)二者之間的服務請求與響應.

2.2　引擎模型設計

作為SOA關(guān)鍵環(huán)節(jié)和系統(tǒng)核心的工作流引擎，負責對流程定義進行解釋并對流程的運轉(zhuǎn)加以控制.當某個流程實例被激活以后，一個或多個工作流引擎調(diào)用對應的Web服務，以實現(xiàn)業(yè)務伙伴間的數(shù)據(jù)、控制信息等方面的交互.SOA架構(gòu)下的參與交互的各工作流引擎被封裝為Web Service，具體的細節(jié)在其內(nèi)部實現(xiàn)，依靠對外提供的統(tǒng)一接口完成互操作，這種互操作可以是工作流引擎之間的互操作，也可以是工作流引擎與用戶之間的互操作，但不管是何種互操作，都基于SOAP的標準.

以WfMC工作流參考模型為標準，在傳統(tǒng)工作流引擎內(nèi)部結(jié)構(gòu)的基礎(chǔ)之上，設計了一種基于SOA的工作流引擎模型，它主要包括解析器、執(zhí)行器、異常處理器、動態(tài)服務代理器、客戶端接口等部件.此工作流引擎的模型框架如圖3所示.

圖3　基于SOA的工作流引擎模型框架

接下來對構(gòu)成基于SOA的工作流引擎模型框架的主要功能模塊作簡要說明.

2.2.1解析器

解析器的功能類似于Java語言中的編譯器和解釋器，在Java語言中，由編譯器將程序源代碼編譯為中間代碼，再由解釋器將中間代碼解釋為計算機可以直接識別的機器碼.而在此框架中，解析器的主要功能是讀取描述工作流流程的文本，并將其解析成能夠被工作流引擎直接執(zhí)行的模板對象.

此外，解析器的輸入對象除了工作流流程文件以外，還包括目標數(shù)據(jù)庫，此目標數(shù)據(jù)庫用來說明被工作流引擎解析而成的模板對象所應流向的流程定義庫，從而滿足工作流的需求.

2.2.2執(zhí)行器

執(zhí)行器是此工作流引擎的核心部件，主要負責對業(yè)務邏輯進行解析，通過與外部資源的交互，執(zhí)行具體的業(yè)務實例.可以發(fā)現(xiàn)，執(zhí)行器的執(zhí)行依賴于解析器解析生成的流程文件，同時還需要建立與外部資源的聯(lián)系[7].在業(yè)務活動執(zhí)行過程中，通過日志管理的方法監(jiān)控和記錄執(zhí)行步驟.當某一項業(yè)務活動執(zhí)行完畢以后，再根據(jù)業(yè)務規(guī)則選擇合適的路由.

2.2.3動態(tài)服務代理器

動態(tài)服務處理器的主要作用是查找服務和調(diào)用服務.在具體的業(yè)務執(zhí)行過程中，需要查找相應的Web服務，然后在查找成功的基礎(chǔ)上，由工作流引擎對其進行解析、調(diào)用.

在SOA的體系結(jié)構(gòu)下，工作流引擎對服務的綁定和調(diào)用分為靜態(tài)和動態(tài)兩種方式.在靜態(tài)綁定的方式下，工作流引擎直接對所需服務進行解析和執(zhí)行；在動態(tài)綁定的方式下，由動態(tài)服務代理器根據(jù)Web服務描述信息，形成相應的SOAP請求信息.

2.2.4異常處理器

異常處理器的存在主要是對業(yè)務流程的執(zhí)行過程中出現(xiàn)的系統(tǒng)異常、任務異常進行容錯處理或補償和恢復操作，以保證業(yè)務流程能夠順利、正常地運轉(zhuǎn).

2.2.5客戶端接口

借助客戶端接口可以實現(xiàn)與工作流引擎進行相應的數(shù)據(jù)交換，借助監(jiān)控管理工具對工作流管理系統(tǒng)中的相關(guān)數(shù)據(jù)進行管理，并監(jiān)控業(yè)務流程的執(zhí)行，根據(jù)流程運轉(zhuǎn)的情況或運行過程中出現(xiàn)的問題做出掛起、停止、恢復等命令.

3　業(yè)務流程與信息集成

3.1　基于SOA的工作流管理系統(tǒng)的集成方案

Web Service作為一個抽象層，位于傳輸層與應用層之間，將功能的實現(xiàn)細節(jié)隱藏在其內(nèi)部，為分布、異構(gòu)環(huán)境下工作流管理系統(tǒng)的業(yè)務集成搭建了良好的技術(shù)平臺.圖4對SOA架構(gòu)下的工作流管理系統(tǒng)的集成方案[8]做出了描述.

圖4　基于SOA的工作流管理系統(tǒng)的集成

辦公自動化水平的提高已經(jīng)使企業(yè)之間的業(yè)務集成不僅僅單純地表現(xiàn)在數(shù)據(jù)交換這一層面了，這種交互已經(jīng)擴展到了更為復雜的文檔，在異構(gòu)系統(tǒng)的環(huán)境下，很難實現(xiàn)這種復雜文檔的無縫集成.因此在異構(gòu)系統(tǒng)之間加入了綁定在HTTP等傳輸協(xié)議之上的SOAP協(xié)議，以XML文檔的形式在應用系統(tǒng)間進行傳輸，實現(xiàn)了系統(tǒng)平臺的無關(guān)性，保證了異構(gòu)系統(tǒng)間的業(yè)務集成.

3.2　服務之間的互操作模式

企業(yè)間的業(yè)務集成在SOA架構(gòu)下表現(xiàn)為服務之間的互操作，這種互操作要求企業(yè)各自的工作流管理系統(tǒng)能夠根據(jù)業(yè)務流程的復雜度對服務做出響應.服務的調(diào)用采用“請求-響應”模式.當然，在此模式下有的請求要求服務快速響應，有的則不然，甚至這種請求是單向的而不需要返回任何結(jié)果.

服務的調(diào)用一般分為同步調(diào)用和異步調(diào)用[9].

（1）當服務請求者向服務提供者發(fā)出例如用戶身份或密碼驗證請求的時候，就要求后者能夠盡快做出響應，在給出返回結(jié)果之前，服務請求者將一直處于等待狀態(tài)，這就屬于同步調(diào)用的方式.

（2）當服務請求者向服務提供者發(fā)出例如文件審批請求的時候，此時往往會由于企業(yè)內(nèi)部層級關(guān)系的不同，而不能快速做出響應，有時甚至需要多達幾天的時間，而服務請求者在獲取響應之前，仍然可以一方面擔任客戶的角色，去請求其他服務，一方面擔任服務器的角色，為服務請求者提供服務，并不會一直處于等待狀態(tài)，即邊等待邊工作，這就屬于異步調(diào)用的方式.

3.3　分布異構(gòu)環(huán)境下的信息集成

在辦公自動化水平和程度越來越高的今天，企業(yè)之間業(yè)務、信息往來的數(shù)據(jù)已經(jīng)不再是傳統(tǒng)意義上的簡單數(shù)據(jù)了，這些數(shù)據(jù)已經(jīng)延伸到更為復雜的文檔領(lǐng)域.在分布異構(gòu)的環(huán)境下，由于企業(yè)間異構(gòu)的系統(tǒng)對各自文檔的描述是基于不同的操作系統(tǒng)、編程語言和網(wǎng)絡環(huán)境，這些因素會導致企業(yè)間的業(yè)務集成受到大大地限制，只能在對等體系結(jié)構(gòu)的狀態(tài)下建立聯(lián)系.在SOA架構(gòu)下信息的集成可以通過以下幾個方面實現(xiàn)：

（1）業(yè)務流程建模.為了實現(xiàn)企業(yè)合作伙伴間的工作流互訪，在企業(yè)內(nèi)部建立模型的時候，對外公開其用于交互的接口，實現(xiàn)不同工作流模型的連接.

（2）信息的描述.WSDL是一種使用XML編寫的可以用來描述某個Web Service的文檔，它包括輸入?yún)?shù)、返回參數(shù)、方法操作等接口定義.正是由于XML是一種支持跨平臺的可擴展標記語言，再借助SOAP協(xié)議，非常適合在Internet環(huán)境下實現(xiàn)業(yè)務集成.

（3）接口的集成.BPEL也是一種基于XML的執(zhí)行語言，它擁有自己的定義接口，并且還定義了借助其他服務的接口來實現(xiàn)自己的接口，換句話說，BPEL是對WSDL功能的擴展，它將現(xiàn)有的服務重新整合起來，集成了更多的接口，成為一個新的服務[10]，進而實現(xiàn)更為復雜的流程.

4　結(jié)語

本文設計的基于SOA的工作流管理系統(tǒng)，依據(jù)軟件工程可復用理論，將Web Service技術(shù)與工作流技術(shù)相結(jié)合，將業(yè)務流程封裝為Web服務，具備了松散耦合的特性和高度的集成能力，很好地實現(xiàn)了企業(yè)間跨地域、跨平臺的業(yè)務流程之間的交互，在使資源共享變得簡單方便的同時，也降低了企業(yè)成本.

參考文獻:

〔1〕傅向華，明仲，彭小剛.基于SOA的流程與數(shù)據(jù)關(guān)聯(lián)模型研究[J].計算機應用研究，2008，25（1）：134-137.

〔2〕管紅杰，王珂，江海峰，許新征.SOA架構(gòu)的工作流管理系統(tǒng)的研究與應用[J].計算機工程與設計，2011，32（5）：1654-1657.

〔3〕喬志強，王勇，張璟.基于 UDDI的應用服務注冊中心的設計 [J].計算機工程與設計，2008，29（9）：6293-6295.

〔4〕趙松，王紅，閻嫕.Web服務組合工作流中擴展UDDI的設計與實現(xiàn) [J].計算機工程與設計，2009，30（1）：216-218.

〔5〕荊澤泉，李庭俊，符云海.基于SOA和Web Service的遺留系統(tǒng)重構(gòu)研究[J].數(shù)字技術(shù)及應用，2012,30（9）：37-39.

〔6〕吳丹.基于SOA的工作流管理系統(tǒng)研究與應用[D].廣州：廣東工業(yè)大學，2008.

〔7〕李敏.基于SOA的工作流技術(shù)的研究[D].曲阜：曲阜師范大學，2009.

〔8〕李紅信，范玉順.基于WebService的異構(gòu)工作流管理系統(tǒng)的集成和互操作研究[J].信息與控制，2003，32（3）：193-197.

〔9〕黃振.面向服務架構(gòu)工作流系統(tǒng)的研究與設計[D].上海：復旦大學，2008.

〔10〕劉霓，錢曉群.SOA技術(shù)在鐵路旅客服務信息系統(tǒng)的應用研究[J].鐵路計算機應用，2008，17（6）：18-20.