?
| 目前的技術存在的問題？ 盡管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問題。 |
)
