corba/com/dcom

分布式计算环境与多层结构的发展背景

早在70年代末第一个关系型数据库管理系统出现时，计算机的数据库时代就已悄然开始。那时的观念是由应用程序与关系型数据库共享统一文件系统，这种数据处理的模式一般称为单层结构。由于这种结构的数据库程序占用计算机资源较多也不利于多用户环境数据库的访问，于是在80年代中期，数据库应用开始转向C/S（Client/Server） 结构， 也就是所谓的两层结构(2－Tier)。如图一：

这种结构在近十年内不但得到了广泛的运用，而且相当成功。然而，在两层C/S 结构成功的背后却逐渐暴露出其构架上的缺陷。其中最明显的问题表现在应用程序的伸缩性和维护方面。例如，一个跨国企业如何把数据库管理系统及其应用程序分散到十分缓慢的网络上， 如何控制数据的统一性和完整性；一旦应用程序有任何改动，维护人员就必须修改每一个客户端上的应用。特别是每一个客户端往往必须配置数据库的客户端服务或ODBC/BDE软件,使得客户端占用资源很多,配置也很繁琐。

    90年代中期后,由于分布式计算技术和Web的迅速发展，数据库应用系统在传统的 C/S 结构的基础上，出现了重要转变：在客户层与数据库服务器层之间增加了应用程序服务器层，应用程序服务器包括了统一的界面、业务规则的封装和数据处理逻辑的规定等等。这种新的结构就是所谓的3层或多层结构。如图二：

 

多层应用服务技术允许分割应用程序，本地计算机上无须安装一整套数据库客户工具，就可以在另一台机器上存取数据。同时它允许对业务规则和进程进行集中管理，并在整个网络上分发、 实现进程负载的动态调节。由于三层结构中中间层并未明确确定定义，而且中间层可以包括所有与应用程序的界面和长久的数据存储无关的处理。假定将中间层划分成许多服务程序是符合逻辑的，那么将每一主要服务都视为独立的层，那么三层结构就成为了N层结构，典型的例子就是基于Web的应用程序。 其层次结构为：

■ 1层,由Web浏览器实现的一个客户层的界面.

■ 2层,由Web服务器实现的一个中间层的任务分配机制.

■ 3层,由一些服务器端脚本(script)实现的中间层服务.

■ 4层,由关系数据库实现的数据层存储机制.

下面将介绍几种常见的分布式对象:

1.1 COM/DCOM(Component Object Model/Distributed Component Object Model)

20世纪90年代初期,Microsoft提出了功能强大的对象链接与嵌入(Object Linking and Embedding,OLE)标准,并创建了组件对象模型(COM),COM为实现OLE可视化提供了基础设施.随着时间的推移,COM演变为多种技术的基础.依赖COM的最重要的新技术之一就是OCX控件(OLE Custom Control,OCX).1996年Microsoft将ActiveX与可视化控件市场联系在一起.到1996年底,Microsoft又引入DCOM,DCOM是一套基于RPC机制的COM技术扩展,它使COM对象具有分布式功能.由于平台支持有限,COM在非Windows平台上的应用进展缓慢,COM更多地被看作是一个组件体系结构,而不是一个远程体系结构;但是,COM又具有很多远程体系结构的功能,尤其是在基于Windows的平台上使用时.毫无疑问COM是当今最成熟,使用最广泛的组件体系结构.这在很大程度得益于基于Windows的操作系统在桌面系统上的霸主地位.

1.2 CORBA(Common Object Request Broker Architecture)

CORBA 技术规范是OMG（Object Manegement Group）的产品，OMG是一个包含800多个组织的联合协会，CORBA 技术得到许多著名的计算机公司的支持，Oracle的NCA（Network Conputing Architecture）的核心技术也在CORBA。CORBA 是一个完全的分布式对象平台。CORBA协议的核心部件称作对象请求代理ORB（ObjectRequest Broker）。CORBA的对象请求代理（ORB）将客户端程序与它将调用的对象连接起来。客户端通过事先定义好的接口请求对象服务，接口是通过OMG的接口描述语言（IDL）书写。客户端通过IDL存根（STUB）或通过DII（Dynamic Invocation Interface）与ORB核心通信，由于IDL存根表示了客户端实现语言与ORB核心实现语言的对应，故客户端可以用ORB核心支持的任一种语言进行开发。

