分布式软件体系结构

分布式软件体系结构
分布式软件体系结构
编写⽬标：
●⾯向计算机专业⾼年级本科⽣与研究⽣的教程。

●可供从事基于Internet/Intranet的分布式软件开发⼈员参考使⽤。

要求读者：
●已掌握⾯向对象程序设计⽅法与⼀门⾯向对象程序设计语⾔（Java最佳）。

●具备软件⼯程的基本知识。

总体构思：
●强调理论与实践相结合：理论上以CORBA 2.4为模型，实践中以VisiBroker for Java
4.0为⼯具。

●强调深度与⼴度相结合：重点介绍CORBA的同时，兼顾DCOM与EJB两种模型，
最后总结对⽐这三种典型体系结构的特点。

主要内容：
●分布式计算的基本概念：从C/S过渡到分布式体系结构、OMA体系结构、CORBA
基本概念。

●分布式应⽤程序的开发：分布式应⽤程序框架、⽤IDL编写对象接⼝、编写服务
程序与客户程序、部署应⽤程序。

●分布式计算更深⼊的课题：探讨分布式应⽤程序的可靠性、伸缩性、安全性、性能
等课题可能提出的问题以及解决途径。

●不同体系结构的⽐较：总结CORBA、DCOM、EJB、XML等特点。

●配合教学需要的内容：在前⾔部分提供教学进度供参考，每⼀章后均配有课后练习
思考题和上机实习题。

引⾔
分布式计算是当前软件开发技术的⼀个重要发展⽅向。

C.A.R.Hoare指出：“分布式计算是⼀个具有重⼤理论与实践意义的迷⼈课题，其迷⼈之处在于理论与实践的同步发展，⼀⽅⾯实践推动了理论，另⼀⽅⾯理论⼜指导着实践。

”本书为读者介绍分布式计算领域的基本概念、开发过程、规范标准等内容。

分布式计算有两种典型的应⽤途径。

第⼀种应⽤途径是将分布式软件系统看作直接反映了现实世界中的分布性，例如当今许多业务处理流程通常呈现⼀种分布式运作⽅式，负责加⼯或制造的⼯⼚可能位于珠江三⾓洲⼀带，⽽负责销售与市场营销的部门则可能分别位于北京、上海和⼴州，这时负责业务流程的软件系统也可作相应的分布式处理。

第⼆种应⽤途径主要⽤于改进某些应⽤程序的运⾏性能，使它们⽐单进程的集中式实现更具有效率，此时软件系统的分布性并不是现实世界中分布性的映射，⽽是为充分利⽤额外的计算资源⽽⼈为引⼊的。

在计算机硬件技术与⽹络通信技术的⽀持下，应⽤需求驱使计算机软件的规模与复杂度不断增长。

⾯对这种情况，对整个软件系统的体系结构进⾏分析与设计就远远重要于对算法与数据结构的选择。

软件体系结构关⼼的正是整个软件系统的结构，它决定了⼀个软件系统由什么样的组件组成，以及这些组件之间的交互关系如何。

典型的软件体系结构风格有设计图形⽤户界⾯常⽤的事件驱动风格、操作系统常⽤的层次化设计、设计编译程序常⽤的管道与过滤器风格、许多应⽤程序都会使⽤的⾯向对象风格等。

分布式软件系统通常基于客户机／服务器风格，其中客户程序提出信息或服务的请⽰，⽽服务程序提供这些信息或服务。

客户机／服务器计算模型的发展⼤约经历了三个⾥程碑：局域⽹⽂件服务器、数据库服务器以及分布式对象。

由于当前⾯向对象技术⼏乎已渗透到软件开发的每⼀个⾓落，先进的分布式软件开发⽅法当然离不开与⾯向对象技术的结合，因⽽分布式软件体系
结构通常是客户机／服务器风格与⾯向对象风格的有效组合，典型的例⼦有OMG的公共对象请求代理体系结构（CORBA）、Microsoft的分布式组件对象模型（DCOM）、Sun Microsystems的企业JavaBeans（EJB）等。

在这些模型中，CORBA以其规范的严格性、供应商的⽆关性和其他许多先进的分布式计算特性成为我们教学的⾸选。

