使用 JMS 和 WebSphere ESB 構建強大而可靠的 SOA——第 1 部分

Java Message Service (JMS) 對 J2EE
平台上的可靠訊息傳遞進行了標準化。最近發布的 IBM WebSphere Enterprise Service Bus (ESB)
產品提供了一些重要的功能，這些功能位於任何基於服務導向架構 (SOA) 的環境核心位置。本系列共三篇文章，描述如何將 JMS 和
WebSphere ESB 結合使用，以形成強大而可靠的 SOA。

使用 JMS 和 WebSphere ESB 構建強大而可靠的 SOA——第 2 部分
使用 JMS 和 WebSphere ESB 構建強大而可靠的 SOA——第 3 部分

引言

服務導向架構 (SOA) 永遠不能建立在真空中。在任何實際的環境中，都必須考慮現有的 IT
環境，功能（和資料）的提供並不能簡單地通過提供一組新服務來實現。因此，構建 SOA
的一個關鍵方面就是將現有應用程式分解為更小的塊（即“服務”），這些塊通過標準協議進行通訊，並具有定義良好的介面。這樣做的優勢在於，此類環境更為靈
活，整個系統的各個部分之間並不存在緊密耦合。

鬆散耦合且具有平台獨立性的服務的概念通過使用企業服務匯流排（Enterprise Service
Bus，ESB）得到了進一步發展。其中，ESB 充當使用不同資料和訊息格式、網路通訊協定和程式設計語言的服務之間的“粘合劑”。ESB
充當服務使用者和服務提供者之間的中介層，允許部署中介，以執行各種操作，如向互動應用服務品質或執行所需的資料轉換。

在本系列的文章中， 我們將瞭解一個 ESB 充當此類中介層的具體例子。我們將利用 IBM
WebSphere Enterprise Service Bus (WebSphere ESB) V6.0.1
產品來連結服務使用者和服務提供者，同時使用 JMS 作為訊息傳遞機制。在第一篇文章中，我們將簡單瞭解一下 WebSphere ESB
產品及其工具環境，即 WebSphere Integration Developer V6.0.1。第 2 部分將描述實際的 ESB
情境，並說明如何構建服務使用者和服務提供者，而在第 3 部分，我們將示範如何構建運行於 WebSphere ESB
中的使用者和提供者之間的中介。您將學習如何部署和運行解決方案，我們將提供進行此操作所需的所有代碼構件。

企業服務匯流排和 Java Message Service

SOA
由彼此進行通訊的服務使用者和服務提供者組成。它們通常通過企業服務匯流排進行通訊。每個服務具有服務定義，在其中描述如何從使用者接受訊息和如何向其使用
者返回訊息（“單向”服務時例外）以及其他一些事項。因此，構建 ESB 與訊息傳遞有很大關係。一直以來，以穩健、快速而可靠的方式發送和接收訊息是
IT 系統的一項關鍵要求，ESB
的到來並未改變這一點；它恰恰給解決方案帶來了額外的要求——例如，支援描述訊息格式的標準、服務間的事務交換等等。

同時，基於 Java J2EE 平台的系統通常會利用 Java Message Service (JMS) API 來滿足其訊息傳遞需求。簡單說來，JMS 描述如何將訊息從一個應用程式發送到另一個應用程式，對服務的事務品質進行了潛在的利用。

充 分考慮到很多應用程式已經在使用 JMS 了，而 SOA
內的服務又需要一種進行訊息傳遞的方式，這樣就能很好地理解 JMS 在 ESB 上下文中所扮演的角色。每個 ESB 都必須能夠通過 JMS
從服務使用者接收訊息，並將其轉寄到相應的服務提供者（通過 JMS 或其他協議，如 HTTP），反之亦然。而且，JMS
還定義了可發送的若干不同類型的訊息。例如，Text 訊息包含訊息的字串表示形式；Object 訊息包含序列化的 Java 對象；Map
訊息包含鍵/值對的映射，等等。Web 服務通常使用 SOAP 作為其訊息格式，但很多應用程式都使用純 XML。因此，ESB
必須支援各種網路和訊息協議。圖 1 顯示了服務使用者和服務提供者可能支援的一系列協議組合。請注意，ESB
充當了這兩者間的中介層，允許在不受協議限制的前提下串連任何使用者和提供者。

圖 1. SOA 中的訊息和網路通訊協定樣本

如果設定 WebSphere ESB，以支援不同的組合，這正是我們將在本系列中討論的內容。不過，首先讓我們看一下該產品本身以及其主要組件。

WebSphere ESB V6.0.1

