在第一章中，Fielding定义了一套研究软件架构的术语。讨论了每个术语定义的由来，或者将该术语与相关的研究进行比较。
这些软件架构术语包括：软件架构、元素、组件、连接器、数据、配置、架构属性、架构风格等等。作者在将自己的定义与相关研究进行比较的过程中，对于一些相关的研究提出了批评。例如：
一些相关的研究完全不关注软件在运行时的特性，而只关注软件静态的源代码中的结构特性。Fielding将这些人研究的内容称作“软件结构”，不认为这是严格意义上的软件架构。在Fielding所给出的软件架构定义中，明确指出软件架构是软件在运行时的特性。
“一个软件架构是一个软件系统在其操作的某个阶段的运行时（run-time）元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成，每个抽象和操作阶段都有自己的软件架构。”
Fielding还说：
“我们将软件架构和源代码结构分离开来是为了更好的关注软件运行时的特性，这些特性不依赖于一个特定的组件实现。因此，尽管架构的设计和源代码结构的设计关系密切，它们其实是分离的设计活动。”
关注软件运行时的特性，是Fielding的软件架构研究和其他研究者明显的不同之处。在对架构元素定义的讨论中，Fielding进一步解释了这个差别。软件架构就好像是大楼的架构，而软件结构则好像是大楼的设计图纸。大楼的设计图纸并不是大楼的架构本身。大楼的设计图纸丢失了，大楼并不会立即倒塌。不应该将大楼的设计图纸看作是大楼的架构本身。同样地，不应该将画在纸面上的方框直线图看作是软件架构本身，那样会导致严重的纸上谈兵，即仅根据绘制在纸面上的方框直线图来研究所谓的软件架构（其实只代表了存在于软件源代码中的静态的软件结构）。
Fielding批评说：
“在这个过程中，软件架构被简化为通常在大多数非形式化的架构图表中能够看到的东西：方框（组件）和直线（连接器）。数据元素和其他很多真实软件架构的动态方面都被忽略了。这样的一个模型是不足以描述基于网络的软件架构的，因为对于基于网络的应用而言，数据元素在系统中的位置和移动常常是系统行为唯一至关重要的决定因素。”
Fielding还提出了软件架构风格这样一个非常重要的概念：
“一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。”
并且将软件架构风格当作“一种用来对架构进行分类和定义它们的公共特征的机制。”
对于国内的软件架构研究者来说，软件的“架构风格”是一种全新的概念。国内的软件架构研究者很少有能力从软件“架构风格”的抽象层次来思考软件架构的设计，几乎全部都是针对某种特定的架构来讨论。那么软件的“架构风格”与软件的架构是一种什么关系呢？
简单来说，软件的架构风格与软件的架构相比是更高层次的抽象。如果将软件的架构风格比作面向对象编程中的接口或者抽象类的话，那么某种具体的软件架构就相当于接口或抽象类的实现类。举个例子：“分布式对象”是一种架构风格，而CORBA、DCOM、EJB都是分布式对象这种架构风格的架构实例。虽然它们之间存在着很多差别，但是它们其实属于同一种架构风格。
架构风格由一组架构约束组成，当将这组架构约束应用于某种具体的架构实例时，会导致一些特定的架构属性。这些架构约束和架构属性正是判断某种架构风格是否适合于一种特定运行环境的关键。
第一章的主要内容就是，在总结和批判前人经验的基础上，提出了Fielding本人对于软件架构的研究方法和一些具有鲜明个性的观点。
发表于 @ 2007年12月08日 19:21:00|评论(loading...)|编辑