---
# System prepended metadata

title: Architectural Styles and the Design of Network-based Software Architectures -Roy Thomas Fielding
tags: [Java]

---

原文
https://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm
中譯
https://github.com/aisuhua/restful-api-design-references/blob/master/%E6%9E%B6%E6%9E%84%E9%A3%8E%E6%A0%BC%E4%B8%8E%E5%9F%BA%E4%BA%8E%E7%BD%91%E7%BB%9C%E7%9A%84%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1.pdf
# 第一章 Software Architecture
## 1.1 Run-time Abstraction
軟體架構可以簡單理解為你所建構的系統的抽象描述，裡面包含很多部件和運行階段，而每一個部間或階段又有自己的軟體架構。例如一間房子是一個完整軟體，裡面包含很多家具和電器，每一樣都有自己的功能和更細小的零件組成，這些小部件組成各式各樣的家具，而這些家具組成間完整的房子。並且每個家具都有其獨特運行方式，依功能各司其職不衝突。

軟體架構的核心就是用抽象層隱藏其系統的細節，以便更好辨認和維持其特性。而一個複雜的系統包含多層級的抽象層，每一層又有自己的架構，而架構代表該層級系統行為的抽象描述，這樣一層一層的結構會持續往下直到無法再分解的層級，並解組成一個複雜的系統。

除了架構的分級，每個運行階段也有自己的架構，例除初始化、開關機等等。而完整的系統架構描述不只要能描述每個階段的行為，也要能描述階段之間的轉換。

最後描述了軟體架構和軟體結構之簡最根本的定義和區別。

## 1.2 Elements
一個軟體架構是由一些元素包含組件、連接器和數據而組成，而其之前的關係會受到某些約束進而產生架構的屬性。

這裡包含作者和其他專家對於軟體架構不同的定義，有別於Perry和Wolf的定義，作者對於軟體架構的定義排除了元素的基本原理。

除此之外，Garlan 和 Shaw對於軟體架構的描述也有不同的見解，他們認為軟體架構是其組件之間的交互作用和對應關係。但作者認為這樣定義方式不足以描述網路上的軟體架構，因為對於網路數據元素是唯一重要因素。
### 1.2.1 Components
一個組件是一個軟體指令和內部狀態的抽象單元，並透過他的介面提供轉換數據。

它們像是能夠執行特定任務的小模組，這些任務可以是從儲存中讀取數據、進行計算、格式轉換等。組件的行為是架構的一部分，由它提供的服務和界面來定義而非介面背後的實現。

### 1.2.2 Connectors
連接器是組件之間溝通、合作或是協調的抽象機制。連接器通過在不改變數據的情況下從一個界面轉移到另一個界面，從而實現組件之間的通信。

### 1.2.3 Data
"資料"是從一個組件通過連接器傳遞到另一個組件，或被組件接收的信息。資料元素的性質影響著選擇適合的架構風格。在網絡應用中，資料元素決定了選擇何種架構的適用性。

## 1.3 Configurations
"配置"是組件、連接器和數據在系統運行時期之間的架構關係結構。它描述了組件之間的互動、連接器的定義以及在系統運行時期的數據流動。

在軟體架構描述中，"配置"可以看作是對組件互動的特定約束集合。它能夠幫助建立系統結構並區分不同的運行情境，同時也能限制合理系統的範圍。
## 1.4 Properties
軟體架構的屬性集包括由組件、連接器和數據的選擇與排列所帶來的特性，包括系統的功能性和非功能性特性，如易於演進、組件可重用性、效率和可擴展性等。這些特性由架構內的約束引起，通常基於軟體工程原則應用於架構元素。架構設計的目標是創建具有一組超越系統需求的架構特性，各特性的重要性視系統性質而定。
## 1.5 Styles
架構風格是一組限制，定義了架構元素的角色和關係。它是分類架構並確定共同特性的方法，不同風格專注於不同的方面。選擇適合的風格需要考慮問題領域和通信需求。
## 1.6 Patterns and Pattern Languages
軟體模式和架構風格都是用來處理系統設計中的重複問題的方法。設計模式關注物件導向程式設計，而架構風格專注於整個系統的結構和約束。兩者都有助於建立適當的設計模式和約束。

