基于C++的BPEL流程引擎原型的設(shè)計與實現(xiàn)

1、HBIISouthChinaUniversityofTechnology本科畢業(yè)設(shè)計（論文）說明書基于C+的BPEL流程引擎原型的設(shè)計與實現(xiàn)學院軟件學院專業(yè)軟件工程學生姓名指導(dǎo)教師提交日期2009年6月3日華南理工大學畢業(yè)設(shè)計(論文)任務(wù)書茲發(fā)給班學生畢業(yè)設(shè)計(論文)任務(wù)書，內(nèi)容如下：畢業(yè)設(shè)計(論文)題目：基于C+的BPEL流程引擎原型的設(shè)計與實現(xiàn)應(yīng)完成的項目：2009年4月10日前擬定提綱并提交開題報告2009年5月25日前完成論文初稿進行基于C+的BPEL引擎原型的設(shè)計與開發(fā)參考外文文獻資料并提交外文翻譯譯文參考資料以及說明：楊開誠.數(shù)據(jù)結(jié)構(gòu)M.電子工業(yè)出版社.2008(9).JamesG

2、osling,BillJoy,GuySteeleandGiladBracha,TheJavalanguagespecificationthirdeditionM.Addison-Wesley,2005.StanleyB.Lippman,Jos配Lajoie,C+Primer,清華大學出版社2003.楊洪波.BPEL4People思想解讀J.軟件世界.2008(11).萬露.基于SOA和BPEL的業(yè)務(wù)流程管理研究與應(yīng)用J.計算機與現(xiàn)代化.2009(8).APACHEODE, HYPERLINK / /Jacob. HYPERLINK /jacob.html /jacob.htmlBoostSer

3、ialize, HYPERLINK / /本畢業(yè)設(shè)計(論文)任務(wù)書于年月日發(fā)出，應(yīng)于年月日前完成，然后提交畢業(yè)考試委員會進行答辯。專業(yè)教研組(系)、研究所負責人審核年月日指導(dǎo)教師簽發(fā)年月日畢業(yè)設(shè)計（論文）評語：畢業(yè)設(shè)計（論文）總評成績：畢業(yè)設(shè)計（論文）答辯負責人簽字 摘要本文詳細介紹了BPEL流程引擎以及流程管理系統(tǒng)的理論知識與應(yīng)用。由于目前幾乎所有BPEL流程引擎核心都是基于JAVA語言編寫的，與操作系統(tǒng)底層交互程度較低，運行效率相對地下，在大規(guī)模應(yīng)用上存在一定的不足。而C+語言的主要特質(zhì)之一就是高效,與操作系統(tǒng)底層交互良好。針對C+語言各自的特點，和目前計算機軟件界使用C+開發(fā)的流程引擎的

4、空白，進一步提升流程引擎效率，本文提出了基于C+語言的BPEL流程引擎原型設(shè)計方案，并對其進行了實現(xiàn)。流程引擎是運行經(jīng)過編譯的可執(zhí)行的業(yè)務(wù)流程語言（通常是BPEL）定義文件的核心部分，其主要三大功能分別是解析業(yè)務(wù)流程語言定義的活動并運行、支持結(jié)構(gòu)性活動、可以持久化地運行。而其中如何控制處理并發(fā)活動、如何持久化運行是流程引擎的設(shè)計難點。只有解決了上述兩個問題，流程引擎才能真正意義上具備實用價值。本文先對APACHEODE流程引擎核心（即JACOB）作了深入詳盡的研究分析，對其處理并發(fā)活動所采用的通信渠道機制和如何處理調(diào)度控制的問題進行了詳細說明；然后給出了JAVA語言與C+語言的異同，在此基礎(chǔ)上

5、指出使用C+語言開發(fā)流程引擎時需要注意的重點，并據(jù)此提出了基于C+的使用調(diào)用堆棧和BOOST序列化庫來實現(xiàn)虛擬處理單元以及整個流程引擎的設(shè)計方案和實現(xiàn)。成品測試表明，使用C+開發(fā)BPEL流程引擎是完全可行的，整合了其余組件后能夠?qū)崿F(xiàn)完整的流程管理系統(tǒng)，其實際運行情況令人滿意。C+在Web時代依然有著很強的生命力，使用C+開發(fā)的流程引擎應(yīng)當有廣闊的發(fā)展前景。關(guān)鍵詞：業(yè)務(wù)流程執(zhí)行語言，業(yè)務(wù)流程引擎，虛擬處理單元AbstractThispaperbrieflyintroducethetheoriesandapplicationsaboutBPELprocessengineandBusinessPro

6、cessManagementSystems.SincealmostallBPELengineisbasedonJAVAlanguage,whichdonothavegoodperformancewiththeunderlyingoperatingsystemandlowefficiency.Andtheymaycostacertainproblemwhilerunninglarge-scaleapplicationsasaresult.Aslongasweknow,C+isalanguagewiththemaincharacteristicsofhighefficiency,anditmake

7、goodinteractionwiththeunderlyingoperatingsystem.TofurtherimprovetheefficiencyofprocessengineusingthecharacteristicsofC+language,weputforwardaprojectofBPELprocessengineusingC+language.ProcessengineisthecorecomponentthatcanexecutecompiledrunnableBPELfiles.Itsthreemainfunctionsareexecuteactivitiesdefin

8、edbyBPEL,PersistenceofexecutionstateandConcurrency.Thereinto,howtoimplementtopersistenceofexecutionstateandhowtocontrolconcurrencyaretwobigproblemswhiledesigningprocessengine.Onlysolvethesetwoproblems,canourenginebeworthiness.ThisarticlefirstanalyzesAPACHEODEenginecore(thatis,JACOB)indetail,interpre

9、tthechannelcommunicationmechanismsofJACOBwhichisusingtosolveconcurrencyproblem.Andthen,showstheimportantpointsofdesigningC+processengineandoursolutionswhichusestackandBoostserializationtodesignVPU,bygivingthesimilaritiesanddifferencebetweenJAVAandC+language.FinaltestshowedthattheBPELprocessenginedev

10、elopedbyC+isentirelyfeasibleandcaneasilycompletelyarchiveamanagementsystemafterintegratedtheremainingcomponents,whichissatisfied.Asfaraswecanconcern,C+stillhasastrongvitalityintheWebarea,andtheprocessenginebasisonitshouldhavebroadprospectsincommerce.Keyword:BPEL,Processengine,VPU iii目錄TOC o 1-5 h z摘

