| 目前的技术存在的问题？ 尽管DCOM和IIOP都是固定的协议，业界还没有完全转向其中任何一个协议。没有融合的部分原因是文化的问题所致。而且在当一些组织试图标准化一个或另一个协议的时候，两个协议的技术适用性就被提出质疑。传统上认为DCOM和CORBA都是合理服务器到服务器端的通信协议。但是，二者对客户到服务器端的通信都存在明显的弱点，尤其是客户机被散布在Internet上的时候。 DCOM 和 CORBA/IIOP都是依赖于单个厂商的解决方案来最大优势地使用协议。尽管两个协议都在各种平台和产品上被实现了，但现实是选定的发布需要采用单一厂商的实现。在DCOM的情况下，这意味着每个机器要运行在Windows NT。（尽管DCOM已经被转移到其它平台，但它只在Windows?上获得了广泛的延伸）。在CORBA情况下，这意味着每个机器要运行同样的ORB产品。的确让两个CORBA产品用IIOP相互调用是有可能的，但是许多高级的服务（如安全和事务）此时通常不是可交互的。而且，任何专门厂商为同样的机器的通信所作的优化很难起作用，除非所有的应用被建立在同一个ORB产品上。 DCOM 和CORBA/IIOP都依赖于周密管理的环境。两个任意的计算机使得DCOM或IIOP 在环境之外被成功调用（calls out of the box）的几率是很低的。特别是在考虑安全性的时候尤其是这样。尽管写一个能成功地运用DCOM或IIOP的紧缩包（shrink-wrap）应用是可能的，但这样做要比基于socket的应用要更多地关注细节。这对于乏味但必需的配置和安装管理任务特别适用。 DCOM 和 CORBA/IIOP都依赖于相当高技术的运行环境。尽管进程内的COM似乎特别简单，但COM/DCOM远程处理程序绝对不只是几天就解决的事情。IIOP 是一个比DCOM更容易实现的协议，但两个协议都有相当多的深奥的规则来处理数据排列、类型信息和位操作。这使得一般的程序员在没有领会ORB产品或OLE32.DLL的情况下去构造一个简单的CORBA或DCOM调用也变得很困难。 也许对DCOM和CORBA/IIOP来说，最令人难以忍受的一点是它们不能在Internet 上发挥作用。对DCOM来说，一般用户的iMac 或廉价的运行Windows 95的PC 兼容机要想使用你的服务器执行基于领域认证几乎是不可能的。更糟的是，如果防火墙或代理服务器分隔开了客户和服务器的机器，任何IIOP或DCOM包要通过的可能性是很低的，主要是由于大多数Internet连接技术对HTTP协议的偏爱所致。尽管一些厂商如Microsoft， Iona和Visigenic都已经建立了通道技术，但这些产品很容易对配置错误敏感而且它们是不可交互的。 在一个服务器群落中这些问题并不能影响DCOM或IIOP的使用。因为在服务器群落中主机的数量很少（一般是成百上千，而不是成千上万），这就抵消了DCOM基于ping的生命周期管理的成本。在服务器群落中，所有主机被一个公共管理域管理的机率很大，使得统一的配置变得可能。相对少量的机器也能保持商业ORB产品可控制使用的成本，因为只需要更少量的ORB许可权。如果只有IIOP在服务器群落中被使用，就只需要少量的ORB许可权。最后，在服务器群落中所有主机有直接的IP连接也是可能的，这就消除了与防火墙相关的DCOM和 IIOP问题。 |
)
