隨著實施面向服務結構體系 (SOA) 這一觀念的日漸普及，企業發現自己的服務組合規模日益增大。如果不遵循正確的體系結構模式，則很難有效地利用和重用這些服務。

企 業服務匯流排 (ESB) 是一種相對較新的軟體類別，我們可以使用它來滿足上述目的。它提供了一個急需的中間層，從而簡化了企業 SOA 實施的資料傳遞、服務訪問、服務重用以及服務管理。ESB 還支援智慧指導的通訊，調解鬆散耦合業務元件和取消耦合的業務元件之間的關係。

在“精通 SOA”的這一部分中，您將瞭解 ESB 為什麼是企業級 SOA 必不可少的一部分，以及如何實施 ESB（包括常見問題）。

是否需要ESB？

正如本系列第 1 部分中所說明的那樣，SOA 是應用程式在設計、開發和整合方面的一次根本性轉變。SOA 還有助於將企業應用程式作為可輕鬆整合和重用的模組化業務服務來進行開發。然而，SOA 還意味著各種挑戰，其中許多挑戰可直接通過 ESB 解決：

    可靠的訊息傳遞：可靠的資料傳輸仍然是所有整合解決方案的基本需要。雖然 SOA 的原則需要基於標準的、與平臺無關的訊息協議，但該原則本身並未考慮可靠的資料傳遞。各項標準（如 WS-RM）正在逐漸支援該功能，但它們還不夠成熟或者未被廣泛採用。
    服務虛擬化：SOA 代表了一種基本的體系結構模式，在該模式中，任何服務使用方均可從任何平臺訪問一個服務提供方。這又意味著適當的協議和語法調解在適當的位置隔離了使用方和提供方。
    動態發現和呼叫服務：為了優化服務的重用，服務使用方需要一箇中介功能來了解服務請求的特性，從而方便與提供方進行連線。在理想的 SOA 中，這種關係將在執行時作為中介。
    策略管理：已知和未知服務使用方進行訪問都需要一個抽象的策略管理模型，該模型除了強制執行與服務提供方實施無關的更復雜的業務級別策略外，還能夠強制執行身份驗證、授權和加密。
    管理和監視服務：逐漸增加的服務數量導致環境越來越複雜。必須監視該環境以瞭解其可用性、效能以及任何技術或業務級別錯誤。
    系統異構性：人們通過常用的應用程式以及用來連線它們的軟體可以發現，今天的新應用程式就是明天的舊應用程式。這種新技術的普及是必然的，因此，設計系統時必須考慮讓其支援這種變化。
    從技術實施細節中抽取業務邏輯：SOA 的目標之一是提供一種分層的方法來開發系統，該方法將技術變化從業務流程的變化中隔離出來，並且將業務流程的變化從技術變化中隔離出來。實際上，必須從一開始就將這種“分別考慮”設計到體系結構中。

解 決這些問題的標準方法 — 無論是企業範圍還是部門範圍 — 是任何 SOA 專案成功的基礎。不能保證資料傳遞的 SOA 解決方案對大多數業務事務而言不夠強健，不能將業務流程從轉換和路由邏輯中抽取出來的 SOA 解決方案不會很敏捷。而且，一個無法適應標準和產品發展變化的體系結構並不會降低 TCO。ESB 模式（以及相關 ESB 產品的引入）是全面的 SOA 解決方案成功的基礎。

ESB 部署的先決條件

深入討論細節之前，我們先進行一下回顧，就會發現並非所有 SOA 實施都需要重大的重用和鬆散耦合。例如，較小的實施可能只會從 ESB 的增加中獲得邊際效益。

您需要滿足一些戰術條件才能建立對 ESB 的需要。按照重要性順序，這些條件依次為：

    1.服務使用方和提供方可能是鬆散耦合的，或者需要同步、非確定性的路由（其中使用方需要響應，但不會顯式知道服務提供方）。
    2.執行業務事務之前，需要根據資料、使用方或提供方執行專門的功能（可能包括策略驗證、轉換等）。
    3.必須有一種將端點應用程式連線到匯流排的方法（通過重新設計或者通過介面卡），該方法必須能夠在面向服務的模型中執行這些應用程式（並非所有應用程式都 能夠輕鬆地支援服務。例如，傳統的老式程式（如客戶資料應用程式）使用連線到老式螢幕的、基於批處理的程式設計模型來執行。它們可能不會很容易地適應更基於事 務的 SOA 模式。）

