ＢＰＥＬ系統開發中異構數據處理的解決方案

摘要： BPEL4WS（業務流程執行語言，簡稱BPEL）是當前服務合成的首選標準語言，但因為它是流程組織的描述語言，所以并不提供處理異構數據的機制。為了解決BPEL系統開發中遇到的數據轉換方面的表達和處理問題，提出一種擴展BPEL規范中賦值活動的屬性的方法，使BPEL引擎可以滿足大部分復雜的數據處理需求，并支持通過業務規則引擎進行數據處理。

關鍵詞：BPEL擴展；數據轉換；業務規則

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)34-1537-03

Solution to Process Heterogeneous Data for Developing the BPEL System

YOU Hai-peng

(Institute of Computer Science Technology， Peking University， Beijing 100080， China)

Abstract: BPEL is currently the first choice of language for services composition， but it has no such a mechanism because it is a language of describing processes. In order to solve the expression and processing of datatransform for developing the BPEL system， this paper proposes an extension to the \"assign\" activity of BPEL. BPEL engine supporting this extension has been implemented， which can satisfy complex data processing need in services composition. Furthermore， the BPEL engine also supports data processing by business rule engines.

Key words: BPEL extension; data transform; business rule

1 引言

面向服務技術的出現，為各組織的應用集成提供了優秀的解決方案，而Web服務集成技術中以BPEL最受關注，并被廣泛應用。BPEL是一種用于表達和處理服務組織流程的語言規范，并不提供過多的數據轉換和存儲操作定義，所以說BPEL是弱數據處理的。然而，隨著Web服務的多樣化、組織間系統異構以及組織內部遺留系統的異構等諸多問題對應用集成技術的挑戰，異構數據的處理已經成為應用集成技術的主要研究方向，而在使用BPEL進行商業應用開發時，卻需要融合額外的數據處理系統來解決實際需求，這既增加了流程定義的復雜性，也降低了BPEL系統引擎的執行效率。此外，在商業領域，大量的數據處理涉及到業務規則的使用，如何在流程運行時解釋這些規則，也成為BPEL在商業領域推廣的絆腳石。

為了克服這些問題，特提出一種擴展BPEL規范的賦值活動屬性的方法，這種方法提高了BPEL在實際應用時數據轉換方面的表達和處理能力，使得在此基礎上開發的BPEL引擎可以滿足大部分的復雜數據處理需求，并使流程執行具備了一定的動態特性，維持了系統的持續運行。

2 Web服務集成的數據處理需求

Web服務集成經常要面臨對企業間的異構數據進行轉換的數據處理問題，目前的Web服務集成解決方案都是忽略了這一點的，產生這個問題的原因是，這些服務集成解決方案的初衷是為了解決Web服務的組織編排問題，它們側重的是如何創建商業處理流程來融合各種Web服務，以實現一個新的功能更強大更完備的Web服務而提供給調用者。這些方案只是定義了數據的流轉，卻并不深入涉及數據的處理和存儲問題。

但是，在服務集成應用的過程中，越來越多的數據處理問題顯現出來，據IDC調查表明，多數組織平均有49種應用程序和14種數據庫需要集成，而且每個組織中只有不到20%的客戶數據信息被安置在一個系統中[1]，因此如何處理好這些數據已經逐漸成為影響Web服務集成實現和執行的主要問題，這些問題主要體現在三個方面。

2.1 數據異構

異構數據轉換是應用集成要面臨的一個主要障礙，這些工作帶來了大量的系統負擔和人工操作的介入，降低了集成的效率和可用性，據AMR的2002年調查表明[1]，在系統運行中，用于數據轉換的程序執行占了20%-30%的資源消耗，這還不包括維護和更新的工作，如果要加上人力資源的介入，這種消耗很容易就能達到50%-70%。所以，如何解決異構系統間的數據通信，就成為集成技術發展的一個重要方向。

數據方面的異構主要體現在結構異構、類型異構、語義異構、表示語言異構等方面。

2.2 動態數據轉換

異構數據轉換需要在系統執行前期，由人工識別數據結構，并定制相應的轉換方式，然后系統在本地執行相應的數據轉換。但是，一旦遇到數據源或者數據結構變化比較頻繁的情況，這種對人力的高依賴性，就會帶來系統運行的間斷和響應延遲。

