軟件體系結構風格介紹
軟件結構風格的定義：軟件結構風格是描述某一特定應用領域中系統組織方式的慣用模式（idiomatic paradigm）。體系結構風格定義了一個系統家族，即一個體繫結構定義一個詞彙表和一組約束。詞彙表中包含一些構件和連接件組合起來的。體系結構風格反映了領域中衆多系統所共有的結構和語義特性，並指導如何將各個模塊和子系統有效地組織成一租個完整的系統。按這種方式理解，軟件體系結構風格定義了用於描述系統的術語表和一組指導構件系統的規則。
構件的定義：構件是具有某種功能的可重用的軟件模板單元，表示了系統中主要的計算元素和數據存儲。構件有兩種：複合構件和原子構件，複合構件由其他複合構件和原子構件通過連接而成；原子構件是不可再分的構件，底層由實現該構件的類組成，這種構件的劃分提供了體系結構的分層表示能力，有助於簡化體系結構的設計。
接件的定義：連接件表示了構件之間的交互，簡單的連接件如管道（pipe）、過程調用（proceduce call）、事件廣播（event broadcast）等，更爲複雜的交互如客戶-服務器（client-server）通信協議，數據庫和應用之間的SQL連接等。
軟件體系結構風格的四要素：
（1）提供一個詞彙表；
（2）定義一套配置規則；
（3）定義一套語義解釋規則；
（4）定義對基於這種風格的系統所進行的分析。
軟件體系結構風格的目的:軟件體系結構風格爲大粒度的軟件重用提供了可能。
軟件體系結構設計的一箇中心問題是能否重用軟件體系結構模式，或者採用某種軟件體系結構風格。有原則地使用軟件體系結構風格具有如下意義：
- 它促進了設計的複用，使得一些經過實踐證實的解決方案能夠可靠地解決新問題。
- 它能夠帶來顯著的代碼複用，使得體系結構風格中的不變部分可共享同一個解決方案。
- 便於設計者之間的交流與理解。
- 通過對標準風格的使用支持了互操作性，以便於相關工具的集成。
- 在限定了設計空間的情況下，能夠對相關風格作出分析。
- 能夠對特定的風格提供可視化支持。
與此同時，人們目前尚不能準確回答的問題是：
- 系統設計的哪個要點可以用風格來描述；
- 能否用系統的特性來比較不同的風格，如何確定用不同的風格設計系統之間的互操作；
- 能否開發出通用的工具來擴展風格；
- 如何爲一個給定的問題選擇恰當的體系結構風格，或者如何通過組合現有的若干風格來產生一個新的風格。
M.Shaw等人根據此框架給出了管道與過濾器、數據抽象和麪向對象組織、基於事件的隱式調用、分層系統、倉庫系統及知識庫和表格驅動的解釋器等一些常見的軟件體系結構風格。
（一）管道和過濾器風格
在管道/過濾器風格的軟件體系結構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然後產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這裏的構件被稱爲過濾器，這種風格的連接件就像是數據流傳輸的管道，將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的 過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性並不依賴於過濾器進 行增量計算過程的順序。
圖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) 既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。
Java的Swing、安卓以及JavaScript 事件的註冊與監聽都體現了此風格。基於事件的隱式調用風格特點很明顯：事件的觸發者並不知道哪些構件會被這些事件影響：不能假定構件的處理順序，甚至不知道哪些過程會被調用；爲此，許多隱式調用的系統也包含顯式調用作爲構件交互的補充形式。
支持隱式調用的系統可以舉出這些
- 在編程環境中用於集成各種工具。（集成開發環境）
- 在數據庫管理系統中確保數據的一致性約束。
- 在用戶界面系統中管理數據。
- 在編輯器中支持語法檢查等。
（四）層次系統風格
層次系統組織成一個層次結構，每一層爲上層服務，並作爲下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機(在另一些層次系統中層是部分不透明的)。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
這種風格支持基於可增加抽象層的設計。這樣，允許將一個複雜問題分解成一個增量步驟序列的實現。由於每一層最多隻影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣爲軟件重用提供了強大的支持。
圖2-3是層次系統風格的示意圖。層次系統最廣泛的應用是分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作爲上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。
圖 2‑3層次系統風格的體系結構
層次系統有許多可取的屬性：
(1) 支持基於抽象程度遞增的系統設計，使設計者可以把一個複雜系統按遞增的步驟進行分解；
(2) 支持功能增強，因爲每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；
(3) 支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現方法。
但是，層次系統也有其不足之處：
(1) 並不是每個系統都可以很容易地劃分爲分層的模式，甚至即使一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；
(2) 很難找到一個合適的、正確的層次抽象方法。
分層通信協議TCP/IP體現此風格
（五）倉庫風格
在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互作用在系統中會有大的變化。
控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
圖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結構存在以下幾個侷限：
- 它是單一服務器且以局域網爲中心的，所以難以擴展至大型企業廣域網或Internet；
- 受限於供應商；
- 軟、硬件的組合及集成能力有限；
- 難以管理大量的客戶機。
因此，三層C/S結構應運而生。三層C/S結構是將應用功能分成表示層、功能層和數據層三部分。其解決方案是：對這三層進行明確分割，並在邏輯上使其獨立。原來的數據層作爲DBMS已經獨立出來，所以關鍵是要將表示層和功能層分離成各自獨立的程序，並且還要使這兩層間的接口簡潔明瞭。
將上述三層功能裝載到硬件的方法基本上有三種(如圖所示)。其中表示層配置在客戶機中，而數據層配置在服務器中。
一般情況是隻將表示層配置在客戶機中，與二層C/S結構相比，其程序的可維護性要好得多，是其他問題並未得到解決。客戶機的負荷太重，其業務處理所需的數據要從服務器傳給客戶機，所以系統的性能容易變壞。
如果將功能層和數據層分別放在不同的服務器中，則服務器和服務器之間也要進行數據傳送。但是，由於在這種形態中三層是分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業務處理時，可以相應增加裝載功能層的服務器。因此，系統規模越大這種形態的優點就越顯著。
值得注意的是：三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，其作爲整體來說也達不到所要求的性能。此外，設計時必須慎重考慮三層間的通信方法、通信頻度及數據量。這和提高各層的獨立性一樣是三層C/S結構的關鍵問題。
三層C/S的功能
1.表示層
表示層是應用的用戶接口部分，它擔負着用戶與應用間的對話功能。它用於檢查用戶從鍵盤等輸入的數據，顯示應用輸出的數據。爲使用戶能直觀地進行操作，一 般要使用圖形用戶接口(GUI)，操作簡單、易學易用。在變更用戶接口時，只需改寫顯示控制和數據檢查程序，而不影響其他兩層。檢查的內容也只限於數據的 形式和值的範圍，不包括有關業務本身的處理邏輯。
圖形界面的結構是不固定的，這便於以後能靈活地進行變更。例如，在一個窗口中不是放入幾個功能，而是按功能分割窗口，以便使每個窗口的功能簡潔單純。在這層的程序開發中主要是使用可視化編程工具。
2.功能層
功能層相當於應用的本體，它是將具體的業務處理邏輯地編入程序中。例如，在製作訂購合同的時要計算合同金額，按照定好的格式配置數據、打印訂購合同，而 處理所需的數據則要從表示層或數據層取得。表示層和功能層之間的數據交往要儘可能簡潔。例如，用戶檢索數據時，要設法將有關檢索要求的信息一次傳送給功能 層(參見圖2)，而由功能層處理過的檢索結果數據也一次傳送給表示層。在應用設計中，一定要避免進行一次業務處理，在表示層和功能層間進行多幾次數據交換 的笨拙設計。
通常，在功能層中包含有：確認用戶對應用和數據庫存取權限的功能以及記錄系統處理日誌的功能。這層的程序多半是用可視化編程工具開發的，也有使用COBOL和C語言的。
3.數據層
數據層就是DBMS，負責管理對數據庫數據的讀寫。DBMS必須能迅速執行大量數據的更新和檢索。現在的主流是關係數據庫管理系統(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並不是處於絕對的統治地位。現在 的趨勢是凡使用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風格方便地支持運行時刻的系統演化，主要包括動態增加或刪除構件、動態改變構件響應的消息類型和消息過濾。
摘自《軟件體系結構原理、方法與實踐（第2版）張友生》