## 1.7 Views
架構觀點是應用特定的，能夠處理不同問題。它們可以從不同角度看待架構，如處理、數據和連接觀點。架構設計方法有不同的觀點，可以同時考慮多個問題。
## 1.8 Realted Work
這裡僅涵蓋了定義軟體架構或描述軟體架構風格的研究領域。其他軟體架構研究領域包括架構分析技術、架構恢復和再工程、架構設計的工具與環境、從規格到實現的架構細化，以及已部署軟體架構的案例研究。與風格分類、分散式過程範式和中間件相關的工作將在第三章中討論。
### 1.8.1 Design Methodologies
早期軟體架構研究聚焦在設計方法論上，包括面向對象設計和Jackson系統開發等。一些研究探索架構分析和開發方法，如SAAM和ATAM。其中，一些方法論導向特定架構風格的產生。
### 1.8.2 Handbooks for Design, Design Patterns, and Pattern Languages
Shaw主張建立軟體架構手冊，面向對象程式設計社群推出了設計模式目錄。軟體設計模式更針對問題，而架構風格則是獨立於應用領域的操作特性。
### 1.8.3 Reference Models and Domain-specific Software Architectures (DSSA)
參考模型提供架構描述和元件關聯的概念框架。例如，OMA是經紀式分散對象架構的參考模型，強調分散對象管理。DSSA專注於特定領域的通用計算框架，強調元件重用而非特定風格。
### 1.8.4 Architecture Description Languages (ADL)
近期軟體架構研究主要集中在架構描述語言（ADL）。ADL是一種語言，用於明確定義軟體系統的概念架構，包括元件、連接器等。一些ADL如Darwin和UniCon用於指定系統結構和元件互動。不同ADL有不同特點，有些專注特定架構風格，有些更通用但可能無法進行特定分析。
### 1.8.5 Formal Architectural Models
Abowd等人認為架構風格可透過少數從架構描述到架構含義的映射進行正式描述。但這假設架構即是描述，不是運行系統的抽象。

Inverardi和Wolf使用CHAM形式模擬軟體架構元素，將其視為受規則控制的化學反應。Rapide是一種用於定義和模擬系統架構的語言，生成部分有序事件集可分析架構限制。Le Métayer提出了基於圖形的架構定義形式。
## 1.9 Summary
本章探討論文背景，引入一致的軟體架構術語，避免混淆架構和架構描述。回顧相關軟體架構研究。下兩章將繼續探討基於網路的應用架構，並描述如何使用風格引導設計，進行常見架構風格調查。
# 第二章 Network-based Application Architectures
本章將繼續討論背景材料，重點集中在基於網路的應用架構，並描述了如何使用風格來引導其架構設計。
## 2.1 Scope
本論文探討軟體系統中不同層次的架構。專注於最高層次的軟體架構抽象，其中元件之間的互動可在網路通信中實現。我們僅討論基於網路的應用架構風格，以減少所研究的風格之間的變異維度。
### 2.1.1 Network-based vs. Distributed
基於網路的架構區別於一般軟體架構，主要在於元件間通信受限於訊息傳遞，而非透過其他更有效的機制。這篇論文關注基於網路的應用架構，並描述如何運用風格來引導架構設計。與此相關，用戶感知網路操作的差異對於系統特性和成本是重要的考慮因素。
### 2.1.2 Application Software vs. Networking Software
本論文範圍僅限於應用程式架構，排除操作系統、網路軟體以及僅用於系統支援的某些架構風格。應用程式架構處於整體系統的抽象層次，專注於用戶操作的功能性特性。相較於網路抽象，應用程式架構更關注使用者互動次數、應用程式狀態位置、所有資料流的實際通量等，以進行設計權衡的評估。
## 2.2 Evaluating the Design of Application Architectures
本論文的目標是提供選擇或創建最適架構的設計指導。架構評估涉及功能需求和約束的比較。通過導出架構約束的樹，架構師可以評估多個不同的應用架構設計。設計評估涉及權衡，而透過視覺模式來指導直覺判斷。
## 2.3 Architectural Properties of Key Interest
這部分描述了用於區分和分類架構風格的架構屬性。這不是完整的清單，僅包括受限風格調查影響的屬性。其他屬性稱為軟體品質，已由軟體工程教科書涵蓋（例如[58]）。Bass等人在[9]中探討了軟體架構方面的品質。
### 2.3.1 Performance
專注於網絡應用程式的架構風格之所以重要，是因為組件之間的互動會影響使用者感知的性能和網絡效率。架構風格影響互動方式，選擇適合的風格可以決定應用程式部署的成敗。

