一種基于反射的ＢＰＥＬ業務過程動態演化方法

摘要：提出了一種基于反射的BPEL業務過程動態演化方法。該方法基于可反射的BPEL業務過程的動態演化框架，擴展了現有BPEL引擎，并對演化元過程建模，使其在BPEL引擎中實例化執行，來實現對業務過程的動態演化。

關鍵詞：業務過程;業務過程執行語言;工作流

中圖分類號：TP311文獻標志碼：A

文章編號：1001－3695(2007)05－0031－04

Web Service是一種設計和實現SOA的方法和技術，它給用戶提供了粗粒度、獨立于定位和連接的業務服務[1，2]。Web服務的業務過程執行語言（WS－BPEL）是一種基于XML的、平臺無關的業務過程建模和執行語言[3]。它提供了一種簡單的、基于標準的方法，以描述現實世界中的業務過程[4]。WS－BPEL 支持兩種截然不同的使用情形，即可執行業務過程和抽象的業務過程。可執行的業務過程可在一個運行環境（即BPEL引擎）中實例化執行[5]。

業務過程的復雜多變和因特網資源固有的不確定性使得對BPEL業務過程的建模無法避免不斷的后期修改。針對上述問題，目前所用的傳統方法一般是中止源程序的運行，待新程序編譯、部署完成后運行新程序[6]。然而對于一個部署和運行在BPEL引擎中的業務過程而言，不能簡單終止其某個正在運行的實例。例如，若終止有較長生存期的業務過程，那么該業務過程的長期工作必須重新實施。又如，若終止某業務過程實例的運行，那么需將其所完成操作進行反向補償，然而并非所有業務過程均可補償。因此，傳統方法不能很好地支持業務過程的動態演化。與此同時，當前的BPEL語言規范和相應的BPEL執行引擎亦不能較好地支持業務過程的動態演化。

根據上述分析，本文提出了一種基于反射的BPEL業務過程的動態演化方法。本文將該框架中向外提供演化功能的Web服務稱為演化元服務。同時，為了完成某次演化，用戶可依次組合多個不同的演化元服務的調用，以形成演化元過程。由于該演化元過程是標準的BPEL過程，其可在BPEL引擎中實例化執行，從而依次調用演化元服務，完成BPEL業務過程的動態演化。

1反射與反射體系結構

所謂反射是指系統能夠通過修改對自身狀態和行為的描述（簡稱自述）來調整自己的能力。系統實際的狀態和行為始終與自述保持一致，即對自述的改變能反映到系統實際的狀態和行為中，而系統的實際狀態和行為改變亦能在自述中得到反映[7]。如圖1所示，一個面向對象的可反射系統在邏輯上可以分為兩層或者更多層（組成一個反射塔）[8]。

相鄰兩層中的下層稱為基本級，描述系統本身想要做的計算；上層稱為元級，負責建立和維護系統自述。工作在基本級的對象稱為基本級對象，工作在元級的對象稱為元級對象。元級和基本級是因果關聯的（Causally Connected），即元級和基本級任何一方的改變均會引起另一方作相應的改變。基本級的任何改變都會自動地在其自述中得到體現——這個過程叫做具體化；而元級的任何改變都會自動地在其基本級中得到體現——這個過程叫做反射。反射提供了一種運行時刻系統修改自身的能力。因此可以很好地實現系統自適應性、動態配置以及系統的動態演化。

2基于反射的BPEL業務過程的動態演化方法

為了使BPEL引擎可以向外提供演化元服務，需要對現有的BPEL引擎作相應的擴展，使之能支持BPEL業務過程的動態演化。為此，提出了一種基于反射的BPEL業務過程的動態演化框架。應用該框架以實現對BPEL引擎的擴充，從而提供對BPEL業務過程動態演化的支持。

2．1基于反射的BPEL業務過程的動態演化框架

基于一個兩層的反射體系結構，圖2描述了本文提出的BPEL業務過程的動態演化框架。其中，基本級定義了需動態修改的對象，即過程定義和過程實例。同時，為了能對過程定義和過程實例進行修改，擴展了BPEL引擎中原有過程定義和過程實例的類庫，使之具有可反射的特性。

相應地，該框架的元級集中實現了提供演化功能的主要模塊，分別定義如下：

（1）演化控制器。接收外部的演化請求，與BPEL引擎的過程管理器、持久化機制通信，并控制整個演化過程的執行。具體化操作和反射操作均在演化控制器中被顯式調用。

（2）過程結構演化模塊。完成對業務過程結構的演化操作。該模塊僅修改過程的結構元信息，不考慮這些修改后的結構元信息如何反射到下面的BPEL過程定義和過程實例中。

