这个问题很麻烦，我试着说说看：
1、首先，CORBA在现有桌面平台很少出现（包括INPRISE的VisiBroker）,
将它扩展到大量的用户群很可能是既费钱、又费时的提议。DCOM包含在
Windows NT 4.0中,可作为一个附件下载到Windows 95。但从服务的角
度来看,它只能在NT下使用,将Unix对象放置到链路上则很困难。相反,
CORBA对象请求代理ORB(object request broker)在几乎所有现行服务
器、客户机平台下都可用。
2、不久前，Netscape Communications 和Visigenic Software
已共同颁布了一项授权协议,让Netscape在Communicator和SuiteSpot
中加入Visigenic的基于Java的VisiBroker ORB ,这无疑给了CORBA
(至少是它的Visigenic版)一个更大的用户群。此外,VisiBroker遵从
CORBA IIOP(Internet Inter-ORB Protocol)协议,这意味着它可以与
其它遵从IIOP协议的公司进行合作。
与此同时,微软通过将技术授权给Software AG、Digital Equipment 、
HP几家公司而扩充了DCOM的平台支持。Software AG已开始交运EntireX,
它是一种用于Sun的Solaris 2.5操作系统的DCOM接口。除提供运行于
Linux 2.0 和Digital Unix 4.0的DCOM β版外,该公司还计划向HP的
HP-UX,IBM OS/390、AIX、OS/400,SCO UnixWare,Digital的OpenVMS
和Siemens-Nixdorf的SIXIX开放版权，另外Digital公司也计划将DCOM嵌入Digital Unix中,HP也正在将它嵌进HP-UX。
或许出于矛盾的心态,或许是出于战略上的考虑,许多公司都在其产品中将CORBA
和DCOM都包容进来，例如：包括Iona、HP、Digital和Sun在内的一些公司,
开发了CORBA到DCOM的桥。而OMG正期待着其COM-CORBA交互规范会被尽快采纳。
3、两者的区别：
COBRA:企业级的设计
CORBA 2.1技术规范是OMG的产品,OMG是一个包含760多个组织的
联合协会。COBRA的强壮在于它的跨平台、跨语言能力。OBR产品支持
目前市场上用到的大多数平台,并且大部分商品CORBA支持多种编程语
言,像DELPHI、C、C++、Cobol、Java及Smalltalk。
但由于OMG向各公司提供的是技术规范而非实现细节,因此每种OBR
版本都不是完全相同的。有些OBR公司在其产品上包含了扩展性能。
在利用这些扩展性能时,开发者可能不得不损失掉OBR间的互操作性和
移植性。
CORBA给出了一个在多种环境下面向对象的编程范例。在CORBA下
的每一个应用,无论它是运行在客户机端还是服务器端,都是作为一个
对象来对待的,服务器上的对象可以调用客户机上的对象,反之亦然,
因而服务器与客户机间的传统界限变得模糊起来。
CORBA体系中的核心成分是ORB,它负责将客户机的需求传递到本
地或远程服务器上,并将结果返回。对一个客户机来说,服务器的位置
应该是透明的。同DCOM客户机一样,CO RBA客户机也是通过界面与服
务器组件进行通信的,界面中存放了服务器组件的调用方法和可用函
数。这些界面是用界面定义语言(IDL)来定义的。
为了保证在语言、操作系统、网络及ORB之间的互用性,OMG提供
了标准IDL语言映射,像数据类型映射、异常处理映射,以便提高代码
的重用性。CORBA还支持继承,允许一个界面从另一个中导出,并继承
该界面的实现。
CORBA允许一个客户机组件以静态和动态两种方式调用服务器组
件。如果使用静态调用,客户机要指定是哪个服务器组件、调用的是
哪个函数。使用动态调用,预先不知道服务器组件的界面,客户机要在
运行时通过CORBA提供的Naming Server或Trader Server找到服务对
象,然后再动态地调用服务方法。与静态调用相比,动态调用更加灵活
,因为它能随时提供新的服务和方法,只要它们可用。而另一方面,动
态调用编程会更复杂些,执行也会更慢一些。
为了解决CORBA 1.0的互操作问题,CORBA 2.0提供了一个解决方
案: 每一个遵从ORB 的CORBA2.0或者支持IIOP协议或者提供一个桥,
能将一个OBR转换到另一个。此外,OBR为每一个对象建立了一个唯一
标识IOR。根据IOR,CORBA应用能够找到位于网络上任何位置的对象。
虽然在所有ORB公司中还没有被统一或特别好的实现,但CORBA的
安全规范提供了比DCOM更加完善的安全模型。CORBA的安全服务提供
了鉴别、授权、加密、安全域、甚至还有跟踪网络上安全行为的审核
服务。 另外还提供了一些安全界面,允许在客户应用中操作安全选项
;还有一些管理界面,允许对ORB的访问控制策略进行操作。
在一个分布式组件环境下,一个客户机对象可能调用另一个对象,
而它又可能会再调用另外一个,CORBA允许管理者为调用链上的每个调
用点建立一个访问决策。CORBA的安全服务允许管理者选择审查的事
件、对象类型、操作及时间。
除了对象间相互调用的机制外,OMG还提供了CORBA服务及CORBA工
具的技术规范,以便在CORBA环境下管理和操作对象。由于并不要求CO
RBA服务和CORBA工具完全一致,不同公司可能提供的是不同的服务和
工具。其中最重要的是OBR,它的作用只是作为一个对象通信器,传送
需求,返回结果。此外,还有性能监控、负载平衡或容错功能。
对CORBA进行的测试
学习IDL语言并不困难,但熟悉一家公司提供的命令集则要花费一
些时间。如果面对的是多种OBR,问题会更加复杂,因为不同的ORB公司
可能提供不同的命亮铑集。与微软的DCOM不同,大多数ORB公司除了ID
L编辑程序外没有提供创建CORBA组件的工具,编辑程序是与ORB一起提
供的,根据用户的IDL代码生成客户机存根模块(client stub)和 服务
器骨架语句(server skeleton)。进行客户/服务器组件开发,一般要
使用与ORB具有相同编辑语言的第三方开发工具。
我们发现由同一家公司提供的运行在不同平台上的两种ORB,相互
间通信进行得很顺利,在它们之间调用对象没有碰到麻烦。另一方面,
让一家公司的ORB应用调用另一家的则要棘手得多,我们必须使用不同
的程序。详细地说,我们首先要获得被调用对象的通用标识IOR,再用
本公司提供的命名服务器(Naming Server)将该对象注册,然后才能使
用命名服务来调用它。如果有大量对象,这种方法可能会变得很慢。
DCOM:强大的工具支持
DCOM,作为微软的分布式计算策略,是在开放性软件DEC远程过程
调用协议的基础上开发的。DCOM是微软的组件对象模型COM的一个扩
增版,而COM是ActiveX的基础技术。COM和DCOM最大的不同在于COM组
件是运行在单机上,而DCOM组件则是分布在网络上。尽管DCOM 在非Wi
ndows平台上也可以使用,但会受到很多限制,因此它更适用于Windows
环境。
DCOM的优点之一就是有很多工具可以用来创建COM和DCOM组件——
C++工具(如微软的Visual C++)、RAID工具(如Visual Basic、Del
phi及PowerBuilder)。此外,还有大量的已被建立、商品化了的Activ
eX组件可供使用。
同CORBA一样,DCOM也是采用面向对象的方法,所有应用都被看作
是一个对象。在DCOM环境下,客户应用与COM组件的通信只需通过包
含指向该对象可用函数的指针的界面。在COM和DCOM中,界面是关键,
组件是界面的具体实现,一个组件可以被支持相同界面的另一个组件
透明地删除和替换。DCOM支持界面继承,即一个界面可以从另一个界
面中导出,但导出的界面不能继承原始界面上的组件。DCOM允许你使
用现存组件,这可通过在应用界面中插入指向该组件的指针来实现。
每一个对象必须在本地机上进行注册,以便客户能通过注册上的
对象唯一标识找到该对象。同CORBA一样,DCOM也支持动态和静态两种
对象调用,但实现上稍有不同。在CORBA下,不管哪种调用方法,实现
界面是一样的;而DCOM则提供了两种界面,不同的调用方法需要不同的
界面来实现。
使用静态调用,我们要定义一个界面和它的组件,让MIDL编辑程序
自动产生连接这些组件的代理存根模块(proxy-stub)代码。DCOM是通
过类库来支持动态调用的,类库中包含了描述组件的文件,客户应用在
运行期间通过一个被称为IDispatch的COM界面来获取这些界面,优点
是无需手工定义界面、让MIDL产生proxy-stub代码了,我们可以使用
缺省的IDispatch代理存根模块代码。
CORBA和DCOM都支持多线程服务。在CORBA中,创建一个线程前不
必进行初始化,所有的工作都是由ORB通过一个对象适配器来处理的。
而DCOM则要求对线程上使用的COM库进行初始化。
同CORBA一样,DCOM也允许现存的客户机和服务器应用通过在主机
上注册和配置分布到网络上。你可以使用Windows NT中的DCOM配置工
具来完成这项工作,也可以使用Micro soft Visual C++提供的
OLEView或Win32软件开发工具集。
DCOM采用的是Windows NT的安全体制而自己没有提供。对于非Windows平台,
DCOM将使用这些平台上的安全机制,同时提供了一个与Windows NT兼容的安全措施。
DCOM还提供了一些访问控制表,其中存放了用户和工作组对一些特殊组件的访问权限。
这些表可以用DCOM配置工具来配置,也可以在程序中通过调用Windows NT的注册程序
或Win32的安全函数来配置。此外,DCOM还提供了一些应用界面,组件可以使用它们来
进行自己的安全检查。如果服务器和客户机上的组件都没有执行任何安全检查,
系统将使用缺省的安全检查。
DCOM下没有提供自动的容错和负载平衡服务。对付这两个企业级
的关键问题,微软的事务处理服务器MTS与微软提供的其它方法相比,
似乎是最具吸引力的方案,因为它提供了事务处理回滚和负载平衡功
能。如果你不想采用MTS,微软还提供了一个让客户检测与服务器的连
接是否还存在的迂回协议。如果探测到服务器已死或连接已被中断,
周密设计的客户程序在必要时能重新连接服务器,并处理丢失或破坏
的数据。但在实践中,回溯一个程序或手工恢复数据可能会花费相当
长的时间,让大量对象在网络间进行迂回将是一个巨大的开销。
第二个可能的解决方案是将服务器组件安装在两台不同的机器上
,让客户同时连接两台,并向其发送需求。
学习基础的不同：
DCOM学起来并不是特别容易,尤其对那些没有OLE背景知识的开发
者,即使有OLE经验,要完全了解底层DCOM的工作也得花费一些功夫。
所幸的是微软提供了一个极好的工具——活动样板库ATL(Active Tem
plate Library),可用来创建DCO和MCOM对象。
通过ATL COM AppWizard,Visual C++可生成大多数后台处理代码
,如代理和存根模块代码,创建必要的COM类。通过ATL ObjectWizard,
你可以选择要插入的COM对象类型,配置对象的属性,如线程模型、界
面类型,然后由该Wizard根据你的配置生成C++代码。
我们发现使用Wizard可以让我们把精力集中在业务问题的实现组
件上,大大缩短了开发周期。另外,Wizard还是一个很好的学习工具,
研究它生成的代码可帮助我们了解COM和DCOM是如何工作的。
开发过程的区别：
创建CORBA界面
● CORBA开发体系
建立一个完整的使用静态调用的CORBA应用的方法说明了这样一
个事实,客户必须预先了解它要使用的对象服务。因此,客户端和服务
器端的代码要同步编译、连接到客户存根模块和服务器骨架语句代码
上。
● 静态调用的开发过程
1使用界面定义语言IDL定义对象。
2使用ORB的IDL语言编译器将对象定义进行编译,生成客户端的存
根模块和服务器端的骨架语句。
3创建应用的客户端部分和服务器端对象。
4使用语言编译器编译客户和服务器端的代码,并将它们连接到步
骤2中产生的存根模块和骨架语句上。
5将对象定义装入界面仓库,运行中的服务器对象记录到工具仓库
中。
6将对象实例化。
CORBA的体系结构
●CORBA为满足适应性定义了多种界面类型
COBRA技术规范的一个主要目标就是将客户和对象工具(Object i
mpelemation)的多种性能进行集成,因此对象管理组重点强调的是静
态和动态界面的标准化,而不是ORB本身的实现细节。
●ORB的结构
1、动态调用界面 在运行时被调用,用来发现新对象以及它们的界
面和它们的定义。
2、静态IDL stub 提供对象服务的预定义界面,它规定了客户如何
调用服务器上的相应服务,其中包括进行参数配置的代码。
3、ORB界面 为开发者提供了一个访问ORB函数的接口。
4、对象适配器 相当于ORB与对象工具之间的接口,用来记录对象
工具(Object imple menttation)、激活服务。
5、静态IDL骨架语句 对服务器输出的每个服务提供了一个预定
义界面。
6、动态骨架语句界面 运行时被调用,提供了对服务器组件请求的
即时连接。
7、界面仓库 存储已知界面的定义,你可以从中获取所用被注册的
组件界面。
8、对象工具仓库 存储服务器支持的类信息和实例化了的对象以及
它们的界面定义。
请求CORBA对象服务
●使用CORBA静态调用界面的调用方法
IDL存根模块和骨架语句定义了CORBA静态方式调用对象和使用它
们的服务。与动态调用界面让客户在运行时指定服务不同,静态界面
是在编译时被定义的。但由于它更容易理解,调用过程更自然,许多开
发者可能更愿意选择它。下列两图分别说明了在单一ORB上和在不同O
RB间的静态调用,重要的是要注意,与DCOM一样,系统维持了对象位置
的透明性。
● 单一ORB请求
1、客户通过IDL存根模块发出调用方法,存根模块将其转成成数据
并将请求传递到ORB 内核。
2、ORB内核找到相应的服务器对象,用对象适配器激活它,然后将本
次调用传递给IDL骨架语句。
3、骨架语句将数据转换成服务器对象能理解的格式,然后调用被请
求的方法,最后将返回值和参数沿相同路径传回客户。
● ORB间的请求
1、客户发出调用方法,过程同上。
2、ORB A找到ORB B域上的服务器对象,并将请求通过IIOP协议传送到ORB B。
3、ORB B 激活该对象,将请求传递给IDL骨架语句,过程同上。
4、骨架语句转换数据并调用方法,过程同上。
COM/DCOM概况
● DCOM为远程服务提供本地/远程透明度
使用COM,客户能够透明地访问进程内或本地跨进程的服务对象,
分布式COM(DCOM),通过一个远程对象代理和微软的对象远程过程调用
ORPC,增加了调用远程服务器对象的能力。而本地跨进程调用则是通
过独立于操作系统的进程间通信完成的。与CORBA一样,DCOM 支持静
态和动态两种调用方法。
● 进程内、本地跨进程及远程请求
1、调度程序(marshaling sequence)创建客户端代理对象,为客户
应用提供了指向服务器对象界面的指针。
2、调度程序还创建存根模块对象,由它向服务器对象发送和接收参
数,使用实际界面指针调用服务器对象。
开发DCOM界面
● Visual C++简化了界面创建
微软提供的两个开发Wizard使得创建COM对象的工作变得更加容
易,应用Wizard产生一个基本框架,你可以在此基础上根据需要添加自
己的IDL代码,对象Wizard则帮助你在最后编译前装配COM对象。
● COM对象开发
1、Visual C++的ATL COM应用向导生成一个IDL基本框架文件。
2、根据需要在IDL文件中增加微软的界面定义语言MIDL。
3、使用MIDL编译程序编译IDL文件,生成必要的proxy和stub代码。
4、使用ATL对象向导添加你要的COM对象。
5、编译并建立最后的COM对象。
6、编写应用,访问该COM对象。
7、将该对象移到远程机器上并在那里登记。
请求DCOM对象服务
● 使用分布式COM 的调用方法
在调用一个类的方法前首先要将这个类进行实例化(也称为生成
一个对象),要做到这一点,必须将COM库放置到客户机上。COM库没有
与Windows 95一起交运,但可以从微软的Web站点上下载;Windows NT
4.0中包含了它。
● 生成一个对象
1、客户应用通过将对象的类标识和界面标识传送到COM库发出对类
实例的请求。
2、COM库检查服务器系统登记,找到服务工具,然后启动它。
3、该服务产生一个对象并将界面指针返回给COM库,由它将指针传
送给客户。
4、此时客户机即可自由地调用该对象的方法了。对远程服务,客户
机要把请求传递给远程对象代理,它通过对象远程过程调用ORPC和服
务器存根模块与远程服务器连接。
一口气贴了这么多，累死了，写得很乱，看着给点分吧！
