Web基礎架構設計原則經典論文《架構風格與基於網路的軟體架構設計》導讀

1. 概述

Roy Fielding博士（見個人首頁）是IETF發布的HTTP和URI協議的主要設計者。HTTP和URI是兩個最為重要的Web基礎技術架構協議，因此Fielding博士可謂是Web架構的奠基者之一。

除了學術上的卓越成就之外，Fielding博士還參與過很多開源軟體的設計和開發工作。他是libwww-perl（世界上最早的HTTP開發庫之一）的開發人員，曾經負責Apache HTTP伺服器中與HTTP、URI協議相關部分代碼的開發。Fielding博士還指導過很多其他團隊在HTTP用戶端和伺服器端軟體方面的開發工作。

HTTP/1.1協議（RFC 2616）於1999年發布，加上於1998年發布的URI協議（RFC 2396），至此Web的基礎技術架構已經完全確立。為了向世人詳細說明Web基礎技術架構背後的設計原則，Fielding在2000年撰寫了自己的著名博士學位論文《Architectural Styles and the Design of Network-based Software Architectures》。這篇論文的中文版名為《架構風格與基於網路的軟體架構設計》，可以從InfoQ中文站上下載：

這篇論文很不容易讀懂，作為論文中文版的譯者，筆者試圖在這篇導讀中為讀者梳理出一個閱讀的脈絡。不過筆者還是希望讀者能克服困難，親自去讀一下這篇論文，因為這篇論文實在是太精彩了。《論語》有很多評註版本，但是讀者最好還是自己親自讀一下《論語》原作，免得上了朱熹之流歪嘴和尚的當。下面我們進入正題。

2. 論文導讀

Fielding博士論文一共包括了緒論和6章本文的內容。緒論的內容就是對6章本文的總結，不需要多說，以下分別對6章本文的每一章進行導讀。

2.1 第1章——軟體架構

在第1章中，Fielding重新定義了一套研究軟體架構的術語，討論了每個術語定義的由來，並且將這些術語與相關研究進行比較。Fielding還對其他軟體架構研究者的一些相關研究進行了點評。

這些軟體架構術語包括：軟體架構、架構元素、組件、連接器、資料、配置、架構屬性、架構風格。以下是Fielding重新給出的術語定義：

軟體架構是一個軟體系統在其操作的某個階段的運行時（run-time）元素的抽象。一個系統可能由很多層抽象和很多個操作階段組成，每層抽象和操作階段都有自己的軟體架構。

軟體架構由一些架構元素（組件、連接器和資料）的配置來定義，這些元素之間的關係受到約束，以獲得想要得到的一組架構屬性。

組件是軟體指令和內部狀態的一個抽象單元，通過其介面提供對資料的轉換能力。

連接器是對組件之間的通訊、協調或合作進行仲裁的一種抽象機制。

資料是組件通過連接器接收或發送的資訊元素。

配置是在系統的運行期間組件、連接器和資料之間的架構關係的結構。

軟體架構的架構屬性集合包括了對組件、連接器和資料的選擇和排列所導致的所有屬性。架構屬性是由架構中的一組約束所導致的。

架構風格是一組相互協作的架構約束，這些約束限制了架構元素的角色和功能，以及在任何一個遵循該風格的架構中允許存在的元素之間的關係。

Fielding在將自己的術語定義與相關研究進行比較的過程中，對於一些相關研究提出了批評。例如：

“一些相關的研究完全不關注軟體在運行時的特性，而只關注軟體靜態原始碼中的結構特性。”

Fielding將這些研究者的研究內容稱作“軟體結構”，他不認為這是嚴格意義上的“軟體架構”。Fielding明確指出軟體架構是軟體在運行時的特性，他說：

“我們將軟體架構和原始碼結構分離開來，是為了更好地關注軟體的運行時特性，這些特性不依賴於一個特定的組件實現。因此，儘管架構的設計和原始碼結構的設計關係密切，它們其實是分離的設計活動。”

