企業服務總線技術並不是魔法棒，但它在處理某些事務方面很有效。
來自IBM Database Magazine中文版。
儘管引用了 1996 年 Spike Lee 的電影，這個欄目中的 bus 不是那種帶輪子的巴士；它是一種通常稱爲企業服務總線（ESB）的中間件。在過去的兩年中，我從一個 ESB 懷疑論者轉變成一個 ESB 迷。
我將向您展示我的轉變，並且提供關於什麼是 ESB 的見解，以及如何使它適應企業的應用程序基礎設施。
從本質上講，ESB 是一個簡化應用程序間通信的軟件。它還能夠簡化企業在多個應用系統之間共享數據和功能，支持複雜的處理需求。ESB 還可以在不同應用程序之上提供一個一致層（邏輯上來講），顯著地減少編寫訪問這些不同系統的開發人員的工作量。通過這些應用鏈接和後端抽象功能，ESB 可以幫助企業實現面向服務架構（SOA）。 瞭解 ESB 的一些事項：
- ESB 的 “骨幹” 通常是一個消息隊列和發送機制，例如 IBM 的 WebSphere MQ（以前稱爲 MQSeries，我稱之爲 MQ）。
- ESB 可以提供基於內容的消息路由（正確路由基於消息內容的消息的能力，相對於基於消息標題信息）。
- ESB 可能有針對不同打包應用程序（例如 SAP 和其它供應商出售的應用程序）的 “適配器”。
- 應用程序通常可以通過 “正常” 的接口與 ESB “對話”。這種接口包括 Java 消息服務（Java Message Service，JMS）、簡單對象訪問協議（SOAP）和 HTTP 等。
- ESB 可以訪問公開爲 Web 服務的應用程序的函數（雖然這通常被認爲是 ESB 最佳實踐，但是 ESB 並不限於使用 Web 服務作爲調用手段）。
- ESB 可以提供數據轉換服務，例如將 XML 標籤數據轉換成在 CICS COMMAREA 中被替換的輸入字符串（反之亦然）。
- ESB 可以包含可用來定義工作流的 “規則引擎”。
- ESB 可以包含一個 “流程引擎”，它能根據通過規則引擎指定的規則來執工作流（以後有關於此的更多內容）。
  |
