原文地址：http://space.itpub.net/14789789/viewspace-421356

引言

IBM 對 ESB 的立場是——并且一貫是——認為 ESB 作為 SOA 中的一種體系結構模式發揮了根本性的作用。ESB 是實現成功 SOA 采用的重要入口點，并且是任何面向服務的解決方案的關鍵成功因素。事實上，作為對 SOA 中的 ESB 承諾的一部分，IBM 提供了實現 ESB 模式的三個戰略產品。

本系列的第 1 部分描述了企業服務總線 (ESB) 體系結構模式如何適應 IBM SOA Foundation，以及 ESB與 Foundation 的其他部分如何相關。

本文介紹以下主題：

• 設計良好和實現良好的 ESB 能夠為面向服務的解決方案提供的價值
• 一些在設計和實現 ESB 時要遵循的最佳實踐
• IBM 對作為 SOA 組成部分 ESB 的承諾

與 SOA 相關的 ESB

IBM SOA Foundation 白皮書描述了 IBM 交付 SOA 價值的整體方法。SOA Foundation 的參考體系結構（圖 1顯示了邏輯模型視圖）的核心中具有 ESB。該參考體系結構的描述聲明“ESB 的存在是簡化服務調用任務的基礎”。雖然該白皮書是在 2005 年末發布的，但是其中預述的論點卻隨著時間推移而通過我們在采用 SOA 的客戶方面的經驗得到加強。

本系列的第 1 部分表明了 ESB 是稱為 SOA 的更大體系結構模式中的一個關鍵體系結構模式。充當中間層的 ESB 提供了服務交互中參與者之間的松散耦合連接，從而提供了 SOA 的中樞。作為中間層，ESB 執行服務虛擬化以協調服務請求程序和服務提供程序之間的差異，并提供面向方面的連接以用作諸如管理和安全性等 SOA 策略的執行點。松散耦合允許解決方案中的組成部分之間徹底分離關注事項（時間上、技術上和組織上的分離），從而同時支持業務流程和 IT 系統的靈活性和敏捷性。

通過 ESB 實現的松散耦合的部分優點（包括本系列的第 1 部分詳細描述的服務虛擬化和面向方面的連接中所固有的優點）如下：

• 請求程序和提供程序不必就消息格式、消息傳輸甚至目標地址達成一致。
• 請求消息可由多個提供程序中的任何一個進行處理，請求程序不必顯式地確定提供程序。這種路由可以基于相應的版本、服務質量或其他度量。
• 現有的請求程序無需更改即可連接到新的提供程序。
• 現有的提供程序無需更改即可對新的請求程序公開。
• 可以對請求程序做出更改而不影響提供程序，或者對提供程序做出更改而不影響請求程序。
• 解決方案的橫切方面，例如安全性和管理等等，可由 ESB 進行添加、執行或加強。
• 可以實現新級別的動態行為，因為 ESB 能夠為請求程序和提供程序之間的每個交互實時執行策略。

作為 SOA 入口點的 ESB

一次性全面采用 SOA 可能是一項艱巨的任務。IBM 已確定了五個SOA 入口點，這些入口點提供了有關如何開始漸進地采用 SOA 的指導。漸進的采用方法允許企業以最適合需要的方式和步調采用 SOA。為什么我們要確定五個入口點？簡單的原因在于眾口難調；企業的在成熟度級別和特定需求方面各不相同，適合于一家企業的入口點可能不適合于另一家企業。這五個入口點基于已導致我們的客戶成功實現了 SOA 的方法。存在兩種類別的入口點：

• 以業務為中心的入口點——人員、信息和流程——允許您從一種側重于基本企業資產的方法開始。
• 以 IT 為中心的入口點——連接性和重用——允許您為 SOA 奠定技術基礎。

您也許已經從SOA Foundation 白皮書中預料到，連接性意味著使用 ESB 來“通過更加安全、可靠和可伸縮的方法簡化 IT 環境，從而在企業內外進行連接”。IBM 認為，雖然 ESB 無疑是一種以 IT 為中心的 SOA 方法，但是“它本身交付了實際業務價值，并且是將來的 SOA 計劃的核心構件”。本文中的一個關鍵問題（將在下面進行討論）是如何最好地使用 ESB 來形成將來的 SOA 計劃的構件，以及如何通過連接性入口點獲得最大的業務價值。