在理论教学⽅⾯，我们可参考OMG发布的⼀系列规范和关于CORBA的丰富读物；在课程实验⽅⾯，我们既可下载使⽤IONA Orbix、Inprise VisiBroker 等商品化CORBA产品的30或60天试⽤版，也可使⽤OmniORB、TAO等免费CORBA产品。

相对于其他分布式计算模型⽽⾔，CORBA在理论更为严格与完善，即使读者采⽤的开发平台未必是CORBA兼容的，CORBA中提出的许多问题也应加以考虑，并可借鉴CORBA 提出的问题解决⽅案。

本书从软件体系结构的⾓度介绍分布式软件系统分析与设计的基本概念，描述了分布式软件的开发与布署过程，并探讨分布式软件的可靠性、性能、可伸缩性等⾼级概念。

本书的主要内容分为四个部分。

第⼀部分“基本概念”介绍分布式计算中的基本概念与基本原理，从客户机／服务器计算模型过渡到真正的分布式计算模型，并掌握OMA与CORBA的基本概念。

为避免为传统集中式软件的开发⼈员⼀次性引⼊太多分布式对象计算的新概念，我们需要⼀个过渡性介绍以实现循序渐进的教学⽬标，Java RMI以其简单性与实⽤性⾃然进⼊我们的视野。

第⼆部分“开发过程”⾸先利⽤⼀个完整⽽简单的分布式应⽤例⼦程序介绍⼀个典型CORBA应⽤程序的开发过程，然后详细讨论如何利⽤接⼝定义语⾔（OMG IDL）编写对象接⼝，如何编写服务端程序与客户端程序，以及如何部署最终的应⽤程序。

第三部分“⾼级课题”探讨分布式应⽤程序中的⾼级课题，提出可能产⽣的问题以及这些问题的可能解决途径，包括分布式环境下对象查找、如何提⾼分布式应⽤程序的可靠性、如何提⾼服务端程序的可伸缩性等。

第四部分“其他与展望”通过简介与对⽐其他分布式体系结构（如DCOM、EJB、XML 等）拓宽读者在分布式计算领域的知识⾯，探讨分布式计算进⼀步的发展⽅向。

本书可供从事基于Internet／Intranet的分布式软件开发⼈员参考使⽤，也可作为计算机专业⾼年级本科⽣与研究⽣学习分布式计算课程的教材。

本书假设读者已掌握⾯向对象程序设计⽅法与Java语⾔，并具备⾯向对象软件⼯程的基本知识。

如果选⽤本书作为授课教材，对具有⾯向对象程序设计基础并熟练掌握C++和Java语⾔的学⽣宜讲授60课内学时，安排课外实验36学时，教学进度安排可参考如下（括号中分别标明了课内学时数与课外实验学时数）：第1章（6／6）、第2章（4／0）、第3章（4／6）、第4章（4／0）、第5章（8／6）、第6章（6／6）、第7章（2／0）、第8章（2／0）、第9章（4／0）、第10章（6／0）、第11章（6／6）、第12章（4／6），第四部分的第13⾄15章（4／0）。

对于不熟悉Java语⾔和Web 应⽤的学⽣宜讲授80课内学时，安排课外实验40学时。

本书课后练习中规模较⼤或复杂性较⾼的题⽬以星号“*”标出，这些题⽬适合作为课程设计的选题。

在即将由ACM／IEEE-CS修订发布的《计算教学⼤纲2001（CC2001）》中，“以⽹络为中⼼的计算（NC）”已成为14个知识领域之⼀，其中包含客户机／服务器计算、开发Web 应⽤、通信与⽹络、分布式对象系统、协作技术与群件等专题。

本书内容覆盖了该知识领域的许多专题。

本书中所有例⼦程序均使⽤Inprise公司的VisiBroker for Java 4.0和WebGain公司的VisualCaféEnterprise Edition 4.0平台开发，这些例⼦很容易移植到其他开发平台。

读者可从我们的教学⽹站
/doc/9e2a5346944bcf84b9d528ea81c758f5f61f2997.html 下载这些例⼦程序的全部源代码。

分布式软件系统是软件开发的⼀个新兴领域，并且各种分布式计算模型还在不断地迅速发展。

由于作者⽔平有限，书中谬误之处在所难免，恳请⼴⼤读者不吝批评指正。

