IBM WebSphere Enterprise Service Bus V6.1 的新功能

瞭解 IBM® WebSphere® Enterprise Service Bus V6.1 及其相關的工具 IBM WebSphere Integration Developer 中推出的最新功能。本文將介紹傳輸協議繫結、資料繫結和管理與中介支援。要跟上本文所述內容的學習，您應該具備 WebSphere Enterprise Service Bus 之前版本的功能和函式的基本知識。

WebSphere Enterprise Service Bus 概述

通過使用 WebSphere Enterprise Service Bus，可以部署中介模組來整合異類系統。WebSphere Integration Developer 用於建立中介模組。中介模組通過使用服務訊息物件（Service Message Object，SMO）提供對訊息的有效負載和傳輸 Header 的訪問，SMO 是訊息資料在通過中介流時的邏輯表示形式。在中介模組中，可以對訊息進行日誌記錄、充實、傳輸或路由，從而通過匯流排整合服務。（有關 WebSphere Enterprise Service Bus 基本概念的更多資訊，請訪問本文最後的參考資料。）

在接下來的幾個部分中，我們將介紹 WebSphere Enterprise Service Bus V6.1 中的新功能和函式，首先將介紹增強功能和安裝與配置嚮導。然後我們將討論新的繫結函式，最後將討論新的中介原語支援。注意：本文並不討論所增加的每項功能，也不會在每個部分進行深入的闡述。本文將重點討論重要的特性，並突出介紹每個新功能的作用。

經過改進的安裝和配置支援

WebSphere Enterprise Service Bus 以 IBM WebSphere Application Server Network Deployment 為基礎構建，因此可以利用該應用伺服器的工作負載平衡和高可用性功能。WebSphere Enterprise Service Bus 的此版本引入了一系列嚮導來為系統管理員提供幫助，並提供了用於配置不同的訊息傳遞引擎和叢集伺服器拓撲的改進支援。以下圖片顯示了概要管理工具中可用的一些配置選項。

圖 1 顯示了概要建立嚮導中的一些選項。您可以選擇適合您需求的配置選項，這其中既包括典型配置，也包括更為高階的選項。高階選項提供對各種設定細粒度的控制，如埠值、管理控制檯的安裝以及資料庫配置。

圖 2 顯示了一些高階選項，如允許指定不同的訊息傳遞引擎、公用事件基礎設施和叢集配置。

您還可以在安裝和配置嚮導內指定安全設定和資料庫配置。增強管理支援的優勢在於其易用體驗，您可以在更短的時間內設定通常使用的叢集化配置並執行。

新的增強型傳輸協議支援

此部分將描述新新增的資料繫結和新 HTTP 傳輸協議繫結。

在 WebSphere Enterprise Service Bus 中，匯入 (import) 定義到現有服務的連線，而匯出 (export) 定義新構造的服務如何向外部應用程式公開。匯入和匯出都與特定的傳輸協議繫結相關，如 Web services、IBM WebSphere MQ、Java™ Message Service (JMS)、WebSphere MQ for Java Message Service 或服務元件體系結構（Service Component Architecture，SCA）。

某些協議繫結型別（如 WebSphere MQ、JMS 和 WebSphere MQ for Java Message Service）還支援配置函式選擇器和資料繫結。函式選擇器 指定中介模組介面中要呼叫的特定操作。資料繫結 將傳輸的本機訊息轉換為元件所希望接收的服務資料物件（Service Data Object，SDO）或進行反向轉換。在 WebSphere Enterprise Service Bus 中，資料表示為 SMO，這是一種特殊化的 SDO，可提供用於訪問資料的通用方法，而不會受到所使用的傳輸協議的影響。

在本文中，繫結 描述與匯出或匯入關聯的協議繫結，而資料繫結 描述可以在匯入和匯出繫結中指定的資料繫結，用於在本機資料和資料物件之間進行轉換。例如，JMS 繫結 是與匯出關聯的傳輸協議，而 JMS Object 資料繫結 將物件訊息轉換為關聯的資料物件。

新的 HTTP 傳輸繫結