對於所有複雜的計算體系結構，這三個條件僅僅是指導方針。肯定存在這樣的情況：無需同時滿足以上三個條件即可輕鬆地判別 ESB。著手進行 SOA 規劃時，不但要關心戰術方面，還要考慮長期策略目標。

自上而下與自下而上

SOA 的兩種主要方法通常被稱作“自上而下”和“自下而上”。在自上而下的方法中，採用 SOA 是由業務方驅動的，結果是一個專門設計以滿足業務需求的體系結構，著重於效率。企業的 IT 部門通常推崇更實用的自下而上的方法，因為該方法更關心服務虛擬化，其主要目標是將成本降至最低並將更多靈活性結合到核心 IT 資產中。

可以想象，人們就哪種方法最適合或最有效展開了激烈的爭論。在此，我們不會偏袒任何一方，而是探討 ESB 是否與這兩種方法相關。

常見用例

詳盡列出所有可能的用例將需要更長的篇幅。然而，其中一些較為常見的用例需要進行強調：

服務虛擬化。服務虛擬化是實施 ESB 的主要驅動因素，其他大多數用例都是它的變形。

設 計時缺少清晰的層次（或“分別考慮”）會在業務邏輯和 IT 細節之間引入不必要的耦合。起初，這些交叉相關性的影響可能不太明顯，但隨著整合範圍的擴大，它們開始以指數級速度削弱 SOA 實施最初的優點。到端點的直接連結越多，最開始靈活、鬆散耦合的體系結構的僵化慣性就越大。

例如，如果將端點詳細資訊嵌入在一個數據庫中，那麼將該資料庫從一個網路重新定位到另一個網路將需要一個新版本的貸款審批流程。處理幾個這樣的連結可能還是可管理的，但如果增加到 50 個服務和數十個端點，您就會看到體系結構很快會變成一張糾纏不清的相關性網。

該示例還暴露了這種設計在 IT 事件（資料庫移動）和業務邏輯（貸款審批流程）之間引入的不正常關係。當複雜的核心商業資產（如貸款審批流程）根本沒有變化時，日常 IT 事件難以接受觸發這些資產的整個版本控制。

當然，這個小示例可能已經通過仔細的配置以及使用諸如 JNDI 或 DNS 這樣的技術縮減至最少，但它仍然可以方便地闡釋服務虛擬化所能解決的問題。更現實的用例包括新增或刪除資料庫、更改 CRM 供應商，甚至吸收作為合併或併購的結果而產生的新系統。

如 圖 1 所示，服務虛擬化是儲存面向服務體系結構的增長能力的關鍵。通過使用 ESB，您可以從業務邏輯中徹底消除所有端點詳細資訊（如 IP 地址、埠以及其他低階特定於計算機的詳細資訊），而是公開一個穩定的介面。最終結果是將業務需求與 IT 需求完全分離，從而允許 IT 和業務獨立修改各自的資產。

 
圖 1 服務虛擬化

集中控制策略。您只需監視幾個應用程式伺服器日誌和配置檔案的日子已經一去不返。幸運的是，ESB 可以幫助您解決如今的分散式系統中固有問題的管理和監視，即，提供有關多個應用程式和協議的端到端檢視，在企業範圍內配置並強制執行全域性策略。

由 於 ESB 邏輯上作為所有整合通訊的中介，因此對 SOA 基礎結構的監視變得簡單。ESB 管理控制檯提供了流經服務的所有交換和訊息的統一檢視。（請參見圖 2。）這些新的監視功能可用於進行被動和主動監視。例如，構建和強制執行端到端的服務級別協議 (SLA) 變成可能。實際的監視平臺可能是一個外部應用程式（如 OpenView 或 Tivoli，也可能是較新的業務活動監視 (BAM) 工具，現在越來越多地用於實時基礎結構監視），但 ESB 提供了所需的統一的、基於標準（SNMP、JMX、SQL）的基礎結構檢視。

圖 2 集中控制策略

使 用 ESB 可以更輕鬆地全域性執行像安全性或可靠性這樣的策略。通過將標準化的鉤子（例如，WSDL 介面）公開到整合體系結構的每個步驟中，ESB 使得插入常用的安全、審計和訊息處理工具成為可能。例如，您可以攔截某些站點之間的所有通訊來執行安全宣告標記語言 (SAML) 斷言，或者在企業級別（而非每個單獨的端點）支援 64 位 DES 加密。此外，ESB 還允許對專門應用程式的特定任務（如安全策略）的責任和委託進行清晰的分層。

原有資料來源支援 Web 服務。最初，沒有將 ESB 作為原有整合的解決方案。但是現在，普遍認為必須在 SOA 中考慮原有資料來源，事實上，這些資料來源通常組成所涉及的大多數服務。

