REST论文中文版：Web架构基石

5星 · 超过95%的资源需积分: 17 75 浏览量更新于2024-07-24 1 收藏 792KB PDF 举报

"REST论文中文版是由Roy Thomas Fielding博士撰写的一篇关于网络软件架构设计的重要论文，该论文深入探讨了软件架构的各个方面，特别是与现代互联网协议如HTTP和URI密切相关的设计原则。Fielding博士是这些Web架构标准的关键设计者，他的工作奠定了Web架构的基石。这篇论文的中文译本由李锟、廖志刚、刘丹和杨光等译者合作完成，他们分别是Ajaxcn.org网站站长、91yee翻译社区负责人、Matrix技术社区负责人和《重构与模式》译者，他们在获得Fielding博士的授权后进行了翻译。论文的版权归属包括原作者和译者，强调了未经许可不得全文或部分转载的重要性。论文本身分为多个章节，包括软件架构的运行时抽象、组件、连接器、数据处理、配置管理、属性定义、风格区分、模式和模式语言以及相关的工作讨论。作者引用了设计方法学的不同流派，比如设计哲学、模式和模式语言手册，并对比了参考模型和领域特定的软件架构。译者们发起这项翻译工作，旨在让国内读者能够了解REST架构背后的原理，从而推动Web开发效率和创新。除了主要译者外，还有来自新浪公司的田乐、丁舜佳和梁晓星等人的贡献，以及多位国内专家的审阅和建议，确保了译文的准确性和质量。这篇论文不仅是Web架构理论的基石，也是实践者理解和设计高效网络应用的指南，对于IT专业人士和Web开发者来说具有很高的价值。"

第 1 章软件架构 14

软件架构的不同方面，一种特定的架构可能是由多种架构风格组成的。同样地，能够通过将

多种基本风格组合为单个的协作风格来形成一种混合风格。

一些架构风格常常被描述为适合于所有形式的软件的“银弹”式解决方案。然而，一个

好的设计师应该选择一种与正在解决的特定问题最为匹配的风格[119]。为一个基于网络的应

用选择正确的架构风格必须要理解该问题领域[67]，因此需要了解应用的通信需求，知道不

同的架构风格和它们所导致的特殊问题，并且有能力根据基于网络的通信的特性来预测每种

交互风格的敏感度[133]。

不幸的是，使用术语“风格”来表达一组协作的约束常常会令人困惑。这种用法与“风

格”一词在词典中的用法有很大的不同，后者强调设计过程的个性化。Loerke [76]专门用了

一章来贬低在一个专业建筑师的工作中应该为个性化风格保留位置的想法。相反地，他将风

格描述为批评家对于过去架构的视图，即应该由可选择的原料、社区的文化、本地统治者的

自尊心等等因素来负责架构的风格，而不是由设计者来负责。换句话说，Loerke 认为在传统

的建筑架构中，风格的真正来源是一组应用在设计上的约束，达到或复制一种特定的风格应

该是设计者的最低的目标。由于将一组已命名的约束称作一种风格，使得对公共约束的特征

进行沟通变得更加容易，我们将架构风格用作一种进行抽象的方法，而不是代表一种个性化

的设计。

1.6

模式和模式语言

在进行架构风格的软件工程研究的同时，面向对象编程社区一直在基于对象的（object-

based）软件开发领域探索如何使用设计模式和模式语言来描述重复出现的抽象。一种设计

模式被定义为一种重要的和重复出现的系统构造。一种模式语言是一个模式的系统，以一种

对这些模式的应用加以指导的结构来进行组织[70]。设计模式和模式语言的概念都基于

Alexander 等人的著作[3, 4]中关于建筑架构的内容。

模式的设计空间（design space）包括了特定于面向对象编程技术的实现关注点，例如

类继承和接口组合，以及架构风格所带来的高层次的设计问题[51]。在一些情况下，架构风