1.3 其他分布式对象概述

除了主流组件体系结构COM和主流远程体系结构CORBA以外,IBM的SOM/DSOM、Java RMI和ObjectSpace的Voyager也可作为分布式对象的一种选择.IBM的SOM系统对象模型与Microsoft的COM类似,SOM是一个能够提供跨语言互操作的,具有包装组件标准机制的组件体系结构.随后网络扩展功能也加入了SOM,最终导致分布式SOM(Distributed SOM,DSOM)的产生.Java RMI 是一种仅适用于Java的解决方案,它提供了一种精美的机制,可以对Java对象进行远程方法调用.其最大缺点是它只能用Java编程语言,但是如果同时使用Java RMI和CORBA技术可以弥补这一缺点.ObjectSpace是另一种进入分布式对象市场的基于Java的产品,它被称为Voyager.由于Voyager与Java RMI一样只能在Java上直接使用,所以它仍然不会成为主流的通用远程体系结构.

2 Dcom与Corba在起源、技术观点与使用等方面的区别

起源

●COM/DCOM

COM/DCOM的前身OLE(Object Linking and Embedding，对象链接和嵌入)是用于在微软的WIN 3.1操作系统中链接文档。开发COM是为了在一个单一的地址空间中，动态地集成组件。COM为在一个单一的应用程序中复杂客户二元组件的动态使用提供支持。组件交互是基于OLE2界面和协议的。虽然COM使用OLE2界面和协议，但我们也必须知道COM不是OLE。DCOM是COM的扩展，支持基于网络的交互，允许通过网络进行进程处理。

●CORBA

公共对象请求代理体系结构是由对象管理工作组（OMG）开发的。OMG是由成千上百个公司组成的组织，他们致力于构建分布式对象计算的标准体系结构。CORBA基于对象管理体系结构，对象管理体系结构由OMG在1991年发布。CORBA为厂商提供一个标准框架，使他们使用不同的语言、操作系统、和硬件开发出来的应用系统，仍然具有可移植性和互操作性。

技术观点

●COM/DCOM

COM允许客户调用服务，服务是由COM兼容的组件通过定义一个二元兼容规范和实现过程来提供的。COM兼容组件（COM对象）提供了一系列的界面，允许客户通过这些界面来调用相关的对象.COM定义了客户和对象之间的二元结构，并且作为用不同程序语言书写的组件之间的相互操作的基础，只要该语言的编译器支持微软的二元结构。COM对象可以具有复杂的界面，但是每一个类必须具有它自己唯一的类标识符（CLSID），并且它的界面必须具有全球唯一的标识符（GUID），以避免名字冲突。对象和界面是通过使用微软的IDL(界面定义语言)来定义的。COM体系结构不允许轻易地对界面作修改，这种方法有助于防止潜在的版本不兼容性。COM开发者，为了给对象提供新的功能，必须努力为对象创建新的界面。COM对象是在服务器内运行的，服务器为客户访问COM对象提供了三种方法。在服务器中处理（In-process server）：客户和服务器在相同的内存处理进程中运行，并且通过使用功能调用的方法彼此通信本地对象代理（Local Object Proxy）：允许客户使用内部进程通信方法访问服务器，而服务器运行于同一物理机器的一个不同的进程中。这种内部进程通信方法也称为廋远程过程调用远程代理对象（Remote Proxy Object）：允许客户访问在另外机器上运行的远程服务器。客户和服务器的通信使用分布式计算环境RPC.远程对象支持这种方法，被称为DCOM服务器。COM的两个主要的扩展：MTS 和MSMQ是由DCOM提供的。DCOM服务器对象支持多线程。MTS(Microsoft Transaction Server )运行于Windows NT

Server，提供事务导向的进程，并且是基于DTC(Distributed Transaction Coordinator，分布式事务协调)的。MTS作为一个实时中间环境被包含于DCOM中，提供对MSMQ的异步应用操作，以及针对RPC（Remote Procedure Call）的同步操作。DCOM中还内建了远程垃圾收集的功能，使之成为一个健壮的系统。