一 般來說，訪問原有應用程式（如 ERP 或 CRM 系統）中的服務意味著使用供應商協議和 API 與目標系統直接交談。（請參見圖 3。）這意味著構建服務使用方的團隊必須瞭解目標系統，並且能夠編譯其客戶端的供應商 API（更不用說購買這些 API 的許可證了）。因此，部署新服務使用方的成本非常高。

圖 3 訪問服務（專有方式）

然而，大多數 ESB 供應商都提供可以連線到受歡迎的原有系統的介面卡。然後，只需進行配置即可訪問應用程式的服務，新增新服務使用方的成本顯著降低，不用再使用供應商協議，所需的只是標準（SOAP、JMS 或 ESB 公開的任何其他入口點）。（請參見圖 4。）

圖 4 訪問服務（基於標準的方法）

進 行服務虛擬化之後，即可以在許多情況下利用 ESB 了。例如，多通道支援。（請參見圖 5。）只需進行簡單的配置，即可向過去只能通過單獨的 API 訪問的服務中新增新通道。因為使用同一個體系結構來支援多個通道，因此，確保所有訪問（不論是哪個通道）都歸屬一個全域性策略中是可能的。

圖 5 多通道支援

例如，通過一個 ESB，只能通過 SOAP 從客戶門戶訪問的 Web 服務可以允許其他面向客戶的系統（如可以與 JMS 或 DCOM 交談的 IVR 或傳真閘道器）訪問相同的服務。

實施ESB 的科學

雖然許多人會認為開發以業務為中心的 SOA 是一門“藝術”，但 ESB 的實施更大程度上是一門科學。遵循正確的方法、標準和體系結構原則將確保成功實施 ESB。

ESB 的實施通常在兩個工作流中進行；軟體體系結構和支援基礎結構（即“技術體系結構工作流”）；以及支援業務所必須的服務邏輯（以及支援配置）的設計、開發和部署（即“應用程式體系結構工作流”）。讓我們看一下這兩個工作流。

技術體系結構工作流。該 工作流包括選擇軟體、識別常見體系結構功能和基礎結構要求，以及部署可以開發服務（最終是組合應用程式）的整個基礎體系結構。與傳統專案相同，有必要對技 術體系結構工作流的組成部分進行需求分析。針對該分析，有必要廣泛地調查期望 SOA 所具備的功能，並將它們分解到分散的服務中。需求列表示例（不詳盡的）包括：

    錯誤處理
    審計
    策略管理（不同的詳細資訊級別）
    服務發現
    有保證的傳遞
    協議支援（特定於所涉及的應用程式和需求）
    標準支援（通常是 WS* 標準，可能包括其他標準，這取決於規劃）
    智慧路由

只有明確了這些需求並選擇了產品之後，才能開始開發。如果重用是所有 SOA 實施的主要著眼點，那麼開發人員培訓可以更廣泛。

應用程式體系結構工作流。應用程式體系結構工作流包括識別、設計、建立業務級別服務以及將其部署到總線上。通過上述的自上而下或者自下而上的方法可以處理這個特殊的工作流；然而，隨方法的不同，管理實際設計和開發過程的基本原則只會略有不同。

針 對 ESB 進行設計時，第一個也是最重要的決策是識別出在哪些條件下服務應該位於總線上，在哪些條件下服務應該位於（例如）業務流程管理 (BPM) 工具中。雖然這兩種功能表面上看來有很大差異，但是用 BPM 工具設計類似於匯流排的功能是很有可能的（在某些情況下，甚至更可取)。通常，以下準則適合這種情況：

    ESB 上的服務應該是短生命、不連續的事務。
    需要複雜規則來確定路由、訪問以及其他基於資料的決策的服務應該位於 ESB 上。
    具有特定於端點的邏輯的服務應該位於 ESB 上。例如，如果無法在應用程式自身內將規範的資料物件對映到特定於應用程式的物件上，就應該在匯流排中進行該操作（因為您在該應用程式中無法進行控制，也可能是因為您沒有留下任何 COBOL 程式設計師來進行修改）。
    ESB 服務應該不包含任何人力工作流活動。

