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