2.1 传统体系架构

1.传统软件的体系架构

早期的程序以语句为基本单位，由语句组成模块，通过模块的聚集和嵌套形成层层调用的程序结构，这就是最初的软件体系结构。由于结构化程序设计时代程序规模不大，通过强调结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以，并未特别研究软件体系结构。这个阶段的应用程序都把操作的数据、用户的接口及所有业务逻辑的处理都混杂在一个可以执行的包中。

这种结构现在仍然被大量使用，因为它只需要少量的开发队伍和较短的开发周期。但它的适用前提是规模较小、系统复杂度较低的系统。一方面，它的简单性会减少开发时间；另一方面，由于它的简单化处理会导致如下一些问题：可重用性差，由于软件在特定平台下为特定的应用而写，所以不能被其他应用所重用；可维护性差，不同目的的程序交杂在一起，一个地方的改动会影响到系统的其他地方；系统集成性较差，不同平台上的系统在集成时需要在两者之间专门构造集成系统，时间和成本较高。

2.基于组件的体系架构

随着系统复杂度和规模的大幅度增加，基于组件的体系结构应运而生。组件是具有一定的功能，能够独立工作或能同其他组件装配起来协调工作的程序体。从抽象程度来看，面向对象技术已达到了类级重用，它以类为封装单位。但是这样的重用粒度还太小，不足以解决异构互操作和效率更高的重用。组件将抽象的程度提到一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。整个组件隐藏了具体的实现，只用接口提供服务。随着独立组件的出现，软件的架构出现了多层的概念，其中经典的三层架构把应用程序从下到上基本划分为数据层、逻辑层和表示层。功能独立的各层可以重用它们需要的组件，从而使生产率大大提高。

比较流行的组件模型主要有CORBA和COM，然而，由于组件很难在异构系统得到使用，如在Java程序中调用COM对象，如果跨过防火墙调用一个外部远程对象就更加困难了，使其应用产生了很大的局限性。如果要在组织内部的所有异构系统中公用业务逻辑，或者跨过防火墙和外部合作伙伴信息共享，就必须解决两个问题。首先，各基于组件的应用程序有共同的交互语言，其次，摒弃数据细节、过程细节和组件细节的互操作方式，必须从更高的一个层次上来考虑如何交互，这就需要采用面向服务体系架构。

图2-1 奠基式向上支撑的平台架构

传统的系统体系结构是一种奠基式向上支撑的架构，其平台架构如图2-1 所示。是一种紧耦合的面向系统的体系架构，也称为钢性架构，这种架构是十分脆弱的，也就是在这种体系架构下开发的系统不牢固，同时容易形成信息孤岛。即使在统一平台开发出的系统之间也只能做到数据共享而不能做到功能共享。