李⽂军（lnslwj@/doc/9e2a5346944bcf84b9d528ea81c758f5f61f2997.html ）
周晓聪（lndcs01@/doc/9e2a5346944bcf84b9d528ea81c758f5f61f2997.html ）
李师贤（lnslsx@/doc/9e2a5346944bcf84b9d528ea81c758f5f61f2997.html ）
2001年5⽉于⼴州康乐园
第⼀部分基本概念
第 1 章客户机／服务器体系结构
本章利⽤Java语⾔的远程⽅法调⽤RMI与数据库接⼝JDBC开发⼀个简单的电话计费查询分布式应⽤程序，通过这个完整的例⼦帮助读者复习客户机／服务器体系结构的基本概念，并分析与探讨该应⽤程序需要进⼀步考虑与改进的不⾜之处，从⽽引出分布式软件体系结构要解决的问题。

§ 1.1软件设计的基本概念
1.1.1隐式地vs 显式地
隐式地（implicitly）与显式地（explicitily）是软件开发技术中经常出现的两个修饰术语，⽤于表⽰程序设计语⾔、编程⼯具或
软件开发环境等对软件开发⼈员的两种不同⽀持⽅式。

例如⼀个采⽤⾯向对象⽅法完成的设计同样也可以利⽤C语⾔实现，然⽽C语⾔对⾯向对象设计的⽀持是⼀种隐式的⽅式，⾯向对象设计的许多概念在C语⾔中⽆法直接地表达出来，显然这种隐式⽀持远远⽐不上C++、Java、Ada、Eiffel、Smalltalk等⾯向对象程序设计语⾔提供的显式⽀持。

软件开发⼈员获得显式⽀持的本质可看作是将许多原来必须由程序员动⼿实现的任务交由更底层的编译程序、开发⼯具或运⾏环境完成。

例如在数据库管理系统的帮助下，应⽤程序员开发数据处理应⽤程序时减轻了许多数据定义、查询、完整性、安全性等⽅⾯的负担。

程序设计技术或软件开发技术的发展⽅向之⼀是不断为软件开发⼈员提供更完善、更有效的显式⽀持。

例如在C语⾔或Pascal语⾔中⽆法显式地描述⼀个求平⽅根函数square_root()中可能引发的异常（譬如计算对象是⼀个负数），⽽C++语⾔或Java语⾔允许在函数原型中显式地将函数体可能引发的异常表达出来，这种显式表达使得编译程序可帮助程序员检查该函数体中是否真的可能引发这些异常，以及约束使⽤这些函数的程序必须处理哪些异常。

此外，将异常作为函数原型的⼀部分也有助于使⽤函数的程序员更全⾯地理解这些函数的语法与语义。

⼜如在⾯向对象程序设计中⼀个实体除了属性与⾏为外，还应包含该实体的属性与⾏为应满⾜的约束。

譬如⼀个银⾏帐户ACCOUNT除了拥有帐户标识、存款余额等属性以及存款、取款、查询余额等⾏为之外，还⾄少必须满⾜⼀个约束，即在帐户⽣存期的任⼀时刻存款余额不得⼩于0（如果是允许透⽀的信⽤卡帐户，则应将约束修改为透⽀不得超过某⼀上限，⽽透⽀上限必须是帐户的⼀个属性）。

在C++语⾔或Java语⾔中，程序员⽆法将这⼀约束显式地表达出来，只能在对象初始化、存款、取款等⾏为的实现中隐式地表达，使⽤这些组件的其他程序员也只能通过理解这些⾏为的实现才能了解到ACCOUNT的这种约束。

当然通过注释将约束表达出来是⼀种良好的程序设计风格，但编译程序不能为此提供任何帮助。

相⽐之下，Eiffel程序员可显式地描述ACCOUNT必须满⾜的约束，以及每⼀操作之前或之后必须满⾜的条件，程序员不必再考虑正常条件之外的异常，⽽交由运⾏环境负责引发相应的异常。

在分布式软件开发中⽐传统的集中式软件开发有更多的问题需要解决，程序员可以⾃⼰动⼿解决这些问题，但更理想的情况是由底层的⽀持（如语⾔、⼯具、环境等）帮助程序员完成这些任务。

本书着重讨论在分布式软件开发中需要解决的重要问题，以及当前的分布式软件开发规范与产品对解决这些问题提供的⽀持。