存在多種利用連接性入口點的方法。有時客戶已經在其環境中定義了一些服務（也許是通過合作伙伴），不過是直接連接的服務；這種情況導致缺乏靈活性并增加管理成本。如上所述，在此類環境中插入 ESB 可以提供直接的松散耦合優點。此外，ESB 的存在為將來定義附加服務、創造附加重用機會、支持新的重用渠道、降低管理成本和獲得更多敏捷性的工作創造了條件。

客戶通常知道 ESB 的價值并渴望開始從 ESB 中實現好處，但是他們還沒有在其環境中定義服務。我們看到了兩種已采用過的成功技術，這兩種技術幫助在這種情況下從 ESB 獲得好處?？蛻艚洺；旌鲜褂弥赜煤瓦B接性入口點。他們確定需要作為服務來連接的功能或應用程序（請求程序或提供程序）。同時，他們將 ESB 插入該體系結構，以提供新的服務請求程序和提供程序之間所需的松散耦合?；旌戏椒ǖ靡粤餍械囊粋€重要因素是 ESB 產品的轉換和變換功能。此類功能允許使用同一個 ESB 產品作為某種形式的適配器，以便以更加可重用的形式公開功能或應用程序，并提供所需的服務虛擬化和面向方面的連接。這里成功的關鍵是謹慎地開始，公開少量的服務并開發對應的中介，但是這些服務和中介都在為考慮中的整個最終范圍而設計的體系結構之內。

有些客戶插入 ESB 以建立組織中連接的所需方向，盡管起初還沒有確定要連接的服務。在此情況下，ESB 是組織的總體參考體系結構的一部分；參考體系結構提供了體系結構方向，并強制要求最終將作為解決方案一部分而創建的所有服務（請求程序和提供程序）進行松散耦合連接。ESB 是用于實現該松散耦合的首選機制。采用 ESB 實際上消除了解決方案中的直接連接不知不覺地增長的可能性。這里成功的關鍵是：

• 采用一個要求并演示 ESB 使用的參考體系結構。
• 考慮解決方案的整個最終范圍，并支持最佳的 ESB 產品選擇。
• 隨著解決方案的發展而實施強有力的治理，以確保利用 ESB 來連接到引入解決方案的新服務（請求程序和提供程序）。

SOA 入口點最佳實踐

存在一組 IBM 強烈建議用于任何 SOA 采用的最佳實踐。這些最佳實踐的最重要元素是建立一個路線圖并漸進地實現該路線圖，該路線圖定義了實現所需業務目標的采用計劃（請參見參考資料部分以獲得指向文章“Service Oriented Architecture:An Introduction for Managers”的鏈接）。該路線圖包括兩個重要組成部分：

1. 戰略遠景，業務或 IT 的方向陳述（包括參考體系結構和治理計劃），可用作決策制定、組織參與和標準采用的指導原則。
2. 一組項目計劃，定義實現項目以滿足當前業務驅動因素的即時和將來需要。

此類路線圖允許您漸進地實現 SOA，以在每個項目步驟中回報業務價值。

您應該在執行該路線圖的早期確定您業務的最佳 SOA 入口點。您應該基于從您的總體戰略遠景和當前 SOA 成熟度級別得出的要求來選擇該入口點。該入口點可能是也可能不是連接性入口點；它可能是上述入口點的混合。但是，連接性入口點是最普遍的入口點，因為有如此多的客戶具有將請求程序連接到提供程序的即時需要，并希望獲得 ESB 提供的松散耦合的好處。IBM 提供了一個在線工具Business Value Analyzer，以幫助您選擇 SOA 入口點。

另一個最佳實踐是建立治理框架以確保組織遵循該路線圖（請參見參考資料以獲得指向文章“SOA Governance and Service Lifecycle Management”的鏈接）。SOA 所促進的靈活性增強和跨組織性質要求組織建立治理框架，以實現主動的決策制定、準確的跟蹤、改進的服務能力和更好的交流。有效的治理通過在增添價值的同時平衡風險和回報，從而幫助實現企業的業務目標。

正如上面所建議的，漸進的 SOA 采用是成功的關鍵。IBM 建議從試驗項目開始，該試驗項目：

• 處理得到充分了解、重要但不關鍵的業務需要。
• 實現參考體系結構的某些重要方面（也許是 ESB 和一組示例服務、提供程序、請求程序，這些方面用于演示 SOA 的使用）。
• 需要一個超出當前能力的可達范圍。
• 積累 SOA 技能。
• 用作對采用 SOA 治理和新的服務生命周期管理流程所進行的試驗。
• 產生將會投入生產應用并將交付投資回報的結果。

通過 SOA 實現的關注事項分離甚至允許試驗項目以能夠積累專業經驗和驗證業務價值但不中斷主要操作的方式引入 SOA。

