DCOM与CORBA分别在哪种情况下适用？(200分)

我不明白你所说的静态是指什么，如果是静态绑定(static bind)，
delphi是支持的，但delphi4/5确实没带idl2pas，不能直接将.idl文件翻译成
delphi的对象定义，但通过typelib editor我们完全可以手式将corba idl翻
译成delphi所能接受的形式：object pascal语法或ms idl语法，从而做到这
一点。如果是用delphi4生成的corba server则会自动生成必要的unit，如果
你需要在非delphi中使用该server那么写一个idl给它就是了。
详情请你看一下delphi4联机帮助中write destribute application中
write corba application部分的Writing CORBA clients一节。

关心linux平台上的开发者不妨看看这一段：
构件编程
很长时间以来, UNIX 有一个诱人的理论, 那就是设计小的工具, 每一个只作好一
件事, 而将他们组合起来, 只使用管道和简单的 shell 角本, 就可以完成复杂的工
作. 当数据 对象是一般文本和作过滤操作时, 这种机制工作得极好. 但是, 这种基于
命令行的理论 却不能更好地适应当前的多媒体对象.
因此, GNOME 最好能够建立一种可以架构, 可以使软件重用和构件联结, 相互作
用, 例如, 将小的专业工具联结起来完成复杂的工作. 有了适当的基础框架, GNOME
应用就可以重温 UNIX 那种简单而专业的工具的理论了.
为了提供这类功能, 一个 RPC(远程过程调用)系统是需要的. 所以, 我们决定使
用 CORBA (the Common Object Request Broker Architecture), 它来自 the Object
Management Group (OMG). CORBA 可以人为是一个面向对象的 RPC 系统, 它正巧有着
各种语言的标准实现.
CORBA 向我们展开了一系列的应用. 构件编程允许我们将程序和共享库组织 成为
一个程序服务器, 以实现一个特定的(应用)界面.
举例来说, GNOME 邮件程序, Balsa, 实现了 GNOME::MailMessage 界面, 它(界面)
允许任何 CORBA-aware(能识别CORBA)的应用远程编写和定制一封邮件, 然后发送它.
这样就可以使用任何实现了 GNOME::MailMessage 界面的程序替代(专门的)邮件程序.
只要安装了 GNOME 桌面, 进程只需实现 GNOME::MailMessage 界面(调用)即可. 这意味
着, 例如, 我可以继续使用 GNUS 去读我的邮件, 可以使 GNUS 完全融合到我的桌面
中. 同时(这种功能)也提供给 其他的 GNOME 构件: 地址簿, 文件管理器, 终端仿真
器, 帮助浏览者, 办公应用等等.
除了提供 GNOME 基本界面外, 应用可以可以实现他们自己的特定界面. 这是通过
COBRA 的界面继承性做到的. 一个特定界面可以衍生自较普通的界面. 例如, GNUS 可
以实现 GNOME::MailMessage 界面, 然后扩展为 GNOME::GnusMailMessage, 带有一些 GNUS
自己的特色. 设想一下, 这个界面允许用户在用 Lisp 定制, 而其他一些邮递者则不
能. 另外一个例子是, GNOME::MozillaMailMessage 界面允许用户配置 Mozilla 邮件程
序中的 HTML 实现.
COBRA 不仅仅只是完成这些工作, 它还可以作为内部进程之间的通讯引擎. 无需
发明一种新的内部程序通讯系统, 一个 COBRA 界面就可以做到.
将一种文档嵌入到其他文档的方式随着微软的对象联结与嵌入体系结构已经越来
越普及. 一套 GNOME 文档嵌入模型正在被设计(Baboon模型), 这个模型中所有 的内
部进程通讯是使用 COBRA 界面描述.
起初, 我们为 COBRA 呈现出的可能性感到兴奋, 但是我们很快意识到在 GNOME
桌面中使用 COBRA 远比设想的困难.
我们尝试使用施乐的 ILU COBRA . 那时(它的)许可证还不允许修改代码和重新发
布. 对于自由软件群体来说, 这可是一件重要的事, 所以我们必须寻找替代产品. 施
乐因此改变了许可证策略.
在试用了几种不同的免费 COBRA的实现后, 我们选定了 MICO, 因为它是实现
COBRA 特性最全的一个. MICO 设计为 COBRA 的一个教学工具, (因此)其清晰的编码
是它的主要特点.
很不幸, 我们很快发现 MICO 不是一个产品质量级, 适合于 GNOME 的工具. 其中
一点是, 我们发现, 相当杂乱的 C++ 模板使用(同时存在于 MICO 和生成的接口) 浪
费了大量的资源. 编译一点 GNOME , 即使使用了最简单的 COBRA, 竟然也需要 48MB
内存, 这减慢了我们的开发速度. 另外一个问题是 MICO 只支持 C++ 语言. 虽然在开
始时期曾经尝试提供 C 语言帮定, 最终并未完成和很好的维护.
为了解决这些问题, i2it 的 Dick Porter 和 Red Hat 实验室的 Elliot Lee 写
了一个称作 ORBit 的基于 C 的, 瘦型快速的 COBRA 2.2 实现版本. 一旦 ORBit 开
始稳定, 贯穿于 GNOME 的 COBRA 的运用便开始了, 不过已经 差不多耽误了 8 个月.
正是有了一个高效的, 产品质量级别, 由我们控制的 COBRA 的实现版本, 我们能够保
证对应用开发者来说, COBRA-enable(COBRA激活的)内部进程通讯是一项有价值的服
务, 而不只是一个杀手或者 "黔之驴" .