網絡應用程式的性能受應用需求和互動風格的影響，而架構則在其之上。最終，組件的實現速度限制了互動的速度。
#### 2.3.1.1 Network Performance
網絡性能衡量通信的一些特點。吞吐量是資訊在組件之間的傳輸速率。開銷可分為初始設置和互動的成本，有些連接器可以分享開銷。帶寬是連接上的最大速率。可用帶寬是實際上應用可使用的部分。

風格影響互動數量和數據大小。小型、強類型互動適合小型數據傳輸。多組件協調適用於大數據流。
#### 2.3.1.2 User-perceived Performance
用戶感知性能是衡量行動對用戶的影響，而網絡性能是衡量網絡傳輸速率。用戶感知性能的關鍵指標是延遲和完成時間。

延遲是從初始操作到首次響應的時間。它包括多個階段，包括辨識操作、設置互動、傳輸數據、處理數據和準備渲染結果等。完成時間是完成整個操作所需的時間。完成時間減去延遲即為數據處理時間。設計考慮優化延遲通常會影響完成時間，需要平衡兩者。

架構風格影響交互次數和數據元素細節，這會影響性能。對於小數據轉移，小型互動效率高；而需要大數據轉移或協調多個組件的場景，效率則較低。
#### 2.3.1.3 Network Efficiency
網絡應用中，最佳性能是在不使用網絡時實現的。因此，最有效的架構風格是能夠最小化網絡使用的風格，通過重用以前的互動、減少網絡互動頻率，或將數據處理移到靠近數據源的地方。性能問題影響與應用的分佈範圍相關，考慮交互距離、WAN和互聯網情況。
### 2.3.2 Scalability
可擴展性是架構支持大量元件或互動的能力。通過簡化元件、分散服務、控制互動，風格影響可擴展性。交互頻率、負載分佈、交互性質也影響可擴展性。
### 2.3.3 Simplicity
風格透過將功能分配至元件中，遵循關注點分離原則，實現簡單性。同時，通用性的原則也提升了簡單性，減少架構內的變化。
### 2.3.4 Modifiability
修改性指的是修改應用程式架構的容易程度，包括進化、擴充、客製化、配置和重用等。對於網絡系統，動態修改能力特別重要，可以在不停止整個系統的情況下修改已部署的應用程式。因為參與網絡系統的元件可能跨越多個組織邊界，所以系統需要能夠適應逐步變化，新舊實現可以共存並利用擴展功能。
#### 2.3.4.1 Evolvability
Evolvability 是指在不影響其他元件的情況下，能夠修改元件實作的程度。靜態演化依賴於架構抽象的實作執行情況，動態演化則可受到風格的影響。在分佈式系統中用於從部分失敗中恢復的技術也適用於支援動態演化。
#### 2.3.4.2 Extensibility
Extensibility 指的是將功能新增到系統的能力。動態可擴展性表示能夠在已部署的系統中新增功能而不影響其餘系統。通過減少元件之間的耦合，可以在架構風格中引入可擴展性，如事件驅動的整合。
#### 2.3.4.3 Customizability
Customizability 指的是能夠臨時特定化架構元素行為的能力，使其執行不尋常的服務。可自定義的元件可以被客戶擴展，而不影響其他客戶。這可以通過遠程評估和代碼動態風格實現。
#### 2.3.4.4 Configurability
Configurability 與擴展性和重用性相關，它指的是在部署後對元件進行修改或配置，使它們能夠使用新的服務或數據元素類型。管道和遠程動態代碼兩種風格都可以引發配置的擴展和元件。
#### 2.3.4.5 Reusability
重用性是應用架構的一種屬性，如果其元件、連接器或數據元素可以在其他應用中無需修改地進行重用。在架構風格內誘發重用性的主要機制是減少元件之間的耦合（身份知識）並對元件界面的一般性進行約束。統一的管道和過濾風格是這些約束的例子。
### 2.3.5 Visibility
風格可以通過限制界面或提供監控來影響元件之間的可見性。這可以改善性能、可擴展性、可靠性和安全性。移動代理風格缺乏可見性可能引起安全問題。這裡的可見性與 Ghezzi 等人的用法不同，他們指的是開發過程的可見性。
### 2.3.6 Portability
軟體可移植性是指它能在不同環境中運行。導致可移植性的風格包括將程式碼與要處理的資料一起移動的風格，如虛擬機和移動代理風格，以及將資料元素約束到一組標準格式的風格。
### 2.3.7 Reliability
從應用程式架構的角度來看，可靠性可以被視為在元件、連接器或資料中存在部分故障的情況下，系統層面容易出現故障的程度。風格可以通過避免單一故障點、實現冗餘、允許監控或將故障範圍減小到可恢復的操作，來提高可靠性。
## 2.4 Summary
本章著重於探討網絡應用程式架構的範圍，並說明風格如何用於引導其架構設計。同時，它定義了在整篇論文中將用於比較和評估架構風格的一套架構特性。

