软件体系结构基础

halo~我是bay_Tong桐小白
本文内容是桐小白个人对所学知识进行的总结和分享，知识点会不定期进行编辑更新和完善，了解最近更新内容可参看更新日志，欢迎各位大神留言、指点

【更新日志】

最近更新：

• 暂无编辑记录，持续更新中……

软件体系结构基本概念

软件体系结构

目前还没有一个公认的关于软件体系结构的定义

Bass、Clements和Kazman给出了如下定义：“一个程序或计算机系统的软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件、构件的外部可见属性以及它们之间的相互关系。外部可见属性则是指软件构件提供的服务、性能、使用特性、错误处理、共享资源使用等。”
【这一定义强调在任一体系结构表述中“软件构件”的角色】

构件：是面向软件体系架构的可复用软件模块。构件是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块、软件框架、软件构架（或体系结构）、文档、分析件、设计模式等

Dewayne Perry和A1exander Wo1f曾这样定义：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。

• 处理构件负责对数据进行加工
• 数据构件是被加工的信息
• 连接构件把体系结构的不同部分组合连接起来

【这一定义注重区分处理构件、数据构件和连接构件】

在体系结构设计的环境中，软件构件可以简单到程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的中间件

体系结构设计是一系列决策和基本原理的集合，这些决策的目标在于开发高效的软件体系结构。在体系结构设计中所强调的基本原理是系统的可理解性、可维护性和可扩展性

体系结构的模式、风格、框架

模式： 软件设计模式是从软件设计过程中总结出来的，是针对特定问题的解决方案

建筑师C.Alexander对模式给出的经典定义是：每个模式都描述了一个在我们的环境中不断出现的问题及该问题解决方案的核心

在软件系统中可以将模式划分为以下三类：

• 体系结构模式：表达了软件系统的基本结构组织形式或者结构方案，包干了一组预定义的子系统，规定了这些子系统的责任，同时还提供了用于组织组织和管理这些子系统的规则和向导。典型的体系结构模式如计算机网络结构模型——开放式系统互联参考模型（OSI参考模型）
• 设计模式：为软件系统的子系统、构件或者构件之间的关系提供一个精炼之后的解决方案，描述了在特定环境下，用于解决通用软件设计问题的构件以及这些构件相互通信时的各种结构。有代表性的设计模式是Erich Gamma及其同事提出的23种设计模式
• 惯用法：是与编程语言相关的低级模式，描述如何实现构件的某些功能，或者利用编程语言的特性来实现构件内部要素之间的通信功能

风格： 同一个问题可以有不同的解决问题的方案或模式，但我们根据经验，通常会强烈倾向于采用特定的模式，这就是风格。包括：

• 一组构件（比如数据库、计算模块）完成系统需要的某种功能
• 一组连接件，它们能使构件间实现通信、合作和协调
• 约束，定义构件如何集成为一个系统
• 语义模型，它能使设计者通过分析系统构成成分的性质来理解系统的整体性质

体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表（包含一些构件和连接件类型）和一组约束，这组约束指出系统是如何将这些构件和连接件组合起来。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组成一个完整的系统

框架 ：随着应用的发展和完善，某些带有整体性的应用模式被逐渐固定下来，形成特定的框架，包括基本构成元素和关系。框架是特定应用领域问题的体系结构模式，框架定义了基本构成单元和关系后，开发者就可以集中精力解决业务逻辑问题

在组织形式上，框架是一个待实例化的完整系统，定义了软件系统的元素和关系，创建了基本的模块，定义了涉及功能更改和扩充的插件位置。典型的框架例子有MFC框架和Struts框架

体系结构的重要作用

• 体系结构的表示有助于风险承担者（项目共利益者）进行交流
• 体系结构突出了早期设计决策，对随后的所有软件工程工作都具有深远的影响，对最终软件的质量和整个系统的成功都具有重要作用
• 软件体系结构是可传递和可复用的模型。体系结构的风格和模式可以在需求相似的其他系统中进行复用。体系结构级的复用粒度比代码级的复用粒度更大，由此带来的益处也就更大

