计算机系统结构李欢分布式对象技术综述.docx

上传人:b****7 文档编号:9972056 上传时间:2023-02-07 格式:DOCX 页数:14 大小:243.94KB
下载 相关 举报
计算机系统结构李欢分布式对象技术综述.docx_第1页
第1页 / 共14页
计算机系统结构李欢分布式对象技术综述.docx_第2页
第2页 / 共14页
计算机系统结构李欢分布式对象技术综述.docx_第3页
第3页 / 共14页
计算机系统结构李欢分布式对象技术综述.docx_第4页
第4页 / 共14页
计算机系统结构李欢分布式对象技术综述.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

计算机系统结构李欢分布式对象技术综述.docx

《计算机系统结构李欢分布式对象技术综述.docx》由会员分享,可在线阅读,更多相关《计算机系统结构李欢分布式对象技术综述.docx(14页珍藏版)》请在冰豆网上搜索。

计算机系统结构李欢分布式对象技术综述.docx

计算机系统结构李欢分布式对象技术综述

分布式对象技术综述

第一章绪论

1.1引言

计算机支持下的工作正在转移到一个复杂的分布异构计算环境,它主要由以下特点:

1)场地分布:

由LAN或WAN支持,存在多种网络协议;2)数据分布:

各种形式的数据分散在各节点,以各种形式(文件、数据库、电子表格等)存在;3)硬件平台多样化,从台式机,工作站到大型主机,从单机处理器,对称处理器到大规模并行处理器;4)操作系统多样化,如WindowsNT,各种Unix及VMS等;5)应用平台多样化,包括来自不同开发组织的各种应用软件、中间件和开发工具。

分布异构计算环境的出现是计算机技术发展市场需求驱动的必然结果,是信息随处可得这一人类期盼已久目标的基础。

同时它也给计算机界带来了新的挑战,用何种方法支持这种环境下的工作?

用户在这种环境下以何种方式获取信息?

面对这些问题,急需新模型支持分布异构环境下的协同工作,这个新模型应提供以下主要措施:

1)场地透明机制,屏蔽本地服务和远程服务对应用造成的差异。

2)平台独立机制,支持各种主流机型和操作系统。

3)统一的编程模型,这种统一性应体现在软件体系的不同层次,如操作系统、网络,特别是应用层。

4)互操作能力,不同的应用程序之间可以互相调用。

[1]

随着计算机技术的迅速发展和网络应用的不断深入,迫切需要建立面向对象的、基于网络的、分布的、异构的应用系统,以实现跨越多种操作平台,独立于程序设计语言,并且协同工作,以便能够完成更复杂的任务。

这就要求支撑这种应用的分布式系统具有良好的互操作性、可迁移性以及可重用性。

在这种需求下,分布式对象技术应用而生,并得以迅速地发展。

1.2论文主要内容

本文从以下几个方面论述了分布式对象技术:

1)分布式对象技术的产生背景和核心概念(第二章);

2)三种不同的分布式对象技术的分析和比较以及互操作(第三章、第四章);

3)分布式对象技术未来的发展趋势(第五章)。

第二章分布式对象技术

2.1分布式对象技术的产生背景

90年代出现的分布式对象技术为网络计算平台上软件的开发提供了强有力的解决方案。

分布式对象技术是为了解决分布式异构网络环境下,信息系统集成的异构性、可重用性、互操作性问题,将面向对象技术与分布式计算技术相结合而形成的分布计算技术.目前,分布式对象技术已经成为建立服务应用框架和软构件的核心技术,在开发大型分布式应用系统中表现出强大的生命力,逐渐形成了3种具有代表性的主流技术,即Microsoft的DCOM/COM+技术、Sun公司的J2EE/EJB技术和OMG的COBRA/CCM技术。

分布对象技术是以面向对象技术为主要特征的第二代分布计算技术。

分布计算(DistributedComputing)是近20年来影响计算技术发展的最活跃因素之一,它的发展经历了两种不同的技术路线:

第一种是理想的技术路线,试图在互连的计算机硬件上部署全新的分布式操作系统,全面管理系统中各自独立的计算机,呈现给用户单一的系统视图。