●CORBA

CORBA被设计和架构为服务于用不同程序语言书写、运行于不同平台上的对象系统。CORBA依赖于ORB中间件在服务器和客户之间进行通信。ORB扮演一个透明地连接远程对象的对象。每个CORBA对象提供一界面，并且有一系列的方法与之相联。ORB负责为请求发现相应的实现，并且把请求传递给CORBA服务器。ORB为客户提供透明服务，客户永远都不需要知道远程对象的位置以及用何种语言实现的。 CORBA是基于对象管理体系结构的（Object Management Architecture，即OMA），OMA为构建分布式应用定义了非常广泛的服务。OMA服务为划分为三层，分别称为CORBAServices, CORBAFacilities, ApplicationObjects 。当应用程序需访问这些服务时，就需要ORB通信框架。这些服务在OMA中实际上是不同种类的对象的定义，并且为了支持分布式应用，定义了很广泛的功能。  CORBAServices（CORBA服务）：是开发分布式应用所必需的模块。这些服务提供异步事件管理，事务、持续、并发、名字、关系和生存周期的管理。CORBAFacilities（CORBA工具）：对于开发分布式应用不是必须的，但是在某些情况下是有用的。这些工具提供信息管理、系统管理、任务管理和用户界面。ApplicationObjects（应用对象）：主要为某一类应用或一个特定的应用提供服务。它们可以是基本服务、公共支持工具或特定应用服务。CORBA界面和数据类型是用OMG界面定义语言定义的。每个界面方法也是用OMG IDL定义的。IDL是CORBA体系结构的关键部分，它为CORBA和特定程序设计语言的数据类型之间提供映射。IDL也允许对原有代码实行封装。IDL是一个面向对象的界面定义语言，具有和C++相类似的语法。由于所有的界面都是通过IDL定义的，CORBA规范允许客户和对象用不同的程序设计语言书写，彼此的细节都是透明的。CORBA在不同对象请求代理之间使用IIOP(Internet Inter-ORB Protocol)进行通信，使用TCP作为网络通信协议。CORBA组件包括ORB核心，ORB界面，IDL存根，DLL(Dynamic Invocation Interface,动态调用界面)，对象适配器，IDL骨架，DSI(Dynamic Skeleton Interface,动态骨架界面)。CORBA运行结构（ORB核心）是由特定开发商决定的，不是由CORBA定义的。不管怎样，ORB界面是一个标准的功能界面，是由所有的CORBA兼容ORB提供的。IDL处理器为每个界面产生存根。这就屏蔽了低层次的通信，提供了较高层次的对象类型的特定API。DLL是相对于IDL存根的另一种方法，它为运行时构建请求提供了一个通用的方法。对象适配器，为把可选的对象技术集成进OMA提供支持。IDL骨架类似于IDL存根，但是，它们是工作于服务器端的（对象实现）。对象适配器发送请求给IDL骨架，然后，IDL骨架就为之调用合适的对象实现中的方法。CORBA依赖于IIOP进行远程对象通信，DCOM则依赖于对象远程处理过程调用（ORPC）以达到相同的目的。CORBA体系结构是基于对象请求代理的；DCOM则以COM作为它的基础，事务处理则依赖于MTS或MSMQ。CORBA规范不是针对特定厂商的，因此CORBA应用能运行于不同的硬件平台上。DCOM则是由微软制定、拥有的体系结构，并且只能运行于微软操作系统支持的硬件平台上。CORBA支持多继承，DCOM仅支持单继承。DCOM每两分钟使用ping的方法检查客户是否依旧处于激活状态，如果客户超过六分钟时依旧未作响应，DCOM则会取消该客户请求。相反地，CORBA不强迫客户保持连接状态，并且不使用保持激活状态的通信方法。由于DCOM使用保持激活状态的通信方式，因此能够决定何时取消请求，从而使用内建的垃圾收集功能;CORBA则不提供内建的垃圾收集方法。

使用方面

●COM/DCOM