通用模型

【通用模型可以应用于许多不同类型的系统。此部分选择有代表性的结构进行总结。体系结构的模式选择设计模式做阐述，风格选择典型的三种体系结构风格做阐述，框架选择MVC、J2EE、PCMEF与PCBMER框架做阐述】

设计模式概述（更新中……）

典型的体系结构风格

数据流风格

当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可以应用这种体系结构

管道/过滤器、批处理序列都属于数据流风格

管道/过滤器结构

管道/过滤器结构拥有一组被称为过滤器的构件，这些构件通过管道连接，管道将数据从一个构件传送到下一个构件。每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出。过滤器不需要了解与之相邻的过滤器的工作

管道/过滤器风格优点：

• 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点
• 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成
• 支持软件复用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来
• 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉
• 允许对一些如吞吐量、死锁等属性进行分析
• 支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行

管道/过滤器风格缺点：

• 通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换
• 不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重
• 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性

批处理序列结构

如果数据流退化成为单线的变换，则成为批处理序列。这种结构接收一批数据，然后应用一系列连续的构件（过滤器）变换它

调用/返回风格

该体系结构风格便于设计出易于修改和扩展的程序结构，此类结构存在3种子风格

主程序/子程序体系结构

这种传统的程序结构将功能分解为一个控制层次，其中“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件。如下图所示，这种结构总体上为树状结构，可以在底层存在公共模块

当主程序/子程序体系结构的构件分布在网络上的多个计算机上时，则称主程序对子程序的调用为远程过程调用。这种系统的目标是要通过将运算分布到多台计算机上来充分利用多台处理器，最终达到提高系统性能的目的

主程序/子程序体系结构的优点：

• 可以使用自顶向下，逐步分解的方法得到体系结构图，典型的拓扑结构为树状结构。基于定义-使用关系对子程序进行分解，使用过程调用作为程序之间的交互机制
• 采用程序设计语言支持的单线程控制

主要缺点：

• 子程序的正确性难于判断。需要运用层次推理来判断子程序的正确性，因为子程序的正确性取决于它调用的子程序的正确性
• 子系统的结构不清晰。通常可以将多个子程序合成为模块

面向对象风格

系统的构件封装了数据和必须应用到该数据上的操作，构件间通过消息传递进行通信与合作。与主程序/子程序的体系结构相比，面向对象风格中的对象交互会复杂一些

面向对象风格与网络应用的需求在分布性、自治性、协作性、演化性等方面具有内在的一致性

面向对象风格的优点:

• 因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他对象
• 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合

面向对象风格的缺点：

• 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象
• 必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的

杂项：

• OMG：对象管理组，于1989年由一些厂商创建，其目的是建立网络中分布式对象（组件）的标准结构。OMG组织是一个国际性的非盈利组织，其职责是为应用开发提供一个公共框架，制订工业指南和对象管理规范，加快对象技术的发展
• OMA：对象管理体系结构，由OMG于1990年提出，定义了软件系统参考模型，包括对象模型和参考模型两部分 OMA对象模型定义如何描述异质环境环境中的分布式对象 OMA参考模型描述对象之间的交互
• CORBA：公共对象请求代理体系结构，以对象管理体系结构（OMA）为基础，是由OMG组织制订的一种标准的面向对象应用程序体系规范。或者说CORBA体系结构是对象管理组（OMG）为解决分布式处理环境(DCE)中，硬件和软件系统的互连而提出的一种解决方案

层次结构风格

整个系统被组织成一个层次结构，每一层为上层提供服务，并作为下一层的客户

从外层到内层，每层的操作逐渐接近机器的指令集

• 在最外层，构建完成界面层的操作；
• 在最内层，构件完成与操作系统的连接；
• 中间层提供各种实用程序和应用软件功能

这种风格支持基于抽象程度递增的设计。允许将复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持

层次结构具有以下优点:

• 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解
• 支持功能增强，因为每一层至多和相邻的上下层交互，因此，功能的改变最多影响相邻的内外层
• 支持复用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，从而允许各种不同的实现方法

层次结构缺点如下:

• 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来
• 很难找到一个合适的、正确的层次抽象方法

仓库风格

数据库系统、超文本系统和黑板系统都属于仓库风格。在这种风格中，数据仓库（如文件或数据库）位于这种体系结构的中心，其他构件会经常访问该数据仓库，并对仓库中的数据进行增加、修改或删除操作

客户软件访问中心仓库。某下情况下仓库是被动的，也就是说，客户软件独立于数据的任何变化或其他客户软件的动作而访问数据，此方式相当于传统型数据库系统

该方式的一个变种是将中心存储库变换成“黑板”，黑板构件负责协调信息在客户间的传递，当用户感兴趣的数据发生变化时，它将通知客户软件

黑板系统的组成：

• 知识源：知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成
• 黑板数据结构：黑板数据是按照与应用程序相关的层次组织的、解决问题的数据，知识源通过不断地改变黑板数据来解决问题
• 控制：控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识

黑板系统的传统应用是信号处理领域（如语音和模式识别），另一应用是松耦合代理数据共享存取

黑板系统的优点：

• 对可更改性和可维护性的支持
• 可复用的知识源
• 支持容错性和健壮性

黑板系统的不足：

• 测试困难，黑板系统的计算没有依据确定的算法，其结果常常不可再现，此外，错误假设也是求解过程的组成部分
• 不能保证有好的求解方案，黑板系统往往只能正确解决所给任务的某一百分比
• 难以建立好的控制策略，控制策略不能以一种直接方式设计，而需要一种实验的方法
• 低效，黑板系统在拒绝错误假设中要承受多余的计算开销
• 昂贵的开发工作，绝大多数黑板系统要花几年时间来进化
• 缺少对并行机制的支持 ，黑板体系结构不能避免采用了知识源潜在并行机制的控制策略，但它不提供它们的并行执行，对黑板上中心数据的并发访问也必须是同步的

体系结构框架

模型-视图-控制器（MVC）

MVC框架即模型-视图-控制器（model-view-controller）框架，它强调将用户输入、数据模型和数据表示的方式分开设计，一个交互式应用系统由模型（model）、视图（view）和控制器（controller）3个部件组成，分别对应于内部数据、数据表示和输入/输出控制部分

• 模型对象（Model）：模型对象独立于外在显示内容和形式，代表应用领域中的业务实体和业务规则，是整个模型的核心。模型对象的变化通过事件处理通知视图和控制器对象
• 视图对象（View）：视图对象代表GUI对象，并且以用户需要的格式表示模型状态，是交互系统与外界的接口。视图对象可以包含子视图，子视图用于显示模型的不同部分。通常，每个视图对象对应一个控制器对象
• 控制器对象（Controller）：控制器对象代表鼠标和键盘事件。它处理用户的输入行为并给模型发送业务事件，再将业务事件解析为模型应执行的动作；同时，模型的更新与修改也将通过控制器来通知视图，从而保持各个视图与模型的一致性。

模型是核心数据和功能，视图只关心显示数据，控制只关心用户输入，这种结构由于将数据和业务规则从表示层分开，因此可以最大化地重用代码

J2EE体系结构框架（更新中……）

PCMEF与PCBMER框架（更新中……）

特定领域的软件体系结构

除通用模型外，对于特别的应用还需要特别的体系结构模型，虽然这些系统实例的细节会有所不同，但共同的体系结构在开发新系统时是能够复用的，这些体系结构模型称为领域相关的体系结构

类属模型

概念： 类属模型是从许多实际系统中抽象出来的一般模型，它封装了这些系统的主要特征

简单说可以理解为，类属模型将各种已经完成好的一般模型（也就是具有某一种小功能的组件）组合在一起，利用其它不同的结构进行联系和组织，完成具有某一特定领域的系统功能的实现，是一种综合性质的体系结构

典型用例： 类属模型的一个最著名的例子是编译器模型，由这个模型已开发出了数以千计的编译器。编译器一般包括以下模块：