格的描述也被称作架构模式（architectural patterns）[120]。然而，模式的一个主要的优点是

它们能够将对象之间的相当复杂的交互协议描述为单个的抽象[91]，其中既包括行为的约束，

也包括实现的细节。总的说来，一种模式或由多种模式集成在一起的模式语言能够被看作是

实现对象之间的一组预期交互的方法。换句话说，一种模式通过遵循一种固定的设计和实现

选择（implementation choices）路径，定义了一个解决问题的过程[34]。

如同软件的架构风格一样，软件模式的研究也偏离了其在建筑架构中的起源。其实，

Alexander 的模式概念的核心并非是对于重复出现的架构元素的排列，而是发生在一个空间

内重复出现的事件（人类的活动和情绪）的模式。Alexander 还理解到：事件的模式不能脱

离于发生这些事件的空间[3]。Alexander 的设计哲学是，识别出目标文化（target culture）中

公共的生活模式（pattern of life），确定哪些架构约束对于以下目的是必需的，即，对可以

使期望的模式自然地产生的特定空间加以区分。这些模式存在于多个层次的抽象和所有的规

模中。

作为世界上的一个元素，每种模式都是在特定环境中的一种关系，是在那个环境中重复

出现的一种特定的力学系统。并且存在一种特定的空间配置，允许系统中的这些力量

（forces）为自己求解，相互支持，达到一种稳定的状态。

作为语言的一个元素，一种模式是一种指导，显示出这种空间配置如何能够一次又一次

的被使用，来为特定的力学系统求解，无论在哪里存在着使其产生的环境。

模式，简而言之，既是在世界上存在的一件事物，又是关于如何创建这件事物，以及何

时我们必须要创建它的规则。它既是一个过程也是一件事物；既是对一个活着的事物的描述，

第 1 章软件架构 15

也是对生成这个事物的过程的描述[3]。

在很多方面，与面向对象编程语言（OOPL）研究中的设计模式相比，Alexander 的模式

实际上与软件架构风格拥有更多的共同点。一种架构风格，作为一组协作的约束，应用于一

个设计空间，以求促使一个系统出现所期望的架构属性。通过应用一种风格，一个架构师是

在区分不同的软件设计空间，希望结果更好地匹配应用中所固有的一些必需满足的先决条件，

这会导致系统行为增强了自然的模式（natural pattern），而不是与之相冲突。

1.7

视图

一种架构视图常常是特定于应用的，并且基于应用的领域而千变万化……我们已经看到

架构视图解决了很多的问题，包括：与时间相关的问题（temporal issues）、状态和控制

方法、数据表述、事务生命周期、安全保护、峰值要求和优雅降级（graceful

degradation）。无疑，除了上述的这些视图，还存在着很多可能的视图。[70]

除了从一个系统中的很多架构，以及组成架构的很多架构风格的角度来观察以外，也有

可能从很多不同的角度来观察一个架构。Perry 和 Wolf [105] 描述了三种重要的软件架构视

图：处理、数据、连接。处理视图侧重于流过组件的数据流，以及组件之间连接（the

connections among the components）的那些与数据相关的方面。数据视图侧重于处理的流程，

而不是连接器。连接视图侧重于组件之间的关系和通信的状态。

多种架构视图在特定架构的案例研究中是司空见惯的[9]。一种架构设计方法学，4+1 视

图模型[74]，使用了 5 种协作的视图来对软件架构的描述加以组织。每种视图致力于解决一

组特定的关注点。

1.8

相关工作

我只在这里包括了那些定义软件架构或者描述软件架构风格的研究领域。其他的软件架

构研究领域还包括架构分析技术、架构的恢复与再造（re-engineering）、架构设计的工具和

环境、从规范到实现的细化、以及部署软件架构的案例研究[55]。有关风格的分类、分布式

过程范例、以及中间件，这些领域的相关工作会在第 3 章中进行讨论。

