在介紹遠程文件系統時(shí)，特別介紹了文件管理的工作劃分不同的部分，分布到客戶(hù)機和文件服務(wù)器兩個(gè)不同機器上，全部任務(wù)仍在操作系統內完成。在遠程文件的情形中，分布實(shí)際上增長(cháng)了而不是減少了進(jìn)程的執行時(shí)間。遠程文件系統的優(yōu)勢只是實(shí)現了以文件作為單位的網(wǎng)絡(luò )資源共享。和遠程文件的情形不同，網(wǎng)絡(luò )操作系統還可以支持用戶(hù)劃分任務(wù)，分布、并行執行劃分后的各個(gè)子任務(wù)，以達到充分利用網(wǎng)絡(luò )資源、減少整個(gè)任務(wù)執行總時(shí)間的目的。
網(wǎng)絡(luò )中的計算機總是和傳統的順序進(jìn)程模型一起來(lái)完成應用處理，如同前面章節中所表現的一樣，操作系統允許自治進(jìn)程能夠在一個(gè)單CPU系統中并行執行。網(wǎng)絡(luò )為計算提供了一種機會(huì )，它可以使計算劃分成多個(gè)邏輯單元，然后讓它們在網(wǎng)絡(luò )的不同計算機上同時(shí)執行。從應用開(kāi)發(fā)人員的角度來(lái)看，根本的問(wèn)題是將串行的計算劃分成N個(gè)計算單元，其中N個(gè)單元都能同時(shí)執行，就會(huì )有最小的開(kāi)銷(xiāo)。在面向對象技術(shù)發(fā)達的今天，計算單元靜態(tài)表現為組件，組件由類(lèi)構成。組件運行時(shí)，表現為一個(gè)個(gè)建立的對象、線(xiàn)程（或進(jìn)程），通過(guò)它們向網(wǎng)絡(luò )提供服務(wù)或請求網(wǎng)絡(luò )服務(wù)。
應用任務(wù)的劃分是開(kāi)發(fā)人員的事情，因為任務(wù)的劃分必須知道在整個(gè)任務(wù)中各個(gè)子任務(wù)之間的邏輯關(guān)系。并行的子任務(wù)如何在支持的網(wǎng)絡(luò )上分布一般由開(kāi)發(fā)人員來(lái)決定。他們把子任務(wù)組件靜態(tài)部署到運行它們的主機上。圖6.17 所示的應用分布是一種典型情況，它分為三層次：數據管理層、業(yè)務(wù)邏輯層和表達層。支持這種分布式應用往往是網(wǎng)絡(luò )操作系統和Web系統共同完成的。
圖6.17 數據管理層、業(yè)務(wù)邏輯層和表達層
網(wǎng)絡(luò )操作系統為分布式計算提供服務(wù)和環(huán)境：
1．客戶(hù)/服務(wù)器模型
單機上操作系統提供了父進(jìn)程創(chuàng )建子進(jìn)程的操作。在網(wǎng)絡(luò )操作系統中，沒(méi)有顯式的系統調用來(lái)動(dòng)態(tài)地在另一個(gè)機器中創(chuàng )建、調度、撤消一個(gè)進(jìn)程?？蛻?hù)/服務(wù)器模型為分布式計算的基本模式。任何特定的應用程序都可以通過(guò)把計算劃分成一組被動(dòng)的服務(wù)器計算和另一組主動(dòng)的客戶(hù)計算來(lái)使用該模式?？蛻?hù)根據應用程序的輸入數據執行計算，然后當需要時(shí)激活服務(wù)器?？蛻?hù)/服務(wù)器模型也是一種顯式的網(wǎng)絡(luò )進(jìn)程調度模型。服務(wù)器在網(wǎng)絡(luò )上的一個(gè)確定的位置被啟動(dòng)，客戶(hù)在網(wǎng)絡(luò )中的任意位置獨立啟動(dòng)對服務(wù)器的請求。在這種情形中，客戶(hù)或服務(wù)器的計算單元在它所在的計算機中作為一個(gè)普通進(jìn)程來(lái)對待。默認情況下，單計算機的多道程序設計調度策略用于為分布計算部分提供服務(wù)。
在一些主流的中間件系統中，如J2EE、.Net，它們使用對象或線(xiàn)程來(lái)激活服務(wù)。在網(wǎng)絡(luò )中任一機器上注冊的用戶(hù)可以啟動(dòng)一個(gè)獨立的應用程序，控制通常隨著(zhù)客戶(hù)/服務(wù)器流進(jìn)行，即，一個(gè)服務(wù)器正在網(wǎng)絡(luò )上運行，客戶(hù)通過(guò)本地服務(wù)代理（client stub）在服務(wù)器啟動(dòng)相應的服務(wù)代理（server skeleton），激活引起計算單元實(shí)例化的活動(dòng)，實(shí)現客戶(hù)與服務(wù)器交互，實(shí)現與應用相關(guān)的分布式計算。
當代網(wǎng)絡(luò )操作系統由于它對編程模式有如此之大的影響，所以操作系統和編程語(yǔ)言都在進(jìn)行分布式計算方面的研究。
2．進(jìn)程通信與同步
在單機操作系統中進(jìn)程通信、同步機制依賴(lài)于共享存貯器。在網(wǎng)絡(luò )進(jìn)程之間沒(méi)有共享的存貯器，操作系統通常提供一個(gè)基于消息或事務(wù)實(shí)現網(wǎng)絡(luò )進(jìn)程通信與同步。
（1）消息
消息傳遞機制是網(wǎng)絡(luò )環(huán)境中分布式計算的基礎。在高性能應用領(lǐng)域中，經(jīng)常提供應用程序員直接使用的網(wǎng)絡(luò )消息傳遞機制接口，甚至操作系統在實(shí)現分布式環(huán)境中其他方面的應用時(shí)也使用該接口。在單機進(jìn)程管理討論了基本的進(jìn)程通信操作(send()和receive())，這里討論如何在網(wǎng)絡(luò )協(xié)議上實(shí)現網(wǎng)絡(luò )進(jìn)程通信操作。
消息服務(wù)有兩個(gè)目的：
1）它提供一個(gè)進(jìn)程與另一個(gè)進(jìn)程共享信息的顯式機制。
2）它可以被用于同步接收者與發(fā)送者之間的操作。
接收者進(jìn)程必須有一個(gè)信箱來(lái)緩沖消息。信箱的消息已經(jīng)被發(fā)送出來(lái)，但邏輯上還沒(méi)有被接收者所接收。發(fā)送操作可以是同步或者異步進(jìn)行的。在同步操作中，發(fā)送者要等待，直到發(fā)送的消息被安全地傳送到接收者的信箱中。在異步操作中，發(fā)送者傳送消息后繼續運行，而無(wú)需查看是否發(fā)送的消息已經(jīng)被加放到接收者的信箱中。接收操作可以是阻塞的或者是非阻塞的。在阻塞情況下，當一個(gè)接收者讀取信箱中的一個(gè)消息時(shí)，如果沒(méi)有消息它會(huì )被阻止，繼續直到消息出現。在非阻塞接收操作時(shí)，接收者未發(fā)現消息也會(huì )繼續運行。
在網(wǎng)絡(luò )系統中，為了把信息放入到遠程機器另一個(gè)進(jìn)程的地址空間中，信息內容通常必須被拷貝幾次，圖6.18概括了通過(guò)網(wǎng)絡(luò )進(jìn)程發(fā)送操作的過(guò)程。首先，發(fā)送者在一個(gè)內部緩沖中生成要被傳送的信息，然后信息被拷貝到操作系統的地址空間中，因此它可以被拷貝到另一個(gè)進(jìn)程的信箱中。假設使用網(wǎng)絡(luò )層協(xié)議，信息從一般的消息中被拷貝到報文中，而在報文又必須被拷貝到數據鏈路層的幀中，通常是在一個(gè)控制器的硬件緩沖中進(jìn)行，然后被拷貝到物理網(wǎng)絡(luò )中進(jìn)行傳輸。在接收機器中，必須進(jìn)行一組類(lèi)似的拷貝過(guò)程。注意到它沒(méi)有使用傳輸層協(xié)議，并且它忽略了信箱的管理，而其中可能還請求額外的拷貝操作?？截惒僮魍ǔＪ腔诰W(wǎng)絡(luò )的消息傳遞機制的性能的限制因素。操作系統設計者所面對的挑戰就是要最小化這種操作的數目。當代操作系統努力實(shí)現消除不必要拷貝操作的消息傳遞機制，這表明確操作系統必須首先提供一個(gè)應用級的消息傳遞接口，它可以直接被應用程序員參及系統軟件所使用。操作系統就可以根據它的設計策略和通信中所采用的網(wǎng)絡(luò )協(xié)議類(lèi)型來(lái)優(yōu)化接口的實(shí)現。
在網(wǎng)絡(luò )分布計算中，一般使用消息來(lái)建立計算的次序而獲得同步。消息在每個(gè)進(jìn)程中都與同步相關(guān)聯(lián)的，每個(gè)消息都帶有發(fā)送計算機本地時(shí)間的時(shí)間戳，然后結合該時(shí)間戳來(lái)確定與消息發(fā)生相關(guān)聯(lián)的一個(gè)全局次序。
（2）事務(wù)
事務(wù)的思想把一序列操作組織作為一個(gè)整體來(lái)被執行，如同執行單個(gè)命令一樣，如果該序列操作都被完成或者根本就沒(méi)有被執行（直到以后的某個(gè)時(shí)間被執行），那么事務(wù)是正確的。事務(wù)在很多情形中可以用于獲得與同步一樣的效果。分布式各部分之間的交互是非常復雜的，這導致任一部分之間都可能交換相關(guān)的消息，或者相關(guān)消息流中的任一消息都可能會(huì )被從一個(gè)部分發(fā)送到另一部分中。這種相關(guān)的消息流稱(chēng)之為一個(gè)事務(wù)。一個(gè)事務(wù)是相關(guān)的命令序列，要么所有命令都被執行了，要么一個(gè)也沒(méi)有執行。一個(gè)事務(wù)引起了一組特殊的微觀(guān)活動(dòng)，并且在兩個(gè)部分之間進(jìn)行交互以獲得某種微觀(guān)層的效果。作為一個(gè)軟件系統例子，假設一個(gè)服務(wù)器的數據文件包含一組記錄，每個(gè)記錄有N個(gè)數據項組成。它們可以被一組用戶(hù)進(jìn)程中的任一個(gè)進(jìn)程更新。如果有兩個(gè)或多個(gè)客戶(hù)都企圖同時(shí)更新同一條記錄中的多個(gè)數據項，那么問(wèn)題就出現了。假設進(jìn)程Pi改變記錄中的數據項3、6、2以及8的同時(shí)，進(jìn)程Pj試圖改變記錄中的數據項5、8、4以及6 (見(jiàn)圖6.18)。那么將會(huì )有兩個(gè)客戶(hù)命令序列。如圖6.19所示，首先Pi發(fā)送一個(gè)消息到服務(wù)器要求更新記錄k中的數據項3，然后發(fā)送一個(gè)消息要求更新記錄k中的數據項6，依次類(lèi)推。
由于Pi可能更新了數據項3和6之后讓Pj更新數據項5、8、4以及6，然后又讓Pi更新數據項2和8，因此結果是服務(wù)器中記錄k數據項8的值是Pi更新的，但數據項6的值是Pj更新的。在一些應用程序中，這也許是可以接受的，但在其他一些應用中卻是災難性的。例如，如果數據項6存一個(gè)人的名字而數據項8存其地址。這個(gè)例子意味著(zhù)Pi修改記錄k的事務(wù)必須完成，然后由進(jìn)程Pj完成修改記錄k的的事務(wù)；或者Pj先完成修改記錄k的事務(wù)，然后由進(jìn)程Pi完成修改記錄k的的事務(wù)。
程序員通過(guò)標記語(yǔ)句序列的開(kāi)始與結束來(lái)定義一個(gè)事務(wù)。服務(wù)器會(huì )檢測事務(wù)開(kāi)始的標記，并隨后將把所有來(lái)自客戶(hù)端的命令作為事務(wù)的一部分來(lái)對待，直到收到一個(gè)事務(wù)結束的標記。如果服務(wù)器代表一個(gè)特定客戶(hù)開(kāi)始處理一個(gè)事務(wù)，那么服務(wù)器就有責任要么執行完所有的命令直到事務(wù)結束，要么保留服務(wù)器的狀態(tài)好像一個(gè)命令也沒(méi)有被執行一樣。當服務(wù)器遇到事務(wù)結束標記時(shí)，它就提交命令序列的結果，從而改變服務(wù)器的信息狀態(tài)，如果服務(wù)器由于與其他事務(wù)的沖突而中止了正在執行的事務(wù)，那么它就可能取消（abort）該事務(wù)。如果中斷事務(wù)，服務(wù)器將恢復所有的信息，包括從事務(wù)開(kāi)始起執行的命令所改變的狀態(tài)，到事務(wù)開(kāi)始之前它們所處的狀態(tài)?？蛻?hù)也可以取消一次事務(wù)，然而，事務(wù)被取消，通常指的是由于命令沖突由服務(wù)器所做的取消操作。
在很多情形中，操作系統使用事務(wù)來(lái)協(xié)同進(jìn)程的操作。例如遠程文件系統為大多數頁(yè)級、塊級以及文件級的處理而使用事務(wù)，因為信息的變化要求在任意時(shí)刻對客戶(hù)端與服務(wù)器狀態(tài)中的多個(gè)域更新。
事務(wù)實(shí)現要求必須在事務(wù)開(kāi)始的時(shí)候，有效地對相關(guān)資源狀態(tài)做一快照，假定快照信息可以用于恢復檢測點(diǎn)的資源狀態(tài)，那么事務(wù)中的命令就在資源的拷貝或者初者初始資源上被執行。如果在一個(gè)事務(wù)進(jìn)行中另一個(gè)事務(wù)又開(kāi)始了，那么狀態(tài)必須認真地保存，如果第一個(gè)事務(wù)被提交，就保留操作過(guò)程的結果。如果事務(wù)被取消，資源狀態(tài)可以基于檢測點(diǎn)的信息進(jìn)行恢復。如果事務(wù)被提交，改變后的拷貝就變成了主版本，檢測點(diǎn)的信息就可以釋放了。
事務(wù)操作情形下死鎖可能會(huì )發(fā)生，一個(gè)服務(wù)器在執行所有事務(wù)過(guò)程中可以涉及到死鎖，所以只要事務(wù)出現不執行的情況，服務(wù)器就可以執行進(jìn)行死鎖檢測。允許服務(wù)器根據它的檢測條件取消任一事務(wù)，所以它可以從死鎖中恢復。
（3）并發(fā)控制
并發(fā)控制是一種技術(shù)，通過(guò)它系統可使一組進(jìn)程在一個(gè)共享資源集上交叉執行一組事務(wù)。它所產(chǎn)生的效果如同單個(gè)進(jìn)程在事務(wù)過(guò)程中獨享所有的相關(guān)資源一樣，因此，盡管事務(wù)內部的操作可能是并行進(jìn)行的，但并發(fā)控制要保證一組事務(wù)間邏輯上的串行化。
在服務(wù)器中資源鎖是一種實(shí)現并發(fā)控制的最簡(jiǎn)單機制。當事務(wù)改變資源的一部分時(shí)，服務(wù)器就在事務(wù)持續期間鎖定該資源。在隨后的進(jìn)程試圖改變被鎖的資源部分時(shí)，因為資源被鎖而不能實(shí)現，一直要等到第一個(gè)事務(wù)結束。
兩階段鎖協(xié)議（two-phased locking protocol）保證一組事務(wù)將產(chǎn)生正確的串行化結果，且不會(huì )發(fā)生死鎖。在第一個(gè)階段期間，事務(wù)請求完成任務(wù)所需要的所有鎖，并且期間不釋放任何一個(gè)鎖。在第二個(gè)階段期間，它釋放鎖并且不再請求，一種極端的情形是，當事務(wù)被初始化時(shí)發(fā)出所有的鎖請求，并且當事務(wù)結束時(shí)發(fā)出所有的鎖釋放請求。
鎖的使用出現了下列和死鎖相關(guān)的問(wèn)題：
1）如果資源是一個(gè)文件，那么鎖是應該加到一個(gè)磁盤(pán)塊、一個(gè)邏輯文件頁(yè)，還是整個(gè)文件涉及到管理的鎖數目與支持事務(wù)間并發(fā)訪(fǎng)問(wèn)量。
2）如果事務(wù)恰好鎖住了系統資源某些部分的同時(shí)而又請求其他部分，死鎖就可能會(huì )發(fā)生。
在采用兩階段鎖方法的情況下，會(huì )強制每個(gè)事務(wù)在它初始化時(shí)，請求所有它需要的鎖。并發(fā)控制機制必須顯式地避免死鎖，否則，它將不得不強制實(shí)行每個(gè)事務(wù)請求鎖的次序、死鎖檢測或者剝奪策略。
并發(fā)控制是圍繞邏輯上集中的鎖管理器來(lái)考慮的，如果資源被分布在網(wǎng)絡(luò )上，鎖管理器必須能夠從每個(gè)構成結點(diǎn)中獲得狀態(tài)。對多道程序設計環(huán)境較慢的網(wǎng)絡(luò )通信速度，基于加鎖的分布并發(fā)控制傾向于使用鎖來(lái)控制相對大的資源單元。在文件高速緩存的討論中，描述了版本如何被用于處理并發(fā)文件訪(fǎng)問(wèn)。類(lèi)似的方法可以用于并發(fā)控制中，它通過(guò)在每個(gè)事務(wù)上設置一個(gè)時(shí)間戳，然后基于時(shí)間戳維護版本的拷貝。版本的后期處理確定訪(fǎng)問(wèn)沖突的情形，并且確定事務(wù)發(fā)生的次序。雖然這種方法不能解決所有的沖突現象，但它確實(shí)可能支持很多的情況。
另一個(gè)困難如同一般的同步中所出現的一樣，即如果事務(wù)起源于不同的機器，它們的時(shí)間戳必須從一個(gè)全局時(shí)鐘中得到而不是一個(gè)局部時(shí)鐘。
（4）死鎖管理。死鎖檢測算法依賴(lài)于系統資源的分配狀態(tài)。在網(wǎng)絡(luò )中，資源的集合包括每個(gè)機器中的所有資源，而且在任意時(shí)刻檢測所有機器的狀態(tài)已經(jīng)被證明是非常困難的，因而在網(wǎng)絡(luò )環(huán)境中分布式死鎖檢測是一個(gè)難以解決的問(wèn)題。
分布式計算中，組件是靜態(tài)分布的單位，組件由類(lèi)構成。組件運行時(shí)構造的對象與其他分布的組件構造的遠程對象之間交互、協(xié)作，實(shí)現它們提供服務(wù)。下面以遠程對象方法調用為例，闡述客戶(hù)/服務(wù)器模型的實(shí)現原理，遠程對象方法調用也是支持分布式計算的基礎。
面向對象的程序設計中討論的對象都位于同一臺機器上，即位于同一地址空間中。一個(gè)對象調用另一個(gè)對象提供的方法，通過(guò)共享的堆棧傳遞參數和調用結果。遠程對象方法調用RMI(Remote Method Invocation)是把本地對象方法調用的概念加以擴充后，以適應對象分布環(huán)境下的交互、協(xié)作。RMI的形式和行為與本地對象方法調用的形式和行為極其相似，主要的差別在于被調用的對象代碼實(shí)際運行在與調用者位于不同的主機結點(diǎn)上。圖6.20表示主機A的程序遠程調用主機Y的類(lèi)RemoteServer對象remotes的方法remotePi()。習慣上，這里請求遠程調用者叫客戶(hù)(client)，接收遠程調用并完成要求方法調用者叫服務(wù)器（server）。
遠程對象方法調用者（客戶(hù)）首先發(fā)送一個(gè)遠程調用請求，請求消息包括：調用的對象、方法、參數等，隨后進(jìn)入等待讀遠程調用結果；服務(wù)者接收客戶(hù)發(fā)送的調用請求消息，然后利用客戶(hù)提供的參數，調用要求的對象方法，并返回結果到調用的客戶(hù)。從調用者的角度看，該框架所產(chǎn)生的行為好像是從一個(gè)對象到另一個(gè)類(lèi)對象間的方法調用一樣。
(2)客戶(hù)代理和服務(wù)器代理
上述客戶(hù)程序中調用遠程對象remotes的方法remotePi()，由于對象remotes及其方法remotePi()不駐留在本地機器上，客戶(hù)包含遠程調用的程序（類(lèi)），編譯找不到引用的類(lèi)，語(yǔ)法上就通不過(guò)，更不用說(shuō)運行了。為了實(shí)現遠程調用語(yǔ)義，在客戶(hù)方引入一個(gè)遠程調用方法代理（clientStub），它是一特定功能的程序（類(lèi)），它具有遠程類(lèi)同樣的類(lèi)首部，同樣的遠程類(lèi)方法首部。它的每個(gè)方法體實(shí)現把遠程調用過(guò)程名、參數等發(fā)送到服務(wù)器，這樣語(yǔ)法上滿(mǎn)足客戶(hù)包含遠程調用的程序編譯的要求。服務(wù)器一方也引入服務(wù)器代理(serverStub)，它也是一特定功能的程序（類(lèi)），它負責接收客戶(hù)代理發(fā)來(lái)的遠程調用請求，裝配方法參數，調用相應的對象方法，把調用結果返回給客戶(hù)代理?？蛻?hù)代理接收服務(wù)器代理的調用結果，并返回給客戶(hù)調用程序?？蛻?hù)代理存放在客戶(hù)方，服務(wù)器代理存放在服務(wù)器方?？蛻?hù)程序與客戶(hù)代理在客戶(hù)方成功編譯、連接；服務(wù)器代理與遠程服務(wù)類(lèi)在服務(wù)器方成功編譯、連接。當程序運行時(shí)，客戶(hù)程序調用遠程方法remotes.remotePi()，實(shí)際調用的是其客戶(hù)代理的remotePi()，客戶(hù)代理和服務(wù)器代理協(xié)同承擔了遠程調用的重要功能（見(jiàn)圖6.21）。
圖6.21 客戶(hù)代理、服務(wù)器代理和RMI實(shí)時(shí)運行系統
在RMI實(shí)現中有幾個(gè)需要關(guān)心的問(wèn)題：
1．RMI的結構
RMI實(shí)現可以采用圖6.21中的通用形式，客戶(hù)機執行客戶(hù)程序（Client），其中包含有客戶(hù)端應用程序代碼、客戶(hù)代理以及傳輸機制。服務(wù)器通過(guò)傳輸機制實(shí)現Server進(jìn)程(服務(wù)器server stub）主程序以及遠程過(guò)程的服務(wù)器實(shí)現?？蛻?hù)代理把本地過(guò)程調用翻譯成RPC協(xié)議中客戶(hù)端的活動(dòng)，并且服務(wù)器代理實(shí)現RPC協(xié)議的服務(wù)器端部分。如圖所示，Client進(jìn)程中的RMI本地調用客戶(hù)代理代碼?？蛻?hù)代理通過(guò)名字服務(wù)器定位執行遠程過(guò)程的服務(wù)器地址。Server進(jìn)程必須事先已經(jīng)注冊了遠程過(guò)程所用的全局名字，在示例中為remote()。查詢(xún)只需要在第一次調用時(shí)進(jìn)行，以后客戶(hù)與服務(wù)器就將建立起連接，在隨后調用中使用已存在的連接。接下來(lái)，客戶(hù)代理將參數打包在一個(gè)消息中并傳送到Server進(jìn)程中的服務(wù)器代理。由于該服務(wù)器可能服務(wù)幾個(gè)不同的遠程過(guò)程，所以它從到來(lái)的消息選擇一個(gè)遠程過(guò)程。服務(wù)器代理完成調用并將結果參數打包返回給Client進(jìn)程，同時(shí)Client進(jìn)程將一直被阻塞等待調用的結束。當Client進(jìn)程得到返回的消息時(shí)，它解包返回參數并傳遞到主程序中。
2.按照本地調用方式擴展遠程調用
RMI機制可能強制程序員在編譯時(shí)，鏈接編輯時(shí)或者運行時(shí)來(lái)區分是RMI還是本地過(guò)程調用。如果要在編譯時(shí)進(jìn)行這種區分，那么程序員需要與本地調用所不同的一個(gè)RMI使用接口，例如，一個(gè)遠程過(guò)程調用可能采用的形式為：
callRemote (remoteF, a1, a2, …, aN, …);
其中callRemote是一個(gè)被鏈接到調用程序地址空間的本地過(guò)程，參數規定了遠程過(guò)程的名字remoteF，同樣規定了過(guò)程調用的參數。
程序員選擇在鏈接時(shí)區分本地和遠程方法，那么系統對于本地和遠程調用采用相同的形式。編譯器將不區分它們并將自動(dòng)地為遠程方法調用客戶(hù)代理，鏈接編輯器將被要求解決所有的外部訪(fǎng)問(wèn)。為了解決外部訪(fǎng)問(wèn)，鏈接編輯器將需要類(lèi)似于鏈接信息庫中的信息來(lái)說(shuō)明進(jìn)程是本地的還是遠程的。鏈接編輯器所需要的最少信息是那些指向遠程過(guò)程的符號標識。
遠程方法運行時(shí)刻說(shuō)明是最一般的方法，這種方法請求與動(dòng)態(tài)消息綁定相同的一種對動(dòng)態(tài)綁定的支持。編譯器或者鏈接編輯器將不能解決外部訪(fǎng)問(wèn)，因而外部訪(fǎng)問(wèn)假定在運行時(shí)刻被綁定。這種延遲綁定要求靜態(tài)綁定機制在編譯的代碼中保留足夠的信息，使運行系統能夠解決外部訪(fǎng)問(wèn)。
3.定位遠程過(guò)程
調用者必須能夠定位遠程對象服務(wù)位置（機器、端口、對象）。一般來(lái)說(shuō)，支持RMI的服務(wù)器部署的機器、使用的端口是可以約定的。RMI的服務(wù)器還必須的支持命名服務(wù)。遠程對象在服務(wù)器一端通過(guò)命名服務(wù)注冊，同時(shí)，網(wǎng)絡(luò )客戶(hù)訪(fǎng)問(wèn)該RMI的服務(wù)器的命名服務(wù)，可以按相應遠程對象名找到其引用對象。
遠程對象網(wǎng)絡(luò )位置的動(dòng)態(tài)綁定是最有用并且應用最廣泛的方法。它如圖6.22所示，客戶(hù)代理是中間媒介，并且是被靜態(tài)地鏈接到調用程序。當第一次執行RMI時(shí)，客戶(hù)代理要求命名機制確定遠程對象位于什么地方，在隨后的調用中，它已經(jīng)知道了服務(wù)器的位置。
4.代理（stub）的生成
客戶(hù)/服務(wù)器模型基于公共的服務(wù)接口（Interface），服務(wù)器實(shí)現這個(gè)接口，客戶(hù)調用這個(gè)約定的服務(wù)接口。遠程接口不同，客戶(hù)代理和服務(wù)器代理也不同。分析表明：每個(gè)遠程對象方法的客戶(hù)代理和服務(wù)器代理只與遠程方法接口有關(guān)。因此，利用RMI編譯器，讀入遠程對象的接口文件，就可以自動(dòng)生成遠程接口對應的客戶(hù)代理和服務(wù)器代理。
5.網(wǎng)絡(luò )支持
傳輸機制實(shí)現網(wǎng)絡(luò )消息傳遞，雖然要求可靠性，但實(shí)際上往往使用專(zhuān)門(mén)用于RMI協(xié)議的數據報來(lái)實(shí)現。RMI協(xié)議并不要求具有像TCP所提供的虛電路一樣的全部特征，當發(fā)送者和接收者作為已知行為的客戶(hù)代理和服務(wù)器代理時(shí)，一個(gè)專(zhuān)用的協(xié)議是相對容易構造的。
在服務(wù)器端，每個(gè)遠程過(guò)程的模塊必須準備接收遠程調用。這要求服務(wù)器包含一個(gè)調用進(jìn)程代理（服務(wù)器代理），接收來(lái)自客戶(hù)代理的調用請求,并進(jìn)行本地調用。在通常的情形中，服務(wù)器通過(guò)命名服務(wù)注冊每個(gè)過(guò)程，從而使客戶(hù)代理能夠在調用時(shí)定位過(guò)程。遠程對象注冊包括將對象名增加到命名服務(wù)器中，并且將內部標識號映射到方法名。
在調用時(shí)，客戶(hù)代理將調用參數打包成消息，并發(fā)送到由名字服務(wù)器所指定的網(wǎng)絡(luò )遠程調用代理接口。服務(wù)器接收消息傳送到服務(wù)器代理，由服務(wù)器代理解包參數，識別出被調用的過(guò)程并調用它。當過(guò)程返回時(shí)，服務(wù)器代理將結果打包并返回給客戶(hù)代理，由客戶(hù)代理再解包返回的結果并返回到調用者。
當通過(guò)傳值方法進(jìn)行參數傳遞時(shí)，使用這種機制很容易進(jìn)行處理，而通過(guò)傳名、傳指針?lè )绞絺鬟f參數則難以實(shí)現。對于后一個(gè)問(wèn)題，不同的遠程過(guò)程使用了不同的方法，然而，每一種都將增加在客戶(hù)代理與服務(wù)器代理之間進(jìn)行網(wǎng)絡(luò )傳輸的負擔。
RMI對于跨越不同機器間的分布式處理是有用的，但它們并不鼓勵并行計算。當一個(gè)調用者調用遠程對象方法時(shí)，在該方法執行期間它會(huì )被阻塞。所以當考慮一個(gè)RMI實(shí)現時(shí)，性能總是一個(gè)主要問(wèn)題。雖然RMI提供了延遲綁定，但它的性能開(kāi)銷(xiāo)必須盡可能地小，即使這樣，在當代分布式應用中遠程過(guò)程還是被廣泛采用，因為它們并不需要了解分布機制和策略，卻實(shí)現了一個(gè)傳統的編程模型。
聯(lián)系客服