下一章將在一個分類框架內對網絡應用程式軟件的常見架構風格進行調查，並根據每個風格應用於典型的網絡超媒體系統架構時將引入的架構特性進行評估。
# 第三章 Network-based Architectural Styles
這一章節介紹了網路應用軟體常見的架構風格，並將其納入一個分類框架中，根據這些風格在應用於典型網路超媒體系統的架構中可能引發的架構特性進行評估。
## 3.1 Classification Methodology
軟體建設的目標是滿足或超越需求，所以架構風格應適應需求，而非逆向。因此，有用的設計指導應該基於架構風格引發的特性進行分類。
### 3.1.1 Selection of Architectural Styles for Classification
這份分類列出的架構風格並不包含所有可能的網路應用風格。我的目標是描述代表性的風格，並提供一個框架，可以將新風格添加到分類中。排除了與調查風格結合後無法增強通信或互動特性的風格。例如，黑板架構可以擴展為基於網路的系統，但這取決於選擇的互動風格。因此，即使有網路能力，也不會在分類中增加價值。
### 3.1.2 Style-induced Architectural Properties
我的分類使用架構特性的相對變化來展示每種風格在分散式超媒體系統中的效果。我們評估每種風格對於基於網路的超媒體系統的影響，專注於特定軟體類型，這有助於識別風格之間的優勢。我們不打算宣稱一種風格適用於所有類型的軟體，將評估範圍限制在特定領域簡化了評估的維度。其他應用軟體類型的評估則是未來研究的方向。
### 3.1.3 Visualization
我使用表格將風格對架構特性進行對比，作為主要的視覺化方式。表格的值顯示特定行的風格對該列特性的相對影響。可以累加負面影響的減號（-），正面影響的加號（+），加減號（±）表示依賴於問題領域的某些方面。雖然這是對各節內容的粗略簡化，但能顯示風格在多大程度上已處理（或忽略）架構特性。

另一種視覺化方式是基於特性的衍生圖，用於分類架構風格。風格根據從其他風格衍生出的方式進行分類，風格之間的弧線表示獲得或失去的架構特性。圖的起點是空風格（無約束）。可以直接從描述中推導出這種圖。
## 3.2 Data-flow Styles

