软件体系结构风格分析与应用——新型类软件体系结构风格---毕业论文

本 科 毕 业 论 文 软件体系结构风格分析与应用新型类软件体系结构风格Analysis and Application on Software Architecture StylesNew Software Architecture Styles姓 名： 学 号：学院：软件学院系：软件工程专 业：软件工程年 级： 指导教师： 年 月摘要随着计算机应用的日益普及, 人们对软件的需求量急剧增加。但是, 计算机软件开发技术却远远没有跟上硬件技术的发展, 使得软件开发的成本逐年剧增。 现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说, 对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择显得更重要。在此种背景下, 软件体系结构的提出对软件重用机制和软件开发效率的提高具有非常重要的意义。软件体系结构的使用是提高软件开发质量、减少软件开销和促进软件生产率提高的最有效方法之一。采用定性分析、比较研究等多种方法,实现了几种新型软件体系结构风格的剖析。给出了软件体系结构及软件体系结构风格的定义,阐述了几种新型软件体系结构风格中关键要素的定义及特性及其风格的主要内容,分析了几种新型软件体系结构风格的特点。本质上, 软件体系结构是对软件需求的一种抽象解决方案。这样, 在引入了体系结构之后, 软件系统的开发变为“问题定义软件需求软件体系结构软件设计软件实现”的过程。本文即将研究几种新型软件体系结构风格，其中包括客户/服务器结构、代理者结构、COM/DCOM/COM+组件结构、PAC(表达抽象控制)结构、映像结构和MVC(模型视图控制)结构。对每一种风格分别进行系统结构、动态特性、系统的设计实现和应用、结构的变体和扩展及结构的优缺点等几方面的详细阐述。关键词：软件体系结构；设计方法；构件AbstractWith the computer widely used,the need of software rapidly increased.however,the development of software technology still has a long way with the development of hardware technology.As a result,the cost of software development increases year by year.The existing software engineering method is not much helpful.To a sweeping and complex software system,the design of the whole system architecture and standard is very important.At this moment,software architecture makes big sense in the reuse and efficiency of software.The using of software architecture can boost the quality of software and decrease the lost of software.It is one of the most effective method to increase the production efficiency.In fact,the software architecture is a solution to the software requirements.So,the development of software system becomes a process as defynation of problemsoftware requirementssoftware architecturesoftware designmentsoftware application after the concept software architecture is created.In this thesis,I will talk about each software architecture including Client/Server, Broker, PAC, Reflection, MVC and talk about the architecture,designation,application,varation and advantages and disadvantages of each architecture.Key words: software architecture;design method;component目录第一章引言11.1软件体系结构的定义11.2软件体系结构应用现状及发展方向11.2.1应用现状11.2.2研究热点21.2.3发展方向21.3软件体系结构风格的种类21.4 论文的组织结构3第二章客户/服务器（Client /Server）结构42.1概述42.2客户/服务器的结构52.2.1客户/服务器系统构成52.2.2两组组件之间的关系62.2.3客户与服务器的连接62.3客户/服务器的连接72.4服务器的调度92.5客户/服务器结构的变异客户/分配器/服务器结构12第三章代理者（Broker）143.1概述143.2问题分析与方案143.3代理者系统的结构153.4动态特性193.5代理者结构的设计实现203.6代理者结构的变体与扩展233.6.1直接通信代理者系统233.6.2信息传递代理者系统243.6.3交易器代理者系统243.6.4适配器代理者系统243.6.5回调代理者系统243.7代理者结构的应用253.8代理者结构的优缺点25第四章COM/DCOM/COM组件结构284.1概述284.2COM组件结构294.3COM组件接口314.3.1COM组件的接口定义314.3.2接口的工作模式324.3.3IUnKnown接口324.3.4COM组件生存期334.3.5COM组件接口查询及其设计原则334.3.6COM接口的特性344.4COM组件的不同类型354.4.1进程内组件354.4.2进程外组件354.5COM组件的运行374.6COM组件的变体和扩展394.6.1连接点组件394.6.2DCOM分布式组件414.6.3COM+（独立组件）结构42第五章PAC(表达-抽象-控制）结构455.1PAC结构概述455.2PAC结构的方案465.3PAC结构475.4动态特性505.5PAC结构的设计实现515.6PAC结构应用举例555.7PAC结构的优缺点565.8PAC的变体57第六章总结与展望586.1本文工作总结586.2进一步展望58参考文献59致谢61ContentsChapter 1 Introduction11.1 The Concept of Software Architecture11.2 The Application State and Development Trends11.2.1Application State11.2.2Research Focus21.2.3Development Trends21.3The Sorts of Architecture Styles21.4 The Structure of Thesis3Chapter 2 Client/Server42.1Introduction42.2Client/Server Architecture52.2.1. Client/Server System52.2.2 Client/Server Component62.2.3 Client/Server62.3Client/Server Connection72.4Client/Server Despatch92.5Client/Server Variation-Client/Distributor/Server12Chapter 3 Broker143.1Introduction143.2Analysis and Method143.3The Architeture of Broker153.4Dynamic Characteristics193.5The Design of The Broker203.6The Variation of Broker233.6.1 Direct Communication System233.6.2 Messaging System243.6.3 Trader Broker System243.6.4 Adapter System243.6.5 Callback System243.7The Application of Broker253.8Advantages and Disadvantages25Chapter 4COM/DCOM/COMConponert Architecture284.1Introduction284.2COM Component294.3COM Component Interface314.3.1 The Definition of COM Component314.3.2 The Pattern of Interface324.3.3 IUnKnown Interface324.3.4 COM Component Survival334.3.5 COM Interface Query and Design Principle334.3.6 COM Interface Characteristic344.4Sorts of COM Component354.4.1 Component in The Process354.4.2 Component out of The Process354.5The Application of COM Component374.6The Variation of COM Component394.6.1 Connection Component394.6.2 DCOM Distributed Component414.6.3 COM+ Architecture42Chapter 5PAC Architecture455.1Introduction of PAC Architecture455.2The Plan of PAC Architecture465.3Architecture of PAC475.4Dynamic Characteristics505.5The Application of PAC515.6Examples of PAC555.7Advantages and Disadvantages565.8The Variation of PAC57Chapter 6 Conclusion586.1The Summary of This Thesis586.2Outlook58References59Acknowledgements61第一章 引言第一章引言所有软件开发方法都要解决从需求到实现之间的转换问题。为了提高软件需求和软件设计的质量, 软件工程界提出了需求分析工程技术和各种软件建模技术。但是, 在需求与设计之间仍存在一条很难逾越的鸿沟, 即缺乏能够反映做决策的中间过程, 从而很难有效地将需求转换为相应的设计。为此, 软件体系结构概念应运而生, 并试图在软件需求与软件设计之间架起一座桥梁, 着重解决软件系统的结构和需求向实现平坦地过渡的问题。本质上, 软件体系结构是对软件需求的一种抽象解决方案。这样, 在引入了体系结构之后, 软件系统的开发变为“问题定义软件需求软件体系结构软件设计软件实现”的过程。1.1软件体系结构的定义软件体系结构风格(style)又称软件体系结构习惯模式(idiomat ic- paradigm)。体系结构风格定义了一个系统家族, 即一个体系结构定义一个词汇表和一组约束: 词汇表中包含一些部件和连接器类型, 而这组约束指出系统是如何将这些部件和连接器组合起来的1。1.2软件体系结构应用现状及发展方向1.2.1应用现状1.形成研究热点，仍处于非形式化水平从软件体系结构研究的现状来看，当前的研究和对软件体系结构的描述，在很大程度上来说还停留在非形式化的基础上。软件架构师仍然缺乏必要的工具，这种工具应该是显示描述的、有独立性的形式化工具。在目前通用的软件开发方法中，其描述通常是用非形式化的图和文本，不能描述系统期望的存在于构件之间的接口，不能描述不同的组成系统的组合关系的意义。难以被开发人员理解，更不能用来分析其一致性和完整性。2.软件体系结构的形式化方法研究软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。从软件体系结构研究的现状来看，在这一领域近来已经有不少进展，1.2.2研究热点当前，体系结构仍是一个非常新的研究领域，其概念还相当模糊。但软件体系结构作为软件工程领域中的一个组成部分，已经取得了长足的发展，收到大多数软件系统设计和研究人员的重视。软件体系结构目前较活跃的研究方向包括：(1)软件体系结构形式基础的研究；(2)针对软件体系结构描述中特有的问题研究新的专门的高级语言；(3)建立用于度量和评价软件体系结构的模型和方法；(4)建立面向专门领域的软件体系结构范型库；(5)把软件体系结构从目前的知觉和经验状态过渡到理论。1.2.3发展方向1. 各种体系结构描述语言之间的信息互换大多数ADLs具有一系列的共同概念，如何用一种公共形式把各种语言综合起来，使得能够交换各种体系结构描述信息，将是今后软件体系结构研究和实践的重点之一。2. 设计工具和环境软件体系结构设计既然作为软件工程的一部分，它的计算机辅助实现手段是相当重要的。我们应当开发出一些软件工具来实现体系结构的描述和分析，开发阶段转换工具，以实现阶段成果的自动转换。目前关于这方面的研究成果很少，特别是可以应用到实际项目开发中的工具和环境就更少。1.3软件体系结构风格的种类新型的软件体系结构风格主要有以下几种：客户/服务器（Client /Server）结构、浏览器/服务器（Browser/Server）结构等、正交（Orthogonal）结构、映像（Reflection)结构、异构结构（Heterogeneous Architecture)、代理者（Broker）、COM/DCOM/COM组件结构、MVC（模型-视图-控制）结构、微核（Microkernel) 结构、PAC(表达-抽象-控制）结构等；下文主要是对以上这几种新型软件体系结构风格进行了分析,并展望了软件体系结构风格的发展前景。1.4 论文的组织结构本论文分八个章节安排，主要讲述了几种新型软件体系结构风格的结构特性及应用，各章节的内容安排如下：第一章简略谈一下软件体系结构的定义及其研究现状、热点及发展方向。第二章介绍了客户/服务器的结构、客户/服务器的连接及客户/分配器/服务器结构等内容。第三章介绍了代理者的结构、问题分析与方案、设计实现及应用等内容。第四章介绍了COM/DCOM/COM+组件的结构、COM组件的接口、COM组件的不同类型及COM组件的运行等内容。第五章介绍了PAC(表达抽象控制)的结构、PAC结构的方案、PAC动态特性及PAC结构设计的实现等内容。第六章总结与展望。对该论文进行工作总结，并对软件体系结构这门技术的发展做了预测。61第二章 客户/服务器（Client/Server）结构第二章客户/服务器（Client /Server）结构2.1概述客户/服务器本事一个较广泛的概念。它指的是一个应用系统被分成了两个逻辑上分离的本分：一个客户和一个服务器。离爱哪个部分各自完成不通的功能并充当不同的角色。客户为完成特定的工作向服务器发出请求，而服务器接受客户的请求，并将处理结果返送给客户。两个部分协作完成一个共同的任务。客户/服务器结构在许多地方得到应用，但是它主要是应用在分布式系统中，并且在应用中不断改进完善，并产生许多发展和变异。在通过网络链接的分布式应用系统中，客户端，或称前端，是处理应用问题内在逻辑与服务器关系的程序，而服务器端，又称后端，是通过网络通信而实施操作服务的程序系统。应用程序在网络上的分布允许多台计算机共同完成一个统一的任务。随着英特网的发展，各种新兴的服务器加入到程序系统中来，组成了以网路互联为基础的更复杂的应用系统。最初的客户/服务器系统主要是应用在基于网络数据库的信息系统中。客户端负责与用户的交互，如用户提交的查询和检索任务经客户端处理后，发送给服务器。服务器负责操作数据库并把查询的结果返送给客户端，最后，客户端把结果显示給用户，该结构的简单模型如图2-1(a)所示。随着系统任务日益复杂繁重以及设计维护的需要，因而把客户和服务器中的应用操作部分抽取出来形成应用逻辑服务器，则系统结构变化如图2-1(b)所示。此时客户仍完成与用户的交互操作，而复杂的处理则交由应用逻辑服务器完成。它成为客户机与数据库服务器的中间桥梁。 由于因特网技术的应用和发展，为减轻客户端应用程序开发的负担和为统一客户端应用程序的设计和开发，引入了浏览器程序和WWW服务器。WWW服务器承担了客户与应用逻辑服务器之间的链接作用，形成了如图2-1(c)所示的多级服务器的系统结构。无论在两级或多级服务器系统结构中，每两个组件之间都形成客户/服务器关系。当然，每个服务器完成不同的操作任务，因而充当不同的角色。但是即使前后两者都是服务器，同样也构成客户/服务器的关系。图2-1客户/服务器体系结构示意图2.2客户/服务器的结构多级客户/服务器结构体系仅是基本客户/服务器关系的扩展。其中每两级之间的关系，构成及运行机构与基本客户/服务器基本相同。下面只针对基本客户/服务器结构进行讨论。2.2.1客户/服务器系统构成客户/服务器结构是油两个独立的逻辑系统即客户及服务器构成。这两个部分是为完成特定的任务而形成的组件之间的单向协作关系。一般认为，客户根据需要向服务器发出操作请求，并期待着从服务器返回所要求的操作结果。客户端组件通常由用户交互界面、操作请求表达，服务代理及通信组成。而服务器服务器端组件由服务器接口、调度管理、事物处理计算、共享资源管理及通信组成。客户与服务器之间具有通信连接，并遵守公共的通信协议，其中主要包括：请求的表达，离爱粘结关系及状态的表达。2.2.2两组组件之间的关系用户通过客户端的用户交互界面跳脚操作要求，并读取操作请求返回的结果。客户端的请求表达把用户的操作要求转换成合乎通信协议要求的表达方式。通过服务器在客户端得的代理，客户提出操作要求，并获得服务器返回的信息，以掌握服务器的状态。通信组件负责客户与服务器的信息联系。服务器端的服务器接口提供客户与服务器联系的标准或“窗口”。它体现了服务器可以提供的操作服务和规范，是客户与服务器连接的桥梁。经连接后，事务处理计算部分负责完成通过接口提供的各种处理和计算。而共享资源管理是服务器中维护的公共信息库或其他资源。它为操作请求的完成，提供信息或其他资源，是服务器能提供各种服务的基础。调度管理部分负责按客户的请求和服务器的内部状态，管理和调配客户的请求和系统的资源，尽可能地快速高效地完成操作请求，将结果返送给客户。通信部分负责实现服务器与客户的联系。在客户/服务器结构中，客户总是知道哪个服务器可用，而服务器却无法知道何时有什么客户会发出服务请求。2.2.3客户与服务器的连接如果客户与服务器都配置在同一台计算机上，那么通过信号、消息，共享存储区等方法都可以实现客户与服务器在进程级上的通信连接。但是，若客户与服务器分布在通过网络连接的不同计算机上，他们之间的通信连接就只能通过网络连接了。在网络上进程通信的首要问题是进程标记。在同一台机器上，不同的进程可以用进程号作为唯一标识。但是在网络上，计算机各自分配的进程号不能单独作为进程标识了，而是在进程标识前需要机器的网络地址和机器的端口号，因此网络上进程间通信的唯一标识需要三元祖：协议、本机网络地址和本机端口号。这是本端的标识，称为”半相关“。而完整的网络上进程通信连接需要客户和服务器端两个进程参与。因此需要5个参数组成的五元祖来标识，它们是：协议、本机网络地址、本机端口号、远程网络地址和远程端口号。这五元祖标识了本机和要连接的远程机的两个进程，称为“全相关”。图2-2标识的是以UNIX提供的服务为基础，客户/服务器通信使用网络套接字建立连接时的时许关系。图2-2中：socket()系统调用，产生一个套接字socket。它标志着一个进程的产生。图2-2客户/服务器通信连接的建立2.3客户/服务器的连接1. 连接要求客户与服务器的连接是通过客户与服务器的接口进行的。他们之间有两种接口，一是使用过程的接口；另一种是基于消息的接口。客户与服务器通信必须满足下列要求： (1)客户与服务器间的所有交互必须通过定义好的接口来实现，客户向服务器发送它的请求需通过服务器的访问接口。服务器返回的信息和状态也必须经客户的接口送入。 (2)客户与服务器交互的信息必须按照规定的语法形式表达，尤其是与数据库服务系统的交互。 (3)组件之间的信息传送，从客户到服务器主要是请求信息，而从服务器到客户主要是操作返回信息和状态信息。 (4)客户的请求信息一般在客户端打包后再传给服务器。在服务器端，对收到的信息包进行解包处理，取其中的有用信息，然后形成对请求服务的调用。从服务器返送給客户端的信息也需经同样打包、解包的处理过程。 (5)服务器对接收到的客户端信息进行解包分析后，执行服务器上的相关服务，如查询数据库，按客户要求进行实施。2. 连接的检测客户与服务器是独立工作的组件，而且常常处在不同的计算机上。尤其是网络上的服务器，随时随地都可能有客户请求连接的发生。通常，使用循环查询的方式检查连接请求是不适宜的。应采用中断方式来激发和控制连接，可以通过进程等待或网络请求中断来实现。一般在服务器端设置一个守护进程，也称服务器进程。服务器启动时即启动守护进程。没有客户请求时，守护进程处于等待状态。每当有客户请求到达时，服务器守护进程立即响应，并相应产生资源分配和执行处理，然后又回到等待状态准备接收下一个请求。3. 连接的方式客户与服务器的连接有使用过程和使用消息两种方式。当采用使用过程连接时，两个组件必须通过良好定义的接口进行交互通信。这些接口可能是系统中的某一过程。客户或服务器可以用过程实现的请求及响应机制进行交互。这是采用远程过程调用（RPC)及相关技术来实现的。客户通过服务器的接口向服务器发出服务请求，该请求被看成对服务器的一个远程的过程调用请求。客户发出请求后，即进入等待返回结果状态。而请求的响应在服务器上计算完成。通常的远程过程调用RPC多是同步运行的，即客户发出请求后一直处于等待状态，不执行任何自身的程序逻辑，直到得到返回结果为止。如果不希望客户发出请求后一直处于等待状态，可以在客户/服务器的接口中加入回调例程。这时，如果客户的请求发出并得到服务器的确认后，客户立即返回执行自身其他的程序逻辑，等到服务器操作完成后，才把结果通知客户。这就是异步响应方式。如若客户发出请求一段时间后才需要使用请求返回的结果，或根本不需要返回结果就可以不必等待请求的返回。当然如果客户需要异步请求返回的结果，这种做法会給客户方的设计增加困难和复杂性。客户方必须维持尚未得到返回结果的请求记录，并解释返回结果和将结果存储到正确的空间中去。至于使用消息的连接，由于目前大多数商品软件都使用事件驱动的图形操作系统，在其中的客户/服务器连接均采用消息传送模式。这是因为基于过程连接的请求，响应接口为了实现异步工作，必须引入回调例程。这是接口本身的同步特性决定的。消息本身是异步的。消息传送并不期待返回信息。但只要建立了双向的消息连接，就可以实现同步的RPC调用。事实上，即使是同步RPC也可以用来发送消息，只是不需要等待返回信息。因此，可以说两者是完全可以互相替代的。4. 连接的协议客户与服务器之间传送的是字符流，需要经过分析处理，根据规定的句法，该字符流传达特定的意义。例如，对调用请求需要提供调用的名称、参数的个数、顺序、类型、值，执行的方式、返回值的类型等。在网络中应用的客户/服务器的连接通信中，传送的信息需要更加标准化地表达，即相互通信需遵守建立在硬件支持上的连接协议，即应用层的连接协议。目前常采用的协议有：在数据库系统中广泛应用的SQL查询语言，远程调用规范RPC，或是根据需要设计的用户语言。2.4服务器的调度客户/服务器结构中服务器的调度主要是解决多客户访问和多请求同时执行的复杂性2。系统中独立工作的服务器是无法知道何时会发生多少客户的请求。它必须时刻准备着，处理来自不同客户的请求，并具有同时接受和处理多个不同请求的能力。如果同时或先后到达的请求超过了服务器的能力，服务器应以一定的策略建立起等待队列并通知等待中的客户不能立即处理请求。目前基于服务器应用的操作系统大多是多任务的，因而服务器应用操作系统的多进程或多线程控制，可以较方便地处理多客户多请求的复杂调度问题。其中有两种调度方式：有等待队列和无等待队列的调度方式。无等待队列的方式认为服务器的进程或线程资源是足够的，可以为每一个请求的客户分配各自独占的处理进程或线程。当同时发生请求的个数超过有限资源数时，超出的请求被放到等待队列，等待某些资源释放后按一定策略顺序进行处理。在某些具有分时能力的操作系统中，多进程或多线程的调度变得更多复杂，会造成更加复杂的调度运行问题。下面讨论几种单调度运行方式。1. 进程调度在服务器断建立一个随系统启动的服务器主进程。主进程具有服务器的对外接口及从事管理的操作服务和共享数据。启动后主进程处于等待状态。每当一个客户请求到达时，主进程即产生一个子进程。将客户的请求传送給子进程后，主进程返回到等待状态。子进程响应客户的请求，进行响应的处理。当请求处理完后子进程即被撤销。主进程又叫做“主服务器”，它负责接受请求并调度子进程响应任务，子进程又称“从服务器”，它执行分配給它的特定任务。2. 线程调度线程调度方式中，服务器端仍需要一个随系统启动的主进程。主进程同样具有服务器的对外接口及管理用的共享数据和操作服务。同样，启动后主进程处于等待状态，只是当客户请求到达时，主进程立即产生一个子线程，将请求传达給线程后，主进程返回等待状态。用户请求有线程响应，进行操作，当请求处理完毕后该线程被撤销。3. 线程池调度在服务器启动时除了启动主进程外还创建一个具有n个线程的线程池。即在线程池支持的服务器中，主进程除了等待请求并分配任务外，还管理这一个含有有限数量线程的线程池及一个请求队列。线程池中线程的调度，完全由服务器进程的主线程管理。当客户请求到来时，主线程根据线程资源的负荷情况，有线程池中分配一个空闲的线程，指派它的执行任务。该线程随即运行以响应客户的请求。处理完请求后，线程返回空闲状态，并等待新请求任务的分配。在此过程中，没有新线程的创建和撤销，只是线程忙闲状态的变化。但是，当客户请求的数量超过线程池中的数量时，请求被置于等待队列，等待现正运行线程的终止。因此，此线程池的运行调度需要计数器的参与。计数器维持可用线程的数量，当线程数低于请求的总线程数时，请求即被置于等待队列。图2-3給出了服务器线程池的调度方式。它由透过你信组件、接收/发送转换组件、调度组件、请求队列及线程池5个部分组成。图2-3服务器线程池的调度结构客户通过通信组件与服务器建立连接。服务器接收的（或发送的）信息通过接收/发送转换组件。转换成一定的格式送往调度组件。调度组件根据线程池的使用状态，給请求指派可用线程并启动工作任务。如果线程池暂时没有可用的线程，调度程序将请求送入请求等待队列。调度组件还负责把线程执行的结果或其他服务器的状态信息经接收/发送转换组件转换成适当格式发往用户。请求在服务器的请求队列中以全相关信息存放，以便准确地实现请求的调度处理及正确的结果返回。对于客户/服务器结构，客户端的结构和连接如图2-4所示。图2-4客户端的结构客户通过应用陈圩发送的客户请求经接收/发送转换组件按协议的要求转换成规定的格式。规定格式的信息打包后，经通信组件发送給服务器。服务器接到请求，经过操作处理后，把结果和状态返回給客户。通信组件接收到返回信息后，同样经解包等转换，把信息返送給客户。2.5客户/服务器结构的变异客户/分配器/服务器结构客户/分配器/服务器结构在客户和服务器之间引入了中间层分配器组件。其作用是借助名字服务来实现通信位置的透明性3。同时借助分配器来隐藏客户与服务器之间建立通信连接的细节。设想为了检索科技信息开发一个软件系统。信息的提供者位于局域网和遍布世界各地的广域网上。若要访问提供某一信息的服务器，就必须制定其位置和要执行的服务。由于这组服务器分布在整个网络上，且往往需要动态地改变服务器的位置服务，并使其与满足用户服务的核心功能与通信机制的细节相分离。为此，在客户与服务器间使用分配器组件。分配器实现名字服务。它允许客户用名字来制定服务器而不需提供物理地址，由此实现了位置透明性。同时，分配器还负责建立客户与服务器间的通信信道，将服务器加入到为客户提供服务的应用程序中去。每个服务器由唯一的名字指定，并通过分配器与客户建立联系。而客户依靠分配器去定位某一特定服务器并同服务器建立通信链路。客户、分配器、服务器三者的关系如图2-5所示。图2-5客户/分配器/服务器结构客户的任务是执行特殊领域的任务，为此它需要访问网络上服务器提供的服务。在发送请求給服务器之前，客户向分配器请求信道，然后客户利用这个信道与服务器通信。服务器为客户提供信息或操作。它可以通过名字和地址向分配器进行注册。而分配器负责在客户与服务器之间建立通信信道。它需要取出服务器的名字并把名字映射为服务器的物理地址。分配器使用现有的通信机制为服务器建立通信链路，并将通信句柄返送給客户。若分配器无法启动通信链路，它将遇到的错误通知客户。为了实现名字服务，分配器需要实现用来注册和定位服务器的功能。为了实现3个组件间的交互，需要指定组件间的交互协议。协议指定了为两组件间通信的信道以及传送消息或数据的结构进行初始化和维护的行为。客户分配器服务器结构有3个协议。服务器和分配器之间的交互协议DSprotocol定义了客户请求分配器建立与某一特殊服务器连接时所发生的交互。如果因某种原因通信建立失败，分配器会再尝试几次试图建立通信连接，若仍不成功，分配器通知客户所发生的故障。客户与服务器之间的协议CSprotocol指定客户与服务器之间如何进行交互。这里就不赘述了。为设计实现分配器需确定如何命名服务器。IP地址肯定是不合适的，这样客户就会依赖服务器的具体位置。应引入不带位置信息又唯一确定服务器的名字。可使用字符串或预先定位的常量，如“server x”、“ID_server-x”等。这些独立于位置的名字将由分配器映射为服务器的物理地址。一个分配器中包含一个服务器名字映射为物理位置的库。服务器位置的表示依赖于用来实现客户/服务器通信的低层机构。物理位置可以用套接字端口、TCP端口、共享存储器句柄或其他一些方式来描述。另外还要考虑分配器的性能问题，如果多个客户通过一个分配器要求访问多个服务器时，分配器显然会够成一个瓶颈，若想改善响应和执行时间，可使用多线程。如可在分配器中提供一个线程池，当多个请求到来时可并行处理。也可以引入分布式分配器来取代网络环境中的单个分配器组件。第三章 代理者（Broker）第三章代理者（Broker）3.1概述代理者结构体系主要用于构件中间有隔离组件的分布式系统。这种结构适合于大型的、分布在网络上的多个服务提供者的、甚至是异构的系统。该系统通过远程服务调用进行通信联系。而其中的代理者组件负责协调相互间的通信、转发请求、传送结果及异常信息等。目前，我国正在开发许多公共信息系统。这些系统均运行在广域网中。网络上无多计算机负责支持一项或多项有关事件、信息（如机票、宾馆、旅游路线、导游等）的服务。这些计算机分布在网络上。系统中的用户可以用连在网络上客户机的终端通过使用万维网（WWW）的浏览器检索，查询他们感兴趣的信息。这些检索的信息分布在网络上的不同的服务器上，而往往不仅是一个特定的服务器上。客户端的浏览器软件支持和帮助用户以在线联系的方式从有关服务器上检索信息，再把结果显示在屏幕上。公共信息往往是不断增加、扩展和更新的。因此，系统也希望能不断地改变和增长。而且每个服务之间应互相隔离，以减少变动的影响。同时当系统变动时，譬如移动、增加、迁移服务时，应不影响客户端的服务。因此，终端软件应该不必知道服务器的具体地址而获得服务。当然也可设计一个独立的网络，它连接多有的服务器和终端，形成一个封闭的内联网。但是，信息提供者往往希望在更大范围中开放自己的服务而且更重要的是用户希望得到世界各地分布的信息，因此，使用因特网是这种系统的必然结论。3.2问题分析与方案从上面的分析可以看出，构件这样一个复杂的软件系统，应该将系统的功能分割成许多独立的组件，这样系统才是可分布和扩展的。所以，系统应是由独立的但相互之间又可以互相操作的组件组合，而不是一个整体的应用程序。这样就具有更大的灵活性、可维护性和可变更性。当分布式组件相互通信时，就需要一些过程间的通信手段。因为如果组件各自处理自己的通信，系统就会面临一些问题：系统会变得依赖于所有使用的通信机制，客户机必须要知道服务器的位置，在不同编程语言间的转换等问题。考虑这些因素，该系统的体系结构应该满足一下条件：(1)该系统中的组件应能通过远程网络，以地址透明的方式访问或调用其他组件的服务。(2)该系统应能在运行期间交换、添加或移动各组件。(3)该系统应该对用户隐藏特定系统和特定实现的细节。因此，该系统的解决方案是在客户端与服务器之间引入代理者组件(Broker)，这样可以做到客户机与服务器的隔离。分布在网上的服务器向代理者注册并使自己的服务通过一定的方法接口为客户机使用。客户机通过代理者发送请求以访问服务器的各种服务。而代理者的任务是定位合适的服务器，将请求转发到该服务器，并向客户机返回所得的结果或有关服务器状态的信息。由于使用了代理者，分布性对开发者变得透明了，因而大大降低了开发分布式应用程序的复杂性。同时，由于应用代理者模式，应用程序可以简单地向合适的组件发出消息调用以访问分布式服务，而不必把重点放在低级的进程间通信上。代理者体系结构十分灵活。在此模式下很容易做到对组件动态地改变、添加、删除和重定位。在代理者结构中可以采用对象模型方式。在这个模型下分布式服务被凤爪功能在对象中。这样就把对象模型从单一应用程序扩展到运行在异构机器上，甚至可用在以不同编程语言编写的独立组件组成的分布式应用程序中。代理者体系结构提供了两种核心技术：分布技术与对象技术的集成。3.3代理者系统的结构代理者体系结构由6中成分构成：客户机、服务器、代理者、桥接、客户端代理和服务器端代理。服务器负责实现各种服务。在面向对象的方法中，每个服务通过一个或多个对象实现。服务器通过其接口展示其功能。服务器接口由操作和属性组成。这些接口通过接口定义语言(IDL)或者二元标准来获得4。接口一般聚合了语义上相关的功能。服务器根据任务的不同分为两种。一种是为许多应用领域提供公共服务或公共信息的服务器，另一种是为特定任务实现特定功能的服务器。例如，公共信息查询系统，服务器由提供访问超文本标记语言(HTML)网页功能的WWW服务器组成。WWW服务器用超文本转换协议过程来实现。该过程在特定端口等待输入请求。当一个请求到达服务器时，所请求的文档及所附带的数据使用数据流方式被送到客户机。HTML网页包含可在网络主机上远程执行操作的文档和CGI(公共网关接口)脚本。为了能在客户机的浏览器上显示动画，可将Java applets集成到HTML文档中。CGI脚本在服务器上执行，而Java applets被发送到浏览器在客户端上执行。客户程序是访问一台或多台服务器的应用程序。在此体系结构中，客户机是通过代理者代为转发请求的。当请求的操作完成后，由代理者传送服务器发回的应答。在代理者体系结构中，客户与服务器之间的相互操作基于一种动态模型。服务器也可以作为客户。它们的关系不是静态定义好的。这是与传统的客户/服务器结构不同之处。特别是客户不必知道它们访问的服务器的位置。因而，即使系统在运行期间也可以增加新的服务或移动现有服务到其他地方。在代理者结构中，客户可以直接利用WWW浏览器。客户并不必直接接入网络上，而可以依赖因特网服务提供商(ISP)，由它们提供接入因特网的网关。WWW浏览器用租用线路或用调制解调器连接到ISP的工作站上。连接完成后，它们就可以检索来自服务器的数据流；解释这些数据，并执行在屏幕显示或其他操作。代理者负责从客户到服务器请求的传送和服务器返回给客户的应答或状态信息的传送工作。根据对信息接受着提供的系统唯一标记符，代理者必须用某种方法对接受着进行准确定位。代理者也必须向客户和服务器提供注册服务器和调用服务器操作的API应用程序编程接口。当客户发出一个请求到在本地代理者上注册了的一个服务器时，代理者将直接把请求传送到该服务器。如果服务器此时未激活，代理者将它激活。所有从服务器返回的应答均由代理者转发到发出请求的客户。如果客户所发出请求的服务器在另一个代理者上注册，则本地代理者会在网络上寻找一条路径到达目标的远程代理者，并使用这条路径转发请求。因此需要网络中的代理者能进行互操作。根据系统的需求，一些附加服务如名字与对象的关联(名字服务)以及数据语义不变的转换(列集和散集)都可以集成在代理者软件中。前面举的信息查询系统的例子中，客户机和服务器之间的任何信息交换都须经过代理者传送。客户机通过URL(通用资源定位器)的唯一网络标记符来指定需要的服务。代理者能够根据此URL定位索要的服务，并把请求传送到适当的服务器上。网络中若增加一个新的服务器，它必须向代理者注册。客户与服务器使用因特网提供的网关作为代理者的接口，如表3-1所示。表3-1 网关作为代理者的接口类客户机服务器代理者责任v 实现用户功能v 通过客户端代理向服务器发送请求v 实现服务v 向本地代理者注册自身v 通过客户机代理将应答发回客户机v 注册服务器v 提供APIsv 传递消息v 错误恢复v 通过桥接与其他代理者互操作v 定位服务器客户端代理是客户与代理者之间的隔层。该附加层提供了透明性，使代理者可以对客户隐藏具体的实现细节。例如：在客户机与代理者之间传送消息的进程间通信机制，存储体的创建和删除，参数和结果的列集等实现细节，客户机均不需要了解，从而使客户机像使用本地服务器一样使用远程服务器。通常，客户端代理会把代理者体系结构中的部分对象模型翻译成用来实现客户端编程语言的对象模型。服务器端代理与客户端代理的作用很相似；只是它的工作是负责接受请求，解析收到的消息、散集参数、调用适当的服务等。同时在向客户机发送结果或状态前对它们进行数据语义不变的转换列集。相反，当客户端代理收到代理者发送来的服务器返回的结果或状态信息时，它进行数据的散集(列集的相反转换)并传送給客户。在信息查询的例子中，客户端的WWW浏览器和服务器端的http服务器都提供了与因特网服务商的网关通信的内在能力。它们都实现了用于远程数据交换所必须的协议，如超文本传输的http协议或文件传输的ftp协议。鉴于这种情况，就不必为代理者与它们之间的通信担心了。如果代理者系统运行在异构网络上，可以使用网桥来隐藏两个代理者互相操作时的实现细节。如果在网络上发送请求，两个不同的代理者必须在各自不同的网络和网络操作系统上独立通信，而中间的网桥将各自系统细节封装起来，实现异构网络之间的通信，如表3-2所示。表3-2 代理者的类及责任类 客户端代理服务器端代理网桥责任v 封装特定系统的功能v 客户机与代理者之间的协调v 在服务器内协调服务v 封装特定系统的功能v 服务器与代理者之间的协调v 封装特定网络的功能v 本地代理者与远程代理者的协调代理者系统的通信有两种方式；(1)采用直接通信的系统和采用间接通信的系统。为了达到较好的性能，代理者只建立客户端与服务器的通信链。而通信的任务由参与的组件之间直接进行。也就是说，在通信链建立后，消息和应答在客户端和服务器之间传递而不用代理者做中间层。这种直接通信