遠程方法調用入門指南
Copyright ? 2005 Stephen Suen. All rights reserved.
Java 遠程方法調用（Remote Method Invocation, RMI）使得運行在一個 Java 虛擬機（Java Virtual Machine, JVM）的對象可以調用運行另一個 JVM 之上的其他對象的方法，從而提供了程序間進行遠程通訊的途徑。RMI 是 J2EE 的很多分布式技術的基礎，比如 RMI-IIOP 乃至 EJB。本文是 RMI 的一個入門指南，目的在于幫助讀者快速建立對 Java RMI 的一個感性認識，以便進行更深層次的學習。事實上，如果你了解 RMI 的目的在于更好的理解和學習 EJB，那么本文就再合適不過了。通過本文所了解的 RMI 的知識和技巧，應該足夠服務于這個目的了。
?
我們知道遠程過程調用（Remote Procedure Call, RPC）可以用于一個進程調用另一個進程（很可能在另一個遠程主機上）中的過程，從而提供了過程的分布能力。Java 的 RMI 則在 RPC 的基礎上向前又邁進了一步，即提供分布式 對象間的通訊，允許我們獲得在遠程進程中的對象（稱為遠程對象）的引用（稱為遠程引用），進而通過引用調用遠程對象的方法，就好像該對象是與你的客戶端代碼同樣運行在本地進程中一樣。RMI 使用了術語"方法"（Method）強調了這種進步，即在分布式基礎上，充分支持面向對象的特性。
RMI 并不是 Java 中支持遠程方法調用的唯一選擇。在 RMI 基礎上發展而來的 RMI-IIOP（Java Remote Method Invocation over the Internet Inter-ORB Protocol），不但繼承了 RMI 的大部分優點，并且可以兼容于 CORBA。J2EE 和 EJB 都要求使用 RMI-IIOP 而不是 RMI。盡管如此，理解 RMI 將大大有助于 RMI-IIOP 的理解。所以，即便你的興趣在 RMI-IIOP 或者 EJB，相信本文也會對你很有幫助。另外，如果你現在就對 API 感興趣，那么可以告訴你，RMI 使用 java.rmi 包，而 RMI-IIOP 則既使用 java.rmi 也使用擴展的 javax.rmi 包。
本文的隨后內容將僅針對 Java RMI。
在學習 RMI 之前，我們需要了解一些基礎知識。首先需要了解所謂的分布式對象（Distributed Object）。分布式對象是指一個對象可以被遠程系統所調用。對于 Java 而言，即對象不僅可以被同一虛擬機中的其他客戶程序（Client）調用，也可以被運行于其他虛擬機中的客戶程序調用，甚至可以通過網絡被其他遠程主機之上的客戶程序調用。
下面的圖示說明了客戶程序是如何調用分布式對象的：
從圖上我們可以看到，分布式對象被調用的過程是這樣的：
-
客戶程序調用一個被稱為 Stub （有時譯作存根，為了不產生歧義，本文將使用其英文形式）的客戶端代理對象。該代理對象負責對客戶端隱藏網絡通訊的細節。Stub 知道如何通過網絡套接字（Socket）發送調用，包括如何將調用參數轉換為適當的形式以便傳輸等。
-
Stub 通過網絡將調用傳遞到服務器端，也就是分布對象一端的一個被稱為 Skeleton 的代理對象。同樣，該代理對象負責對分布式對象隱藏網絡通訊的細節。Skeleton 知道如何從網絡套接字（Socket）中接受調用，包括如何將調用參數從網絡傳輸形式轉換為 Java 形式等。
-
Skeleton 將調用傳遞給分布式對象。分布式對象執行相應的調用，之后將返回值傳遞給 Skeleton，進而傳遞到 Stub，最終返回給客戶程序。
這個場景基于一個基本的法則，即行為的定義和行為的具體實現相分離。如圖所示，客戶端代理對象 Stub 和分布式對象都實現了相同的接口，該接口稱為遠程接口（Remote Interface）。正是該接口定義了行為，而分布式對象本身則提供具體的實現。對于 Java RMI 而言，我們用接口（interface）定義行為，用類（class）定義實現。
RMI 的底層架構由三層構成：
-
首先是 Stub/Skeleton 層。該層提供了客戶程序和服務程序彼此交互的接口。
-
然后是遠程引用（Remote Reference）層。這一層相當于在其之上的 Stub/Skeleton 層和在其之下的傳輸協議層之前的中間件，負責處理遠程對象引用的創建和管理。
-
最后是傳輸協議（Transport Protocol） 層。該層提供了數據協議，用以通過線路傳輸客戶程序和遠程對象間的請求和應答。
這些層之間的交互可以參照下面的示意圖：
和其它分布式對象機制一樣，Java RMI 的客戶程序使用客戶端的 Stub 向遠程對象請求方法調用；服務器對象則通過服務器端的 Skeleton 接受請求。我們深入進去，來看看其中的一些細節。
注意: 事實上，在 Java 1.2 之后，RMI 不再需要 Skeleton 對象，而是通過 Java 的反射機制（Reflection）來完成對服務器端的遠程對象的調用。為了便于說明問題，本文以下內容仍然基于 Skeleton 來講解。
當客戶程序調用 Stub 時，Stub 負責將方法的參數轉換為序列化（Serialized）形式，我們使用一個特殊的術語，即編列（Marshal）來指代這個過程。編列的目的是將這些參數轉換為可移植的形式，從而可以通過網絡傳輸到遠程的服務對象一端。不幸的是，這個過程沒有想象中那么簡單。這里我們首先要理解一個經典的問題，即方法調用時，參數究竟是傳值還是傳引用呢？對于 Java RMI 來說，存在四種情況，我們將分別加以說明。
-
對于基本的原始類型（整型，字符型等等），將被自動的序列化，以傳值的方式編列。
-
對于 Java 的對象，如果該對象是可序列化的（實現了 java.io.Serializable 接口），則通過 Java 序列化機制自動地加以序列化，以傳值的方式編列。對象之中包含的原始類型以及所有被該對象引用，且沒有聲明為 transient 的對象也將自動的序列化。當然，這些被引用的對象也必須是可序列化的。
-
絕大多數內建的 Java 對象都是可序列化的。 對于不可序列化的 Java 對象（java.io.File 最典型），或者對象中包含對不可序列化，且沒有聲明為 transient 的其它對象的引用。則編列過程將向客戶程序拋出異常，而宣告失敗。
-
客戶程序可以調用遠程對象，沒有理由禁止調用參數本身也是遠程對象（實現了 java.rmi.Remote 接口的類的實例）。此時，RMI 采用一種模擬的傳引用方式（當然不是傳統意義的傳引用，因為本地對內存的引用到了遠程變得毫無意義），而不是將參數直接編列復制到遠程。這種情況下，交互的雙方發生的戲劇性變化值得我們注意。參數是遠程對象，意味著該參數對象可以遠程調用。當客戶程序指定遠程對象作為參數調用服務器端遠程對象的方法時，RMI 的運行時機制將向服務器端的遠程對象發送作為參數的遠程對象的一個 Stub 對象。這樣服務器端的遠程對象就可以回調（Callback）這個 Stub 對象的方法，進而調用在客戶端的遠程對象的對應方法。通過這種方法，服務器端的遠程對象就可以修改作為參數的客戶端遠程對象的內部狀態，這正是傳統意義的傳引用所具備的特性。是不是有點暈？這里的關鍵是要明白，在分布式環境中，所謂服務器和客戶端都是相對的。被請求的一方就是服務器，而發出請求的一方就是客戶端。
在調用參數的編列過程成功后，客戶端的遠程引用層從 Stub 那里獲得了編列后的參數以及對服務器端遠程對象的遠程引用（參見 java.rmi.server.RemoteRef API）。該層負責將客戶程序的請求依據底層的 RMI 數據傳輸協議轉換為傳輸層請求。在 RMI 中，有多種的可能的傳輸機制，比如點對點（Point-to-Point）以及廣播（Multicast）等。不過，在當前的 JMI 版本中只支持點對點協議，即遠程引用層將生成唯一的傳輸層請求，發往指定的唯一遠程對象（參見 java.rmi.server.UnicastRemoteObject API）。
在服務器端，服務器端的遠程引用層接收傳輸層請求，并將其轉換為對遠程對象的服務器端代理對象 Skeleton 的調用。Skeleton 對象負責將請求轉換為對實際的遠程對象的方法調用。這是通過與編列過程相對的反編列（Unmarshal）過程實現的。所有序列化的參數被轉換為 Java 形式，其中作為參數的遠程對象（實際上發送的是遠程引用）被轉換為服務器端本地的 Stub 對象。
如果方法調用有返回值或者拋出異常，則 Skeleton 負責編列返回值或者異常，通過服務器端的遠程引用層，經傳輸層傳遞給客戶端；相應地，客戶端的遠程引用層和 Stub 負責反編列并最終將結果返回給客戶程序。
整個過程中，可能最讓人迷惑的是遠程引用層。這里只要明白，本地的 Stub 對象是如何產生的，就不難理解遠程引用的意義所在了。遠程引用中包含了其所指向的遠程對象的信息，該遠程引用將用于構造作為本地代理對象的 Stub 對象。構造后，Stub 對象內部將維護該遠程引用。真正在網絡上傳輸的實際上就是這個遠程引用，而不是 Stub 對象。
在 RMI 的基本架構之上，RMI 提供服務與分布式應用程序的一些對象服務，包括對象的命名/注冊（Naming/Registry）服務，遠程對象激活（Activation）服務以及分布式垃圾收集（Distributed Garbage Collection, DGC）。作為入門指南，本文將指介紹其中的命名/注冊服務，因為它是實戰 RMI 所必備的。其它內容請讀者自行參考其它更加深入的資料。
在前一節中，如果你喜歡刨根問底，可能已經注意到，客戶端要調用遠程對象，是通過其代理對象 Stub 完成的，那么 Stub 最早是從哪里得來的呢？RMI 的命名/注冊服務正是解決這一問題的。當服務器端想向客戶端提供基于 RMI 的服務時，它需要將一個或多個遠程對象注冊到本地的 RMI 注冊表中（參見java.rmi.registry.Registry API）。每個對象在注冊時都被指定一個將來用于客戶程序引用該對象的名稱?？蛻舫绦蛲ㄟ^命名服務（參見 java.rmi.Naming API），指定類似 URL 的對象名稱就可以獲得指向遠程對象的遠程引用。在 Naming 中的 lookup() 方法找到遠程對象所在的主機后，它將檢索該主機上的 RMI 注冊表，并請求所需的遠程對象。如果注冊表發現被請求的遠程對象，它將生成一個對該遠程對象的遠程引用，并將其返回給客戶端，客戶端則基于遠程引用生成相應的 Stub 對象，并將引用傳遞給調用者。之后，雙方就可以按照我們前面講過的方式進行交互了。
注意: RMI 命名服務提供的 Naming 類并不是你的唯一選擇。RMI 的注冊表可以與其他命名服務綁定，比如 JNDI，這樣你就可以通過 JNDI 來訪問 RMI 的注冊表了。
理論離不開實踐，理解 RMI 的最好辦法就是通過例子。開發 RMI 的分布式對象的大體過程包括如下幾步：
-
定義遠程接口。這一步是通過擴展 java.rmi.Remote 接口，并定義所需的業務方法實現的。
-
定義遠程接口的實現類。即實現上一步所定義的接口，給出業務方法的具體實現邏輯。
-
編譯遠程接口和實現類，并通過 RMI 編譯器 rmic 基于實現類生成所需的 Stub 和 Skeleton 類。
RMI 中各個組件之間的關系如下面這個示意圖所示：
回憶我們上一節所講的，Stub 和 Skeleton 負責代理客戶和服務器之間的通訊。但我們并不需要自己生成它們，相反，RMI 的編譯器 rmic 可以幫我們基于遠程接口和實現類生成這些類。當客戶端對象通過命名服務向服務器端的 RMI 注冊表請求遠程對象時，RMI 將自動構造對應遠程對象的 Skeleton 實例對象，并通過 Skeleton 對象將遠程引用返回給客戶端。在客戶端，該遠程引用將用于構造 Stub 類的實例對象。之后，Stub 對象和 Skeleton 對象就可以代理客戶對象和遠程對象之間的交互了。
我們的例子展現了一個簡單的應用場景。服務器端部署了一個計算引擎，負責接受來自客戶端的計算任務，在服務器端執行計算任務，并將結果返回給客戶端。客戶端將發送并調用計算引擎的計算任務實際上是計算指定精度的 π 值。
定義遠程接口與非分布式應用中定義接口的方法沒有太多的區別。只要遵守下面兩個要求：
注意: 在 Java 1.2 之前，上面關于拋出異常的要求更嚴格，即必須拋出 java.rmi.RemoteExcption，不允許類似 java.io.IOException 這樣的超類?，F在之所以放寬了這一要求，是希望可以使定義既可以用于遠程對象，也可以用于本地對象的接口變得容易一些（想想 EJB 中的本地接口和遠程接口）。當然，這并沒有使問題好多少，你還是必須聲明異常。不過，一種觀點認為這不是問題，強制聲明異?？梢允归_發人員保持清醒的頭腦，因為遠程對象和本地對象在調用時傳參的語意是不同的。本地對象是傳引用，而遠程對象主要是傳值，這意味對參數內部狀態的修改產生的結果是不同的。
對于第一個要求，java.rmi.Remote 接口實際上沒有任何方法，而只是用作標記接口。RMI 的運行環境依賴該接口判斷對象是否是遠程對象。第二個要求則是因為分布式應用可能發生任何問題，比如網絡問題等等。
例 1
列出了我們的遠程接口定義。該接口只有一個方法：executeTask() 用以執行指定的計算任務，并返回相應的結果。注意，我們用后綴 Remote 表明接口是遠程接口。
例 1. ComputeEngineRemote 遠程接口
package rmitutorial;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface ComputeEngineRemote extends Remote {
public Object executeTask(Task task) throws RemoteException;
}
例 2
列出了計算任務接口的定義。該接口也只有一個方法：execute() 用以執行實際的計算邏輯，并返回結果。注意，該接口不是遠程接口，所以沒有擴展 java.rmi.Remote 接口；其方法也不必拋出 java.rmi.RemoteException 異常。但是，因為它將用作遠程方法的參數，所以擴展了 java.io.Serializable 接口。
例 2. Task 接口
package rmitutorial;
import java.io.Serializable;
public interface Task extends Serializable {
Object execute();
}
接下來，我們將實現前面定義的遠程接口。例 3給出了實現的源代碼。
例 3. ComputeEngine 實現
package rmitutorial;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class ComputeEngine extends UnicastRemoteObject
implements ComputeEngineRemote {
public ComputeEngine() throws RemoteException {
super();
}
public Object executeTask(Task task) throws RemoteException {
return task.execute();
}
}
類 ComputeEngine 實現了之前定義的遠程接口，同時繼承自 java.rmi.server.UnicastRemoteObject 超類。UnicastRemoteObject 類是一個便捷類，它實現了我們前面所講的基于 TCP/IP 的點對點通訊機制。遠程對象都必須從該類擴展（除非你想自己實現幾乎所有 UnicastRemoteObject 的方法）。在我們的實現類的構造函數中，調用了超類的構造函數（當然，即使你不顯式的調用這個構建函數，它也一樣會被調用。這里這樣做，只是為了突出強調這種調用而已）。該構造函數的最重要的意義就是調用 UnicastRemoteObject 類的 exportObject() 方法。導出（Export）對象是指使遠程對象準備就緒，可以接受進來的調用的過程。而這個過程的最重要內容就是建立服務器套接字，監聽特定的端口，等待客戶端的調用請求。
為了讓客戶程序可以找到我們的遠程對象，就需要將我們的遠程對象注冊到 RMI 的注冊表。這個過程有時被稱為"引導"過程（Bootstrap）。我們將為此編寫一個獨立的引導程序負責創建和注冊遠程對象。例 4 給出了引導程序的源代碼。
例 4. 引導程序
package rmitutorial;
import java.rmi.Naming;
import java.rmi.RMISecurityManager;
public class Bootstrap {
public static void main(String[] args) throws Exception {
String name = "ComputeEngine";
ComputeEngine engine = new ComputeEngine();
System.out.println("ComputerEngine exported");
Naming.rebind(name, engine);
System.out.println("ComputeEngine bound");
}
}
可以看到，我們首先創建了一個遠程對象（同時導出了該對象），之后將該對象綁定到 RMI 注冊表中。Naming 的 rebind() 方法接受一個 URL 形式的名字作綁定之用。其完整格式如下：
protocol://host:port/object
其中，協議（Protocol）默認為 rmi；主機名默認為 localhost；端口默認為 1099。注意，JDK 中提供的默認 Naming 實現只支持 rmi 協議。在我們的引導程序里面只給出了對象綁定的名字，而其它部分均使用缺省值。
例 5
給出了我們的客戶端程序。該程序接受兩個參數，分別是遠程對象所在的主機地址和希望獲得的 π 值的精度。
例 5. Client.java
package rmitutorial;
import java.math.BigDecimal;
import java.rmi.Naming;
public class Client {
public static void main(String args[]) throws Exception {
String name = "rmi://" + args[0] + "/ComputeEngine";
ComputeEngineRemote engineRemote =
(ComputeEngineRemote)Naming.lookup(name);
Pi task = new Pi(Integer.parseInt(args[1]));
BigDecimal pi = (BigDecimal)(engineRemote.executeTask(task));
System.out.println(pi);
}
}
例 6. Pi.java
package rmitutorial;
import java.math.*;
public class Pi implements Task {
private static final BigDecimal ZERO =
BigDecimal.valueOf(0);
private static final BigDecimal ONE =
BigDecimal.valueOf(1);
private static final BigDecimal FOUR =
BigDecimal.valueOf(4);
private static final int roundingMode =
BigDecimal.ROUND_HALF_EVEN;
private int digits;
public Pi(int digits) {
this.digits = digits;
}
public Object execute() {
return computePi(digits);
}
public static BigDecimal computePi(int digits) {
int scale = digits + 5;
BigDecimal arctan1_5 = arctan(5, scale);
BigDecimal arctan1_239 = arctan(239, scale);
BigDecimal pi = arctan1_5.multiply(FOUR).subtract(
arctan1_239).multiply(FOUR);
return pi.setScale(digits,
BigDecimal.ROUND_HALF_UP);
}
public static BigDecimal arctan(int inverseX,
int scale) {
BigDecimal result, numer, term;
BigDecimal invX = BigDecimal.valueOf(inverseX);
BigDecimal invX2 =
BigDecimal.valueOf(inverseX * inverseX);
numer = ONE.divide(invX, scale, roundingMode);
result = numer;
int i = 1;
do {
numer =
numer.divide(invX2, scale, roundingMode);
int denom = 2 * i + 1;
term =
numer.divide(BigDecimal.valueOf(denom),
scale, roundingMode);
if ((i % 2) != 0) {
result = result.subtract(term);
} else {
result = result.add(term);
}
i++;
} while (term.compareTo(ZERO) != 0);
return result;
}
}
編譯我們的示例程序和編譯其它非分布式的應用沒什么區別。只是編譯之后，需要使用 RMI 編譯器，即 rmic 生成所需 Stub 和 Skeleton 實現。使用 rmic 的方式是將我們的遠程對象的實現類（不是遠程接口）的全類名作為參數來運行 rmic 命令。參考下面的示例：
E:\classes\rmic rmitutorial.ComputeEngine
編譯之后將生成 rmitutorial.ComputeEngine_Skel 和 rmitutorial.ComputeEngine_Stub 兩個類。
遠程對象的引用通常是通過 RMI 的注冊表服務以及 java.rmi.Naming 接口獲得的。遠程對象需要導出（注冊）相應的遠程引用到注冊表服務，之后注冊表服務就可以監聽并服務于客戶端對遠程對象引用的請求。標準的 Sun Java SDK 提供了一個簡單的 RMI 注冊表服務程序，即 rmiregistry 用于監聽特定的端口，等待遠程對象的注冊，以及客戶端對這些遠程對象引用的檢索請求。
在運行我們的示例程序之前，首先要啟動 RMI 的注冊表服務。這個過程很簡單，只要直接運行 rmiregistry 命令即可。缺省的情況下，該服務將監聽 1099 端口。如果需要指定其它的監聽端口，可以在命令行指定希望監聽的端口（如果你指定了其它端口，需要修改示例程序以適應環境）。如果希望該程序在后臺運行，在 Unix 上可以以如下方式運行（當然，可以缺省端口參數）：
$ rmiregistry 1099 &
在 Windows 操作系統中可以這樣運行：
C:\> start rmiregistry 1099
我們的 rmitutorial.Bootstrap 類將用于啟動遠程對象，并將其綁定在 RMI 注冊表中。運行該類后，遠程對象也將進入監聽狀態，等待來自客戶端的方法調用請求。
$ java rmitutorial.Bootstrap
ComputeEngine exported
ComputeEngine bound
啟動遠程對象后，打開另一個命令行窗口，運行客戶端。命令行的第一個參數為 RMI 注冊表的地址，第二個參數為期望的 π 值精度。參考下面的示例：
$ java rmitutorial.Client localhost 50
3.14159265358979323846264338327950288419716939937511
在演示示例程序時，我們實際上是在同一主機上運行的服務器和客戶端，并且無論是服務器和客戶端所需的類都在相同的類路徑上，可以同時被服務器和客戶端所訪問。這忽略了 Java RMI 的一個重要細節，即動態類裝載。因為 RMI 的特性（包括其它幾個特性）并不適用于 J2EE 的 RMI-IIOP 和 EJB 技術，所以，本文將不作詳細介紹，請讀者自行參考本文給出的參考資料。不過，為了讓好奇的讀者不至于過分失望，這里簡單介紹一下動態類裝載的基本思想。
RMI 運行時系統采用動態類裝載機制來裝載分布式應用所需的類。如果你可以直接訪問應用所涉及的所有包括服務器端客戶端在內的主機，并且可以把分布式應用所需的所有類都安裝在每個主機的 CLASSPATH 中（上面的示例就是極端情況，所有的東西都在本地主機），那么你完全不必關心 RMI 類裝載的細節。顯然，既然是分布式應用，情況往往正相反。對于 RMI 應用，客戶端需要裝載客戶端自身所需的類，將要調用的遠程對象的遠程接口類以及對應的 Stub 類；服務器端則要裝載遠程對象的實現類以及對應的 Skeleton 類（Java 1.2 之后不需要 Skeleton 類）。RMI 在處理遠程調用涉及的遠程引用，參數以及返回值時，可以將一個指定的 URL 編碼到流中。交互的另一端可以通過 該 URL 獲得處理這些對象所需的類文件。這一點類似于 Applet 中的 CODEBASE 的概念，交互的兩端通過 HTTP 服務器發布各自控制的類，允許交互的另一端動態下載這些類。以我們的示例為例，客戶端不必部署 ComputeEngine_Stub 的類文件，而可以通過服務器端的 HTTP 服務器獲得類文件。同樣，服務器端也不需要客戶端實現的定制任務 Pi 的類文件。
注意，這種動態類裝載將需要交互的兩端加載定制的安全管理器（參見 java.rmi.RMISecurityManager API），以及對應的策略文件。
-
The Java? Tutorial Trail:RMI
-
David Flanagan, Jim Farley, William Crawford and Kris Magnusson, 1999, ISBN 1-56592-483-5E, O'Reilly, Java? Enterprise in a Nutshell
-
Ed Roman, Scott Ambler and Tyler Jewell 2002, ISBN 0-471-41711-4, John Wiley &Sons, Inc., Matering Enterprise JavaBeans? , Second Edition