Table 3-1: Evaluation of Data-flow Styles for Network-based Hypermedia![](https://hackmd.io/_uploads/rykdpWjnn.png)
### 3.2.1 Pipe and Filter (PF)
管道和過濾器風格中，每個組件讀取輸入數據並輸出處理後的數據，通常會對數據流進行轉換並在處理時逐步產生輸出。這種風格追求簡單、重用、擴展和並行執行等優勢。然而，它的缺點包括傳播延遲、無法互動和特定問題的限制。此外，這種風格的配置由一個「無形之手」進行，並需要考慮控制器的運行階段。
### 3.2.2 Uniform Pipe and Filter (UPF)
均一管道和過濾器風格要求所有過濾器具有相同界面。Unix操作系統是主要例子，它使用相同的界面連接過濾器，以形成新的應用。這簡化了過濾器的使用和理解，但可能降低數據轉換效能。
## 3.3 Replication Styles![](https://hackmd.io/_uploads/ry5keMo2n.png)
### 3.3.1 Replicated Repository (RR)
複製儲存庫風格的系統透過多個進程提供相同服務，提高數據可訪問性和可擴展性。分散的伺服器互動，讓客戶感覺只有一個集中式服務。改進使用者感知的性能是主要優勢，減少請求延遲，支援斷線操作。簡單性保持中立，複製的複雜性可透過允許不具網路意識的組件在本地複製數據的透明運作來彌補。保持一致性是主要關注點。
### 3.3.2 Cache ($) 
快取風格是複製儲存庫的變體，將個別請求的結果複製，供後續請求重複使用，通常在數據集龐大時或不需要完全訪問儲存庫時使用。快取的效果稍遜於複製儲存庫，但更易實施，並且只在需要時傳輸數據。
## 3.4 Hierarchical Styles!
[]https://hackmd.io/_uploads/BywvzI2hn.png)
### 3.4.1 Client-Server (CS)
客戶端-伺服器風格是常見的網路應用架構，伺服器提供服務，客戶端發送請求。透過分離功能，客戶端負責用戶界面，伺服器處理請求。該風格可使用遠程過程呼叫或消息中間件實現。
### 3.4.2 Layered System (LS) and Layered-Client-Server (LCS)
分層系統以階層組織，每層提供服務給上一層，使用下一層的服務。分層系統提高了演化性和重用性，但會增加處理數據的開銷和延遲，降低使用者感知的性能。分層客戶端-伺服器在客戶端-伺服器基礎上加入代理和閘道組件，以添加功能，如負載平衡和安全檢查。這種架構在信息系統中稱為兩層、三層或多層架構。在大規模分佈式系統中，分層可以解決身份管理問題。
### 3.4.3 Client-Stateless-Server (CSS)
客戶端無狀態伺服器風格源自客戶端-伺服器，強調伺服器不保存會話狀態，所有必需請求信息都在客戶端。這提高了可見性、可靠性和可擴展性，但可能增加網路性能開銷。
### 3.4.4 Client-Cache-Stateless-Server (C$SS)
客戶端-快取-無狀態伺服器風格源自客戶端-無狀態伺服器和快取風格，通過添加快取組件而來。快取作為客戶端和伺服器之間的中介，對先前請求的回應，如果被認為是可快取的，可以在後續等價的請求中被重複使用，如果這些請求被轉發到伺服器，則結果可能與快取中的回應相同。一個有效使用此風格的例子是Sun Microsystems的NFS [115]。

添加快取組件的好處是它們有可能部分或完全消除某些互動，提高效率和使用者感知的性能。
### 3.4.5 Layered-Client-Cache-Stateless-Server (LC$SS)
「分層客戶端快取無狀態伺服器」（LC$SS）架構風格結合了「分層客戶端伺服器」（LCS）和「客戶端快取無狀態伺服器」（C$SS）的特點，透過加入代理和/或閘道元件進一步擴展。優點包括可擴展性、效能提升、可靠性、簡化設計、以及快取優勢；缺點則在於複雜性增加、維護困難、資料一致性挑戰、可能的延遲增加，以及配置開銷。在考慮優缺點時，需注意部分優勢可能因共同祖先衍生而不重複計算。
### 3.4.6 Remote Session (RS)
遠程會話風格是客戶端-伺服器的一種變體，強調在伺服器端保持應用程式狀態，讓客戶端元件保持簡單和重用。每個客戶端在伺服器上建立會話，調用一系列服務，然後結束會話。這樣的風格適合通用客戶端訪問遠程服務，但可能降低伺服器的可擴展性，並減少交互的可見性。
### 3.4.7 Remote Data Access (RDA)
遠程數據訪問風格是客戶端-伺服器的變體，將應用程式狀態分佈在客戶端和伺服器之間。客戶端發送標準格式（如SQL）的數據庫查詢到遠程伺服器，伺服器執行查詢，然後客戶端可以對結果進行操作。此風格的優點是可以在伺服器上迭代地處理大型數據集，提高效率，並透過標準查詢語言提高可見性。缺點是需要在客戶端理解伺服器的數據庫操作概念，可能降低簡單性，且在伺服器上存儲應用程式狀態會影響可擴展性。可靠性也受到影響，需透過交易機制解決，但可能增加複雜性和交互開銷。
## 3.5 Mobile Code Styles
移動代碼風格運用移動性來改變處理和數據來源或結果的距離，以提升效率和性能。通過引入站點抽象，考慮不同元件的位置，可以模擬交互成本。這些風格中，數據元素轉換為元件，並通過比較代碼大小和數據傳輸節省，確定是否需要移動性。如果軟件架構排除了數據元素，則無法從架構角度進行建模。
### 3.5.1 Virtual Machine (VM)
在各種移動代碼風格的基礎上，存在著虛擬機器或解釋器風格的概念。這種風格下，代碼需要以某種方式執行，最好在受控環境中確保安全性和可靠性。虛擬機器風格提供了這種受控環境，它不僅具有可移植性和易於擴展性的優點，同時也降低了可見性，因為單純從代碼難以了解執行文件的行為。雖然需要管理評估環境可能降低了簡單性，但在某些情況下，通過簡化靜態功能，也可以對此進行補償。
### 3.5.2 Remote Evaluation (REV)
遠程評估風格是一種源自客戶端-伺服器和虛擬機器風格的架構，其中客戶端元件具備執行服務所需的知識，但缺乏必要的資源，將知識發送到遠程伺服器，由伺服器執行代碼，並將結果返回客戶端。這種風格的優點包括提供伺服器服務的自定義能力，提高擴展性和定制性，並在代碼能夠適應伺服器內部環境的情況下提高效率。然而，它的簡單性、可擴展性和可見性都會受到影響，其中最明顯的限制是客戶端傳送代碼而不是標準化查詢，可能導致部署問題和可信性問題。
### 3.5.3 Code on Demand (COD)
代碼按需風格中，客戶端元件擁有一組資源，但缺乏處理資源的知識。它向遠程伺服器請求代表知識的代碼，然後在本地執行該代碼。此風格的優點包括能夠為已部署的客戶端添加功能，提高擴展性和配置性，並在代碼可以適應客戶端環境並在本地與用戶交互時提高性能和效率。然而，由於需要管理評估環境，它的簡單性降低，但在某些情況下，可能通過簡化客戶端的靜態功能來進行補償。伺服器的可擴展性得到改善，因為它可以將工作卸載到客戶端，但最顯著的限制是由於伺服器發送代碼而不是簡單數據，導致可見性不足。如果客戶端不能信任伺服器，則缺乏可見性會導致明顯的部署問題。
### 3.5.4 Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)
以將代碼按需添加到上述分層客戶端快取無狀態伺服器風格中作為架構互補的示例。由於代碼可以被視為另一個數據元素，這不會干擾LC$SS風格的優勢。一個例子是HotJava Web瀏覽器 [java.sun.com]，它允許下載作為類型化媒體的小程序和協議擴展。

LCODC$SS風格的優缺點僅僅是代碼按需和LC$SS風格的優缺點的結合。我們可以進一步討論COD和其他CS風格的組合，但這份調查並不旨在全面（也不會令人疲憊）。
### 3.5.5 Mobile Agent (MA)
在移動代理風格 [50] 中，整個計算元件與其狀態、所需代碼和可能需要執行任務的一些數據一起移動到遠程站點。這可以視為遠程評估和代碼按需風格的一種衍生，因為移動性是雙向的。

移動代理風格的主要優勢，除了已經描述過的遠程評估和代碼按需風格的優點外，還在於在何時移動代碼的選擇上更具動態性。在處於一個位置處理信息的應用程式可能會決定移動到另一個位置，可能是為了減少與它希望處理的下一組數據之間的距離。此外，由於應用程式狀態一次只存在於一個位置，部分失敗的可靠性問題得到減少 [50]。
## 3.6 Peer-to-Peer Styles
### 3.6.1 Event-based Integration (EBI)
事件驅動整合風格，也稱為隱式呼叫或事件系統風格，通過消除組件間的耦合，不需要連接器界面上的身份需求。組件可以宣告事件，其他組件可以註冊對事件的興趣，當事件發生時，系統調用所有已註冊的組件。這種風格支持擴展性、重用性和演化性，但可能導致事件通知的可擴展性和理解性問題。雖然可透過分層和事件過濾來解決一些問題，但可能導致複雜性增加。
### 3.6.2 C2
C2架構風格旨在通過結合事件驅動整合和分層客戶端-伺服器，實現大粒度重用和靈活組合的系統組件支援。它通過異步通知和請求消息來實現組件間通信，從而實現了對較高層的鬆散依賴和與較低層的零耦合，從而提高了系統的控制。通過引入分層的消息過濾，C2解決了事件驅動整合的可擴展性問題，同時提高了可演化性和可重用性。重型連接器可以提升可見性並減少部分失敗的可靠性問題。
### 3.6.3 Distributed Objects
分佈式對象風格將系統組織為一組以對等方式交互的組件，每個組件被視為對象，封裝了狀態信息和操作。對象的操作可以調用其他對象的操作，形成一個操作鏈。狀態分佈在各個對象之間，這可以使狀態保持最新，但也可能降低整體系統活動的可見性。分佈式對象系統的核心問題包括對象管理、對象交互管理和資源管理。該風格有助於實現組件的重用、隔離和可演化性，但可能需要考慮身份變更對組件間互動的影響。
### 3.6.4 Brokered Distributed Objects
為了減少身份的影響，現代分佈式對象系統通常使用中介風格來促進通信，如事件驅動整合和代理式客戶端/伺服器。代理式分佈式對象風格引入名稱解析器組件，以回答客戶端的通用服務名稱請求，但額外的間接層可能降低效率。代理式分佈式對象系統在CORBA和ODP等標準下得到廣泛應用。然而，與其他基於網絡的架構風格相比，分佈式對象在效能方面表現不佳。它們更適合涉及遠程調用封裝服務的應用，例如硬件設備。
### 3.7 Limitations
每種架構風格都促進特定元件間的互動。在分佈式超媒體系統中，網路使用會影響應用可用性。但分類方法有限制：1. 僅適用於特定需求，建議針對不同通訊問題創建分類；2. 特性分組可細化，也可保持抽象。此初始調查為未來分類奠定基礎，可解決這些限制。
## 3.8 Related Work
### 3.8.1 Classification of Architectural Styles and Patterns
本章研究關於架構風格和架構級模式的識別和分類。研究人員針對不同架構風格提出分類，然而這些分類可能未能有效協助應用設計。其他分類方法則注重模式的抽象程度、功能和結構原則。雖然一些分類方法有相似之處，但各有限制，可能尚需進一步發展以提高應用價值。
### 3.8.2 Distributed Systems and Programming Paradigms
Andrews [6] 調查分布式程式中的進程通過訊息傳遞如何互動，描述了不同進程類型、互動範式和通訊通道。Sullivan 和 Notkin [126] 探討隱式調用研究，Barrett 等人 [8] 綜述事件整合，Rosenblum 和 Wolf [114] 探討網際網路事件通知設計。Fuggetta 等人 [50] 分類移動程式碼範式，本章基於他們工作，將其與其他網絡風格進行比較，放置於單一架構中。
3.8.3 Middleware
### 3.8.3 Middleware
Bernstein [22]將中介軟體定義為分散式系統服務，提供標準程式介面和協議。中介軟體位於作業系統和應用程式之間，影響系統架構。Garlan等人 [56] 指出現成元件的架構假設，分為元件性質、連接器性質、全局架構和構建過程四大類。
## 3.9 Summary
本章在一個分類框架內，對基於網絡的應用軟體常見的架構風格進行了調查，根據應用於典型網絡超媒體系統的架構，評估每種風格所引起的架構特性。整體分類如下表 3-6 所述。

下一章將利用此調查和分類所獲得的見解，提出一些假設方法，以引導現代萬維網架構的改進設計和評估。