随着分布式软件开发技术的发展与成熟，程序员将获得越来越完善与有效的⽀持。

对显式⽀持与隐式⽀持的讨论可以提醒我们，必须留意在分布式软件开发中存在哪些问题需要解决，这些问题并不会因为得不到显式⽀持⽽消失，在只有隐式⽀持的情况下程序员仍要⾃⾏解决这些问题。

因⽽对解决关键问题的显式⽀持是评价与选择分布式软件的体系结构规范、程序设计语⾔、开发⼯具与环境的⼀个重要因素。

当然更重要的⼀点是提醒我们，在软件开发过程中应考虑可为分布式软件开发添加哪些新的显式⽀持，从⽽为分布式软件在我国的推⼴应⽤作出⾃⼰的贡献。

1.1.2逻辑的vs 物理的
逻辑的（logical）与物理的（physical）分别代表着两个不同的抽象层次。

早在10年前由IEEE-CS/ACM联合制订的《91’计算教学计划》中，就将抽象层次列为计算机科学与⼯程专业学⽣必须掌握的⼀个核⼼概念，这⼀概念贯穿了计算机学科的众多领域。

抽象是⼈类认知世界的最基本思维⽅式之⼀。

罗素曾断⾔：“发现⼀对鸡、两昼夜都是数２的实例，⼀定需要很多年代，其中所包含的抽象程度确实不易达到；⾄于１是⼀个数的发现，也必定很困难。

”
抽象源于⼈类⾃⾝控制复杂性能⼒的不⾜：我们⽆法同时把握太多的细节，复杂的问题迫使我们将⼀些相关的概念组织成不同的抽象层次。

例如⽇常⽣活中的is-a关系是⼈们对概念进⾏抽象和分类的结果，例如苹果是⼀种⽔果，⽔果是⼀种植物等，⽣物学采⽤的界、门、纲、⽬、科、属、种标准⽣物分类⽅法是这⼀思维⽅式的经典应⽤。

将这种is-a关系在程序中显式地表达出来⽽形成的继承机制，是⾯向对象程序设计最重要的特征之⼀。

在软件设计中太容易找到抽象层次的实例，例如变量→类型、对象→类→抽象数据类型、实现→规格说明、数据流图分解与平衡等。

逻辑层与物理层组织是⼀种常见的抽象层次。

⼀个典型的C++程序从逻辑上看由m个类与1个主函数main()组成，但同样的逻辑组织形式却在物理上可根据不同需要组织为不同形式的⽂件模块，整个程序既可能划分为n1个⽂件模块，也可能划分为n2个⽂件模块。

从不同的抽象层次来看，这两个程序的物理组织形式虽然不同，但其逻辑组织形式却是⼀样的。

⼜如在管理信息系统的开发过程中，系统分析的主要任务是根据现有管理信息系统的物理模型建⽴更⾼抽象层次的逻辑模型，在逻辑模型中抛弃了物理模型中那些开发者不关⼼的细节，仅表达了系统边界之内⽤户最关⼼的内容，这⼀建模过程的本质就是⼀个抽象过程。

系统分析员通过对逻辑模型的研究与改进，进⼀步实现在计算机平台上的⼀个新的物理模型。

在分布式软件系统中，有许多机制虽然与传统的集中式软件在物理层次表现出很⼤差异，但从逻辑层次上看它们却是统⼀的，例如普通函数调⽤与远程过程调⽤（RPC）、对象消息传递与远程⽅法调⽤（RMI）、接⼝与实现的分离、同⼀接⼝多种实现等。

因⽽在分布式软件体系结构的学习与研究中，利⽤不同的抽象层次可帮助我们从更⾼层次掌握分布式软件系统的各种机制，并且可以⽤⼀种统⼀的知识框架来理解分布式软件与传统的集中式软件的基本概念、表⽰技术以及开发过程。

同理，⼀个软件系统在逻辑层次表现为分布式的，但在物理层次部署时却可能是集中式的。

对于同⼀个分布式软件系统，可以⽤⼀台单机同时充当客户机与服务器，并包含了两者之间的通信，从⽽让我们有可能在家中的⼀台电脑上就能学习开发与调试分布式应⽤程序，
然后再将这些应⽤程序部署到真正的分布式运⾏环境中。