|
當我第一次聽說 ESB 軟件時，我的企業正在使用 DB2。一些公司在嘗試向我們銷售 ESB 產品，並且我的企業有幾個人支持這些技術。我很長時間內看不到 ESB 的實際用途。我知道 ESB 與消息處理有關，但是我們已經有一個成品 MQ。ESB 能做哪些 MQ 不能做的工作呢？
當有人建議（再次說明，是公司裏面的支持者）後端應用程序服務的所有請求（包括通過 DB2 訪問程序提供的數據請求）都應該通過 ESB 時，我的懷疑開始發生動搖。我再次思考：“所有請求？即使是我們的最高量同步 [從用戶角度而言] 事務也包含？”。那對我沒有意義。它意味着添加一層軟件（或插入一個額外的軟件）來處理需要快速響應時間的流程。這不會奏效。
隨着我學習關於 ESB 技術的更多知識（通過接觸其僱主已經部署 ESB 解決方案的人員），我改變了想法。我現在發現，對於某些類型的事務，使用 ESB 可以產生顯著的優勢，並且通過 ESB 運行所有請求是一些企業的最佳選擇。
|
|
我相信，ESB 用於 ACL 事務（即異步、長期運行和複雜的事務）時能獲得最大的優勢。
對於異步，從發起用戶的角度來看，處理過程的完成事務是一個異步事件。
考慮一個簡單的訂單輸入流程。消費者想要在線購買一件特定的襯衫。當用戶輸入的信息更新了後端訂購管理系統數據庫時，服裝廠商認爲事務完成。如果後端處理可以足夠快地完成，那麼讓用戶等待工作完成沒有問題。用戶在他的屏幕上看到一個沙漏標，當事務完成消息被髮送到服裝廠商時沙漏標消失，這在後端數據庫更新發生之後發生。如果響應快速，那麼每個人都很高興。
如果事務量達到很高的級別（每秒幾千次）或者關聯的後端處理變得非常複雜（因此很耗時間），那麼處理模型就會崩潰。對於這種情況，使用發起用戶異步的方式進行儘可能多的處理就會很有意義。
考慮經紀公司部署的股票購買程序。它的量非常大，並且處理的完成取決於不受經紀公司控制的系統（它們由證券交易所運行）。這些情況中，明智的方法是儘可能將購買/銷售事務處理的同步部分壓縮成基本的 “我們已經收到您的訂單” 消息，表明已經在強大而可恢復的數據倉庫中捕獲到用戶交易指令。
收到 “訂單已收到” 消息後，用戶可以單擊 “查看訂單狀態” 按鈕。通常，在單擊 “查看訂單狀態” 幾秒鐘後，用戶將看到訂單已經按計劃執行，以每股 z 美元（或歐元、或日元等）購買（出售）了 Y 公司的 x 股股票。
如果交易訂單比通常完成的時間長一點，那麼用戶會在單擊 “查看訂單狀態” 按鈕後看到一些形式的 “執行掛起” 消息；這條消息可能伴有 “刷新訂單狀態” 鏈接。單擊該鏈接很有可能使用戶收到 “訂單執行完成” 信息。
同樣，這樣每個人都很高興。用戶很快收到 “訂單已收到” 確認（並且可能在可接受的時間內看到 “訂單執行完成” 信息），並且經紀公司能夠有效地管理從訂單捕獲的那部分處理流程。
將 ESB 放入工作流中確實給應用程序增加了一層代碼，這可能會影響響應時間（後面您將看到，可以減輕這種影響）。但是，給事務處理的異步部分增加一點響應時間通常不是什麼大問題，這是我喜歡爲異步工作流使用 ESB 的原因。
“但是，等一下”，您可能會說：“難道不能使用 MQ 和用於消息存取的代碼來處理異步工作流嗎？爲什麼要購買 ESB 呢？”
好問題。答案是我的 ACL 異步有許多複雜和長期運行的部分。
|
|
不相信我嗎？您不認爲在現實中存在一些事務，並且日曆能夠提供合適的響應時間度量的嗎？請再次思考。
假設公司 ABC 允許客戶在線訂購其產品。公司 QRS 的員工（公司 ABC 的客戶之一）爲產品 XYZ 輸入一個訂單。下面是接下來發生的情況：
- 訂單信息被公司 ABC 捕獲，訂單輸入人員收到 “訂單已收到” 消息。
- 產品 XYZ 的訂單出現在公司 ABC 的一個員工的工作隊列中，他負責與訂單管理應用程序交互。
- 與訂單有關的信息到達使用應用程序生成構建請求的另一個員工那裏（可以用各種方式配置產品 XYZ）。
- 出貨部門的人員在應用程序中輸入確定所訂購產品出貨日期和運輸方式（常規的水陸運輸、空運等）的信息。
- 一些員工在生成發票的帳單應用程序中輸入信息。
- 一個客服人員在生成電子郵件的應用程序中輸入信息，爲輸入訂單的個人發送郵件（“謝謝您訂購 XYZ。如果您在接下來的 30 天內訂購 XYZ 增強的 JKL 產品，我們將給予您 10% 的折扣”）。
朋友們，這個事務（唯一的同步部分是 “訂單已收到”）不僅是異步的，並且是複雜的（涉及多個完全不同的應用系統）和長期運行的（“訂單已收到” 和 “產品已發出” 的時間可以是幾天）。
在這裏，ESB 可以產生可觀投資回報。對於新手，ESB 可以減小（有時極大地減小）ACL 事務的週期時間。如何減小？通過 ESB 規則和流程引擎提供的工作流控制。
通過規則引擎定義了複雜的產品訂單等流程之後，流程引擎將確保每個關聯的子流程（訂單管理、構建請求、記帳、出貨、客服等）以正確的順序執行直至成功完成（否則，會產生一個警告併發送到相應的組等待解決）。這種協作可以手動完成，但是 ESB 始終在工作，縮短週期時間。各個子流程與不同應用系統交互不會產生問題；ESB 設計用於大多數應用平臺。ESB 會在複雜的流程中丟失數據嗎？不會，ESB 的基礎是一個強壯並可恢復的消息隊列和傳輸機制（在 IBM 的 WebSphere Enterprise Service Bus 中是 MQ）。
這裏速度是最大的優勢，它提高了服務質量。ESB 始終遵循規則。如果正確指定了規則，決不會發生因爲以錯誤順序執行子流程而導致遺漏步驟和掛起。
真的不錯，不是嗎？許多企業已經通過 ESB 將工作流編排變成工作的初始活動，從而實現 SOA。
|
|
在實際場景中，已經成功通過企業的 ESB 處理後端應用服務的所有請求。這樣做的好處是：調用應用服務的一致接口。
這不能使用不需要 ESB 的 Web services 來實現嗎？可以，但要請記住 ESB 的規則引擎。我知道有一家公司由於一系列的收購活動而擁有幾個企業資源計劃（ERP）系統。ESB 爲訪問不同系統提供一致的方法；ERP 服務消費程序的開發人員根據 ESB 進行編碼（基於內容路由消息將請求傳遞給正確的後端系統）。後來，當公司準備撤銷一個 ERP 系統（其數據已經被遷移到另一個系統）時，它只需通過 ESB 的規則引擎進行更改；將流向 ERP 系統 A 的請求引向 ERP 系統 B。
另一個例子：一家實現 SOA 的公司使用 ESB 來避免程序員從頭編寫應用服務（服務重用是 SOA 的關鍵原則）。所有應用服務請求都需要經過 ESB，任何應用服務都必須註冊到 ESB，以便其可用於服務消費程序。這種嚴格的方法提供 “門檻”，允許檢測服務重複。允許服務請求繞過 ESB 將提供一個終止運行，它會導致丟失開發流程規則，這又會導致重複的服務開發和 SOA 無法提高程序員的生產率。
但是，如果在服務請求和服務提供程序之間放置額外的代碼層（ESB），情況會怎樣呢？是的，額外的路徑長度的確存在。但是 ESB 產品通常提供一些功能（比如數據緩存），這能夠減輕 ESB 對事務吞吐量和響應時間的影響。關於數據緩存的更多信息，請參閱參考資料中的專欄 “Can SOA Perform?” 。
|
|
我的目的並不是展示 ESB 產品能爲所有應用集成和 SOA 需求提供解決方案。它不是魔法棒，但這門技術確實爲多個行業的許多企業帶來了利益。您可以幫助公司檢驗一些 ESB 產品。以懷疑的態度接近這些產品。我就是這樣做的，並且最終發現了隱藏在表面現象背後的價值。
|
|
- 本文從 IBM Database Magazine 期刊（原 DB2 Magazine）取得授權並進行翻譯，參見 IBM Database Magazine 站點 上的 英文原文。
- 通過訪問 “數據架構師：SOA 可以產生良好的性能嗎？” ，（IBM Database Magazine,2008 年,第 2 期），他解釋了 SOA 開發中是否可以產生最好的性能。
- 通過訪問 developerWorks 中國 Websphere 專區的 “Enterprise Service Bus 專欄 ”，討論 ESB 的定義和價值、技術標準選擇、IBM ESB 產品、ESB 實施模式等理論知識。
- 通過訪問 developerWorks 中國 Information Management 專區的 IM 和 Rational 集成應用開發 專題，獲得更多 Rational Data Architect 相關的文章、教程和多媒體課件等學習資源。
- 通過訪問 developerWorks 中國 Information Management 專區的 Data Studio 資源中心 ，獲得更多 Data Studio 相關的文章、教程和多媒體課件等學習資源。
- 通過訪問 developerWorks 中國 Information Management 專區的 DB2 9 技術資源中心， 獲得更多 DB2 9 相關的文章、教程和多媒體課件等學習資源。
- 下載 DB2 V9 試用版 體驗 DB2 最新的技術特性。
- 下載 IBM Data Studio 體驗 IBM Data Studio 開發技術新特性。
- 下載 IDS 11 試用版 體驗 Informix 最新的技術特性。
- 通過訪問 alphaWorks 獲得更多 IBM 的前瞻性技術和資源。
- 通過訪問 IBM Database Magazine 站點 community 專題 獲得更多用戶體驗和交流信息。
| ||
|
Robert Catterall ([email protected]) 是 Catterall Consulting 的總裁。Catterall Consulting 是一家幫助客戶有效利用關係數據庫技術（特別是 DB2）的公司。 | |