这种方法,尽管产生了许多技术成果和实验系统,但却没有被用户和市场接受。

第二种是现实的技术路线,即在网络计算平台上部署分布计算环境(也称为中间件),提供开发工具和公共服务,支持分布式应用,实现资源共享和协同工作。

90年代,工业界普遍遵循这一技术路线,产生了一系列行之有效的技术和广为用户接受的产品。

面向对象技术已经成为建立集成构架和软构件标准的核心技术.分布对象技术最具代表性的是90年代初CORBA1。

0标准的颁布,揭开了分布对象技术的里程碑。

[2]

2.2分布式对象技术的核心概念

在分布对象计算中,通常参与计算的计算体就是分布对象,分布对象也被称为组件(Component),组件是一些独立的代码封装体,在分布计算环境下组件既可以是一个简单的对象,更多情况下是一组相关对象的组合体。

组件是一些灵敏的软件模块,它们可以位置透明,语言独立,和平台独立地相互发送消息,实现请求服务。

分布对象存在于网络的任何地方,可被远程客户应用以方法调用的形式访问。

至于分布对象是使用何种程序设计语言和编译器所创建,对客户对象来说是透明的。

客户应用无须知道它所访问的分布对象在网络中的具体位置以及运行在何种操作系统上,该分布对象与客户应用可能在同一台计算机上,也可能分布在由广域网(如Internet)相连的不同计算机上。

分布对象具有动态性,它们可以在网络上到处移动。

分布对象技术采用面向对象的多层客户/服务器计算模型,将分布在网络上的全部资源(系统层或应用层)都按照对象的概念来组织,每个对象都有定义明晰的访问接口。

创建和维护分布对象实体的应用称服务器,按照接口访问该对象的应用称为客户。

支持客户访问异地分布对象的核心机制称为对象请求代理(ObjectRequestBroker,ORB)。

ORB处于分布对象技术的核心位置,ORB如同一条”软”总线把分布式系统中的各类对象和应用连接成相互作用的整体。

分布式对象技术是分布式系统的技术解决,是继面向对象技术之后软件开发领域的重大成果。

它把应用系统中所需要的功能归结为一个个的组件对象,并把这些组件对象分布在网络上,通过类似于“软件总线”的结构以完成异构系统上组件对象之间的通信,从而实现了组件对象之间的独立运行与互相操作,大大提高了软件系统开发的效率以及可重用性。

[3]

分布式对象技术是计算机网络技术和面向对象技术相互协调、相互促进而发展起来的。

随着Internet的发展,网络环境变得相当复杂多样,解决异构网络环境下的互操作,当前显得尤为重要。

分布式对象技术的核心内容就是对象之间的互操作。

要实现互操作就必须有一套独立于硬件平台、操作系统和编程语言的接口规范。

本文主要介绍了CORBA、COM/DCOM和Java/RMI三种具有代表性的分布式对象模型及标准。

[4]

第三章分布式对象的三种主流技术

3.1CORBA体系结构概述

3.1.1CORBA的体系结构

CORBA(CommonobjectRequestBrokerArchitecture)是由OMG(objectManagementGroup)制定的应用软件体系结构和对象技术规范。

遵照CORBA规范开发出的分布计算软件环境可以在几乎所有的主流硬件平台和操作系统上运行。

OMG是一个非盈利性国际组织,目前已拥有900多个成员,世界上几乎所有最有影响的计算机公司、著名的工商企业和大学研究机构都是这个组织的成员。

现在,CORBA对象通信使用的协议——IIOP已成为许多公司进行系统集成的基本协议。

[5]

CORBA体系结构如图1所示,CORBA体系结构主要是由对象实现、公共对象请求代理、IDL存根和框架、对象适配器OA、接口存储库、实现存储库等

组成。

[6]

 

1)对象实现(objectImplementation)。

它定义了实现一个CORBA对象IDL界面的方法,对象实现可由不同的语言来编写。

2)公共对象请求代理(objectRequestBroker,ORB)。

ORB在CORBA规范中处于核心地位,它定义了CORBA对象总线,即定义了异构环境下对象透明地发送请求和接收响应的基本机制,是建立对象之间Client/Server关系的中间件。