11、要IAbstractII第一章緒論錯誤！未定義書簽。1.1研究背景和意義1 HYPERLINK l bookmark8 1.2國內(nèi)外研究現(xiàn)狀2 HYPERLINK l bookmark14 1.3應(yīng)解決的主要問題及應(yīng)達到的技術(shù)要求3 HYPERLINK l bookmark16 1.4本文組織結(jié)構(gòu)4第二章BPEL理論概述5 HYPERLINK l bookmark18 BPEL語言理論知識5 HYPERLINK l bookmark20 BPEL語言的作用域5 HYPERLINK l bookmark22 BPEL活動的標準屬性和成員5 HYPERLINK l bookmark24 BPEL基

12、礎(chǔ)活動6 HYPERLINK l bookmark26 BPEL結(jié)構(gòu)化活動7其他結(jié)構(gòu)化活動7 HYPERLINK l bookmark28 本章小結(jié)8第三章關(guān)于ApacheODE流程引擎的研究9 HYPERLINK l bookmark30 ApacheODE結(jié)構(gòu)總覽9 HYPERLINK l bookmark32 3.1.1為什么選擇參考ApacheODE流程引擎9 HYPERLINK l bookmark34 ODEBPEL編譯器10 HYPERLINK l bookmark36 ODEBPEL弓I擎運行時10 HYPERLINK l bookmark38 ODE數(shù)據(jù)訪問對象(DAOs)1

13、0 HYPERLINK l bookmark42 ODE集成層11 HYPERLINK l bookmark44 APACHEODE流程引擎的JACOB框架11 HYPERLINK l bookmark46 什么是JACOB11 HYPERLINK l bookmark90 通道Channels12 HYPERLINK l bookmark92 Jacob對象(JacobObject)與Jacob可運行的線程狀態(tài)(JacobRunnable)12 HYPERLINK l bookmark94 方法集MethodLists(MLs)13 HYPERLINK l bookmark96 虛擬處理單元

14、(VirtualProcessUnit)和執(zhí)行隊列(ExecutionQueue)13 HYPERLINK l bookmark98 實例解析14 HYPERLINK l bookmark108 本章小結(jié)20第四章提出基于C+特性的BPEL引擎方案21 HYPERLINK l bookmark110 JAVA和C+的異同214.2基于C+的BPEL流程引擎核心的設(shè)計方案22并發(fā)控制的設(shè)計方案22C+的多態(tài)機制在BPEL引擎中的應(yīng)用234.2.3基本活動的處理244.2.4結(jié)構(gòu)性活動的處理24 HYPERLINK l bookmark112 本章小結(jié)25第五章掛起與再啟動26為什么需要掛機與再啟

15、動26 HYPERLINK l bookmark114 序列化26 HYPERLINK l bookmark116 BoostSerialization26 HYPERLINK l bookmark118 BoostSerialization的特點26 HYPERLINK l bookmark122 BoostSerialization的使用27 HYPERLINK l bookmark124 本章小結(jié)28 HYPERLINK l bookmark0 第六章基于C+的BPEL引擎原型設(shè)計與實現(xiàn)296.1基于C+的BPEL引擎主要模塊設(shè)計與實現(xiàn)296.1.1系統(tǒng)層次架構(gòu)296.1.2引擎運行時的

16、VPU模塊實現(xiàn)306.1.3引擎運行時的執(zhí)行隊列模塊實現(xiàn)30 HYPERLINK l bookmark126 BPEL引擎的動態(tài)行為描述316.1.5序列化的實現(xiàn)31系統(tǒng)應(yīng)用實例32 HYPERLINK l bookmark134 6.2.1Sequence實例32 HYPERLINK l bookmark136 6.2.2Flow實例36 HYPERLINK l bookmark148 本章小結(jié)39第七章結(jié)論40 HYPERLINK l bookmark150 7.1結(jié)論407.2存在的不足40 HYPERLINK l bookmark152 參考文獻41 HYPERLINK l bookm

17、ark154 致謝42 HYPERLINK l bookmark156 附錄43 緒論1.1研究背景和意義什么是業(yè)務(wù)流程？業(yè)務(wù)流程可以被定義為一個由各種不同功能的活動相連的一組有相互關(guān)系的任務(wù)，它們依照一定的業(yè)務(wù)邏輯和順序依次執(zhí)行。業(yè)務(wù)流程有起點和終點，而且它們都是可重復(fù)的。業(yè)務(wù)流程是企業(yè)實現(xiàn)商務(wù)目標的方法。對于企業(yè)而言，業(yè)務(wù)流程是企業(yè)重要的知識資產(chǎn)，是企業(yè)的核心競爭力的體現(xiàn)，一個精心設(shè)計和執(zhí)行的業(yè)務(wù)流程能夠為企業(yè)創(chuàng)造價值并節(jié)約成本。在著名作家佛里德曼對經(jīng)濟全球化有著精彩的論述，它描繪了一個由互聯(lián)網(wǎng)、通信基礎(chǔ)設(shè)施和新型軟件搭建的全球舞臺；在這個舞臺上，人們能夠以多種方式分享知識、勞動、娛樂和發(fā)

18、現(xiàn)，并且創(chuàng)造新的商業(yè)機會?！叭缃裎譅栺R是美國最大的公司，然而它什么也不生產(chǎn)，只是建立了這個非凡的供應(yīng)環(huán)節(jié)，從世界各地進口非常便宜的商品并把世界各地的產(chǎn)品送到消費者手里。它是一個全球組裝線。”世界是平的：21世紀簡史1。在經(jīng)濟全球化的過程中，企業(yè)的邊界變得模糊，企業(yè)會將任務(wù)分解為一系列的子任務(wù)，企業(yè)只關(guān)注于自己的核心競爭力所在，并將其他工作分包給最合適的人來完成。企業(yè)需要通過業(yè)務(wù)流程將這些片斷有機地組織在一起。在這里我們可以深刻地認識到業(yè)務(wù)流程對企業(yè)的重要性2。信息化產(chǎn)業(yè)中由此誕生了業(yè)務(wù)流程管理系統(tǒng)，其核心部分就是流程引擎。定義業(yè)務(wù)流程并對其做出文檔所花費的時間和努力是完全值得的。在一個反映中國

