這些年人們一直在談論SOA，有過面向服務開發經驗的人對企業服務匯流排ESB一定不會陌生。但大家對ESB的理解卻並不相同，可能是千奇百怪的，我找了很多資料，也沒有找到一個能被大家普遍接受的定義。正式因為對ESB的理解不同，大家對ESB的使用也不同。我覺得應該清楚地認識ESB在SOA中扮演的角色，才能讓ESB真正在幹分內的事情。

最近在實施一個採用ESB的專案，純靠幾個人研究，大家以前都沒有這方面的經驗，算是摸著石頭過河吧，走了很多彎路，供大家參考。

1、一勞永逸現實嗎？

一開始，我們的設想是：能否設計一個一勞永逸的ESB中間平臺，將來不論哪種服務都可以方便地接入到ESB上，當服務足夠多的時候，我們就可以提供一個萬能平臺。

這個想法很讓人興奮，我們在做的專案也確實在往這個目標上靠，但現在看來，這個想法有些天真了。首先，當不同的客戶端採用不同的方式訪問同一個服務的時候，這個時候，服務裡的仲裁邏輯是非常具體的，我們要考慮的不僅是協議的差異，還要考慮訊息格式的差異。另一方面，具體的業務往往是複雜的，並不存在對每個系統完全通用的服務，就像不可能存在兩個完全一樣的人。如果讓ESB去關心業務層面的事情，我覺得本身就是對ESB的片面認識，複雜的業務應該在具體的業務系統中實現，ESB解決的事技術層面的工作。

如果我們定義一套標準的資料介面，使用統一的協議，所有ESB服務的消費者和生產者都遵循該標準，那麼是不是就可以呢？

這樣的做法肯定是為了簡化ESB的開發工作，但如果要求所有的外圍應用的協議標準和資料標準都統一了，那我們要ESB幹什麼？

丟失了ESB本身最強大的連通性方面的功能，正式因為需要聯通的應用之間的差異性，才逐漸發展出了ESB這樣的元件

2、在一個系統中所有的業務操作都採用ESB，採用訊息機制，即系統的下層為上層提供服務。

之所以會想到這種方式，是為了最大限度的提高系統的靈活性和可擴充套件，可維護性，即我們可以通過服務編排和新增服務來滿足系統的需求變更。

現在看來想法太過幼稚，第一，原本很簡單的業務，我們需要編輯很多程式碼，配置很多XML才能完成，最後導致系統很臃腫。第二，通過ESB,

3、用ESB實現業務流程

我們看到ESB支援服務組合（ServiceComposition）模式，進而認為可用該模式來實現業務流程。因此，ESB產品就演變成了BPM產品。

事實上，二者有著本質的區別。其一：ESB是一個偏向技術層整合的元件，比如將“使用者資訊修改”服務與“日誌”服務組裝起來，得到的結果還是“使用者資訊修改”服務，只是在仲裁流中間插入了一個新的附加功能，即“日誌”服務。BPM中的服務編排的含義很側重於業務流轉的概念。比如“專案立項審批流程”，該流程的實現可能需要來自幾個相關係統中的服務的參與，它們可能是“立項申請”，接著是“一級職能經歷審批”，然後是“部門經理審批”，“財務審批”等。這些服務流轉起來形成的是一個完整的業務流程。其二：ESB上的服務組合是無狀態的，ESB執行時會為每個請求建立一個例項來執行其仲裁邏輯，請求與請求之間沒有時序關係，是互不相干的、各自獨立的。相反，BPM上的服務編排這不一樣，未完成的業務流程例項一直會存活在BPM執行時中，存活期可能為一天、一週、甚至1個月或更長；請求與請求之間可能存在著一定的關聯性，比如對與一個專案（相同的專案ID）的立項審批流程，一級職能經理、部門經理和財務對流程發出的請求都是針對同一執行時例項的。

應該認清認清技術上的服務組合與服務編排之間的差異。

4、用ESB做資料傳輸匯流排

我們僅僅使用ESB去從一個系統把資料直接搬到另一個系統。也就意味著只使用了ESB提供的連通性功能，而沒有使用其他功能，如訊息解析，轉換，路由等。

ESB作為企業級的服務聯通、管理平臺，需要穿透ESB的服務應該是企業內重用可能最大、價值最大的那些服務，應用程式對這類服務的訪問應該非常頻繁，因此同一時刻需要ESB支撐的業務可能非常繁重。所以，ESB產品的設計初衷是實現一個無狀態、高吞吐的服務匯流排，為企業內重要的業務服務提供透明、標準、開放的接入能力。如果僅僅是作為一個數據傳輸通道，去傳輸大量資料，並不划算。

以上只是我的片面思考，也參考了一些大牛的意見，希望大家在實施ESB的時候，能真正理解ESB到底能幹什麼，放在什麼位置上最合適。

參考文獻

等等