企業 SOA 設計(1)–ESB 設計

通訊	服務交互
路由尋址通訊技術、協議和標準（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS）發佈/訂閱響應/請求 Fire-and-Forget，事件同步和異步消息傳遞	服務接口定義（例如，Web 服務描述語言（Web Services Description Language，WSDL））支持替代服務實現通訊和集成所需的服務消息傳遞模型（例如 SOAP 或企業應用程序集成 (EAI) 中間件模型）服務目錄和發現
集成	服務質量
數據庫服務聚合遺留系統和應用程序適配器 EAI 中間件的鏈接性服務映射協議轉換應用程序服務器環境（例如 J2EE 和 .NET）服務調用的語言接口（例如 Java 和 C/C++/C#）	事務（原子事務、補償、Web 服務事務（WS-Transaction））各類肯定的傳遞範例（例如 Web 服務可靠消息傳遞（WS-ReliableMessaging）或對 EAI 中間件的支持）
安全性	服務級別
身份驗證受權不可抵賴性機密性安全標準（例如 Kerberos 和 Web 服務安全性（WS-Security））	性能吞吐量可用性其餘能夠構成契約或協定的持久評估方法
消息處理	管理和自治
編碼的邏輯基於內容的邏輯消息和數據轉換有效性中介對象標識映射數據壓縮	服務預置和註冊記錄、測量和監控發現系統管理和管理工具的集成自監控和自管理
建模	基礎架構智能
對象建模通用業務對象建模數據格式庫 B2B 集成的公共與私有模型開發和部署工具	業務規則策略驅動的行爲，特別是對於服務級別、服務功能的安全和質量（例如 Web 服務策略（WS-Policy））模式識別

而最低要求的 ESB 須要具備的功能：

通訊	集成
提供位置透明性的路由和尋址服務控制服務尋址和命名的管理功能至少一種形式的消息傳遞範型（例如，請求/響應、發佈/訂閱等等）支持至少一種能夠普遍使用的傳輸協議	支持服務提供的多種集成方式，好比 Java 2 鏈接器、Web 服務、異步通訊、適配器等等
服務交互
一個開放且與實現無關的服務消息傳遞與接口模型，它應該將應用程序代碼從路由服務和傳輸協議中分離出來，並容許替代服務的實現。

相關資源：

面向服務架構（SOA）和企業服務總線（ESB）

ESB同步,異步選擇,從項目實際出發(電信)

NServiceBus

NServiceBus 是 .NET 平臺上最受歡迎的一個開源 ESB 框架。有較完善的文檔及示例代碼。

目前，.NET 平臺上開源的 ESB 框架，大多基於消息隊列來實現。NServiceBus 一樣也使用消息隊列機制來實現消息的傳遞，例如可使用 MSMQ。因爲消息隊列天生就是異步傳輸的，因此 NSB 也一樣只支持異步消息，是一種‘發送即忘卻’的模式。（As a general purpose communications technology, WCF does not enforce the queued messaging paradigm. NServiceBus does, and the architectural implications are profound.）。

NServiceBus 相對於 WCF 的優點在於：事件驅動的架構（發佈、訂閱）、更好地支持長時間運行的工做流。

缺點一：只支持異步的消息機制的問題是，沒法進行傳統的的數據查詢。（To allow clients to perform queries, it is best not to use NServiceBus. Messaging is designed for non-blocking operations, and queries are (for the most part) operations for which the user wishes to wait.）

若是必定要使用 NSB 來實現數據查詢，那麼只能經過 CQRS 來進行系統的設計：

缺點二：NSB 的服務能夠輕易集成到 WCF 中使用 MSMQ 實現，可是反之則不行。也就是說，已經使用 WCF 開發的服務，是沒法使用 NSB 來完成簡單的遷移的。（緣由也主要是由於 NSB 的異步機制。）

NServiceBus---最流行的開源企業服務總線 for .Net

NServiceBus 開源通信框架（幾種通訊模式）

三篇筆記：1、2 錯誤處理、3

雲計算，及與 SOA 的關係

雲計算是一種部署體系結構，而 SOA 則是企業 IT 的體系結構。

SOA與雲整合既帶來應用和業務流程靈活的虛擬化和節省的費用（雲），又帶來原有應用的集成應用及業務流程的敏捷重構（SOA）。

上層基於 SOA 進行應用服務的開發，底層基於雲計算進行資源整合，包括存儲，網絡，數據庫，服務器等。

目前業界比較多的觀點贊同：SOA 與雲計算將整合發展。

它們的關係：

從產生的背景和緣由看，SOA產生的緣由是爲解決企業存在的信息孤島和遺留系統這兩大問題。雲計算產生的緣由是企業的信息系統數據量的高速增加與數據處理能力的相對不足，還有計算資源的利用率處於不平衡的狀態。
從關鍵的技術和屬性看，經過產生背景和緣由的分析，SOA和雲計算是不一樣的概念，可是它們卻互相聯繫，又有必定的類似性。從服務角度來看，SOA實現了能夠從多個服務提供商獲得多個服務（一個服務即是一個功能模塊），並經過不一樣的組合機制造成本身所需的一個服務；雲計算實現了全部的資源都是服務，能夠從雲計算提供商購買硬件服務、平臺服務、軟件服務等，把購買的資源做爲雲計算提供商提供的一種服務。
從關鍵技術來看，SOA須要實現業務組件的可重用性、敏捷性、適應改變、鬆耦合、基於標準；雲計算則須要虛擬化技術、按需動態擴展、資源即服務的支撐。
從應用場景來看，當企業的業務需求常常改變的時候能夠考慮使用SOA；當企業對IT設施的需求常常改變或者沒法提早預知的時候能夠考慮使用雲計算，當有大量的批處理計算的時候也能夠考慮使用雲計算。
從應用的側重點來看，SOA側重於採用服務的架構進行系統的設計，關注如何處理服務；雲計算側重於服務的提供和使用，關注如何提供服務。
從商業模式來看，SOA可能會下降軟件的開發及維護的成本，商業模式是間接的，須要落地；雲計算根據使用的時間（硬件）或流量（帶寬）進行收費，具備明確的商業模式。

下面列出最近看的與本文相關的一些 pdf 書籍，東西太多，不上傳了，列下書名：

《中國SOA最佳應用及雲計算融合實踐》、《SOA in the Real World》、《SOA應用案例分析及設計》、《A Developer’s Guide to the Microsoft .NET Service Bus》、《IBM ESB概要設計說明書@CBOD》、《Mule+ESB+Studio+v3.3安裝使用手冊》、《軟通動力蘭州ESB平臺項目詳細設計說明書》、《SOA實踐者指南》、《基於.NET+Framework+WCF的面向服務SOA中間件設計》、《基於WCF的SOA框架設計》、《IBM-ESB 在 SOA 內的工做角色》、《WSSF（服務工廠）架構剖析》、《開源SOA快速入門指南》、《Composite Software Construction》、《Enterprise Integration Patterns - Designing Building and Deploying Messaging Solutions》、《Enterprise SOA Adoption Strategies》、《Prentice.Hall.SOA.with.NET.and.Windows.Azure.May.2010》。

企業 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 整個系統內部的全部組件。