目前的技術存在的問題？
儘管dcom和iiop都是固定的協議，業界還沒有完全轉向其中任何乙個協議。沒有融合的部分原因是文化的問題所致。而且在當一些組織試圖標準化乙個或另乙個協議的時候，兩個協議的技術適用性就被提出質疑。傳統上認為dcom和corba都是合理伺服器到伺服器端的通訊協議。但是，二者對客戶到伺服器端的通訊都存在明顯的弱點，尤其是客戶機被散布在internet上的時候。
dcom 和 corba/iiop都是依賴於單個廠商的解決方案來最大優勢地使用協議。儘管兩個協議都在各種平台和產品上被實現了，但現實是選定的發布需要採用單一廠商的實現。在dcom的情況下，這意味著每個機器要執行在windows nt。（儘管dcom已經被轉移到其它平台，但它只在windows?上獲得了廣泛的延伸）。在corba情況下，這意味著每個機器要執行同樣的orb產品。的確讓兩個corba產品用iiop相互呼叫是有可能的，但是許多高階的服務（如安全和事務）此時通常不是可互動的。而且，任何專門廠商為同樣的機器的通訊所作的優化很難起作用，除非所有的應用被建立在同乙個orb產品上。
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問題。
SOAP協議初級指南（五）
soap體的核心 soap的xml特性是為把資料型別的例項序列化成xml的編碼模式。為了達到這個目的，soap不要求使用傳統的rpc風格的 而是乙個soap方法呼叫包含至少兩個資料型別 請求和響應。考慮這下面個com idl uuid deadf00d bead bead bead baabaaba...
SOAP協議初級指南（4）
xml 作為乙個更好的網路資料表達方式 ndr http是乙個相當有用的rpc協議，它提供了iiop或dcom在組幀 連線管理以及序列化物件應用等方面大部分功能的支援。而且urls與iors和objrefs在功能上令人驚嘆的接近 http所缺少的是用單一的標準格式來表達乙個rpc呼叫中的引數。這則正...
SOAP協議初級指南（二）
目前的技術存在的問題？儘管dcom和iiop都是固定的協議，業界還沒有完全轉向其中任何乙個協議。沒有融合的部分原因是文化的問題所致。而且在當一些組織試圖標準化乙個或另乙個協議的時候，兩個協議的技術適用性就被提出質疑。傳統上認為dcom和corba都是合理伺服器到伺服器端的通訊協議。但是，二者對客戶到...