1.1.3⾯向对象技术
在⼆⼗世纪80年代兴起的⾯向对象技术已在软件⽣存期的各个阶段取代传统的结构化⽅法，成为当前软件开发的主流技术。

在分布式软件开发领域也不例外。

⾯向对象开发过程本质上是⼀个建模过程。

开发⼈员通过分析问题域中实体的属性、⾏为、约束等，抽象出能描述这些实体共同结构与特征的概念，然后在计算机中利⽤类建⽴这些概念的系统模型，再通过类创建具体的对象实例模拟问题域的实体⾏为。

⾯向对象开发⽅法强调将系统功能建⽴在系统模型之上，所有系统功能采⽤底层的系统模型提供的术语来表达，从⽽提⾼了软件系统的可扩展性与可维护性。

除了封装与信息隐藏、数据抽象、模块化等特征外，⾯向对象技术的最主要特⾊是继承与多态性。

继承是⽇常⽣活中的is-a关系在程序中的显式表达，是重⽤数据与操作的重要⼿段。

多态性有⼗分⼴泛的含义，这⾥主要是指运⾏期间程序表现出来的多态性，它建⽴在继承与动态绑定的基础上，使得⼀个对象可以具有多种不同的动态类型，从⽽⼤⼤提⾼了⾯向对象程序的表达能⼒。

先进的分布式软件体系结构必须与⾯向对象技术结合在⼀起，从⽽可分享⾯向对象技术带来的众多好处。

例如由开放软件基⾦会（OSF）于1992年发布的分布式计算环境（Distributed Computing Environment，缩写为DCE）采⽤的是远程过程调⽤（Remote Procedure Call，缩写为RPC）技术，RPC⽀持开发⼈员进⾏结构化程序设计，使得客户程序可以像调⽤本地过程⼀样调⽤服务程序中的过程。

⽽由Sun Microsystems于1996年发布的远程⽅法调⽤（Remote Method Invocation，缩写为RMI）技术是⼀种分布式对象模型，保持了Java语⾔的对象语义，⽀持分布式应⽤程序员进⾏⾯向对象程序设计，在客户程序中可以像将消息传递给本地对象⼀样，将消息传递给服务程序中的对象。

当前⼏种主流的分布式软件体系结构均融合了分布式计算与⾯向对象技术，包括OMG 的公共对象请求代理体系结构（CORBA）、Microsoft的分布式组件对象模型（DCOM）、Sun Microsystems的企业版JavaBeans（EJB）等。

1.1.4软件体系结构
随着计算机软件系统的规模不断增⼤并且系统复杂度不断提⾼，在软件开发过程中对整个软件系统的体系结构进⾏分析与设计远⽐对算法与数据结构的选择更加重要。

软件体系结构关⼼的正是整个软件系统的结构，它决定⼀个软件系统由什么样的组件构成，以及这些组件之间的交互关系如何，并提供⼀种模式指导组件的合成。

尽管严格的形式化⼯作仍处于实验阶段，软件体系结构在软件⼯程中已扮演着越来越重要的⾓⾊。

典型的软件体系结构风格有设计图形⽤户界⾯（GUI）常⽤的事件驱动风格、设计操作系统常⽤的层次化设计风格、设计编译程序常⽤的管道与过滤器风格、设计分布式应⽤程序常⽤的客户机／服务器风格等。

⼀个实⽤的软件系统通常是⼏种典型体系结构风格的组合。

分布式软件系统通常基于客户机／服务器（client/server）模型，因⽽组成系统的最核⼼组件是客户程序与服务程序，然⽽不同的分布式软件体系结构还决定了各⾃不同的组件以及这些组件之间的交互⽅式。

例如在OMG的CORBA模型中，存在若⼲称为对象请求代理（ORB）的组件，这些组件之间采⽤因特⽹ORB间协议（IIOP）进⾏通信；⼜如在OSF/DCE 中，客户程序与服务程序之间通过远程过程调⽤（RPC）进⾏交互，参数与返回值的编码采⽤外部数据表⽰（XDR）技术，⽽Sun Microsystems的EJB则利⽤远程⽅法调⽤（RMI）进⾏交互，参数与返回值的编码采⽤Java语⾔专⽤的对象串⾏化技术。

本书主要从软件体系结构的⾓度探讨分布式软件系统的有关课题。