ORB拦截请求调用,并负责找到可以实现请求的对象、传送参数、调用响应的方法、返回结果等。

Client对象并不知道同Server对象通信、激活或存储Server对象的机制,也不必知道Server对象位于何处、它是用何种语言实现的、使用的是什么操作系统或其他不属于对象接口的系统成分。

ORB屏蔽了对象的通信机制、位置、实现等,提供了异构分布式环境中应用之间的互操作性,同时也保证了多种对象系统之间的无缝连接。

对象请求代理(ORB)为分布式对象提供了通信的基础设施。

ORB负责完成查找对象实现、通知对象实现、传递请求数据等任务。

客户程序所看到的对象接口完全独立于对象实现所在的网络位置、硬件平台,操作系统平台以及编写对象实现所使用的程序设计语言。

为调用对象实现的一个实例对象,客户程序必须首先获取一个对象的引用。

客户程序发出远程调用的方式与本地调用相似,但调用的是远程对象实例的对象引用。

ORB将负责参数打包,并通过网络传递给远程对象所在的ORB,再由该ORB将参数解包后,把调用请求转发给对象实现的一个实例。

客户程序向对象实现传递请求是ORB所提供的基本功能,这包含了为客户程序送出实际参数与送回处理结果。

ORB内核是ORB中真正负责传递请求的部分。

3)IDL存根和框架。

它们将客户服务应用、ORB粘合在一起。

IDL存根和框架提供了静态IDL功能,它是同IDL定义的统一界面,IDL的定义和目的程序之间的翻译是通过IDL编译器自动匹配的。

4)动态调用接口(DynamicInvocationInterfaces,DII)。

这个接口允许客户直接访问ORB提供的请求机制。

5)动态框架接口(DynamicSkeletonInterfaces,DSI)。

DSI允许把请求传送给对象实现,而不需要知道对象实现在编译时的知识。

6)对象适配器(objectAdapter,OA)。

实现了对象和ORB内核间的通信。

7)接口存储库(InterfacesRepository,IR)。

它包含运行时所需要的IDL规范。

IR可以查询用户定义的IDL类型的详细情况,从而提供一个基本类型映射机制。

8)实现存储库(ImplementationRepository,IMR)。

它包含服务器的详细信息(即哪一个执行程序需要被放置到哪一个服务器上)。

OA需要这个信息来自动激活服务器。

3.1.2CORBA规范的特点

CORBA规范充分利用了现今软件技术发展的最新成果,在基于网络的分布式应用环境下实现应用软件的集成,使得面向对象的软件在分布、异构环境下实现可重用、可移植和互操作。

其特点可以总结为如下几个方面:

1)在CORBA规范中引人了代理(Broker)的概念,一个代理至少可以有三个方面的作用:

完成对客户方提出的抽象服务请求的映射;

自动发现和寻找服务器;

自动设定路由,实现到服务器方的执行。

这样用户在编制客户程序时只要完整地定义和说明客户需要完成的任务和目标即可。

2)实现客户与服务对象的完全分开,客户不需要了解服务对象的实现过程以及具体位置。

3)应用程序间的统一接口。

CORBA提供软总线机制,这是系统定义的一组接口规范,使得在任何环境下,采用任何语言开发的软件只要符合接口规范的定义,均能够集成到CORBA系统中。

4)CORBA采用面向对象的软件实现方法开发应用系统,实现对象内部细节的完整封装,保留对象方法的对外接口定义。

5)分层的设计原则和实现方式。

CORBA规范只是针对OMA体系结构中的ORB制定的工业标准,而面向应用的对象定义则可以在OMA的应用对象或应用开发环境中逐步分层定义和实现。

3.2COM/DCOM体系结构概述

3.2.1COM/DCOM的体系结构

COM技术是Microsoft公司的组件对象模型,是在OLE技术上发展而来,经历了OLE2/COM、ActiveX、DCOM和COM+等几个阶段。

COM这一技术部分是作为规范,用于单机上应用之间的通信,对象实现与使用的语言无关。

DCOM是COM的分布式扩展,在RPC之上构造对象的远程过程调用层来支持对远程对象的访问。