19、傳統(tǒng)醫(yī)學的電視劇中，當配置藥劑的時候，掌柜把自己反鎖在藥房里，只有他會根據(jù)“秘方”將不同的藥材調(diào)配成救死扶傷的靈藥。然而只有他一人掌握這個過程是非常危險的。對于現(xiàn)代企業(yè)來說這更是不可能的，我們不可能只讓配件制造主任了解企業(yè)的配件制造知識，然后讓他每晚獨自裝配所有的零件。只要定義了配件制造業(yè)務(wù)流程，配件制造工人可以隨時來去，而且任何配件制造工人都可以隨時取代另一個人的工作，這是因為工廠里的所有配件制造工人都理解并遵循業(yè)務(wù)流程。我們可以學習、改變、評估，然后再次改變配件制造業(yè)務(wù)流程，因為該流程對于每個人都是可見的，而非局限于配件制造主任?，F(xiàn)代業(yè)務(wù)流程管理系統(tǒng)的歷史可以追溯到工作流系統(tǒng)2。業(yè)務(wù)流程管

20、理系統(tǒng)是自本世紀初以來企業(yè)信息技術(shù)應(yīng)用(信息化)背景上最重要和活躍的概念之一。它有兩方面的基本含義或理解背景。一方面是企業(yè)管理，一方面是企業(yè)應(yīng)用(軟件、系統(tǒng))。綜合而言，它是典型的，在企業(yè)應(yīng)用強力推動下產(chǎn)生的跨管理與信息技術(shù)領(lǐng)域的流行概念之一。從管理的角度，它可以看作是業(yè)務(wù)流程再造(BPR)所帶來的以業(yè)務(wù)流程為中心的管理思想的延續(xù)與發(fā)展；從企業(yè)應(yīng)用角度，它是在工作流(Workflow)等技術(shù)基礎(chǔ)上發(fā)展起來的，基于業(yè)務(wù)流程建模，支持業(yè)務(wù)流程的分析、建模、模擬、優(yōu)化、協(xié)同與監(jiān)控等功能的新一代企業(yè)應(yīng)用系統(tǒng)核心。簡單地來講，工作流定義了業(yè)務(wù)流程中的參與者(Who)、所執(zhí)行的工作(What)及何時執(zhí)行(

21、When)。在企業(yè)IT環(huán)境中，工作流軟件通常與企業(yè)應(yīng)用集成(EnterpriseApplicationIntegration,EAI)系統(tǒng)結(jié)合在一起，成為企業(yè)應(yīng)用的“黏合劑”實現(xiàn)業(yè)務(wù)流程的自動化和流水線化2。傳統(tǒng)工作流系統(tǒng)的最大缺陷就是：它們大多采用了專有技術(shù)。這使得業(yè)務(wù)流程與企業(yè)應(yīng)用的結(jié)合變得非常復(fù)雜，通常需要很長時間進行部署和實施，而與企業(yè)外部系統(tǒng)進行集成則更加困難，無法適應(yīng)全球化浪潮和互聯(lián)網(wǎng)時代對企業(yè)靈活、無縫集成的需求。人們開始考慮利用Web服務(wù)的開放性和標準化，來解決業(yè)務(wù)流程與企業(yè)應(yīng)用之間的互操作性問題。2002年7月，IBM、微軟、BEA提交了BusinessProcessExec

22、utionLanguageforWebServices(BPEL4WS)1.0的規(guī)范。業(yè)務(wù)流程執(zhí)行語言基于XML和Web服務(wù)技術(shù)，它融合了早期的IBM的WebServicesFlowLanguage(WSFL)及微軟的XLANG規(guī)范的很多特點。隨后許多主要供貨商如SAP和Siebel(已被Oracle并購)等公司陸續(xù)加入規(guī)范的制定，并催生了多項修改和改進，并于2003年3月發(fā)布了1.1版。2003年4月，BPEL被提交結(jié)構(gòu)化信息標準促進組織(OASIS)以實現(xiàn)標準化，并組建了Web服務(wù)業(yè)務(wù)流程執(zhí)行語言技術(shù)委員會(WSBPELTC),該努力使BPEL在業(yè)界獲得更為廣泛的認可。目前該技術(shù)委員會正在

23、致力于下一代規(guī)范的制定工作，并將該規(guī)范重命名為WS-BPEL2.0。雖然除BPEL之外還有一些業(yè)務(wù)流程規(guī)范，但是到目前為止，BPEL是最為成熟和被廣泛支持的技術(shù)6,13,14。“萬維網(wǎng)其共通之標準讓網(wǎng)絡(luò)的應(yīng)用軟件溝通無礙1”隨著全球經(jīng)濟一體化，社會分工更加的細致，業(yè)務(wù)流程管理系統(tǒng)的應(yīng)用廣度與深度將越來越大。通過研究、探索其核心部分，有助于提高筆者對新世紀計算機軟件技術(shù)發(fā)展和現(xiàn)代企業(yè)軟件的認識。國內(nèi)外研究現(xiàn)狀目前國外流行的流程引擎主要有以下幾種15：OSWworkFlow：是完全用java語言編寫的開放源代碼的工作流引擎，具有顯著的靈活性及完全面向有技術(shù)背景的用戶的特點。用戶可以根據(jù)自身的需求利

24、用這款開源軟件設(shè)計簡單或是復(fù)雜的工作流。JBPM：全稱是JavaBusinessProcessManagement(業(yè)務(wù)流程管理)，它是覆蓋了業(yè)務(wù)流程管理、工作流、服務(wù)協(xié)作等領(lǐng)域的一個開源的、靈活的、易擴展的可執(zhí)行流程語言框架JBPM是公開源代碼項目，它使用要遵循ApacheLicense，其最大的特色就是它的商務(wù)邏輯定義沒有采用目前的一些規(guī)范，如WMC、XPDL、BPML、ebXML、BPEL4WS等，而是采用了它自己定義的JBossjBPMProcessdefinitionlanguage(jPdl)。jPdl認為一個商務(wù)流程可以被看作是一個UML狀態(tài)圖。jPdl就是詳細定義了這個狀態(tài)圖的

