Java遠程方法調(diào)用（2）
· 傳遞屬性
前面我們講到，RMI可以傳遞屬性，并簡單介紹了一下一個有關(guān)開支報告程序的情況。下面我們將深入討論如何設計這樣的系統(tǒng)。這樣介紹的目的是使您能夠利用RMI的功能將屬性從一個系統(tǒng)傳遞到另一個系統(tǒng)，并隨心所欲地安排當前的計算地點，并便于將來的改變。下面的例子并未涉及真實世界可能發(fā)生的所有問題，但可幫助讀者了解處理問題的方法。
· 服務器定義的策略
客戶機向用戶顯示圖形用戶界面(GUI)，用戶填寫開支報告?？蛻魴C程序使用RMI與服務器進行通信。服務器使用JDBC( Java關(guān)系數(shù)據(jù)庫連接包)將開支報告存儲在數(shù)據(jù)庫中。至此，這看起來與其它多層次系統(tǒng)大同小異，但有一個重大區(qū)別-- RMI能下載屬性。
假定公司關(guān)于開支報告的政策發(fā)生改變。例如，目前公司只要求對超過20美元的開支需開具發(fā)票。但到明天，公司認為這太寬松了，便決定除不超過20美元的餐費以外，任何開支均需開具發(fā)票。如果不能下載屬性的話，那么在設計便于修改的系統(tǒng)時您可選擇下列方法之一：
用客戶端安裝與政策有關(guān)的程序。政策改變時，必須更新包含此政策的所有客戶端程序。您可在若干服務器上安裝客戶程序，并要求所有用戶從這些服務器之一運行客戶程序，從而減少問題。但這仍不能徹底解決問題-- 那些讓程序運行好幾天的用戶就無法使程序更新，而總是會有一些用戶為了方便而把軟件復制到本地磁盤上。
您可要求服務器在每次向開支報告添加項目時檢查政策。但這樣就會在客戶機和服務器之間產(chǎn)生大量數(shù)據(jù)流，并增加服務器的工作量。這還會使系統(tǒng)變得更加脆弱--網(wǎng)絡故障會立即妨礙用戶，而不僅僅是只在其呈交開支報告或啟動新的報告時對其產(chǎn)生影響。同時，添加項目的速度也會變慢，因為這需要穿越整個網(wǎng)絡往返一圈才能到達(不堪重負的)服務器。
您可在呈交報告時要求服務器對政策進行檢查。這樣就會使用戶創(chuàng)建很多必須待批報告的錯誤項目，而不是立刻捕捉到第一個錯誤，從而使用戶有機會停止制造錯誤。為避免浪費時間，用戶需要立刻得到有關(guān)錯誤的反饋。
有了RMI，您就能以簡單的方法調(diào)用程序從服務器得到屬性，從而提供了一種靈活的方式，將計算任務從服務器卸載到客戶機上，同時為用戶提供速度更快的反饋。當用戶準備編寫一份新的開支報告時，客戶機就會向服務器要求一個對象，該對象嵌入了適用于該開支報告的當前政策，就如同通過用Java編寫的政策接口所表示的那樣。該對象可以以任何方式實現(xiàn)當前政策。如果這是客戶機RMI首次看到這種專門執(zhí)行的政策，就會要求服務器提供一份執(zhí)行過程的副本。如果執(zhí)行過程將來發(fā)生變化，則一種新的政策對象將被返回給客戶機，而RMI運行時則會要求得到新的執(zhí)行過程。
這表明，政策永遠是動態(tài)的。您要想修改政策，就只需簡單地編寫通用政策接口的新的執(zhí)行程序，把它安裝在服務器上，并對服務器進行配置以返回這種新類型的對象即可。這樣，每臺客戶機都會根據(jù)新的政策對新的開支報告進行檢查。
這是一種比任何靜態(tài)方法都更好的方法，原因如下：
所有客戶機不必暫?；蛴眯碌能浖砩?-軟件可根據(jù)需要在不工作時加以更新。
服務器不必參與項目檢查工作，該工作可在本地完成。
允許動態(tài)限制，因為對象執(zhí)行程序(而不僅僅是數(shù)據(jù))是在客戶機和服務器之間進行傳遞的。
使用戶能立刻看到錯誤。
使客戶機在服務器上所能調(diào)用的方法的遠程接口定義如下：
import java.rmi.*;
public interface ExpenseServer extends Remote {
Policy getPolicy() throws RemoteException;
void submitReport(ExpenseReport report)
throws RemoteException, InvalidReportException;
}
import語句輸入Java RMI包。所有RMI類型均在包java.rmi或其子包內(nèi)定義。接口ExpenseServer是一般的Java接口，具有如下兩種有趣的特點：
它擴展了名為Remote的RMI接口，這使該接口標記為可用于遠程調(diào)用。
它的所有方法均拋出RemoteException，后者用來表示網(wǎng)絡或信息故障。
遠程方法還可拋出您所需要的任何其他例外，但至少必須拋出RemoteException，這樣您才能處理只會在分布式系統(tǒng)中發(fā)生的錯誤狀態(tài)。該接口本身支持兩個方法：getPolicy (返回一個實現(xiàn)政策接口的對象)，和submitReport (提交一個完成的開支請求，并在報告無論因何種原因使表格出現(xiàn)錯誤時，拋出一個例外)。
政策接口本身可聲明一種使客戶機知道能否在開支報告中添加一個項目的方法：
public interface Policy {
void checkValid (Expenseentry entry)
throws PolicyViolationException;
}
如果該項目有效--即符合當前政策，則該方法可正常返回。否則就會拋出一個描述該錯誤的例外。政策接口是本地的(而非遠程的)，所以將通過本機對象在客戶機上執(zhí)行--在客戶機的虛擬機上，而非整個網(wǎng)絡上運行的對象?？蛻魴C可能運行下列程序：
Policy curPolicy = server.getPolicy();
start a new expense report
show the GUI to the user
while (user keeps adding entries) {
try {
curPolicy.checkValid(entry); // throws exception if not OK
add the entry to the expense report
} catch (PolicyViolationException e) {
show the error to the user
}
}
server.submitReport(report);
當用戶請求客戶機軟件啟動一份新的開支報告時，客戶機就調(diào)用server.getPolicy，并要求服務器返回一個包含當前開支政策的對象。添加的每個項目首先都被提交給該政策對象，以獲得批準。如果政策對象報告無錯誤，則該項目就被添加到報告中；否則錯誤就被顯示給用戶，而后者可采取修正措施。當用戶完成向報告中添加項目時，整個報告就被呈交。服務程序如下：
import java.rmi. *;
import java.rmi.server. *;
class ExpenseServerImpl
extends UnicastRemoteObject
implements ExpenseServer
{
ExpenseServerImpl() throws RemoteException {
// . . . set up server state . . .
}
public Policy getPolicy() {
return new TodaysPolicy();
}
public void submitReport(ExpenseReport report) {
// . . . write the report into the db . . .
}
}
除基本程序包外，我們還輸入RMI的服務程序包。類型UnicastRemoteObject 定義了此服務程序遠程對象的類型，在本例中，應為單一服務程序而非復制服務(下面還會詳細介紹)。Java類ExpenseSeverImpl實現(xiàn)遠程接ExpenseServer的方法。遠程主機的客戶機可使用RMI將信息發(fā)送給ExpenseServerImpl對象。
本站僅提供存儲服務，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點擊舉報。