COM/DCOM是微软拥有的体系结构，仅被WINDOWS家族的操作系统支持。不管怎样，有第三方厂商提供了在UNIX系统上的DCOM支持。DCOM基于自然的二进制格式，因此执行较快，但是不适用于其它平台。COM/DCOM组件能够访问WINDOWS API，因此能潜在地损坏或危及用户的计算环境。DCOM为分布式对象提供基本的支持，但不支持实时处理，也不适于在需高可靠性的情形下使用。虽然COM已经出现了很长时间，但是，对于它的扩展DCOM，在大量的分布式应用中的前景，还不是很明朗的。

●CORBA

CORBA仅仅是一个规范，而不是一个实现，因此，用户很难确定所购买的产品是否全兼容CORBA。并且没有已定义的测试套件，来测试是否兼容CORBA。对于客户来说，需要有行家对厂家的产品进行评价。CORBA是一个复杂的规范，需要有相当多的专家来开发分布式对象和应用。从另一方面来讲，使用CORBA，能使开发分布式应用变得容易。当然，需要很多对分布式系统设计，分布式、多线程程序设计和调试，内联网，和面向对象分析、设计精通的专家。使用比较,CORBA提供跨平台支持，COM/DCOM则局限于微软操作系统。CORBA和COM都支持用不同的程序设计语言书写的组件。CORBA对象基于1991年颁布的一个标准规范；COM规范和代码则是处于一个不停地变化的过程中，它的文档也只是一个草案。COM最初被设计运行于单一的机器上，而不是大规模的网络上。不管怎样，CORBA从一开始就是被设计用于大规模的分布式应用中的.提供CORBA产品的开发商很多，而COM/DCOM只能从微软处获得。CORBA规范是由OMG定义的，它的成员很多，能够比较好地反映行业的需求，而COM/DCOM是微软所拥有的，它的规范是由微软说了算的。 

3 DCOM与CORBA在企业应用服务器建立中的互用

随着分布式计算对于企业应用拥有越来越重要的作用，各种标准之争越来越火热，最为明显的就是DCOM与CORBA。但由于在目前的形势下，无论是CORBA还是DCOM均还不是事实上的标准，故目前企业开发的应用最好能兼顾这两种标准，实现DCOM与CORBA的集成.所以我们的想法是在一个应用服务器中同时提供DCOM与CORBA接口，同时支持DCOM客户与CORBA客户．这种企业应用程序服务器的模型可以如图三:

 

    由于条件和时间所限,我们不能将我们的观点在短时间内应用在某个系统中,所以在此我将以东南大学计算机科学与工程系硕士研究生李刚以及王茜教授所开发的CIMS-MRPII的成本管理系统为例:
    他们在开发CIMS-MRPII的成本管理系统中,构造了一个能同时支持DCOM/CORBA标准的应用服务器模型，由于该系统涉及大量复杂的对树状BOM表的查询与更改,有很多算法需要占用大量的CPU资源，他们采用放置在较高性能多CPU处理器上的应用服务器集中处理与数据库的连接与查询，客户端将SQL查询和修改语句动态传给应用服务器，再由应用服务器集中与数据库交易。当计算的每一阶段完成后，应用服务器将中间结果传给客户端，客户端可根据此中间结果再构造算法所需的另外的SQL查询和修改语句，由于客户端不与数据库直接连接，顾客户端无需附加配置诸如ODBC/BDE等动态连接库，故客户端是真正的瘦客户。为使应用服务器实现DCOM与CORBA 的双重支持，就必须使应用服务器同时具有DCOM和CORBA接口,他们的做法如下：

首先，在Delphi4/Cbuilder4利用Remote Data Module先构造一个DCOM应用服务器，通过Tprovider提供SQL接口。特别是DCOM应用服务器同时作为OLE自动化服务器，可以被客户端透明激活。然后再使此应用服务器的类型库同时提供CORBA支持。最后，可以使用Type Library工具，提供 CORBA IDL 接口描述语言和微软MIDL接口描述语言，以便今后可以使用合适的工具重新编译应用服务器。由于该应用服务器同时提供DCOM与CORBA 接口，以下具体就这两种不同协议下客户端的建立和他们怎么与应用服务器通信尤其是从Internet上作一讨论