而且，隨著Web服務技術的發展，人們越來越希望Web服務的任何變化（特別是輸入輸出數據結構的改變）都不要影響集成系統的持續執行，還有動態選擇服務提供者及動態編排流程等，這些都需要實現動態的數據轉換。

所謂的動態，這里主要指兩個層面，一是在系統運行期，對于已經定義好的轉換規則發生改變時，系統無需停止，就可以響應這種變化需求；二是只需指定數據的源和目標，集成系統就可以根據數據特征，自動進行匹配，而且無論數據結構怎么變化，都可以正確的進行轉換。 可以看出，如果實現了這種動態的數據轉換，就可以擺脫人力依賴的束縛，提高系統的靈活性，因此動態數據轉換成為搭建一個高效率、高可用性集成系統的重要環節。

2.3 業務規則

全球化和多變性正挑戰著現在的商業，一個構建和運行成功的商業應用系統，必須能響應變化而不需要重新編譯和重新部署。業務規則正是為了應對這種商業變化而出現的，它通過配合各種內外部執行規則來提供更高的靈活性。

依據業務規則組織（Business Rules Group，BRG）[2]的定義，業務規則是定義或約束業務的某一方面的一條語句，其目的是對業務結構做出斷言或者對業務行為施加控制和影響。業務規則具有原子性。

因為業務規則比業務流程本身更改得更頻繁，而更改和管理嵌入的業務規則是一個復雜問題，并超出了大多數分析員的能力范圍，如果業務流程要隨著業務規則的更改而更改，就會消耗程序員大量的時間來執行該任務。此外，大多數組織都缺少中央規則信息庫，這就導致規則中任何涉及到組織范圍的更改都無法運用到所有業務流程中[3]。因此，Web服務集成技術一開始就將業務規則分離在業務流程引擎之外，而且到現在仍沒有提供把基于規則的知識集成在合成流程的有效方法。

然而，業務規則與業務流程是兩個互補互助的部分，兩者的合作可以更好的應對各種商業需求。特別是在數據處理上，以往使用的業務規則中已經定義好了處理邏輯，將這些邏輯轉化為流程定義，是費時費力的事情，轉換邏輯的重新定義只會帶來的過多的不必要的重復勞動，而降低系統開發的效率，而且多變的商業邏輯定死在流程中，更會降低靈活性。

因此，當Web服務集成進行數據處理時，如何使用以往系統中使用了很久的業務規則，實現這些規則的重用，就成為了Web服務集成的一個挑戰。

3 BPEL的弱數據處理特性

盡管BPEL憑著自身的特點迅速成為業界集成方案的主流技術，但是因為它的弱數據處理特性給復雜的應用集成帶來了不小的障礙。

所以說BPEL是弱數據處理的，是因為它在數據處理的表達和操作能力上都相對局限。BPEL是通過assign活動來實現數據操作的[4]，assign活動可以包含多個copy子活動，每個copy代表一次賦值，copy中通過一個from元素和一個to元素指定賦值操作的源和目標。通過copy元素，可以實現變量間的賦值，包括端點引用復制到合作伙伴鏈接或從合作伙伴鏈接中獲取端點引用，還可以使用表達式來構造和插入新數據。但這些定義只能滿足部分簡單數據操作的應用需求：

1) 相同數據類型的一對一的賦值；

2) 簡單的計算（例如遞增序列號）；

3) 和目標變量相同類型的文字值的賦值。

對于繁雜的各種商業應用場景來說，這些功能是遠遠不能滿足要求的，因此，需要定義的BPEL流程在運行時能處理更多更復雜的情況，比如，有效且簡潔的表達和處理多源數據到多目標數據的轉換；在不同類型數據之間進行賦值；支持商業領域的復雜計算等；此外，BPEL對于以往通過業務規則定義的數據處理邏輯，表示起來繁瑣冗長，甚至不能表示清楚。

Web服務技術，讓開發人員可以將各種數據處理和業務規則處理開發成相應的Web服務，然后集成到BPEL流程中，但這種方法卻因為需要流程在更多的服務間的跳轉，以及產生的大流量數據傳遞，而消耗過多的系統資源，降低BPEL流程的運行效率。因此，開發高效的商業系統需要提高BPEL的數據處理能力。

4 解決方案

為了能滿足服務集成中面臨的數據處理需求，需要對BPEL規范進行相應擴展。