⼀个分布式应⽤系统
在软件体系结构层次需要考虑的问题包括如何将组件合成系统、如何将功能指派到设计元素、通信与同步协议、全局控制结构、物理的分布、可伸缩性与可靠性等。

§ 1.2客户机／服务器模型
1.2.1客户机与服务器
在⼆⼗世纪90年代兴起的客户机／服务器数据库技术是⾃70年代关系数据库技术以来数据库技术的⼀次重⼤飞跃。

由于在客户机／服务器数据库系统中将系统的处理任务划分为客户系统与数据库服务器两端，因⽽⼤量的数据库操作可在后端运⾏，⼯作站只需能够运⾏前端软件即可。

尽管客户机／服务器系统⽐传统的集中式系统更复杂，然⽽这⼀新的计算模型带来的优势是显⽽易见的，例如减轻了⽹络传输负担，实现了⼯作站⽆关性，更⽅便维护数据的完整性等。

其实客户机／服务器体系结构并不仅仅局限于数据库应⽤，这种计算模型有着更⼴义的定义。

如果⼀个系统被划分为两类不同的但相互联系的组成部分，其中⼀⽅提出对信息或服务的请求（称为客户机），⽽另⼀⽅提供这种信息或服务（称为服务器），那么这种体系结构即可看作是⼀种客户机／服务器计算模型。

按照这⼀定义，局域⽹中的⼯作站与⽂件服务器之间是⼀种客户机／服务器模型，其中⼯作站向⽂件服务器发送服务请求，例如要求访问⽂件或⽹络打印等，⽂件服务器接收这些请求后为⼯作站提供这些服务。

因特⽹的许多应⽤程序都采⽤客户机／服务器模型，例如Web浏览器与服务器、电⼦邮件客户程序与服务程序、FTP客户程序与服务程序等。

客户机与服务器是⼀个相对的概念，⼀个服务器可能是另⼀个服务器的客户机，⼀个客户机也可能是另⼀个客户机的服务器。

客户机与服务器的划分可以是物理层次的，例如局域⽹中的⼯作站与⽂件服务器通常是由两台不同的计算机系统担任；客户机与服务器的划分也可以是逻辑层次的，这时我们经常⼜将这两端分别称为客户程序与服务程序。

⼀个常见的简单例⼦是在过程式程序设计中，执⾏函数调⽤表达式的⼦程序与实现函数体的⼦程序可看作⼀种客户机／服务器模型，其中函数实现⽅是服务程序，函数调⽤⽅是客户程序。

在⾯向对象程序设计中，消息传递可看作客户程序向服务程序发送服务请求的过程，发送消息的是客户程序，接收并处理消息的服务程序。

在普通的函数调⽤中，对于函数实现与函数调⽤双⽅最为重要的是两者之间的接⼝（⼜称界⾯，即函数原型说明）以及通信协议（例如双⽅对调⽤风格的约定，决定采⽤C还是Pascal的调⽤风格）。

客户程序与服务程序之间的接⼝描述越清晰，对编写客户程序与服务程序的开发⼈员帮助越⼤，同时各种编程⼯具或可重⽤组件管理⼯具越有可能为开发⼈员提供有⼒⽀持。

函数原型⼀般都包含了函数名字、返回值类型、参数个数与类型等，更完善的接⼝还可能包括可能引发的异常、必须满⾜的前置条件与后置条件等。

这些接⼝的内容都是语法层⾯的，如果有朝⼀⽇能提供语义层⾯的接⼝描述，软件开发⼈员将看到软件构造⾃动化的曙光，这当然还要依赖于形式语义学研究有进⼀步的突破。

分布式软件系统绝⼤多数采⽤客户机／服务器体系结构，其中最重要的仍是上述接⼝与通信协议的问题，只不过由于客户端与服务端在物理层次上的分离，导致通信协议更加复杂，并且可靠性、安全性、性能等因素显得更加突出。

1.2.2客户端与服务端的分离
分布式软件与传统的集中式软件主要区别在于强调客户端与服务端在地理位置上的分离。

虽然分布式软件与集中式软件在逻辑层次有许多⽅⾯是⼀致的，但在物理层次两者仍有
许多重⼤区别。

在分布式软件系统中客户端与服务端的物理分离可带来许多好处。

