软件架构风格介绍
架構風格是一組原則。你可以把它看成是一組為系統家族提供抽象框架的粗粒度模式。架構風格能改進分塊，還能為頻繁出現的問題提供解決方案，以此促進設計重用。
常見的軟件體系結構風格涉及：
- 設計詞匯表是什么？或者構件和連接器的類型是什么？
- 可容許的結構模式是什么？
- 基本的計算模型是什么？
- 風格的基本不變性是什么？
- 其使用的常見例子是什么？
- 使用此風格的優缺點是什么？
- 其常見特例是什么？
軟件體系結構設計的一個中心問題是能否重用軟件體系結構模式，或者采用某種軟件體系結構風格。有原則地使用軟件體系結構風格具有如下意義：
- 它促進了設計的復用，使得一些經過實踐證實的解決方案能夠可靠地解決新問題。
- 它能夠帶來顯著的代碼復用，使得體系結構風格中的不變部分可共享同一個解決方案。
- 便于設計者之間的交流與理解。
- 通過對標準風格的使用支持了互操作性，以便于相關工具的集成。
- 在限定了設計空間的情況下，能夠對相關風格作出分析。
- 能夠對特定的風格提供可視化支持。
與此同時，人們目前尚不能準確回答的問題是：
- 系統設計的哪個要點可以用風格來描述；
- 能否用系統的特性來比較不同的風格，如何確定用不同的風格設計系統之間的互操作；
- 能否開發出通用的工具來擴展風格；
- 如何為一個給定的問題選擇恰當的體系結構風格，或者如何通過組合現有的若干風格來產生一個新的風格。
M.Shaw等人根據此框架給出了管道與過濾器、數據抽象和面向對象組織、基于事件的隱式調用、分層系統、倉庫系統及知識庫和表格驅動的解釋器等一些常見的軟件體系結構風格。
?
架構風格
客戶端-服務器
將系統分為兩個應用，其中客戶端向服務器發送服務請求。
基于組件的架構
把應用設計分解為可重用的功能、邏輯組件，這些組件的位置相互透明，只暴露明確定義的通信接口。
分層架構
把應用的關注點分割為堆棧組（層）。
消息總線
指接收、發送消息的軟件系統，消息基于一組已知格式，以便系統無需知道實際接收者就能互相通信。
N層/三層架構
用與分層風格差不多一樣的方式將功能劃分為獨立的部分，每個部分是一個層，處于完全獨立的計算機上。
面向對象
該架構風格是將應用或系統任務分割成單獨、可重用、可自給的對象，每個對象包含數據，以及與對象相關的行為。
分離表現層
將處理用戶界面的邏輯從用戶界面（UI）視圖和用戶操作的數據中分離出來。
面向服務架構（SOA）
是指那些利用契約和消息將功能暴露為服務、消費功能服務的應用。
這些架構風格分別適用于特定領域：
通信
SOA，消息總線，管道和過濾器
部署
客戶端/服務器，三層架構，N層架構
領域
領域模型，網關
交互
分離表現層
結構
基于組件的架構，面向對象，分層架構
?
下面介紹幾種常見的架構風格：
管道和過濾器風格
在管道/過濾器風格的軟件體系結構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然后產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這里的構件被稱為過濾器，這種風格的連接件就像是數據流傳輸的管道，將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的 過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性并不依賴于過濾器進 行增量計算過程的順序。
圖2-1是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程序。Unix既提供一種符號，以連接各組成部分(Unix的進程)，又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編 譯器。傳統的編譯器一直被認為是一種管道系統，在該系統中，一個階段(包括詞法分析、語法分析、語義分析和代碼生成)的輸出是另一個階段的輸入。
圖 2?1管道/過濾器風格的體系結構
管道/過濾器風格的軟件體系結構具有許多很好的特點：
(1)使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；
(2)允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；
(3)支持軟件重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；
(4)系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；
(5)允許對一些如吞吐量、死鎖等屬性的分析；
(6)支持并行執行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務并行執行。
但是，這樣的系統也存在著若干不利因素。
(1)通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。
(2)不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。
(3)因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，并增加了編寫過濾器的復雜性
?
數據抽象與面向對象風格
抽象數據類型概念對軟件系統有著重要作用，目前軟件界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和面向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因為它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
圖2-2是數據抽象和面向對象風格的示意圖。
圖 2?2數據抽象和面向對象風格的體系結構
面向對象的系統有許多的優點，并早已為人所知：
(1) 因為對象對其它對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其它的對象。
(2) 設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
但是，面向對象的系統也存在著某些問題：
(1)為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象。
(2)必須修改所有顯式調用它的其它對象，并消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的。
?
基于事件的隱式調用風格
基于事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
從體系結構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中注冊一些過程，當發生這些事件時，過程被調用。
基于事件的隱式調用風格的主要特點是事件的觸發者并不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統也包含顯式調用作為構件交互的補充形式。
支持基于事件的隱式調用的應用系統很多。例如，在編程環境中用于集成各種工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系 統中，編輯器和變量監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程 序可以卷屏到斷點，變量監視器刷新變量數值。而Debugger本身只聲明事件，并不關心哪些過程會啟動，也不關心這些過程做什么處理。
隱式調用系統的主要優點有：
(1)為軟件重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它注冊到系統的事件中。
(2)為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其它構件的接口。
隱式調用系統的主要缺點有：
(1)構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件注冊了哪些構件的構成，它也不能保證這些過程被調用的順序。
(2)數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基于事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
(3)既然過程的語義必須依賴于被觸發事件的上下文約束，關于正確性的推理存在問題。
?
層次系統風格
層次系統組織成一個層次結構，每一層為上層服務，并作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機(在另一些層次系統中層是部分不透明的)。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
這種風格支持基于可增加抽象層的設計。這樣，允許將一個復雜問題分解成一個增量步驟序列的實現。由于每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件重用提供了強大的支持。
圖2-3是層次系統風格的示意圖。層次系統最廣泛的應用是分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作為上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。
圖 2?3層次系統風格的體系結構
層次系統有許多可取的屬性：
(1)支持基于抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解；
(2)支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；
(3)支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現方法。
但是，層次系統也有其不足之處：
(1)并不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出于對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；
(2)很難找到一個合適的、正確的層次抽象方法。
?
倉庫風格
在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互作用在系統中會有大的變化。
控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
圖2-4是黑板系統的組成。黑板系統的傳統應用是信號處理領域，如語音和模式識別。另一應用是松耦合代理數據共享存取。
圖 2?4黑板系統的組成
我們從圖2-4中可以看出，黑板系統主要由三部分組成：
(1)知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只通過黑板來完成。
(2)黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。
(3)控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
?
C2風格
C2體系結構風格可以概括為：通過連接件綁定在一起的按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下：
(1)系統中的構件和連接件都有一個頂部和一個底部；
(2)構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；
(3)一個連接件可以和任意數目的其它構件和連接件連接；
(4)當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
圖2-5是C2風格的示意圖。圖中構件與連接件之間的連接體現了C2風格中構建系統的規則。
圖 2?5 C2風格的體系結構
C2風格是最常用的一種軟件體系結構風格。從C2風格的組織規則和結構圖中，我們可以得出，C2風格具有以下特點：
(1)系統中的構件可實現應用需求，并能將任意復雜度的功能封裝在一起；
(2)所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的；
(3)構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
?
二層C/S我們不再介紹了，直接說三層C/S
三層C/S的基本硬件結構
傳統的二層C/S結構存在以下幾個局限：
l 它是單一服務器且以局域網為中心的，所以難以擴展至大型企業廣域網或Internet；
l 受限于供應商；
l 軟、硬件的組合及集成能力有限；
l 難以管理大量的客戶機。
因此，三層C/S結構應運而生。三層C/S結構是將應用功能分成表示層、功能層和數據層三部分。其解決方案是：對這三層進行明確分割，并在邏輯上使其獨立。原來的數據層作為DBMS已經獨立出來，所以關鍵是要將表示層和功能層分離成各自獨立的程序，并且還要使這兩層間的接口簡潔明了。
將上述三層功能裝載到硬件的方法基本上有三種(如圖所示)。其中表示層配置在客戶機中，而數據層配置在服務器中。
一般情況是只將表示層配置在客戶機中，與二層C/S結構相比，其程序的可維護性要好得多，是其他問題并未得到解決。客戶機的負荷太重，其業務處理所需的數據要從服務器傳給客戶機，所以系統的性能容易變壞。
如果將功能層和數據層分別放在不同的服務器中，則服務器和服務器之間也要進行數據傳送。但是，由于在這種形態中三層是分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此，系統規模越大這種形態的優點就越顯著。
值得注意的是：三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，其作為整體來說也達不到所要求的性能。此外，設計時必須慎重考慮三層間的通信方法、通信頻度及數據量。這和提高各層的獨立性一樣是三層C/S結構的關鍵問題。
三層C/S的功能
1.表示層
表示層是應用的用戶接口部分，它擔負著用戶與應用間的對話功能。它用于檢查用戶從鍵盤等輸入的數據，顯示應用輸出的數據。為使用戶能直觀地進行操作，一 般要使用圖形用戶接口(GUI)，操作簡單、易學易用。在變更用戶接口時，只需改寫顯示控制和數據檢查程序，而不影響其他兩層。檢查的內容也只限于數據的 形式和值的范圍，不包括有關業務本身的處理邏輯。
圖形界面的結構是不固定的，這便于以后能靈活地進行變更。例如，在一個窗口中不是放入幾個功能，而是按功能分割窗口，以便使每個窗口的功能簡潔單純。在這層的程序開發中主要是使用可視化編程工具。
2. 功能層
功能層相當于應用的本體，它是將具體的業務處理邏輯地編入程序中。例如，在制作訂購合同的時要計算合同金額，按照定好的格式配置數據、打印訂購合同，而 處理所需的數據則要從表示層或數據層取得。表示層和功能層之間的數據交往要盡可能簡潔。例如，用戶檢索數據時，要設法將有關檢索要求的信息一次傳送給功能 層(參見圖2)，而由功能層處理過的檢索結果數據也一次傳送給表示層。在應用設計中，一定要避免進行一次業務處理，在表示層和功能層間進行多幾次數據交換 的笨拙設計。
通常，在功能層中包含有：確認用戶對應用和數據庫存取權限的功能以及記錄系統處理日志的功能。這層的程序多半是用可視化編程工具開發的，也有使用COBOL和C語言的。
3. 數據層
數據層就是DBMS，負責管理對數據庫數據的讀寫。DBMS必須能迅速執行大量數據的更新和檢索?，F在的主流是關系數據庫管理系統(RDBMS)。因此，一般從功能層傳送到數據層的要求大都使用SQL語言。
三層C/S結構的優點
1。 具有靈活的硬件系統構成
對于各個層可以選擇與其處理負荷和處理特性相適應的硬件。這是一個與系統可縮放性直接相關的問題。例如，最初用一臺Unix工作站作為服務器，將數據層 和功能層都配置在這臺服務器上。隨著業務的發展，用戶數和數據量逐漸增加，這時就可以將Unix工作站作為功能層的專用服務器，另外追加一臺專用于數據層 的服務器。若業務進一步擴大，用戶數進一步增加，則可以繼續增加功能層的服務器數目，用以分割數據庫。清晰、合理地分割三層結構并使其獨立，可以使系統構 成的變更非常簡單。因此，被分成三層的應用基本上不需要修正。
2。 提高程序的可維護性
三層C/S結構中，應用的各層可以并行開發，各層也可以選擇各自最適合的開發語言。
3。 利于變更和維護應用技術規范
因為是按層分割功能，所以各個程序的處理邏輯變得十分簡單。
4。 進行嚴密的安全管理
越關鍵的應用，用戶的識別和存取權限設定愈重要。在三層C/S結構中，識別用戶的機構是按層來構筑的，對應用和數據的存取權限也可以按層進行設定。例如，即使外部的入侵者突破了表示層的安全防線，若在功能層中備有另外的安全機構，系統也可以阻止入侵者進入其他部分。
此外，系統管理簡單，可支持異種數據庫，有很高的可用性。
?
C/S和B/S 的優缺點比較
C/S和B/S是當今世界開發模式技術架構的兩大主流技術。C/S是美國 Borland公司最早研發，B/S是美國微軟公司研發。目前，這兩項技術以被世界各國所掌握，國內公司以C/S和B/S技術開發出產品也很多。這兩種技術都有自己一定的市場份額和客戶群，各家企業都說自己的管理軟件架構技術功能強大、先進、方便，都能舉出各自的客戶群體，都有一大群文人墨客為自己搖旗吶 喊，廣告滿天飛，可謂仁者見仁，智者見智。
1、C/S架構軟件的優勢與劣勢
（1）、應用服務器運行數據負荷較輕。
最簡單的C/S體系結構的數據庫應用由兩部分組成，即客戶應用程序和數據庫服務器程序。二者可分別稱為前臺程序與后臺程序。運行數據庫服務器程序 的機器，也稱為應用服務器。一旦服務器程序被啟動，就隨時等待響應客戶程序發來的請求；客戶應用程序運行在用戶自己的電腦上，對應于數據庫服務器，可稱為 客戶電腦，當需要對數據庫中的數據進行任何操作時，客戶程序就自動地尋找服務器程序，并向其發出請求，服務器程序根據預定的規則應答，送回結果，應用 服務器運行數據負荷較輕。
（2）、數據的儲存管理功能較為透明。
在數據庫應用中，數據的儲存管理功能，是由服務器程序和客戶應用程序分別獨立進行的，前臺應用可以違反的規則，并且通常把那些不同的（不管是已知 還是未知的）運行數據，在服務器程序中不集中實現，例如訪問者的權限，編號可以重復、必須有客戶才能建立定單這樣的規則。所有這些，對于工作在前臺程序上 的最終用戶，是“透明”的，他們無須過問（通常也無法干涉）背后的過程，就可以完成自己的一切工作。在客戶服務器架構的應用中，前臺程序不是非常“瘦小 ”，麻煩的事情都交給了服務器和網絡。在C/S體系的下，數據庫不能真正成為公共、專業化的倉庫，它受到獨立的專門管理。
（3）、C/S架構的劣勢是高昂的維護成本且投資大。
首先，采用C/S架構，要選擇適當的數據庫平臺來實現數據庫數據的真正“統一”，使分布于兩地的數據同步完全交由數據庫系統去管理，但邏輯上兩地 的操作者要直接訪問同一個數據庫才能有效實現，有這樣一些問題，如果需要建立“實時”的數據同步，就必須在兩地間建立實時的通訊連接，保持兩地的數據庫服 務器在線運行，網絡管理工作人員既要對服務器維護管理，又要對客戶端維護和管理，這需要高昂的投資和復雜的技術支持，維護成本很高，維護任務量大。
其次，傳統的C/S結構的軟件需要針對不同的操作系統系統開發不同版本的軟件，由于產品的更新換代十分快，代價高和低效率已經不適應工作需要。在JAVA這樣的跨平臺語言出現之后，B/S架構更是猛烈沖擊C/S，并對其形成威脅和挑戰。
2、B/S架構軟件的優勢與劣勢
（1）、維護和升級方式簡單。
目前，軟件系統的改進和升級越來越頻繁，B/S架構的產品明顯體現著更為方便的特性。對一個稍微大一點單位來說，系統管理人員如果需要在幾百甚至 上千部電腦之間來回奔跑，效率和工作量是可想而知的，但B/S架構的軟件只需要管理服務器就行了，所有的客戶端只是瀏覽器，根本不需要做任何的維護。無論 用戶的規模有多大，有多少分支機構都不會增加任何維護升級的工作量，所有的操作只需要針對服務器進行；如果是異地，只需要把服務器連接專網即可，實現遠程 維護、升級和共享。所以客戶機越來越“瘦”，而服務器越來越“胖”是將來信息化發展的主流方向。今后，軟件升級和維護會越來越容易，而使用起來會越來越簡單，這對用戶人力、物力、時間、費用的節省是顯而易見的，驚人的。因此，維護和升級革命的方式是“瘦”客戶機，“胖”服務器。
（2）、成本降低，選擇更多。
大家都知道windows在桌面電腦上幾乎一統天下，瀏覽器成為了標準配置，但在服務器操作系統上windows并不是處于絕對的統治地位?，F在 的趨勢是凡使用B/S架構的應用管理軟件，只需安裝在Linux服務器上即可，而且安全性高。所以服務器操作系統的選擇是很多的，不管選用那種操作系統都 可以讓大部分人使用windows作為桌面操作系統電腦不受影響，這就使的最流行免費的Linux操作系統快速發展起來，Linux除了操作系統是免費的 以外，連數據庫也是免費的，這種選擇非常盛行。
（3）、應用服務器運行數據負荷較重。
由于B/S架構管理軟件只安裝在服務器端（Server）上，網絡管理人員只需要管理服務器就行了，用戶界面主要事務邏輯在服務器 （Server）端完全通過WWW瀏覽器實現，極少部分事務邏輯在前端（Browser）實現，所有的客戶端只有瀏覽器，網絡管理人員只需要做硬件維護。 但是，應用服務器運行數據負荷較重，一旦發生服務器“崩潰”等問題，后果不堪設想。因此，許多單位都備有數據庫存儲服務器，以防萬一。
?
C/S 與 B/S 區別
????? Client/Server是建立在局域網的基礎上的，Browser/Server是建立在廣域網的基礎上的。
（1）硬件環境不同：
????? C/S 一般建立在專用的網絡上， 小范圍里的網絡環境， 局域網之間再通過專門服務器提供連接和數據交換服務。
B/S 建立在廣域網之上的， 不必是專門的網絡硬件環境，例如電話上網， 租用設備， 信息自己管理， 有比C/S更強的適應范圍， 一般只要有操作系統和瀏覽器就行。
（2）、對安全要求不同
????? C/S 一般面向相對固定的用戶群， 對信息安全的控制能力很強。 一般高度機密的信息系統采用C/S 結構適宜，可以通過B/S發布部分可公開信息。
B/S 建立在廣域網之上， 對安全的控制能力相對弱， 面向是不可知的用戶群。
（3）、對程序架構不同
????? C/S 程序可以更加注重流程，可以對權限多層次校驗，對系統運行速度可以較少考慮。
B/S 對安全以及訪問速度的多重的考慮， 建立在需要更加優化的基礎之上。 比C/S有更高的要求，B/S結構的程序架構是發展的趨勢，從MS的。Net系列的BizTalk 2000 Exchange 2000等，全面支持網絡的構件搭建的系統。SUN和IBM推的JavaBean構件技術等，使B/S更加成熟。
（4）、軟件重用不同
????? C/S 程序可以不可避免的整體性考慮， 構件的重用性不如在B/S要求下的構件的重用性好。
????? B/S 對的多重結構，要求構件相對獨立的功能。 能夠相對較好的重用。就如買來的餐桌可以再利用，而不是做在墻上的石頭桌子。
（5）、系統維護不同
系統維護是軟件生存周期中，開銷大，相當重要。C/S 程序由于整體性，必須整體考察，處理出現的問題以及系統升級難， 可能是再做一個全新的系統。 B/S 構件組成方面構件個別的更換，實現系統的無縫升級。系統維護開銷減到最小，用戶從網上自己下載安裝就可以實現升級。
（6）、處理問題不同
????? C/S 程序可以處理用戶面固定，并且在相同區域， 安全要求高的需求，與操作系統相關， 應該都是相同的系統。 B/S 建立在廣域網上， 面向不同的用戶群，分散地域， 這是C/S無法作到的，與操作系統平臺關系最小。
（7）、用戶接口不同
????? C/S 多是建立在Window平臺上，表現方法有限，對程序員普遍要求較高。 B/S 建立在瀏覽器上， 有更加豐富和生動的表現方式與用戶交流， 并且大部分難度減低，降低開發成本。
（8）、信息流不同
????? C/S 程序一般是典型的中央集權的機械式處理，交互性相對低。 B/S 信息流向可變化， B－B、 B－C、 B－G等信息流向的變化， 更像交易中心。
?
基于層次消息總線的架構風格
JB/HMB風格的基本特征
目前對軟件體系結構的研究集中在以下方面：各種體系結構風格的匯編和總結、體系結
構描述語言(architectural description languages，簡稱ADLS)、體系結構的形式化基礎、體系結構分析技術、基于體系結構的軟件開發、體系結構恢復和再工程、支持體系結構設計的工具和環境及特定領域的軟件體系結構等。 青鳥工程在“九五”期間，對基于構件構架模式的軟件工業化生產技術進行了研究，并實現了青鳥軟件生產線系統151。以青鳥軟件生產線的實踐為背景，提出了基于層次消息總線的軟件體系結構(Jade bird hierarchical message bus based style，以下簡稱JB/HMB風格)，設計了相應的體系結構描述語言，開發了支持軟件體系結構設計的輔助工具集，并研究了采用JB/HMB風格進行應用系統開發的過程框架。
JB/HMB風格的提出基于以下的實際背景：
(1) 隨著計算機網絡技術的發展，特別是分布式構件技術的日漸成熟和構件互操作標準的出現，如CORBA，DCOM和EJB等，加速了基于分布式構件的軟件開發趨勢，具有分布和并發特點的軟件系統已成為一種普遍的應用需求。
(2) 基于事件驅動的編程模式已在圖形用戶界面程序設計中獲得廣泛應用。在此之前的
程序設計中，通常使用一個大的分支語句(switch Statement)控制程序的轉移，對不同的輸人情況分別進行處理，程序結構不甚清晰?；谑录寗拥木幊棠Ｊ皆趯Χ鄠€不同事件響應的情況下，系統自動調用相應的處理函數，程序具有清晰的結構。
(3) 計算機硬件體系結構和總線的概念為軟件體系結構的研究提供了很好的借鑒和啟發，
在統一的體系結構框架下(即總線和接口規范)，系統具有良好的擴展性和適應性。任何計算機廠商生產的配件，甚至是在設計體系結構時根本沒有預料到的配件，只要遵循標準的接口規范，都可以方便地集成到系統中，對系統功能進行擴充，甚至是即插即用(即運行時刻的系統演化)。正是標準的總線和接口規范的制定，以及標準化配件的生產，促進了計算機硬件的產業分工和蓬勃發展。
JB/HMB風格基于層次消息總線、支持構件的分布和并發，構件之間通過消息總線進行通訊，如圖所示。消息總線是系統的連接件，負責消息的分派、傳遞和過濾以及處理結果的返回。各個構件掛接在消息總線上，向總線登記感興趣的消息類型。構件根據需要發出消息，由消息總線負責把該消息分派到系統中所有對此消息感興趣的構件，消息是構件之間通訊的唯一方式，構件接收到消息后，根據自身狀態對消息進行響應，并通過總線返回處理結果。由于構件通過總線進行連接，并不要求各個構件具有相同的地址空間或局限在一臺機器上。該風格可以較好地刻畫分布式并發系統，以及基于CORBA，DCOM和EJB規范的系統。
如圖所示，系統中的復雜構件可以分解為比較低層的子構件，這些子構件通過局部消息
總線進行連接，這種復雜的構件稱為復合構件。如果子構件仍然比較復雜，可以進一步分解。
如此分解下去，整個系統形成了樹狀的拓撲結構，樹結構的末端結點稱為葉結點，它們是系統中的原子構件，不再包含子構件，原子構件的內部可以采用不同于JB/HMB的風格，例如數據流風格、面向對象風格及管道/過濾器風格等，這些屬于構件的內部實現細節。但要集成到JB/HMB風格的系統中，必須滿足JB/HMB風格的構件模型的要求，主要是在接口規約方面的要求。另外，整個系統也可以作為一個構件，通過更高層的消息總線，集成更大的系統中。于是，可以采用統一的方式刻畫整個系統和組成系統的單個構件。
構建模型
系統和組成系統的成分通常是比較復雜的，難以從一個視角獲得對它們的完整理解，因
此一個好的軟件工程方法往往從多個視角對系統進行建模，一般包括系統的靜態結構、動態行為和功能等方面。例如，在Rumbaugh等人提出的OMT(object modeling technology)方法中，
采用了對象模型、動態模型和功能模型刻畫系統的以上3個方面。
借鑒上述思想，為滿足體系結構設計的需要，JB/HMB風格的構件模型包括了接口、靜態結構和動態行為3個部分，如圖所示。
在圖中所示的構件模型中，左上方是構件的接口部分，一個構件可以支持多個不同的接口，每個接口定義了一組輸入和輸出的消息，刻畫了構件對外提供的服務以及要求的環境服務，體現了該構件同環境的交互.右上方是用帶輸出的有限狀態自動機刻畫的構件行為，構件接收到外來消息后，根據當前所處的狀態對消息進行響應，并可能導致狀態的變遷.下方是復合構件的內部結構定義，復合構件是由更簡單的子構件通過局部消息總線連接而成的.消息總線為整個系統和各個層次的構件提供了統一的集成機制。
構件接口
在體系結構設計層次上，構件通過接口定義了同外界的信息傳遞和承擔的系統責任，構件接口代表了構件同環境的全部交互內容，也是唯一的交互途徑.除此之外，環境不應對構件做任何其他與接口無關的假設，例如實現細節等。JB/HMB風格的構件接口是一種基于消息的互聯接口，可以較好地支持體系結構設計。
構件之間通過消息進行通訊，接口定義了構件發出和接收的消息集合.同一般的互聯接口相比.JB/HMB的構件接口具有兩個顯著的特點.首先，構件只對消息本身感興趣，并不關心消息是如何產生的，消息的發出者和接收者不必知道彼此的情況，這樣就切斷了構件之間的直接聯系，降低了構件之間的藕合強度，進一步增強了構件的復用潛力，并使得構件的替換變得更為容易。另外，在一般的互聯接口定義的系統中，構件之間的連接是在要求的服務和提供的服務之間進行固定的匹配，而在JB/HMB的構件接口定義的系統中，構件對外來消息的響應，不但同接收到的消息類型相關，而且同構件當前所處的狀態相關.構件對外來消息進行響應后，可能會引起狀態的變遷.因此，一個構件在接收到同樣的消息后，在不同時刻所處的不同狀態下，可能會有不同的響應。
消息是關于某個事件發生的信息，上述接口定義中的消息分為兩類:(i)構件發出的消息，通知系統中其他構件某個事件的發生或請求其他構件的服務；(ii)構件接收的消息，對系統中某個事件的響應或提供其他構件所需的服務.接口中的每個消息定義了構件的一個端口，具有互補端口的構件可以通過消息總線進行通訊，互補端口指的是除了消息進出構件的方向不同之外，消息名稱、消息帶有的參數和返回結果的類型完全相同的兩個消息. 當某個事件發生后，系統或構件發出相應的消息，消息總線負責把該消息傳遞到對此消息感興趣的構件.按照響應方式的不同，消息可分為同步消息和異步消息.同步消息是指消息的發送者必須等待消息處理結果返回才可以繼續運行的消息類型.異步消息是指消息的發送者不必等待消息處理結果的返回即可繼續執行的消息類型.常見的同步消息包括(一般的)過程調用。
?
消息總線
JB/HMB風格的消息總線是系統的連接件，構件向消息總線登記感興趣的消息，形成構件-消息響應登記表.消息總線根據接收到的消息類型和構件一消息響應登記表的信息，定位并傳遞該消息給相應的響應者，并負責返回處理結果.必要時，消息總線還對特定的消息進行過濾和阻塞.下圖給出了采用對象類符號表示的消息總線的結構。
運行時的演化
在許多重要的應用領域中，例如金融、電力、電信及空中交通管制等，系統的持續可用性是一個關鍵性的要求，運行時刻的系統演化可減少因關機和重新啟動而帶來的損失和風險。此外，越來越多的其他類型的應用軟件也提出了運行時刻演化的要求，在不必對應用軟件進行重新編譯和加載的前提下，為最終用戶提供系統定制和擴展的能力。JBI/HMB風格方便地支持運行時刻的系統演化，主要體現在以下3個方面：
(1) 動態增加或刪除構件。在JB/HMB風格的系統中，構件接口中定義的輸人和輸出消息刻畫了一個構件承擔的系統責任和對外部環境的要求，構件之間通過消息總線進行通訊，彼此并不知道對方的存在。因此只要保持接口不變，構件就可以方便地替換。一個構件加人到系統中的方法很簡單，只需向系統登記其所感興趣的消息即可。但刪除一個構件可能會引起系統中對于某些消息沒有構件響應的異常情況，這時可以采取兩種措施：一是阻塞那些沒有構件響應的消息，二是首先使系統中的其他構件或增加新的構件對該消息進行響應，然后再刪除相應的構件。系統中可能增刪改構件的情況包括：當系統功能需要擴充時，往系統中增加新的構件。當對系統功能進行裁剪，或當系統中的某個構件出現問題時，需要刪除系統中的某個構件。用帶有增強功能或修正了錯誤的構件新版本代替原有的舊版本。
(2) 動態改變構件響應的消息類型。類似地，構件可以動態地改變對外提供的服務(即接收的消息類型)，這時應通過消息總線對發生的改變進行重新登記。
(3) 消息過濾。利用消息過濾機制，可以解決某些構件集成的不匹配問題，詳見“消息過濾”一節。消息過濾通過阻塞構件對某些消息的響應，提供了另一種動態改變構件對消息進行響應的方式。
JB/HMB風格的優點
以上討論了JB/HMB風格的各組成要素，下面對JB/HMB風格的主要特點作總結。
(1) 從接口、結構和行為方面對構件進行刻畫。在JB/HMB風格中，構件的描述包括接口、靜態結構和動態行為3個方面。接口：構件可以提供一個或多個接口，每個接口定義了一組發送和接收的消息集合，刻畫了構件對外提供的服務以及要求的環境服務，接口之間可以通過繼承表達相似性。
靜態結構：復合構件是由子構件通過局部消息總線連接而成的，形成該復合構件的內部結構。
動態行為：構件行為通過帶輸出的有限狀態機刻畫，構件接收到外來消息后，不但根
據消息類型，而且根據構件當前所處的狀態對消息進行響應，并導致狀態的變遷。
基于層次消息總線：消息總線是系統的連接件，負責消息的傳遞、過濾和分派，以及
處理結果的返回。各個構件掛接在總線上，向系統登記感興趣的消息。構件根據需要發出消息，由消息總線負責把該消息分派到系統中對此消息感興趣的所有構件。構件接收到消息后，根據自身狀態對消息進行響應，并通過總線返回處理結果。由于構件通過總線進行連接，并不要求各個構件具有相同的地址空間或局限在一臺機器上，系統具有并發和分布的特點。系統和復合構件可以逐層分解，子構件通過(局部)消息總線相連。每條消息總線分別屬于系統和各層次的復合構件，我們把這種特征的總線稱為層次消息總線。在系統開發方面，由于各層次的總線局部在相應的復合構件中，因此可以更好地支持系統的構造性和演化性。
統一描述系統和組成系統的構件：組成系統的構件通過消息總線進行連接，復雜構
件又可以分解為比較簡單的子構件，通過局部消息總線進行連接，如果子構件仍然比較復雜，
可以進一步分解。系統呈現出樹狀的拓撲結構。另外，整個系統也可以作為一個構件，集成到更大的系統中。于是，就可以對整個系統和組成系統的各層構件采用統一的方式進行描述。
支持運行時刻的系統演化：系統的持續可用性是許多重要的應用系統的一個關鍵性
要求，運行時刻的系統演化可減少因關機和重新啟動而帶來的損失和風險。JB/HMB風格方便地支持運行時刻的系統演化，主要包括動態增加或刪除構件、動態改變構件響應的消息類型和消息過濾。
REST架構風格
首先，REST是Web自身的架構風格。REST也是Web之所以取得成功的技術架構方面因素的總結。REST是世界上最成功的分布式應用架構風格（成功案例：Web，還不夠嗎？）。它是為運行在互聯網環境 的 分布式 超媒體系統量身定制的?；ヂ摼W環境與企業內網環境有非常大的差別，最主要的差別是兩個方面：
- 可伸縮性需求無法控制：并發訪問量可能會暴漲，也可能會暴跌。
- 安全性需求無法控制：無法控制客戶端發來的請求的格式，很可能會是惡意的請求。
而所謂的“超媒體系統”，即，使用了超文本的系統?？梢园选俺襟w”理解為超文本+媒體內容。
REST是HTTP/1.1協議等Web規范的設計指導原則，HTTP/1.1協議正是為實現REST風格的架構而設計的。新的Web規范，其設計必須符合REST的要求，否則整個Web的體系架構會因為引入嚴重矛盾而崩潰。這句話不是危言聳聽，做個類比，假如蘇州市政府同意在市區著名園林的附近大型土木，建造大量具有后現代風格的摩天大樓，那么不久之后世界聞名的蘇州園林美景將不復存在。
上述這些關于“REST是什么”的描述，可以總結為一句話：REST是所有Web應用都應該遵守的架構設計指導原則。當然，REST并不是法律，違反了REST的指導原則，仍然能夠實現應用的功能。但是違反了REST的指導原則，會付出很多代價，特別是對于大流量的網站而言。
要深入理解REST，需要理解REST的五個關鍵詞：
什么是資源？
資源是一種看待服務器的方式，即，將服務器看作是由很多離散的資源組成。每個資源是服務器上一個可命名的抽象概念。因為資源是一個抽象的概念，所以它不僅僅能代表服務器文件系統中的一個文件、數據庫中的一張表等等具體的東西，可以將資源設計的要多抽象有多抽象，只要想象力允許而且客戶端應用開發者能夠理解。與面向對象設計類似，資源是以名詞為核心來組織的，首先關注的是名詞。一個資源可以由一個或多個URI來標識。URI既是資源的名稱，也是資源在Web上的地址。對某個資源感興趣的客戶端應用，可以通過資源的URI與其進行交互。
什么是資源的表述？
資源的表述是一段對于資源在某個特定時刻的狀態的描述?？梢栽诳蛻舳?服務器端之間轉移（交換）。資源的表述可以有多種格式，例如HTML/XML/JSON/純文本/圖片/視頻/音頻等等。資源的表述格式可以通過協商機制來確定。請求-響應方向的表述通常使用不同的格式。
什么是狀態轉移？
狀態轉移（state transfer）與狀態機中的狀態遷移（state transition）的含義是不同的。狀態轉移說的是：在客戶端和服務器端之間轉移（transfer）代表資源狀態的表述。通過轉移和操作資源的表述，來間接實現操作資源的目的。
什么是統一接口？
REST要求，必須通過統一的接口來對資源執行各種操作。對于每個資源只能執行一組有限的操作。以HTTP/1.1協議為例，HTTP/1.1協議定義了一個操作資源的統一接口，主要包括以下內容：
- 7個HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
- HTTP頭信息（可自定義）
- HTTP響應狀態代碼（可自定義）
- 一套標準的內容協商機制
- 一套標準的緩存機制
- 一套標準的客戶端身份認證機制
REST還要求，對于資源執行的操作，其操作語義必須由HTTP消息體之前的部分完全表達，不能將操作語義封裝在HTTP消息體內部。這樣做是為了提高交互的可見性，以便于通信鏈的中間組件實現緩存、安全審計等等功能。
什么是超文本驅動？
“超文本驅動”又名“將超媒體作為應用狀態的引擎”（Hypermedia As The Engine Of Application State，來自Fielding博士論文中的一句話，縮寫為HATEOAS）。將Web應用看作是一個由很多狀態（應用狀態）組成的有限狀態機。資源之間通過超鏈接相互關聯，超鏈接既代表資源之間的關系，也代表可執行的狀態遷移。在超媒體之中不僅僅包含數據，還包含了狀態遷移的語義。以超媒體作為引擎，驅動Web應用的狀態遷移。通過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時通過解析超媒體發現的，而不是事先定義的。從面向服務的角度看，超媒體定義了服務器所提供服務的協議?？蛻舳藨撘蕾嚨氖浅襟w的狀態遷移語義，而不應該對于是否存在某個URI或URI的某種特殊構造方式作出假設。一切都有可能變化，只有超媒體的狀態遷移語義能夠長期保持穩定。
?
理解REST風格的架構所具有的6個的主要特征：
- 面向資源（Resource Oriented）
- 可尋址（Addressability）
- 連通性（Connectedness）
- 無狀態（Statelessness）
- 統一接口（Uniform Interface）
- 超文本驅動（Hypertext Driven）
這6個特征是REST架構設計優秀程度的判斷標準。其中，面向資源是REST最明顯的特征，即，REST架構設計是以資源抽象為核心展開的。可尋址說的是：每一個資源在Web之上都有自己的地址。連通性說的是：應該盡量避免設計孤立的資源，除了設計資源本身，還需要設計資源之間的關聯關系，并且通過超鏈接將資源關聯起來。無狀態、統一接口是REST的兩種架構約束，超文本驅動是REST的一個關鍵詞，在前面都已經解釋過，就不再贅述了。
從架構風格的抽象高度來看，常見的分布式應用架構風格有三種：
- 分布式對象（Distributed Objects，簡稱DO）
架構實例有CORBA/RMI/EJB/DCOM/.NET Remoting等等
- 遠程過程調用（Remote Procedure Call，簡稱RPC）
架構實例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等
- 表述性狀態轉移（Representational State Transfer，簡稱REST）
架構實例有HTTP/WebDAV
DO和RPC這兩種架構風格在企業應用中非常普遍，而REST則是Web應用的架構風格，它們之間有非常大的差別。
REST與DO的差別在于：
- REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對象。在不同的編程語言中，對象的定義有很大差別，所以DO風格的架構通常都是與某種編程語言綁定的?？缯Z言交互即使能實現，實現起來也會非常復雜。而REST中的資源，則完全中立于開發平臺和編程語言，可以使用任何編程語言來實現。
- DO中沒有統一接口的概念。不同的API，接口設計風格可以完全不同。DO也不支持操作語義對于中間組件的可見性。
- DO中沒有使用超文本，響應的內容中只包含對象本身。REST使用了超文本，可以實現更大粒度的交互，交互的效率比DO更高。
- REST支持數據流和管道，DO不支持數據流和管道。
- DO風格通常會帶來客戶端與服務器端的緊耦合。在三種架構風格之中，DO風格的耦合度是最大的，而REST的風格耦合度是最小的。REST松耦合的源泉來自于統一接口+超文本驅動。
REST與RPC的差別在于：
- REST支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風格的架構建模是以名詞為核心的，RPC風格的架構建模是以動詞為核心的。簡單類比一下，REST是面向對象編程，RPC則是面向過程編程。
- RPC中沒有統一接口的概念。不同的API，接口設計風格可以完全不同。RPC也不支持操作語義對于中間組件的可見性。
- RPC中沒有使用超文本，響應的內容中只包含消息本身。REST使用了超文本，可以實現更大粒度的交互，交互的效率比RPC更高。
- REST支持數據流和管道，RPC不支持數據流和管道。
- 因為使用了平臺中立的消息，RPC風格的耦合度比DO風格要小一些，但是RPC風格也常常會帶來客戶端與服務器端的緊耦合。支持統一接口+超文本驅動的REST風格，可以達到最小的耦合度。
比較了三種架構風格之間的差別之后，從面向實用的角度來看，REST架構風格可以為Web開發者帶來三方面的利益：
- 簡單性
采用REST架構風格，對于開發、測試、運維人員來說，都會更簡單。可以充分利用大量HTTP服務器端和客戶端開發庫、Web功能測試/性能測試工具、HTTP緩存、HTTP代理服務器、防火墻。這些開發庫和基礎設施早已成為了日常用品，不需要什么火箭科技（例如神奇昂貴的應用服務器、中間件）就能解決大多數可伸縮性方面的問題。
- 可伸縮性
充分利用好通信鏈各個位置的HTTP緩存組件，可以帶來更好的可伸縮性。其實很多時候，在Web前端做性能優化，產生的效果不亞于僅僅在服務器端做性能優化，但是HTTP協議層面的緩存常常被一些資深的架構師完全忽略掉。
- 松耦合
統一接口+超文本驅動，帶來了最大限度的松耦合。允許服務器端和客戶端程序在很大范圍內，相對獨立地進化。對于設計面向企業內網的API來說，松耦合并不是一個很重要的設計關注點。但是對于設計面向互聯網的API來說，松耦合變成了一個必選項，不僅在設計時應該關注，而且應該放在最優先位置。
?
架構風格和架構模式之間的細微差別
- 架構風格是系統主要的、組織性的設計。
- 架構模式從子系統或模塊、及其之間的關系層次上描述了粗粒度的解決方案。
- 系統隱喻則更為概念化，比起軟件工程概念，它更多地涉及現實世界的概念。
?
David Calvert在1996年給出了一份架構風格/模式的部分清單:
- 數據流系統——批處理，管道-過濾器。
- 調用-返回系統——主程序和子程序，面向對象系統，分層。
- 獨立組件——通信過程，事件系統。
- 虛擬機——解釋器，基于規則的系統。
- 以數據為中心的系統（倉庫）——數據庫，超文本系統，黑板。
?
其它比較現代的風格/模式還有：插件、點對點、無共享架構、表述性狀態轉移（REST）、前端-后端。在維基百科上有更為完整的列表。
希望對您系統架構設計，軟件研發有幫助。 其它您可能感興趣的文章：
互聯網數據庫架構設計思路
企業級應用架構模式N-Tier多層架構
某企業社交應用網絡拓撲架構圖
IT基礎架構規劃方案一(網絡系統規劃)
餐飲連鎖公司IT信息化解決方案一
REST服務介紹
企業服務總線Enterprise service bus介紹
如有想了解更多軟件研發 , 系統 IT集成 , 企業信息化，項目管理 等資訊，請關注我的微信訂閱號：
?
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發布在我的獨立博客中-Petter Liu Blog。
總結
- 上一篇： lua的GC原理
- 下一篇： 英语口语练习五十五之英语委婉提建议