计算机研究与发展
JOURNAL OF COMPUTER RESEARCH AND DEVELOPMENT
1999年 第36卷 第8期 Vol.36 No.8 1999



一种实现互操作的分布式集成框架的设计与实现
史殿习　吴泉源　王怀民　邹　鹏 
摘　要　互操作性问题是分布计算中需要解决的关键问题.这一问题可以通过多种途径加以解决，其中面向对象的集成框架是一种比较好的解决方法.文中首先研究了互操作性的概念、实现机制及面向对象方法对互操作性的支持机制；在对DCE 的RPC机制和CORBA的ORB机制比较的基础上，采用面向对象方法和技术，开展了基于Agent的分布客户/服务器集成框架的研究，提出了一种基于Agent的分布式通用框架，以支持客户/服务器应用的开发和实现Agent之间的互操作性.
关键词　互操作性，CORBA，对象请求代理，Agent，框架
中图法分类号　TP393
DESIGN AND IMPLEMENTATION OF A DISTRIBUTED INTEGRATED FRAMEWORK IMPLEMENTING INTEROPERABILITY
SHI Dian-Xi, WU Quan-Yuan, WANG Huai-Min, and ZOU Peng
(Department of Computer Science, National University of Defense Technology, Changsha 410073)
Abstract　Interoperability is one of the key problems, which must be solved in distributed computing systems. The distributed integrated framework is a good solution for interoperability. First studied in this paper are the concept and implementation mechanism of the interoperability, and the mechanism with which object-oriented technology supports interoperability. Then, after comparing the DCE RPC mechanism with the CORBA ORB mechanism, research on the distributed client/server integrated framework is carried out based on the agent using the object-oriented method and technology, and a generic framework is presented based on multiple agent, to support client/server computing application development and to support the interoperability among agents.
Key words　interoperability, CORBA, ORB, agent, framework
1　引　言
　　随着计算机技术的发展，基于客户/服务器的分布计算成为新一代的计算范型［1］.分布计算可以给用户带来很多的好处，它不仅可以使用户共享分布在网络不同平台上的信息和资源，而且可以使用户访问分布在网络不同节点上的服务.然而，分布计算在给用户带来诸多好处的同时却给应用开发者提出了新的挑战和新的问题，这些新的问题主要包括应用互操作性问题以及应用的可移植性等问题.其中，如何解决应用间的互操作性问题成为分布计算中研究的重要课题.目前，对应用间互操作问题已提出了一些相应的解决方法，如Sun RPC和OSF DCE等，它们对应用互操作性提供了相应的支持机制，但这些机制都建立在传统的面向过程和结构化程序设计方法的基础之上，存在一些不足和缺陷，主要表现在它们是在一个比较低的层次上支持应用的集成和互操作的，应用开发者在开发具体的应用时常常要涉及很多与平台有关的细节问题，而不能将主要精力集中在问题的解决上，为此必须寻求新的解决方法和机制来解决这些问题，以支持分布应用的集成和互操作性.根据国内外的研究资料表明［2,3］，很多的有识之士都认为面向对象方法和技术是解决这些问题的理想方法.在对传统的解决方法和分布对象计算规范CORBA［5］研究的基础上，我们采用面向对象方法和技术，开展了基于Agent［4］的分布客户/服务器集成框架的研究和开发，目的在于提供一种支持分布客户/服务器应用的分布式集成框架，实现分布应用的集成和互操作性，支持应用开发者开发基于客户/服务器计算的分布式应用.
　　本文如下组织：第2节讨论了互操作性的概念及其实现机制；第3节研究了面向对象方法对互操作性的支持机制；第4节研究了CORBA对对象间互操作性的支持机制；第5节将CORBA与OSF DCE进行了比较；第6节讨论了DIF/MA的框架结构和利用DIF/MA建立客户/服务器应用的组成部分以及DIF/MA所提供的开发工具；第7节将DIF/MA与CORBA中的相应机制进行比较；第8节对全文作一个小结.
2　互操作性
2.1　互操作性的提出
　　为解决系统资源的合理分布和有效共享，实现对已有投资的有效保持，支持日益广泛的协同工作的应用，需要各种互联技术控制应用软件在网络计算机环境上运行，这就是互操作性的基本需求.互操作性是指分布计算环境下两个软件元素相互通信并协同完成任务的能力.它包括基础层次和应用层次等两个层次的含义.基础层次是指实现不同计算平台之间的互联和通信及协同完成任务；应用层次是指实现各计算平台上的应用在网络基础上的互操作.本文重点讨论的是实现基础层次互操作性的实现机制和方法.
2.2　实现互操作性的机制
　　要实现应用间的互操作性必须解决位置透明、通信机制透明和激活机制的透明性等问题，为此必须提供相应的实现机制，这些机制主要包括：
　　(1) 自动定位和通信机制
　　自动定位服务方法在网络上的物理位置，并自动地将客户的请求(包括服务器的名字、服务方法的名字及参数等)传递给服务器；服务方法执行完成之后，将服务结果返回给客户，并且保证客户与服务器之间的同步；
　　(2) 抽象机制
　　使互操作的软件元素相互独立，使它们与程序设计语言无关，与实现细节无关及实现平台无关；
　　(3) 动态机制
　　在客户事先不知道服务器提供什么样的服务的条件下，能够动态地搜索能够提供服务的软件元素，动态地构造参数和动态地构造服务请求，并最终返回服务结果.
3　解决互操作性问题的方法
3.1　解决互操作性的传统方法：RPC机制
　　OSF DCE中的RPC机制是OSF提供的一种解决分布应用互操作性的一种机制，它主要用于支持异构型分布系统间的通信，它使用存根进程(stub)作为远程过程的本地代理，调用RPC运行时库(RPC runtime)来传输网络中的调用.存根和RPC运行时库屏蔽了网络调用所涉及的许多细节，特别是参数的编码/解码及网络通信是由存根和RPC运行时库来完成的.
　　DCE RPC 为应用的互操作性提供了一种实现机制，但这种机制是使用传统的面向过程的方法开发的，它的缺陷是没有提供动态机制和抽象机制，并且过程调用机制在传统的软件开发过程中存在的问题在分布式系统中将更加突出，因此它是一种比较低级的实现机制.
3.2　面向对象方法和技术是解决互操作性问题的理想选择
　　面向对象范型用对象来对应用进行分解，这与用数据和功能来分解应用的传统的面向过程的范型相比更加自然.面向对象方法具有良好的封装性、可重用性以及可移植性等特性.下面我们从面向对象方法的概念层次来对面向对象方法中的关键概念和机制进行分析，以说明面向对象方法是如何来支持对象的互操作性的.我们可以将面向对象方法的概念分为如下3个层次：
　　(1) 第1个层次是封装机制.封装机制是面向对象范型的核心.其基本思想是隐藏一个对象的内部数据和操作的实现细节，对象间通过一个良定义的接口进行通信.因此，可以对对象进行修改而不影响系统的其它部分.
　　(2) 第2个层次是继承机制和多态性机制.类是定义一个特殊对象类型行为的模板.类可以被组织成一个层次的继承结构，一个子类可以继承父类中的操作和属性，允许应用开发者重用已存在的类.而多态性是指同一个方法可以作不同的事情，这依赖于实现该方法的类.多态性也是一种允许子类重载一个继承的方法的机制，并且不影响父类中其它的方法.
　　(3) 第3个层次是框架机制.框架表示一个超越类库的抽象层次，一个面向对象框架是一个可重用的设计.对于特定的应用问题，应用开发者可以对其进行扩展或剪裁.一个框架不是一个类库，它是一组提供特定功能的类，这些类之间相互关联并且可以被用来建立某一特定类型的应用.
　　面向对象方法中这3种机制从不同层次上对应用的互操作性提供了支持，封装机制使不同的对象之间相互独立；继承机制和多态机制为代码的可重用提供了支持；框架机制从一个更高的层次上对应用互操作性提供支持.
　　随着面向对象技术越来越被人们所接受，各种组织如OMG已开始逐步进行面向对象的标准化工作，其目标是在一个广泛的可用的接口规范的基础上为面向对象应用提供一个通用的框架结构，使用户的软件能够在不同的平台上进行移植，保证系统内的互操作性.
4　CORBA对对象互操作性的支持机制
　　CORBA是OMG提出的一个标准，它是针对多种对象系统在分布计算环境中以对象方式集成而设计的.它比较好地解决了封装对象在分布计算环境中的资源共享、软件重用及功能扩展等问题.其最基本的目标是为分布对象间的互操作性定义一个开放的标准，并提出如下的机制来支持对象间的互操作性：
　　(1) ORB——自动定位和通信机制
　　ORB(object request broker)是CORBA的核心，它将客户与对象实现(由数据和代码组成的实体)分离开来，应用开发者只要按照他们定义的统一接口便可以独立地开发客户应用和对象实现.ORB充当客户应用和对象实现的中介，为客户和对象实现之间的通信提供支持机制，为对象访问提供了透明性，它负责定位对象实现、请求传递和结果返回等功能.
　　(2) IDL——语言抽象机制
　　为实现封装和继承特性，以及实现程序设计语言和实现环境的抽象性，OMG在CORBA中引入了接口描述语言IDL.OMG IDL 不是一种程序设计语言，它是一种中性语言，专门用来描述服务对象的接口.一个服务对象的IDL语言描述，包含了客户按对象方式使用该服务对象所需的全部信息.定义好的接口文件，经过IDL编译器可直接映射到相应的程序设计语言，如映射到C++，Java等语言.通过语言映射，用不同的语言实现的对象之间就可以实现互访.例如，一个用C++实现的客户可以访问用Java实现的服务对象，反之亦然.
　　(3) DII——动态激活机制
　　为实现动态请求，CORBA定义了一个动态激活接口DII(dynamic invocation interface).DII允许客户动态地生成和激活对对象的请求.客户可以使用该接口发送请求，其产生的请求语义与用客户IDL存根方式所产生的请求语义完全一样.该方式首先要将服务对象的接口加入到接口池IR(interface repository)中，而后通过ORB提供的统一服务请求接口，在运行时刻(runtime)动态地访问服务对象.
　　(4) OA——激活机制
　　对象识配器OA(object adapter)是一个对象实现访问ORB功能的主要接口.对象识配器为对象实现提供访问服务，这些服务主要包括对象引用的产生和解释、服务对象的激活和撤销、对象引用与对象实现之间的映射、服务方法的激活等.
5　CORBA与OSF DCE的比较
　　OSF DCE 和 CORBA中都为开发分布应用提供了相应的支持机制，如定位和通信机制等，但它们之间存在着很大的差别，主要表现在如下几个方面：
　　(1) DCE分布模型是建立在RPC机制之上，并且是一个面向过程的分布模型；CORBA模型是建立在对象技术之上，是一个面向对象的分布模型；
　　(2) 从面向对象的角度来看，RPC机制是基于远程过程调用，客户通过RPC机制只能以过程调用的方式调用服务器的过程；在ORB机制中，服务对象管理自己的状态信息，客户只与服务对象的本地代理发生关系，由代理和实际的服务对象交互，协同完成客户请求.此外，ORB机制的多态性使不同的服务对象对相同的方法激活反应不同；
　　(3) 从透明性的角度来看，RPC机制的操作是复杂的，客户需要直接与服务器连接；而ORB机制将很多复杂的工作交给ORB机制隐式完成，增加了透明性，用户不需知道服务对象的物理位置，而由ORB自动定位服务器的物理位置；
　　(4) ORB与RPC的关系：ORB可以建立在RPC之上，利用RPC提供的支持实现对象管理及其他ORB特性.
6　DIF/MA——一种与CORBA兼容的分布集成框架
6.1　Agent的概念及模型
　　通过对OSF DCE与CORBA的比较，我们可以看出CORBA比DCE更加适合分布应用的集成和实现对象之间的互操作性.为了统一地划分分布式计算系统中的计算节点、服务器、客户机及进程等各类独立自主的行为实体，我们开展对Agent的研究，引入了Agent的概念和机制.Agent是指在分布式系统中持续自主地发挥作用的计算实体.例如，通常分布式客户/服务器计算机系统中的各类服务器、SNMP中的Manager和Agent都为我们这里所说的Agent.从内部结构上看，
Agent=对象结构 + 行为引擎
简单形象地讲，Agent是有“生命”的对象. 其中，行为引擎是Agent的“心脏”，是体现Agent“生命力”的部分；对象结构是Agent的“大脑”，是体现Agent“智力”的部分.从外部特征上看，Agent具有独立性、自主性、交互性等特性.为此，我们提出了以事件处理为中心的Agent模型.在该模型中，Agent由事件处理系统、方法集和内部状态集3个主要成分构成.其中，事件处理系统是Agent的行为引擎，Agent的活性表现为它的事件处理系统在该Agent的生命期内始终持续自主地工作.Agent的事件处理系统的功能是对其所关注的事件进行检测和处理；Agent的方法集是体现Agent事件处理能力的成分，描述了Agent处理相关事件的方法.Agent的内部状态集是表现该Agent当前状态的成分，其中包括表征事件的状态.
　　在对Agent的概念及模型研究的基础上，我们提出了一种基于Agent的分布式集成框架DIF/MA，其基本目标是扩展分布计算环境，支持应用系统的集成，实现Agent之间的互操作性，为应用开发者提供开发客户/服务器应用的通用框架，支持应用开发者灵活方便地建立各种客户/服务器应用.
6.2　DIF/MA的结构
　　DIF/MA是一种支持互操作及系统集成的通用框架(如图1)，它为应用系统中各个独立成分之间实现相互作用提供公共通道.DIF/MA框架由如下两个基本机制组成：


