BPEL文檔基于DAG自動生成框架的研究與實現

陳　龍　蘇厚勤

(東華大學計算機科學與技術學院　上海 200051)

?

BPEL文檔基于DAG自動生成框架的研究與實現

陳龍蘇厚勤

(東華大學計算機科學與技術學院上海 200051)

摘要針對目前服務之間組合的復雜性，提出一種基于有向無環圖的業務流程執行語言文檔生成框架。通過對框架模型的解析，提出一種能夠自動生成服務組合所需各種文檔的改進框架及其算法，有效地隱藏了專業的業務流程執行語言知識和繁瑣的服務組合流程。實踐表明，該框架簡單、易用，不僅能夠清楚地反應服務組合之間的流程，而且還不需要BPEL專業方面的知識，減少了服務組合的工作量。

關鍵詞業務流程執行語言Web服務服務組合有向非循環圖

0引言

由于Web服務具有跨平臺、跨語言和低耦合等應用特性，使得Web服務技術已經成為解決企業集成、組件復用問題的一種重要方法[1]。實際業務環境中，單個Web 服務的功能是特定的，為了滿足快速發展的業務需求，需要對Web 服務進行組合。2002年7月在BEA、IBM和微軟的努力下，發布了業務流程執行語言(BPEL)來解決Web 服務集成問題。在實踐中一般使用BPEL設計器來編寫BPEL文檔。目前市場上有許多BPEL設計器，如Eclipse 的BPEL插件、Oracle的BPEL Process Manager以及Active Endpoints的 Active BPEL等[2]。這些設計器都是圖形化操作，通過手工拖動組件設計業務流程，生成Web 服務組合需要的文檔。但是使用這些BPEL設計器需要相關的Web服務和BPEL知識，并且創建組合服務的過程非常繁瑣。目前針對Web服務組合建模并自動生成BPEL的研究已有一定的成果，如文獻[3,4]采用的是Petri 網模型來對服務組合建模。文獻[5]使用有限自動機來對服務組合建模。但是這兩種建模方式可讀性比較差。有向圖模型的建模過程簡單并且模型流程清楚。文獻[2]給出了一種基于有向無環圖的自動生成組合文檔的原型框架，但是此原型框架沒有控制流程且組合的活動不能并行執行。由于在BPEL2.0規范中有和標簽支持流程控制和并行執行，本文在該原型框架的基礎上，提出一種新的組合框架，并對生成算法加以改進，解決了原框架生成的組合文檔沒有控制流程和組合活動不能并行執行的問題。

1BPEL元模型

BPEL是一種使用XML編寫的業務流程執行語言，主要用來對Web 服務進行編制，組合成大粒度的服務以滿足復雜的業務需求[6]。BPEL定義了一些元素標簽用來描述服務組合流程的消息流、控制流、數據流和伙伴會話的通道。消息流部分使用、和三個基本標簽支持接收、響應和調用消息活動，以便與其他服務進行通信。控制流包括、和等結構化活動標簽，能夠用于控制流程的串行和并行執行，以及選擇狀態轉移活動。和標簽可以對流程中的數據進行拷貝和更新活動。標簽用于指定服務組合時角色和提供的接口活動，從而建立對等的會話信道[7]。BPEL還有異常和故障處理的標簽元素等，限于篇幅不再贅述。圖1是關于BPEL2.0元模型的UML視圖[7]。

圖1　BPEL 2.0元模型的UML視圖

2Web服務組合工作流建模

DAG模型的建模過程簡單、描述內容豐富，廣泛應用于描述業務流程，已成為流程工業系統建模的主要建模方法之一[8]。鑒于DAG建模的簡單性，采用DAG對服務組合工作流進行建模，并稱這種模型為服務組合DAG(SCDAG)。一個SCDAG主要由3部分組成：開始和結束節點、伙伴節點以及節點之間的連接。

2.1開始節點和結束節點

開始節點是流程的開始，用來接收整個流程的輸入參數，并說明開始調用流程，對應BPEL文檔中的標簽。結束節點一般接收整個流程的輸出參數，并表明流程的結束，對應BPEL文檔中的標簽。在一個SCDAG中只有一個開始節點和結束節點，分別用帶有字符S、E的方形表示，如圖2所示。

圖2　SCDAG模型圖

2.2伙伴節點

伙伴節點和BPEL文檔中的標簽對應的，用來調用伙伴服務，使用帶圈內的小寫字母表示，如圖2所示。

2.3連接