在 V6.1 中，為了對當前的匯入和匯出繫結傳輸協議列表進行補充，引入了 HTTP 繫結，提供了對原始 HTTP Header 和 SMO 內的內容的訪問。

圖 3 中的圖片顯示了工具內的 HTTP 匯出和匯入圖示。

您可以使用預先定義的或自定義的函式選擇器和資料繫結配置 HTTP 繫結。此繫結提供了以下兩個預定義的函式選擇器：

• HTTP Header 函式選擇器：使用 TargetFunctionName 訊息 Header 來指定要呼叫的介面操作
• HTTP URL 函式選擇器：使用 URL 地址確定要呼叫的介面操作（例如，http://myHost/myService/getQuote 將對目標服務呼叫 getQuote 操作）

如果希望使用訊息的其他部分的資訊來確定呼叫的操作，則可以建立自定義函式選擇器。

雖然可以編寫自己的資料繫結，不過 HTTP 繫結提供了三個預定義資料繫結實現：

• HTTP 位元組資料繫結：用於接收位元組
• HTTP XML 資料繫結：用於接收 XML（表示服務介面中定義的資料物件）
• HTTP SOAP 資料繫結：用於接收主體轉換為服務介面中定義的資料物件表示形式的 SOAP 訊息

還可以選擇第四個資料繫結，即 IBM WebSphere Transformation Extender 資料繫結，我們將在新資料繫結部分對此進行討論。

下面的程式碼示例顯示了傳送到 HTTP 繫結的 XML 訊息如何在使用 XML 資料繫結時採用 SMO 的形式表示。在清單 2 中，已知的 HTTP Header 包含在 SMO 的 HTTPHeader 元素中，並在屬性元素中包含額外的傳輸 Header，如 Cookie 等。

                


  12345

                


  
  
    
      E3E1664D-0116-4000-E000-12600914F31C
      
        6
        1
        0
      
      Request
    
    
      Cookie
      ABCDE12345
    
    
             
        
          http://localhost:9080/CustomerWeb/Export1/getCustomerDetails
          
        1.1
        POST
      
      

        Host
        localhost:9080
      
    
  
  
    
      12345
    
  

新的通用 JMS 提供者繫結

圖 4 顯示瞭如何在工具內選擇新的用於匯出和匯入的通用 JMS 提供者繫結。此繫結型別與第三方 JMS 1.1 提供者（已經在 WebSphere 中進行了配置）整合，而且其工作方式與當前的 JMS 協議繫結非常相似。關鍵的區別在於，您應該使用現有 JMS 繫結與 WebSphere Application Server 中提供的預設訊息傳遞提供者互動，而對於支援可選應用伺服器工具（Application Server Facility，ASF）的其他 JMS 1.1 提供者，您應該使用新的通用 JMS 繫結。

新資料繫結

對於某些訊息傳遞匯入和匯出傳輸協議繫結，您可以為其配置自定義資料繫結和預定義資料繫結。IBM 增加了 WebSphere Enterprise Service Bus V6.1 中預定義資料繫結的數量，提供了更多現成功能供使用。此外，您現在可以建立資料繫結配置，而且可以跨多個不同的匯出和匯入繫結例項共享這些配置。

預定義資料繫結集合中新增的一個重要繫結是新的 WebSphere Transformation Extender 資料繫結，此資料繫結允許將 WebSphere Enterprise Service Bus 和 WebSphere Transformation Extender V8.2 整合（請參見圖 5）。WebSphere Transformation Extender 是一項強大的傳輸和驗證引擎（有關此產品的更多資訊，請參見參考資料）。

WebSphere Transformation Extender 資料繫結將傳輸邏輯委託給 WebSphere Transformation Extender。資料繫結使用恰當的對映名稱進行配置，執行時將呼叫此名稱來在本機資料和資料物件格式之間進行轉換。

中介原語

WebSphere Enterprise Service Bus V6.1 引入了幾個新中介原語，並對當前集合進行了增強。

增強的自定義中介支援

要使用自定義中介，請將圖 6 中所示的圖示新增到中介流。