图1　DIF/MA的结构
(1) 框架接口：提供一组APIs，该组APIs是对每个框架所提供的服务的简单抽象.框架接口作为框架之上的一个抽象层次.
　　(2) 请求代理机制：该请求代理机制相当于“软件总线”，其作用是跨越地址空间传递请求.
　　DIF/MA的核心是基于Agent的服务请求代理机制，各类服务Agent（简记为SA）可作为“软部件”插接到该框架上.客户应用则通过本地称为服务请求代理（简记为RA）的对象访问SA.RA的存在使得客户应用所需的异地服务如同在本地一样.
　　从客户/服务器计算角度来看，DIF/MA分为客户环境和服务器环境两个部分.DIF/MA客户环境不仅提供了典型SA的RA，而且提供了一组请求构造框架及其相应的功能简洁的API，支持应用开发者建立所需的RA.服务环境中服务可分为基本系统服务、公共应用服务和特殊应用服务.基本系统服务是保证系统正常工作的系统服务.如注册管理服务Register使得客户方的RA可以通过SA的名字在运行时刻动态地确定SA的物理位置；公共应用服务涉及客户应用所需的常规服务；特殊应用服务为特定客户提供针对性的服务.
6.3　DIF/MA的开发框架
　　DIF/MA为应用开发者提供了建立SA及RA的开发框架，应用开发者利用SA和RA开发框架可方便地建立各种新的SA和RA，并且利用DIF/MA的集成框架，可以方便地将SA加入到服务环境中，为客户提供服务.利用DIF/MA的框架结构建立客户/服务器应用涉及系统服务Register，SA，RA和客户应用等几个部分.其中：
　　(1) 系统服务Register
　　Register是系统实施分布资源管理的核心，其作用相当于分布式系统中的名字服务，其基本功能是管理系统中的SA和RA的地址信息及其有关的信息，为RA提供访问SA所需的地址信息，使应用开发者可以方便地开发与SA驻留地无关的分布式客户/服务器应用.Register的地址为系统中的SA和RA共知.Register还为系统提供了基本的系统管理功能.
　　(2) 服务Agent
　　SA通常驻留在一个服务器节点上，为客户应用提供服务.SA在生成时自动将其地址信息，及有关的管理信息注册到Register上；然后启动守护进程监听网络上的服务请求；如果有请求消息达到，则进行相应的处理.
　　为了支持用户建立SA，DIF/MA提供了标准的SA开发框架，该框架的作用是完成接收客户应用发来的各种服务请求的通信管理，并提供于特定服务进程的挂接机制，以便应用开发者采用这一框架和挂接机制建立新的服务并加入到服务环境中.SA框架包括构造框架和执行框架两个部分.构造框架描述应用SA是如何被定义的，执行框架描述应用SA中的服务方法是如何被激活的.在具体实现服务SA的框架时，DIF/MA将构造框架和执行框架中的基本机制定义在标准类ServerAgentBase中，并为应用开发者提供生成应用服务Agent的定义模板，应用开发者按照该定义模板可以方便地生成应用服务Agent.
　　(3) 请求代理Agent
　　RA与客户应用驻留在同一个节点上.RA是SA在客户方的代理，其作用是在客户应用与SA之间建立一座通信的桥梁，负责客户应用与SA之间的通信管理，实现代理机制的思想.RA在生成时自动向Register查询它所代理的SA的地址信.当客户应用欲请求一个SA为其服务时，即向SA在本地的代理RA发送请求，RA利用从Register那里获得的地址信息与SA建立连接，并将请求发送给所代理的SA.
　　为了支持应用开发者方便地建立RA，DIF/MA为应用开发者提供了标准的RA开发框架，该框架包括构造框架和远程消息传递机制两个部分.构造框架描述如何生成SA在本地的代理RA，远程消息传递机制描述RA与SA之间的消息如何进行传递.构造框架为应用开发者定义RA提供支持机制，远程消息传递机制提供各种通信手段，将客户应用的服务请求和服务方法的参数传递给SA，并接收SA的返回结果，最后，将结果返回给客户应用.在具体实现RA的框架时，DIF/MA将构造框架的基本机制和远程消息传递机制定义在标准类RequestAgentBase中，并为应用开发者提供生成RA的定义模板，应用开发者按照该定义模板可以方便地生成RA.
6.4　DIF/MA的应用开发环境和工具
　　DIF/MA为建立分布客户/服务器应用提供了良好的开发手段和基本的分布系统管理功能.基于DIF/MA的框架结构，DIF/MA为应用开发者提供了两种开发分布客户/服务器应用的手段：一是C++风格的API；二是接口描述语言IDL.应用开发者使用C++风格的API以及DIF/MA提供的RA和SA框架，即可方便地开发其应用.IDL是DIF/MA提供给应用开发者的更高层次的开发工具，应用开发者只需定义SA的接口描述说明，DIF/MA即可通过IDL编译器将接口描述说明自动转换成RA的C++代码和SA的实现模板的C++代码.