Microsoft的COM平台效率比较高,同时它有一系列相应的开发工具支持,应用开发相对简单。

但它的缺点是COM的跨平台性较差,只局限于微软操作平台。

COM只支持封装机制和接口继承,不支持实现继承,但COM组件可以有多个接口,通过包含和聚合实现对象复用,并能以二进制形式发布。

它的IDL基于DCE,与CORBA不兼容且不提供向程序设计语言的映射。

CORBA用接口仓库管理IDL信息并可以从本地和远程访问,COM用类型库来管理IDL信息,只能在本地访问。

与CORBA不同,COM提供了垃圾回收功能。

DCOM是COM在网络上的扩展,从根本上消除了本地和远程对象的差别。

在DCOM环境中,位于某一网络上的COM对象能和另一网络上的COM对象进行通讯,其底层通讯机制是RPC。

[7]

COM的体系结构(图2)包括统一数据传输、持久存储和智能命名、COM核心等。

其中COM核心包括服务控制管理、接口代理、接口基和COM库。

COM核心定义了COM对象与使用者(客户)如何通过二进制标准接口进行交互的规格说明。

持久存储通过IStorage和IStream接口提供了一个“文件系统”。

智能命名通过对象实现接口,使用户可以在以后重新连接一个指定的对象实例,并且使对象实例仍保持原来的状态,另外还提供保存它们名字和其他持久信息的机制。

COM库提供对所有客户及组件都非常有用的组件管理服务。

[8]

3.2.2COM组件的特点

1)语言无关性。

COM规范的定义不依赖于特定语言,它采用的是一种二进制代码级的标准,而不是源代码级的标准。

COM语言无关性为跨语言的开发提供了统一的标准。

目前很多语言都提供对COM的支持。

[9]

2)可重用性。

COM重用性是建立在组件对象的行为方式上的,它指示了COM对象如何重用已有的COM对象功能。

有两种途径:

包容和聚合可实现COM重用性。

3)位置透明性。

组件从一台计算机转移到另一台计算机仅涉及到重新配置的问题,不涉及到一个大的开发项目。

3.3EJB体系结构概述

3.3.1EJB的体系结构

J2EE(Java2PlatformEnterpriseEdition)是由Sun公司于1999年推出的一个支持企业级计算的Java平台。

J2EE提供了一个基于构件的集中式服务器多级应用体系,其基础是EJB(EnterpriseJavaBeans,即企业级Java构件)。

EJB为开发和部署可重用的Java服务器构件定义了一个模型,为Java应用服务器定义了一个标准编程接口。

EJB构件在EJB服务器提供的EJB容器中运行,EJB服务器代表EJB构件自动管理大量的企业级中间件服务,例如事务、状态、持久性和安全性,这使得EJB构件开发人员可以集中精力编写业务逻辑而不是复杂的中间件,从而可以更快地开发出代码质量更高的应用。

[10]

EJB的体系结构(图3)包括服务器(Server)、容器(Container)、远程接口(RemoteInterface)以及EJB-Home等。

 

图3EJB体系结构

EJB服务器是管理EJB容器的高端进程或应用程序,并提供对系统服务的访问。

EJB服务器实际是各种支持EJB安装的服务的集合,这些服务包括分布式事务管理、分布式对象管理和对这些对象的分布式调用以及低层次的系统服务。

1)EJB容器是一个管理一个或多个EJB类/实例的抽象。

它通过规范中定义的接口使EJB类访问所需的服务。

EJB容器管理EnterpriseBean对象的生命周期(包括创建和销毁一个对象),协调分布式事务和实现对象安全性。

2)远程接口(RemoteInterface)列出了EJB类中的商业方法。

EJBObject实现远程接口,并且客户端通过它访问EJB实例的商业方法。

EJB类开发者定义远程接口,容器开发商提供产生相应的EJBObject的方法。

客户端不能得到EJB实例的引用,只能得到它的EJBObject实例的引用。

当客户端调用一个方法,EJBObject接收请求并把它传给EJB实例,同时提供进程中必要的包装功能。

客户端应用程序通过Home对象来位、创建、删除EJB类的实例,通过EJBObject来调用实例中的商业方法。