已經對自定義中介原語支援進行了增強，以提供在中介流中編寫自定義程式碼的更多靈活性。在 WebSphere Enterprise Service Bus 之前的版本中，自定義原語上只允許一個輸入和輸出末端，而目前這個限制已經放鬆，允許多個末端。圖 7 顯示了包含兩個輸入末端和三個輸出末端的自定義中介。這樣可以允許複雜的路由條件，支援在其中根據中介原語中包含的邏輯指定觸發哪個輸出末端。

工具仍然允許選擇圖形程式碼片段或 Java 編輯器，但目前在二者中都能夠根據中介原語內的邏輯觸發不同的輸出末端或引發異常來觸發 fail 末端。您還可以在中介原語上定義使用者屬性，從而允許系統管理員在執行時修改各個值。

XSLT 編輯器

要使用 XSLT 中介，請將圖 8 中所示的圖示新增到中介流中。

XSLT 對映編輯器已經進行了更新，提供了很多可用性增強功能，其中尤其值得一提的是經過改進的自定義指令碼編寫支援。此編輯器與之前版本一樣會顯示輸入和目標訊息對映。但現在還允許使用者定義自對映，以供跨多種不同的原語以及圖 9 中所示的編輯器內的其他自定義邏輯進行重用。

對於複雜的轉換，如果能夠在部署之前測試對映輸出，將會非常有用。在 V6.1 中，此工具現在作為 XSLT 中介原語的一部分提供。如果在生成 XSLT 對映時選中了 Create a sample xml input file for testing the XML Map 核取方塊，則將會建立示例 XML 輸入檔案。這將建立一個輸入 XML 檔案，可以在工具業務整合透檢視內的物理資源檢視中找到此檔案。

在 XSLT 對映編輯器內，還可以選擇 associate XML files 圖示來關聯新輸入的 XML 檔案。選擇 generate XSL script 圖示時，將基於實際的資源業務整合透檢視中的輸出 XML 檔案的對映定義對所定義的輸入 XML 檔案進行轉換。

新的 Business Object Map 中介原語

要使用 Business Object Map 中介，請將圖 11 中所示的圖示新增到中介流。

Business Object Map 原語在中介流中提供了一個額外的對映工具。選擇使用 XSLT 原語還是 Business Object Map 原語取決於所需的功能。如果您熟悉 XSLT 而且希望使用現有 XSLT 功能，則可能要選擇 XSLT 原語。不過，如果您熟悉 WebSphere Process Server 內的 Business Object Map 技術，或者已經定義了業務物件關係，則可能要使用 Business Object Map 原語。

圖 12 顯示了使用 Business Object Map 編輯器的對映。您可以執行多個函式，如新增自定義程式碼或呼叫關係對映。Relationship mapping 是 Business Object Map 原語的一個強大的功能，用於關聯不同上下文中的資料。例如，某個特定服務可能將客戶 ID 生成為整數值，但目標服務期望 ID 為組合使用字元和整數的格式。您可以建立定義這兩個邏輯欄位間關係的關係對映，然後從對映編輯器對此進行呼叫。

新的 Set Message Type 中介原語

要使用 Set Message Type 中介，請將圖 13 中所示的圖示新增到中介流中。

此原語提供對 XML 模式 any、anySimpleType 或 anyType 定義的增強支援。對於包含此類元素的訊息定義，此原語支援在工具內指定具體的執行時型別或元素。以下場景演示了 Set Message Type 原語的用法。名為 Car 的業務物件在其訊息定義中包含 xsd:anyType，但在執行時，此元素可能包含業務物件型別 FordCar 或型別 HondaCar。所有三個業務物件如圖 14 中所示。

圖 15 顯示了使用 Message Filter 原語基於 Car id 元素路由訊息的中介流。如果 id 元素以 x 開始，則 Car 訊息包含 FordCar 型別；否則其中就包含 HondaCar 型別。中介中名為 SetFordType 的 Set Message Type 原語將 Car 業務物件內的 details xsd:anyType 與 FordCar 業務物件關聯。