25、每個部分，如起始、結(jié)束狀態(tài)，狀態(tài)之間的轉(zhuǎn)換,過圖型化的流程定義，直觀地描述業(yè)務(wù)流程。APACHEODE（OrchestrationDirectorEngine）：是基于Java的開源WS-BPEL（簡稱BPEL）引擎，它于2007年7月18日從Apache的孵化器中誕生成為一個頂級項目。它的主要功能就是執(zhí)行使用BPEL描述的業(yè)務(wù)流程，實現(xiàn)業(yè)務(wù)流程自動化，它支持長期運行和短期運行的過程。WebSphereProcessServer基于WebSphereApplicationServer和WebSphereEnterpriseServiceBus,它為面向服務(wù)的體系結(jié)構(gòu)（SOA）的模塊化應(yīng)用程序提

26、供了基礎(chǔ)，并支持應(yīng)用業(yè)務(wù)規(guī)則，以驅(qū)動支持業(yè)務(wù)流程的應(yīng)用程序。除此之外還有BEAAquaLogic、OracleBPELProcessManager、IONAArtixOrchestration、ActiveBPEL、IntalioBPMS、MicrosoftBizTalkServer等等。在國內(nèi)，主要是使用上述幾個引擎做擴展、應(yīng)用，研究流程引擎核心的團體、組織、個人非常少。同時，目前所有的商業(yè)流程引擎或開源流程引擎均使用Java或C#實現(xiàn)。之所以沒有使用C+實現(xiàn)的BPEL引擎，主要有三個原因：第一，一般的電子商務(wù)應(yīng)用，主要是在較底層的ESB上提高性能，而不是處于上層的BPM；第二，各大廠商為了

27、使他們生產(chǎn)的產(chǎn)品系列配套，根據(jù)其原有產(chǎn)品基礎(chǔ)來設(shè)計實現(xiàn)BPEL引擎；第三，開源項目實際上也是各大廠商主導(dǎo)推動，為其產(chǎn)品的改進提供活躍技術(shù)支持的，因此采用與其產(chǎn)品相關(guān)的結(jié)構(gòu)。而C+語言相對其他語言具有性能上的優(yōu)勢，因此本設(shè)計將采用C+語言來實現(xiàn)BPEL引擎，進一步提高BPEL引擎的性能。應(yīng)解決的主要問題及應(yīng)達到的技術(shù)要求BPEL引擎主要功能是執(zhí)行業(yè)務(wù)流程，是BPM架構(gòu)的核心，其設(shè)計好壞、效率高低直接影響到整個BPM的性能高低。2,16BPEL引擎的主要功能是提供BPEL流程的部署和運行環(huán)境。對于部署在BPEL引擎上的業(yè)務(wù)流程，首先解析流程文件生成數(shù)據(jù)對象結(jié)構(gòu)，然后將數(shù)據(jù)對象結(jié)構(gòu)序列化并保存。執(zhí)行

28、流程的時候，將已保存的數(shù)據(jù)對象結(jié)構(gòu)反序列化，并根據(jù)流程中的結(jié)構(gòu)和活動執(zhí)行相應(yīng)的操作，必要時將變量和流程執(zhí)行狀態(tài)持久化。執(zhí)行流程時，BPEL引擎在與服務(wù)的交互過程中扮演了兩種角色：服務(wù)消費者和服務(wù)提供者，區(qū)別在于BPEL引擎是作為交互消息的發(fā)起者或被發(fā)起者。交互的消息類型有In-Only和In-Out兩種，區(qū)別在于是否需要返回結(jié)果。實現(xiàn)BPEL引擎時應(yīng)該注意這些區(qū)別。BPEL引擎的核心BPEL運行時，在執(zhí)行流程中需要解決兩個主要的問題：第一，如何表達流程執(zhí)行狀態(tài)，方便需要的時候掛起當前狀態(tài)，等待重新啟動。特別是對于需要長期運行的流程，如果能夠隨時將流程當前執(zhí)行狀態(tài)通過數(shù)據(jù)持久化機制掛起保存，則可

29、以避免進入長等待時由于出現(xiàn)系統(tǒng)故障而丟失流程執(zhí)行狀態(tài)，無法恢復(fù)。第二，如何解決流程執(zhí)行并發(fā)性管理問題。一般來說，創(chuàng)建一個流程實例都應(yīng)該新建一個線程來執(zhí)行。流程本身也支持并發(fā)操作flow,常規(guī)做法是為流程內(nèi)的并發(fā)操作新建線程執(zhí)行。由于流程內(nèi)并發(fā)操作數(shù)量不可知，有可能出現(xiàn)線程泛濫甚至系統(tǒng)崩潰12。好的做法應(yīng)該是將并發(fā)性管理建立在每個流程實例占用單個線程的基礎(chǔ)之上，避免創(chuàng)建過多的線程而帶來的線程調(diào)度對系統(tǒng)性能的影響。本文組織結(jié)構(gòu)本文第一章介紹了選題的背景和意義。第二章將闡述與本課題相關(guān)的計算機軟件知識，提出本課題需要解決的關(guān)鍵問題。第三章與第四章將說明設(shè)計原理并進行方案選擇。其中第三章將詳細分析講解

30、ApacheODE流程引擎的核心部分，第四章將通過對JAVA語言和C+語言的對比說明設(shè)計原理并提出方案，闡明選擇這個設(shè)計方案的理由以及所采用方案的特點。第五章與第六章將分點詳細論述設(shè)計，并進行結(jié)果分析。其中第五章將致力于解決如何表達流程執(zhí)行狀態(tài)的問題；第六章將結(jié)合第四章詳細闡述基于C+的BPEL引擎的設(shè)計與實現(xiàn)，致力于解決如何流程執(zhí)行并發(fā)性管理問題。第七章將對整個研究工作進行歸納和綜合，闡述本課題研究中尚存在的問題及進一步開展研究的見解和建議。第二章BPEL理論概述BPEL語言理論知識BPEL全稱是業(yè)務(wù)流程可執(zhí)行語言，用于描述業(yè)務(wù)流程。流程由一系列活動組成；通過作用域定義變量、合作伙伴鏈接、相

31、關(guān)集和事件響應(yīng)處理邏輯等；通過合作伙伴鏈接定義與流程交互的其他服務(wù)；流程可以是有狀態(tài)的長時間運行過程，并且一個流程可以同時存在多個實例，流程引擎通過相關(guān)集將一條消息關(guān)聯(lián)到特定的流程實例。以上是BPEL描述業(yè)務(wù)流程的基本情況，下面詳細介紹OASIS制定的WS-BPEL2.0標準中定義的各個元素，以便加深大家對BPEL的理解。6,14BPEL語言的作用域作用域Scope提供影響其內(nèi)部活動執(zhí)行結(jié)果的上下文環(huán)境，包括變量Friable,合作伙伴鏈接PartnerLink，消息交互MessageExchange，相關(guān)集CorrelationSet，事件處理EventHandler，異常處理FaultHa

