中間件ICE介紹

自從上世紀九十年代以來，計算工業一直在使用像DCOM[3] 和

CORBA[4] 這樣的面向對象中間件平台。在使分布式計算能為應用開發者

所用的程序中，面向對象中間件是十分重要的一步 。開發者第一次擁有了

這樣的可能：不必是一個網絡古魯（guru），就可以建構分布式應用——

中間件平台會照管大部分網絡雜務，比如整編（marshaling）和解編

（unmarshaling）（對資料進行編碼與解碼，以進行傳送）、把邏輯對象位址

映射到實體傳輸端點、根據客戶和伺服器的原生機器架構改變資料的表

示，以及應需自動啟動伺服器。

然而，由于一些原因，無論是DCOM 還是CORBA，都未能成功占領大

部分計算市場：

• DCOM 是Microsoft 的獨家解決方案，在異種網絡中，各種機器會運作多

種作業系統，無法使用DCOM。

• DCOM 不能支援大量對象（數十萬或數百萬），這在很大程度上是它的

分布式垃圾收集機制帶來的開銷造成的。

• 盡管有多家供應商提供CORBA 産品，幾乎不可能找到一家供應商，能

夠為異種網絡中的所有環境提供實作。盡管進行了大量标準化工作，不

同的CORBA 實作之間仍缺乏互操作性，進而不斷地造成各種問題；而

且，由于供應商常常會自行定義擴充，而CORBA 又缺乏針對多線程環

境的規範，對于像C 或C++ 這樣的語言，源碼相容性從未完全實作過。

• DCOM和 CORBA都過于複雜。要熟悉DCOM或CORBA，并進行相應的

設計和程式設計，是一項需要許多個月來掌握的艱難任務（而要達到專家

水準，需要好幾年）

• 在其各自的曆史中，性能問題一直在折磨這兩種平台。DCOM 隻有一種

實作可用，是以不可能購買性能更好的實作。而盡管有多家供應商提供

CORBA 産品，很難找到遵從标準、性能良好的實作——其主要原因是

CORBA 規範自身所帶來的複雜性（在許多情況下，其特性都豐富得超

出了需要）

• 在異種環境中，讓DCOM 和CORBA 共存從來都不是一件容易的事情：

盡管有供應商提供互操作産品，這兩種平台之間的互操作從來都不是無

縫的，而且難以管理，會産生互不相連的技術孤島。

2002 年， Microsoft .NET 平台[11] 取代了DCOM。但盡管.NET 提供了

比DCOM 更強大的分布式計算支援，它仍然是Microsoft 的獨家解決方案，

因而不是異種環境下的選擇。另一方面，CORBA 近年來已停滞不前，許多

供應商離開了市場，給消費者留下了不再受到廣泛支援的平台；剩下的少

數供應商在進一步标準化方面的興趣也已衰退，緻使CORBA 規範中的許

多缺陷未能得到解決，或是在它們被報告多年之後才得到解決。

在DCOM 和CORBA 衰敗的同時，分布式計算社群對SOAP[23] 和web

services[24] 産生了濃厚的興趣。使用無處不在的WWW 基礎設施和HTTP

來開發中間件平台的想法十分迷人——至少在理論上。SOAP 和web

services 曾經允諾要成為Internet 上的分布式計算通用語言。 但盡管引發了

很大的公衆效應，發表了許多論文， web services 卻沒有能兌現其允諾：在

本書撰寫的同時，用web services 架構開發的商業系統非常少。其原因是：

• 無論是在網絡帶寬方面，還是在CPU 開銷方面，SOAP 都會給應用造成

嚴重的性能惡化，以緻于該技術無法适用于許多有苛刻性能要求的系

統。

• 盡管SOAP 提供了"on-the-wire" 規範，要開發現實的應用，那仍是不夠

的，因為該規範提供的抽象層次太低。應用可以把各種SOAP 消息拼湊

在一起，但這樣做極其繁瑣而易錯。

• 缺乏更進階的抽象促使供應商提供各種應用開發平台，使遵從SOAP 的