1.8.1 设计方法学

大部分早期的软件架构研究都集中在设计的方法学（design methodologies）上。例如，

面向对象设计[25]提倡以一种结构化的方式来解决问题，能够自然地导致基于对象的架构

（或者，更确切地说，不会导致任何其他形式的架构）。最早从架构层面上强调设计的设计

方法学之一是 Jackson 系统开发方法（JSD）[30]。JSD 有意将对于问题的分析结构化，这样

能够导致一种组合了管道和过滤器（数据流）风格和过程控制约束（process control

constraints）风格的架构风格。这些设计方法学通常只会产生一种架构风格。

人们对架构分析和开发的方法学进行了一些初步的研究。Kazman 等人使用 SAAM[68]

和 ATAM[69]的架构权衡（trade-off）分析，通过基于场景的分析对用来识别出架构的方面

（architectural aspects）的设计方法进行了描述。Shaw [119]比较了一个汽车导航控制系统的

多种不同的方框箭头（box-and-arrow）设计，每一种设计都使用了一种不同的设计方法学并

包括了多种架构风格。

1.8.2 设计、设计模式、模式语言手册

在与传统的工程学科保持一致的同时，Shaw[117]提倡对于架构手册的开发。面向对象

编程社区率先开发了设计模式的目录，例子包括“四人帮”的书籍[51] 、Coplien 和 Schmidt

第 1 章软件架构 16

[33] 的文章。

软件设计模式比架构风格更加倾向于面向特定的问题（problem-oriented）。Shaw [120]

基于在[53]中描述的架构风格，提出了 8 个架构模式的例子，还包括了最适合于每一种架构

的问题种类。Buschmann 等人[28] 对架构模式进行了与基于对象开发（object-based

development）相同的全面的检查。这两份参考资料都是纯粹描述性的，并没有试图去比较

或者展示架构模式之间的区别。

Tepfenhart 和 Cusick [129] 使用了一张二维地图来区分领域分类学、领域模型、架构风

格、框架、工具包、设计模式、以及应用软件。在这张拓扑图中，设计模式是预先设计的结

构，用作软件架构的的建造块（building block），而架构风格则是用来识别独立于应用领域

的一种架构家族的一组操作特征。然而，它们都未能成功地定义架构本身。

1.8.3 参考模型和特定于领域的软件架构

研究者们开发出来了各种参考模型，为描述架构和显示组件之间的相互关系提供了概念

框架[117]。OMG[96]开发了对象管理架构（OMA），作为代理式的分布式对象架构

（brokered distributed object architectures）的参考实现，详细说明了如何定义和创建对象、客

户端应用如何调用对象、如何共享和重用对象。其重点是在分布式对象的管理方面，而不是

在应用中的高效的交互方面。

Hayes-Roth 等人[62] 将特定于领域的软件架构（DSSA）定义为由以下部分组成：a) 一

种参考架构，为一个重大的应用领域描述了一种通用的概念框架。b) 一个包含了可重用的领

域专家知识的组件库。c) 一种应用的配置方法，为满足特殊应用的需求的架构选择和配置组

件。Tracz [130] 提供了一个 DSSA 的概要描述。

DSSA 项目通过将软件开发空间限制到一个满足某个领域的需求的特定的架构风格，成

功地将架构决策转移到了正在运行的系统之中[88]。DSSA 的例子包括：用于航空电子学的

ADAGE [10]，用于自适应智能系统的 AIS [62]，用于导弹导航、航海、以及控制系统的

MetaH [132]。DSSA 更强调在一个公共的架构领域中的组件的重用，而不是对特定于每一个

系统的架构风格的选择。

1.8.4 架构描述语言

最近发布的与软件架构有关的工作大多都是在架构描述语言（ADL）的领域里。根据

Medvidovic 和 Taylor [86]的定义，一种 ADL 是一种为明确说明软件系统的概念架构和对这

