（通信与信息系统专业论文）基于corba的分布式系统数据传输技术研究.pdf

西北_ t - 业大学硕士学位论文 摘要 分布式技术的历史可以追溯到2 0 世纪8 0 年代中期，那时主要采用客 户机服务器结构来构建分布式系统。然而到了9 0 年代以后，客户机朋日务 器结构发生了深刻变革：客户机与服务器的界限日益模糊，多层结构开始 流行；分布式成为高性能网络应用的重要特征，其理念总体上已从紧耦合 的、地域集中的、同构的机器转移到松耦合的、远程的、异构的机器上。 与此同时，面向对象技术也发展成为软件开发的首选技术。于是，分布式 对象技术就成为了构建大型复杂系统的主流技术。 本文结合作者近年在分布式应用领域的研发工作对分布式系统的数据 传输技术进行了深入论述。 在分布式系统中，采用何种机制在各分布节点间传输数据是系统设计需要考 虑的重要方面。本文基于c o r b a ( 通用对象请求代理结构) 技术提出一种在分 布节点间提供数据传输服务的数据服务模型，并给出数据服务在分布式监控系统 中的一种实现。根据数据消费者请求数据的不同类型，数据服务分为持久数 据服务和实时数据服务，文章分别对= 者的时间性能进行了分析。针对持 久数据服务，本文从远程调用的粒度、消息尺寸以及不同i d l 数据类型三个方 面对时间性能的影响加以阐述；针对实时数据服务，由于现有的关于c o r b a 事 件服务的性能分析资源相对缺乏，本文基于v i s i b r o k e r 的对象包装和拦截器技术 创造性地给出了性能测试和分析的实验方案，根据试验数据对实时数据服务的 性能进行了分析，同时也比较了c o r b a 事件服务的四种不同数据传输模式 f 即经典的推模式、经典的拉模式、混合推拉模式和混合拉，推模式) 的传输效率。 对测试数据进行的分析表明：事件服务的数据传输效率基本上能满足实时数 据数据服务的实时性需要；在事件服务的四种数据传输方式种，经典的推模式的 性能要更优秀。这一研究结论对基于c o r b a 的一般分布式应用具有普遍意 义。文章最后对数据服务的研究工作进行了总结并提出了进一步探讨的方 向。 关键字 分布式系统，分布式对象，通用对象请求代理结构，远程接口调用 事件服务 西北工业大学硕士学位论文 一_ _ _ - - - _ _ _ _ - - _ _ _ - - _ - a b s t r a c t d i s t r i b u t e dt e c h n o l o g y ( d t ) c a nb ed a t e db a c kt ot h em i d d l eo f19 8 0 s w h e nd i s t r i b u t e d s y s t e m w a s m o s t l y b u i l tw i t hc l i e n t s e r v e ra r c h i t e c t u r e h o w e v e r ，s i g n i f i c a n tc h a n g e sh a v eh a p p e n e dt ot h i sa r c h i t e c t u r es i n c et h ee n d o f19 9 0 s ：t h eb o r d e ro fc l i e n ta n ds e r v e ri s v a n i s h i n gd a yb yd a y ，a n d m u l t i t i e rd i s t r i b u t e ds y s t e mi s p o p u l a r i z i n go v e rt i m e ；d i s t r i b u t i o nh a sb e e n o n eo ft h em o s ti m p o r t a n tc h a r a c t e r i s t i c so fn e t w o r k a p p l i c a t i o n a n dt h en o t i o n o fd i s t r i b u t i o nh a sg e n e r a l l ym i g r a t e df r o mt i g h t l y c o u p l e d ，g e o g r a p h i c a l l yc l o s e ， h o m o g e n e o u s m a c h i n e st om o r e l o o s e l y c o u p l e d ，g e o g r a p h i c a l l y r e m o t e ， h e t e r o g e n e o u sm a c h i n e s a tt h es a m et i m e ，o b j e c t o r i e n t e dt e c h n o l o g yh a sb e e n t h ec h i e fo n eo fs o f t w a r ed e v e l o p m e n t t h e nd i s t r i b u t e do b j e c tt e c h n o l o g y ( d o t ) c a r v e d i t s p o s i t i o n a st h em a i n t e c h n o l o g y t ob u i l d l a r g e a n d c o m p l i c a t e ds y s t e m s i nt h i sp a p e r ，t h e o r i e sa b o u td a t at r a n s f e rt e c h n i q u ei nd i s t r i b u t e ds y s t e m a r ed i s c u s s e d f i r s t ，d i s t r i b u t e do b j e c tt e c h n o l o g ya n dt h ec o m m o no b j e c t r e q u e s tb r o k e ra r c h i t e c t u r e a r e a n a l y z e d b e c a u s et h e ya r et h eb a s e so fm y r e s e a r c hw o r k s e c o n d ，t h ep e r f o r m a n c eo ft h ed a t at r a n s f e rm e c h a n i s mo f c o r b ai sa n a l y z e da n di t1 e a d st ot h ed a t as e r v i c em o d ew h i c hs e r v e sf o rd a t a t r a n s f e rs e r v e r i t sd e s i g na n di m p l e m e n t a t i o na r ep a r t i c u l a rd i s c u s s e d ，t h i r d ， t h ei m p l e m e n t e dr e a l t i m ed a t as e r v i c ei st e s t e dt of i n di ft h ep e r f o r m a n c ei s a c c e p t a b l e a l s o ，t h ee x p e r i m e n ti n d i c a t e sw h i c hi s m o s te f f i c i e n ta m o n gt h e f o u rm o d e so fd a t at r a n s f e ri nt h ee v e n ts e r v i c eo fc o r b a i nt h ee n d ，t h e r e s e a r c hw h i c hf u t u r er e s e a r c hf i e l d sa r ep r o p o s e di ss u m m a r i z e d k e y w o r d s d i s t r i b u t e ds y s t e m ，d i s t r i b u t e do b j e c t ，c o r b a ，r m i ，e v e n t s e r v i c e 玎 西北工业大学硕士学位论文 1 1 选题背景及意义 第一章绪论 近十年来，通信技术和计算机技术的长足发展推动了网络应用的深刻变革。 这一变革的一个显著特征是：越来越多的企业级应用基于网络的业务增加，这些 应用软件所采纳的传统的客户端服务器两层结构由于在运行效率、网络安全性 以及升级能力方面的局限而逐渐向分布式应用的多层结构转变。 在这一时期，分布式处理技术和面向对象技术的融合形成了引人瞩目的分布 式对象技术，它使得在多层结构的分布式环境中，应用程序不再以整体的形式提 供给用户，而是成为运行在网络上的服务对象。分布式对象技术利用对象的特性 大大简化了分布计算的复杂性，并且具有以下优点：接口定义与功能实现分离， 可为特定应用提供优良服务，实现透明互操作，便于已有异构系统的集成，基于 构件开发，具有良好可重用性等等。 当前主流的分布式对象技术有c o m d c o m ，r m y e j b 和c o r b a ： c o m 1 3 c o m 是m i c r o s o f t 的标准，仅局限于w i n d o w s 平台，在非w i n d o w s 平台上不具各优势。 r m i 与e j b 是以j a v a 语言为主体的分布式对象框架，鉴于j a v a 语言的 运行效率比较低，用它开发实时性强的应用系统也不合适。 c o r b a 是o m g 组织制定的分布式对象框架标准。由于o m g 是一个 由全球8 0 0 多个大型软、硬件公司联合成立的组织，所以c o r b a 标准 得到了业界广泛的支持，使得它能跨越硬件平台、操作系统、编程语言 和联网细节。用c o r b a 可以方便地构造一个鲁棒式的分布式应用系统。 基于以上原因，我们可以认为c o r b a ( 通用对象请求代理结构) 作为分布 对象计算技术的典型示范，是基于网络的各类复杂应用系统的理想集成框架。 但是，国内业界普遍存在一种观点：认为基于c o r b a 开发分布式系统园为 其提供的强大的抽象机制屏蔽了基础网络和分布式基础结构的复杂性，这将导致 开发的软件执行效率低下，一个具体的体现就是分布在各节点上的对象之间传输 数据的时间性能不能令人满意。 针对这一论断，本文除了介绍c o r b a 技术在分布式软件开发中的应用以 外，着重对基于c o r b a 的分布式系统的数据传输进行性能分析从而提出一种 为各分布节点间提供数据传输服务的数据服务模型，并给出数据服务在分布式监 控系统中的一种实现，然后论述了实时数据服务的性能测试方案，根据试验 数据对实时数据服务的性能进行了分析，同时也比较了c o r b a 事件服务的 西北工业大学硕士学位论文 四种不同数据传输模式的传输效率。 1 2 课题内容及本人所做工作 1 2 1 课题内容 我有幸加入了y s z 2 0 0 2 电力监控管理系统网络版的设计与开发工作，并在 工作过程中对分布式应用各网络节点间的数据传输模型设计及其性能开展了实 验研究。 y s z 2 0 0 2 电力监控管理系统网络版是在原有的单机版，也即y s s 2 0 0 0 电力 监控管理系统的基础上进行网络拓扑的重新设计，采用c o r b a 中闯件模型开 发，扩展到分布式应用的网络版本。 y s s 2 0 0 0 电力监控系统是在单片机系统的基础上重新开发的远距离集中监 控保护低压电路系统可组态软件，保留了原有系统的必要功能，同时为了和国际 标准接口，改造了原系统的网络模型，应用p r o f i b u s 总线系统，保证了系统 的工业可靠性和实时性。系统分为开发版和运行版两部分。其中开发版的作用是 进行项目组态，其结果提供给运行版用，从而达到电力监控的目的。 作为升级版本的y s z 2 0 0 2 电力监控系统网络版在网络应用上加以延伸，采 用三层体系结构，分别是处于第一层的作为c o 褂3 a 通信核心的o r b 软总线层， 处于第二层的子系统内部实现层，以及处于第三层的现场总线层。整个系统中包 括完成现场数据采集监视任务的s c a d a 及其热备机。还包括对s c a d a 进行远 程监控的工作站，以及可以管理整个网络的网管系统。这些子系统又通过o r b 软总线与各种分布式对象服务、w e b 服务器以及企业服务器互连。目前该系统 的研发处于功能测试阶段。 l - 2 2 我所作的工作 y s z 2 0 0 2 电力监控管理系统规模较大，整套系统是由多人合作完成的。本 人所作的工作归纳起来有以下几点： 参与完成了整个软件系统的需求分析和整体设计； 完成了远程监控工作站模块的设计与实现； 参与完成部分人机界面的设计与实现； 参与数据服务性能测试与分析。 1 3 论文组织 全文组织为：第一章为绪论部分、第二章至第五章为主体部分、第六章为结 西北工业走学硕士学位论文 束语。 第一章 第二章 绪论 综述本文的选题背景、研究内容和整体组织。 关键技术分析 本章介绍了分布式对象技术的基本原理和特点，以及它的典型代表 c o r b a 对象模型的体系结构，并简要介绍了一种基于c o r b a 的 分布式监控系统的实现。 第三章基于c o r b a 的分布式系统的性能分析 本章是本文的重要部分。对基于c o r b a 的分布式系统中影响时间 性能的重要因素逐一加以讨论，提出改善i d l 接口设计的方法， 并给出统计分析结果进行验证。 第四章数据服务模型及其一种实现 本章是本文的重要部分。对分布式系统中的数据传输技术进行深入 探讨，介绍了基于c o r b a 的数据服务模型的设计以及实现。 第五章实时数据服务性能测试与分析 本章是对实时数据服务的性能设计测试方案，以及对测试数据展开 分析。 第六章结束语 本章对本文进行了总结，并指出了进一步的研究方向。 西北工业大学硕士学位论文 第二章关键技术分析 分布式对象技术和它的典型代表c o r b a 技术是构建本文重点数据服 务的基础技术。本章就这两种技术作简要的分析，重点讲述c o r b a 的对象模型 和关键服务。 2 1 分布式对象技术分析 常规的面向对象技术可以直接应用于分布式系统的分析和设计，然而传统的 面向对象设计环境，例如c + + ，在直接用于分布式应用系统的程序设计时遇到了 问题。传统的对象与访问该对象的程序只能存在于同一进程中，并且只有相关程 序设计语言的编译器才能创建这些对象并感知这些对象的存在，而外部进程无法 了解和访问这些对象。这意味着在常规的分布式客户端服务器应用中，客户进 程不可能直接访问异地服务进程中的常规对象。为了解决这个问题，人们提出了 分布式对象的概念。 2 1 1 分布式对象技术的基本原理 分布式对象存在于网络的任何地方，可被远程客户应用以方法调用的形式访 问。至于分布式对象是使用何种程序设计语言和编译器所创建，对客户对象来说 是透明的。客户应用不必知道它所访问的分布式对象在网络中的具体位置以及运 行在何种操作系统上，该分布对象与客户应用可能在同一台计算机上，也可能分 布在由广域网( 如i n t e m e t ) 相连的不同计算机上。分布对象具有动态性，它们 可以在网络上到处移动。 我们把独立于特定的程序设计语言和应用系统、可重用和自包含的软件称为 软构件。分布式对象是一种典型的软构件。基于分布对象技术的分布式应用开发 就是分布式对象的开发和组装。 分布式对象技术采用面向对象的多层客户端i j r 务器计算模型，该模型将分 布在网络上的全部资源( 无论是系统层还是应用层) 都按照对象的概念来组织，每 个对象都有定义明晰的访问接口。创建和维护分布对象实体的应用称为服务器， 按照接口访问该对象的应用称为客户。服务器中的分布对象不仅能够被访问，而 且自身也可能作为其他对象的客户。因此在分布式对象技术中，客户与服务器的 角色划分是相对的或多层次的。支持客户访问异地分布对象的核心机制称为对象 请求代理( o b j e c tr e q u e s tb r o k e r , o r b ) 。o r b 处于分布对象技术的核心位置。 通过重用已有的软构件，使用构件对象模型的软件开发者可以像搭积木一样 4 一 望苎三兰查主堡主堂堡垄查 快速构造应用程序。这样不仅可以节省时间和经费，提高工作效率，而且可以产 生更加规范、更加可靠的应用软件。 2 1 ，2 分布式软件构件的特征 如前一节所描述。构件模型具有下面的四个特征： 自描述：构件必须能够识别其属性、存取方法和事件，这些信息可以使 开发环境将第三方软件构件无缝地结合起来； 可定制：提供一个典型的图形方式环境，软件构件的属性只能通过控制 面板来设置； 可集成：构件必须可以被编程语言直接控制。构件也可以和脚本语言连 接或者与从代码级访问构件的环境连接，这个特性使得软件构件可以在 非可视化开发项目中使用； 连接机制：构件必须能产生事件或者具有让程序员从语义上实现相互连 接的其他机制。这意味着程序员可以很容易地向按钮添加代码，使点中 按钮就可以影响其他构件的动作。 构件模型是为开发者定义软件构件而建立的体系结构和a p i 集，使开发者 可通过软件构件的动态组合来建立应用系统。构件模型由构件与容器两种主要成 份构成。构件是具有可重用特性的基本软件部件。容器用于存放和安排构件实 现构件间的交互。容器也可以作为另一个容器的构件使用。 2 1 3 分布式对象的服务 分布式对象服务包括支持分布式系统正常工作的各类基本的系统级服务，例 如名字管理、事件通告、对象事务管理、对象生命期、时间同步、并发控制等。 公共设施包括支持分布式系统高效开发和有效工作的各类面向领域的常规服务 和工具，例如g u i 服务、数据库服务、电子邮件服务、系统管理服务以及面向 电信、仿真和金融等应用领域的领域构架等等。应用对象涉及各种应用软件，它 在对象服务和公共设施的帮助下完成相应的应用逻辑，o r b 如同一条总线( b u s ) 把分布式系统中的各类对象和应用连接成相互作用的整体。 2 1 4 为什么选择分布式对象模型 我们为什么要使用分布式对象模型来实现大型的网络应用昵? 换句话说，分 布式对象模型相比较传统的客户端服务器模型能更好地解决什么问题呢? 为了 回答这些问题，我们不妨以一种用于电力监控的具有行业特色的分布式监控系统 西北工业大学硕士学位论文 的设计为例对分布式对象计算的关键特征加以论述： 资源共享问题： 如何使实时历史数据能够进入e r p 、c r i v l 等企业信息管理系统，是现代电 力系统迫在眉睫的需求。监控系统所取得的信息数据要和其他系统进行共享。如 果使用传统的客户端n 务器模型，则存在一些问题。首先是异构环境的问题， 若消费数据的e r p 和c r m 系统与电力监控系统不是在同一操作系统平台，或不 使用同一编程语言开发，则它们之间的数据共享将非常难以实现。其次是数掘存 储和处理能力问题，传统的客户端服务器模型中信息数据一般只存储在一个中 心服务器上，数据存储量和处理能力是非常有限的。如果数据量很大，数据消费 频繁，则整个系统性能将变得很低，而且一旦中心服务器出错，则整个系统也将 停止运行，无法再为外界提供数据共享功能。而分布式对象模型是以对象的方式 向外提供数据服务，独立于网络协议、编程语言、软硬件平台，提供了很好的跨 平台性能：并且在分布式对象模型中，数据存储在分布式数据库系统中，包括分 布式实时数据库和分布式历史数据库，并向外提供一个或几个数据代理，其他的 企业信息管理系统通过数据代理来访问数据。这种机制不但保证系统不会由于单 点故障而导致整个系统崩溃，而且具有存储和处理海量数据的能力，这种能力从 理论上来说是无限的。 开放性问题： 自动化软件正逐渐成为协作生产制造过程中不同阶段的核心系统，无论是用 户还是硬件供应商都将自动化软件作为全企业范围内信息收集和集成的工具，这 就要求自动化软件大量采用“标准化技术”，成为一个开发的软件平台。电力监 控系统也一样。它不仅要能够完成自身的监控要求，还要和其他应用系统进行互 连和互操作。对于这一点，传统的客户端服务器模型是无能为力的。而分布式 对象模型却提供了分布式异构环境下应用系统互连和互操作的标准，使得系统在 具有很好的开放性的同时，也提供了很好的可扩展性，便于新的应用模块的扩展。 容错和热备问题： 稳定、安全、可靠的电力监控系统要求系统部分失效时还能继续发挥作用的 能力，如某节点故障而不影响系统正常行为，而且要提供热备。在传统的客户端 服务器模型中，服务器是整个系统的核心，一旦服务器出错，则整个系统崩溃， 因此不具备好的容错能力。而分布式对象模型的资源多重性为实现容错和热备创 造了条件，实现途径有硬件资源冗余、数据多副本、动态切换等。 2 2c o r b a 技术分析 目前，分布式对象技术已经成为建立服务应用框架和软件构件的核心技术 6 西北工业大学硕士学位论丈 在开发大型分布式应用系统中表现出强大的生命力。c o r b a ( t h ec o m m o n o b j e c tr e q u e s tb r o k e ra r c h i t e c t u r e 通用对象请求代理结构) 是一个分布式的面向 对象应用架构规范，它是由o m g 研究组在8 0 年代末提出，在9 0 年代逐步完善， 形成现在被软件行业普遍认可的标准c o r b i i o p 规范2 3 ，这也是我们在 实际研究中所遵循的开发规范。 与c o m d c o m 技术在扩展性发面的局限，和r m i e j b 在实现语言方面的 不足相比，c o r b a 是一种异构平台下的语言无关的对象互操作模型。也即， c o r b a 的设计是独立于平台和语言的，因此c o r b a 可以在任何平台上运行， 可以定位在网络的任何地方，能够使用任何有i d l ( i n t e r f a c ed e f i n i t i o n l a n g u a g e ) 映射的语言。 这也是我们选择c o r b a 作为开发分布式系统数据服务的分布式对象模型 的原因。 2 2 1c o r b a 对象管理体系结构 图2 1 对象管理体系结构 c o r b a 对象管理体系结构由应用程序对象、垂直基础设施、水平基础设施、 对象请求代理和对象服务组成。 应用程序接口是专门为特定的应用程序开发的，它们并不是o m g 制定 的标准。 纵向基础设施是为专门领域制定的接口。如电信、电力、卫生等专门领 域。 横向基础设施是为通用领域制定的接口。如信息管理、系统管理等通用 领域。 对象请求代理是公共对象请求代理结构的基础。基本职责是解决对象引 7 。 望! ! 三些垄兰堡主兰堡垒苎 用的请求和建立对象引用之间的连接，通过标准接口来屏蔽不同的平 台、操作系统、网络协议和编程语言。 对象服务。对象服务是为公共设施和各种应用对象提供的基本服务，如 命名服务、事件服务、事务服务和通知服务等。 2 2 2c o r b a 对象请求接口结构 c o r b a 规范是o m a 中o r b 的具体实现。它的结构如下图所示。 c l i e n t ) o b j e c ti m p l e m e n t a t i o n ) 土 南每o r b ，土占熬 d y n a m i c l 豳囱糯 o r b c o r e 图2 2 通用对象请求代理结构 o r b 核一t j , ( o r bc o r e ) 。o r b 核心主要起对象定位、屏蔽底层网络协议、 编组和解组的作用。同时，它还提供一些接口库和a p i 。 o r b 接口( o r bi n t e r f a c e ) 。o r b 接口提供了一组标准的a p i ，客户程序 和对象实现程序都可以使用它。 客户端i d l 码根( i d ls t u b ) 。码根实际上是一段程序，它为接口中的每 一个操作提供一个虚实现。相当于对象实现在客户端的代理。 服务器端i d l 框架( i d ls k e l e t o n ) 。框架实际上是对象实现代码的编程框 架，但它并不负责对象实现。柑当子服务器端的码根。 动态调用接e l ( d y n a m i ci n v o c a t i o ni n t e r f a c e ) 。动态调用接口是一组标准 的a p i ，通过它客户程序可以调用未知类型的c o r b a 对象的操作。动 态调用接口提供了一种代替i d l 码根的机制，但使用起来比较麻烦，效 率也不如码根高。 动态框架接口( d y n a m i cs k e l e t o ni n t e r f a c e ) 。动态框架接口也是一组标准 的a p i ，它提供了一种可以创建不继承自框架类的对象实现的机制。 对象适配器( o b j e c ta d a p t e r ) 。对于不同的对象实现需求，会有不同的对 象适配器。c o r b a2 0 以前的规范，所有的o r b 都支持基本对象适配 西北工业大学硕士学位论文 器( b a s i co b j e c ta d a p t e r ) 。但基本适配器不能用于不同的o r b 产品之唰 互操作，于是c o r b a2 - 3 规范定义了一种新的可移植的对象适配器 ( p o r t a b l eo b j e c ta d a p t e r ，简称p o a ) 。 2 2 3c o r b a 对象服务 c o r b a 服务规范定义了1 5 种标准服务，但一般o r b 厂商只实现了其中的 几种服务，有的还提供了扩展服务。例如v i s i b r o k e r 就只实现了命名服务和事件 服务两种标准服务，并提供了一个扩展服务：定位服务。由于我们使用的o r b 产品是v i s i b r o k e r ，所以这里就只分析命名服务、事件服务和定位服务，并重点 分析事件服务和定位服务。 命名服务。命名服务允许给对象引用绑定一个或多个逻辑名字，客户程 序通过命名服务对逻辑名字解析就可以得到被绑定的对象引用。 事件服务。事件服务提供了一个退耦的“提供者一消费者”模型，多个 提供者可以向多个消费者异步发送数据。这个退耦模型的关键是事件通 道，提供者只要连接到事件通道并不需要任何有关消费者的信息就可以 主动或者被动的提供数据。根据事件流的方向，又可以分为四种数据传 输模式：经典的推模式、经典的拉模式、混合推拉模式和混合拉推模 式，分别如下图所示。 图2 3 经典推模式 图2 4 经典拉模式 图2 5 混合推，拉模式 9 西北工业大学硕士学位论文 图2 6 混合拉推模式 定位服务。定位服务不是c o r b a 标准服务，而是v i s i b r o k e r 提供的扩 展服务。通过定位服务可以查找所有在p o a 上以b y j n s t a n c e 策略 注册的对象实例或者在b o a 上注册的永久对象实例。 2 z 4c o r b a 体系结构的特点 c o r b a 的产生有其特定的背景，它是在面向对象的技术兴起，客户端服务 器模式普遍得到应用的前提下，为屏蔽通信和实现细节的需求，在已有系统的基 础上扩展而产生的。它弥t l t 传统分布处理系统的不足( 如r p c 等) ，其特点可以 总结为如下几个方面： 引入中间件( m i d d l e w a r e ) 作为事务代理，代理起到如下作用：完成对 客户方提出的抽象服务请求的映射，自动发现和找到服务器，自动设定 路由，从而实现服务方程序的执行。引入中间件概念后分布计算模式如 图2 7 所示； 图2 7 引入中间件后客户机与服务器之间的关系 实现客户与服务对象的完全分离，客户不再需要了解服务对象的实现过 程以及具体位置： 提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符 合接口规范的定义，均能够集成到分布式系统中。如此，客户应用于服 务对象之间可以透明地交互运行，实现应用软件在软件总线上的即插即 用； c o r b a 规范软件系统采用面向对象的软件实现方法开发应用系统，实 现对象内部细节的完整封装，保留对象方法的对外接口定义a 在以上特点中，最突出的是中间件的引入，在c o r b a 系统中称为对象请求 代理( o r b ，o b j e c tr e q u e s tb r o k e r ) 和采用面向对象的开发模式a 1 0 西北工业大学硕士学位论文 综上所述，c o r b a 技术是先进技术发展的结果，它将面向对象的概念揉合 到分布计算中，使得c o r b a 规范成为开放的、基于客户端服务器模式的、面 向对象的分布计算的工业标准。 2 3 一种分布式监控系统的实现 基于c o r b a 对象模型的应用很多。这里仍然是以我们研发的分布式系统一 - - y s z 2 0 0 2 电力监控系统为例进行简要的说明。 整个y s z 2 0 0 2 系统宏观上的网络拓扑图如图2 8 所示。 图2 8 宏观上的网络拓扑图 整个系统中包括完成现场数据采集监视任务的s c a d a 及其热各机，还包括 对s c a d a 进行远程监控的工作站，以及可以管理整个网络的网管系统。这些子 系统又通过o r b 软总线与各种分布式对象服务、w e b 服务器以及企业服务器互 连。其中分布式对象服务中心包括各种服务对象，但因为c o r b a 对象在一个 i ) 9 域中是可以任意部署的，因此它实际上是一个抽象的概念。各种分布式对象可以 部署在网域中的任何一台电脑上，它们的位置是对使用者透明的。 更详细的系统结构图如图2 9 所示。 西北工业大学硕士学位论文 图2 9 系统结构图 从图上可以看到，本系统将整个监控环境划从上往下分为三个层次： 第一层是o r b 软总线层，主要用于资源共享以及系统互连。同时也可 以通过o p c 和m o d b u ss e r v e r 组件和其他系统互连，这些系统包括 d c s 、p l c 以及其他的电力监控系统或自动化软件。而且这种互连和共 享不仅可以在单一的l a n 中实现，还可以通过交换机和路由器与其他 l a n 互连，甚至组成v p n ，形成一个统一的分布式服务平台； 第二层是各子系统应用层，例如s c a d a 的实现： 第三层是现场总线层，在这一层上s c a d a 通过各种现场总线与下位机 通讯，从而进行数据采集和指令发送。 其中第二层和第三层传统的客户端服务器模型系统已经做到，但第一层是 它所缺少的，这也正是分布式对象模型不同与客户端朋覆务器模型的地方。 由于分布式对象可以在网络系统中任意部署，因此在整个监控系统中，所有 的上位机可以被分为两种类型，服务器和工作站。 服务器：在其上运行某一服务的节点就被称为服务器。服务是指通过单 个分布式对象独立工作或多个分布式对象的协同工作向外提供各种应 用的一种手段，是服务的供应者。我们知道c o r b a 规范已经定义了许 多服务，但在本系统中我们要在一些c o r b a 服务的基础上实现电力监 控系统所需要的服务，比如下文将详细分析的数据服务、以及安全服务、 网管服务、报表服务、备份服务等。 工作站：在其上运行某一模块的节点就称为工作站。模块是指使用各种 1 2 西北工业大学硕士学位论文 服务来完成具体工作的子系统，是服务的消费者。同时模块也n - i d a 是一 个c o r b a 对象，向外提供各种应用接e l 。本系统中模块包括：s c a d a 模块、监控管理模块以及网管模块。 这些服务器和工作站相互连接，共享资源，甚至可以相互操作，完成分 布式电力监控任务。同时通过服务向系统外部的e r p 、w e bs e r v e r 和其他 应用系统提供接入解决方案。 2 4 小结 本章简要地讲解了数据服务所涉及的关键技术：分布式对象技术和c o r b a 技术。 我们把独立于特定的程序设计语言和应用系统、可重用和自包含的软件称为 软构件。分布式对象是一种典型的软构件。基于分布对象技术的分布式应用开发 就是分布式对象的开发和组装。 c o r b a 是一种面向对象的中间件，用来构建异构的分布式系统。o m g 定 义的对象管理体系结构是c o r b a 技术的基础，该结构包含四个主要部分：应用 程序对象接口、基础设施、对象请求代理和对象服务。y s z 2 0 0 2 电力监控系统 就是一个应用分布式c o r b a 技术架构的分布式软件。 西北工业大学硕士学位论文 第三章基于c o r b a 的分布式系统的性能分析 性能对于c o r b a 企业级解决方案是一个很根本的问题，不当的c o r b a 设 计方案对分布式系统的性能尤其是时间性能造成很大的影响。导致这一性能损失 的主要原因是我们忽视了基础网络和分布式基础结构的复杂性，而过分依赖于 c o r b a 对这两者的抽象，对于其它分布式对象模型的应用也是如此。 c o r b a 提供了强大的抽象机制，这是它的优点之一，使得我们能够着重于 相对简单的应用层的开发而非系统级的功能开发。但是抽象并不意味着用户可以 完全忽略抽象层下面要处理的复杂的分布式系统结构，忽略这一复杂性的 c o r b a i d l 设计会导致差的性能和可伸缩性。本章重点从i d l 接口设计的角度 分析c o r b a 分布式对象模型的时间性能。 3 1 访问模式 3 1 1 本地接口和远程接口 计算机体系存在着这样个基本事实：一个进程内部的程序调用非常快，但 是两个不同的进程间的程序调用速度呈几何级数减慢。因此将一个进程运行在其 它的机器上，就会增加一个或者两个数量级的复杂度，这与网络的拓扑结构有关。 所以，本地对象接口和远程对象接口截然不同。 本地对象接口应该是细粒度的。假设有一个地址类，一个良好的接口应该有 分别的方法来获取城市名、获取省名，设置城市名、设置省名等等。细粒度的接 口结构很好，因为它依循了一般的面向对象原则：大量的小块能够被组合在一起， 以不同的方式重载，这样就可以扩展设计以适应将来的需要。 但是细粒度接口处理远程任务时就不那么好用了。当方法调用速度减慢时， 我们希望用一个调用，而不是用三个调用来获取或更新城市名、省名和邮编。因 此需要的接口是粗粒度的，它不是为了灵活性和扩展性而设计的，而是为了减少 调用设计的，所以将看到一个有获取地址和更新地址功能的接口。也许粗粒度接 口看上去笨拙，但是为了性能，必须使用粗粒度接口。 我们经常会想当然地认为采用c o r b a 对象模型无论是对于远程调用还是 本地调用都是适用的。如果是本地调用，它就拥有本地调用的速度；如果是远程 调用，速度就会慢一些。因此，只需要在需要远程调用时付出远程调用的代价a 这个说法在某种程度上是真实的，但是它并没有解决一个基本问题：任何被用于 远程调用的对象都应该是粗粒度的，而每个不是用于远程的对象应该有细粒度的 接口。当两个对象通信的时候，必须选择使用哪种接口。如果对象在不同的进程 1 4 垦! ! 三些垄芏翌主差垒垒查 中，就必须使用粗粒度接口，就必须为此付出更多的编程工作。显而易见，只有 当必要的时候才使用粗粒度接口，因此需要尽量减少进程间的协作。 3 1 2 改善i d l 接口设计 通过上面的分析我们意识到：在分布式环境中，必须仔细考虑预期的对象访 问模式。每个远程接口调用都会增加一定的执行开销，忽略这个事实的i d l 设 计会导致很差的睦能，我们可以通过分析2 3 节介绍的y s z 2 0 0 2 系统实时数据 服务的i d l 设计对接口粒度的重要性加以理解。 我们的意图是实时数据服务驻留在监控管理模块上的客户端应用程序访问 数据服务驻留在s c a d a 上的服务端，以注册一系列的设备变量。 客户端注册设备变量时，用到了远程接口调用d s r r e g v a r i a b l e o ，这显示 于图3 1 中。这个方法的问题在于，如果客户端需要注册n 个变量，就会有n 个远程接口调用，而每一个调用都要增加可观的开销。如果n 数值很小这就不 成问题，但如果n 很大，上面设计的系统就会有很长的响应时间。 监控管理模块 s c a d a d s r _ r e g v a r i b l e0 持久数据服务 陷。酣。， 持久数据服务 客户端服务端 图3 1 采用细粒度的远程接口调用 一 塑! ! 三些垄鲎婴主茎竺笙查 上面持久数据服务接口的变化大大改变了远程访问模式。如图3 2 所示，第 二版提供的接口d s r r e g v a r i a b l e s o 允许用户在单一的远程接口调用中注册所 有的设备变量信息。 匿斗啦 3 、比较两种i d l 的设计 我们从时间性能的角度来比较两种不同的i d l 设计版本。图3 3 显示了客户 端有大量设备变量注册时两个设计版本的区别。可以看到采用第二版粗粒度的接 口设计因为远程接口调用的次数减少从而大大改善了性能。但是值德注意的是， 图中第一版的设计在参数数据类型的打包时间开销上明显低于第二版的 s e q u e n c e 类型，并且第一版每一次远程接口调用传送的数据量也远小于第二版 的一次接口调用。那么在影响性能的因素：远程接口调用的数量、每次远程接口 调用所传递的数据量和请求参数的数据类型中孰重孰轻昵? 下面将对此作出详 细的分析。 1 6 一里! ! 兰些垄兰堡主鲎堡垒圭 第一版 第二版 厂厂7 ( 麓渊 s 的开销 f ) i 解包的开销 “7 1 ” j 厂厂7 ( i 翌堕上竺到 解包的开销 ”“”i 持续时间 图3 3 两个| d l 设计版本的时间性能比较 3 2 影响性能的重要因素 我们总结出三个对c o r b a 应用程序性能有重大影响的因素： 远程接口调用的数量： 每次远程接口调用传递的数据量； 伴随接口调用所传送的数据的打包开销。 下面逐一讨论每一个因素。 3 2 1 远程接口调用的数量 每个通过网络连接发送的请求都必然存在网络延迟。这个延迟对每个c o r b a 远程激发增加了相当可观的处理时间，特别是在t c p i p 网络中。每个请求和回 答所强加的网络延迟并不是每次远程接口调用中唯一的消耗因素。还有其他的因 素，例如服务器端对象查找，它向每次远程接口调用贡献一定的消耗因素。我们 通过统计分析发现这个消耗因素是远程接口调用数量通常比每次请求所传递数 据量更能影响性能的原因。3 1 2 节两种i d l 设计版本的对比就是一个很好的例 证。 3 2 2 消息尺寸 从上面可得到一个简单的结论：高处理速度可以这样实现：使用少量请求， 每次传递大量的数据，而不是用多个请求，每次只传递少量的数据。但在单个消 息中传递极其大量的数据又有另一个问题如果消息太大，处理速度就会下 降。下降的原因包括t c p 缓冲区问题和进程空间的增加。 = = = 塑塑塑墼 我们通过在局域网的实验得到曲线图3 4 ： m 3 2 3 不同i d l 数据类型的打包开销 是不勰篙僦；雾暑淼裁鬻也 西北工业大学硕士学位论文 与 l l l l 图3 5 打包，解包不同i d l 数据类型的相对开销 打包诧费 o c t e t ：o c t e t 是c o r b ai d l 提供的最简单数据类型。o c t e t 的打包开销是很 少的。o r b 甚至不负责o c t e t 的字节顺序。 s t r u c t ：s t r u c t 同样也很简单，因此它的打包歼销很少。s t r e u t 的打包开销由 s t r u c t 的成员类型来决定。图中指出了s t r u c t 本身的开销，而没有包括s t r u c t 所含的任意数据。 u n i o n ：u n i o n 比s t r u c t 稍为复杂，因为u n i o n 可以存储不同类型的数值。因 此，打包开销也比u n i o n 稍高。u n i o n 的打包开销取决于u n i o n 中所含数据的 类型。图中只是指u n i o n 本身的开销。 s t r i n g ：s t r i n g 是一长度可变的数据类型。长度可变数据类型的问题是它们通 常包括很耗费内存的管理操作。例如，拷贝一s t r i n g 序列时，o r b 不能立即 为所有s t r i n g s 预分配内存，而必须为每个s t r i n g 单独分配内存。通常，读者 会发现可变长度数据类型比固定长度数据类型更加耗费资源。 s e q u e n c e ：s e q u e n c e 不仅是可变长度数据类型，它还可存储复杂的i d l 类型。 同样，s e q u e n c e 的打包开销取决于它的成员类型。 a n y ：a n y 类型是i d l 提供的最复杂的基本数据类型，因为它本质上是动态 类型，而且在打包和解包期间必须处理动态类型代码。a n y 类型的打包开销 极大地依赖于编程语言( 一些语言比其他语言更适合支持动态类型) 和o r b 实现。通常，a n y 比其他基本数据类型更加耗费资源。 o b j e c tr e f e r e n c e ：对象引用提供了强大的抽象机制。它们封装了如主机地址 和对象标识等信息，并映射到激活的网络连接。这种抽象的代价是相对高的 对象引用打包开销。通常，接收器端对象引用的解包开销特别大，因为它包 1 9 = = o 哪涨 骑 糟 西北工业大学硕士学位论文 括代理对象的创建。