（3）過程狀態演化模塊。完成對業務過程狀態的演化操作。該模塊修改過程的結構元信息，不考慮這些修改后的結構元信息如何反射到下面的BPEL過程定義和過程實例中。

（4）過程結構元信息對象。對業務過程結構方面的信息進行描述。

（5）過程狀態元信息對象。對業務過程狀態方面的信息進行描述。

2．2演化元服務

演化元服務是該演化框架與外部交互的接口。演化元過程調用演化元服務以完成演化操作；演化元服務將接收到的請求轉發給演化控制器，并在其控制下完成相應的演化操作。

（1）InitEvolution操作

當演化元過程調用演化元服務的InitEvolution操作時，演化控制器將會完成以下工作：①與BPEL引擎的過程管理器交互，獲得被演化的業務過程實例列表，并將這些過程實例掛起、加鎖；②執行具體化操作，從過程定義中獲得過程結構元信息，從各個過程實例中獲得過程狀態元信息。

（2）修改過程結構的操作

修改業務過程結構的操作分為三類操作，即添加、刪除和修改。相應地，本文定義了如下操作：①對合作伙伴鏈接的操作。AddPartnerLink、RemovePartnerLink、ModifyPartnerLink。②對變量的操作。AddVariable、 RemoveVariable、ModifyVariable。③對相關集的操作。AddCorrelationSet、RemoveCorrelationSet、ModifyCorrelationSet。④對活動的操作。分為對基本活動的操作和對結構化活動的操作兩類。基本活動的操作包括AddBasicActivity、RemoveBasicActivity、ModifyBasicActivity三個；而結構化活動相對較復雜，對其進行操作會具體到每一類活動，包括AddSequence、AddWhile、AddSwitch、AddFlow、AddPick、RemoveSequence、RemoveWhile、RemoveSwitch、RemoveFlow、RemovePick、ModifySequence、ModifyWhile、ModifySwitch、ModifyFlow、ModifyPick共15個操作。

當演化元過程調用這些操作時，演化控制器首先會將相應的操作委托給過程結構演化模塊；過程結構演化模塊會對過程結構元信息進行相應的修改；然后，演化控制器委托過程狀態演化模塊，對過程狀態元信息進行相應的修改。

（3）CommitEvolution操作

當演化元過程調用該操作時，演化控制器會做以下工作：①進行演化的正確性驗證。正確性是指過程定義的結構和數據的正確性（3.6節）。如果驗證失敗，系統拋出“正確性驗證失敗”異常，通知用戶進行修改，同時，取消演化，繼續執行原來的業務過程；如果驗證通過，則做下面的操作。②執行反射操作，用過程結構元信息修改過程定義和過程實例的結構；用過程狀態元信息修改過程實例的狀態。③繼續執行（Resume）相關的過程實例。④記錄日志。

2．3過程結構演化模塊

過程結構演化模塊負責對業務過程的結構部分進行演化。此模塊并不關心如何修改具體的過程定義和過程實例，而只是對過程結構元信息進行操作。例如，在演化元過程中調用一個添加Invoke活動的操作：

scope name=\"AddActivityInvokeScope\" 

variableAccessSerializable=\"no\"

sequence

assign

copy

form

aBasicActivity

xmlns=\"http://www.sklse.edu.cn/BPELEvolution\"

nameThirdLoanService/name

parentActivity

//scope[@name=\"GetLoanOffer\"]/sequence/flow/sequence[3]

/parentActivity

preActivity /

activityTypeinvoke

properties

property name=\"partnerLink\" value=\"ThirdLoanService\"/

property name=\"portType\" value=\"services:LoanService\"/

property name=\"operation\" value=\"initiate\"/

property name=\"inputVariable\" value=\"loanApplication\"/

/properties

/aBasicActivity

/form

to variable=\"AddActivityInput\"/

/copy

/assign

invoke name=\"AddActivityInvoke\"

partnerLink=\"EvolutionService\"

portType=\"tns:EvolutionServicePT\"

operation=\"AddBasicActivity\"

inputVariable=\"AddBasicActivityInput\"/

/sequence

/scope

這里傳入了name、ParentActivity、PreActivity、ActivityType和properties等幾個參數。在過程結構演化模塊中，執行流程如下：

（1）新建一個BasicActivityDef對象。

（2）按照傳入的參數。

①設置其name為“ThirdLoanService”;

②設置其Type為“invoke”;

③設置其ParentActivity：找到xpath為“//scope[@name=\"GetLoanOffer\"]/sequence/flow/sequence[3]”的活動對象，將其設為本對象的父活動;