應用開發自動化。但是，除了協定一級，這些開發平台完全沒有标準

化，不可避免是私有的，是以用一家供應商開發的應用無法與其他供應

商的中間件産品一起使用。

• 關于SOAP 和web services 的架構安全性，有一些嚴重的擔憂[15] 。特别

地，許多專家都表示，他們對該平台缺乏内在的安全性感到擔憂。

• DCOM和 CORBA都過于複雜。要熟悉DCOM或CORBA，并進行相應的

設計和程式設計，是一項需要許多個月來掌握的艱難任務（而要達到專家

水準，需要好幾年）

• 在其各自的曆史中，性能問題一直在折磨這兩種平台。DCOM 隻有一種

實作可用，是以不可能購買性能更好的實作。而盡管有多家供應商提供

CORBA 産品，很難找到遵從标準、性能良好的實作——其主要原因是

CORBA 規範自身所帶來的複雜性（在許多情況下，其特性都豐富得超

出了需要）

• 在異種環境中，讓DCOM 和CORBA 共存從來都不是一件容易的事情：

盡管有供應商提供互操作産品，這兩種平台之間的互操作從來都不是無

縫的，而且難以管理，會産生互不相連的技術孤島。

2002 年， Microsoft .NET 平台[11] 取代了DCOM。但盡管.NET 提供了

比DCOM 更強大的分布式計算支援，它仍然是Microsoft 的獨家解決方案，

因而不是異種環境下的選擇。另一方面，CORBA 近年來已停滞不前，許多

供應商離開了市場，給消費者留下了不再受到廣泛支援的平台；剩下的少

數供應商在進一步标準化方面的興趣也已衰退，緻使CORBA 規範中的許

多缺陷未能得到解決，或是在它們被報告多年之後才得到解決。

在DCOM 和CORBA 衰敗的同時，分布式計算社群對SOAP[23] 和web

services[24] 産生了濃厚的興趣。使用無處不在的WWW 基礎設施和HTTP

來開發中間件平台的想法十分迷人——至少在理論上。SOAP 和web

services 曾經允諾要成為Internet 上的分布式計算通用語言。 但盡管引發了

很大的公衆效應，發表了許多論文， web services 卻沒有能兌現其允諾：在

本書撰寫的同時，用web services 架構開發的商業系統非常少。其原因是：

• 無論是在網絡帶寬方面，還是在CPU 開銷方面，SOAP 都會給應用造成

嚴重的性能惡化，以緻于該技術無法适用于許多有苛刻性能要求的系

統。

• 盡管SOAP 提供了"on-the-wire" 規範，要開發現實的應用，那仍是不夠

的，因為該規範提供的抽象層次太低。應用可以把各種SOAP 消息拼湊

在一起，但這樣做極其繁瑣而易錯。

• 缺乏更進階的抽象促使供應商提供各種應用開發平台，使遵從SOAP 的

應用開發自動化。但是，除了協定一級，這些開發平台完全沒有标準

化，不可避免是私有的，是以用一家供應商開發的應用無法與其他供應

商的中間件産品一起使用。

• 關于SOAP 和web services 的架構安全性，有一些嚴重的擔憂[15] 。特别

地，許多專家都表示，他們對該平台缺乏内在的安全性感到擔憂。

Internet Communications Engine （Ice）

針對這些使人不快的選擇，ZeroC, Inc. 決定開發Internet Communications

Engine，簡稱Ice1。其主要設計目标是：

• 提供适用于異種環境的面向對象中間件平台。

• 提供一組完整的特性，支援廣泛的領域中的實際的分布式應用的開發。

• 避免不必要的複雜性，使平台更易于學習和使用。

• 提供一種在網絡帶寬、記憶體使用和CPU 開銷方面都很高效的實作。

• 提供一種具有内建安全性的實作，使它适用于不安全的公共網絡。

更簡單地說， Ice 的設計目标可陳述為：“讓我們建構與CORBA 一樣強

大的中間件平台，而又不去犯CORBA 所犯下的任何錯誤”