• 词法分析器：将输入的语言符号转换成相应的内部形式
• 符号表：由词法分析器建立，保留程序中出现的名字及其类型信息
• 语法分析器：检查正被编译的语言语法。它使用该语言定义的文法来建立一棵语法树
• 语法树：是正被编译的程序在机器内部的结构表示
• 语义分析器：使用来自语法树和符号表的信息检查这个输入程序的语义正确性
• 代码生成器：遍历语法树并生成机器代码

构成编译器的组件可以依照不同的体系结构模型来组织，编译器能使用组合模型来实现。如总体上可采用数据流风格，并将符号表作为容器来共享数据

这个模型现在仍然被广泛使用，程序编译时没有用户交互的影响。但当编译器要与其它语言处理工具（如结构化的编辑系统、交互式调试器、高质量打印机等）集成时效率会很低，这种情形下一般系统组件可以使用基于容器（仓库）模型来组织

参考模型

概念： 参考模型源于对应用领域的研究，它描述了一个理想化的包含了系统应具有的所有特征的软件体系结构。它是更抽象且是描述一大类系统的模型，并且也是对设计者有关某类系统的一般结构的指导

典型用例： 典型的例子由国际化标准组织（ISO）与1978年提出的计算机网络结构模型——开放式系统互连参考模型（OSI）参考模型。它描述了开放系统互连的标准，如果系统遵从这个标准，就可以与其它遵从该标准的系统互连

PS： 以上两种不同类型的模型之间并不存在严格的区别。也可以将类属模型视为参考模型。

两者区别之一是类属模型可以直接在设计中复用，而参考模型一般是用于领域概念间的交流和对可能的体系结构做出比较；另外，类属模型通常是经过“自下而上”地对已有系统的抽象，而参考模型是“由上到下”地产生的

分布式系统结构

集中式计算与分布式计算

• 集中式计算技术：广泛使用的是大型机/小型机计算模型。这种计算模型几乎完全依赖于一台大型的中心计算机（称为宿主机）的处理能力，通过和它相连的非智能终端（用户设备，往往仅仅作为一台输入输出设备使用）来实现宿主机上的应用程序。在多用户环境中宿主机应用程序既负责与用户的交互，又负责对数据的管理，随着用户的增加，对宿主机能力的要求不断提高
• 分布式系统结构：20c80s之后集中式结构主要被以PC为主的微机网络所取代。网络上所有计算机都有处理能力，每个新加入的用户都对网络处理能力的提高有贡献，可以使用网上多台计算机来完成一个共同的处理任务。如果某一台计算机脱离了网络（发生故障或关机）对网上的其他用户不会有大的影响

分布式计算模型的优点

• 资源共享。分布式系统允许硬件、软件等资源共享使用
• 经济性。分布式计算性价比要高于集中式结构
• 性能与可扩展性。分布式应用程序能利用网络上可获得的资源，通过使用联合起来的多个网络结点的计算能力获得性能方面的提升
• 固有分布性。有些应用程序是固有分布式的，如遵循客户机/服务器模型的数据库应用程序
• 健壮性。大多数情况下网络上的一台机器或多处理器系统中的一个CPU的崩溃不会影响到系统的其余部分

多处理器体系结构

概念： 是分布式系统的一个最简单的模型，系统由许多进程组成，这些进程可以在不同的处理器上并行运行，可以极大地提高系统的性能

适用场合： 由于大型实时系统对响应时间要求较高，这种模型在大型实时系统中比较常见。大型实时系统需要实时采集信息，并利用采集到的信息进行决策，然后发送信号给执行机构。

客户机/服务器体系结构

概念： 客户机/服务器（client/server，C/S）体系结构是基于资源不对等，且为实现共享而提出来的，定义了工作站如何与服务器相连，以将数据和应用分布到多个处理机上

主要组成部分：

• 服务器：负责给其他子系统提供服务（如数据库服务器提供数据存储和管理服务，文件服务器提供文件管理服务，打印服务器提供打印服务等）
• 客户机：向服务器请求服务。客户机通常都是独立的子系统，在某段时间内，可能有多个客户机程序在并发运行
• 网络：连接客户机和服务器。通常客户机程序和服务器程序放在不同的机器上运行

