soa已然是企業級開發的必定之路。有人會問：我們有了oop，還須要soa嗎？好吧我承認，這個問題也困擾了我非常久。現現在我得出的結論是：oop是oop，soa是soa。
oop是指物件導向程式設計。是指程式開發中的程式設計思想或者是程式設計設計方法。它的產生是為了彌補面向過程開發的缺陷，用現代人的思維方式編敲**的方法。
soa（面向服務的體系結構service oriented architecture）是大型分布式系統的架構模式，它讓架構師站在了乙個全新的角度理解企業級架構的開發。
soa本質上是一種架構模式，它與物件導向相比，它是乙個粗粒度、松耦合的元件架構模式。它的產生，也是隨著生產關係的變化，不適應生產力發展的須要。
面對公司陳舊的老系統，能夠用乙個詞來形容雞肋（食之無味，棄之可惜）。
企業是要生存的，不可能全然丟棄老系統，去開發乙個全新的系統。況且在新的系統，也會變成將來的老系統。推倒重來，不是乙個長久的解決的方法，正途是須要與老系統進行整合。這樣，soa就登場了。
那麼oop與soa的關係，你可能也有點兒明確了。soa的內部實現。可能會使用oop實現，但這不是肯定的。soa內部全然能夠採用其它設計方法進行實現。所以oop關注的是程式設計層次。soa關注的是架構模式層次，它希望通過服務化，來實現系統整合，解決資訊孤島。
談了這麼久的soa。那麼什麼是esb呢？esb是soa的重要實現手段。
大家應對各種各樣詳細的需求。也就對soa有了行業性的理解，結果就是現現在各種各樣的esb產品。這些esb都致力於解決各行各業的問題。
esb的表現形式儘管有非常多，可是從巨集觀作用上來講是一致的。
它能實現於各系統見的協議轉換、資料裝換、動態路由功能。
我也僅僅是接觸過幾個esb的產品：mule esb、jboss esb以及shuttle esb。關於再詳細的關於esb的東西。我也僅僅能是談下自己的理解。由於這些產品，功能各異，側重的實現不一。
mule esb以輕量級著稱。它是基於實際需求的整合問題而設計實現的。它能輕鬆的與眼下的系統進行整合，並且非常easy進行再擴充套件。它標榜可以解決一切資訊孤島問題。用一位同事的話來形容：mule就是乙個大雜燴，它裡面什麼都有，所以可以完畢各種格式資料的轉化；
jboss esb比較重量級，它必須部署到jboss的應用server中，並且它主要專注於與jboss產品的整合。
shuttle esb是.net平台基於事件的專案。
這是乙個比較新的開源專案。我眼下專案中，就負責這一塊的開發與研究。
我會在後文中。著重介紹shuttle esb在我們專案中的應用。
與此同一時候，我在網上也找了一些資料，也看了非常多官網，發現大家都說的都有道理，並且它們都是致力於不同行業問題的不同解決方式。總結起來。esb主要起到例如以下作用：
如上圖所看到的，這就是esb的基本思路的一種實現。
不管是系統內部的服務呼叫，還是系統間的呼叫。都會走esb這條服務匯流排。不管哪乙個系統，都之和esb有關係，減少系統間的耦合性，便於系統的功能擴充套件。
這裡發揮的是esb強大的連通性。整合老系統也是應用了該思想。這個訊息通道，也是乙個服務中介，為各系統提供基礎的服務支援。
這麼看來，似乎esb應該是統一的，不應該有那麼多產品的出現，實則不然。
實際需求中，業務邏輯是複雜的，一種esb產品內不可能包括對每乙個系統都通用的服務。
詳細到訊息、事件，詳細實現也不可能做到面面俱到。
多個服務進行編排形成新的服務。
esb支援乙個直觀形式定義新服務的流程。soa有兩個核心元件：乙個是esb。乙個是bpel。esb是基礎設施，bpel是業務流程驅動下服務的整合與整合。離開soa。esb將失去全部連線的服務，而不過乙個匯流排。bobby做過乙個比喻：路是沒有不論什麼價值的，除非你利用它把乙個東西從乙個地方一道還有乙個地方。離開soa，esb就像乙個沒人通行的道路。
esb作為一條匯流排。插入系統之中。所以，就要求esb具有無狀態。高吞吐量的特點。
所以，怎樣給esb**，也是一款成功產品在架構設計中，必定要考慮的問題。
只是，esb的使用，要注意系統的效能問題。記得gxpt專案中，系統間的通訊採用的是webservice，webservice的效率就已經非常低了，中間再走一層esb的話，無疑會減少系統的效能，這些在系統架構。必須考慮進去。
智慧型路由 ESB
soa已然是企業級開發的必然之路。有人會問 我們有了oop，還需要soa嗎？好吧我承認，這個問題也困擾了我很久。現如今我得出的結論是 oop是oop，soa是soa。oop是指物件導向程式設計，是指程式開發中的程式設計思想或者是程式設計設計方法。它的產生是為了彌補面向過程開發的缺陷，用現代人的思維方...
ESB企業服務匯流排 ESB概述
談及企業服務匯流排 esb 在有面向服務的架構 soa 實施經驗的開發者眼中一定不會陌生。這些年，人們一直在談論它，以至有些人認為 實施soa一定需要esb 或 只要將esb架起來了，我們就soa了 這些說法有可取之處，也存在片面之嫌，由於業界對於esb沒有統 一 標準的定義，所以一千個人眼中有一千...
ESB架構筆記
又一次重溫esb的兩份經典文件 esb綜述1 定義esb esb綜述2 esb使用案例 infoq defining the esb ddj 還有一本三年前的 enterprise service bus o reilly，想想還是算了。openspace 架構，感覺傳統j2ee的程式設計模型的影響...