關注軟體在運行時的特性，是Fielding的軟體架構研究方法與其他研究者明顯的不同之處。在對架構元素定義的討論中，Fielding進一步解釋了這個差別。按照他的說法，軟體架構就好像是大樓的架構，而軟體結構則好像是大樓的設計圖紙。假如大樓的設計圖紙丟失了，大樓並不會立即倒塌，因此不能將大樓的設計圖紙看作是大樓的架構本身。同樣地，不應該將畫在紙面上的方框直線圖（例如常見的ER圖）看作是軟體架構本身，那樣會導致嚴重的紙上談兵，即僅僅根據繪製在紙面上的方框直線圖來研究軟體架構，其實這些圖形只代表了存在於軟體原始碼中的靜態軟體結構。

Fielding批評說：

“在這個過程中，軟體架構被簡化為通常在大多數非形式化的架構圖表中能夠看到的東西：方框（組件）和直線（連接器）。資料元素和其他很多真實軟體架構的動態方面都被忽略了。這樣的一個模型是不足以描述基於網路的軟體架構的，因為對於基於網路的應用而言，資料元素在系統中的位置和移動常常是系統行為唯一至關重要的決定因素。”

（譯者註：在UML中，除了靜態類圖之外，還有時序圖、狀態圖、活動圖表等等來表現各種動態行為。但是在Fielding的博士論文研究期間，UML規範尚未完全穩定下來。）

在所有的軟體架構研究者中，Fielding首次提出了軟體的架構風格這樣一個非常重要的概念，並且將軟體架構風格當作是“一種用來對架構進行分類和定義它們的公用特徵的機制。”

對於國內的軟體架構研究者來說，架構風格是一個全新的概念。國內的軟體架構研究者很少有人從架構風格這樣高的抽象層次來思考軟體的架構設計，幾乎全部都是針對某種特定的架構來討論。那麼架構風格與特定架構是一種什麼關係呢？

簡單來說，架構風格與特定架構相比是更高層次的抽象。做一個不是很恰當的類比：假如將架構風格看作物件導向設計中的介面，那麼特定的架構就是介面的實作類別。例如：“分布式對象”是一種架構風格，而CORBA、DCOM、EJB、.NET Remoting都是分布式對象這種架構風格的架構執行個體。雖然它們四者之間存在著很多差別，但是它們其實屬於同一種架構風格。

一種架構風格是由一組架構約束組成的，當將這組架構約束應用於某種特定的架構時，會產生出一些架構屬性。這些架構約束和架構屬性正是判斷某種架構風格是否適合於一種特定運行環境的關鍵。

在討論了上述這些軟體架構術語之後，Fielding接下來討論了模式和模式語言、架構視圖，這兩部分也很有趣。

在對模式和模式語言的討論中，Fielding指出：

“如同軟體的架構風格一樣，軟體模式的研究也偏離了其在建築架構中的起源。”

他追根溯源地剖析了建築學中模式語言的創造者Alexander大師(Jeffrey Charles Alexander)發明模式語言的本意。Fielding說：

“其實，Alexander的模式概念的核心並非是對於重複出現的架構元素的排列，而是發生在一個空間內重複出現的事件（人類的活動和情緒）的模式。Alexander還理解到：事件的模式不能脫離於發生這些事件的空間。”

架構視圖代表的是對於特定架構的不同觀察角度，Fielding說：

“觀察一種架構，除了可從系統中的多個架構及組成這些架構的多種架構風格的角度之外，還有可能從很多其他的角度來觀察。Perry和Wolf描述了三種重要的軟體架構視圖：處理、資料、串連。處理視圖側重於流過組件的資料流，以及組件之間串連的那些與資料相關的方面。資料檢視側重於處理的流程，而不是連接器。串連視圖側重於組件之間的關係和通訊的狀態。”

Fielding在後面論文的第5章中，正是使用了這三種視圖來描述REST架構風格。不過在第5章中，三種視圖的名稱略有變化，處理（processing）視圖變成了過程（process）視圖、串連（connection）視圖變成了連接器（connector）視圖。

在第1章剩餘的內容中，Fielding回顧了其他軟體架構研究者的一些相關研究工作，並且對這些研究工作進行了點評。筆者注意到，這一部分並沒有提到UML相關的研究工作。在筆者看來，儘管UML對於軟體架構研究確實非常重要，但是UML其實只是一個溝通工具，UML的圖形本身並不能教會設計者如何設計軟體的架構（會畫UML圖 != 會設計複雜的軟體架構）。另外UML的研究工作和Fielding的研究工作是並行的，Fielding可能並不瞭解UML同時取得的進展。