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