首先，對于BPEL的copy元素增加了三個屬性。

＜all＞

＜attribute name=\"rule\" type=\"string\"/ ＞

＜attribute name=\"ruleengine\" type=\"string\"/ ＞

＜attribute name=\"expression\" type=\"string\"/＞

＜/all＞

其中，rule屬性用來指定數據轉換的規則，一般為一個轉換定義文件的URL，在系統開發中，默認的數據轉換定義使用XSLT規范，XSLT用于定義兩個XML文件之間的轉換，并且可以有效的表示多對一、多對多和復雜類型的映射關系。

ruleengine屬性用來指定處理數據轉換的引擎類，這個屬性的缺省值為空，此時表示使用引擎默認的數據轉換引擎（即XSLT的解析引擎），也可以是一個能處理業務規則文件的業務規則引擎，或者是用戶自定義的數據處理引擎。

expression屬性的值是一組函數表達式，這個能夠提供對專有領域自定義函數的支持能力，目前所實現的引擎支持Xpath 1.0規范中的大部分函數表達式，更多更專業化的函數表達式，還有待擴展。函數的參數可以是from元素指定的變量，而返回值必須與目標數據同類型。

還有一些擴展體現在from元素里，首先，為from元素增加了name屬性，這個屬性是為了定位當前源數據在表達式參數中的位置而設定的，例如：

expression = “concat(variable1，variable2) ”

這里，variable1、variable2分別是兩個from元素通過name屬性指定的變量名，而函數是將兩個變量做連接，并賦值到to元素指定的變量中。

其次，不再限制一個copy活動中from的數量，這就滿足了多個源數據的需要。對于多目標數據的情況，并沒有象from元素那樣修改to元素，因為，多目標數據無非兩種情況，一種是一個變量的多個子元素，另一種是多個變量，對于前者，rule屬性所指定的轉換樣式文件（比如XSL文件）就可以實現同時對一個變量的多個子元素進行賦值，而后者，考慮到不會增加過多的copy活動，因此可以分在多個copy中分別實現，這樣做是為了避免程序的過度復雜而難于編寫和維護。

5 示例

通過一個應用場景的示例，將能更好的說明擴展方法所能帶來的好處。

示例為一個網絡購物的簡化流程。首先，客戶通過互聯網填寫購物訂單，提交后，網站系統調用庫存查詢服務確定庫存量，如果滿足用戶的訂購條件，系統將進一步調用核算服務，核算服務將根據客戶的身份和訂購總量，按照企業設定的優惠規則計算出最終的價格，然后調用物流公司的運輸請求服務，并獲得運輸費用等相關返回信息，最后，網站將貨物最終價格、運輸費用及其他一些確認信息一并返回給客戶，作為訂購成功的依據，并等待客戶付款。

在這個流程中，調用的每個服務之間都會涉及到數據處理操作，每次的數據處理操作使用擴展后的規范表示如下：

1) 從訂單中提取商品信息賦值給庫存查詢服務的輸入變量

＜copy rule=\"checkstorage.xsl\"＞

＜from variable=\"orderRequest\"/＞

＜to variable=\"checkstorageinputVariable\"/＞

＜/copy＞

2) 根據商品信息調用核算服務

＜copy rule=\"account.xsl\"＞

＜from variable=\"orderRequest\"/＞

＜to variable=\"accountinputVariable\"/＞

＜/copy＞

3) 轉換客戶資料和訂單信息到運輸服務使用的數據格式

＜copy rule=\"ship.xsl\"＞

＜from variable=\"orderRequest\"/＞

＜to variable=\"shipinputVariable\"/＞

＜/copy＞

4) 根據企業使用的業務規則計算最終的商品價格

＜copy rule=\"discount.drl\"ruleengine=\"org.drools.jsr94.rules.RuleServiceProviderImpl\"＞

＜from variable=\"accountoutputVariable\"/＞

＜to variable=\"price\"/＞

＜/copy＞

5) 賦值訂購返回信息

＜copy rule=\"output.xsl\"＞

＜from variable=\"shipoutputVariable\" name = \"shipinfo\"/＞

＜from variable=\"price\" name = \"priceinfo\"/＞

＜to variable=\"orderResponse\"/＞

＜/copy＞