3)Home接口列出了所有定位、创建、删除EJB类实例的方法。

Home对象是Home接口的实现。

EJB类开发者必须定义Home接口。

容器厂商应该提供从Home接口中产生Home对象的实现方法。

3.3.2EJB组件的特点

1)可移植性。

由于EJB规范颁布了一组明确的EJB容器(供应商服务器)和EJB组件(商业对象)之间的契约,这保证了EJB组件在不同EJB服务器上的可移植性。

2)平台独立性。

EJB体系结构完全独立于任何特定的平台、协议和中间件等基础设施。

一个平台上开发的应用程序不需要做任何修改就可移植到另一平台,完全实现了“编写一次,到处运行”。

3)简化了分布式对象的开发、部署和访问。

EJB分布式对象(一种EnterpriseBean)的开发人员只需依照为EnterpriseJavaBean建立的契约和协议实现对象。

这使整个开发、发布和管理变得非常简单,可降低系统建设成本、减小开发周期。

第四章三种分布式对象技术的比较和互操作

4.1CORBA/DCOM/EJB技术的比较

CORBA、DCOM、EJB是目前三种主流的面向对象分布式中间件技术,从接口定义和开发语言方面、适用平台和通信协议方面、事务管理方面综合来看,CORBA在三者之间有着不可比拟的优势。

[11]

在接口定义和开发语言方面,CORBA采用的接口定义语言是OMGIDL,它采用类似于C++的语法,简单易学,并且可以提供到多种语言的映射,包括Java,C++,C等,可以在使用不同语言的客户机和服务器之间实现异构通信。

CORBA是一个规范,可以用在不同的平台、操作系统和编程语言之上,只要该平台支持ORB的实现,而且有对编程语言的映射就可以。

相对而言,DCOM比较适合与C++紧密集成,对象的实现需要WIN32API的支持。

J2EE则建立在Java语言之上,只能使用Java语言和JavaRMI进行接口定义和应用开发。

虽然Java语言提供了和其它语言的接口,但这种接口使用起来非常复杂。

在适用平台和通信协议方面,DCOM是基于微软操作系统的,使用RPC和安全机制产生符合DCOM协议标准的标准网络包,但DCOM只是简单地把本地跨进程通信用一个网络协议传输来替代。

虽然通过使用第三方组件,开发者可以实现其它操作平台上的DCOM组件,但这些实现必须和微软的实现相匹配。

J2EE是一种纯Java的解决方案,只要安装有Java虚拟机,就可以实现J2EE,但是它对集成的支持却很脆弱。

EJB使用Java远程方法调用接口RMI,RMI使用JRMP作为通信传递协议,但JRMP是一个非标准的协议,不允许使用交叉语言编写的对象之间进行通信,这就要求客户端和服务器都必须是基于Java的。

CORBA使用IIOP和GIOP作为通信层协议,两个协议从本质上来讲非常简单,但提供了建立可扩展的CORBA服务器的能力。

在分布式事务处理方面,DCOM没有提供自动的容错和负载平衡服务,这个工作全是交给MTS来完成的。

EJB使用Java事务服务JTS来完成分布式事务处理,应用程序通过JTA使用事务管理功能。

CORBA规范中的OTS为分布式CORBA对象提供了事务管理的接口,支持平面事务和嵌套式事务,同时OTS基于X/openDTP标准,所以不是基于CORBA的应用程序也可以与OTS互操作。

三种技术的综合比较如表1所示:

 

 

表1给出了这三种分布式对象模型的比较,其中:

*继承性:

主要反映在基础平台对应用程序互操作能力的支持上。

它要求将分布在不同平台/操作系统上、采用不同的语言或者开发工具生成的各类商业应用必须能集成在一起。

*可用性:

要求在企业应用中能够稳定/安全、可靠地运行。

*可扩展性:

能够协调不同的设计模式和实现策略,可以根据企业计算的需求进行裁剪,并能迅速反应市场的变化和技术的发展趋势。

4.2三种分布式对象模型的互操作

4.2.1CORBA组件间的互操作

CORBA组件间的互操作是建立在具有相同的ORB的基础上。

ORB间的互操作主要通过建立ORB间的桥接实现。

