爱华网CORBA和DCOM都是被设计用于分布式对象的客户/服务器模式的通信。在这两种技术中，都是一个客户调用一个请求，该请求则由远方的一个对象来实现，远方的对象充当服务器的角色。提供服务的对象都有一个界面（interface，接口），该界面是通过界面定义语言（IDL）来定义的。由于界面的存在，使对象的实现过程对于客户是隐蔽的。CORBA 和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对象可以具有复杂的界面，但是每一个类必须具有它自己唯一的类标识符（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从一开始就是被设计用于大规模的分布式应用中<