1)、2)、3)、5)都使用XSLT文件作為數據轉換的定義。其中1)、2)都是為了從訂單中提取需要商品相關信息賦值給服務的輸入變量；3)是因為物流是外部組織提供的服務，產生了跨組織的數據異構問題，而需要進行數據轉換；4)則是綜合運輸服務的反饋信息和商品的最終價格，返回給客戶訂貨成功的具體細節。此外，4)直接使用企業定義好的優惠規則，計算出商品的最終價格，這里，業務規則引擎以Drools為例，在這一步中，用戶還需做的唯一工作就是根據流程變量和業務規則定義相應的對象，以保證規則引擎的正常運行。

示例中的賦值操作，有些用原規范可以表達，但也是繁瑣冗長的工作，最后定義的文件，可能多達幾十頁，業務規則到BPEL的邏輯轉化，更會影響到BPEL文件的整體可讀性，而干擾BPEL表示流程編排的目標。

此外，當轉換邏輯改變時，只需要修改相應的轉換規則定義文件，而不需要修改流程，因此維持了BPEL引擎的持續運行，在一定程度上實現了BPEL的動態特性。

6 相關工作

目前針對BPE數據處理的相關研究還不是很多。Oracle公司作為業界的先驅，有著自己的解決辦法，對于數據轉換，他們采用隱式擴展的方法，擴展了from元素的expression屬性的內容，通過一個參數包含XSLT文件的函數來實現數據轉換，而針對業務規則，則是使用將業務規則公開為Web服務的方法，并在BPEL引擎中集成業務規則引擎的做法來實現的[3]；此外，針對BPEL對業務規則支持的研究，[5]同樣采用了面向服務的方法，而[6]采用定義一個agent的方法，[7]則對業務規則進行數據分析，然后將規則轉換為系統行為，以此達到集成的目的。此外[8]闡述了一種規則驅動機制來管理和指導服務流程編排。

7 結束語

在Web服務集成中，大量的數據異構現象成了流程編排的一大障礙，而目前最為流行的BPEL服務組織技術在數據上是弱處理能力的，這是因為服務組織能力的側重，使得它并沒有致力于數據轉換表達和操作，而BPEL系統的應用開發卻因為數據轉換能力的不足而遇到了很多問題，比如單源到多目標的轉換、多源到單目標的轉換、多源到多目標的轉換、復雜類型數據的轉換、經過復雜計算的轉換、使用業務規則語言定義的轉換等。

為滿足實際應用的需要，在不改變BPEL規范結構的基礎上，通過簡單擴展，來提高BPEL在數據轉換方面的表達和處理能力，使得在此基礎上開發的BPEL引擎可以滿足上述多種復雜的數據處理需求，并使流程執行具備了一定的動態特性，維護了系統的持續運行。

參考文獻：

[1] Kumar R.Web Services Oriented Integration: The Importance of Data Semantics[EB/OL]. http://www.dama.org.au/conference/2005/kumar.doc.

[2] The Business Rules Group.Defining Business Rules - What Are They Really?[EB/OL].(2000-07).http://www.businessrulesgroup.org/first-paper/br01c0.htm.

[3] Geminiuc K.面向服務的方法在業務規則開發中的運用[EB/OL].http://www.oracle.com/technology/global/cn/pub/articles/bpel_cookbook/geminiuc.html.

[4] Business Process Execution Language for Web Services Version 1.1[EB/OL].(2003-05). http://www.ibm.com/developerworks/library/specification/ws-bpel/.

[5] Rosenberg F，Dustdar S.Business Rules Integration in BPEL-A Service-Oriented Approach[C].Proceedings of the Seventh IEEE International Conference on E-Commerce Technology (CEC’05)，2005:476-479.

[6] Ali S，Soh B，Torabi T.A Novel Approach Toward Integration of Rules Into Business Processes Using An Agent-Oriented Framework[C].IEEE Transactions on Industrial InforMatics，2006，2:145-154.

[7] Vasilecas O，Smaizys A.The Framework: an Approach to Support Business Rule Based Data Analysis[C].2006 7th International Baltic Conference on Databases and Information Systems，2006:141-147.

[8] Orriens B，Yang J，Pppazoglou M P.A Framework for Business Rule Driven Service Composition[C].Proceedings of the Technologies for E-Services，4th International Workshop，TES 2003，Berlin，Germany，2003:14-27.