32、ndler，補償處理CompensationHandler和終止處理TerminationHandler。作用域上下文環(huán)境可以多層次嵌套，父作用域中定義的環(huán)境在子作用域中可見。每個流程的根節(jié)點Process實際上就是一個頂層作用域。Process和Scope語法上是一致的，但是他們有以下三點區(qū)別：Scope是一個活動而Process不是，活動的標準屬性和成員在Process中不適用；Scope中包含補償處理和終止處理而Process中不允許包含；Scope中特有的isolated隔離屬性在Process中不適用。盡管Process和Scope有所區(qū)別，但BPEL引擎中對他們的處理基本上是一致的

33、，可以認為Process是一個特殊的Scope。每個Scope都包含一個主活動，定義該作用域的業(yè)務(wù)邏輯，這個活動可以是一個復(fù)雜的擁有任意層次嵌套的結(jié)構(gòu)化活動。其他上下文環(huán)境相關(guān)成員是可選的。BPEL對Scope的處理效率由主活動的處理效率決定。BPEL活動的標準屬性和成員在BPEL標準定義的各種元素中，BPEL活動用于表示流程的業(yè)務(wù)邏輯，可分為基礎(chǔ)活動和結(jié)構(gòu)化活動兩種類型?；A(chǔ)活動描述流程業(yè)務(wù)的單個步驟實現(xiàn)，結(jié)構(gòu)化活動則編碼控制流邏輯，能遞歸的包含其他基礎(chǔ)活動或者結(jié)構(gòu)化活動。業(yè)務(wù)流程的執(zhí)行實際上是BPEL活動的執(zhí)行，其他元素只是提供輔助BPEL活動實際執(zhí)行過程中所需的資源。根據(jù)BPEL標準提供

34、的各種基礎(chǔ)活動和結(jié)構(gòu)化活動的多層次嵌套，可以定義任意復(fù)雜的業(yè)務(wù)邏輯，從而實現(xiàn)所需的業(yè)務(wù)功能。BPEL引擎對活動的解析和執(zhí)行效率決定了BPEL引擎的效率。每個活動都包含兩個標準的可選屬性，name和suppressJoinF屬性指定流程中各個活動的機器可讀的命名，用于區(qū)分不同的活動。suppressJoinFailure是在并發(fā)處理的Flow活動執(zhí)行中定義是否屏蔽接合活動異常，具體詳見Flow活動。每個活動都包含兩個可選容器，sources和targets，分別存儲標準成員source和target。source和target用于通過Flow活動中的Link元素確定并發(fā)處理的活動的同步關(guān)系，每個

35、Link對應(yīng)一個source活動和一個target活動，規(guī)定了在source活動執(zhí)行結(jié)束之后，才允許target活動開始執(zhí)行，保證了并發(fā)執(zhí)行的活動中部分活動的同步關(guān)系。具體詳見Flow活動中的Link元素。BPEL基礎(chǔ)活動Invoke調(diào)用Web服務(wù)操作Invoke活動用于調(diào)用服務(wù)提供者提供的Web服務(wù)，典型的應(yīng)用是調(diào)用Web服務(wù)上的一個操作。Invoke可以在其補償處理和異常處理中內(nèi)聯(lián)其他的活動。根據(jù)WSDL文件的定義，操作可以是請求響應(yīng)或者單向調(diào)用。BPEL標準對兩種方式的調(diào)用使用相同的語法，單向調(diào)用方式只需提供輸入變量或者輸入輸出變量都不提供，而請求響應(yīng)方式需要同時提供輸入變量和輸出變量。

36、Receive和Reply提供Web服務(wù)操作Receive和Reply活動用于業(yè)務(wù)流程為其合作伙伴提供服務(wù)。Receive等待合作伙伴發(fā)送請求消息，并根據(jù)createlnstance屬性決定是否創(chuàng)建流程實例。流程啟動活動包括Receive和Pick兩種，流程必須以啟動活動開始，其他活動控制依賴于啟動活動，否則流程將無法執(zhí)行。Receive是一個阻塞活動，只有流程實例接收到一個匹配的消息該活動才會結(jié)束。Reply用于發(fā)送響應(yīng)消息給之前通過Receive活動等接收的請求。這種響應(yīng)只對請求響應(yīng)交互方式有意義。Assign更新變量和合作伙伴鏈接Assign活動用于從一個變量到另一個變量復(fù)制數(shù)據(jù)，或者使

37、用表達式操作變量、屬性和常量來構(gòu)造和插入新的數(shù)據(jù)，或者在合作伙伴鏈接之間復(fù)制端點引用。Throw拋出內(nèi)部異常Throw活動用于顯式拋出內(nèi)部異常。Throw必須提供異常的名稱，可選的提供更多異常相關(guān)信息，對應(yīng)的異常處理可以利用這些信息處理異常，并發(fā)布異常消息到需要的其他服務(wù)。Wait延遲執(zhí)行Wait活動用于指定一段特定時間的延遲或者直到某個期限到來，當指定時間已過或者某個期限到來時，Wait活動馬上結(jié)束。Empty什么事都不做Empty活動并不做任何事，但有些場合往往需要這樣一個活動，比如一個異常需要被捕獲或者禁止。Empty活動的另一個用途是在并發(fā)的Flow活動中提供一個同步點。Extensi

38、onActivity增加活動類型ExtensionActivity活動用于引入BPEL標準未定義的新的活動。（8）Exit立即終止流程執(zhí)行Exit活動用于立即終止業(yè)務(wù)流程實例。除了終止處理、異常處理和補償處理外，流程實例中所有當前正在運行的活動都必須立即終止。（9）Rethrow重新拋出已捕獲的異常Rethrow活動用于異常處理中重新拋出已捕獲的異常。Rethrow只能在異常處理Catch和CatchAll中使用。重新拋出的異常包含的信息是原始捕獲到的異常信息，而不是經(jīng)過異常處理修改過的信息。2.1.4BPEL結(jié)構(gòu)化活動結(jié)構(gòu)化活動規(guī)定了一組活動集合的執(zhí)行順序。結(jié)構(gòu)化活動以不同的結(jié)構(gòu)組合基礎(chǔ)活動

