編者注：自從 Bobby 的這篇文章發表以來，受到了極大關注，我們對圍繞這篇文章的討論非常重視。不過，這篇文章讓某些讀者誤認為 IBM® 不再看重 ESB 的價值。請相信事實并非如此。請參見下面側欄中 Greg Flurry 和 Kyle Brown 撰寫的內容，其中對所涉及的問題進行了澄清。
引言
我們會經常遇到越來越多的客戶要求完成根本不使用 SOA 的項目，而僅僅在其中實現企業服務總線（Enterprise Service Bus，ESB）體系結構。此類面向 ESB 的體系結構并不困難，但是其成功與否卻難下定論。要求進行此類項目的客戶并不了解這一點：面向 ESB 的體系結構并不帶來業務價值�；诿嫦� ESB 的體系結構的項目需要成為基于 SOA 的項目，才能幫助確保成功地提供業務價值。
僅使用 ESB 體系結構
SOA 基于業務需求。SOA 可保持 IT 與業務的一致性，使 IT 系統按照業務系統的方式工作，幫助確保 IT 產生業務價值。有關更多細節，請參見 IBM 白皮書“IBM SOA Foundation: An architectural introduction and overview”（參考資料部分提供了一個鏈接）。
SOA 的主要目標是在業務領域與 IT 領域之間保持一致，從而同時提高二者的效率。
使用 IBM 產品和服務構建 IT 系統的 IT 部門可能對其業務需求了解并不夠。對于習慣于精確計劃系統將如何工作的工程師，業務工作的方式可能會讓人覺得沒有計劃，是隨機的。說明內容看起來不一致，不可行，業務用戶的需求似乎不現實，而且總在變。業務需求成了“都市神話”，似乎存在于組織中，但仔細分析卻又找不到。
從這個角度而言，將 IT 與業務保持一致是不現實的。業務部門似乎不知道自己需要什么。其流程對自動化構成了挑戰。實現流程自動化的工作沒有效果，而且站不住腳。
工程師所了解的是技術。技術并不需要想像的需求列表，僅僅需要代碼而已。代碼不會抱怨不好用，編譯器也不會每天改變自己的需求。代碼要么運行，要么不運行。如果今天代碼在運行，那么明天它也會運行。
技術對于工程師來說更容易掌握，也讓他們覺得比較滿意。這也碰巧成為了大多數企業軟件公司銷售的主要內容。ESB 是技術，用于連接到其他技術。
SOA 非常復雜，而與此不同，ESB 理解起來較為容易。ESB 并不需要任何這樣的業務需求，僅僅需要技術需求。ESB 非常精確，以各項標準為基礎：數據格式、連接協議、XML、IP、HTTP、SOAP、JMS、JAX-RPC、JAX-WS 等等。SOA 可能會永遠都處在分析停滯狀態，而構建 ESB 可以實際完成一些看得見的工作。
這經常被稱為連接一切 的項目�？蛻粲泻芏嗖糠帧獞贸绦�、計算機系統、數據中心、部門、子公司、外派機構、合作伙伴和客戶——這些部分彼此并不通信。各個部分對其他部分所進行的工作毫不知情。一個部分擁有另一個部分需要的數據，因此這兩個部分需要協同工作。只有所有的部分連接到一起，才能夠都正常工作。與嘗試了解業務需求的無效果相比，連接一切是一個能夠解決的問題，因為其解決方案是技術。如果將 IT 部門比作錘子，則 ESB 就是 SOA 的釘子。
他們的想法經常是，“我們不知道還需要別的什么，因此目前我們將僅僅構建 ESB�！钡@與“您開始編寫代碼，我們將了解他們需要什么”方法有什么實際的區別么？
ESB“夢話之地”介紹
讀者經常通過單個屬于來對連接一切的想法進行總結：企業服務總線（ESB）。那么，他們在說需要 ESB 的時候到底是希望什么呢？他們的 ESB 指的是什么呢？是否真的有必要將其稱為 ESB？
客戶經常喜歡將 ESB 中的第一個詞替換掉。他們不使用企業，而使用其它的組織單位，如公司、部門或政府。有時候還會使用其用途進行描述，如采購或工資單�；蛘呙枋銎鋵鬟f的內容，如產品或訂單。即使客戶所需的是公司產品采購服務總線，也不要被服務總線 之前的詞語所迷惑。這些客戶需要的是 ESB。他們有時候甚至會這樣描述需求“一個 ESB，但……”。
客戶的重點實際上在最后一部分：總線。在包括總線的技術拓撲中，所有對象都連接到總線，因此，也使用總線連接到所有其他對象�？偩�是各個部分間通信的主干道。應用程序間的通信（甚至網絡上計算機之間的通信）通常都使用消息（即一系列不同的信息數據包）完成。Enterprise Integration Patterns 一書（請參見參考資料部分提供的鏈接）對此進行了很好的概述，其中將此類連接稱為消息總線。
客戶機經常不會太多考慮 ESB 的服務部分。xSB（x 可以為企業或別的什么）用于調用服務，否則就只是消息總線。服務調用指一個應用程序告知另一個應用程序進行什么工作，而后者將完成此工作，而且通常會發送回響應，以報告結果。
因此，如果客戶希望構建的是 xSB，那服務是什么？IT 人員可能會說，“服務可以是所需要的任何形式的東西”。這是最明確地指出，該項目實際上仍然是一個技術性的解決方案。暗示服務不相關，就是在說使用總線的應用程序不相關，應用程序如何使用總線不相關，而且應用程序集成需求（算不上業務需求）不相關。xSB 將用于任何目的。針對 SOA 進行了體系結構設計的 ESB 最初可能會忽略很多這樣的服務需求，因為服務會在充實 SOA 的過程中變得明顯起來。但沒有 SOA 的 ESB 沒有服務，因此只是總線而已。
只構建總線 的項目可以視為 IT 夢話之地 項目。就像 Kevin Costner 在“夢話之地”(Field of Dreams) 這部棒球運動電影中的角色一樣，IT 部門所持有的態度是，“如果您建了，他們就會來�！比绻麡嫿丝偩�，人們就會圍繞總線構建 SOA 應用程序�！皦粼捴亍钡膯栴}在于，與好萊塢的世界不一樣，在業務世界中并不能保證服務將會出現。如果人們構建 SOA 應用程序，可能不會像您所構建的應用程序那樣，因此可能必須進行大量的重新構建工作后才能使用。即使最后投入了使用而且效果非常好，得到回報的延遲也非常大，而這可能會讓 IT 部門在等待“電影”最后的美滿結局的過程中感到十分難熬。
回頁首
了解面向 ESB 的體系結構的局限性
ESB 有什么問題呢？還記得在電影的中間 Annie 想和 Ray 離婚的部分嗎？（就是整個第二幕的內容，此時每個人都認為 Ray 是個傻瓜。）您的項目也將經過這樣一個時間段，項目贊助人可能并不希望他的員工離自己而去！
問題是：ESB 本身不產生任何業務價值。ESB 是實現目的的手段，而不是目的本身。ESB 就像 SOA 的電線或水管。水管并不產生價值，帶有能放出水的水龍頭的水池能帶來價值。電線不會產生價值；但電燈（特別是連接到開關的電燈）具有價值。除非一條路能夠讓您從一個位置達到另一個位置，否則這條路就沒有價值。沒有 SOA 的 ESB 就像一條起點和終點沒有意義的路。人們可能會最終希望去這些地方，但此前這條路所帶來的全是成本，沒有好處。
面向 ESB 的體系結構有個固有的缺點，即它所構建的是沒有人要使用的連接。除非系統彼此連接并協同工作，否則業務并不會帶來任何其他價值。在此之前，ESB 只是沒有好處的開銷而已。IT 部門可能會因為搭建了某些實際的東西而感覺不錯，但業務部門決不會有任何好的感覺，業務部門依然無法完成那些在沒有 ESB 時候就無法完成的工作。ESB 成了 IT 部門可有可無的東西，也成了已部署的應用程序拓撲中的累贅。
不要遵循 IT“夢話之地”方法所奉行的“如果您建了，他們就會來”，極限編程（Extreme Programming，XP）中的一句話可能更為恰當：“您將不需要它�！边@句話代表了一個非常實用的原則：
在真正需要的時候實現所需的內容，而不要在預計會使用時進行實現。
這個原則（直到需要時才構建）與 IT“夢話之地”方法奉行的原則相反。不要因為希望有人將會使用而進行相關的構建工作，而是要在知道有人真正需要時才進行構建。這樣就可以確保能構建他們真正所想要的東西，而不是您認為他們可能會最終需要的東西。這樣只有在您真正想獲得這個構建帶來的好處時才進行構建，直到這個時候您才需要付出相應的成本。此原則是一個很好的業務哲學，也適用于 IT 部門和業務的其他部分。
回頁首
使用 SOA
現在來回顧一下前面的內容，下面列出了一些任何軟件開發過程都適用的原則：
直到需要時才構建。 構建可帶來業務價值的東西。 使 IT 與業務保持一致。不要采用面向 ESB 的體系結構，而要采用 SOA，將 ESB 作為 SOA 的一部分構建。也就是說，按照 IBM SOA Foundation: An architectural introduction and overview（請參見參考資料部分提供的鏈接）所述的關于進行 SOA 開發，創建和集成采用 SOA Foundation 體系結構的應用程序。
通過此方法，可以將 ESB 作為 SOA 的一部分進行開發。您將根據業務需求發現服務。每個服務不僅需要提供者和使用者，還需要 ESB 中的通道來連接這兩者。該通道就像提供者一樣實現服務接口（但實際充當代理），包括支持服務的遠程調用（如進程內通信）的服務請求和響應的消息格式。使用者和提供者的服務接口、消息格式、范圍和服務質量的區別可以通過中介予以解決和消除。所有這些都是 ESB 設計的核心，而且在不知道 ESB 調用的服務的情況下根本不能進行其中的任何工作。了解這些服務，還需要了解 SOA 中將使用 ESB 的服務。
從這點而言，連接應用程序是較為容易完成的部分。將其業務功能連接起來將是更大的挑戰。這不能通過僅構建 ESB 來實現。
回頁首
結束語
客戶經常僅僅構建 ESB，因為這涉及到沒有雜亂的業務需求的技術挑戰。僅僅構建 ESB 沒有實際意義，因為在這種情況下 IT 構建 ESB，然后希望某個 SOA 將出現并使用這個 ESB。這種面向 ESB 的體系結構缺少 SOA 的好處。它并不能帶來業務價值。事實上，它會在沒有直接好處的情況下產生成本。而且這樣并沒有保持 IT 與業務的一致性。面向 ESB 的體系結構的更好的替代品是 SOA。不要僅僅構建 ESB，而要將其作為 SOA（最好符合 IBM 建議的 SOA Foudation 體系結構）的一部分構建。
文章來源于領測軟件測試網 http://www.k11sc111.com/
