本篇主要是為后文做鋪墊，所以理論的東西相對而言比較的多一點！

　　服務層的概述

　　首先解釋一下什么是”服務Service”，從廣義來講：只要是你使用了別人的東西，那么你就在使用別人提供的服務。在這里，服務就是指可能被一個或者多個系統使用的核心的業務邏輯，我們可以把服務簡單的想象成為一些可供調用的API。

　　在之前的第四章中，我們講述了如何組織業務邏輯，第五章講述了在業務層的設計中可以采用的一些模式。但是還有一個問題需要大家考慮的是：如何把業務層提供給其他的層來調用？

　　可能認為這個問題有莫名奇妙—不是只要引用業務層的組件就行了嗎。但是仔細想想，卻不盡然：因為在很多系統中，我們不是直接把業務層的組件引用就可以了的，特別是在分布式的系統中，我們往往在服務端暴露一些服務接口，讓其他的子系統或者外部系統來調用提供的服務。

　　一般來說，服務層處于業務層和顯示層之間(當然服務層也可以處于系統和系統之間)。服務層往往提供了一些供外部調用的服務接口，這些接口往往是一些粗粒度，或者說提供了一些簡單易用，功能強大的接口，當客戶端調用這些接口服務之后，服務層那邊就開始處理比較復雜的一些業務邏輯，驗證規則，以及持久化數據等。

　　服務層內的邏輯的組織形式有點類似我們之前在第四章中講述的Transaction Script模式。

　　我們可以簡單的把服務層看成是一個中介：從客戶端接收請求，通過一系列的步驟之后，請求就到了服務層，服務層就開始協調和組織所需要的業務類，把請求的的具體處理交給那些業務類來做，最后把結果返回給客戶端。

　　在服務層的邏輯組織往往是比較過程化的，但是和Transaction Script有一點不同的是：Transaction Script的每一個方法處理一個比較細（比較具體的，小的）的業務流程和邏輯。但是服務層的一個接口的方法往往是處理一個比較大的流程（這個大的流程可能包含很多的小的流程）。

　　下面我們就來就從一個例子來看看SOA。

　　SOA架構講述

　　我們首先來看一個例子：

　　上面的圖就是一個電子網站的系統架構圖。可以看出，在這個系統中，又包含很多其他的小的子系統，而且每一個子系統都有自己的業務邏輯。同時每一個系統都連接搭配同一個數據庫，所有的子系統也都同時使用一個SMTP服務器。而且還有一些系統，如Order Management還需要鏈接第三方的WebService(PayPal).

　　這種錯綜復雜的系統架構存在一些問題：

　　1． 因為整個大的系統中存在很多的子系統，而且這些子系統都有自己的業務邏輯層，這樣就導致了相同的業務邏輯在很多的其他子系統中重復，維護起來很困難。而且相同的業務流程在一些子系統中重復出現。例如，在Customer Management中，需要查看一個客戶的所有的訂單，那么這個邏輯和Order Management中的一些邏輯重復。

　　2． 各個系統和底層的數據結構緊耦合。因為這些系統都是用的是同一個數據庫，有著各自的業務邏輯和數據訪問層，那么一旦要對數據庫做一點點的改動，那么就會牽連很多的子系統做相應的改變。

　　3． 審計跟蹤比較的麻煩。因為很多的子系統各自可以操作數據庫，所以記錄操作系統比較麻煩。

　　通過SOA可以解決上面提到的一些問題(當然，不僅僅只是上面提到的一些問題)：把所有的業務處理放在一起，進行統一管理和控制（而不是像上面的設計那樣—零散的到處分布），并把業務邏輯的通過服務的形式暴露會給外界，讓其他的子系統調用。

　　上面改良后的系統的好處如下：

　　1． 系統的業務邏輯等的維護變得容易，因為改變只是發生在一個地方。

　　2． 并且服務都是通過接口的形式暴露給外界的，那么這就為以后的擴展提供了可能。例如我們可以在接口不變的前提下，替換現有的一些業務流程處理方式。

　　3． 日志，審計跟蹤容易實現。

　　4． 對外界隱藏了數據層的實現。只要接口之前定義的數據的scheme，或者說數據契約不變，服務層可以任意替換數據存儲設備和方式。

　　5． 各個系統與服務層的交互是基于粗粒度的接口，避免了系統直接和數據庫頻繁的交互，減小了通信的成本，也減輕了數據庫的壓力。

　　SOA的基本原則

　　上面的一些原則可能有點抽象，在文章的后面一個例子中會設計一個小的項目，會對這些原則多一些講解。

　　今天就講述到這里吧，沒有什么很新的東西，都是為了給后文做準備的，下一篇主要講述在SOA常常使用的設計模式和架構模式。