呵呵，怎么用type lib editor把idl to pas?我没用出来过，望品雪兄指教

建议去看Delphi4编程技术内幕(unleashed)，中文版第六部分第25章。
另外上边提到那个文档也有所帮助。
值得一提的是，如果用delphi做corba，还是用动态绑定来得方便。
sorry，没法直接给出例子，俺主要用cbuilder。

哈哈，用不着这么麻烦了，inprise发布visibroker for delphi5了，内含
idl2pas。升级吧。

我对dcom的看法：
（1）无论是以前还是以后，dcom都不会是微软的大力推广之技术，从com(ole)->dcom->mts->COM+的技术进军路线可以看出，dcom是com和mts/com+之间的过渡，它是com的无缝扩展，同时也是mts/com+的底层技术。
（2）从应用角度来看，com在单机上取得了很大成功，而com+(可以认为是mts 3.0)着重于企业环境。用dcom构造client/server应用缺乏太多的工具支持，仅仅一个dcomcnfg和一些扩展的API函数足以说明微软的重点不在dcom。
（3）在微软的技术体系中，用dcom技术建立起来的应用在Intranet环境中还可以，但用到Internet上还很有问题。其发展的方向是SOAP协议，利用XML把远程调用传递到Internet上，进一步的情况我就不清楚了。

都是高手! 本问题让我受益匪浅阿!

dcom 是以 windows 作为大本营
corbaq 主要以 unix 作为大本营。

收益非浅！！
多谢各位大虾！
不过，我个人喜欢DCOM
CORBA 体系结构不是很明白的说

收益非浅!!!!!!

初学者,我使用发现Corba比DCom易于使用
我用BCB4和VisiBroker for C++ 3.3.2

VisiBroker for Delphi 3.3在使用ACCESS时好象有个BUG，有谁用过

不要担心，CORBA 和DCOM的标准和用法最终会统一，你可以看看WIN2000的COM+已向CORBA靠拢。

发言者万岁！！！！！！！！！
衷心感谢这么多人的精辟论解，吾不孤也！！！

DCOM
是一种最直接的连接方式，且不用运行期软件支持。
我喜欢DCOM。

可惜corba的许可协议太贵了。

接受答案了.