④設置其PreActivity為1;

⑤設置其XPath為“//scope[@name=\"GetLoanOffer\"]/sequence/ flow/sequence[3]/invoke[@name=\"AddActivityInvoke\"]”;

⑥將傳入的properties依次添加到Properties Map中。

（3）修改它的ParentActivity對象，將該對象添加到父活動對象的子活動列表中。

（4）修改它的后繼活動對象的PreActivity為該對象。

2．4過程狀態演化模塊

當過程定義發生改變后，需要同時修改過程實例的狀態，使之能夠符合新過程定義的執行要求，同時不出現運行時錯誤。過程狀態演化模塊的主要功能就是對過程狀態元信息進行相應的修改以達到上述要求。

修改某個過程實例的狀態時，系統遵循以下方法：

（1）添加修改或刪除某活動時，系統首先檢查要添加的活動是否會造成系統的不一致。

①若不能保持系統的一致性，系統會拋出一個“一致性校驗失敗”異常，通知用戶不一致性發生的原因，請示用戶是否進行相應的修改，或是否允許不演化該過程實例，而讓該實例按照之前的過程定義運行下去。

②若可保持系統的一致性，那么系統會對變化后的活動進行相應的設置：新加入的活動被置為NOT_ACTIVATE，修改后的活動會保持之前的狀態不變。

(2)當對變量、相關集及合作伙伴鏈接進行相應的添加、修改或刪除時，需在相應的變量狀態元信息、相關集狀態元信息和合作伙伴狀態元信息中作相應的增刪操作。

①新加入的變量或修改后的變量需設置初始值。若這些變量與某些消息相關，則按消息內容設置；若這些變量與消息無關，則將其初始化為空值。

②新加入的相關集或修改后的相關集也需要設置初始值。相關集的值亦與消息相關。若已有相應消息，則用消息的數據初始化相關集;否則設為空值。

③新加入的合作伙伴鏈接或修改后的合作伙伴鏈接需設置其Endpoint Reference。通過訪問WSDL文檔，可得其Endpoint Reference的值。

2．5因果關聯的實現

元級和基本級是因果關聯的，基本級對象的信息可在元級對象中得到相應描述，而元級對象的改變亦會影響基本級對象。系統獲得基本級的信息，在元級生成元信息對象的過程稱為具體化；而當元信息發生改變后，基本級對象相應地修改自身結構和行為的過程稱為反射。在本文提出的框架中，基本級對象是BPEL引擎中的過程定義和過程實例，但是BPEL中的過程定義和過程實例的類庫并不能提供可反射的特性。因此，對BPEL引擎中的過程定義和過程實例的類庫進行了相應的擴展。

在本文的框架中定義了一個名為IReflectiveObject的接口，接口中定義了兩個主要的方法，即Reify和Reflect方法。BPEL引擎中的所有Process類、Activity類、PartnerLink類、Variable類、ProcessDef類、ActivityDef類、PartnerLinkDef類和VariableDef類等均需要實現這兩個方法以提供可反射的特性。

具體化——獲得業務過程的結構和狀態元信息。具體化操作是通過調用ProcessDef類和Process類的Reify方法來實現的。在這兩個類中的Reify方法被實現為一個遞歸的調用形式。調用這兩個類的Reify方法會遞歸地生成相應的子活動的元信息、變量的元信息、合作伙伴鏈接的元信息、相關集的元信息。

反射——根據元信息修改過程定義和過程實例。反射操作是通過調用ProcessDef類和Process類的Reflect方法來實現的。Reflect方法也是一種遞歸的實現，父活動的Reflect方法中會調用子活動的Reflect方法。這樣，調用這兩個類的Reflect方法就可以遞歸地利用元信息修改相應的子活動、變量、合作伙伴鏈接和相關集。

2．6案例研究

本文使用WS－BPEL規范中定義的貸款審批的案例來闡明文中方法的使用情況。首先，對演化元過程進行建模。與原業務過程相比，假定新業務過程需要在風險評估的活動之前，添加一個信用度評估的活動。該活動調用某外部的新Web服務，即涉及對新合作伙伴鏈接的定義和變量的定義。同時，需修改原活動Link的Source和Target。

以AddInvoke這個活動為例，說明如何用BPEL進行建模。其他元服務調用均為大致相同的方式。但對不同的演化元服務，需傳入的參數屬性不同。如下所示，使用一個Assign活動來初始化調用AddInvoke元服務所需要的輸入參數。為了使演化元服務知道要添加的Invoke活動的位置，使用ParentActivity和PreActivity兩個屬性來定位。這兩個屬性均使用XPath進行描述。然后，調用演化元服務AddInvoke來完成添加Invoke活動的操作。