ORB的桥接主要分为嵌入桥接和请求级桥接。

嵌入桥接是在ORB间建立桥接的最直接的方法,其实现是在ORB内增加一个新的进程间通信模式,这就要对ORB作一个根本性的改变。

请求级桥接是在客户机ORB外增加一个ORB代理对象,将请求传递给客户机ORB中的代理对象,代理对象将请求内容翻译成服务器ORB能理解的形式,代理对该服务器对象调用所需操作。

ORB的这种桥接技术,虽然从理论方面可以实现ORB间的互操作,但在实际中ORB产品比较多,要实现所有ORB间的桥接会成为非常繁杂的一件事。

4.2.2CORBA和EJB间的互操作

根据按值传递(Object-by-Value)规范实现的IDL反编译工具可以从JavaRMI实现类生成IDL文件,根据Java到CORBA的映射规范和EnterpriseJavaBeanstoCORBAMapping的规范可以确定CORBA和EJB架构各元素之间的对应关系。

目前很多ORB产品都实现了RMIoverIIOP,像Sun的JavaIDL,InPrise的VisiBroker,以及些开发源码的ORB产品,如OPenORB,JacORB等。

应用服务器中添加CORBA功能后,可以在CORBA代码中访问EJB对象这段代码可以是CORBA客户端,也可以是CORBA服务器端,为了能提供如上所示的CORBA功能,需要把EJB的Bean实例封装成一个CORBA对象,只有这样才能被ORB定位,接受ORB传来的客户端请求。

共享的CORBA服务提供一些公用的CORBA相关的预备操作和共享信息。

每个EJB独立的CORBA功能,包括为每个容器动态生成可以接受10P方式请求的Home对象和IIOP方式的EJB对象,用来响应通过ORB传来的客户端请求。

其中Home对象负责对EJB的Home接口中的远程方法调用;EJB对象负责对EJB的Remote接口中的远程方法的调用。

[12]

4.2.3CORBA和COM/DCOM间的互操作

在DCOM中,客户机存根称为代理(Proxy),而服务器存根称为存根(Stub)。

相反,CORBA中的客户机存根称为存根(Stub),而服务器存根称为框架(Skeleton)。

在DCOM和CORBA之间由于存在以下方面的差异性,使得互操作显得很困难。

1)通信终端命名方式的不同:

在ORPC协议中,为了在网络中通信,通信终端必须命名。

在CORBA中,这种命名被称为InteroperableObjectReference。

IORs以简洁的地址信息来描述通信终端,而在DCOM中被称为OBJREF,它将分布引用计数同终端/对象标识连接作为命名。

IORs与OBJBEFs不能相互转换,这就阻碍了COM/DCOM与CORBA之间的通信。

2)数据类型、对象接口数目的不同:

CORBA中,只支持一个接口定义,而在COM/DCOM对象中,可支持多个接口;COM/DCOM与CORBA数据类型有很大差别,成为COM/DCOM与协作的障碍。

3)有效载荷参数值形式不同:

在DCOM中,有效负载是用一种称为网络数据表示法(NetworkDataRepresentation,DR)的格式编写的。

在CORBA/1I0P中,有效负载是用通用数据表示法(CommonDataRepresentation,CDR)编写的。

由于这两种形式的数据总存在微小的差异,使得COM/DCOM与COBRA不能互操作。

总之,传统分布式对象模型之间的互操作存在许多问题。

如果要开发一个DCOM应用程序,分布式应用程序中所有的参与节点都必须以Windows风格运行。

如果要开发CORBA应用程序,其程序环境中的每个节点都需运行相同的ORB产品。

现在有不同厂商的CORBA应用程序能够相互操作,但是这种互操作性并不能扩展到安全与事务管理那样更高级别的服务中,而且所有特定厂商产品的优化在这种情况下将会丢失。

使用JavaRMI和EJB开发应用程序,则将开发人员局限在Java语言上。

而且,使用传统分布式对象模型构建的应用系统还存在一个共同的缺陷:

它们要求服务客户端与系统提供的服务本身之间必须进行紧密藕合,即要求一个同类基本结构。

因此,这样的系统往

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 党团工作 > 入党转正申请

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1