COM (Common Object Model)有时被称为公共对象模型，微软官方则称之为组件对象
模型(Component Object Model)。DCOM用于分布式计算，是微软开发设计的，作为对CO
M的一个扩展。CORBA （Common Object Request Broker Architecture）表示公共对象
请求代理体系结构，是由对象管理工作组（OMG）开发的。COM/DCOM和CORBA都是用面向
对象的方法，进行软件组件的开发和应用。它们是客户/服务器世界中，进行应用系统开
发时的两个竞争对手。这些体系结构都支持分布式计算，并且提供对交互操作性和有限
的可移植性的支持。在创建可扩展的客户/服务器系统时，分布式计算技术是必须的。由
于这些分布式对象里面封装了数据和商业规则，因此，它们能存在于系统的任何部分。
现在异构系统越来越普遍，这就导致分布式对象也变得越来越流行，并且，它们在连接
异构系统时确实做得非常好。
CORBA和DCOM都是被设计用于分布式对象的客户/服务器模式的通信。在这两种技术
中，都是一个客户调用一个请求，该请求则由远方的一个对象来实现，远方的对象充当
服务器的角色。提供服务的对象都有一个界面（interface，接口），该界面是通过界面
定义语言（IDL）来定义的。由于界面的存在，使对象的实现过程对于客户是隐蔽的。C
ORBA 和COM都是通过RPC和引用远程对象的方法来实现的。这两种技术中，对数据类型的
支持都局限于几种数据类型，这些数据类型被映射到多种程序设计语言中。
起源
●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对象可以具有复杂的界面，但是每一个类必须具有它自己唯一的类标识符（CLSI
D），并且它的界面必须具有全球唯一的标识符（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（Re
mote Procedure Call）的同步操作。DCOM中还内建了远程垃圾收集的功能，使之成为一
个健壮的系统。
●CORBA
CORBA被设计和架构为服务于用不同程序语言书写、运行于不同平台上的对象系统。
CORBA依赖于ORB中间件在服务器和客户之间进行通信。ORB扮演一个透明地连接远程对象
的对象。每个CORBA对象提供一界面，并且有一系列的方法与之相联。ORB负责为请求发
现相应的实现，并且把请求传递给CORBA服务器。ORB为客户提供透明服务，客户永远都
不需要知道远程对象的位置以及用何种语言实现的。
CORBA是基于对象管理体系结构的（Object Management Architecture，即OMA），O
MA为构建分布式应用定义了非常广泛的服务。OMA服务为划分为三层，分别称为CORBASe
rvices, 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。D
LL是相对于IDL存根的另一种方法，它为运行时构建请求提供了一个通用的方法。对象适
配器，为把可选的对象技术集成进OMA提供支持。IDL骨架类似于IDL存根，但是，它们是
工作于服务器端的（对象实现）。对象适配器发送请求给IDL骨架，然后，IDL骨架就为
之调用合适的对象实现中的方法。
CORBA依赖于IIOP进行远程对象通信，DCOM则依赖于对象远程处理过程调用（ORPC）
以达到相同的目的。 CORBA体系结构是基于对象请求代理的；DCOM则以COM作为它的基础
，事务处理则依赖于MTS或MSMQ。CORBA规范不是针对特定厂商的，因此CORBA应用能运行
于不同的硬件平台上。DCOM则是由微软制定、拥有的体系结构，并且只能运行于微软操
作系统支持的硬件平台上。CORBA支持多继承，DCOM仅支持单继承。DCOM每两分钟使用p
ing的方法检查客户是否依旧处于激活状态，如果客户超过六分钟时依旧未作响应，DCO
M则会取消该客户请求。相反地，CORBA不强迫客户保持连接状态，并且不使用保持激活
状态的通信方法。由于DCOM使用保持激活状态的通信方式，因此能够决定何时取消请求
，从而使用内建的垃圾收集功能； CORBA则不提供内建的垃圾收集方法。
使用方面
●COM/DCOM
COM/DCOM是微软拥有的体系结构，仅被WINDOWS家族的操作系统支持。不管怎样，有
第三方厂商提供了在UNIX系统上的DCOM支持。DCOM基于自然的二进制格式，因此执行较
快，但是不适用于其它平台。COM/DCOM组件能够访问WINDOWS API，因此能潜在地损坏或
危及用户的计算环境。DCOM为分布式对象提供基本的支持，但不支持实时处理，也不适
于在需高可靠性的情形下使用。虽然COM已经出现了很长时间，但是，对于它的扩展DCO
M，在大量的分布式应用中的前景，还不是很明朗的。
●CORBA
CORBA仅仅是一个规范，而不是一个实现，因此，用户很难确定所购买的产品是否完
全兼容CORBA。并且没有已定义的测试套件，来测试是否兼容CORBA。对于客户来说，需
要有行家对厂家的产品进行评价。CORBA是一个复杂的规范，需要有相当多的专家来开发
分布式对象和应用。从另一方面来讲，使用CORBA，能使开发分布式应用变得容易。当然
，需要很多对分布式系统设计，分布式、多线程程序设计和调试，内联网，和面向对象
分析、设计精通的专家。
使用比较
CORBA提供跨平台支持，COM/DCOM则局限于微软操作系统。CORBA 和COM都支持用不同
的程序设计语言书写的组件。CORBA对象基于1991年颁布的一个标准规范；COM规范和代
码则是处于一个不停地变化的过程中，它的文档也只是一个草案。COM最初被设计运行于
单一的机器上，而不是大规模的网络上。不管怎样，CORBA从一开始就是被设计用于大规
模的分布式应用中的。
提供CORBA产品的开发商很多，而COM/DCOM只能从微软处获得。CORBA规范是由OMG定
义的，它的成员很多，能够比较好地反映行业的需求，而COM/DCOM是微软所拥有的，它
的规范是由微软说了算的。
结语
对于分布式计算，COM/DCOM和CORBA都具有可扩展性和健壮性的结构，并且具有各自
不同的优势。不管怎样，鉴于它们内在的区别，它们分别适用于具有不同规模和类型的
应用中。如果系统主要运行微软操作系统，并且其地域分布上不是很广的话，那么，CO
M/DCOM或许是比较合适的。CORBA则适用于异构的、大规模的分布式系统。两种技术体系
结构有其相同点和不同点，因此，在挑选产品时，必须作一番考虑。当然，许多开发商
为CORBA应用和COM交互提供了许多解决方案。看上去，COM/DCOM和CORBA将会继续强有力
地竞争下去，并且会长久地并存。