39、，表示不同控制流模式、異常處理、外部事件以及業(yè)務(wù)協(xié)議中流程實例之間的消息交互協(xié)調(diào)。結(jié)構(gòu)化活動可以以任意方式嵌套和組合。通過基礎(chǔ)活動和結(jié)構(gòu)化活動的多層次嵌套，可以創(chuàng)建出表達任意復(fù)雜業(yè)務(wù)邏輯的流程4。BPEL標準定義多種結(jié)構(gòu)化活動，實現(xiàn)了不同的控制流模式。BPEL標準定義的結(jié)構(gòu)化活動集合并不是最小集，有些情況下一個業(yè)務(wù)邏輯可以用不同的活動來實現(xiàn)。比如一個順序業(yè)務(wù)邏輯可以使用Sequence活動實現(xiàn)，也可以使用定義合適Links的Flow實現(xiàn)。而Sequence和Flow是BPEL結(jié)構(gòu)化活動中最重要的兩個。（1）Sequence順序執(zhí)行Sequence活動包含一個或多個按照出現(xiàn)順序先后執(zhí)行的子活動，

40、當最后一個子活動執(zhí)行結(jié)束時Sequence活動結(jié)束。（2）Flow并行和控制依賴處理Flow活動提供并發(fā)和同步機制。Flow的子活動并發(fā)執(zhí)行，當所有子活動都結(jié)束時Flow才結(jié)束。子活動使能判斷為假而跳過執(zhí)行也認為該子活動結(jié)束。Flow同時啟動各個子活動執(zhí)行,其子活動的各層次子活動之間可能存在同步依賴，因此Flow通過定義Link提供Flow內(nèi)部各層次子活動之間的同步依賴。每個活動都有可選的sources和targets容器，分別包含一組source和target元素，這些元素通過Link確定活動之間的同步關(guān)系。一個Link分別對應(yīng)一個source活動和target活動，規(guī)定在source活動執(zhí)

41、行結(jié)束之前target活動不允許開始執(zhí)行。一個活動可以設(shè)置多個source，也可以設(shè)置多個target。targets容器中有個可選參數(shù)joinCondition定義多個target的布爾組合方式，默認是或，即該活動對應(yīng)的多個source活動只要有一個完成即可開始執(zhí)行該活動。Link定義的過程中不能形成控制環(huán)，即一個source活動對應(yīng)的target活動是其邏輯在前的。2.1.5其他結(jié)構(gòu)化活動除了Sequence和Flow，結(jié)構(gòu)化活動還有Pick（事件觸發(fā)選擇處理）、ForEach（遍歷執(zhí)行）、While、RepeatUntil（循環(huán)執(zhí)行）、If、Elseif（選擇執(zhí)行）等等。這類結(jié)構(gòu)化活動的

42、定義主要是為了能貼近人類語言，按照用戶指定的表達式有選擇地執(zhí)行活動。他們的表達式的解析和條件的判定由該活動本身的執(zhí)行方法處理，然后按照用戶的定義，以串行或者并行的方式來調(diào)度他們。我們可以認為，在流程引擎內(nèi)部，活動總是以串行或者并行的方式進行調(diào)度和執(zhí)行，對其他的活動類型并不關(guān)心。Sequence和Flow結(jié)構(gòu)化活動是流程引擎的主要工作模式和設(shè)計重點，實現(xiàn)了穩(wěn)定可靠的串行與并行控制機制，就能在此基礎(chǔ)上執(zhí)行其他結(jié)構(gòu)化活動。因此，我們把Sequence和Flow活動作為關(guān)鍵點進行研究。本章小結(jié)本章主要介紹了BPEL語言的基礎(chǔ)理論，描述了BPEL基本活動與結(jié)構(gòu)化活動的標準屬性和成員，并說明了為什么SEQ

43、UENCE和FLOW是流程引擎處理的關(guān)鍵活動類型。為下文鋪開APACHEODE流程引擎的設(shè)計，提出基于C+的BPEL流程引擎原型設(shè)計方案中如何解決處理并發(fā)控制部分作理論知識介紹。第三章關(guān)于ApacheODE流程引擎的研究ODE的主要開發(fā)目標是開發(fā)可靠的，結(jié)構(gòu)緊湊的，可嵌入的組件，能夠管理使用BPEL流程描述語言的長時間運行的業(yè)務(wù)流程的執(zhí)行。重點是開發(fā)具有最小依賴性的小模塊，以便重新組裝成一個功能齊全的業(yè)務(wù)流程管理系統(tǒng)。4,16ApacheODE結(jié)構(gòu)總覽ODE架構(gòu)中的關(guān)鍵組成部分包括BPEL編譯器、ODEBPEL引擎運行時，ODE數(shù)據(jù)訪問對象(DAOs),ODE集成層(ILs),和用戶工具16。

44、編譯器把BPEL文件轉(zhuǎn)換成運行時可執(zhí)行的格式，運行時以一種可靠方式執(zhí)行他們，并通過DAO層把他們保存起來；運行時在集成層中運行，集成層將BPEL引擎連接到更為廣闊的外部執(zhí)行環(huán)境。圖3.1APACHEODE流程引擎架構(gòu)圖3.1.1為什么選擇參考ApacheODE流程引擎為了研究流程引擎的內(nèi)部機制，必需研究學習其源代碼，因為我們首先考慮開源項目。而在諸多開源項目中，ApacheODE流程引擎是嚴格按照BPEL標準制訂，有詳細規(guī)范文檔可參閱的項目之一。其他流程引擎，如JBPM，擴展了BPEL，加入了其他繁雜的功能，增加了分析的難度。因此選擇參考ApacheODE引擎能拋開其余干擾，在其嚴格的標準下研

45、究流程引擎的內(nèi)部機制。ODEBPEL編譯器BPEL編譯器負責把BPEL來源（即BPEL流程文件，WSDLs和schemas）編譯成可執(zhí)行的形式。編譯器的輸出結(jié)果不是一個“好的”編譯表現(xiàn)結(jié)果，也不是這些源文件的錯誤信息列表。編譯器生成的結(jié)果是一種對象模型，類似于基本BPEL流程文件的結(jié)構(gòu)。但是，這種變異結(jié)果解決了BPEL中出現(xiàn)的各種名稱引用（如變量名），內(nèi)聯(lián)了所需的WSDL和類型信息，并生成了各種結(jié)構(gòu)（如默認的補償處理）。這些編譯結(jié)果（通常是一個擴展名為cbp的文件）是BPEL運行所需的唯一對象。ODEBPEL引擎運行時ODEBPEL引擎運行時在BPEL運行時模塊中建立，提供給BPEL流程執(zhí)行的