WebSphere ESB 產品是 IBM SOA Foundation
的一部分。儘管其版本號碼可能會讓人覺得此產品已經存在很長時間，但該產品卻是在 2005 年末首次發布，與其他已經存在的 WebSphere
產品系列成員共用很多組件。例如，它使用基於 J2EE 的 IBM WebSphere Application Server
作為其核心運行時。WebSphere Application Server 提供了一個 JMS 實現，該實現由 WebSphere ESB
進行了重用。它還使用了服務元件體繫結構（Service Component Architecture，SCA）作為其基礎編程模型，並與
WebSphere Process Server 共用 SCA 運行時。

圖 2 顯示了 WebSphere ESB 及其基本組件的概況。

圖 2. WebSphere ESB 概況

WebSphere ESB 支援通過 JMS 的基本訊息傳遞，可以通過 WebSphere
Application Server 中的 MQLink 與 WebSphere MQ 進行通訊。使用 SOAP over HTTP 和
SOAP over JMS 的 Web 服務是插入到 ESB 中的，支援很多 Web 服務標準和通過應用伺服器提供的 UDDI
註冊表。WebSphere ESB 不僅可以從標準 J2EE 用戶端使用，也提供 C/C++ 和 .Net 的用戶端支援。而且，它還通過
WebSphere Adapter 提供了到各種遺留環境的串連。

WebSphere ESB 和服務元件體繫結構

我 們在前面提到 WebSphere ESB 所使用的編程模型基於 SCA。SCA
描述了一個完整的服務編程模型，涉及到大量可採用相同的方式描述和訪問的組件（即服務）。此類組件可以為 BPEL 流程、商務規則或傳統 Java
組件等等。WebSphere ESB 向 SCA 模型引入了一個新的組件類型，即中介流組件。從 SCA 的角度而言，中介流組件與任何其他服務元件沒有任何區別，因為中介組件具有以下特徵：

• 存在於模組中（更準確地說，存在於中介模組中，它採用這種方式部署到伺服器運行時中）。
• 具有介面，採用 Java 或 WSDL 描述。
• 通過匯出向用戶端公開，匯出可以有多個不同協議的綁定（我們將在以後對此進行討論）。
• 具有對其他服務的依賴關係（通過匯入，匯入也具有描述協議詳細資料的綁定）。

就某種程度而言，中介流編程模型是獨一無二的；它支援訪問和操作關於正在處理的服務訊息的綁定特定資訊（通常為 Header 類型的資訊）。有關 SCA 及其編程模型的詳細資料以及如何通過其構建和部署組件，請參閱 Building SOA solutions with the Service Component Architecture 系列文章。（在本系列的剩下部分中，我們將假定您已具有 SCA 的基本知識，因此我們將不會對已在其他地方得到詳細闡述的內容進行複述。）

中介流組件提供了一種服務元件的新實現，即中介流的實現。中介流通常使用可視流編輯器進行構建，用於通過一系列中介原語描述請求和響應訊息流程。這些原語可以讀取和更改訊息，或將其路由（“篩選”）到不同的目標位置。雖然您可以構建自己的自訂中介原語，該產品仍然提供了一系列用於以下用途的預定義原語：

• XSLT 轉換
• 訊息日誌記錄
• 訊息篩選
• 資料庫訪問。

圖 3 顯示了一個使用若干中介原語實現響應流的中介流組件實現。

圖 3. 中介流樣本

順便說明一下，我們將在第 2 部分詳細講解建立此類流所需的各個步驟。

WebSphere ESB 和服務訊息對象

我們尚未討論的是，訊息“在匯流排中”時如何對其進行處理。也就是說，如何對發送到中介流組件的資料進行表示？答案是，每個訊息到達中介流組件時，將立即被轉換為服務訊息對象。與此類似，在離開中介流組件前，會將其重新轉換為訊息的目標所要求的任何格式。

服 務訊息對象是 Service Data Object (SDO)
規範的擴充，該規範描述了一種以獨立於源的方式訪問資料的方法。因此，並不會考慮訊息是否通過 HTTP 或 JMS
或任何其他協議傳入，也不會考慮訊息是 SOAP 訊息還是純文字，而會始終將其轉換為一種可由實際中介流實現（如中介原語）使用的通用格式。

因此，SCA 提供了用於調用中介流組件的編程模型，而 SMO/SDO 則表示在此組件中處理的實際訊息。這二者實現了緊密的協作。

SCA 匯出和匯入綁定

正如前面提到的，SCA 組件使用匯入和匯出與外部世界通訊（即，與使用組件的用戶端和組件的實現使用的其他服務通訊）。對 WebSphere ESB 及其中介流組件而言，可以將匯出視為 ESB 的入站連接埠，而將匯入視為出站連接埠。