3.1 基于CORBA 的客户端与应用服务器的互操作

    由于CORBA 对象之间可以达到完全的互操作，CORBA对象的通信基于IIOP（Internet Inter-ORB Protocol）协议。我们通过带Javabean的浏览器客户端程序，与支持CORBA的应用服务器通信，从而实现Java与CORBA的互操作。客户端的程序通过本机的ORB请求得到其他CORBA对象的服务，通过IIOP协议，客户端的ORB 可以穿过网络寻找其他系统的ORB及可以提供服务的服务器对象。一旦ORB找到可以提供服务的服务器对象，客户端对象就可以与服务器对象进行通行，仍然基于IIOP协议。由于当今各种流行的Unix平台（如Linux，Solaris）普遍拥有Netscape浏览器，从而我们可以很容易的从Unix客户端访问CORBA服务器。正是由于这种CORBA与Java的互操作，使得我们的企业应用跳出Windows平台限制，实现了企业信息集成中需要的平台无关性。

3.2 基于DCOM客户端与应用服务器的通信

  对于无需相互作用的，文本的或者简单的图形信息，HTML页面可以为用户访问所需信息提供一个著名而有效的方式。对于更加复杂、结构化和相互作用的信息来说，如分布式多层应用系统，我们可以用ActiveX组件来扩展HTML页面，使其以一种用户友好、安全和有效的方式真正的分布式任务。可以在客户端应用一些简单的事务规则来为用户提供迅速的反馈。更加复杂的事务规则能够透明地激活DCOM上应用服务器的组件，特别可以采用Active Form技术直接将Vcl控件转为ActiveX控件嵌入HTML页面。不过需要强调的是，因为DCOM的语言独立性，这些ActiveX组件可以用任何一种编程语言来完成，其中包括C++、Delphi,Powerbuilder, Java、Visual Basic或者Cobol。现存的组件（ActiveX控件）能够被结合到客户端或者用Visual Basic Script或Java Script写的服务器端顾客组件上。值得注意的是，由于DCOM主要实用与Window NT/95/98环境，平台的专有性无疑是其最大的缺陷。另外，采用本模型可以拥有分布计算的公文包的支持， 随着企业的发展,企业内有很多职员的工作地点不是固定的,越来越多的人拥有了笔记本电脑,为适应这种潮流,我们的应用服务器支持一种称作公文包的移动计算工作方式。公文包模式是数据库缓存更新的发展,我们所熟悉的Office软件中也有这样一个公文包,可以预期随着移动用户的增加,公文包模式的支持将是企业应用服务器不可少的功能之一。为采用此种方式，只需如下操作即可:

  (1) 笔记本电脑在公司的局域网内与应用服务器相连并且从应用服务器上获得数据,然后将缓存在本地的数据即进行文件存盘,存盘后即可断线。

  (2) 在断线后, 拥有笔记本电脑的职员就可以在任何地点,如飞机上,从存盘过的文件中读出数据,并可对数据进行各种离线处理和分析。

  (3) 当拥有笔记本电脑的职员回到公司并和公司内应用服务器重新连接后,可以一次新的将离线所作的处理更新到数据库服务器中.

3.3 总结

通过该模型应用服务器的建立，可以非常快速地开发出企业环境下所需的分布式应用，而其可行的要点在于DCOM，CORBA这两种竞争的分布式计算标准在原理和功能上出奇的接近，而采用本模型又恰能使这两种模型的优势互为补充，并为操作系统平台Windows2000（内置com+）作好扩充的准备。

4  结语

   对于分布式计算，COM/DCOM和CORBA都具有可扩展性和健壮性的结构，并且具有各自不同的优势。不管怎样，鉴于它们内在的区别，它们分别适用于具有不同规模和类型的应用中。如果系统主要运行微软操作系统，并且其地域分布上不是很广的话，那么，COM/DCOM或许是比较合适的。CORBA则适用于异构的、大规模的分布式系统。两种技术体系结构有其相同点和不同点，因此，在挑选产品时，必须作一番考虑。当然，由于许多开发商为CORBA应用和COM交互提供了许多解决方案，我们就可以充分利用两者的优势互补来达到我们的应用目的。