企業 SOA 整體方案
在前一篇《SOA、ESB、NServiceBus、雲計算 總結》中說到，SOA 是面向服務的架構，其核心思想是把業務進行組件化，而業務組件的能力服務化。
我們的整個 SOA 的設計分爲兩個層面：一個是系統間的 SOA 設計，另一個則是單個系統內的 SOA 設計。系統間的 SOA 設計，主要是設計一個 ESB 系統來實現各業務系統間的交互。而系統內部的 SOA 設計，則是建立一個組件化的技術平臺，使得系統的開發能以一個個業務組件的形式完成，並通過技術平臺來實現各業務組件的組合與互連。
一般說的 SOA 設計，都是在講如何進行系統間的互連，例如如何進行 ESB 的設計。但是，不論是系統間互連，還是系統內部的組件化，其實都是 SOA 思想在不同層面上的體現。而我認爲，應用系統內部的 SOA 設計，會更重要。因爲它不但是一個低耦合、高複用的產品設計，而且也爲系統間的 SOA 提供了更好的支持。
本文，主要說明如何實現 ESB 的設計。而更重要的應用系統內部的組件化產品開發平臺，則留到下一篇。
ESB 目標功能
在前一篇中，列出了一個較完整 ESB 應有的功能。SOA 不但包括簡單的系統間互邊的功能，也應該包含更高級的 BPM 業務流程編排的功能。
下面，簡單列出了我們對於我們的 ESB 的功能樹：
圖中，功能按優先級進行了排序。第一個階段，只會實現其中紅色的部分。而服務編排，則放到了最後。紅色部分，是一個 ESB 應該具有的最小功能集。在交互模式部分，我選擇了實現‘響應/請求’模式，這種交互方式在系統間互連時場景相對較少，但是不需要引用 MSMQ 等功能，所以實現起來會更簡單。
ESB 主體設計
對於 ESB 的主體設計，是參考了網上另一個 ESB 的設計，下面是它的設計圖：
ESB 詳細設計
首先，規劃出 ESB 整個系統內部的所有組件。
Web Portal：ESB 對外以網站的形式公佈。同時，服務調用者、提供者，都是直接使用網站提供的功能。
Adapter：協議的適配器組件。
Service Invoker：服務的同步調用器。
Async Invoker：異步方式的同步調用器。
Service Mocker：這個組件用於實體 ESB 的服務可以以 WS 等方式暴露。
ESB Message：ESB 內部的消息結構體。
Service Registry：服務的註冊庫。
Service Router：服務的路由器組件。
Service Router Cache Notification：路由緩存通知組件。
Logger：日誌組件。
Exception Handler：異常處理組件。
Performance Counter：服務調用過程中的一些性能統計工具。
以下是一些詳細的調用設計。
ESB 網站：
模擬服務：
服務的調用：
服務調用過程中的管道模塊設計
路由表及路由更新：
適配器：
最後，是最重要的持久化的領域實體：