例 如，假定您有一個現有服務使用者和一個現有服務提供者，二者通過 SOAP over HTTP
進行通訊。現在您希望向此串連中插入 WebSphere ESB
中介，以便能對通過的每個訊息進行記錄。通過建立中介流組件，並為其提供與目標服務相同的介面，就可以實現此目標。然後為匯入建立 Web 服務綁定，
以引用目標服務的 WSDL（包括端點地址），從而建立指向現有 Web 服務的匯入。也就是說，已將匯入“綁定”到該 Web
服務。類似地，為匯出建立 Web 服務，從而產生新 WSDL
檔案，並構建一個指向中介流組件的端點。最後，部署此組件，並告知服務使用者使用新端點地址。訊息現在將定向到 WebSphere
ESB，通過一系列中介原語，然後轉寄到實際的目標 Web 服務。

還記得我們曾提到每個訊息都將成為匯流排中的一個 SMO 嗎？Web 服務綁定是一段將傳入 SOAP/HTTP
請求訊息轉換為服務訊息對象的邏輯，而出站 Web 服務綁定則提供其反向邏輯；即，它將傳出 SMO 轉換回 SOAP/HTTP
訊息。這些都是自動進行的。運行時知道入站訊息的格式，因為這個訊息是由相應的 WSDL 定義進行了全面的描述，運行時可以據此進行分析和處理。

為了保證正確性，自訂綁定僅處理訊息的本文部分。Header 欄位由基礎設施自動處理，將在不需任何編程的情況下在 JMS 訊息和 SMO 之間進行轉換。

不 過，如果傳入的訊息並不遵循 SOAP 之類的特定訊息協議，會發生什麼呢？例如，如果有 JMS
映射訊息發送到匯出，則不能使用預設綁定，因為不知道此映射的格式。此時自訂綁定就派上用場了。必須以 Java 類的形式提供從傳入訊息到 SMO
的轉換，以執行相應的分析邏輯和構建正確的 SMO。在出站端（即匯入）也應該進行相同的處理。自訂綁定實現知道如何擷取 SMO
並將其轉換為正確的格式。

在本系列的第 2 部分和第 3 部分，我們將詳細討論自訂 JMS 綁定的樣本（支援全部五種 JMS 訊息類型的綁定），因此我們會再次討論自訂綁定的話題，並示範如何將自訂綁定作為中介模組的一部分部署到運行時中。

WebSphere Integration Developer V6.0.1

WebSphere ESB
的目標之一是簡化建立中介並將其插入到企業的訊息流程中。在某種程度上來說，這個目標是通過利用 SCA
編程模型實現的，該模型允許使用一個描述和部署機制處理不同類型的服務。SCA
規範還描述了用於將這些組件裝配為較大的解決方案的方法。而且，我們希望支援以細粒度中介原語為基礎構建的中介流組件。WebSphere
Integration Developer V6.0.1 支援所有這些操作。

我們在前面提供了使用多個原語的中介流組件實現的圖。該工具也支援採用可視方式將中介流組件、匯出和匯入裝配為中介模組，以便部署和安裝到運行時中。例如，圖 4 示範了如何使用裝配編輯器來構建包含中介流組件的中介模組。

圖 4. 包含中介流的中介模組

前面提到的系列文章“Building SOA solutions with the Service Component Architecture”詳細討論了使用此工具的樣本情境。我們還將在第 3 部分逐步說明如何構建中介模組。

結束語

在本文中，我們討論了可以如何使用 WebSphere ESB 產品構建企業服務匯流排，該產品支援可用於串連到現有服務和新服務的各種訊息和網路通訊協定。其中一個協議就是 JMS。

WebSphere ESB 基於新的服務元件體繫結構，使用服務資料對象作為其內部訊息格式模型。SCA
定義了綁定的概念，可利用綁定對用戶端提供服務元件，並讓其與其他組件進行通訊。在採用五種不同的 JMS
訊息類型的情況下，我們需要提供自訂綁定實現，以便支援任何訊息格式。

在本系列的其他兩篇文章中，我們將提供一個樣本，示範如何利用 WebSphere ESB 來處理 JMS
用戶端和（基於 JMS 的）訊息驅動 Bean 交換的訊息。您將瞭解如何開發和部署自訂綁定實現，如何全程使用 WebSphere
Integration Developer 作為工具環境來構建相應的解決方案。

關於作者

		Andre Tost 是 Software Group 的 Enterprise Integration Solutions 組織的一名進階技術人員，他在這個部門協助 IBM 的客戶建立服務導向架構。他專長於 Web 服務技術。在擔任他目前的職務前，他在 IBM 軟體開發工作中擔任過十年的各種夥伴支援、開發和體繫結構角色（在擔任目前的職務前，他在 WebSphere Business Development 組工作）。他出生於德國，目前在美國明尼蘇達州的羅徹斯特居住和工作。在業餘時間，他喜歡和家人在一起，並且一有空就去踢球或看球賽。