ICE官方文檔中2.2【The Ice Architecture】章節翻譯之二 收藏
2.2.3 Slice(Specification Language for ICE)
就像前面提到的，每個ice對象都有一個接口，接口中包括很多的操作；接口、操作、數據類型要想在客戶端和服務端進行交互，就需要用Slice語言來進行定義；Slice允許用某種方式定義客戶端和服務端交互的契約，該契約是與編程語言無關的，比如C++、Java、C#；Slice的定義被編譯器編譯成特定編程語言對應的API，也即：針對定義好的接口、數據類型的API內容都是由自動生成的代碼組成。
2.2.4 Language Mappings
控制每個Slice構造器如何轉換成對應語言的規則被稱為語言映射【Language Mappings】；比如，對于C++映射（詳見Chapter 6），Slice中的序列【Sequence】以STL vector的形式出現；而對于Java映射（詳見Chapter 10），Slice中的序列以Java array的形式出現；為了確定對于特定Slice構造的API看起來到底像什么，你只需要了解Slice定義、以及Slice語言映射規則即可；語言映射的規則非常地簡單、有規律性，以至于你根本不需要去閱讀自動生成的代碼就可以知道怎樣去使用這些生成的API。
當然，你完全可以去閱讀自動生成的代碼；但是，一般來說【as a rule】，自動生成的代碼還不是非常適合于人的閱讀的；我們推薦你熟練掌握語言映射規則，這樣你就可以最大限度的忽略自動生成的代碼，你只需要關注那些你很感興趣的一些特定細節即可。
目前，Ice對C++、Java、C#、Python提供語言映射；對于客戶端，目前還支持PHP、Ruby。
2.2.5 Clients and Servers Structure
Ice客戶端、服務端都有如下的內部邏輯結構：
從上圖可以看出，兩者都由應用代碼、lib代碼、從Slice定義自動生成的代碼這三者一起混合組合：
Ice Core包含客戶端、服務端為支持遠程通信而需要的運行時；這些代碼關注的是網絡、線程、字節排序、以及其他一些和網絡相關的問題，這樣就可以讓應用代碼遠離這些問題；Ice Core以很多lib包的形式提供給客戶端、服務端使用。
Ice Core中的通用部分可以通過Ice API進行訪問；你可以使用這些API來處理一些零星的瑣事，比如初始化、關閉Ice運行時；Ice API對于客戶端、服務端來說都是一樣的，只是服務端比客戶端使用API更多。
Proxy代碼是從Slice定義中自動生成的，所以他主要是和你在Slice中定義好的對象、數據類型有關；代理代碼主要有兩個主要功能：
對于客戶端他提供向下調用【down-call】的接口；在生成的代理API中調用一個功能最終會以發送一個RPC消息請求給服務端而結束，服務端會在對應的目標對象上調用一個對應的功能；
他提供marshaling、unmarshaling代碼
Marshaling是指序列化一個復雜對象的過程；比如要想傳輸一個序列，Marshaling代碼會將數據轉換成一種可傳輸的標準形式；
Unmarshaling是Marshaling的逆過程；也即，當數據通過網絡到達時需要反序列化，重新構造一個本地的數據類型展現形式，以便適合于編程語言的使用；
Skeleton代碼也是從Slice定義中自動生成的，所以他也是和Slice中定義的對象和數據類型有關；存根代碼就相當于服務端的代理代碼；他提供一個上行調用【up-call】接口，該接口允許Ice運行時將線程控制權轉向應用代碼，存根也提供marshaling、unmarshaling代碼，這樣服務端就能接收由客戶端發送過來的參數，同時返回參數或者異常給客戶端。
Object Adapter是服務端相關ICE API中的一部分，只有服務端才會使用對象適配器，一個對象適配器主要有以下一些功能：
對象適配器將客戶端發起的請求映射到具體對象的方法上面；換句話說，對象適配器根據對象標識來跟蹤到底是哪個伺服器【servant】。
對象適配器可以與一個或多個傳輸協議端點關聯；如果超過一個傳輸協議端點與一個對象適配器關聯，伺服器可以通過多種傳輸協議到達；比如，一個適配器同時關聯了TCP/IP和UDP端點，此時適配器就可以提供可選的Qos和性能特性了；
對象適配器負責創建能夠被傳輸到客戶端的代理；對象適配器知道他的每一個對象的類型、標識、傳輸協議詳情，當服務端應用代碼請求創建一個代理時對象適配器只需要將這些信息嵌入即可；
注意到，就關注的過程視圖中，過程中只涉及到兩個點：客戶端、服務端；為了支持分布式通信，所有的運行時被Ice lib和從Slice定義中生成的代碼提供。
2.2.6 The Ice Protocol
ICE提供的是RPC協議，他使用TCP/IP、或者UDP作為底層傳輸協議；除此之外，Ice還允許使用SSL來作為傳輸協議，這樣客戶端和服務端之間的所有通信都是被加密的。
Ice協議定義如下一些內容：
很多的消息類型，比如請求和回復消息類型；
一個協議狀態機，能夠確定不同消息類型在客戶端和服務端之間交換信息時以何種順序進行；以及針對TCP/IP協議的連接建立以及釋放；
編碼規則，他決定了每種類型的數據在傳輸過程中的表現形式；
對每條信息的消息頭，包括詳細信息有：消息類型、消息尺寸、以及協議和編碼版本；
Ice也支持傳輸過程中的數據壓縮功能：通過設置一個可配置的參數即可，這樣你就能壓縮網絡流量從而節省帶寬；如果你的應用程序在客戶端和服務端之間有大量數據需要交互，那這是非常有用的。
Ice協議很適合于構建高效的事件轉發機制，因為他允許在不知道消息體內任何詳細信息的情況下對消息進行轉發；這就意味著消息的轉發不需要任何的消息反序列化和重新序列化【unmarshaling and remarshaling】，他們轉發一條消息，只是簡單的把他作為一個不透明的字節緩沖器而已。
Ice協議也支持雙向操作：如果服務端想要發送一條消息給客戶端提供的一個回調對象，就可以直接通過由客戶端調用請求時創建的那個原始連接進行回調；當客戶端位于防火墻之后，而防火墻只允許友好【outgoing】連接、而不允許外來【incoming】連接訪問，此時這個特性就顯得異常重要了。
2.4 Architectural Benefits of Ice
Ice的架構對應用開發者來說提供了很多的好處：
面向對象語義
Ice全面維持【preserve】面向對象的樣式【paradigm】“Across the wire”；所有的操作調用都使用后期綁定【late binding】，這樣所有操作的實現都是依賴于實際運行時（不是靜態的【not static】）的對象類型；
支持同步和異步消息
Ice同時提供同步和異步的操作調用和操作分發，通過IceStorm還可以實現發布-訂閱【publish-subscribe】消息；這就允許你去根據應用需要選擇通信模型，而不是一定得讓應用程序去適應某個單獨的模型；
支持多個接口
通過facet，對象能夠提供多個不相關的接口，同時這些接口卻保持著同一個對象標識；特別地，隨著應用的不斷演變，卻需要去保持對老的、已經部署過的客戶端保持兼容時，對此Ice就提供了非常好的靈活性；
機器無關性
通過底層的機器架構，客戶端和服務端是完全隔離的【shield】；類似字節排序和填充這些問題對于應用代碼而言都是隱藏的；
語言無關性
客戶端和服務端能夠獨立的用不同編程語言開發；客戶端和服務端通過使用Slice定義來確定雙方都需要遵循的契約，而這也是雙方唯一需要達成一致的；
實現無關性
客戶端對于服務端如何實現他們的對象是不知道的；這就意味著客戶端被部署之后服務端的實現仍然可以被改變；比如，可以使用不同的持久機制，甚至使用不同的編程語言；
操作系統無關性
Ice API是非常輕便的，所以相同的源代碼可以在Windows和Unix下面編譯和運行；
線程支持
Ice運行時是完全基于線程的，Ice API也是線程安全的；對需要開發基于線程的、高性能的客戶端和服務端應用程序的開發者而言是不需要什么努力【no effort】的；
傳輸協議無關性
Ice目前支持TCP/IP和UDP作為傳輸協議，可以通過配置參數選擇想要的傳輸協議；客戶端和服務端代碼都無需關注底層的傳輸協議；
定位和服務器透明性
Ice運行時負責定位和查找對象、以及管理底層傳輸協議機制，比如打開和關閉連接；客戶端和服務端的交互就像是沒有連接一樣；通過IceGrid，你能夠讓服務端按需【on demand】啟動，也即當客戶端調用一個操作時服務端若不在運行狀態，此時服務器自動開始運行；服務器還能在不破壞被客戶端持有的代理情況下遷移到不同的物理地址上，此時客戶端是完全不知道對象的實現是如何通過服務端進程分發的；
安全性
客戶端和服務端能夠在具有強大加密功能的SSL協議下進行通信，這樣應用程序就能夠在不安全的公共網絡上進行安全的通信了；通過Glacier2，你能夠穿越防火墻，實現對請求的安全轉發，而且還對回調提供全面支持；
內置持久化
有了Freeze，創建持久化對象實現變得毫無價值；Ice通過內置高性能的Berkeley DB數據庫來提供支持；
源碼可用性
Ice的源代碼是可用的；雖然對于使用該平臺時看源碼不是必要的，但是他讓你可以知道事情到底是如何完成的；
終上所述，Ice對于分布式計算提供了比我們熟知的其他平臺更加完善的、更具有生產力的【state-of-the art】開發和部署環境。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/sfdev/archive/2008/12/07/3468777.aspx