連接是用來連接節點之間的弧，并且弧是有方向的。弧的方向表示活動調用的順序，并且也表示一種依賴關系，只有當該節點父節點全部執行完，該節點才能被調用。一般在連接中會傳遞一些服務調用的變量參數和一些條件選擇信息。節點之間是通過連接串連一起的，節點間是選擇執行還是并行執行都可以通過連接來傳遞。SCDAG中有3種類型的連接，分別是順序連接、并行連接和帶有條件選擇的連接。順序連接只是表明節點之間的依賴關系。并行連接和條件選擇連接除了有依賴關系還有其他特性。并行連接表明有唯一相同父節點的節點可以并行執行，如圖3所示的?節點有兩個并行執行節點?和。條件選擇連接和高級語言中的選擇判斷語句相似，只有條件滿足時，被指向的分支才能夠執行。其中順序連接和并行連接使用實線有向弧表示，在代碼生成時，通過模型上下文來區分是哪種連接。條件選擇連接使用虛線有向弧表示,如圖2所示。

圖3　SCDAG并行模型圖

3Web服務組合文檔的生成

Web服務組合時會涉及到3個文檔，分別是Web服務描述語言WSDL(Web Services Description Language)文檔、BPEL文檔、Deploy發布文檔。其中WSDL是Web服務的描述文檔，為用戶提供詳細的接口說明書。BPEL文檔是描述Web服務組合之間業務流程的文檔。Deploy發布文檔用來發布新集成的服務。由于這3個文檔都使用XML語言描述，可以采用開源的XML解析框架DOM4J來生成和解析這些XML文檔。其中WSDL文檔和Deploy文檔的結構比較固定且內容簡單，容易生成，這里不再贅述。

3.1生成BPEL文檔算法選擇

對于有向無環圖的遍歷方法，主要有廣度優先遍歷和深度優先遍歷。但是在SCDAG模型中，節點之間是有依賴的。如圖2所示，c節點指向e節點，那么e節點就依賴c節點。如果想要遍歷e節點，必須當e的前驅節點c、d、b都被執行后才能遍歷e節點。所以一般的廣度和深度優先遍歷不能滿足對SCDGA模型的遍歷。對于這種有依賴關系的遍歷，可以采用基于一種依賴的遍歷方法，具體在3.3節予以描述。

3.2并行和條件選擇設計

BPEL使用、、等結構化活動來控制管理整個流程并指定活動的執行順序。在SCDGA中，有唯一相同父節點的節點可以并行執行。如圖3所示，節點a和節點b是兄弟節點，并且節點a和節點b只依賴節點S，那么節點a、b可以并行運行。對于節點e，它依賴節點a和節點b，所以節點e不能和節點c、節點d并行運行。而節點c和節點d可以在節點a流程下嵌套進行并行執行。對于節點e，則會跳出標簽，在標簽之后生成對節點e的調用。

在SCDGA中，使用條件選擇連接控制活動分支的選擇。每一個條件選擇連接都有一個判斷條件，當條件為真時，則會執行該分支。標簽里有多個分支，當分支的輸出參數作為另一個伙伴節點的輸入參數時，會使得伙伴節點的輸入參數不知來自哪一分支。如圖2所示，伙伴節點f的中的一個輸入參數可能來自節點c或節點d。這里采用一個節點執行完后立即對它出度節點賦值。

3.3整體設計和算法實現

如果把BPEL文檔中的服務之間調用看成一個整體，那么BPEL文檔結構是比較固定的，可以采用生成器模式來設計。圖4是框架的整體實現，BpelBulider定義了BPEL文檔主要結構的接口，BpelBuliderImpl是接口實現。Edge表示連接，Vertex表示伙伴節點，Graph表示SCDAG模型。

圖4　框架實現類視圖

在對SCDAG模型進行遍歷生成BPEL文檔前，應該保證SCDAG是一個無環的并且沒有孤立節點的有向圖，這兩點也比較容易實現。在DAG中，若從節點i到節點j有一條有向路徑，那么就說節點j依賴節點i，i是j的入度節點，j是i的出度節點。在對DAG進行依賴遍歷時，如果遍歷i節點，必須把i的依賴節點全部遍歷后才能遍歷i節點。由于BPEL標簽可以嵌套，是有層次結構的，那么在生成BPEL標簽時也是分層次。如果節點i有一個出度節點j，那么節點i和節點j生成的BPEL標簽是同一層次；如果節點i有多個出度，那么出度節點的生成標簽在i后面的或標簽內部；如果i節點有多個依賴節點，那么節點i生成的標簽和依賴節點的最近公共父節點在同一個層次，這種情況下要先找到依賴節點最近父節點。下面是依賴遍歷算法和依賴算法中會使用的最近公共父節點算法的偽代碼。

算法1依賴遍歷算法

輸入參數v表示當前要遍歷的節點，f是節點v的一個入度節點，e當前XML標簽。

void genBpel(v,f, e)

{

if(v的入度節點還有沒訪問的) return；

v.visit = true；

//標記當前節點已訪問

type = 節點f到節點v的連接類型；

if(v有多個入度節點)

{

commFather=lastCommonFather(v);

//算法下面給出

e = 獲取節點commFather對應同一層級的XML標簽；

}

if(type == IF連接)

e = 生成BPEL的IF標簽;

else If(type == Flow類型連接)

e = 生成BPEL的Flow標簽;

生成節點v的活動調用標簽invoke;

For(v的出度節點v1…vn)

{

生成節點v到出度節點vi的參數賦值標簽Assign;

genBpel(vi,v,e);

} }

