【正文】 和其對BPEL的支持。它說明了如何開發(fā)在BizTalk業(yè)務(wù)流程，并導(dǎo)出到BPEL。它還介紹了如何導(dǎo)入的BizTalk BPEL流程，以及如何使用業(yè)務(wù)流程設(shè)計工具，圖形化流程定義，并比較BizTalk和BPEL的結(jié)構(gòu)。附錄A提供了對BPEL 。附錄部分包括標(biāo)準(zhǔn)BPEL活動和要素，功能，屬性和故障。為了測試第3，4，5，6和7章的代碼，你需要有Oracle BPEL流程管理器。在您的系統(tǒng)中安裝（），以及微軟的BizTalk Server 2004（）。下面是例子，以及對它們的意義的解釋。這里有三種風(fēng)格的代碼。文本編碼字如下：我們可以通過使用包括其他環(huán)境中的include指令。當(dāng)我們想請你注意一個代碼塊的特定部分時，有關(guān)的鏈接或項目將被進(jìn)行了加粗的：新的術(shù)語和重要的詞是一個加粗的類型字體介紹。你可以再書上看到，菜單或?qū)υ捒?，在我們這樣的文字顯示：“點(diǎn)擊下一步按鈕知道你看到下一個屏幕。從我們讀者那得到反饋始終是我們最欣喜的。以此讓我們知道您對這本書，是喜歡還是不喜歡，也可能有一些特別的想法。讀者的反饋一直是我們發(fā)展的重要動力。反饋給我們的方式，只需要電子郵件至feedback@，同時確保您的郵件主題是書名。如果有一本書，你希望我們幫你出版，請給我們另外發(fā)郵件，請發(fā)送至 @，同時要注明所有權(quán)形式。如果有問題的話， /作者指南。訪問，可以選擇和下載本書的任何示例代碼或額外資源?？晒┫螺d的文件將都被顯示出來。下載的文件中包含有關(guān)如何使用它們的說明。盡管我們已采取一切謹(jǐn)慎措施，確保我們的內(nèi)容的準(zhǔn)確性，但是錯誤時有發(fā)生。如果您發(fā)現(xiàn)在我們的圖書，也許存在錯誤的文字或錯誤代碼，我們將不勝感激，如果你向我們提出報告。這樣您可以節(jié)省其他讀者時間，讓他們少走彎路，并有助于提高這本書的后續(xù)版本。如果您發(fā)現(xiàn)任何錯誤，報告他們通過，在提交勘誤點(diǎn)擊鏈接，并輸入您的勘誤表的細(xì)節(jié)。一旦你的勘誤表已核實(shí)，您的申請將被接受和勘誤表添加到現(xiàn)有的勘誤表?，F(xiàn)有的勘誤表，可以通過選擇。你可以發(fā)郵件回至questions@，如果你存在一些與本書有關(guān)的問題，我們將盡一切努力來解決這一問題。10 BPEL和SOASOA：面向服務(wù)的體系結(jié)構(gòu)（ServiceOriented Architecture，SOA）是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以一種統(tǒng)一和通用的方式進(jìn)行交互。松耦合的系統(tǒng):這種具有中立的接口定義（沒有強(qiáng)制綁定到特定的實(shí)現(xiàn)上）的特征稱為服務(wù)之間的松耦合。松耦合系統(tǒng)的好處有兩點(diǎn)，一點(diǎn)是它的靈活性，另一點(diǎn)是，當(dāng)組成整個應(yīng)用程序的每個服務(wù)的內(nèi)部結(jié)構(gòu)和實(shí)現(xiàn)逐漸地發(fā)生改變時，它能夠繼續(xù)存在。而另一方面，緊耦合意味著應(yīng)用程序的不同組件之間的接口與其功能和結(jié)構(gòu)是緊密相連的，因而當(dāng)需要對部分或整個應(yīng)用程序進(jìn)行某種形式的更改時，它們就顯得非常脆弱。對松耦合的系統(tǒng)的需要來源于業(yè)務(wù)應(yīng)用程序需要根據(jù)業(yè)務(wù)的需要變得更加靈活，以適應(yīng)不斷變化的環(huán)境，比如經(jīng)常改變的政策、業(yè)務(wù)級別、業(yè)務(wù)重點(diǎn)、合作伙伴關(guān)系、行業(yè)地位以及其他與業(yè)務(wù)有關(guān)的因素，這些因素甚至?xí)绊憳I(yè)務(wù)的性質(zhì)。我們稱能夠靈活地適應(yīng)環(huán)境變化的業(yè)務(wù)為按需（On demand）業(yè)務(wù)，在按需業(yè)務(wù)中，一旦需要，就可以對完成或執(zhí)行任務(wù)的方式進(jìn)行必要的更改。　雖然面向服務(wù)的體系結(jié)構(gòu)不是一個新鮮事物，但它卻是更傳統(tǒng)的面向?qū)ο蟮哪Ｐ偷奶娲Ｐ停嫦驅(qū)ο蟮哪Ｐ褪蔷o耦合的，已經(jīng)存在二十多年了。雖然基于 SOA 的系統(tǒng)并不排除使用面向?qū)ο蟮脑O(shè)計來構(gòu)建單個服務(wù)，但是其整體設(shè)計卻是面向服務(wù)的。由于它考慮到了系統(tǒng)內(nèi)的對象，所以雖然 SOA 是基于對象的，但是作為一個整體，它卻不是面向?qū)ο蟮摹２煌幵谟诮涌诒旧?。SOA 系統(tǒng)原型的一個典型例子是通用對象請求代理體系結(jié)構(gòu)（Common Object Request Broker Architecture，CORBA），它已經(jīng)出現(xiàn)很長時間了，其定義的概念與 SOA 相似。然而，現(xiàn)在的 SOA 已經(jīng)有所不同了，因為它依賴于一些更新的進(jìn)展，這些進(jìn)展是以可擴(kuò)展標(biāo)記語言（eXtensible Markup Language，XML）為基礎(chǔ)的。通過使用基于 XML 的語言（稱為 Web 服務(wù)描述語言（Web Services Definition Language，WSDL））來描述接口，服務(wù)已經(jīng)轉(zhuǎn)到更動態(tài)且更靈活的接口系統(tǒng)中，非以前 CORBA 中的接口描述語言（Interface Definition Language，IDL）可比了。Web 服務(wù)并不是實(shí)現(xiàn) SOA 的惟一方式。前面剛講的 CORBA 是另一種方式，這樣就有了面向消息的中間件（MessageOriented Middleware）系統(tǒng)，比如 IBM 的 MQseries。但是為了建立體系結(jié)構(gòu)模型，您所需要的并不只是服務(wù)描述。您需要定義整個應(yīng)用程序如何在服務(wù)之間執(zhí)行其工作流。尤其需要找到業(yè)務(wù)的操作和業(yè)務(wù)中所使用的軟件的操作之間的轉(zhuǎn)換點(diǎn)。因此，SOA 應(yīng)該能夠?qū)I(yè)務(wù)的商業(yè)流程與它們的技術(shù)流程聯(lián)系起來，并且映射這兩者之間的關(guān)系。例如，給供應(yīng)商付款的操作是商業(yè)流程，而更新您的零件數(shù)據(jù)庫，以包括進(jìn)新供應(yīng)的貨物卻是技術(shù)流程。因而，工作流還可以在 SOA 的設(shè)計中扮演重要的角色。此外，動態(tài)業(yè)務(wù)的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作伙伴進(jìn)行的操作。因此，為了提高效率，您需要定義應(yīng)該如何得知服務(wù)之間的關(guān)系的策略，這種策略常常采用服務(wù)級協(xié)定和操作策略的形式。 現(xiàn)有資源的重用性?，F(xiàn)有資源不加修改就可加入現(xiàn)有的業(yè)務(wù)系統(tǒng)。服務(wù)的組件性。將業(yè)務(wù)系統(tǒng)中的功能實(shí)現(xiàn)以功能或業(yè)務(wù)需求為基礎(chǔ)，粗粒度地包裝成相對獨(dú)立地單元對外界提供無狀態(tài)地服務(wù)。服務(wù)的隨需應(yīng)變性。隨著企業(yè)業(yè)務(wù)需求的變化，其所提供的服務(wù)也會隨之改變。SOA系統(tǒng)應(yīng)該具有很強(qiáng)的敏捷性，快速適應(yīng)業(yè)務(wù)需求的變化，對軟件系統(tǒng)只做很少的調(diào)整就能適應(yīng)新業(yè)務(wù)的需求。讓我們再來回顧以下SOA的這些特點(diǎn)是如何獲得的？大家也許還記得所謂的SOA鐵三角，它說明了SOA所致力于解決的三大問題，以及采用了什么樣的技術(shù)來解決的。SOA架構(gòu)需要一種基于開放的，與后端數(shù)據(jù)源無關(guān)的，能夠清晰表達(dá)業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)模型。SDO很好地解決了這一問題。它基于中立的XML Schema，將業(yè)務(wù)數(shù)據(jù)封裝成業(yè)務(wù)對象，系統(tǒng)可以采用離線的方式對其進(jìn)行訪問和更新，而不用考慮任何與數(shù)據(jù)源和實(shí)現(xiàn)相關(guān)的問題。這使得業(yè)務(wù)數(shù)據(jù)能夠建模為數(shù)據(jù)對象而成為相對獨(dú)立的實(shí)體存在于系統(tǒng)之中并可以在系統(tǒng)的各組件之間進(jìn)行傳遞。而SCA標(biāo)準(zhǔn)則解決了服務(wù)的封裝和調(diào)用問題。SOA的特點(diǎn)決定了SOA不可能是集中式的管理，服務(wù)是SOA的基本單位，任何服務(wù)在SOA中都是平等的。對服務(wù)的調(diào)用者看來，任何服務(wù)的調(diào)用都應(yīng)該是一致的方式，不應(yīng)該因服務(wù)的實(shí)現(xiàn)是Java程序還是C++程序而不同。SCA實(shí)現(xiàn)了服務(wù)的組件化，每一個服務(wù)不論其提供的功能和實(shí)現(xiàn)的方式，在SOA系統(tǒng)中都被看做服務(wù)組件，它們之間的調(diào)用都是松耦合的。SOA就好像搭積木，SDO和SCA為我們準(zhǔn)備好了所需的積木，只是它們還現(xiàn)在處于一種無序狀態(tài)，一兩塊“積木”的簡單組合顯然無法滿足企業(yè)復(fù)雜的業(yè)務(wù)需求。BPEL的作用就是將這些積木“搭”起來從而形成我們想要的東西。BPEL：全稱為Business Process Execution Language,即業(yè)務(wù)流程執(zhí)行語言，是一種使用XML編寫的編程語言。用于自動化業(yè)務(wù)流程，也曾經(jīng)被稱作WSBPEL和 BPEL4WS。廣泛使用于Web服務(wù)相關(guān)的項目開發(fā)中，優(yōu)點(diǎn)為具有可移植性和有效保護(hù)了投資。BPEL是一門用于自動化業(yè)務(wù)流程的形式規(guī)約語言。 用XML文檔寫入BPEL中的流程能在Web 服務(wù)之間以標(biāo)準(zhǔn)化的交互方式得到精心組織。這些流程能夠在任何一個符合BPEL規(guī)范的平臺或產(chǎn)品上執(zhí)行。 所以，通過允許顧客們在各種各樣的創(chuàng)作工具和執(zhí)行平臺之間移動這些流程，BPEL使得他們保護(hù)了他們在流程自動化上的投資。盡管以前想使業(yè)務(wù)流程定義標(biāo)準(zhǔn)化，但BPEL已經(jīng)引起了史無前例的興趣，而且它最早在軟件供應(yīng)商中獲得大量認(rèn)可。BPEL、WSBPEL和 BPEL4WS之間除了歷史參考文獻(xiàn)不同外，沒有什么其他的不同。這些名字都涉及到相同的未決標(biāo)準(zhǔn)?！癇PEL4WS”是起初規(guī)范的名字，它由BEA、IBM和Microsoft編寫和公布的?！癢SBPEL”目前是規(guī)范和未決標(biāo)準(zhǔn)的名稱。當(dāng)這個規(guī)范提交到OASIS時,出于Web服務(wù)相關(guān)標(biāo)準(zhǔn)的努力，按照OASIS命名方案更換了這個名字。盡管如此，大部分團(tuán)體仍然簡單地稱這個標(biāo)準(zhǔn)為“BPEL”。商業(yè)流程執(zhí)行語言BPEL4WS(Business Process Execution Language For Web Services)是專為整合Web Services而制定的一項規(guī)范標(biāo)準(zhǔn)。BPEL的作用是將一組現(xiàn)有的服務(wù)組合起來，從而定義一個新的Web服務(wù)。因此，BPEL基本上是一種實(shí)現(xiàn)此種組合的語言。組合服務(wù)的接口也被描述為WSDL port Type的集合。按業(yè)務(wù)流程之間的協(xié)作方式可以分為單工作流模式和多工作流模式。單工作流模式把一組相關(guān)的服務(wù)按一定順序和條件組合執(zhí)行，完成某項業(yè)務(wù)，流程執(zhí)行過程中涉及的服務(wù)不屬于其他業(yè)務(wù)流程。多工作流模式是兩個或兩個以上的工作流程并行執(zhí)行并進(jìn)行交互的業(yè)務(wù)流程模式，多工作流模式側(cè)重于業(yè)務(wù)流程之間的交互。我們再來看看BPEL流程是怎樣與SDO結(jié)合的。由于BPEL支持將XML Schema定義的數(shù)據(jù)類型直接定義為BPEL的流程變量，因此在SOA系統(tǒng)中，BPEL和業(yè)務(wù)對象可以共享相同的SDO定義。圖中的虛線表示了在SOA系統(tǒng)中，業(yè)務(wù)對象是如何在BPEL流程中使用的。BPEL流程服務(wù)的使用者調(diào)用SCA組件將業(yè)務(wù)對象BO1傳人SCA組件1，業(yè)務(wù)對象BO1會被BPEL流程接收，并啟動新的BPEL流程實(shí)例。BPEL流程根據(jù)所調(diào)用的SCA接口定義，生成BO2，BO3和BO4，并用它們分別傳遞給SCA組件2，3和4，從而實(shí)現(xiàn)這些SCA組件按照預(yù)定的次序執(zhí)行。我們看到業(yè)務(wù)對象在SCA中以及BPEL流程中始終采用一致的定義模型，并不需要進(jìn)行任何轉(zhuǎn)換。因此，BPEL與SDO的很好結(jié)合使得BPEL在數(shù)據(jù)層面上融入了SOA，而BPEL與SCA的很好結(jié)合使得BPEL在服務(wù)層面上融入了SOA體系結(jié)構(gòu)。BPEL與SDO和SCA一起構(gòu)成了SOA的基石。圖1412用層次化的結(jié)構(gòu)說明了BPEL在SOA中的地位和作用。服務(wù)組件層將以服務(wù)組件為單位提供單個服務(wù)的封裝，對外隱藏了服務(wù)的實(shí)現(xiàn)細(xì)節(jié)，SCA規(guī)范可作為這一層等的實(shí)現(xiàn)技術(shù)。服務(wù)層則是單個的服務(wù)或是多個服務(wù)組件的簡單連接。用戶可以直接訪問這一層而獲取所需的服務(wù)。但這一層的服務(wù)多是單個服務(wù)組件或多個服務(wù)組件的簡單組合所提供的服務(wù)。但是復(fù)雜的業(yè)務(wù)流程需要對多個服務(wù)組件按照預(yù)定邏輯進(jìn)行組織和編排，這就是業(yè)務(wù)過程層所起的作用。BPEL規(guī)范是實(shí)現(xiàn)業(yè)務(wù)過程層的合適技術(shù)。因此，一般來說BPEL流程位于SOA的上層，是與企業(yè)的業(yè)務(wù)邏輯關(guān)系最為密切的一層。