⾸先，整个系统的所有计算任务可在客户端与服务端两边进⾏负载重新分布，使得RISC⼯作站与微机建⽴的计算机⽹络系统可以完成以前只有价格昂贵的⼤型机（mainframe）才可胜任的⼯作，实现企业计算规模的下⾏（downsizing）；⽽与传统的基于局域⽹的应⽤系统相⽐，客户端与服务端的分离⼤⼤减少了⽹络传输的数据量，可有效地提⾼系统的运⾏效率，实现企业计算规模的上⾏（upsizing）。

其次，这种新的计算模型更好地⽀持了平台⽆关性，客户端既可以运⾏在IBM PC兼容微机、Macintosh微机、RISC⼯作站等不同机型，也可以运⾏Microsoft Windows、IBM OS/2、Apple System 8、各种版本的Unix等不同操作系统，还⽀持TCP/IC、IPX/SPX、NetBEUI等不同⽹络协议。

此外，采⽤客户机／服务器计算模型的软件系统具有更好的可扩充性，例如可在服务端功能不变的前提下对服务端程序进⾏改进或扩充，⽽这种改进与扩充不会影响到客户端的应⽤程序。

当然这种分离也会带来⼀些新问题，对于软件开发⼈员⽽⾔，最主要的问题是分布式软件系统通常⽐集中式软件系统更加复杂。

例如开发⼈员不得不分别开发客户端与服务端的应⽤程序，并⼒求保持两端应⽤程序的⼀致性，软件系统的部署与维护也更加困难。

此外，设计分布式软件系统时⽐设计集中式软件系统需要考虑更多的可靠性、安全性、性能等软件质量要素。

本书将主要讨论客户机／服务器体系结构设计中的这些复杂问题，包括如何更好地显式表达客户端与服务端双⽅的公共接⼝，客户端应⽤程序与服务端应⽤程序双⽅如何进⾏通信，客户端应⽤程序如何查找服务程序，如何保证服务端应⽤程序的可⽤性等等。

1.2.3两层模型与多层模型
典型的客户机／服务器体系结构⼜称为两层（2-tier）模型。

在两层模型的设计中，由客户应⽤程序直接处理对数据库的访问。

因⽽每⼀台运⾏客户应⽤程序的客户机都必须安装数据库驱动程序，增加了系统安装与维护的⼯作量。

同时，数据库由众多客户程序直接访问，导致数据的完整性与安全性难以维护。

为提⾼数据的安全性与系统的可扩充性，可在两层模型的基础上考虑采⽤三层（3-tier）或多层（N-tier）设计模型，将数据库访问分布在⼀个或多个中间层。

客户程序与数据库的连接被中间层屏蔽，客户程序只能通过中间层间接地访问数据库。

中间层可能运⾏在不同于客户机的其他机器上，经过合理的任务划分与物理部署后，可使得整个系统的⼯作负载更趋均衡，从⽽提⾼整个系统的运⾏效率。

这些位于中间层的中间件（middleware）⼜称应⽤服务程序（application server），因为它们实际上表达了⼀个企业处理信息的主要业务逻辑（business logic），即企业的系统模型与功能模型，⽽客户程序仅实现图形⽤户界⾯，完成终端⽤户与业务逻辑之间的交互。

从客户程序的⾓度来看，中间件将企业的所有业务逻辑抽象为更⾼层次的应⽤程序接⼝（API），客户程序则通过这些API构建整个企业的应⽤系统。

与典型的两层模型相⽐，三层模型或多层模型可更好地⽀持对企业业务逻辑的集中控制与管理。

§ 1.3⼀个简单的例⼦
1.3.1问题背景
电信收费是当前⽼百姓关⼼的热点问题，明明⽩⽩消费是每⼀个消费者的合理要求，但如果打印并邮寄每⽉话费清单⽆疑会额外花费⼤量的⼈⼒、物⼒与财⼒。

随着我国信息基础
设施的不断完善，上⽹普及率越来越⾼，通过因特⽹查询话费将是⼀条⾮常可⾏的途径。

本⼩节以⼀个简化的电话计费查询程序为例，向读者介绍分布式应⽤程序的基本概念，并通过对这⼀简单应⽤程序的讨论引出分布式软件体系结构中需要考虑的更⾼级课题。