46、。運行時提供了大量BPEL結(jié)構(gòu)的實現(xiàn)，以處理流程執(zhí)行中最復(fù)雜繁瑣的工作。運行時同時也實現(xiàn)了何時應(yīng)當創(chuàng)建新實例，和把剛收到的消息分發(fā)給哪個實例的邏輯。最后，運行時實現(xiàn)了流程管理的API以供用戶工具使用。為了在不可靠的環(huán)境中實現(xiàn)可靠的執(zhí)行過程，運行時依賴于數(shù)據(jù)訪問對象（DAOs）提供的持續(xù)設(shè)施。這些DAOs的實現(xiàn)可自定義，但通常提供了與關(guān)系數(shù)據(jù)庫的交互。BPEL結(jié)構(gòu)的運行時在實例級上是通過ODE的Java并發(fā)對象（Jacob）框架實現(xiàn)的Jacob提供了一個應(yīng)用級的不依賴于線程的并發(fā)機制和一個提供執(zhí)行中斷與恢復(fù)的透明機制。Jacob是Java實現(xiàn)ACTORSAgha并發(fā)模型中非常大的一塊，其流程代數(shù)

47、有許多功能，如Picalculus。本質(zhì)上來說，Jacob為BPEL的執(zhí)行提供了一個持久穩(wěn)固的虛擬機。ODE數(shù)據(jù)訪問對象（DAOs）ODE數(shù)據(jù)訪問對象作為BPEL引擎運行時與底層數(shù)據(jù)存儲間交互的媒介。通常，數(shù)據(jù)存儲是一個JDBC關(guān)系數(shù)據(jù)庫：既然如此，那么DAOs就是使用OpenJPA數(shù)據(jù)訪問庫來實現(xiàn)的。這樣就能夠創(chuàng)建自定義的DAO實現(xiàn)，即使JDBC沒有提供相關(guān)實現(xiàn)，也能以某種機制達到持久化保存的目的。BPEL引擎運行時需要DAO對象來以處理以下持久化的問題：（1）積極的情況下知道哪一個實例被創(chuàng)建；（2）消息路由哪一個實例正在等待哪一條消息；（3）變量每一個實例的BPEL變量的值；（4）合作伙伴

48、鏈接每一個實例的BPEL合作伙伴連接的值；（5）流程執(zhí)行狀態(tài)Jacob的持久穩(wěn)固虛擬機的序列化狀態(tài)。有關(guān)OpenJPA/JDBCDAO的實現(xiàn)，和相關(guān)組織信息通常在FIGREF中提供。ODE集成層ODEBPEL引擎運行時不能在真空中存在：它自己本身是不能影響與外部世界交往的。為此它依賴于一個ODE集成層（ILs）。集成層將運行嵌入一個執(zhí)行環(huán)境。例如，有一個集成層AXIS2和JBI。集成層的基本功能是為運行時提供通道間的通信。AXIS2集成層使用AXIS2庫，讓運行時以Web服務(wù)的方式與外加交互。JBL集成層則嘗試把運行時加入JBI消息總線達到同樣的目的。除了通訊以外，集成層還為運行時提供了線程管

49、理機制，并管理運行時的整個生命周期，例如配置和啟動運行時。APACHEODE流程引擎的JACOB框架3.2.1什么是JACOBJACOB卩JavaConcurrentObjects（Java并發(fā)對象），是APACHEODE引擎的內(nèi)核框架。ODE依賴于JACOB框架去實現(xiàn)BPEL的構(gòu)建?？蚣芴峁┮恍C制去解決兩個構(gòu)建BPEL的關(guān)鍵問題：執(zhí)行狀態(tài)的持久化，并發(fā)處理17。卩使是用戶只有一個線程，代碼也能夠拆解成并發(fā)處理的問題。通過把整個事務(wù)分解為一些較小的部分，我們就可以控制到那些真正被調(diào)用和執(zhí)行的部分。比如說，我們有一個按照以下次序來執(zhí)行一個過程：InvokeReceiveWaitInvoke如果

50、有兩個進程我們需要同時處理，簡單的實現(xiàn)方法是這樣：Invoke1Receive1Wait1Invoke1Invoke2Receive2Wait2Invoke2但是如果我們把代碼分解，引進一個所謂的“中間人”（或者稱為棧），并且不允許活動直接地進行相互調(diào)用，我們就有了以下的調(diào)用次序：Invoke1Invoke2Receive1Wait1Receive2Wait2Invoke1Invoke2從客戶的角度來看，我們就實現(xiàn)了利用單線程達到并發(fā)的效果。在實際情況中，一些活動可能會持續(xù)幾天，倘若進程發(fā)生錯誤時，進程的執(zhí)行狀態(tài)就會丟失。所以用類似“掛起”這種能把執(zhí)行狀態(tài)保存在磁盤的操作會更好。然而把進程掛起

51、到磁盤上存在著一些實現(xiàn)上的問題。在我們希望“掛起”時，調(diào)用?？雌饋硎沁@樣的：Sequence.run()Wait.run()為了把進程保存到磁盤上，我們需要終止當前的控制進程，這就意味著要彈出所有棧結(jié)構(gòu)。要做到這些，我們只有通過等待活動(Wait)和順序活動(Sequence)的實現(xiàn)去迎合這種需求，因此帶來的會是實現(xiàn)復(fù)雜程度的增加。并且這也意味著所謂“自然”(即符合人們正常思維)的模型不能夠被直接使用。JACOB的目標就是提供一個可選的“自然”的模型來解決這個問題。這個模型能夠允許執(zhí)行狀態(tài)被掛起，但是卻不需要實現(xiàn)類(如wait，Sequence)等做出特別的更改。JACOB的思想就是不使用調(diào)用