除了這些高階準則以外，您還應該在全域性範圍內實施一些較低級別的設計和開發準則。其中某些準則不是 ESB 所特有的，但由於 ESB 會變得更相關。我們已經在下面用斜體標明瞭新準則。

    建立成功度量。乍一看，這似乎是顯而易見的，但經常有很多 ESB（以及 SOA）專案失敗，都是因為它們無法量化地演示其所支援的過程或服務中的成功。有用的度量可能包括服務的使用方數量以及服務的響應時間（平均時間和高峰時間）。
    對於每個應用程式，必須識別適當的介面卡以及必須應用的相應協議和封套技術。這包括識別互動中所需的所有標準（例如，Web 服務可靠的訊息傳遞）。確保在選擇介面卡和協議時考慮事務模型（非同步或同步的）以及可靠性需求。
    必須詳細定義所涉及的源資料物件和目標資料物件，並將它們對映到對應的規範物件。如果某個規範物件不存在，您必須識別、設計並開發一個。規範物件的存在對於廣泛採用 ESB 範例很重要。
    將度量設計到服務中。利用 BAM 工具可以輕鬆地訪問實時度量。實時度量的示例可能包括給定值上的訂單數、某種型別的客戶更新數，或者一段時間內一個人（客戶或其他）的請求數。
    識別所有級別的安全限制。這些級別包括應用程式、事務、資料物件內容以及潛在的資料域內容。還必須將安全策略定義為支援這些要求。
    在可能的情況下利用現有服務。所有企業級的 SOA 都應該有一個可搜尋的服務登錄檔。
    識別審計要求以及技術和業務級錯誤處理要求，相應地設計服務。某些 ESB 工具具有重要的現成功能，對這個特殊步驟有所幫助。
    設計時牢記所有可用的標準。企業體系結構組釋出給定的 SOA 環境中將支援的標準並且支援所有開發人員輕鬆地訪問該列表，這是一個不錯的做法。
    部署服務時，定義併發布 WSDL。將服務註冊到企業服務登錄檔中。

遵循這些準則就可以成功實施 ESB，從而可以隨著時間的流逝輕鬆地進行小改動。

其他注意事項

和其他所有技術一樣，ESB 也有自己的特性和困難。以下是使用 ESB 時會遇到的一些問題。

    開始使用 ESB 時就要分別考慮。您新獲得的 ESB 是對您技術庫的一個非常強大的補充。它還是一個工具，經常展示其 BPM 形式的許多特性（如邏輯結構或轉換功能）。當想使用 ESB 進行一些輕型程序協調時，先回頭想想您將 ESB 引入 SOA 的初衷：虛擬化您的 IT 基礎結構，將業務需求與 IT 需求相分離。因此，遏制將某些邏輯洩露到 ESB 中的念頭；讓對 BPM 工具的編排和流程協調待在它們該待的地方。

    轉換到何處？使用大多數整合工具（訊息處理、ESB、BPM）所提供的轉換功能，將“什麼”轉換到“何處”的決定不再是一個問題，而是一個最佳實踐。因 此，在 ESB 和 BPM 工具中應該進行什麼型別的轉換呢？此處沒有適合所有情況的答案。一個省事的經驗是將方便的“分別考慮”原則擴充套件到轉換，這意味著在 ESB 中執行系統級別的語法轉換（例如，CSV 到 XML），在 BPM 中執行應用程式級別的語義轉換（例如，CRM 客戶到規範客戶）。

    影響分析。鬆散耦合的體系結構的問題之一是詳細計劃服務之間的關係以及評估變化或中斷的影響。在大型 SOA 中獲得直接和間接的相關性是一個恐怖的任務。通過支援更大的分離，ESB 可能會加劇這個問題。另一方面，由於 ESB 瞭解所有的服務及其相關性，因此它還是執行相關性分析的最好資訊來源。這對整合供應商而言是一個新興領域。

    接受異構性的現實（即“匯流排艦隊”）。雖然構想完美的 ESB 可能是一個邏輯的、單一供應商的匯流排，但是您必須接受當今世界的現實：企業將必須處理多條匯流排，這些匯流排可能來自多個供應商、跨部門、位置和時間（通過升 級和移植）。記住這些之後，採用將使這種現實更易於處理的最佳實踐和技術就非常重要了。標準的使用在以下這些地方很重要：HTTP、JMS 或 WS-RM 用於訊息傳遞，XSLT 用於轉換，WSDL 用於介面，等等。

結論

ESB 體系結構模式（以及相應的產品）是任何企業級 SOA 的重要組成部分。ESB 提供了一個重要的功能，可以斷開特定於應用程式的邏輯與 BPM 功能的連線，同時還提供了一種支援鬆散耦合的、虛擬化的服務層的方法。通過精心的前期體系結構考慮以及目前正在嚴格強制執行的一組簡單明瞭的設計準則，通 過 ESB 編寫服務成為一門非常產業化的科學。