算法2最近公共父節點算法

在調用算法前，先把v的入度節點放入集合set中。對DAG進行深度優先遍歷，如果節點在set集合中則返回，當遞歸節點w的出度節點有返回多個不同的值時，則說明要找的節點分布在以w出度節點為根子圖中，這時遞歸函數返回w。輸入參數root為DAG根節點S。

Node lastCommonFather(root)

{

If(root == null) return null;

If(root 在集合set中)

{

return root;

}

node = v;

int cnt = 0;

for(root出度節點child1…childn)

{

nodei = lastCommonFather(childi);

if(nodei != null&& node !=nodei)

{

cnt ++;

//簡單記錄nodei是否多于2個

node = nodei;

}

}

If(cnt >=2) return root;

Else if(cnt == 1) return node;

Else return null;

}

4原型系統搭建及驗證

用戶通過使用UML建模工具Enterprise Architect建立服務組合流程，并生成相應的XML文檔，系統對XML文檔解析建立SCDAG模型。然后系統再讀取伙伴服務的WSDL文檔，提取相關信息生成組合服務的WSDL文檔，結合SCDAG模型生成BPEL文檔和服務發布文檔。把生成的文檔放入BPEL引擎中進行發布。系統使用的是Apache 基金下的開源項目Apache ODE作為BPEL執行引擎。

圖5　服務組合工作流程圖

當把生成的文檔在ODE引擎中發布后，可以調用新的組合服務。使用SoapUI對組合服務進行測試，圖6是調用組合服務的往返soap消息,其中左邊是發送的soap消息，右邊是返回的soap消息。

圖6　服務調用時的往返SOAP消息

5結語

針對目前服務之間組合的復雜性，提出了一種基于DGA的BPEL文檔生成框架。通過對框架模型的解析，能夠自動生成服務組合時所需要的各種文檔，有效地隱藏了專業的BPEL知識和繁瑣的服務組合流程。實踐表明，該框架簡單易用，不僅能夠清楚地反應服務組合之間的流程而且還不需要BPEL專業方面的知識，減少了服務組合的工作量。

實驗驗證表明該框架是可行的，但是該框架還不夠完善。雖然框架解決了伙伴服務的并行調用，但是沒有把融入并行處理中。框架還應該增加對BPEL的故障異常處理的支持。

參考文獻

[1] 岳昆,王曉玲,周傲英.Web服務核心支撐技術:研究綜述[J].軟件學報,2004,15(3):428-442.

[2] 崔福東,喬彥友,常原飛.基于BPEL的Web服務快速組合框架[J].計算機工程,2010,36(7):262-264.

[3] 劉賢,李建華,李向,等.基于擴展同步Petri網的BPEL建模[J].計算機工程,2011,37(2):57-60.

[4] 杜彥華,范玉順,李喜彤.基于模塊化可達圖的服務組合驗證及BPEL代碼生成[J].軟件學報,2010,21(8):1810-1819.

[5] 于守健,李衛民,吳國文,等.BPEL中基于有限狀態自動機的Web服務自動組合[J].小型微型計算機系統,2007,28(4):742-747.

[6] 丁兆青,董傳良.基于SOA的分布式應用集成研究[J].計算機工程,2007(10):246-248.

[7] 鐵威,黃志球,王進.基于BPEL的RESTful Web服務異步交互及組合研究[J].計算機工程與科學,2013,35(4):29-36.

[8] 韓中,高建民,陳富民,等.面向對象的流程工業系統有向無環圖建模[J].計算機工程,2009,35(8):23-25.

RESEARCH AND IMPLEMENTATION OF DAG-BASED AUTOMATIC BPEL DOCUMENT GENERATION FRAMEWORK

Chen LongSu Houqin

(SchoolofComputerScienceandTechnology,DonghuaUniversity,Shanghai200051,China)

AbstractWe proposed a DAG-based framework of Business Process Execution Language document generation for the complexities of compositions among current services. By resolving the framework model, we presented an improved framework, which can automatically generate various documents required for service compositions, and its algorithm, the professional knowledge of Business Process Execution Language and complex service composition processes are effectively hidden. Practice indicated that the framework was simple and easy to apply, the process among service compositions could be clearly reflected, and there was no need of professional knowledge of Business Process Execution Language as well, this reduced the work quantity for service compositions.

KeywordsBusiness Process Execution Language (BPEL)Web serviceService compositionDirected acyclic graph(DAG)

收稿日期：2014-11-14。陳龍，碩士生，主研領域：Web服務。蘇厚勤，教授級高工。

中圖分類號TP393

文獻標識碼A

DOI:10.3969/j.issn.1000-386x.2016.05.022