图2　IDL基础上的DIF/MA应用开发过程
　　基于DIF/MA应用开发环境和工具，应用开发者建立客户/服务器应用的一般过程(如图2所示)为：问题定义、客户/服务器功能分解、定义SA的接口、经IDL编译器自动生成SA的模板及其RA模板、SA模板与SA的方法实现联编生成包含SA的服务软件，以及RA模板与客户应用联编生成包含RA的客户应用.
7　DIF/MA与CORBA的比较
　　DIF/MA基本上是遵循CORBA规范的，DIF/MA中的许多机制与CORBA中的相应的机制相对应：
　　(1) DIF/MA中RA及远程消息机制(RMP)对应CORBA中ORB机制.RA负责自动定位其所代理的SA，并为客户应用与SA之间的交互提供通信机制，负责为客户应用传递请求，并将服务结果返回给客户应用；同时，RA还提供相应的同步和异步机制来保证客户应用与SA之间的同步操作和异步操作；
　　(2) DIF/MA中接口描述语言IDL也是一种中性语言，它是OMG IDL的一个子集.DIF/MA IDL的主要作用是描述SA的接口.SA的接口描述经过IDL编译器编译之后就可以自动地生成RA和SA的模板；
　　(3) SA中的服务方法分发框架对应于CORBA中OA.服务方法分发框架的主要作用是接收来自客户应用的请求，对请求进行处理，激活相应的服务方法，并将服务结果返回给客户应用.
　　尽管DIF/MA中有很多的机制与CORBA中的机制相对应，但与CORBA相比，DIF/MA还存在很多的不足，如DIF/MA中没有提供动态机制；SA的框架结构的划分不甚合理等，这些是DIF/MA中需要进一步加强和改进的地方.
8　结　论
　　分布式集成框架是解决分布应用集成和实现应用互操作性的一种比较好的方法.其好处在于它将实现框架之间关系的责任交给集成框架来完成，从而使应用开发者将主要精力集中在应用对象的开发上.本文所提出的集成框架对分布应用的集成和实现应用的互操作提供了较好的支持.其中基于Agent的服务请求代理机制超越了传统的客户/服务器计算的功能，有助于适应新的协同工作的应用需求.
作者简介：史殿习，男，1966年生，博士研究生，主要研究方向为分布式计算.吴泉源，男，1942年生，教授，博士生导师，主要研究方向为分布式计算及人工智能.王怀民，男，1964年生，博士，副教授 主要研究方向为分布式计算及人工智能.邹鹏，男，1958年生，教授，博士生导师，主要研究方向为操作系统及分布式计算.
作者单位：史殿习　吴泉源　王怀民　邹　鹏　国防科学技术大学计算机科学系　长沙　410073
参考文献
1　Lewie T G. Where is client/server software headed. Computer, 1995, 28 (4): 49～55
2　Adder R M. Emerging standards for component software. Computer, 1995,28(3): 68～77
3　HeSham EL-Rewini, Soct Hamilton. Object technology. Computer, 1995,28(10): 58～72
4　Genesereth M R, Ketch S P. Software agents. Communication of the ACM, 1994, 37(7):48～53
5　Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG, 1998
收到日期：1998-07-16
修改日期：1999-05-12
