利用ESB虛擬化 BPEL流程服務端點

自 Oracle 將企業服務總線 (ESB) 作為 SOA 套件的一部分發布以來，許多人都很好奇，與僅在 Oracle BPEL 流程管理器內進行完整的自包含實施相比，ESB 所具有的附加值及其使用場合。

它的優勢之一是能夠對其用戶透明地虛擬化服務端點，從而提供從其自有格式到規范格式的轉換以及可靠路由。

在該技術說明中，您將通過兩個有指導的步驟了解如何通過重用現有產品采用 BPEL 流程來利用 ESB 將原有服務虛擬化，以及這樣做可以獲得怎樣的寶貴價值。

設置

現在，開始啟動流程，您將通過應用該流程了解使用 BPEL 和 ESB 的最佳實踐。我們已經創建了一個使用公用模式的異步流程，它代表一個規范的客戶請求，以下為部分摘錄：

該規范客戶請求 (CustomerUpdateProcessProcessRequest) 包含名稱 (customerName)、信用卡類型 (ccard)、信用卡號 (ccardNr)，以及電子郵件地址 (email) 和口令 (pw)。

本說明中探討的示例流程將更新一個原有系統(在本例中為一個數據庫)，該系統最后將由不同的數據結構替代，如下所示。

該轉換利用 XSL(XML 樣式表轉換)(之后可在系統中重用)。部分代碼摘錄如下所示。

第 1 步：不修改流程源而將原有服務調用移至 ESB 中

現在，流程已就位，周邊情況已設定，第一個目標就是虛擬化 ESB 系統后的真實服務，并使調用對該 BPEL 流程變得透明。

應用該模式可使流程松散，但在其基礎架構服務方面仍具有可靠的耦合，且無需知曉這些服務內容。如此，更改某項服務時就不會導致整體服務崩潰或更改。

因為 BPEL 流程內創建的文件具有很高的可重性，所以無需更改就可用于任何一個 ESB 系統內。

開始之前，在創建了新的 ESB 項目后，所有與 partnerlink 有關的文件都需在 ESB 項目中可引用。在生產環境中，架構師會將其存儲在一個集中的模式服務器上或信息庫中，以確保這些文件只存在一個副本。為了簡單起見，您可以復制他們。

在使用數據庫適配器的情況下(本例即是如此)，要復制的文件是

• DBAdapterOutboundHeader.wsdl(頭描述)
• UpdateCustomer.wsdl(partnerlink 的服務定義)
• UpdateCustomer_toplink_mappings.xml(TopLink 映射)
• UpdateCustomer_table.xsd(數據定義)

執行完上述操作后，這些文件就可在新創建的 ESB 系統中重用了。第一步是以 UpdateCustomer.wsdl 為基礎創建一個新服務 (UpdateCustomerService)(如下所示)。

其結果將是流程中 partnerlink 的一個完美克隆，它公開兩個操作：合并和寫入。一旦所有所需文件都可使用后，ESB 就可確定該服務的類型了：

接下來，創建一個使用同一定義 (WSDL) 的路由服務 (Routing Service)，以向外部公開合并/寫入操作。將其命名為 PlainExposed 并包含兩個路由規則，以只將請求轉發至由數據庫適配器公開的相應操作。

在 ESB 系統圖中應用了更改后，將如下所示。

創建了該系統并將其注冊到企業服務總線后，BPEL 流程就可使用它了 — 目前只能在運行時使用。

Oracle BPEL 流程管理器在 partnerlink 級提供了一個標志來為服務定義 (WSDL) 指定運行時位置。與編譯時用于類型驗證的位置不同，該位置用于調用。該標志名為 wsdlRuntimeLocation，如果設置了該標志，則它必須指向具體的 WSDL(其中包含一個綁定)。在本例中，它指向了 PlainExposed 路由服務的定義，該服務可在 ESB 控制臺 (ESB Console) 中找到。在運行時，通過只在運行而非加載時獲取綁定 WSDL，BPEL 流程將盡可能晚地進行綁定。

在 BPEL 流程內，可以直觀地添加該屬性(雙擊 partnerlink 即可)，如下所示。

重新部署了流程后，再次執行該流程時可在 ESB 控制臺看到其實例。

考慮到性能和將 ESB 添加到圖中的影響，需要注意的是 BPEL 和 ESB 以原生或內存方式通信(如果可能)。只有在分發后，它們才通過 HTTP 使用 SOAP 進行調用。此外，組件間的內存中優化可以針對 SOA 實現無縫的可跟蹤方法。

第 2 步：在 ESB 系統內重用規范的模型和轉換以實現“區別對待”

通過應用該模式，BPEL 流程可以保持一致性，專注于業務問題，而不是協議轉換，并完全基于規范的模型進行工作。

第二步的目標是在 BPEL 流程中重用轉換文件以及規范的客戶模型，向外部服務使用方公開客戶請求的規范表示。

重用 BPEL 流程的兩個以上文件所需執行的第一個步驟就是引用這些文件。在示例中，第一個文件名為 CustomerUpdateProcess.xsd，其中包含了簡介部分所述的客戶模型。

第二個轉換文件名為 Transformation_Cannonical2Protocol.xsl，可將規范的表示轉換為原有表示。

執行完這些操作后，就可使用這兩個文件了。在 ESB 系統圖中，創建一個新的路由服務 (UpdateCustomerCanonical)，并添加一個名為“execute”的新異步操作。該新操作將從 CustomerUpdateProcess.xsd 模式中提取參數 CustomerUpdateProcessProcessRequest 元素。

接下來，通過創建新的路由規則將該路由服務連接到數據庫服務 (UpdateCustomerService)，如以上屏幕截圖的底部所示。

因為路由服務的輸入與數據庫服務的參數不同，所以這時要重用轉換 (Transformation_Cannonical2Protocol.xsl)。

Oracle JDeveloper 中的 ESB 系統最終將如下圖所示，其中包含兩個路由服務：一個是規范服務 (UpdateCustomerCanonical)，另一個是具有原有格式及其公開操作(合并/寫入)的服務 (PlainExposed)。

在企業服務總線內重新注冊該系統后，就可向 BPEL 流程添加邏輯來調用該系統了。

在 BPEL 流程內，創建一個新 partnerlink，它指向路由服務 UpdateCustomerCanonical 的抽象定義 (WSDL)。而具體的綁定定義則再次添加為 wsdlRuntimeLocation 標志。因此，剩下的就是簡單的分配了，如下圖所示。

assign 規則 (Assign_ToInput) 將流程的輸入變量挨個映射到 CanCustomerServiceESB 的輸入變量。

一旦重新部署并執行了 BPEL 流程，就可在 ESB 控制臺中看到該實例，如以下屏幕截圖所示。

請看 BPEL 控制臺，即便更改了 partnerlink，整個系統的可跟蹤特性仍得到了改善，只需單擊操作，用戶就可跟蹤實例從 BPEL 到 ESB，反之亦然。

結論

采用 BPEL 流程之前，該流程需要了解原有數據庫服務及其格式，還有之間的轉換，現在，原有服務對于流程完全透明。無需犧牲流程自身的編排就可對其進行替換。

應用這些模式和最佳實踐的好處有哪些?業務編排完全基于規范的模型業務，而非由協議驅動。ESB 的引入提高了可靠性;利用其精確的錯誤診斷功能，您可以實時對故障做出反應、隨時更改路由以及重試失敗的調用。

(責任編輯：銘銘 mingming_ky#126.com TEL：（010）－68476636)