在C/S体系结构中，客户机可以通过远程调用来获取服务器提供的服务，因此，客户机必须知道可用的服务器的名字及它们所提供的服务，而服务器不需要知道客户机的身份，也不需要知道有多少台服务器在运行

逻辑结构的三层划分： 在逻辑上，通常将应用系统划分为三层，即数据管理层、应用逻辑层、表示层

• 数据管理层：关注数据存储及管理操作，通常选择成熟的关系数据库管理系统来承担这项任务
• 应用逻辑层：关注与业务相关的处理逻辑
• 表示层：关注用户界面及与用户的交互

两层C/S体系结构

传统的C/S体系结构为二层的C/S体系结构。在这种体系结构中，一个应用系统被划分为客户机和服务器两部分

二层C/S体系结构可以有两种形态：

• 瘦客户机模型。即数据管理部分和应用逻辑部分都在服务器上执行，客户机只负责表示部分
• 胖客户机模型。服务器只负责对数据的管理，客户机实现应用逻辑和与系统用户的交互

胖客户机模型能够利用客户机的处理能力，比瘦客户机模型在分布处理上更有效。胖客户机的数据处理流程如下：

随着企业规模的日益扩大，软件复杂程度的不断提高，胖客户机模型逐渐暴露出缺点：

• 开发成本较高。C/S体系结构对客户端软硬件配置要求较高，增加了整个系统的成本
• 用户界面风格不一，使用繁杂，不利于推广使用
• 软件移植困难，采用不同工具或平台开发的软件，一般互不兼容，很难移植到其他平台上运行
• 软件维护和升级困难，由于应用程序安装在客户端，若软件需要维护则每台客户机上的软件均需要更新或升级

三层C/S体系结构

为了避免选择瘦客户机模型产生的伸缩性和性能的问题以及选择胖客户机模型产生的系统管理上的问题，产生了三层C/S体系结构。三层C/S体系结构中增加了一个应用服务器，可以将整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上

三层C/S体系结构在系统上与逻辑结构上相似，被划分为表示层、应用逻辑层、数据层三个部分

• 表示层：是应用程序的用户界面部分，担负着用户与应用程序之间的对话功能。它用于检查用户从键盘等输入的数据，显示应用程序输出的数据，一般采用图形用户界面（GUI）
• 应用逻辑层：应用逻辑层为应用系统的主体部分，包含具体的业务处理逻辑。通常在功能层中包含有确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能
• 数据层：数据层主要包括数据的存储及对数据的存取操作，一般选择关系型数据库管理系统（RDBMS）

三层C/S体系结构数据处理流程如下：

三层C/S结构具有的优点：

• 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性
• 允许更灵活有效地选用相应的平台和软件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性
• 应用的各层可以并行开发，可以选择各自最适合的开发语言
• 利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础

【PS：需注意的是三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，整体性能可能也会达不到要求。此外设计时必须慎重考虑三层间的通信方法、通信频度、数据量。这和提高各层的独立性一样是三层C/S结构的关键问题】

浏览器/服务器（B/S）体系结构

浏览器/服务器（B/S）风格是三层应用结构的一种实现方式

• 浏览器：也可以说是客户端，只有简单的输入输出功能，处理极少部分的事务逻辑。由于客户不需要安装客户端，只要有浏览器就能上网浏览，所以它面向的是大范围的用户，所以界面设计得比较简单，通用
• WEB服务器：扮演着信息传送的角色。当用户想要访问数据库时，就会首先向WEB服务器发送请求，WEB服务器统一请求后会向数据库服务器发送访问数据库的请求，这个请求是以SQL语句实现的
• 数据库服务器：当数据库服务器收到了WEB服务器的请求后，会对SQL语句进行处理，并将返回的结果发送给WEB服务器，接下来，WEB服务器将收到的数据结果转换为HTML文本形式发送给浏览器，也就是我们打开浏览器看到的界面

B/S体系结构主要利用WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上说B/S结构是一种全新的软件体系结构

B/S体系结构工作原理：

B/S体系结构具有的优点：