scope name=\"AddInvokeScope\"

sequence

assign

copy

from expression=\"‘ CreditRating’\"/

to variable=\"AddInvokeInput\"part=\"name\"/

from expression=\"‘//flow[1]’\"/

to variable=\"AddInvokeInput\"part=\"parentActivity\"/

from expression=\"‘//flow[1] //receive[1]’\"/

to variable=\"AddInvokeInput\"part=\"preActivity\"/

from expression=\"‘CreditRator’\"/

to variable=\"AddInvokeInput\"part=\" partnerLink \"/

from expression=\"‘CreditRatingPT’\"/

to variable=\"AddInvokeInput\"part=\" portType \"/

from expression=\"‘check’\"/

to variable=\"AddInvokeInput\"part=\" operation \"/

from expression=\"‘request’\" part=\"PersonalInfo\"/

to variable=\"AddInvokeInput\"part=\" inputVariable \"/

/copy

/assign

invoke name=\"AddInvoke\"

partnerLink=\"EvolutionService\"

portType=\"tns:EvolutionServicePT\"

operation=\"AddInvoke\"

inputVariable=\"AddInvokeInput\"/

/sequence

/scope

用BPEL建模工具編寫的演化元過程也是一個標準的BPEL過程。因此，需要將其部署到BPEL引擎中，并啟動它來完成演化。演化元過程首先調用InitEvolution元服務來對演化過程進行初始化。演化框架中的演化控制器模塊將準備演化的過程實例掛起、加鎖，并執行具體化操作生成過程結構和過程狀態元信息。然后演化元過程調用一系列對過程的修改活動。這些活動也是調用相應元服務來完成的。這些元服務的實現是由演化控制器分別委托結構演化模塊和狀態演化模塊完成的。最后，演化元過程調用CommitEvolution元服務提交所做的演化，即對過程進行正確性驗證、執行反射操作修改過程定義和過程實例、設置過程實例的狀態為running。這樣就完成了一次演化活動，過程定義和過程實例都演化到了新版本。

3結束語

本文提出了一種基于反射的BPEL業務過程動態演化方法。從兩個層面支持演化，在用戶層面上，用戶可通過對演化元過程建模并將其在BPEL引擎中實例化執行來完成演化。這個層面上，只對“做什么”進行定義，用戶無須關心BPEL引擎內部的實現細節。在系統層面上，文中方法通過一個可反射的框架向外提供演化元服務。這個層面上解決“怎么做”的問題，任何一個BPEL引擎可將該框架集成到系統中以支持系統動態演化。當然，尚有某些方面的問題有待作進一步研究。例如對業務過程元信息和演化框架的進一步研究和改進，添加異常、事務等方面的處理。同時，對業務過程的演化元過程建模、部署、執行、監控、調試，對審計工具的開發和研究，對BPEL業務過程演化中的一致性和正確性分析，及其驗證工具的開發等問題均為進一步工作的內容。

參考文獻：

［1］CHAMPION M，RERRIS C， NEWCOMER E，et al.Web service architecture， W3C working draft[EB/OL].[2002].http://www.w3.org/TR/2002/WD－ws－arch－2002 1114/.

［2］ALONSO G，CASATI F，KUNO H， et al.Web services:concepts，architectures， and applications[M].[S.l.]:Springer，2004.

［3］ARKIN A. Business process modeling language－bpml1.0 last call working draft[EB/OL].[2002].http://www.bpmi.org.

［4］OASIS. Web services business process execution language working Draft[EB/OL].[2005－02－27].http://www.oasis－open.org/apps/org/workgroup/wsbpel/.

［5］WFMC. Workflow management coalition terminology glossary[EB/OL].[1999－02].http://www.wfmc.org/standards/docs/TC－1011_term_glossary_v3.pdf.

［6］CASATI F，CERI S，PERNICI B，et al.Workflow evolution[J].Data and Knowledge Engrg，1998，24(3) :211－238.

［7］MAES P. Concepts and experiments in computational reflection:proceedings of ACM Conference on Object－Oriented Programming， Systems， Languages and Applications (OOPSLA’87)[C].Orlando:[s.n.]，1987:147－155.

［8］CAZZOLA W，GHONEIM A，SAAKE G. Reflective analysis and design for adapting object run－time behavior:proceedings of the 8th International Conference on Object－Oriented Information Systems[C].[S.l.]:[s.n.]，2002:242 －254.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”