文章目錄
- 面向服務的一般原則---摘自《SOA概念、技術與設計》第八章
- 《WCF編程》——面向服務概述
- 架構原則
- 實用原則
SOA 新業務語言 新系統架構——SOA原則
面向服務的一般原則---摘自《SOA概念、技術與設計》第八章 在第3章中我們建立了不止一個SOA定義。也有不止一個掌控定義面向服務背後原則的標準體。同樣，對於面向服務的組成，也有許多源自公開的IT組織、廠商及諮詢機構觀點。據稱面向服務的根源在於軟體工程理論所謂的“關注點分離”。這一理論基於這樣的觀念：將一個大的問題分解為一系列單個關注點是有益的。這使得邏輯將需要解決的問題分解成更小的、相關片段的集合。每一段邏輯處理一個特定的關注點。這個理論已經被不同的開發平台以不同的方式實現。例如，物件導向的編程與基於組件的編程方法，通過使用對象、類和組件而實現了關注點分離。面向服務能夠被視作以截然不同的方式來實現關注點分離。面向服務原則提供了一個支援此理論的方法，同時實現了一種基本範式，在此基礎上可構建諸多當代SOA特徵。實際上，如果你再次研究這些特徵，將會注意到數個（直接或間接）與關注點分離理論有聯絡。如前所述，沒有官方的面向服務原則。然而，卻有一些最常與面向服務關聯的原則。現將這些原則羅列如下，本節將做進一步描述。
- 服務可複用不管是否存在即時複用的機會，服務被設計為支援潛在可複用。
- 服務共用一個正式契約為了與服務互動，只需要共用描述每個服務資訊交換術語定義的正式契約。
- 服務是鬆散耦合的服務被設計為無需緊密的、跨服務的依賴而互動。
- 服務是底層邏輯的抽象只有經由服務契約所暴露的部分服務對於外部世界是可見的。契約之外所表達的底層邏輯是不可見的，且與服務要求者無關。
- 服務是可組合的服務可能組合其他服務。這允許表示不同粒度的邏輯，並促進複用及抽象層的建立。
- 服務是自治的邏輯由服務所控制，並位於一個清晰的邊界內。服務已經在這個邊界內被控制，並且不依賴於執行其控制的其他服務。
- 服務是無狀態的服務應當不需要管理狀態資訊，因此能夠其維持松耦合性。服務應當儘可能設計成無狀態的，即便這意味著要將狀態管理移至別處。
- 服務是可發現的服務應當允許其描述被發現，並被人工和可能會利用其邏輯的服務要求者所理解。
在這八條原則中，自治性、鬆散耦合、抽象、以及需要正式契約被視為形成SOA根本基礎的核心原則。如同在本章後面
面向服務原則內部如何關聯一節所解釋，這四個原則直接支援其他原則（及其相互之間）的實現。《WCF編程》——面向服務概述架構原則面向服務方法學負責管理服務之間所發生的內容（參見圖A-1）。它有一套設計原則與最佳實務，用於構建面向服務應用程式，稱為面向服務架構原則：
服務邊界是明確的 任何服務總是被限制在邊界例如實現技術和分布位置之後。服務公開的契約與資料類型不會將它的實現技術與分布位置透露給用戶端，從而隱藏了這些邊界的本質。堅持這一原則可以使得服務與位置和技術無關。不管是以何種方式思考這一原則，它所表達的思想就是用戶端知道服務的實現越多，則用戶端與服務的耦合度就越高。要減小潛在的耦合度，服務就必須明確地公開它的功能，而且只有操作（或資料契約）才會被明確地被公開給用戶端共用。服務的其餘內容會被封裝起來。面向服務技術採用了預設為“否決（Opt-Out）”的編程模型，公開的內容則被明確標記為參與（Opt-In）[注]。 譯註：Opt-Out與Opt-In本身屬於發送廣告中的兩種不同行為與授權方式。在這裡，Opt-Out指的是如果服務的成員沒有明確地進行設定，則預設是不暴露的，即否決機制。Opt-In則指的是只有明確標記了需要暴露的成員，則該成員才會參與到服務中，能夠被跨越服務邊界調用。
服務是自治的 服務無需擷取它的用戶端或其它服務的內容。服務的運行與版本應該與用戶端無關。這一原則允許服務脫離用戶端單獨演化。服務的安全也是獨立的，它能夠保護服務自身以及傳遞的訊息，而不用考慮用戶端使用的安全層級。這樣做（除了盡人皆知的常識之外）同時也能夠解除用戶端與服務安全之間的耦合。
服務共用操作契約與資料樣式，而不是類型與特定技術的中繼資料。 服務要做的就是決定公開在服務邊界之外內容應與技術無關。服務能夠將本地的資料類型轉換為某種與技術無關的表示形式，而不是共用本地的、特定技術的內容，例如程式集版本號碼或者它的類型。此外，服務應該禁止用戶端知道本地的實現細節，例如執行個體管理員模式或並發管理員模式。服務只公開邏輯操作。服務對於操作的實現方式以及執行方式，對於用戶端而言是不透明的。
服務與策略保持一致 服務應該發布一種策略，指示它所能完成的內容以及用戶端與服務互動的方式。策略所體現的訪問約束（例如可靠通訊）不應依賴於服務的實現細節。並非所有的用戶端都能與所有的服務互動。這種不相容性是完全有效，它能夠防止特殊的用戶端訪問服務。發布的策略是用戶端決定它們能否與服務互動的唯一方法，同時不應有任何的帶外機制讓用戶端做出這樣的決策。不同的是，服務必須能夠在策略的標準表達形式中，表示服務能夠執行的內容以及用戶端能夠與之通訊的方式。如果無法表示，就意味著服務的設計是拙劣的。注意，如果服務是私人的（即不是公有服務），那麼實際上它可能不會發布任何策略。這一原則暗示如果服務需要，就應該能夠發布策略。
實用原則 前面列舉的原則是非常抽象的，對它們的支援主要體現在開發、調用以及設計服務的技術方面。因此，應用程式可能會不同程度地遵循這些原則，正如開發人員可以在C++中編寫非物件導向的代碼那樣。然而，精心設計的應用程式應該力圖堅持這些原則。因此，我又補充了一些更加實用的原則：
服務是安全的 服務與它的用戶端必須使用安全通訊。至少，從用戶端傳遞到服務的訊息必須是安全的，用戶端必須具有驗證服務的方法。同時，用戶端可能會在訊息中提供它們的安全性憑證，這樣服務才能夠對它們進行授權與認證。
服務在系統中應保持一致的狀態 執行用戶端請求時，禁止進行部分替換的條件。服務訪問的所有資源在用戶端調用之後必須是一致的。服務不能有任何剩餘內容作為錯誤的結果，例如部分地影響系統狀態。服務不應尋求它的用戶端的協助，在發生錯誤後，服務會將系統復原為一致的狀態。
服務是安全執行緒的 服務必須設計為安全執行緒，才能夠維持多線程的並發訪問。服務同樣能夠處理因果關係或邏輯線程的重入。
服務是可靠的 如果用戶端調用服務，用戶端總是能夠以確定的方式獲知訊息是否被服務接收。訊息應該按照發送的順序處理，而不是接收的順序。
服務是健壯的 服務與它的錯誤分離能夠防止錯誤影響服務本身或其它服務。服務不能要求用戶端根據服務遇到的錯誤類型改變它們的行為。這能夠有助於用戶端與錯誤處理層面上的服務解耦。
可選原則
我們可以將實用原則看作是強制原則，同時還有一套可選原則，這些原則並非所有應用程式所必需的，雖然堅持這些原則通常是一個不錯的主意： 服務是互操作的 設計的服務應該能夠被任意的用戶端調用，而不用考慮用戶端的技術。 服務的規模是不變的 不管用戶端有多少，也不管服務的承載是多少，服務代碼都應該相同。隨著系統的發展，這樣的設計才能夠極大地降低維護服務的成本，服務也能夠支援不同的部署情境。 服務是可用的 服務總是能夠接收用戶端的請求，而不會因此停止。如果服務不可用，則意味著用戶端需要解決服務的問題，反過來就會引入耦合。 服務是及時響應的 服務開始處理用戶端的請求時，不能讓用戶端等待太久。如果服務不能及時響應，則意味著用戶端需要解決服務的問題，反過來就會引入耦合。 服務是受限的
服務執行的任意操作應儘可能短，不能消耗太多時間去處理用戶端的請求。長時間的處理過程意味著用戶端需要解決服務的問題，反過來就會引入耦合。
