免费网站提交入口,邯郸app开发,自己做鞋子网站,78建筑人才网目前的技术存在的问题#xff1f; 尽管DCOM和IIOP都是固定的协议#xff0c;业界还没有完全转向其中任何一个协议。没有融合的部分原因是文化的问题所致。而且在当一些组织试图标准化一个或另一个协议的时候#xff0c;两个协议的技术适用性就被提出质疑。传统上认为DC… 目前的技术存在的问题 尽管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问题。转载于:https://www.cnblogs.com/alaricblog/p/3278259.html
