首先聲明,我們既不想引起一場"CORBA vs Ice"的爭論，也不想懷疑CORBA。相反，我們認爲CORBA在它的時代是一個很大的成就，而且，Ice也明顯借用了CORBA的很多思想。
我們決定寫這篇比較文章是因爲我們期望更多的人能正確地詢問我們爲何他們要用Ice代替CORBA。對這個問題，我們通常的回答是：爲什麼不先自己試試使用 Ice呢？我們敢肯定，一旦你使用了Ice有一段時間，你就永遠不會再想用回CORBA。請相信我們，很容易會喜歡上Ice，因爲它優雅、簡單，它的結構一致性，而且最後一點：至少它沒有大量的特性和工具。
對於沒有時間去試驗Ice來了解它的人，這裏有一些原因讓我們相信Ice優於CORBA：
1、Completeness(完備性)
當我們說到完備性時，我們的意思是實際產品的完備性，而不是從來未被實現的標準的完備性。我們相信Ice比市場上任何單個CORBA更完備。你可以自己做一個檢查：市場上有哪個CORBA產品提供了跟Ice可比較的特性？
2、Performance(性能)
由於具有CORBA所沒有的結構優點，Ice具有突出的性能。Ice高效的協議、請求批量化、高效的事件分發都意味着Ice比CORBA ORB運行得更快，同時消耗更少的線路帶寬。
3、No "Design by Committee"(非“委員會設計”)
Ice由一羣專業的資深專家所設計。Ice沒有設計成適合所有人的“萬金油”。而CORBA則充斥着被具有特權的制定者加進到標準裏的衆多不切實際的特性，卻又沒有真正考慮到這些特性是否會被真正地實現。
通常，爲了就CORBA標準達成一致的唯一方法就是將之前大量實現的特性放在一起，生硬地塞進標準裏。這導致了標準越來越大，也越來越複雜，超出了實際的需要。這也意味着平臺更大更慢，也因爲複雜的API導致了難以使用。Ice提供的API集小得多，也更高效，比CORBA的API易於學習使用，並且功能並不少。
4、Slice
Slice，Ice的規範定義語言，比CORBA IDL更小、更簡潔、更強大。Slice具有更少的語言結構，但卻更靈活。例如，一個內建的字典類型提供直接快速訪問數據結構，異常的繼承允許更清晰地影射到支持異常處理的語言。同時，Slice拋棄了CORBA IDL不需要的複雜性，例如屬性，inout參數，上下文和傳值對象(Objects-by-Value)的複雜性。
5、Language Mappings(語言影射)
Ice支持到C++、Java、Python、PHP、C#和Visual Basic的語言影射。我們知道任何一個CORBA實現提供商都沒有提供那麼多的語言影射選擇。
實際上大多數的CORBA提供商只提供C++和Java的影射，如果你想使用其它語言影射，你就要切換到不同的提供商的產品或使用沒有實驗支持的CORBA實現。
6、Persistence(持久性)
Slice並不單單是一個接口定義語言。它也可以用來描述Ice對象進行持久的屬性，使得很容易寫出支持對象持久的服務器端程序。
7、Metadata(元數據)
Slice支持可擴展的元數據設施，它允許Slice爲實現應用程序相關的某些目的而使用元數據的標記。例如元數據可以用於定製不同於標準Java影射方式的影射來滿足某些特定程序的要求。
8、No any Type(沒有any數據類型)
Ice 沒有CORBA裏Any類型的等價數據類型。這對於CORBA用戶來說可能感到很驚訝，因爲Any數據類型在CORBA標準裏被廣泛地使用。但是，Any 數據類型是多餘的：程序語言象Java和C++並沒有Any數據類型，而且Any數據類型對分佈式系統來說也不是屬於一個良好的設計。Any數據類型通常用在兩種情況下：一種是需要在系統的中介部分對接收到的數據直接進行傳遞，而不用關心數據的真實類型，例如CORBA的Event服務，另一種是用來作爲 union(聯合結構體)的一個等價物。
Ice可以通過發送和接收"blobs"的請求來滿足第一種情況，Slice的類繼承可以滿足第二種情況。任何一種情況，Ice的程序都更高效，更加具有類型安全，更加容易設計和實現，而不會遇到使用CORBA Any數據類型時所具有的複雜性。
9、Ice Core(Ice的核心)
雖着時間的演化，CORBA的核心變得異常的複雜。一個初級的例子要在POA(CORBA的對象適配器)裏面正確使用都需要很專業的知識，即使你只想支持一小部分的技術特性。Ice的對象適配器，在另一方面來說，更加簡單、直觀、也跟POA一樣的功能強大：定義良好的API使得比POA開發一個可擴展的程序項目需要更少的工作。
10、Ice Protocol(Ice協議)
IIOP是CORBA的弱點之一，具有太多的設計缺陷。例如，沒有缺少請求的封裝來防止消息的分發。低效的對齊規則導致了多餘的數據拷貝。數據的編碼規則複雜，卻沒有帶來相應的性能的提高，對象引用的編碼異常複雜，妨礙了有效的的編碼和在內存共享的執行。代碼集的協商是在標準下達成，會遭遇到很多衝突。所有這些複雜性意味着IIOP很難實現，帶來了互操作性和性能上的問題。Ice的協議是簡單並且更加有效，它提供了一些IIOP沒有提供的特性，例如數據壓縮和批請求批量化。
11、Security(安全性)
安全性是CORBA的最大的一個難題。OMG已經通過了多個標準，但很多都沒有被廣泛地實現，CORBA的客戶依然沒有一個可工作的安全的ORBs。當設計 Ice時，和CORBA相比，安全性被認爲是基本的特性。這就是Ice提供一個真正能運作的SSL實現的安全的防火牆的原因。
12、C++ Mapping(C++映射)
用 C++來使用CORBA非常困難。即使你是很有經驗的C++開發者。CORBA的C++映射在內存管理和異常安全方面有很多的陷阱和缺陷。相較之下，Ice的C++映射非常簡單和直觀。它不會有因爲錯誤而導致內存的泄漏。要記住的映射規則的數目比CORBA的C++映射少得多，而且Ice的C++ 映射是基於工業標準的STL。
14、Scalability(可伸縮性)
當你是一個專家時，CORBA是一種可伸縮性很好的技術。但採用Ice，任何人都可以寫出高可伸縮性的應用。例如，Ice實現了一個持久化的逐出器，你可以使用它來很容易地處理上百萬的對象，你所做的僅僅是在 Slice的定義裏指定對象的數據，剩下的工作Ice一手包辦：Ice運行庫使用高速的數據庫來自動加載和保存對象。
15、Versioning(版本化)
CORBA沒有任何機制來支持對象狀態的版本化。Freeze是Ice的持久服務，它允許持久數據在Slice的定義中改變時，很容易地進行數據庫的移植。
16、Software Updates(軟件更新)
IcePatch是一個允許你更行客戶端軟件的工具。它使用壓縮來提高數據的傳輸，並使用校驗值來保證一致性。CORBA完全沒有提供一個在分佈式環境來進行軟件更新的機制。
17、Typed Event Service(類型化的事件服務)
CORBA有一個標準來提供類型化的事件服務，但很少甚至沒有被實現。類型化的事件服務也有很多已知的問題，事實上它在真正環境的部署是不可用的。Ice從一開始就提供了類型化事件的服務。IceStorm是一個高效、類型化事件服務的實現，它支持事件聯盟。
18、Facets(多接口)
CORBA支持繼承，DCOM支持聚合。在過去，有很多關於那一種是更好的方法的爭論。Ice以接口繼承加上以多接口形式的聚合來同時支持這兩種方式。Facets允許你在運行的時候用動態的聚合來擴展類型來替代靜態的繼承。
19、Asynchronous Messages(異步消息)
CORBA 支持異步消息調用(AMI)，但很少CORBA產品實現了AMI。Ice一開始就以簡單和有效的方式支持AMI。Ice也支持異步消息分發(AMD)，這是CORBA裏完全沒有的東西。AMD等價於客戶端的AMI，不過AMD是用在服務器端的。使用AMI，你可以發送了一個請求，然後在以後的一個事件收到服務器的結果時調用一個回調函數來處理返回的結果。而使用AMD，你可以將分發線程歸還給Ice，並在結果已經準備好發送到客戶端時再次調用分發線程。 AMI和AMD都能被連接起來，這允許你只消耗很少的資源就能構建高效的路由程序。
AMI和AMD對客戶端和服務器端來說都是透明的。也就是，一個服務器程序不知道一個請求是否通過AMI調用發出的還是同步地調用發出的，客戶端程序也不知道一個操作的調用在服務器端是通過AMD分發處理的還是同步地處理的。當需要使用AMI和AMD時，不用修改Slice。
結束語：
我們希望上面的解釋能另你激發你對Ice的興趣。如果你有任何的問題或解釋，我們會邀請你加入我們的郵件列表。我們的目標是不斷地改進Ice，因此你的反饋對我們來說是很有價值的。
gigaboy翻譯完成於2005/7/4 3:02