分布式软件体系结构

分布式软件体系结构
分布式软件体系结构

分布式软件体系结构

编写目标:

●面向计算机专业高年级本科生与研究生的教程。

●可供从事基于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平台开发,这些例子很容易移植到其他开发平台。读者可从我们的教学网站https://www.360docs.net/doc/9416937985.html,下载这些例子程序的全部源代码。

分布式软件系统是软件开发的一个新兴领域,并且各种分布式计算模型还在不断地迅速发展。由于作者水平有限,书中谬误之处在所难免,恳请广大读者不吝批评指正。

李文军(lnslwj@https://www.360docs.net/doc/9416937985.html,)

周晓聪(lndcs01@https://www.360docs.net/doc/9416937985.html,)

李师贤(lnslsx@https://www.360docs.net/doc/9416937985.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’计算教学计划》中,就将抽象层次列为计算机科学与工程专业学生必须掌握的一个核心概念,这一概念贯穿了计算机学科的众多领域。

抽象是人类认知世界的最基本思维方式之一。罗素曾断言:“发现一对鸡、两昼夜都是数2的实例,一定需要很多年代,其中所包含的抽象程度确实不易达到;至于1是一个数的发现,也必定很困难。”

抽象源于人类自身控制复杂性能力的不足:我们无法同时把握太多的细节,复杂的问题迫使我们将一些相关的概念组织成不同的抽象层次。例如日常生活中的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问题背景

电信收费是当前老百姓关心的热点问题,明明白白消费是每一个消费者的合理要求,但如果打印并邮寄每月话费清单无疑会额外花费大量的人力、物力与财力。随着我国信息基础

设施的不断完善,上网普及率越来越高,通过因特网查询话费将是一条非常可行的途径。本小节以一个简化的电话计费查询程序为例,向读者介绍分布式应用程序的基本概念,并通过对这一简单应用程序的讨论引出分布式软件体系结构中需要考虑的更高级课题。

该例子程序采用纯Java语言编写,利用JDBC/ODBC访问关系数据库,并采用远程方法调用RMI实现客户程序与服务程序之间的交互。客户程序只能通过服务程序间接地访问关系数据库,因而该例子程序属于一种典型的三层设计模型。

1.3.2数据库设计

根据数据库设计原理,我们很容易得到如图1.1所示的典型设计结果。

数据库Telephone

表TelephoneDirectory

number文本类型;电话号码

subscriber文本类型;电话用户姓名

表CallHistory

number 文本类型;电话号码(索引,允许重复)

startTime日期/时间类型;起始通话时间

endTime日期/时间类型;终止通话时间

图1.1 话费查询程序中的数据库设计

其中,表TelephoneDirectory记录了所有用户的电话号码,以number为主关键码;表CallHistory记录了所有电话的通话历史,其中number是外部关键码,建立该属性的允许重复的索引。表CallHistory通过外部关键码number与表TelephoneDirectory相关联。由于同一名字的用户可能登记多个电话号码(例如一个用户同时拥有两部住宅电话和一部移动电话),因而电话计费查询程序除了提供根据电话号码查询话费清单外,还可能提供以用户名字进行查询。本例子程序演示了后者的用法。

程序中利用JDBC/ODBC访问数据库,因而支持使用多种不同的数据库管理系统,只要这些数据库管理系统提供了ODBC接口,如Microsoft Access、Microsoft SQL Server、Sybase、Oracle等。

使用ODBC访问数据库之前,必须将数据库配置为ODBC的一个数据源。假设我们选用了Microsoft Access数据库,则这一安装步骤为:在Windows 98的控制面板中打开“ODBC 数据源(32位)”,单击“添加”按钮后选择一个驱动程序(此处应为“Microsoft Access Driver (*.mdb)”),然后为数据源命名并选择相关联的Access数据库文件,如图1.2所示。

图1.2 在Windows 98中添加ODBC数据源

为进一步提高程序的数据独立性,还可以利用许多关系型数据库管理系统支持的“存储过程”来完成数据查询与更新操作。数据独立性使得在数据库中表的属性或表之间的关联发生某些变化时,程序员无需对应用程序作任何修改。使用存储过程访问数据库还可带来其他好处,例如提高了SQL语句查询与更新数据库的效率,在网络环境下加强了数据库的安全性等等。在不同的数据库管理系统中,存储过程可能有不同的名字,如保留过程、触发器、查询等。

图1.3展示了在Microsoft Access中编写的一个存储过程(即一个查询),它根据指定电话用户名字的参数(Telephone Subscriber)查询该用户登记的所有电话的通话记录。本节的例子程序利用该存储过程实现对数据的查询。

图1.3 根据用户名字查询通话记录的存储过程

1.3.3客户程序与服务程序之间的通信

客户程序与服务程序之间需要通信以交换信息。在本小节的例子程序中,服务程序负责接收客户程序发来的查询请求,完成访问数据库的查询操作,并将查询结果返回给客户程序。客户程序利用图形用户界面与终端用户进行交互,从终端用户获取电话用户的名字并作为参数向服务程序发出查询请求,然后将服务程序返回的查询结果显示给终端用户浏览。

客户程序与服务程序可利用socket进行通信,socket在TCP/IP网络中是一种很原始、高效率的通信方式,但要求客户程序与服务程序自己处理交换消息的编码与解码工作,即程序员必须自定义客户程序与服务程序之间的应用层通信协议,这不仅需要花费大量的编程时间(例如必须考虑连接控制、错误恢复、如何通过防火墙等问题),同时也比较容易产生错误。

一种更好的通信方式是使用远程过程调用(RPC),它将客户程序与服务程序之间的通信接口抽象为过程调用层次,程序员可像调用本地过程一样去调用远程过程,由RPC系统完成参数与返回值的打包、解包与传输等底层任务。但使用RPC不能平滑地与面向对象技术结合在一起。

本小节的例子程序采用了抽象层次更高的远程方法调用(RMI)。RMI是支持多层分布式对象计算的一系列Java类,使得Java应用程序员无需额外的程序设计工作即可实现客户程序与服务程序之间的连接与通信,在客户程序中可以像使用本地对象一样调用服务程序中远程对象的方法。

1.3.4远程方法调用

RMI可看作一种简化的、专用于Java平台的CORBA模型,由JDK 1.1开始支持。RMI

的服务程序通常是一个Java应用程序,而客户程序既可以是一个Java应用程序,也可以是一个Java Applet。

RMI注册表rmiregistry是运行在服务器上的一个后台进程,必须在服务程序启动之前就已启动完毕,它相当于客户程序与服务程序之间的通信网关。服务程序将远程对象的名字注册到RMI注册表,客户程序通过RMI注册表将远程对象名字解析为远程对象引用,通过该对象引用调用远程对象上的方法。

RMI体系结构采用典型的层次设计风格,从上至下分别由桩/框架层、远程引用层和传输层组成,各层之间明确定义了接口与协议,如图1.4所示。

应用程序

RMI系统

图1.4 远程方法调用(RMI)体系结构

RMI系统采用类似CORBA的请求代理机制,桩(stub)是远程对象在客户端的代理,客户程序中的远程对象引用实际上是对本地桩的引用。桩负责将远程调用请求通过远程引用层转发给服务端的框架(skeleton),再由服务端的框架分派给真正的远程对象实现。创建应用程序时,客户程序与服务程序都需要桩,而框架仅服务程序需要。

远程引用层完成调用的语义,例如决定服务程序的对象是单个对象,还是需要与多个位置进行通信的复制对象,这些语义由远程对象的实现提供。远程引用层还为上一层屏蔽了服务程序的激活方式,即桩/框架层不必关心提供远程对象的服务程序是一直在同一机器上运行,还是仅在有方法调用时才被激活(JDK 1.2开始支持不同的激活策略)。

传输层负责建立与管理连接,跟踪远程对象,以及将调用请求分派给合适对象。在服务端,传输层将调用请求向上转发给远程引用层,远程引用层作相应处理后转发给框架,由框架向上调用远程对象的实现,由远程对象的实现完成真正的方法调用。远程调用的返回值送回客户端的路线是:首先经过服务端的框架、远程引用层和传输层,再向上经过客户端的传输层、远程引用层和桩。

RMI在桩/框架层利用了两种关键技术。首先,Java语言专用的对象串行化技术可将对象透明地传送到不同地址空间,桩与框架利用对象串行化技术打包(marshal)与解包(unmarshal)远程调用的参数与返回值。其次,动态类装载技术用于支持将客户端的桩作为远程对象本身,桩实现了相同的远程接口集合,从而支持Java语言的类型检查与类型转换机制。

1.3.5接口定义

一个基于RMI的多层模型分布式应用程序通常包括以下几部分:①远程接口,规定了客户程序与服务程序进行交互的界面;②远程对象实现,为远程接口规定的每一个方法提供真正的实现;③服务程序,远程对象并不是服务程序本身,它需要由服务程序创建并注册,服务程序中的这些真正提供服务的对象实例又称伺服对象(servant);④客户程序,利用服务程序中伺服对象提供的服务完成某一功能。其中,远程接口是编写服务程序与客户程序之

前需要首先考虑的问题。

Java提供了接口与类两种机制:接口不含数据表示方法与操作的具体实现,因而适用于定义对象的规格说明(specification),一个接口可以同时继承多个接口;类给出了数据表示方法与操作实现,因而适用于定义对象的实现(implementation),仅支持对类的单继承。所有远程对象的接口都使用接口来定义,并且必须继承java.rmi.Remote接口,还要求其中的每一个方法必须声明抛出java.rmi.RemoteException异常,因为网络通信或服务程序等原因均可能导致远程调用失败。程序1-1给出了例子程序中通话记录管理器的远程接口定义。

程序1-1 CallManagerInterface.java

// 通话记录管理器CallManager的远程接口

package Telephone;

public interface CallManagerInterface

extends java.rmi.Remote

{

// 根据电话用户名字查询通话记录。

// 参数: subscriber - 电话用户的名字

public Database.DatabaseTableModel getCallHistory(String subscriber)

throws java.rmi.RemoteException;

}

1.3.6服务端程序

程序1-2定义的类CallManager为远程接口CallManagerInterface中的每一个远程方法提供了具体实现。为防止多个客户程序并发地调用数据库查询操作,方法getCallHistory()被定义为同步方法。程序1-3所示ServerApplication是服务程序的主程序,它必须首先装入安全管理器,用于保证动态装载的类不会执行某些敏感操作,如果未指定安全管理器则不允许装入任何RMI类。

程序1-2 CallManager.java

// 通话记录管理器(即远程接口CallManagerInterface的实现)

package Telephone;

public class CallManager

extends java.rmi.server.UnicastRemoteObject

implements CallManagerInterface

{

// 属性定义

protected Database.DatabaseAccess database;

// 缺省构造方法,必须抛出RemoteException异常。

public CallManager()

throws java.rmi.RemoteException

{

database = new Database.DatabaseAccess();

}

// 根据电话用户名字subscriber查询通话记录,实现远程接口指定的方法。

public synchronized Database.DatabaseTableModel getCallHistory(String subscriber) throws java.rmi.RemoteException

{

String sql = ""; // SQL查询语句

Database.DatabaseTableModel table = null; // 返回的二维表模型

System.out.println("Respond to client request: " + subscriber);

try {

sql = "QueryCallHistoryWithSubscriber('" + subscriber + "')";

java.sql.ResultSet rs = database.callQuery(sql);

table = new Database.DatabaseTableModel(rs);

rs.close();

} catch(java.sql.SQLException exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

return table;

}

}

程序1-3 ServerApplication.java

// 服务程序的主程序

public class ServerApplication

{

final static String JDBC_DRIVER = "sun.jdbc.odbc.JdbcOdbcDriver";

public static void main(String args[])

{

// 为RMI设置安全管理器

System.setSecurityManager(new java.rmi.RMISecurityManager());

// 加载JDBC驱动程序

try {

Class.forName(JDBC_DRIVER);

} catch(ClassNotFoundException exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

// 创建并注册伺服对象

try {

// 创建伺服对象

Telephone.CallManager callManager = new Telephone.CallManager();

// 用名字"CallManagerServant001"注册伺服对象

java.rmi.Naming.rebind("CallManagerServant001", callManager);

} catch(java.rmi.RemoteException exc) {

System.out.println(exc.getMessage());

System.exit(1);

} catch(https://www.360docs.net/doc/9416937985.html,.MalformedURLException exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

// 提示服务程序就绪

System.out.println("Call manager in the server is ready ...");

}

}

程序1-4定义的DatabaseAccess类与程序1-5定义的DatabaseTableModel类均用于抽象JDBC访问数据库的行为,在实际应用中我们通常会设计更完善、更个性化的数据库访问程序包来包装JDBC的API。DatabaseAccess主要用于管理服务程序与数据库的连接,并完成数据库的查询与更新操作。DatabaseTableModel负责将数据库查询结果转换为二维表数据模型的形式,方便利用Swing的二维表控件显示查询结果。在基于关系数据库的应用中,二维表控件是最常用的数据表达方式,对于某些具有层次结构的数据则以树控件表达会更加自然。

程序1-4 DatabaseAccess.java

// 实现JDBC与数据库的连接

package Database;

import java.sql.*;

public class DatabaseAccess

{

// 常量定义

protected final String DATABASE_NAME = "jdbc:odbc:Telephone";

// 属性定义

protected Connection connection; // 为数据库建立的连接

protected Statement statement; // 将执行的SQL语句

protected CallableStatement callable; // 将调用的SQL存储过程语句 // 行为定义

// 构造方法,建立与数据库的连接。

public DatabaseAccess()

{

try {

// 建立与指定数据库的连接

connection = DriverManager.getConnection(DATABASE_NAME);

// 如果连接成功则检测是否有警告信息

SQLWarning warn = connection.getWarnings();

while (warn != null) {

System.out.println(warn.getMessage());

warn = warn.getNextWarning();

}

// 创建一个用于执行SQL的语句

statement = connection.createStatement();

callable = null;

} catch(SQLException exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

}

// 析构方法,撤销与数据库的连接。

public synchronized void finalize()

{

try {

connection.close();

} catch(SQLException exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

}

// 利用存储过程执行数据库查询操作。

// 参数: procedure - 存储过程名字

// 返回: 查询结果集

public synchronized ResultSet callQuery(String procedure)

throws SQLException

{

callable = connection.prepareCall("{call " + procedure + "}"); ResultSet rs = callable.executeQuery();

return rs;

}

}

程序1-5 DatabaseTableModel.java

// 根据数据库查询结果构造供JTable控件使用的二维表数据模型

package Database;

import com.sun.java.swing.*;

import java.sql.*;

import java.util.Vector;

public class DatabaseTableModel

extends com.sun.java.swing.table.AbstractTableModel

{

// 属性定义

protected String[] titles; // 列标题

protected int[] types; // 各列的数据类型

protected Vector data; // 二维表的数据

// 构造方法,根据SQL查询结果集rs构造二维表。

public DatabaseTableModel(ResultSet rs)

{

try {

// 取得结果集的元数据

ResultSetMetaData meta = rs.getMetaData();

int columnCount = meta.getColumnCount();

// 取所有列标题与类型名字(注意JDBC元数据的下标从1开始计数)

titles = new String[columnCount];

types = new int[columnCount];

for (int index = 1; index <= columnCount; index++) {

titles[index - 1] = meta.getColumnName(index);

types[index - 1] = meta.getColumnType(index);

}

// 逐行取结果集中的数据

data = new Vector(1000, 100);

while (rs.next()) {

Vector row = new Vector(30);

for (int index = 1; index <= columnCount; index++)

row.addElement(rs.getObject(index));

row.trimToSize();

data.addElement(row);

}

data.trimToSize();

} catch(SQLException exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

}

// 实现AbstractTableModel遗留的抽象方法。

public int getRowCount() {

return data.size();

}

public int getColumnCount() {

return titles.length;

}

public String getColumnName(int col) {

return titles[col];

}

public Object getValueAt(int row, int col) {

return ((Vector) data.elementAt(row)).elementAt(col);

}

}

1.3.7客户端程序

客户程序必须获取远程对象引用才可调用远程对象的方法。一般情况下,远程对象引用

可通过其他远程方法调用的参数或返回值获取,但最早的远程对象引用则必须借助基于URL的注册表,将远程对象标识解析为远程对象引用。

程序1-6给出的查询程序QueryPanel.java中,用于解析远程对象的对象标识为“CallManagerServant001”,它必须与服务程序注册远程对象时采用的名字完全相同。由于构造远程对象的URL时必须包含主机名,所以QueryPanel的构造方法将当前运行的Applet 作为参数。注意程序中远程对象callManager必须声明为远程对象接口CallManagerInterface 的实例,而不是远程对象实现类CallManager的实例。

程序1-6 QueryPanel.java

// 查询时的图形用户界面

package Telephone;

import java.awt.*;

import com.sun.java.swing.*;

public class QueryPanel

extends JPanel

implements java.awt.event.ActionListener

{

// 属性

protected JApplet applet; // 当前正在运行的Applet

protected JTextField subscriberTextField; // 输入用户名字的字段

protected JPanel tablePanel; // 显示二维表的面板

// 构造方法,显示图形用户界面。

// 参数: applet - 启动查询的Applet

public QueryPanel(JApplet applet)

{

this.applet = applet;

setLayout(new BorderLayout());

setBorder(BorderFactory.createEmptyBorder(12, 12, 12, 12));

// 查询条件面板

JPanel conditionPanel = new JPanel(new BorderLayout());

conditionPanel.setBorder(BorderFactory.createEtchedBorder());

add("North", conditionPanel);

// 用户名字面板

JPanel subscriberPanel = new JPanel(new FlowLayout(FlowLayout.LEFT)); conditionPanel.add("Center", subscriberPanel);

// 用户名字的标注

JLabel subscriberLabel = new JLabel("Subscriber\'s Name");

subscriberPanel.add(subscriberLabel);

// 用户名字的文本域

subscriberTextField = new JTextField();

subscriberTextField.setPreferredSize(new Dimension(160, 18));

subscriberPanel.add(subscriberTextField);

// 按钮面板

JPanel buttonPanel = new JPanel(new FlowLayout(FlowLayout.RIGHT));

conditionPanel.add("East", buttonPanel);

// 查询按钮

JButton queryButton = new JButton("Query");

queryButton.setActionCommand("QUERY");

queryButton.addActionListener(this);

buttonPanel.add(queryButton);

// 重置按钮

JButton resetButton = new JButton("Reset");

resetButton.setActionCommand("RESET");

resetButton.addActionListener(this);

buttonPanel.add(resetButton);

// 查询结果是带标签的页面

JTabbedPane resultTabbedPane = new JTabbedPane();

add(resultTabbedPane);

// 查询页面

tablePanel = new JPanel(new BorderLayout());

resultTabbedPane.addTab("Result", null, tablePanel, "");

// 显示上述控件

validate();

setVisible(true);

}

// 实现ActionListener规定的事件处理程序。

// 参数: evt - 发生的事件

public void actionPerformed(java.awt.event.ActionEvent evt)

{

String cmd = evt.getActionCommand();

if (cmd.equals("QUERY")) { // 处理“查询”按钮

String subscriber = subscriberTextField.getText();

if (subscriber.equals("")) return;

// 调用远程对象的方法进行查询

Database.DatabaseTableModel result = null;

try {

// 从Applet取主机名

String host = "//" + applet.getCodeBase().getHost() + "/";

// 远程对象的标识必须与服务程序注册时使用的对象标识完全相同

String objectId = "CallManagerServant001";

// 根据主机名与对象标识解析远程对象

CallManagerInterface callManager = (CallManagerInterface)

java.rmi.Naming.lookup(host + objectId);

// 调用远程对象方法查询用户的通话记录

result = callManager.getCallHistory(subscriber);

} catch(Exception exc) {

System.out.println(exc.getMessage());

System.exit(1);

}

// 将查询结果显示为二维表

JTable table = new JTable(result);

tablePanel.removeAll();

tablePanel.add(new JScrollPane(table));

tablePanel.validate();

} else if (cmd.equals("RESET")) { // 处理“重置”按钮

subscriberTextField.setText("");

subscriberTextField.requestFocus();

}

}

}

程序1-7是客户程序的主程序,而程序1-8则是一个包含了客户程序主程序的HTML 文档,因为客户程序被设计为一个Java Applet,可利用Web页来启动。

程序1-7 ClientApplet.java

// 客户程序的主程序

public class ClientApplet

extends com.sun.java.swing.JApplet

{

public void init()

{

getContentPane().add(new Telephone.QueryPanel(this));

}

}

程序1-8 QueryPage.html

1.3.8部署并运行应用程序

Java语言要求程序包与子目录相对应,因而在编写Java程序之前就必须决定程序包与子目录的名字。表1-1总结了本小节例子程序完整的目录组织与文件清单。

表1-1 目录组织与文件清单

\TelephoneExample –整个例子程序所处的子目录

ClientApplet.java –客户程序

ClientApplet.class -由ClientApplet.java编译得到的字节码

ServerApplication.java –服务程序

ServerApplication.class - 由ServerApplication.java编译得到的字节码

QueryPage.html -调用客户程序的HTML文档

\TelephoneExample\Database –数据库访问程序包

DatabaseAccess.java –提供对数据库的连接与访问服务

DatabaseAccess.class - 由DatabaseAccess.java编译得到的字节码

DatabaseTableModel.java –将数据库查询结果转换为二维数据表模型

DatabaseTableModel.class - 由DatabaseTableModel.java编译得到的字节码

\TelephoneExample\Telephone –电话计费查询程序包

CallManager.java –通话记录管理器的实现

CallManager.class - 由CallManager.java编译得到的字节码

CallManagerInterface.java –通话记录管理器的接口

CallManagerInterface.class - 由CallManagerInterface.java编译得到的字节码 CallManager_Stub.class - 由rmic根据CallManager.java生成的客户端的桩

CallManager_Skel.class - 由rmic根据CallManager.java生成的服务端的框架

QueryPanel.java –查询条件与结果的图形用户界面

QueryPanel.class - 由QueryPanel.java编译得到的字节码

表1-1中的Java字节码由JDK提供的javac编译器生成,而远程对象在客户端的桩与服务端的框架必须另由rmic编译器生成,rmic的输入是Java字节码文件而不是Java源程序文件。

如果开发者不是直接使用JDK,而是使用某种集成化开发环境(如WebGain/Symantec VisualCafé、Borland/Inprise JBuilder、Microsoft Visual J++、IBM Visual Age、Sun Microsystems Java Workshop等),则利用项目(Project)机制可减轻许多编译工作的负担,开发环境会根据项目内容自动调用相应的编译器生成字节码文件以及客户程序桩与服务程序框架文件。表1-2和1-3分别列出了服务程序项目与客户程序项目中应包含的文件。

表1-2 服务程序项目ServerProject

\TelephoneExample

ServerApplication.java

\TelephoneExample\Database

DatabaseAccess.java

DatabaseTableModel.java

\TelephoneExample\Telephone

CallManager.java

CallManagerInterface.java

表1-3 客户程序项目ClientProject

\TelephoneExample

ClientApplet.java

\TelephoneExample\Database

DatabaseTableModel.java

\TelephoneExample\Telephone

QueryPanel.java

CallManagerInterface.java

完成例子程序的编译与布置后,就可以开始运行例子程序了。首先启动RMI远程对象注册表,然后启动服务程序。例如在Windows 98或Windows NT中可在MS-DOS方式键入以下命令(当然也可以做成一个批处理脚本):

prompt> start rmiregistry

prompt> java ServerApplication

图1.5 客户程序运行画面

客户程序必须在服务程序就绪后才可访问远程对象。由于例子程序中的客户程序是一个嵌入在HTML文档中的Applet,故而客户程序既可以是JDK提供的appletviewer,也可以是各种支持Java的浏览器(例如Netscape Navigator 4.7、Microsoft Internet Explorer 5、Sun HotJava等)。appletviewer或浏览器装入带有Applet的HTML文档QueryPage.html后,将启动其中的Applet,Applet显示图形用户界面,用户输入电话用户名字后按Query按钮,并以二维表方式查看查询结果,如图1-5画面所示。

例子程序中的服务程序只实现了文本界面,可以让系统管理员监视服务程序响应了哪些客户程序的请求,如图1-6画面所示。一个实用的服务程序通常会利用图形用户界面提供更完善的监控与管理功能。

图1.6 服务程序运行画面

§ 1.4关于例子程序的讨论

终于完成了我们的第一个分布式应用程序,现在可以放松放松,讨论一下这个例子程序的特点,看看我们在分布式应用程序的哪些方面已经做得不错了,在哪些方面还需进一步考虑与改进。

我们的讨论目标不应只限于该例子程序,而是考虑如何扩展到更庞大、更复杂的分布式软件系统。借用一句流行的广告词:“让我们做得更好”。

1.4.1我们做了什么

例子程序展现了一个比较完整的分布式软件体系结构。从逻辑上看,该例子程序由客户端程序与服务端程序组成,两端程序必须拥有一致的交互接口,交互时采用了较高抽象层次的远程方法调用(RMI)技术。服务程序提供信息与服务(包括访问数据库),客户程序向服务程序发送服务请求,服务程序响应请求并将服务的结果返回给客户程序。显然,服务程序并不知道有哪些客户程序需要服务,以及这些客户程序在什么时候会提出这些服务请求。从物理上看,该例子程序的客户端程序与服务端程序可在一个集中式环境下开发与调试,然后部署到一个实际的分布式运行环境中。

由于选用的编程语言是Java语言,因而例子程序可获得因Java语言而带来的许多好处,例如可充分利用封装与信息隐藏、数据抽象、继承、运行时多态性等面向对象程序设计特性,可通过异常处理提高程序的健壮性,可平滑地结合因特网与Web技术,可享用因特网上关于Java的大量免费资源等。

例子程序的客户端与服务端通信采用RMI技术,访问数据库时采用JDBC应用程序接口(API),因而这是一个纯Java解决方案,平台无关性是该例子程序的一大特点。这种解决方案以Java字节码与Java虚拟机为中间层,使得应用程序可以运行在不同的硬件系统、不同的操作系统、不同的网络协议以及不同的关系数据库管理系统。

由于采用了3层设计模型,例子程序除了提高数据库安全性与访问效率之外,更重要的是这种体系结构很容易扩充为多层设计模型,由多层中间件显式地表达软件系统的系统模型与功能模型,而客户程序则建立在这些高级API的基础之上,采用图形用户界面与终端用户进行交互。这样建立的软件系统具有非常好的可扩展性。

1.4.2我们还可以做什么

尽管本章的例子程序可以正常地工作,但从分布式软件体系结构角度出发,尚有许多课题需要进一步探讨,特别是当要解决的问题变得更庞大、更复杂的时候,分布式软件系统的可扩展性、可靠性、可伸缩性等质量要素变得更加重要。对于本章的例子程序,我们至少可以考虑并改进以下几个问题。

①可互操作性

虽然纯Java解决方案取得了平台无关性的效果,但在程序设计语言方面反而约束了程序员只能使用Java语言。从软件开发的历史与现状来看,不同种类程序设计语言长期积累的大量程序资源与劳动力资源是不容忽视的,更好的平台无关性还应包括程序设计语言的无关性,即用一种语言编写的客户程序可操作由另一种语言编写的服务对象。

这种对象之间的可互操作性(interoperability)对于集成企业现有的计算资源以及重用

很详细的系统架构图-强烈推荐汇总

很详细的系统架构图 --专业推荐 2013.11.7 1.1. 共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA 面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用

最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相 关架构进行描述。 1.2. 技术架构设计 如上图对本次项目整体技术架构进行了设计,从上图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3. 整体架构设计

分布式控制系统

分布式控制系统

题,才能使计算机自动化真正起到其应有的作用。

1975-1980年,在这个时期集散控制系统的技术特点表现为:

从结构上划分,DCS包括过程级、操作级和管理级。过程级主要由过程控制站、I/O 单元和现场仪表组成,是系统控制功能的主要实施部分。操作级包括:操作员站和工程师站,完成系统的操作和组态。管理级主要是指工厂管理信息系统(MIS系统),作为DCS更高层次的应用,目前国内纸行业应用到这一层的系统较少。 DCS的控制程序:DCS的控制决策是由过程控制站完成的,所以控制程序是由过程控制站执行的。 过程控制站的组成: DCS的过程控制站是一个完整的计算机系统,主要由电源、CPU(中央处理器)、网络接口和I/O组成 I/O:控制系统需要建立信号的输入和输出通道,这就是I/O。DCS中的I/O一般是模块化的,一个I/O模块上有一个或多个I/O通道,用来连接传感器和执行器(调节阀)。 I/O单元:通常,一个过程控制站是有几个机架组成,每个机架可以摆放一定数量的模块。CPU所在的机架被称为CPU单元,同一个过程站中只能有一个CPU单元,其他只用来摆放I/O模块的机架就是I/O单元。 国内外应用 分散控制系统 1975 年美国最大的仪表控制公司Honeyw ell 首次向世界推出了它的综合分散控制系统TDC—2000 ( Toal Distributed Control-2000),这一系统的发表,立即引起美国工业控制界高度评价,称之为“最鼓舞人心的事件”。世界各国的各大公司也纷纷仿效,推出了一个又一个集散系统,从此过程控制进入了集散系统的新时期。 在此期间有日本横河公司推出的CEN TUM,美国泰勒仪表公司的MO SË,费雪尔公司的DCÉ —400,贝利公司的N —90,福克斯波罗公司的Cpect rum 和德国西门子公司的Telepermm。 随着计算机特别是微型计算机与网络技术的飞速发展,加上各制造商的激烈竞争,使DCS 很快从70 年代的第一代发展到90 年代初的第三代DCS。尽管在这之前的集散系统的技术水平已经很高,但其中存在着一个最主要的弊病是:各大公司推出的几十种型号的系统,几乎都是该公司的专利产品,每个公司为了保护自身的利益,采用的都是专利网络,这就为全厂、全企业的管理带来问题。 随着计算机的发展与网络开发使各控制厂商更多地采用商业计算机的技术,80年代末许多公司推出新一代的集散系统,其主要特征是新系统的局部网络采用MA P 协议;引用智能变送器与现场总线结构;在控制软件上引入PLC 的顺序控制与批量控制,使DCS 也具有PLC 的功能。 至90 年代初各国知名的DCS 有:3000,Bailey 的IN F I—90,Ro semoun t 的RS—3,W est Hoo se 的WDPF,L eeds &Non th rup 的MAX—1000,Foxbo ro 的IöA S,日本横河的CEN TUM。这里所提到的均为大型的DCS,为了适应市场的需要各厂商也开发了不少中小型的DCS 系统如S—9000,MAX—2,LXL,A 2 PACS 等等。

各种系统架构图

各种系统架构图

————————————————————————————————作者:————————————————————————————————日期: ?

各种系统架构图 与详细说明 2017.07.30 ?

1.1.共享平台逻辑架构设计? 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。

软件体系结构总结

第一章:1、软件体系结构的定义 国内普遍看法: 体系结构=构件+连接件+约束 2、软件体系结构涉及哪几种结构: 1、模块结构(Module) 系统如何被构造为一组代码或数据单元的决策 2、构件和连接件结构(Component-And-Connector,C&C) 系统如何被设计为一组具有运行时行为(构件)和交互(连接件)的元素 3、分配结构(Allocation) 展示如何将来自于模块结构或C&C结构的单元映射到非软件结构(硬件、开发组和文件系统) 3、视图视点模型 视点(View point) ISO/IEC 42010:2007 (IEEE-Std-1471-2000)中规定:视点是一个有关单个视图的规格说明。 视图是基于某一视点对整个系统的一种表达。一个视图可由一个或多个架构模型组成 架构模型 架构意义上的图及其文字描述(如软件架构结构图) 视图模型 一个视图是关于整个系统某一方面的表达,一个视图模型则是指一组用来构建 4、软件体系结构核心原模型 1、构件是具有某种功能的可复用的软件结构单元,表示了系统中主要的计算元素和数据存储。 2.连接件(Connector):表示构件之间的交互并实现构件

之间的连接 特性:1)方向性2)角色3)激发性4)响应特征 第二章 1、软件功能需求、质量属性需求、约束分别对软件架构产生的影响 功能性需求:系统必须实现的功能,以及系统在运行时接收外部激励时所做出的行为或响应。 质量属性需求:这些需求对功能或整个产品的质量描述。 约束:一种零度自由的设计决策,如使用特定的编程语言。 质量原意是指好的程度,与目标吻合的程度,在软件工程领域,目标自然就是需求。 对任何系统而言,能按照功能需求正确执行应是对其最基本的要求。 正确性是指软件按照需求正确执行任务的能力,这无疑是第一重要的软件质量属性。质量属性的优劣程度反映了设计是否成功以及软件系统的整体质量。 系统或软件架构的相关视图的集合,这样一组从不同视角表达系统的视图组合在一起构成对系统比较完整的表达

很详细的系统架构图-强烈推荐

很详细的系统架构图--专业推荐 2013.11.7

1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相

关架构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计,从上图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节,我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明,通过上述设计,我们对整体项目的架构图进行了归纳如下:

最新各种系统架构图与详细说明资料

各种系统架构图与详细说明 2012.07.30

1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现

采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。 1.2.技术架构设计

如上图对本次项目整体技术架构进行了设计,从上图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节,我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明,通过上述设计,我们对整体项目的架构图进行了归纳如下: 综上,我们对整体应用系统架构图进行了设计,下面我们将分别进行说明。

学生分布式系统复习题与参考答案2

一、填空题 1.访问透明性是指对不同数据表示形式以及资源访问方式的隐藏。而位置透明是用户无法判别资源在系统中的物理位置。 2. 迁移透明性是指分布式系统中的资源移动不会影响该资源的访问方式。而复制透明是指对同一个资源存在多个副本的隐藏。 3. 一个开放的分布式系统就是根据一系列准则来提供服务,这些准则描述了所提供服务的语法和语义。 4. 集群计算系统一个突出的特征是它的同构性;它提供了最大限度的分布式透明性。可用于单个程序在多台计算机上并行地运行。 5. 网格计算系统具有高度的异构性:其硬件、操作系统、网络、管理域和安全策略等都不尽相同。 6. 网格计算系统一个关键问题是如何把来自不同计算机组织的资源集中起来,使一组人或机构进行协调工作。 7. 分布式事务处理的四个特性是:原子性、一致性、独立性和持久性。 8. 分布式普适系统应用程序的需求归纳为三种,它们是:接受上下文的变化、促使自主合成、认可共享为默认行为。 9. 分布式系统体系结构样式很多,其最重要的有:分层体系结构;基于对象的体系结构、以数据为中心的体系结构以及基于事件的体系结构等四类。10. 客户/服务器结构的应用程序通常划分为三层,它们是:用户接口层、处理层和数据层。 11. 在结构化点对点体系结构中覆盖网络是用一个确定性的过程来构成的,这个使用最多的进程是通过一个分布式哈希表来组织进程的。 12. 超级对等体通常是维护一个索引或充当一个代理程序的结点。 13. 分布式软件体系结构主要分集中式、非集中式和各种混合形式三大类。其非集中式体系结构又分为 结构化的点对点、非结构化的点对点、超级对等体 三种。 14. 实现软件自适应的基本技术分为要点分离、计算 映像和基于组件的设计三种类型。 15. 分布式的自主系统指的是自我管理、自我恢复、 自我配置和自我优化等各种自适应性。 16. 一个线程独立地执行它自己的程序代码。线程系 统一般只维护用来让多个线程共享CPU所必需的最 少量信息。 17. 有两种实现线程线程包的基本方法:一是可以构 造一个完全在用户模式下执行的线程;二是由内核 来掌管线程并进行调度。 18. 分布式系统中的多线程通常有:多线程用户和多 线程服务器两大类型。而以分发器/工作者模型组织 起来的多线程服务器是最为流行的一种。 19. 虚拟化可采用两种方法,一是构建一个运行时系 统,提供一套抽象指令集来执行程序。二是提供虚 拟机监视器。 20. 在服务器的组织结构中,迭代服务器是自己处理 请求,将响应返回给客户;而并发服务器将请求传 递给某个独立线程或其他进程来处理。 21. 服务器集群在逻辑上由三层组成,第一层是逻辑 交换机;第二层是应用/计算服务;第三层是文件/ 数据库系统。 22. 在代码迁移的框架结构中,进程包含三个段,它 们是代码段、资源段和执行段三个段。 23. 进程对资源的绑定有三种类型:一是按标识符绑 定;二是按值绑定;三是按类型绑定。而三种类型 的资源对机器的绑定是未连接资源、附着连接资源 和紧固连接资源。 24. 中间件是一种应用程序,它在逻辑上位于应用层 中,但在其中包含有多种通用协议,这些协议代表 各自所在的层,独立于其他更加特别的应用。 25. 在RPC操作中,客户存根的功能是将得到的参 数打包成消息,然后将消息发送给服务器存根。 26. 所有DCE的底层编程模型都是客户-服务器模 型。而DCE本身的一部分是由分布式文件服务、目 录服务、安全服务以及分布式时间服务等构成的。 27. IDL编译器的输出包括三个文件,它们是头文件、 客户存根和服务器存根。 28. 在面向消息的通信中,通常分为面向消息的瞬时 通信和持久通信两种机制。 29. 在面向消息的瞬时通信中,通常采用套接字接口 和消息传递接口。 30. 在面向持久的通信中,消息队列系统为持久异步 通信提供多种支持。它提供消息的中介存储能力。 31. 在消息队列系统中,队列由队列管理器来管理, 它与发送或接收消息的应用程序直接交互。 32. 在消息队列系统中,转换是由队列网络中特定结 点完成的,这些结点称为消息转换器。 33. 在面向流的通信中,数据流的传输模式有异步传 输模式、同步传输模式和等时传输模式等三种。 34. 在流与服务质量(QOS)描述中,服务质量特性指 的是数据传输所要求的比特率、创建会话的最大延 时、端到端的最大延时、最大延时抖动以及最大往 返延时等。 35. 流同步有两种类型,一种是在离散数据流与连续 数据流之间保持同步;另一种是连续数据流之间的 同步。 36. 在流同步的机制中,需要研究的两个问题是:一 个是两个流同步的基本机制;二是在网络环境下这 些机制的分布式版本。 37. 应用层多播的基本思想是结点组织成一个覆盖 网络,然后用它来传播信息给其成员。一个重要的 因素是网络路由器不在组成员中。

很详细的系统架构图-强烈推荐

很详细的系统架构图 专业推荐 2013.11.7

1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。

综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计,从上图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节,我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明,通过上述设计,我们对整体项目的架构图进行了归纳如下:

第11讲多高层房屋钢结构——结构体系类型及其特点1多层

第11讲多(高)层房屋钢结构——结构体系类型及其特点(一) 1、多层房屋钢结构的结构体系类型有哪些?阐述各自的抗侧力单元。 答: 多层房屋钢结构常见结构类型有纯框架体系、柱-支撑体系和框-支撑体系。如果抗侧刚度不满足,还可采用双重抗侧力体系,主要采用钢框架-支撑体系、钢框架-剪力墙体系以及钢框架-核心筒体系。纯框架体系的抗侧力单元为平面框架,柱-支撑体系的抗侧力单元为支撑,框-支撑体系的抗侧力单元为无支撑的平面框架和支撑;钢框架-支撑体系、钢框架-剪力墙体系以及钢框架-核心筒体系的抗侧力单元除了钢框架外,还分别由支撑、剪力墙以及核心筒作为抗侧力单元。 2、试述纯框架体系在水平荷载作用下的受力和变形特征? 答: 水平荷载作用下梁柱刚接的框架结构如同空腹桁架结构,结构一侧的部分柱脚产生轴向拉力,另一侧的部分柱脚则产生轴向压力,这些轴向力将形成力偶,平衡外部水平荷载产生的倾覆力矩;另外,楼层剪力使该层框架柱产生弯矩和剪力,而柱端弯矩又使框架梁两端产生反对称的梁端弯矩和剪力。 平面框架结构在水平荷载作用下的变形包括两部分,一部分是由于水平荷载作用下的倾覆力矩使竖向构件(柱)承受轴向拉力或压力,进而使结构整体产生弯曲变形;另一部分为各层梁、柱在剪力作用下引起的框架整体剪切变形。因此,框架整体侧移曲线呈剪切型。 3、框架结构有哪些优点?适于多少层的钢结构房屋? 答: 优点:无承重墙,使建筑设计具有一定的自由度;外墙采用非承重构件,可使建筑立面设计灵活多变;轻质墙体的使用还可以大大降低房屋自重,减小地震作用,降低结构和基础造价;构件易于标准化生产,施工速度快,而且结构各部分的刚度比较均匀,自振周期长,对地震作用不敏感。 适用层数:因框架结构的抗侧刚度较小,适于30层以下的房屋建筑。在地震区,一般不超过15层。 4、试述框架-支撑体系在水平荷载下的变形特点? 答: 在框架-支撑体系中,框架属于剪切型构件,支撑近似于弯曲型构件。当楼板可视为刚性体且结构不发生整体扭转时,在刚性楼盖的协调下,使各榀框架与各个支撑的变形相互协调—致,因此,框架-支撑体系可以简化成用刚性连杆将框架与支撑并联,其侧移属于弯剪型变形。

软件总体架构图

1软件总体架构图 软件结构如图1.1所示: 大容量数据采集与处理程序 工业以太网 网关路由程序 CGI BOA TCP/IP 操作系统界面 ucLinux 内核 MicroBlaze Ip 设计 图1.1 FPGA 数据采集软件架构图 以上是系统的软件结构框图,我们下面将就具体每一个步骤的设计进行一个简要的描述: 2 MicroBlaze IP 核设计 IP 字面意思是知识产权,在微电子领域,具有知识产权的功能模块成为IP Core 或IP 核。IP 可以用来生成ASIC 和PLD 逻辑功能块,又称为虚拟器件VC 。IP 核可以有很多种,比如UART 、CPU 、以太网控制器、PCI 接口等。根据IP 核描述的所在集成电路的设计层次,IP 可以分为硬IP 、软IP 、固IP 。硬IP 的芯片中物理掩膜布局已经得到证明,所有的验证和仿真工作都已经完成,用它可以直接生产硅片,系统设计者不能再对它进行修改。而软IP 是以行为级和RTL 级的Verilog 或VHDL 代码的形式存在,它要经过逻辑综合和版图综合才能最终实现在硅片上。固IP 则介于两者之间。 Xilinx 公司的MicroBlaze32位软处理器核是支持CoreConnect 总线的标准外设集合。MicroBlaze 处理器运行在150MHz 时钟下,可提供125 D-MIPS 的性能,非常适合设计针对网络、电信、数据通信和消费市场的复杂嵌入式系统。 1.MicroBlaze 的体系结构 MicroBlaze 是基于Xilinx 公司FPGA 的微处理器IP 核,和其它外设IP 核一起,可以完成可编程系统芯片(SOPC)的设计。MicroBlaze 处理器采用RISC 架构和哈佛结构的32位指令和数据总线, 可以全速执行存储在片上存储器和外部存储器中的程序, 并访问其中的数据, 如图4.1所示

软件系统架构图_参考案例

各种软件开发系统架构图案例介绍

第一章【荐】共享平台架构图与详细说明 1.1.【荐】共享平台逻辑架构设计 (逻辑指的是业务逻辑) 注:逻辑架构图 --主要突出子系统/模块间的业务关系, 这里的逻辑指的是业务逻辑如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现

采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。 1.2.【荐】技术架构设计 注:技术架构图 --主要突出子系统/模块自身使用的技术和模块接口关联方式

各种系统架构图与详细说明

各种系统架构图与详细说明

1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。

1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计,从上图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节,我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明,通过上述设计,我们对整体项目的架构图进行了归纳如下: 综上,我们对整体应用系统架构图进行了设计,下面我们将分别进行说明。 1.3.1.应用层级说明 整体应用系统架构设计分为五个基础层级,通过有效的层级结构的划分可以全面展现整体应用系统的设计思路。 基础层 基础层建设是项目搭建的基础保障,具体内容包含了网络系统的建设、机房建设、多媒体设备建设、存储设备建设以及安全设备建设等,通过全面的基础设置的搭建,为整体应用系统的全面建设良好的基础。 应用数据层 应用数据层是整体项目的数据资源的保障,本次项目建设要求实现全面的资源共享平台的搭建,所以对于应用数据层的有效设计规划对于本次项目的建设有着非常重要的作用。 从整体结构上划分,我们将本次项目建设数据资源分为基础的结构型资源和非结构型资源,对于非结构型资源我们将通过基础内容管理平台进行有效的管理维护,从而供用户有效的查询浏览;对于结构型数据,我们进行了有效的分类,具体包括政务公开资源库、办公资源库、业务经办资源库、分析决策资源库、内部管理资源库以及公共服务资源库。通过对资源库的有效分类,建立完善的元数据管理规范,从而更加合理有效的实现资源的共享机制。

分布式系统复习题及参考答案

关于分布式系统复习题与参考答案 一、填空题(每题n分,答错个扣分,全错全扣g,共计m分) 1.访问透明性是指对不同数据表示形式以及资源访问方式的隐藏。而位置透明是用户无法判别资源在系统中的物理位置。 2. 迁移透明性是指分布式系统中的资源移动不会影响该资源的访问方式。而复制透明是指对同一个资源存在多个副本的隐藏。 3. 一个开放的分布式系统就是根据一系列准则来提供服务,这些准则描述了所提供服务的语法和语义。 4. 集群计算系统一个突出的特征是它的同构性;它提供了最大限度的分布式透明性。可用于单个程序在多台计算机上并行地运行。 5. 网格计算系统具有高度的异构性:其硬件、操作系统、网络、管理域和安全策略等都不尽相同。 6. 网格计算系统一个关键问题是如何把来自不同计算机组织的资源集中起来,使一组人或机构进行协调工作。 7. 分布式事务处理的四个特性是:原子性、一致性、独立性和持久性。 8. 分布式普适系统应用程序的需求归纳为三种,它们是:接受上下文的变化、促使自主合成、认可共享为默认行为。 9. 分布式系统体系结构样式很多,其最重要的有:分层体系结构;基于对象的体系结构、以数据为中心的体系结构以及基于事件的体系结构等四类。 10. 客户/服务器结构的应用程序通常划分为三层,它们是:用户接口层、处理层和数据层。 11. 在结构化点对点体系结构中覆盖网络是用一个确定性的过程来构成的,这个使用最多的进程是通过一个分布式哈希表来组织进程的。 12. 超级对等体通常是维护一个索引或充当一个代理程序的结点。 13. 分布式软件体系结构主要分集中式、非集中式和各种混合形式三大类。其非集中式体系结构又分为结构化的点对点、非结构化的点对点、超级对等体三种。 14. 实现软件自适应的基本技术分为要点分离、计算映像和基于组件的设计三种类型。 15. 分布式的自主系统指的是自我管理、自我恢复、自我配置和自我优化等各种自适应性。 16. 一个线程独立地执行它自己的程序代码。线程系统一般只维护用来让多个线程共享CPU 所必需的最少量信息。 17. 有两种实现线程线程包的基本方法:一是可以构造一个完全在用户模式下执行的线程;二是由内核来掌管线程并进行调度。 18. 分布式系统中的多线程通常有:多线程用户和多线程服务器两大类型。而以分发器/工作者模型组织起来的多线程服务器是最为流行的一种。 19. 虚拟化可采用两种方法,一是构建一个运行时系统,提供一套抽象指令集来执行程序。二是提供虚拟机监视器。 20. 在服务器的组织结构中,迭代服务器是自己处理请求,将响应返回给客户;而并发服务器将请求传递给某个独立线程或其他进程来处理。 21. 服务器集群在逻辑上由三层组成,第一层是逻辑交换机;第二层是应用/计算服务;第三层是文件/数据库系统。 22. 在代码迁移的框架结构中,进程包含三个段,它们是代码段、资源段和执行段三个段。 23. 进程对资源的绑定有三种类型:一是按标识符绑定;二是按值绑定;三是按类型绑定。而三种类型的资源对机器的绑定是未连接资源、附着连接资源和紧固连接资源。 24. 中间件是一种应用程序,它在逻辑上

分布式系统架构设计

本文作者Kate Matsudaira是一位美丽的女工程副总裁,曾在Sun Microsystems、微软、亚马逊这些一流的IT公司任职。她有着非常丰富的工作经验和团队管理经验,当过程序员、项目经理、产品经理以及人事经理。专注于构建和操作大型Web应用程序/网站,目前她的主要研究方向是SaaS(软件即服务)应用程序和云计算(如大家所说的大数据)。 本文是作者在AOSA一书介绍如何构建可扩展的分布式系统里的内容,在此翻译并分享给大家。 开源软件已经成为许多大型网站的基本组成部分,随着这些网站的逐步壮大,他们的网站架构和一些指导原则也开放在开发者们的面前,给予大家切实有用的指导和帮助。 这篇文章主要侧重于Web系统,并且也适用于其他分布式系统。 Web分布式系统设计的原则 构建并运营一个可伸缩的Web站点或应用程序到底是指什么?在最初,仅是通过互联网连接用户和访问远程资源。 和大多数事情一样,当构建一个Web服务时,需要提前抽出时间进行规划。了解大型网站创建背后的注意事项以及学会权衡,会给你带来更加明智的决策。下面是设计大型Web系统时,需要注意的一些核心原则: ?可用性 ?性能 ?可靠性 ?可扩展 ?易管理 ?成本 上面的这些原则给设计分布式Web架构提供了一定的基础和理论指导。然而,它们也可能彼此相左,例如实现这个目标的代价是牺牲成本。一个简单的例子:选择地址容量,仅通过添加更多的服务器(可伸缩性),这个可能以易管理(你不得不操作额外的服务器)和成本作为代价(服务器价格)。 无论你想设计哪种类型的Web应用程序,这些原则都是非常重要的,甚至这些原则之间也会互相羁绊,做好它们之间的权衡也非常重要。 基础

软件体系结构论文:一种面向方面软件体系结构模型

软件体系结构论文:一种面向方面软件体系结构模型 摘要: 为了分离软件系统中的核心关注点和横切关注点,通过引入面向方面软件开发的思想设计了一种面向方面软件体系结构模型,并详细分析了该模型的三个基本构成单元,即构件、连接件和方面构件。最后通过一个网上支付实例验证了该模型具有一定的理论意义和实用价值。 关键词: 面向方面软件体系结构;横切关注点;构件;连接件;方面构件 20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上,然而随着软件系统规模越来越大,对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧,软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式,在较高层次上把握系统各部分之间的内在联系,将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比,软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题,有利于构件的重用,也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和

横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标,横切关注点是那些与核心关注点之间有横切作用的关注点,如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点,使得系统的设计和维护变得容易很多。 Extremadura大学的Navasa等人[1]在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中,称之为面向方面软件体系结构(aspect oriented software architecture,AO-SA),这样能够结合两者的优点,但是并没有给出构建面向方面软件体系结构的详细方法。 尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识,但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspect component)这一新的构成单元,通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少,对它的构成单元模型的研究更少,通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人[2]提出的,它是在自适应可插拔构件(adaptive plug and play component,APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的,但它关于请求接口和服务接口的定义很模糊,未能给出一个清晰的方面构件模型。Pawlak等人

多层轻钢住宅的结构体系与设计方案

多层轻钢住宅的结构体系 与设计 摘要:多层轻钢住宅是一种新型建筑体系,也是目前国内住宅研究和开发的方向。但是它的设计方法,结构体系,结构特点,常用经济指标不为设计者所熟悉,因此多层轻钢住宅示范楼的设计与施工是推广这种新型体系的最好方式。本文结合某轻钢住宅示范楼介绍了它的结构体系,布置特点,计算方法等。 关键词:多层民用住宅轻钢结构1. 轻钢住宅在我国的发展我国轻型钢结构经过20 多年的发展历史,虽然起步并不晚,主要由于经济与技术的原因使得多层轻钢住宅的发展受到制约。国内最早出现的轻钢结构住宅是94 年11 月建于上海浦东北蔡的8 层钢结构住宅,采用冷弯成型的矩形钢管混凝土柱和U 型冷弯型钢组合梁组成框架。其特点是采用稻草板作外墙和楼板的组件,单位面积用钢量34kg/m2 。天津经济开发区太平村是我国住宅产业化的探 索基地之一,来自中国,日本,美国,加拿大等15 个国家和地区的95 名参展商展示了各自的产品,其中钢结构住宅 均采用框架结构。楼板及墙体、屋顶均采用复合结构,工厂预制,现场安装,缩短了施工工期。长沙远大集团建造的

8 层钢结构公寓,称之为集成化建筑。该建筑装有中央空调一体化机组,整体浴室,“五表” 远传系统等现代化设备。室内设计考究,体现了钢结构住宅的风格和质量,表明了钢结构住宅的良好发展前景。表1 为若干轻钢住宅经济技术指标。当前,国家将住宅产业作为国民经济新的经济增长点。为居民提供高质量的符合市场需求的商品化住宅成为必然趋势。国家鼓励发展表1 轻钢住宅经济技术指标工程名称马钢住宅实验楼北京西三旗水电工程宿舍涿州中铁 紫荆关钢结构公司实验楼保定太行集团轻钢住宅示范楼结构体系12 层框架-支撑体系6 层框剪体系6 层钢框架-砼核心筒体系空间框架结构结构型式热轧H 型钢H 型钢,压型钢板组合楼板焊接工型梁柱H 形柱,工形梁用钢量(kN/m2) 52 63 46 52 单位造价(元) 1100 1100 1200 900 “ 新型建筑体系” ,已将其列入优先发展的高新技术领域中。国务院1999 年颁发的72 号文件提出要发展钢结构住宅产业,在沿海大城市限期停止使用粘土砖。建设部标准定额研究司正在编制与修改与多层钢结构房屋密切相关的技术规程。建设部科技司在今年上半年分别召开了“ 钢结构住宅产业化技术导则编制研讨会” 和“钢结构住宅建筑体系及关键技术研究课题立项评审会”。通过了18 个包括钢结 构住宅建筑体系及其关键和试点工程的立项。国家政策为钢结构住宅开发创造了条件,钢结构产业化住宅有望在最近取得突破性进展。2. 多层轻钢住宅的优势过去我国大量开发的是以小开间砖混结构为主的住宅。这种住宅体系由于使用实心粘土砖,浪费土地资源,建筑

软件体系结构 4+1模型案例

案例教学1:4+1视图方法进行软件体系结构设计 要开发出用户满意的软件并不是件容易的事,软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处,分门别类地将不同需求一一满足。本文从理解需求种类的复杂性谈起,通过具体案例的分析,展示了如何通过RUP的4+1视图方法,针对不同需求进行体系结构设计,从而确保重要的需求一一被满足。 1、呼唤体系结构设计的多重视图方法 灵感一闪,就想出了把大象放进冰箱的办法,这自然好。但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。 需要体系结构设计的多重视图方法,从根本上来说是因为需求种类的复杂性所致。以工程领域的例子开道吧。比如设计一座跨江大桥:我们会考虑"连接南北的公路交通"这个"功能需求",从而初步设计出理想化的桥墩支撑的公路桥方案;然后还要考虑造桥要面临的"约束条件",这个约束条件可能是"不能影响万吨轮从桥下通过",于是细化设计方案,规定桥墩的高度和桥墩之间的间距;另外还要顾及"大桥的使用期质量属性",比如为了"能在湍急的江流中保持稳固",可以把大桥桥墩深深地建在岩石层之上,和大地浑然一体;其实,"建造期间的质量属性"也很值得考虑,比如在大桥的设计过程中考虑"施工方便性"的一些措施。 和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似,软件系统的需求种类也相当复杂,具体分类如图1所示。

图1 软件需求分类的复杂性 2、超市系统案例:理解需求种类的复杂性 例子是最好的老师。为了更好地理解软件需求种类的复杂性,我们来分析一个实际的例子。在表1中,我们列举了一个典型的超市系统的需求子集,从这个例子中可以清晰地看到需求可以分为两大类:功能需求和非功能需求。

多种软件系统架构图与说明

各种系统架构图 与详细说明 1.1.共享平台逻辑架构设计 1.2.如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面:应用系统建设1 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开 发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 应用资源采集2 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源 审核和分析处理后进入到数据交换平台进行有效管理。数据分析与展现3 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的 搭建。数据的应用4 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。综上,我们对本次项目整体逻辑架构进行了有效的构建,下面我们将从技术角度对相关架构进行描述。 技术架构设计1.3.如上图对本次项目整体技术架构进行了设计,从上图我们可以 看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。整体架构设计 1.4. 上述两节,我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明,通过上述设计,我们对整体项目的架构图进行了归纳如下:综上,我们对整体应用系统架构图进行了设计,下面我们将分别进行说明。.

.NET多层体系结构设计

基于.NET平台架构P&G移动应用解决方案的研究硕士论文节选 ?2006 陈栋良国防科技大学研究生院 3.3 多层体系结构 本方案设计的多层体系结构框架,不仅为P&G移动解决方案提供框架,也为今后一段时间P&G其它基于.NET技术的业务系统提供基础框架。见图3.3。 图3.3 多层体系结构框架:业务框架 本论文不会对基于JA V A的多层体系结构框架作研究,但是虽然JA V A/J2EE 和.NET架构的组成元素有所不同,后端的架构设计概念是相通的。 3.3.1 目标 P&G多层体系结构框架的研究目标是: (1) 提供一套应用程序模式和应用程序块来加快应用程序的设计和开发,从而提高开发的竞争力。 (2) 在具体的代码实现方面,整合公司以前的开发经验,标准和最佳实践,构建基础服务模块,从而能重用已有知识,最大化公司知识资产。 (3) 建立应用软件架构基础框架,以支持应用程序模式和应用程序块的开发。 (4) 必须兼顾安全性(Security)、可用性(Availability)、可靠性(Reliability)、扩展性(Scalability)、性能(Performance)…等系 统层次的非功能性需求(Non-Functional requirement)。 基于P&G多层体系结构框架,开发团队可以在软件开发生命周期的初期更早的开始最初程序的构建。由于各种业务基于同一框架和同一基本服务,避免了重复性开发,在減少项目成本的同时,也会提高软件的质量。

3.3.2 框架设计 本框架是一整套设计和指南用于提供总体的应用程序体系结构,主要为分布式多层应用程序提供结构、集成、性能、安全、稳定性和可靠性等方面的设计。 3.3.2.1 N-Tier 应用程序体系结构 P&G多层体系结构框架是基于Microsoft .NET Framework 1.1以及微软推荐的N-Tier应用程序结构,见图3.4[6]。 它是由不同类型的应用程序块和应用程序模式组成,合并表示层、业务层、数据层以及基础服务等的最佳实践,而安全、通信等基本服务贯穿于所有层。 图3.4 Microsoft N-Tier Application Architecture 3.3.2.2 P&G多层体系结构应用框架 P&G多层体系结构应用框架分成不同的层次,每一个层次有着不同的角色和功能特性。为了代码的可维护性以及代码优化的目标,当我们在建立分布式应用程序时,在作出技术或者设计决策,并用不同方式布置应用程序时,必须采用清晰的体系结构,见图3.5。

相关文档
最新文档