软件体系结构基础
halo~我是bay_Tong桐小白
本文內容是桐小白個人對所學知識進行的總結和分享，知識點會不定期進行編輯更新和完善，了解最近更新內容可參看更新日志，歡迎各位大神留言、指點
軟件體系結構基礎
- 【更新日志】
- 軟件體系結構基本概念
- 軟件體系結構
- 體系結構的模式、風格、框架
- 體系結構的重要作用
- 通用模型
- 設計模式概述（更新中……）
- 典型的體系結構風格
- 數據流風格
- 調用/返回風格
- 倉庫風格
- 體系結構框架
- 模型-視圖-控制器（MVC）
- J2EE體系結構框架（更新中……）
- PCMEF與PCBMER框架（更新中……）
- 特定領域的軟件體系結構
- 類屬模型
- 參考模型
- 分布式系統結構
- 多處理器體系結構
- 客戶機/服務器體系結構
- 兩層C/S體系結構
- 三層C/S體系結構
- 瀏覽器/服務器（B/S）體系結構
- 分布式對象體系結構
- 代理
【更新日志】
最近更新：
- 暫無編輯記錄，持續更新中……
軟件體系結構基本概念
軟件體系結構
目前還沒有一個公認的關于軟件體系結構的定義
Bass、Clements和Kazman給出了如下定義：“一個程序或計算機系統的軟件體系結構是指系統的一個或者多個結構。結構中包括軟件的構件、構件的外部可見屬性以及它們之間的相互關系。外部可見屬性則是指軟件構件提供的服務、性能、使用特性、錯誤處理、共享資源使用等。”
【這一定義強調在任一體系結構表述中“軟件構件”的角色】
構件：是面向軟件體系架構的可復用軟件模塊。構件是可復用的軟件組成成份，可被用來構造其他軟件。它可以是被封裝的對象類、類樹、一些功能模塊、軟件框架、軟件構架（或體系結構）、文檔、分析件、設計模式等
Dewayne Perry和A1exander Wo1f曾這樣定義：軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。
- 處理構件負責對數據進行加工
- 數據構件是被加工的信息
- 連接構件把體系結構的不同部分組合連接起來
【這一定義注重區分處理構件、數據構件和連接構件】
在體系結構設計的環境中，軟件構件可以簡單到程序模塊或者面向對象的類，也可以擴充到包含數據庫和能夠完成客戶與服務器網絡配置的中間件
體系結構設計是一系列決策和基本原理的集合，這些決策的目標在于開發高效的軟件體系結構。在體系結構設計中所強調的基本原理是系統的可理解性、可維護性和可擴展性
體系結構的模式、風格、框架
模式： 軟件設計模式是從軟件設計過程中總結出來的，是針對特定問題的解決方案
建筑師C.Alexander對模式給出的經典定義是：每個模式都描述了一個在我們的環境中不斷出現的問題及該問題解決方案的核心
在軟件系統中可以將模式劃分為以下三類：
- 體系結構模式：表達了軟件系統的基本結構組織形式或者結構方案，包干了一組預定義的子系統，規定了這些子系統的責任，同時還提供了用于組織組織和管理這些子系統的規則和向導。典型的體系結構模式如計算機網絡結構模型——開放式系統互聯參考模型（OSI參考模型）
- 設計模式：為軟件系統的子系統、構件或者構件之間的關系提供一個精煉之后的解決方案，描述了在特定環境下，用于解決通用軟件設計問題的構件以及這些構件相互通信時的各種結構。有代表性的設計模式是Erich Gamma及其同事提出的23種設計模式
- 慣用法：是與編程語言相關的低級模式，描述如何實現構件的某些功能，或者利用編程語言的特性來實現構件內部要素之間的通信功能
風格： 同一個問題可以有不同的解決問題的方案或模式，但我們根據經驗，通常會強烈傾向于采用特定的模式，這就是風格。包括：
- 一組構件（比如數據庫、計算模塊）完成系統需要的某種功能
- 一組連接件，它們能使構件間實現通信、合作和協調
- 約束，定義構件如何集成為一個系統
- 語義模型，它能使設計者通過分析系統構成成分的性質來理解系統的整體性質
體系結構風格定義了一個系統家族，即一個體系結構定義一個詞匯表（包含一些構件和連接件類型）和一組約束，這組約束指出系統是如何將這些構件和連接件組合起來。體系結構風格反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組成一個完整的系統
框架 ：隨著應用的發展和完善，某些帶有整體性的應用模式被逐漸固定下來，形成特定的框架，包括基本構成元素和關系。框架是特定應用領域問題的體系結構模式，框架定義了基本構成單元和關系后，開發者就可以集中精力解決業務邏輯問題
在組織形式上，框架是一個待實例化的完整系統，定義了軟件系統的元素和關系，創建了基本的模塊，定義了涉及功能更改和擴充的插件位置。典型的框架例子有MFC框架和Struts框架
體系結構的重要作用
- 體系結構的表示有助于風險承擔者（項目共利益者）進行交流
- 體系結構突出了早期設計決策，對隨后的所有軟件工程工作都具有深遠的影響，對最終軟件的質量和整個系統的成功都具有重要作用
- 軟件體系結構是可傳遞和可復用的模型。體系結構的風格和模式可以在需求相似的其他系統中進行復用。體系結構級的復用粒度比代碼級的復用粒度更大，由此帶來的益處也就更大
通用模型
【通用模型可以應用于許多不同類型的系統。此部分選擇有代表性的結構進行總結。體系結構的模式選擇設計模式做闡述，風格選擇典型的三種體系結構風格做闡述，框架選擇MVC、J2EE、PCMEF與PCBMER框架做闡述】
設計模式概述（更新中……）
典型的體系結構風格
數據流風格
當輸入數據經過一系列的計算和操作構件的變換形成輸出數據時，可以應用這種體系結構
管道/過濾器、批處理序列都屬于數據流風格
管道/過濾器結構
管道/過濾器結構擁有一組被稱為過濾器的構件，這些構件通過管道連接，管道將數據從一個構件傳送到下一個構件。每個過濾器獨立于其上游和下游的構件而工作，過濾器的設計要針對某種形式的數據輸入，并且產生某種特定形式的數據輸出。過濾器不需要了解與之相鄰的過濾器的工作
管道/過濾器風格優點：
- 使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點
- 允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成
- 支持軟件復用。只要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來
- 系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉
- 允許對一些如吞吐量、死鎖等屬性進行分析
- 支持并行執行。每個過濾器是作為一個單獨的任務完成，因此可與其他任務并行執行
管道/過濾器風格缺點：
- 通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換
- 不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重
- 因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，并增加了編寫過濾器的復雜性
批處理序列結構
如果數據流退化成為單線的變換，則成為批處理序列。這種結構接收一批數據，然后應用一系列連續的構件（過濾器）變換它
調用/返回風格
該體系結構風格便于設計出易于修改和擴展的程序結構，此類結構存在3種子風格
主程序/子程序體系結構
這種傳統的程序結構將功能分解為一個控制層次，其中“主”程序調用一組程序構件，這些程序構件又去調用別的程序構件。如下圖所示，這種結構總體上為樹狀結構，可以在底層存在公共模塊
當主程序/子程序體系結構的構件分布在網絡上的多個計算機上時，則稱主程序對子程序的調用為遠程過程調用。這種系統的目標是要通過將運算分布到多臺計算機上來充分利用多臺處理器，最終達到提高系統性能的目的
主程序/子程序體系結構的優點：
- 可以使用自頂向下，逐步分解的方法得到體系結構圖，典型的拓撲結構為樹狀結構。基于定義-使用關系對子程序進行分解，使用過程調用作為程序之間的交互機制
- 采用程序設計語言支持的單線程控制
主要缺點：
- 子程序的正確性難于判斷。需要運用層次推理來判斷子程序的正確性，因為子程序的正確性取決于它調用的子程序的正確性
- 子系統的結構不清晰。通常可以將多個子程序合成為模塊
面向對象風格
系統的構件封裝了數據和必須應用到該數據上的操作，構件間通過消息傳遞進行通信與合作。與主程序/子程序的體系結構相比，面向對象風格中的對象交互會復雜一些
面向對象風格與網絡應用的需求在分布性、自治性、協作性、演化性等方面具有內在的一致性
面向對象風格的優點:
- 因為對象對其他對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其他對象
- 設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合
面向對象風格的缺點：
- 為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象
- 必須修改所有顯式調用它的其他對象，并消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的
雜項：
- OMG：對象管理組，于1989年由一些廠商創建，其目的是建立網絡中分布式對象（組件）的標準結構。OMG組織是一個國際性的非盈利組織，其職責是為應用開發提供一個公共框架，制訂工業指南和對象管理規范，加快對象技術的發展
- OMA：對象管理體系結構，由OMG于1990年提出，定義了軟件系統參考模型，包括對象模型和參考模型兩部分 OMA對象模型定義如何描述異質環境環境中的分布式對象 OMA參考模型描述對象之間的交互
- CORBA：公共對象請求代理體系結構，以對象管理體系結構（OMA）為基礎，是由OMG組織制訂的一種標準的面向對象應用程序體系規范。或者說CORBA體系結構是對象管理組（OMG）為解決分布式處理環境(DCE)中，硬件和軟件系統的互連而提出的一種解決方案
層次結構風格
整個系統被組織成一個層次結構，每一層為上層提供服務，并作為下一層的客戶
從外層到內層，每層的操作逐漸接近機器的指令集
- 在最外層，構建完成界面層的操作；
- 在最內層，構件完成與操作系統的連接；
- 中間層提供各種實用程序和應用軟件功能
這種風格支持基于抽象程度遞增的設計。允許將復雜問題分解成一個增量步驟序列的實現。由于每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件復用提供了強大的支持
層次結構具有以下優點:
- 支持基于抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解
- 支持功能增強，因為每一層至多和相鄰的上下層交互，因此，功能的改變最多影響相鄰的內外層
- 支持復用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的接口，從而允許各種不同的實現方法
層次結構缺點如下:
- 并不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出于對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來
- 很難找到一個合適的、正確的層次抽象方法
倉庫風格
數據庫系統、超文本系統和黑板系統都屬于倉庫風格。在這種風格中，數據倉庫（如文件或數據庫）位于這種體系結構的中心，其他構件會經常訪問該數據倉庫，并對倉庫中的數據進行增加、修改或刪除操作
客戶軟件訪問中心倉庫。某下情況下倉庫是被動的，也就是說，客戶軟件獨立于數據的任何變化或其他客戶軟件的動作而訪問數據，此方式相當于傳統型數據庫系統
該方式的一個變種是將中心存儲庫變換成“黑板”，黑板構件負責協調信息在客戶間的傳遞，當用戶感興趣的數據發生變化時，它將通知客戶軟件
黑板系統的組成：
- 知識源：知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通信，它們之間的交互只通過黑板來完成
- 黑板數據結構：黑板數據是按照與應用程序相關的層次組織的、解決問題的數據，知識源通過不斷地改變黑板數據來解決問題
- 控制：控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識
黑板系統的傳統應用是信號處理領域（如語音和模式識別），另一應用是松耦合代理數據共享存取
黑板系統的優點：
- 對可更改性和可維護性的支持
- 可復用的知識源
- 支持容錯性和健壯性
黑板系統的不足：
- 測試困難，黑板系統的計算沒有依據確定的算法，其結果常常不可再現，此外，錯誤假設也是求解過程的組成部分
- 不能保證有好的求解方案，黑板系統往往只能正確解決所給任務的某一百分比
- 難以建立好的控制策略，控制策略不能以一種直接方式設計，而需要一種實驗的方法
- 低效，黑板系統在拒絕錯誤假設中要承受多余的計算開銷
- 昂貴的開發工作，絕大多數黑板系統要花幾年時間來進化
- 缺少對并行機制的支持 ，黑板體系結構不能避免采用了知識源潛在并行機制的控制策略，但它不提供它們的并行執行，對黑板上中心數據的并發訪問也必須是同步的
體系結構框架
模型-視圖-控制器（MVC）
MVC框架即模型-視圖-控制器（model-view-controller）框架，它強調將用戶輸入、數據模型和數據表示的方式分開設計，一個交互式應用系統由模型（model）、視圖（view）和控制器（controller）3個部件組成，分別對應于內部數據、數據表示和輸入/輸出控制部分
- 模型對象（Model）：模型對象獨立于外在顯示內容和形式，代表應用領域中的業務實體和業務規則，是整個模型的核心。模型對象的變化通過事件處理通知視圖和控制器對象
- 視圖對象（View）：視圖對象代表GUI對象，并且以用戶需要的格式表示模型狀態，是交互系統與外界的接口。視圖對象可以包含子視圖，子視圖用于顯示模型的不同部分。通常，每個視圖對象對應一個控制器對象
- 控制器對象（Controller）：控制器對象代表鼠標和鍵盤事件。它處理用戶的輸入行為并給模型發送業務事件，再將業務事件解析為模型應執行的動作；同時，模型的更新與修改也將通過控制器來通知視圖，從而保持各個視圖與模型的一致性。
模型是核心數據和功能，視圖只關心顯示數據，控制只關心用戶輸入，這種結構由于將數據和業務規則從表示層分開，因此可以最大化地重用代碼
J2EE體系結構框架（更新中……）
PCMEF與PCBMER框架（更新中……）
特定領域的軟件體系結構
除通用模型外，對于特別的應用還需要特別的體系結構模型，雖然這些系統實例的細節會有所不同，但共同的體系結構在開發新系統時是能夠復用的，這些體系結構模型稱為領域相關的體系結構
類屬模型
概念： 類屬模型是從許多實際系統中抽象出來的一般模型，它封裝了這些系統的主要特征
簡單說可以理解為，類屬模型將各種已經完成好的一般模型（也就是具有某一種小功能的組件）組合在一起，利用其它不同的結構進行聯系和組織，完成具有某一特定領域的系統功能的實現，是一種綜合性質的體系結構
典型用例： 類屬模型的一個最著名的例子是編譯器模型，由這個模型已開發出了數以千計的編譯器。編譯器一般包括以下模塊：
- 詞法分析器：將輸入的語言符號轉換成相應的內部形式
- 符號表：由詞法分析器建立，保留程序中出現的名字及其類型信息
- 語法分析器：檢查正被編譯的語言語法。它使用該語言定義的文法來建立一棵語法樹
- 語法樹：是正被編譯的程序在機器內部的結構表示
- 語義分析器：使用來自語法樹和符號表的信息檢查這個輸入程序的語義正確性
- 代碼生成器：遍歷語法樹并生成機器代碼
構成編譯器的組件可以依照不同的體系結構模型來組織，編譯器能使用組合模型來實現。如總體上可采用數據流風格，并將符號表作為容器來共享數據
這個模型現在仍然被廣泛使用，程序編譯時沒有用戶交互的影響。但當編譯器要與其它語言處理工具（如結構化的編輯系統、交互式調試器、高質量打印機等）集成時效率會很低，這種情形下一般系統組件可以使用基于容器（倉庫）模型來組織
參考模型
概念： 參考模型源于對應用領域的研究，它描述了一個理想化的包含了系統應具有的所有特征的軟件體系結構。它是更抽象且是描述一大類系統的模型，并且也是對設計者有關某類系統的一般結構的指導
典型用例： 典型的例子由國際化標準組織（ISO）與1978年提出的計算機網絡結構模型——開放式系統互連參考模型（OSI）參考模型。它描述了開放系統互連的標準，如果系統遵從這個標準，就可以與其它遵從該標準的系統互連
PS： 以上兩種不同類型的模型之間并不存在嚴格的區別。也可以將類屬模型視為參考模型。
兩者區別之一是類屬模型可以直接在設計中復用，而參考模型一般是用于領域概念間的交流和對可能的體系結構做出比較；另外，類屬模型通常是經過“自下而上”地對已有系統的抽象，而參考模型是“由上到下”地產生的
分布式系統結構
集中式計算與分布式計算
- 集中式計算技術：廣泛使用的是大型機/小型機計算模型。這種計算模型幾乎完全依賴于一臺大型的中心計算機（稱為宿主機）的處理能力，通過和它相連的非智能終端（用戶設備，往往僅僅作為一臺輸入輸出設備使用）來實現宿主機上的應用程序。在多用戶環境中宿主機應用程序既負責與用戶的交互，又負責對數據的管理，隨著用戶的增加，對宿主機能力的要求不斷提高
- 分布式系統結構：20c80s之后集中式結構主要被以PC為主的微機網絡所取代。網絡上所有計算機都有處理能力，每個新加入的用戶都對網絡處理能力的提高有貢獻，可以使用網上多臺計算機來完成一個共同的處理任務。如果某一臺計算機脫離了網絡（發生故障或關機）對網上的其他用戶不會有大的影響
分布式計算模型的優點
- 資源共享。分布式系統允許硬件、軟件等資源共享使用
- 經濟性。分布式計算性價比要高于集中式結構
- 性能與可擴展性。分布式應用程序能利用網絡上可獲得的資源，通過使用聯合起來的多個網絡結點的計算能力獲得性能方面的提升
- 固有分布性。有些應用程序是固有分布式的，如遵循客戶機/服務器模型的數據庫應用程序
- 健壯性。大多數情況下網絡上的一臺機器或多處理器系統中的一個CPU的崩潰不會影響到系統的其余部分
多處理器體系結構
概念： 是分布式系統的一個最簡單的模型，系統由許多進程組成，這些進程可以在不同的處理器上并行運行，可以極大地提高系統的性能
適用場合： 由于大型實時系統對響應時間要求較高，這種模型在大型實時系統中比較常見。大型實時系統需要實時采集信息，并利用采集到的信息進行決策，然后發送信號給執行機構。
客戶機/服務器體系結構
概念： 客戶機/服務器（client/server，C/S）體系結構是基于資源不對等，且為實現共享而提出來的，定義了工作站如何與服務器相連，以將數據和應用分布到多個處理機上
主要組成部分：
- 服務器：負責給其他子系統提供服務（如數據庫服務器提供數據存儲和管理服務，文件服務器提供文件管理服務，打印服務器提供打印服務等）
- 客戶機：向服務器請求服務。客戶機通常都是獨立的子系統，在某段時間內，可能有多個客戶機程序在并發運行
- 網絡：連接客戶機和服務器。通常客戶機程序和服務器程序放在不同的機器上運行
在C/S體系結構中，客戶機可以通過遠程調用來獲取服務器提供的服務，因此，客戶機必須知道可用的服務器的名字及它們所提供的服務，而服務器不需要知道客戶機的身份，也不需要知道有多少臺服務器在運行
邏輯結構的三層劃分： 在邏輯上，通常將應用系統劃分為三層，即數據管理層、應用邏輯層、表示層
- 數據管理層：關注數據存儲及管理操作，通常選擇成熟的關系數據庫管理系統來承擔這項任務
- 應用邏輯層：關注與業務相關的處理邏輯
- 表示層：關注用戶界面及與用戶的交互
兩層C/S體系結構
傳統的C/S體系結構為二層的C/S體系結構。在這種體系結構中，一個應用系統被劃分為客戶機和服務器兩部分
二層C/S體系結構可以有兩種形態：
- 瘦客戶機模型。即數據管理部分和應用邏輯部分都在服務器上執行，客戶機只負責表示部分
- 胖客戶機模型。服務器只負責對數據的管理，客戶機實現應用邏輯和與系統用戶的交互
胖客戶機模型能夠利用客戶機的處理能力，比瘦客戶機模型在分布處理上更有效。胖客戶機的數據處理流程如下：
隨著企業規模的日益擴大，軟件復雜程度的不斷提高，胖客戶機模型逐漸暴露出缺點：
- 開發成本較高。C/S體系結構對客戶端軟硬件配置要求較高，增加了整個系統的成本
- 用戶界面風格不一，使用繁雜，不利于推廣使用
- 軟件移植困難，采用不同工具或平臺開發的軟件，一般互不兼容，很難移植到其他平臺上運行
- 軟件維護和升級困難，由于應用程序安裝在客戶端，若軟件需要維護則每臺客戶機上的軟件均需要更新或升級
三層C/S體系結構
為了避免選擇瘦客戶機模型產生的伸縮性和性能的問題以及選擇胖客戶機模型產生的系統管理上的問題，產生了三層C/S體系結構。三層C/S體系結構中增加了一個應用服務器，可以將整個應用邏輯駐留在應用服務器上，只有表示層存在于客戶機上
三層C/S體系結構在系統上與邏輯結構上相似，被劃分為表示層、應用邏輯層、數據層三個部分
- 表示層：是應用程序的用戶界面部分，擔負著用戶與應用程序之間的對話功能。它用于檢查用戶從鍵盤等輸入的數據，顯示應用程序輸出的數據，一般采用圖形用戶界面（GUI）
- 應用邏輯層：應用邏輯層為應用系統的主體部分，包含具體的業務處理邏輯。通常在功能層中包含有確認用戶對應用和數據庫存取權限的功能以及記錄系統處理日志的功能
- 數據層：數據層主要包括數據的存儲及對數據的存取操作，一般選擇關系型數據庫管理系統（RDBMS）
三層C/S體系結構數據處理流程如下：
三層C/S結構具有的優點：
- 允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性，能提高系統和軟件的可維護性和可擴展性
- 允許更靈活有效地選用相應的平臺和軟件系統，使之在處理負荷能力上與處理特性上分別適應于結構清晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性
- 應用的各層可以并行開發，可以選擇各自最適合的開發語言
- 利用功能層有效地隔離開表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫或黑客手段去非法地訪問數據層，為嚴格的安全管理奠定了堅實的基礎
【PS：需注意的是三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，整體性能可能也會達不到要求。此外設計時必須慎重考慮三層間的通信方法、通信頻度、數據量。這和提高各層的獨立性一樣是三層C/S結構的關鍵問題】
瀏覽器/服務器（B/S）體系結構
瀏覽器/服務器（B/S）風格是三層應用結構的一種實現方式
- 瀏覽器：也可以說是客戶端，只有簡單的輸入輸出功能，處理極少部分的事務邏輯。由于客戶不需要安裝客戶端，只要有瀏覽器就能上網瀏覽，所以它面向的是大范圍的用戶，所以界面設計得比較簡單，通用
- WEB服務器：扮演著信息傳送的角色。當用戶想要訪問數據庫時，就會首先向WEB服務器發送請求，WEB服務器統一請求后會向數據庫服務器發送訪問數據庫的請求，這個請求是以SQL語句實現的
- 數據庫服務器：當數據庫服務器收到了WEB服務器的請求后，會對SQL語句進行處理，并將返回的結果發送給WEB服務器，接下來，WEB服務器將收到的數據結果轉換為HTML文本形式發送給瀏覽器，也就是我們打開瀏覽器看到的界面
B/S體系結構主要利用WWW瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器實現了原來需要復雜的專用軟件才能實現的強大功能，并節約了開發成本。從某種程度上說B/S結構是一種全新的軟件體系結構
B/S體系結構工作原理：
B/S體系結構具有的優點：
- 基于B/S體系結構的軟件，系統安裝、修改和維護全在服務器端解決。用戶在使用系統時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級
- B/S體系結構還提供了異種機、異種網、異種應用服務的聯機、聯網和統一服務的最現實的開放性基礎
B/S體系結構與C/S體系結構關系與區別：
B/S架構是從C/S架構改進而來，可以說是三層C/S架構，由此可見兩者關系不一般。B/S從C/S中脫離而出，后來隨著WEB技術的飛速發展以及人們對網絡的依賴程度加深，B/S一舉成為當今最流行的網絡架構。兩種架構都在各自崗位上虎虎生威，它們各有千秋，都是非常重要的網絡架構。在響應速度，用戶界面，數據安全等方面，C/S強于B/S，但是在業務擴展和適用www條件下，B/S明顯勝過C/S。可以這么說，B/S的強項就是C/S的弱項，反之亦然。它們各有優缺點，相互無法取代。
C/S結構與B/S結構兩種模式各自擁有其特色優勢，在不同的系統環境與操作平臺下，選擇較為接近或交叉進行混合模式的使用，可以保證數據的敏感性、安全性和穩定發展，還可以加強對數據庫的修改與新增記錄的操作。對客戶端程序進行保護，提高資源數據的交互性能，實現系統維護成本較低、維護方式較簡便、布局更合理、網絡數據使用效率較高的目的，采用C/S與B/S混合模式才是最佳方案
分布式對象體系結構
在B/S模型中客戶機和服務器的地位是不同的，客戶機必須要知道服務器的存在及其所提供的服務，而服務器則不需要知道客戶機的存在，設計者必須決定服務在哪里提供，要規劃系統的伸縮性，當有較多客戶機增加到系統中時需要考慮如何將服務器上的負載分布開來。分布式系統設計旨在去掉客戶機與服務器之間的差別。
分布式環境下，構件是一些靈活的軟件模塊，它們可以位置透明、語言獨立和平臺獨立地互相發送消息，實現請求服務。構件之間并不存在客戶機與服務器的界限，接受服務者扮演客戶機的角色，提供服務者就是服務器
分布式對象的實質是在分布式異構環境下建立應用系統框架和對象構件，它將應用服務分割成具有完整邏輯含義的獨立子模塊（稱為構件），各個子模塊可放在同一臺服務器或分布在多臺服務器上運行，模塊之間通過中間件互相通信
PS：傳統通信方式與中間件通信方式
- 傳統通信方式：通過一種集中管理式的固定的服務接口，或進行能力有限的遠程過程調用，這種方式不僅開銷大，也難于開發，要進行成功的軟件系統集成也存在很多障礙
- 中間件通信方式：如硬件總線允許不同的卡插于其上以支持硬件設備之間的通信一樣，通常將這個中間件稱為軟件總線或對象請求代理，它的作用是在對象之間提供一個無縫接口
分布式對象技術的應用目的是為了降低主服務器的負荷、共享網絡資源、平衡網絡中計算機業務處理的分配，提高計算機系統協同處理的能力，從而使應用的實現更為靈活
當前主流的分布式對象技術規范有：OMG的CORBA、Microsoft的.NET、Sun公司的J2EE等，它們均支持服務端構件的開發，都有各自的特點
代理
代理可以用于構建帶有隔離組件的分布式軟件系統，該軟件通過遠程服務調用進行交互。代理者負責協調通信，諸如轉發請求以及傳遞結果和異常等
1991年OMG基于面向對象技術給出了以對象請求代理（ORB）為中心的分布式應用體系結構（CORBA）
其中ORB是一個關鍵的通信機制，它以實現互操性為主要目標，處理對象之間的消息分布，在ORB之上有4個對象接口：
- 對象服務：定義加入ORB的系統級服務，如安全性、命名和事務處理，它們是與應用領域無關的
- 公共設施：水平級的服務，定義應用程序級服務
- 領域接口：面向特定的領域
- 應用接口：面向指定的現實世界應用。是指供應商或用戶借助于ORB、公共對象服務及公共設施而開發的特定產品
CORBA有很廣泛的應用，它易于集成各廠商的不同計算機，從大型機一直到微型內嵌式系統的終端桌面，是針對大中型企業應用的優秀的中間件。最重要的是，它使服務器真正能夠實現高速度、高穩定性處理大量用戶的訪問
持續更新中……
我是桐小白，一個摸爬滾打的計算機小白
總結