• 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级
• B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网和统一服务的最现实的开放性基础

B/S体系结构与C/S体系结构关系与区别：

B/S架构是从C/S架构改进而来，可以说是三层C/S架构，由此可见两者关系不一般。B/S从C/S中脱离而出，后来随着WEB技术的飞速发展以及人们对网络的依赖程度加深，B/S一举成为当今最流行的网络架构。两种架构都在各自岗位上虎虎生威，它们各有千秋，都是非常重要的网络架构。在响应速度，用户界面，数据安全等方面，C/S强于B/S，但是在业务扩展和适用www条件下，B/S明显胜过C/S。可以这么说，B/S的强项就是C/S的弱项，反之亦然。它们各有优缺点，相互无法取代。

C/S结构与B/S结构两种模式各自拥有其特色优势，在不同的系统环境与操作平台下，选择较为接近或交叉进行混合模式的使用，可以保证数据的敏感性、安全性和稳定发展，还可以加强对数据库的修改与新增记录的操作。对客户端程序进行保护，提高资源数据的交互性能，实现系统维护成本较低、维护方式较简便、布局更合理、网络数据使用效率较高的目的，采用C/S与B/S混合模式才是最佳方案

分布式对象体系结构

在B/S模型中客户机和服务器的地位是不同的，客户机必须要知道服务器的存在及其所提供的服务，而服务器则不需要知道客户机的存在，设计者必须决定服务在哪里提供，要规划系统的伸缩性，当有较多客户机增加到系统中时需要考虑如何将服务器上的负载分布开来。分布式系统设计旨在去掉客户机与服务器之间的差别。

分布式环境下，构件是一些灵活的软件模块，它们可以位置透明、语言独立和平台独立地互相发送消息，实现请求服务。构件之间并不存在客户机与服务器的界限，接受服务者扮演客户机的角色，提供服务者就是服务器

分布式对象的实质是在分布式异构环境下建立应用系统框架和对象构件，它将应用服务分割成具有完整逻辑含义的独立子模块（称为构件），各个子模块可放在同一台服务器或分布在多台服务器上运行，模块之间通过中间件互相通信

PS：传统通信方式与中间件通信方式

• 传统通信方式：通过一种集中管理式的固定的服务接口，或进行能力有限的远程过程调用，这种方式不仅开销大，也难于开发，要进行成功的软件系统集成也存在很多障碍
• 中间件通信方式：如硬件总线允许不同的卡插于其上以支持硬件设备之间的通信一样，通常将这个中间件称为软件总线或对象请求代理，它的作用是在对象之间提供一个无缝接口

分布式对象技术的应用目的是为了降低主服务器的负荷、共享网络资源、平衡网络中计算机业务处理的分配，提高计算机系统协同处理的能力，从而使应用的实现更为灵活

当前主流的分布式对象技术规范有：OMG的CORBA、Microsoft的.NET、Sun公司的J2EE等，它们均支持服务端构件的开发，都有各自的特点

代理

代理可以用于构建带有隔离组件的分布式软件系统，该软件通过远程服务调用进行交互。代理者负责协调通信，诸如转发请求以及传递结果和异常等

1991年OMG基于面向对象技术给出了以对象请求代理（ORB）为中心的分布式应用体系结构（CORBA）

其中ORB是一个关键的通信机制，它以实现互操性为主要目标，处理对象之间的消息分布，在ORB之上有4个对象接口：

• 对象服务：定义加入ORB的系统级服务，如安全性、命名和事务处理，它们是与应用领域无关的
• 公共设施：水平级的服务，定义应用程序级服务
• 领域接口：面向特定的领域
• 应用接口：面向指定的现实世界应用。是指供应商或用户借助于ORB、公共对象服务及公共设施而开发的特定产品

CORBA有很广泛的应用，它易于集成各厂商的不同计算机，从大型机一直到微型内嵌式系统的终端桌面，是针对大中型企业应用的优秀的中间件。最重要的是，它使服务器真正能够实现高速度、高稳定性处理大量用户的访问

持续更新中……
我是桐小白，一个摸爬滚打的计算机小白