52、堆棧，而是以來自外部的通信渠道(communicationchannel)來控制流程。通道Channels如上所述，通道是用于流程執(zhí)行環(huán)境中活動的通信的接口。通道有終結(jié)通道(TerminationChannel)，父事務(wù)范圍通道(ParentScopeChannel)和補償通道(CompensationChannel)等幾種。某些簡單的通道能使所有活動在創(chuàng)建時就能與其環(huán)境相互作用。當一個活動想要通知其的父級活動他已經(jīng)結(jié)束執(zhí)行，那么這個活動就會調(diào)用其父級活動的終結(jié)通道。通道主要由通道工廠(ChannelFactory)中的動態(tài)協(xié)議提供。Jacob對象(JacobObject與Jacob可運行的線

53、程狀態(tài)(JacobRunnable)如果你不在乎細節(jié)的話，那么Jacob對象和Jacob可運行的線程狀態(tài)就是方法的實現(xiàn)。當抽象執(zhí)行的時候，這個方法就會執(zhí)行。一個Jacob對象就是一個閉包。維基百科對閉包有如下解釋：“一個閉包是一組由特定文法環(huán)境約束的函數(shù)源碼。閉包文法變量與全局變量的區(qū)別在于，他們并不出現(xiàn)在全局變量的名空間。他們區(qū)別與面向?qū)ο蟮膶ο笞兞吭谟冢麄兗s束于方法，而不是對象。”一般而言Java語言并不支持閉包，所以Jacob對象嘗試解決這個問題。但Jacob對象的解決方案并不是一個真正意義上的閉包，而只是使問題變得簡單些。閉包在Java語言中是靜態(tài)編碼的，但是在其他大多數(shù)語言支持的閉

54、包是動態(tài)的。所以在Jacob中，一個閉包應(yīng)當實現(xiàn)某些方法，并提供其他公共方法以控制通道和復(fù)制自身。Jacob可運行的線程狀態(tài)就是一個實現(xiàn)了run（）方法的Jacob對象。因為所有的活動都繼承了Jacob可運行的線程狀態(tài)，因此這些活動都應(yīng)當在這個run（）方法中實現(xiàn)他們的主要處理。他們的初始化階段在各自的構(gòu)造器中完成。方法集MethodLists（MLs）方法集MethodLists類可以看作是通道的另一端。當只調(diào)用一個通道方法的時候，他們并不會被援引，但是一旦Jacob引擎把通道援引從其內(nèi)部堆棧中頂出來，就會援引方法集（此處能再次看到執(zhí)行堆棧是如何被中止的）。通常方法集的實現(xiàn)在預(yù)引導(dǎo)執(zhí)行環(huán)境中

55、是內(nèi)聯(lián)的，因為這樣比較容易在活動的run方法中申明。對象方法繼承于Jacob對象，這也是一個提交方法集到Jacob的辦法。因此該Jacob運行時就能匹配后面的通道消息。虛擬處理單元（VirtualProcessUnit和口執(zhí)行隊列（ExecutionQueue）虛擬處理單元VPU是所有Jacob處理發(fā)生的地方。當一個Jacob對象被注入虛擬處理單元的時候，他實際上被認為是一個持久化部分（Continuation），該部分包裹了調(diào)用Jacob對象并執(zhí)行該對象的方法（在我們的實例中，這總是run方法，因為我們只處理Jacob可運行的線程狀態(tài)的實例）。執(zhí)行隊列（ExecutionQueue，與其實現(xiàn)

56、FastExecutionQueuelmpl）是虛擬處理單元管理的人工環(huán)境容器，并且將這些人工環(huán)境組織成可推入（push）可浮出（pop）的隊列形式，同時記錄各項執(zhí)行統(tǒng)計。所以虛擬處理單元的主要功能是從SOUP中出列一個回應(yīng)（reaction），然后通過調(diào)用其抽象run方法來執(zhí)行他（這個回應(yīng)包裹了這樣一個抽象）。然而當Jacob可運行的線程狀態(tài)（通常是一個活動）被執(zhí)行后，有可能發(fā)生一下事情：（1）如果創(chuàng)建了別的抽象，他們就會插入回應(yīng)隊列；（2）如果創(chuàng)建了新的通道，他們就會被保存起來留給以后使用；（3）如果援引了別的通道，該信息將被保存起來以與新的ML匹配；（4）如果創(chuàng)建了一個新的方法集，那么他

57、將被提交至虛擬處理單元以嘗試匹配一個channel援引。虛擬處理單元也負責維持其內(nèi)部狀態(tài)。因此當一個執(zhí)行暫停（例如我們的過程有一個接收活動）的時候，虛擬處理單元的狀態(tài)將序列化，作為一個持久化部分保存到磁盤，當收到繼續(xù)執(zhí)行的時候再讀入此持久化部分，繼續(xù)執(zhí)行。這個邏輯可以參考RuntimeContextImpl的execute方法。還有一點必需指出的是，持久化部分（Jacob可運行的線程狀態(tài)也是）不會“停留”在虛擬處理單元的隊列中。他們只會浮出、執(zhí)行。所以如果一個抽象有持續(xù)的并多于一個操作的時候，他會簡單的執(zhí)行，生成子活動加入隊列。實例解析Whilewhilecondition=bpws:getV

58、ariableData(var1,TestPart)一切都從接收開始。所以我們首先從BpelProcess.PartnerLinkMyRoleImpl.inputMsgRcvd()開始討論Jacob-focused。以下是重要的代碼(當信息到達實例的時候開始執(zhí)行)：BpelRuntimeContextImplinstance=createRuntimeContext(newInstance,newPROCESS(_oprocess),messageExchange);/runthevpuinstance.execute();!BpelRuntimeContextImpl構(gòu)造器中有如下代碼：if

59、(PROCESS!=null)vpu.inject(PROCESS);這里注入了一個流程(Process)o當開始執(zhí)行的時候，流程例示了他對其子活動的執(zhí)行的控制范圍，并且開始監(jiān)聽對消通道和完成通道。從流程我們可以得到范圍(Scope)，然后是我們的主順序活動(Sequence)，最后是我們的接收(Receive)。接收被映射到一個獲取消息PICK上，因此其Jacob實現(xiàn)寫在PICK中。PICK主要是分離出正確的相互關(guān)系，再選擇合適的消息，然后等到消息。在實例中，我們對BpelRuntimeContextlmpl.select()(andcalledbyPICK)中的代碼更感興趣：if(_ins

60、tantiatingMessageExchange!=null&_dao.getState()=ProcessState.STATE_READY)for(inti=0;icorrelators.size();+i)CorrelatorDAOci=correlators.get(i);if(ci.equals(_dao.getInstantiatingCorrelator()inputMsgMatch(pickResponseChannelStr,i,_instantiatingMessageExchange);return;這里會調(diào)用類似如下的東西:vpu.inject(newJacobRun