位於 Set Message Type 原語下游的後續中介原語使用這個具體的資訊來向使用者顯示擴充套件資訊，以指定恰當的 XPath 表示式。請注意，圖 16 中所示的 XSLT 對映編輯器中 details 元素現在包含 FordCar 型別的方式。

新的 Service Invoke 中介原語

要使用 Service Invoke 中介，請將圖 17 中所示的圖示新增到中介流。

在 WebSphere Enterprise Service Bus 之前的版本中，使用者從中介模組內呼叫服務的方法有兩種：通過將流連線到調出節點，或提供自定義程式碼。新的 Service Invoke 中介原語支援使用者從中介流中的任意位置呼叫服務。

除了輸出和失敗輸出末端外，此原語還有在採用延遲響應的非同步呼叫未能在指定的時間內返回訊息時傳播原始訊息的超時末端。工具中還會為每個目標服務介面上指定的錯誤訊息生成進一步的輸出末端。這樣您就可以處理可能從目標服務返回的所有定義響應（輸出和錯誤）。對於標註（callout）節點，可以將 Service Invoke 配置為重試目標服務呼叫，或使用在 SMO Header 或原語屬性中指定的端點地址 URL 執行動態呼叫。

您可以在請求或響應中介流中放置任意數量的 Service Invoke 原語。此功能與新的 Fan Out 和 Fan In 中介原語結合使用時功能非常強大。

新的 Fan Out 和 Fan In 中介原語

要使用 Fan Out 和 Fan In 中介，請將圖 18 所示的圖示新增到中介流。

新的 Fan Out 原語允許使用者在中介流內觸發一個或多個訊息，與 Fan In 原語結合使用時，可以定義範圍，以便定義來自多個源的資料的聚合。

您可以配置 Fan Out 中介原語，以僅觸發其輸出末端一次，或對使用指定 XPath 表示式獲取的每個元素都觸發一次。通過這樣可以為重複元素建立不同的訊息。例如，通過使用清單 3 中的 XML 表示形式，可以配置 Fan Out 原語為從 XPath 表示式 /body/myMessage/values 返回的每個元素觸發其輸出末端。

                

  
    A
    B
    C
  

此原語在執行時將觸發輸出末端三次。第一次，訊息包含 Fanout 上下文中的值 A 以及原始訊息。第二次其中包含 FanOut 上下文中的 B。第三次其中包含值 C。FanOut 是 SMO 中用於儲存此類值的專用區域。

您還可以將 Fan Out 原語與 Fan In 原語結合，以執行訊息的聚合。另外 SMO 中還有一個新的上下文區域，名為 Shared Context，專門用於 Fan Out 和 Fan In 原語。您可以使用使用者定義的業務物件定義對這個 Shared Context 區域進行配置。此上下文區域在以下場景中非常重要，此場景是組合使用 Fan Out、Fan In 和 Service Invoke 原語的特定聚合場景。

場景：某個訂單應用程式中介模組需要首先使用額外資訊對訂單文件進行充實，然後再將其傳送到訂單處理服務。圖 19 顯示了一箇中介模組，此模組對兩個服務進行調出操作，以獲取目標服務所需的其他客戶和部件資訊。

Fan Out 中介在此例項中配置為僅觸發其輸出末端一次。輸出末端連線到三個流路徑：兩個包含用於建立目標服務的請求訊息 XSLT、呼叫目標服務的 Service Invoke 和將目標服務響應訊息對映到共享上下文中的另一個 XSLT。第三個程式碼路徑僅包含一個 XSLT 原語，即 SaveOrderDoc，用於將傳入訂單訊息放入 Shared Context 中供以後檢索。Fan In 原語配置為在接收到其輸入末端上的所有三條訊息時觸發輸出末端。Fan In 原語收到所有訊息後，XSLT 將使用 Shared Context 資訊中的資料來對訂單文件進行充實，以補充最終訂單處理服務所需的其他客戶和部件資訊。您還可以將 Fan In 原語配置為在指定時間內未收到所有三條訊息時觸發其 incomplete 末端。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-421355/，如需轉載，請註明出處，否則將追究法律責任。