ICE官方文檔中2.2【The Ice Architecture】章節翻譯之一 收藏
每次去參加各類大會或者培訓之后，就下定決心說要好好學習英語，不過這個目標還是一次次的沒有實現；當然工作忙、時間緊、沒語境……都成了有力的接口；但是這次偶想到一個退而求其次的方法，雖然沒有練習聽力的語境，但是我們可以先把英語翻譯能力練習起來，平時看英文doc的時間也不少，自認為看大多數文檔都不存在啥障礙，但此次的要求是將他們翻譯出來，呵呵，別小看哦，能看懂和能翻譯出來可完全是兩個level！不信你也可以嘗試一把，呵呵；此次，正好遇到自己在看關于ICE相關的一些文檔，網上search了也沒有比較詳細點的中文資料，于是決定將其官方文檔中的架構部分都翻譯出來，歡迎大家拋磚！
2.2.1 Introduction
ICE是一個面向對象的中間件平臺。從根本上講，這就意味著ICE對于構建面向對象的CS結構應用程序提供Tool、Api、以及各類lib支持。ICE應用程序非常適合于在各式各樣的環境下使用：客戶端和服務端可以分別用不同的編程語言來實現，而且可以運行在不同的操作系統和服務器架構中，相互間的通信也可以使用各種網絡技術。
2.2.2 Terminology
每一種技術在其不斷演變、成熟過程中都會創造出一些特有的詞匯，當然ICE也不例外，但是，被ICE使用的特有詞匯數量卻是非常少的。和發明新的術語相比，我們會更傾向于使用已經存在的術語；如果你在過去曾經使用過其他的中間件技術，比如CORBA，那么你將會對接下來的內容非常熟悉；
Clients and Servers
對于一個應用程序，client、server分別對應于哪個部分并沒有一致的規定；一般來說，他們是指在一次請求中扮演不同角色的特定應用部分：
Client可以理解為主動實體，他們負責向Server發起某個請求服務；
Server可以理解為被動實體，他們負責對Client請求進行響應并提供服務；
通常，服務端并不是“純粹的”服務端【從來不發起請求，只負責對請求進行響應】；相反，服務端經常扮演服務端和客戶端的雙重角色，而他們扮演客戶端的角色是為了滿足原客戶端的請求。
類似的，客戶端也不是“純粹的”客戶端【只負責發起請求，而不對請求進行響應】；相反，客戶端也經常扮演雙重角色；比如，一個客戶端可能向服務端發起了一個耗時很長的請求，作為請求的一部分，該客戶端對服務端提供了一個回調【callback】對象，讓服務端在操作執行完畢之后能夠通知到客戶端；在這個實例中，客戶端在請求發起時扮演了客戶端的角色，而在服務端執行完畢之后通知客戶端時就扮演了服務端的角色。
類似上面的角色互換在很多系統中是非常普遍的，一般來說，CS類型的應用系統更多的被準確描述為點對點【Peer-to-Peer】系統。
ICE Objects
一個ICE對象是一個概念性的、抽象的實體。一般來說一個ICE對象具有如下一些特征：
它是一個本地的、或者是能對客戶端請求進行響應的遠程地址空間的一個實體。
一個single ice對象能夠在一臺服務器上被實例化、或者在多臺服務器上被冗余的實例化；雖然一個對象有多個同時存在的實例，但他仍然是一個single ice對象。
每個ice對象有一個或者多個接口【interface】；接口就是一組操作【operation】組成的集合；客戶端通過調用接口來發起請求。
一個操作有零個或者多個參數，返回值也一樣；參數和返回值都有一個特定的類型【type】；對于參數又分成兩類：輸入型參數【in-parameters】被客戶端初始化并傳給服務端；輸出型參數【out-parameters】被服務端初始化并傳給客戶端；返回值只不過是一種特殊的輸出型參數。
一個ice對象有一個能夠區別于其他對象的主接口；除此之外，一個ice對象還提供零個或者多個可選接口，這些可選接口被稱為facets；客戶端能夠選擇一個對象的facets中的其中一個來一起工作。
每個ice對象都有一個唯一的對象標識【object identity】；一個對象的標識就是讓他能夠區別于其他對象的標識值；ice對象模型假設對象標識都是全球唯一的，也就是說，在一個ice通信域里面，沒有兩個對象擁有相同的對象標識。實際上，對象標識并不一定要求使用類似UUID一樣的全球唯一標識，只需要在你自己的ice通信域里面保證任意的兩個對象標識不沖突就可以了。
Proxies
客戶端若要和一個ice對象進行通信，客戶端必須持有一個ice對象的代理【Proxy】；代理對于客戶端地址空間來說就像是本地對象一樣，對于客戶端而言，代理就代表著ice對象（可能是遠程對象），對于一個ice對象來說，代理就是一個本地大使；ice中的代理和CORBA中的引用【Reference】是等價的，ice使用代理替換引用主要是為了避免混淆，因為引用已經在各種不同的編程語言中有了太多其他的意思。當客戶端對代理觸發一個操作時，ice的運行時會做如下的一些事情：
找到需要通信的ice對象；
若ice對象所在的服務器不在運行狀態時，嘗試激活他；
在服務器上激活ice對象；
傳輸輸入型參數給ice對象；
等待服務端操作完成；
返回輸出型參數、返回值給客戶端；當遇到問題時會拋出一個異常；
為了完成如上所有步驟的操作，代理封裝了所有必要的信息；特別地，一個代理包括的信息有：
地址信息：允許客戶端運行時能夠找到正確的服務器；
對象標識：能明確找到服務器上的具體某個特定對象；
可選的facet標識：確定代理需要關聯的某個特定facet；
Stringified Proxies
代理內部包括的信息能夠被表示成一個字符串；比如，字符串
SimplePrinter:default -p 10000
就是一個代理的最具可讀性的表示；ice運行時對此提供了api調用的支持，他允許把一個代理轉換成他的字符串化的形式，相反也是可以的。這是非常有用的，比如可以將代理保存在數據庫或者是文本文件中。
假設客戶端知道了一個ice對象的對象標識、以及他的地址信息，那他就能靠提供的這些信息生成一個代理，就像無中生有一樣；換句話說，代理的內部沒有任何不透明的信息；一個客戶端需要知道的僅僅是一個對象標識、地址信息、以及對象的類型（當需要觸發某個操作時）。
Direct Proxies
直接代理是代理的一種類型，他嵌入了對象標識、以及他的服務器所運行的地址信息；完整的地址信息包括兩部分：
協議標識，比如TCP/IP、或者UDP；
協議指定的地址，比如主機名以及端口號；
為了和直接代理后面的對象進行通信，ice運行時使用代理里面的地址信息去聯系服務器；然后客戶端每次發起請求時都會將該對象的標識發送給服務端。
Indirect Proxies
間接代理有兩種形式：他只提供對象標識、或者他只提供一個和對象標識一起的對象適配標識【object adapter identifier】。只通過他的對象標識就能被訪問的對象成為知名對象【well-known object】；比如，字符串
SimplePrinter
就是一個被標識為SimplePrinter的知名對象的有效代理。
一個包括對象適配標識的間接代理有如下的字符串化的形式：
SimplePrinter@PrinterAdapter
該對象適配的所有對象均可以通過該代理被訪問，而不管該對象是否是知名對象。
注意：間接代理里面是不包括地址信息的。為了確定正確的服務器，客戶端ice運行時將代理信息傳遞給定位服務【location service】；依次地，定位服務根據對象標識或者對象適配標識作為關鍵字，到包括了服務器地址信息的列表中查詢，然后返回正確的服務器地址信息給客戶端。這樣客戶端運行時就知道怎樣和服務端進行通信了。
以上的整個過程類似于DNS【domain name service】將域名轉換為IP；當我們使用一個域名時，比如打開www.zeroc.com去請求一個web頁面，主機名在后臺首先被解析成IP地址，一旦獲取到了正確的IP地址，就可以直接用來連接到正確的服務器上了。對ICE而言，除了映射是從一個對象標識或者對象適配標識找到對應的協議地址對，其他的都是非常類似的；客戶端運行時通過配置信息知道如何聯系到定位服務，就像web游覽器通過配置知道使用哪個DNS一樣。
Direct Versus Indirect Binding
從代理中相關信息解析成協議地址對的這個過程被稱為綁定；可以想象到，直接綁定是針對于直接代理的，而間接綁定就是針對間接代理的。
間接綁定的主要優勢是他允許我們在不變動客戶端已經持有的代理的情況下對服務器進行變更（也即變更服務器地址）；換句話說，直接代理可以避免定位到服務器的額外查詢，但是當服務端變更到另外一臺機器時，此時直接代理就失效了；而另一方面，間接代理是可以繼續工作的，即使我們移動或者變更了服務器。
Fixed Proxies
固定代理也是代理的一種類型，他和一個特定的連接綁定；與包括地址信息或者適配名稱不同，固定代理包含了一個連接的句柄【Handle】。連接句柄只有在連接打開時有效，一旦連接關閉，代理也就不再有效；固定代理不能夠被【marshaled】，也就是說，他們不能被當作參數在操作調用時進行傳遞；固定代理經常被用于雙向通信【bidirectional communication】，這樣服務端能夠在不重新打開一個新連接時，直接對客戶端執行回調【callback】操作。
Routed Proxies
路由代理將所有的請求都指向一個特定的目標對象，而不是直接發送調用請求到一個實際對象；路由代理對于實現類似Glacier2服務時非常有用，因為他能讓客戶端和服務端在防火墻的保護下進行通信。
Replication
復制是讓對象適配器在多個地址有效的必要條件；復制的目標是對相同服務端運行在多個不同服務器上提供冗余；即使服務器中的某一臺出現了問題，在其他服務器上的服務端仍然有效。
特別的，復制的使用意味著：客戶端能夠通過一個地址訪問一個對象，也可以通過其他的地址而返回相同的結果；這些對象要么是無狀態的，要么他們的實現被設計成和數據庫保持同步，因為各個對象的狀態需要保持一致。
當一個代理對一個對象指定多個地址時，ice對此提供了有限的支持；在初始化連接時，ice運行時會隨機選擇地址空間中的其中一個，而當這個連接失效時，運行時則嘗試用其他地址進行連接。比如，考慮如下這個代理：
SimplePrinter:tcp -h server1 -p 10001:tcp -h server2 -p 10002
該代理表明對象標識為SimplePrinter、使用TCP協議、并在兩個地址server1和server2的對象是有效的；對于用戶或者系統管理員來說，最重要的就是確保服務端真正的運行在不同端口號的服務器上。
Replica Groups
除了以上我們談到的基于代理的復制之外，ice還提供了被稱為復制集群【replica groups】的更有用的形式，他需要使用到定位服務。
一個復制集群有一個唯一的標識，且由任意數量的對象適配器組成；一個對象適配器只可能是最多一個復制集群的成員，這樣的適配器被稱為可復制對象適配器【replicated object adapter】。
一個復制集群被確定之后，他的標識就可以被用在間接代理中替代適配器標識；比如，一個標識為PrinterAdapters的復制集群可以被用在如下的代理：
SimplePrinter@PrinterAdapters
復制集群被定位服務視為一個“虛擬對象適配器”；當解析一個包含復制集群標識的間接代理時，定位服務的行為就是一個實現細節。比如，一個定位服務能夠決定返回在集群內的所有對象適配器的地址信息，此時客戶端ice運行時就會在前面討論過的有限的復制方式中隨機選擇其中的某一個地址；另外一個可能性就是對于定位服務只返回唯一一個地址，這樣的決定將是依賴于啟發式的。
不管定位服務解析復制集群的方式如何，關鍵的收獲還是間接性的：在綁定過程中定位服務作為中間人能夠加入更多的智能化。
Servants
就像我們前面提到的，一個ice對象是一個概念性實體，他有類型、標識、以及地址信息；不管怎樣，客戶端請求最終必須以一個確切的服務端處理實體而結束，該處理實體能夠提供對操作調用時的具體行為；說得更確切些【To put this differently】，一個客戶端請求最終必須以執行服務端代碼結束，那些代碼用特定編程語言編寫，并且通過特定的處理器執行。
伺服器就是在服務端能夠對操作被調用時提供相應實際行為的artifact；一個伺服器對一個或者多個ice對象提供本體【substance】；在實際情況中，一個伺服器只不過是一個服務端開發人員編寫的類實例，該實例在服務端運行時注冊成為一個或多個ice對象的伺服器；類中的方法就相當于ice對象提供的接口中的操作，并對各操作提供具體的行為。
單個伺服器一次能依附于【incarnate】單個ice對象或者同時依附于多個ice對象；如果是前者，被伺服器依附的ice對象在伺服器中是明了的；如果是后者，伺服器隨著每次請求而根據ice對象標識被提供，如此他就能決定在請求期間哪個對象會被依附。
與此相反的，單個ice對象可以擁有多個伺服器；比如，我們可能會為一個對象創造一個代理，該代理對不同的服務器有不同的地址；在這個情況中，我們有兩臺服務器，每臺服務器中對相同的ice對象包含一個伺服器；當客戶端對該ice對象請求一個操作時，客戶端運行時會直接發送某個請求到確定的一個服務器；換句話說，對于單個ice對象的多個伺服器讓我們可以構建具有冗余功能的系統：客戶端運行時企圖向某服務器發送一個請求時，若此次請求失敗了，那么還可以將此次請求發送給另外一臺服務器；當第二次嘗試請求也失敗時，客戶端應用程序才會收到一個被服務端返回的錯誤信息。
At-Most-Once Semantics
ice支持至多一次【at-most-once】語義：ice運行時盡其所能去分發請求到正確的目的地，依賴于確切的環境他可能會對一次失敗的請求進行重試；ice保證要么他對某個請求進行分發，要是他不能分發請求，此時他會明確告訴客戶端一個適當的異常；對于一個請求絕不會【under no circumstances】被分發兩次，也即，重試只有在明確知道上次請求失敗的情況下才會發起（注意：通過UDP協議進行的自帶尋址信息的觸發會是個例外，那種情況下，重復的UDP包會導致違反至多一次語義）。
支持至多一次語義是非常重要的，因為他們能夠保證不是冥等【idempotent】的操作可以被安全的使用；所謂冥等操作是指某操作即使被執行多次也返回相同的結果；比如，x = 1; 就是一個冥等操作；即使我們執行兩次，返回的結果也都和前次的一樣。另一方面，x++; 該操作就不是冥等的：如果我們執行該操作兩次，那結果就和第一次返回的結果是不一樣的。
如果不支持至多一次語義，我們可以針對網絡失敗構建出更加健壯的分布式系統；然而，現實系統需要支持非冥等操作，所以至多一次語義是必要的，即使他們因此而降低了系統的健壯性。ice允許將個別操作標識為冥等的，對此類操作，ice運行時使用相對于非冥等操作更具侵入性的錯誤恢復機制。
Synchronous Method Invocation
默認情況下，ice的請求分發模型是同步的遠程過程調用【remote procedure call】：此時操作調用時的行為就像是本地過程調用一樣，也即，客戶端線程在操作調用期間被暫緩【suspend】直到調用完全結束。
Asynchronous Method Invocation
ice也知道異步方法觸發【AMI】：客戶端能夠異步地調用某個操作，也即客戶端照常使用一個代理去觸發某個操作，但是除了傳遞普通參數之外，還需要傳遞回調對象，而且客戶端觸發是立刻返回的。一旦操作完成了，服務端運行時觸發由客戶端初始傳入的回調對象中的方法，然后將操作結果傳給回調對象（若處理失敗，則傳遞異常信息給回調對象）。
服務端并不能辨別以同步方式或者其他方式請求的異步觸發，服務端只是知道客戶端對某個對象觸發了一次操作而已。
Asynchronous Method Dispatch
AMD是服務端的AMI；對于默認的同步分發，服務端運行時直接定位到服務器內的應用程序代碼對觸發的操作進行響應；在操作執行期間，服務端的某個執行線程被完全占用，當操作完成時被釋放。
對于異步分發【AMD】，當客戶端的某個操作觸發到達服務端時，服務端的應用程序代碼被告知；但是與AMI中代碼立刻去處理請求不同，服務端應用可以選擇延遲對請求的處理，如此他就釋放了針對請求的執行線程；此時服務端應用程序代碼就可以去做任意的他想做的；最后，一旦操作的結果可用了，應用程序代碼通過調用api通知服務端ice運行時前面被分發過來的餓請求已經處理完成了，然后ice運行時將操作的結果返回給客戶端。
AMD是非常有用的，比如服務端提供了一個執行非常耗時的操作給客戶端，或者服務端的某個操作是需要從其他額外的數據源中去異步的讀取數據并將其返回給客戶端；對于同步分發【SD】，每個客戶端需要一直等待服務端執行線程返回的數據；顯然，該方法對于有很多個客戶端時是非常不具有可擴展性的；對于異步分發，成千上萬的客戶端可以對某個相同的操作進行請求觸發，但卻不會完全占用服務端的任何執行線程。
AMD的另外一個使用場景是：當完成某個操作并將操作結果返回給客戶端時，此次卻還需要繼續保持服務端執行線程去做一些其他事情，比如執行cleanup或者是更新持久層存儲等。
同步和異步分發對于客戶端而言是完全透明的，客戶端不可能告訴服務器是采用同步還是異步的方式去處理一個請求。
Oneway Method Invocation
客戶端能夠通過單向請求的方式來調用操作；單向觸發【oneway invocation】支持“best effort”語義；對于單向觸發，客戶端運行時將請求傳遞給local transport，只要被local transport緩沖器記錄了，那對于客戶端的請求就完成了；而實際的觸發請求隨后會被操作系統異步的發送；對于單向觸發，服務器并不進行響應，也即，流量只是從客戶端向服務端的，而服務端到客戶端卻是沒有的。
單向請求是不可靠的；比如，目標對象可能不存在，此時請求就被丟失掉了；類似的，該操作可能被分發給服務器上的某個伺服器，但是操作卻可能會失敗（比如參數非法）；即使這樣，客戶端仍然無法接收到任何關于出錯的通知信息。
單向請求只可能適用于沒有返回者、沒有輸出型參數、不會拋出用戶級異常這類型的操作。
對于服務端的應用程序代碼而言，單向請求是透明的，也即，沒有任何方法可以區分從一個單向請求發起的雙向調用。
單向請求只對提供了基于流的傳輸協議（比如TCP/IP/SSL）的目標對象有效。
注意：即使單向請求通過基于流的傳輸協議進行發送，他們在服務端被處理時有可能是無序的；這是因為每次調用都是在他自己所在線程中被分發的；即使請求到達服務端時請求在被初始化時進行了排序，那也不意味著他們將會按照那個順序被處理--線程調用的異常行為可能會導致某個單向請求比另外一個比他更早到達的單向請求早完成。
Batched Oneway Method Invocation
每個單向請求都發送一個獨立的消息給服務器；對于一系列短消息而言，這樣做的代價是相當高的：因為對于每條消息客戶端和服務端運行時都必須在用戶模式和內核模式之間進行切換；在網絡層面，每條消息都會帶來流控制和消息確認的代價。
批量單向請求【Batched oneway invocations】允許以單條信息的方式發送一系列的單向請求：每次觸發一個批量單向操作時，請求都會在客戶端運行時被緩存，一旦你將所有需要發送的單向請求都累計在一起了，你可以通過調用一個獨立的api一次將所有的請求都發送完畢；隨后客戶端運行時在一條消息內將所有已經緩存起來的請求發送給服務器，服務器也以一條消息的形式接收到所有的觸發請求；這就避免了客戶端和服務端不斷重復的切換內核，在網絡傳輸上也更加容易，因為一條大的消息體被傳輸要比很多小信息體傳輸高效得多。
一個批量單向信息中的單個請求被一個單獨線程按照他們加入該批次的順序進行分發；這就保證了在一個批次的單向信息被服務器處理時是有序的。
批量單向請求對于消息服務特別有用，比如IceStorm。
Datagram Invocations
數據包請求與單向請求有著類似的“best effort”語義；但是，數據包請求需要對象使用UDP作為傳輸協議，而單向請求采用TCP/IP。
就像單向請求，數據包請求也需要操作沒有返回值、輸出型參數、用戶級異常；數據包請求通過UDP協議去觸發某個操作，只要本地UDP堆棧接收到消息操作就返回了；而實際的操作調用在后臺被網絡堆棧異步的發送。
數據包請求也是不可靠的，就像單向請求一樣。
和單向請求不一樣的是，數據包請求有很多額外的錯誤描述：
個別請求可能在網絡層被丟失；這是因為UDP包投遞的不可靠性所致；比如，若依次觸發三個操作，中間的那個操作可能就會被丟失；類似的事情在單向請求中就不可能出現，因為他們是基于連接的傳輸協議進行分發的，個別請求不可能丟失。
個別請求可能無序到達；這也是因為UDP的特性所致；因為每個請求作為一個單獨的數據包進行發送，數據包在網絡上可能通過不同路徑傳輸，這樣請求到達時的順序就可能和他們被發送時的順序是不一樣的。
數據包請求非常適合于在LANs中發送小消息，此時丟失率是很低的；他們也適合于低延遲比可靠性更重要的應用場景，比如針對快速、交互式的應用程序；最后，數據包請求能夠被用于同時向多臺服務器組播消息。
Batched Datagram Invocations
關于批量單向請求，批量數據包請求允許在緩沖器中收集很多的請求，然后通過調用api將整個緩沖器中數據作為一個數據包進行發送，之后清除緩沖器；批量數據包降低了重復系統的調用，還允許底層網絡更加有效的運行；但是，批量數據包請求只對批量消息的容量未超過網絡的協議數據單元【PDU】時有用；如果一個批量數據包的容量太大，將會被拆分成多個數據片段，這樣一個或者多個數據片段可能會被丟失，從而導致整個批量消息的丟失；然而，有一點是可以保證的，即一個批量數據包中的所有請求要么被分發，要么都不被分發，一個批次中某個請求被丟失是不可能的。
在服務端批量數據包使用一個單獨的線程來分發各批次中的各個請求；這就保證了在一個批次中各請求是被有序的執行，在服務端請求不可能出現重新排序的現象。
Run-Time Exceptions
任何的操作調用都可能引發運行時異常；運行時異常是被ice運行時預先定義好的、且覆蓋了通用的錯誤情況，比如連接失敗、連接超時、資源分配失敗；對于應用程序而言，運行時異常就像本地異常一樣，這樣對于具有異常處理能力的編程語言具有的本地異常處理進行了優美的集成。
User Exceptions
用戶級異常被使用來標示依賴于客戶端的應用程序特定的錯誤；用戶級異常能夠攜帶任意的復雜數據，且能夠被繼承，這樣就使得客戶端能夠通過捕獲繼承體系中的某個異常，從而很容易的處理錯誤類別。
Properties
ice運行時中的很多參數都可以通過properties文件來進行配置；Properties是一個鍵值對【name-value pair】，比如Ice.Default.Protocol = tcp; Properties一般被存儲在文本文件中，然后被運行時解析，比如線程池大小，跟蹤級別、以及其他各種配置參數。
?
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/sfdev/archive/2008/12/04/3446640.aspx