SOA 連接性入口點最佳實踐

除了 SOA 最佳實踐以外，還存在其他更特定于 ESB 的最佳實踐：

• 僅當 ESB 在您的路線圖中有意義時才采用 ESB。例如，如果 SOA 入口點以業務為中心，您可以推遲通過 ESB 實現的松散耦合，盡管您的參考體系結構中包括了 ESB。
• 基于您的參考體系結構和一組跨全套項目計劃的實際要求來設計 ESB 并選擇 ESB 產品。我們說實際是因為您應該集中于未來幾年中的需要；到您超過該時間期限時，產品和需求已經發生了改變。如果僅考慮即時需求，尤其是忽略服務請求程序和提供程序的預期需要，則會導致選擇非最優 ESB 產品。您必須明確地在公司的約束內行事，例如年度資金周期和預算，但您同時還希望將短期采購和決策與考慮中的長期（三至五年）目標保持一致。
• 根據情況考慮 ESB 聯合。更大型的異構企業通常作為某種自治域的聯合體出現，這些自治域基于各個業務部門或者職能或治理方面。在此類環境中，某些服務可以在單個域中進行共享或重用，而其他服務可以在整個企業中進行共享或重用。在這些情況下，我們建議采用某種形式的 ESB 聯合，該形式的 ESB 聯合與域聯合的需要相匹配。ESB 聯合允許在不同的域中使用不同的 ESB 產品，并支持域需求與產品功能之間的最佳匹配。路線圖和參考體系結構應該為任何給定域的產品選擇提供指導原則甚至選項，以確保實現企業范圍的優化。我們進一步建議使用聯合服務注冊中心和存儲庫，為企業范圍的管理和可重用服務的治理提供幫助。

您是否需要 ESB 來成功采用 SOA？

前面幾個部分說明了從 ESB 開始成功的 SOA 之旅。另外四個入口點不需要 ESB 即可開始該旅程。然而 IBM 認為，無論其入口點是什么，絕大多數成熟的面向服務的解決方案都將包括 ESB，以最大化 SOA 中所需的敏捷性和靈活性。因此，雖然初始項目可以不包括 ESB，但是在您的長期業務和 IT 路線圖中，ESB 應該是參考體系結構的一部分，以實現成功的 SOA。如果沒有 ESB 提供的敏捷性和靈活性，您會發現在面臨不可避免的變更時，管理解決方案將變得非常困難，并且開銷很大。

這是否意味著在準備好包括 ESB 在內的所有體系結構組件之前，您還沒有擁有真正的 SOA 呢？此問題沒有正確或錯誤的答案，并且可能存在許多選項。在某種程度上，此問題并不重要——重要的是在實現新的 SOA 項目以及解決方案根據您的路線圖逐漸變得成熟時，您要漸進地向業務交互越來越多的價值。

我們的客戶好像同意這個觀點。幾乎我們的所有采用 SOA 的客戶都從 ESB 開始，或最終在解決方案中使用了 ESB，并從 ESB 支持的靈活性和敏捷性中獲得了重大的 IT 和業務價值。

IBM 的 ESB 產品系列

IBM 對 ESB 的重視及其對 ESB 的承諾體現在我們如何使用產品來履行對 SOA Foundation 的承諾上。IBM 推出了一個產品系列，其中包括三個實現 ESB 體系結構模式的產品：

• IBM WebSphere® Message Broker是一個成熟的產品，此產品在多年前就已實現了該模式。
• IBM WebSphere Enterprise Service Bus于 2005 年推出，此產品專門設計用于在側重于標準的環境中實現該模式。
• IBM WebSphere DataPower Integration Appliance XI50于 2006 年推出，此產品以可容易地部署和管理的工具的形式封裝了該模式。

為什么要推出三個產品？同樣是由于眾口難調。所有三個產品都實現了 ESB 模式，但是分別強調了使它們適合于特定情況的特定功能。您將在developerWorks上找到許多文章和IBM 紅皮書®，編寫這些內容的目的是為了幫助在面向服務的解決方案中使用這些產品。

結束語

本文再次強調了 IBM 一如既往的信仰，即 ESB 是稱為 SOA 的更大模式中的一種基本體系結構模式。您通過閱讀本文了解了 ESB 如何幫助從 SOA 獲得業務價值，以及 ESB 如何成為成功的 SOA 采用的重要入口點——ESB 模式是如此重要，以致于 IBM 目前在 SOA Foundation 組合中推出了三個實現該模式的戰略產品。

Author: orangelizq
email: orangelizq@163.com