些概念架构建模提供功能的语言，至少包括以下部分：组件、组件接口、连接器、以及架构

配置。

Darwin 是一种声明式（declarative）的语言，它旨在成为一种通用的表示方法，来详细

描述由使用不同交互机制的不同组件组成的系统的结构[81]。Darwin 的有趣之处在于，它允

许详细描述分布式架构（distributed architectures）和动态组合架构（dynamically composed

architectures）[82]。

UniCon [118]是一种语言和相关的工具集，用来将一组受到限制的组件和连接器组合为

一个架构。Wright [5] 通过根据交互的协议来指定连接器的类型，为描述架构组件之间的交

互的提供了形式化的基础。

如同设计方法学一样，ADL 经常引入一些特定的架构假设，这些假设有可能会影响到

该语言描述一些架构风格的能力，并且可能会与存在于现有中间件中的假设相矛盾[38]。在

一些情况下，一种 ADL 是专门为单一架构风格而设计的，这样以来就需要以丧失通用性为

代价，增强它在专业化的描述和分析方面的能力。例如，C2SADEL[88]是一种为了描述以

C2 风格开发的架构而专门设计的 ADL[128]。与之相反，ACME [57]是一种试图尽量通用的

第 1 章软件架构 17

ADL，但是它所做的权衡就是，它不支持特定于风格的分析和建造实际的应用，而是聚焦于

分析工具之间的交换。

1.8.5 形式化的架构模型

Abowd 等人[1]声称，根据少量的一组从架构描述的语法领域（方框直线图）到架构含

义的语义领域的映射，就能够形式化地描述架构风格。然而，他们所做的假设是：架构就是

描述，而不是对于一个正在运行的系统的一种抽象。

Inverardi 和 Wolf [65] 使用化学抽象机（CHAM）的表达形式，将软件架构元素建模为

化学物品，在这些元素之上发生的反应受到了明确说明的规则的控制。它根据组件如何转换

可用的数据元素，以及如何使用组合规则将单个转换传播到整个系统结果中，来指定组件的

行为。尽管这是一个很有趣的模型，有一点仍然不明确：如何使用 CHAM 来描述任何一种

其目的超出了转换一个数据流的架构形式。

Rapide [78]一种专门为定义和模拟系统架构而设计的并行的、基于事件的模拟语言。模

拟器生成一组部分排序的（partially-ordered）事件，这些事件能够被用来分析内部连接之上

的架构约束的一致性。Le Métayer[75]提出了一种根据图和图的语法来定义架构的表达形式。

1.9

小结

本章检查了本论文的背景。引入并形式化了一组一致的软件架构概念术语，这些术语对

于避免出现文献中常见的架构和架构描述之间的混淆来说是必需的，特别是在早期的架构研

究中往往未将数据作为一个重要的架构元素。最后我调查了与软件架构和架构风格相关的其

他的一些研究。

后面两章通过聚焦于基于网络的应用的架构，来继续我们对于背景材料的讨论，并且描

述如何使用风格来指导它们的架构设计，然后使用一种分类方法学（classification

methodology）来调查公共的架构风格，这种分类方法学侧重于架构的属性，这些属性是当

风格被应用于一个基于网络的超媒体架构时所导致的。

剩余83页未读，继续阅读

青鸟天空

粉丝: 190
资源: 22

REST论文中文版：Web架构基石

Roy Thomas Fielding博士论文REST(中文版)

REST翻译中文论文

REST论文中文版：理解互联网WEB开发的关键

网络软件架构设计：REST风格中文翻译

Fielding博士REST架构风格博士论文中文修订版

REST架构博士论文中文版：Web架构基石详解

REST标准奠基人Fielding博士论文中文版解析

REST设计中文版：Web架构基石翻译

REST架构风格：网络软件设计的博士论文翻译

REST架构风格与网络软件设计——Fielding博士论文中文版

最新资源