15.8 远程方法
15.8 远程方法
为通过网络执行其他机器上的代码，传统的方法不仅难以学习和掌握，也极易出错。思考这个问题最佳的方式是：某些对象正好位于另一台机器，我们可向它们发送一条消息，并获得返回结果，就象那些对象位于自己的本地机器一样。Java 1.1 的“远程方法调用”（RMI）采用的正是这种抽象。本节将引导大家经历一些必要的步骤，创建自己的 RMI 对象。
15.8.1 远程接口概念
RMI 对接口有着强烈的依赖。在需要创建一个远程对象的时候，我们通过传递一个接口来隐藏基层的实施细节。所以客户得到远程对象的一个指针时，它们真正得到的是接口指针。这个指针正好同一些本地的根代码连接，由后者负责通过网络通信。但我们并不关心这些事情，只需通过自己的接口指针发送消息即可。
创建一个远程接口时，必须遵守下列规则：
(1) 远程接口必须为 public 属性（不能有“包访问”；也就是说，它不能是“友好的”）。否则，一旦客户试图装载一个实现了远程接口的远程对象，就会得到一个错误。
(2) 远程接口必须扩展接口 java.rmi.Remote。
(3) 除与应用程序本身有关的异常之外，远程接口中的每个方法都必须在自己的 throws 从句中声明 java.rmi.RemoteException。
(4) 作为参数或返回值传递的一个远程对象（不管是直接的，还是在本地对象中嵌入）必须声明为远程接口，不可声明为实施类。
下面是一个简单的远程接口示例，它代表的是一个精确计时服务：
//: PerfectTimeI.java
// The PerfectTime remote interface
package c15.ptime;
import java.rmi.*;
interface PerfectTimeI extends Remote {
long getPerfectTime() throws RemoteException;
} ///:~
它表面上与其他接口是类似的，只是对 Remote 进行了扩展，而且它的所有方法都会“掷”出 RemoteException（远程异常）。记住接口和它所有的方法都是 public 的。
15.8.2 远程接口的实施
服务器必须包含一个扩展了 UnicastRemoteObject 的类，并实现远程接口。这个类也可以含有附加的方法，但客户只能使用远程接口中的方法。这是显然的，因为客户得到的只是指向接口的一个指针，而非实现它的那个类。
必须为远程对象明确定义构造器，即使只准备定义一个默认构造器，用它调用基础类构造器。必须把它明确地编写出来，因为它必须“掷”出 RemoteException 异常。
下面列出远程接口 PerfectTime 的实施过程：
//: PerfectTime.java
// The implementation of the PerfectTime
// remote object
package c15.ptime;
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
import java.net.*;
public class PerfectTime
extends UnicastRemoteObject
implements PerfectTimeI {
// Implementation of the interface:
public long getPerfectTime()
throws RemoteException {
return System.currentTimeMillis();
}
// Must implement constructor to throw
// RemoteException:
public PerfectTime() throws RemoteException {
// super(); // Called automatically
}
// Registration for RMI serving:
public static void main(String[] args) {
System.setSecurityManager(
new RMISecurityManager());
try {
PerfectTime pt = new PerfectTime();
Naming.bind(
"//colossus:2005/PerfectTime", pt);
System.out.println("Ready to do time");
} catch(Exception e) {
e.printStackTrace();
}
}
} ///:~
在这里，main()控制着设置服务器的全部细节。保存 RMI 对象时，必须在程序的某个地方采取下述操作：
(1) 创建和安装一个安全管理器，令其支持 RMI。作为 Java 发行包的一部分，适用于 RMI 唯一一个是 RMISecurityManager。
(2) 创建远程对象的一个或多个实例。在这里，大家可看到创建的是 PerfectTime 对象。
(3) 向 RMI 远程对象注册表注册至少一个远程对象。一个远程对象拥有的方法可生成指向其他远程对象的指针。这样一来，客户只需到注册表里访问一次，得到第一个远程对象即可。
- 设置注册表
在这儿，大家可看到对静态方法 Naming.bind()的一个调用。然而，这个调用要求注册表作为计算机上的一个独立进程运行。注册表服务器的名字是 rmiregistry。在 32 位 Windows 环境中，可使用：
start rmiregistry
令其在后台运行。在 Unix 中，使用：
rmiregistry &
和许多网络程序一样，rmiregistry 位于机器启动它所在的某个 IP 地址处，但它也必须监视一个端口。如果象上面那样调用 rmiregistry，不使用参数，注册表的端口就会默认为 1099。若希望它位于其他某个端口，只需在命令行添加一个参数，指定那个端口编号即可。对这个例子来说，端口将位于 2005，所以 rmiregistry 应该象下面这样启动（对于 32 位 Windows）：
start rmiregistry 2005
对于 Unix，则使用下述命令：
rmiregistry 2005 &
与端口有关的信息必须传送给 bind()命令，同时传送的还有注册表所在的那台机器的 IP 地址。但假若我们想在本地测试 RMI 程序，就象本章的网络程序一直测试的那样，这样做就会带来问题。在 JDK 1.1.1 版本中，存在着下述两方面的问题（注释 ⑦）：
(1) localhost 不能随 RMI 工作。所以为了在单独一台机器上完成对 RMI 的测试，必须提供机器的名字。为了在 32 位 Windows 环境中调查自己机器的名字，可进入控制面板，选择“网络”，选择“标识”卡片，其中列出了计算机的名字。就我自己的情况来说，我的机器叫作“Colossus”（因为我用几个大容量的硬盘保存各种不同的开发系统——Clossus 是“巨人”的意思）。似乎大写形式会被忽略。
(2) 除非计算机有一个活动的 TCP/IP 连接，否则 RMI 不能工作，即使所有组件都只需要在本地机器里互相通信。这意味着在试图运行程序之前，必须连接到自己的 ISP（因特网服务提供者），否则会得到一些含义模糊的异常消息。
⑦：为找出这些信息，我不知损伤了多少个脑细胞。
考虑到这些因素，bind()命令变成了下面这个样子：
Naming.bind("//colossus:2005/PerfectTime", pt);
若使用默认端口 1099，就没有必要指定一个端口，所以可以使用：
Naming.bind("//colossus/PerfectTime", pt);
在 JDK 未来的版本中（1.1 之后），一旦改正了 localhost 的问题，就能正常地进行本地测试，去掉 IP 地址，只使用标识符： Naming.bind(“PerfectTime”, pt);
服务名是任意的；它在这里正好为 PerfectTime，和类名一样，但你可以根据情况任意修改。最重要的是确保它在注册表里是个独一无二的名字，以便客户正常地获取远程对象。若这个名字已在注册表里了，就会得到一个 AlreadyBoundException 异常。为防止这个问题，可考虑坚持使用 rebind()，放弃 bind()。这是由于 rebind()要么会添加一个新条目，要么将同名的条目替换掉。 尽管 main()退出，我们的对象已经创建并注册，所以会由注册表一直保持活动状态，等候客户到达并发出对它的请求。只要 rmiregistry 处于运行状态，而且我们没有为名字调用 Naming.unbind()方法，对象就肯定位于那个地方。考虑到这个原因，在我们设计自己的代码时，需要先关闭 rmiregistry，并在编译远程对象的一个新版本时重新启动它。
并不一定要将 rmiregistry 作为一个外部进程启动。若事前知道自己的是要求用以注册表的唯一一个应用，就可在程序内部启动它，使用下述代码：
LocateRegistry.createRegistry(2005);
和前面一样，2005 代表我们在这个例子里选用的端口号。这等价于在命令行执行 rmiregistry 2005。但在设计 RMI 代码时，这种做法往往显得更加方便，因为它取消了启动和中止注册表所需的额外步骤。一旦执行完这个代码，就可象以前一样使用 Naming 进行“绑定”——bind()。
15.8.3 创建根与干
若编译和运行 PerfectTime.java，即使 rmiregistry 正确运行，它也无法工作。这是由于 RMI 的框架尚未就位。首先必须创建根和干，以便提供网络连接操作，并使我们将远程对象伪装成自己机器内的某个本地对象。
所有这些幕后的工作都是相当复杂的。我们从远程对象传入、传出的任何对象都必须“implement Serializable”（如果想传递 远程引用，而非整个对象，对象的参数就可以“implement Remote”）。因此可以想象，当根和干通过网络“汇集”所有参数并返回结果的时候，会自动进行序列化以及数据的重新装配。幸运的是，我们根本没必要了解这些方面的任何细节，但根和干却是必须创建的。一个简单的过程如下：在编译好的代码中调用 rmic，它会创建必需的一些文件。所以唯一要做的事情就是为编译过程新添一个步骤。
然而，rmic 工具与特定的包和类路径有很大的关联。PerfectTime.java 位于包 c15.Ptime 中，即使我们调用与 PerfectTime.class 同一目录内的 rmic，rmic 都无法找到文件。这是由于它搜索的是类路径。因此，我们必须同时指定类路径，就象下面这样：
rmic c15.PTime.PerfectTime
执行这个命令时，并不一定非要在包含了 PerfectTime.class 的目录中，但结果会置于当前目录。 若 rmic 成功运行，目录里就会多出两个新类：
PerfectTime_Stub.class
PerfectTime_Skel.class
它们分别对应根（Stub）和干（Skeleton）。现在，我们已准备好让服务器与客户互相沟通了。
15.8.4 使用远程对象
RMI 全部的宗旨就是尽可能简化远程对象的使用。我们在客户程序中要做的唯一一件额外的事情就是查找并从服务器取回远程接口。自此以后，剩下的事情就是普通的 Java 编程：将消息发给对象。下面是使用 PerfectTime 的程序：
//: DisplayPerfectTime.java
// Uses remote object PerfectTime
package c15.ptime;
import java.rmi.*;
import java.rmi.registry.*;
public class DisplayPerfectTime {
public static void main(String[] args) {
System.setSecurityManager(
new RMISecurityManager());
try {
PerfectTimeI t =
(PerfectTimeI)Naming.lookup(
"//colossus:2005/PerfectTime");
for(int i = 0; i < 10; i++)
System.out.println("Perfect time = " +
t.getPerfectTime());
} catch(Exception e) {
e.printStackTrace();
}
}
} ///:~
ID 字串与那个用 Naming 注册对象的那个字串是相同的，第一部分指出了 URL 和端口号。由于我们准备使用一个 URL，所以也可以指定因特网上的一台机器。
从 Naming.lookup()返回的必须造型到远程接口，而不是到类。若换用类，会得到一个异常提示。 在下述方法调用中：
t.getPerfectTime( )
我们可看到一旦获得远程对象的指针，用它进行的编程与用本地对象的编程是非常相似（仅有一个区别：远程方法会“掷”出一个 RemoteException 异常）。
15.8.5 RMI 的替选方案
RMI 只是一种创建特殊对象的方式，它创建的对象可通过网络发布。它最大的优点就是提供了一种“纯 Java”方案，但假如已经有许多用其他语言编写的代码，则 RMI 可能无法满足我们的要求。目前，两种最具竞争力的替选方案是微软的 DCOM（根据微软的计划，它最终会移植到除 Windows 以外的其他平台）以及 CORBA。CORBA 自 Java 1.1 便开始支持，是一种全新设计的概念，面向跨平台应用。在由 Orfali 和 Harkey 编著的《Client/Server Programming with Java and CORBA》一书中（John Wiley&Sons 1997 年出版），大家可获得对 Java 中的分布式对象的全面介绍（该书似乎对 CORBA 似乎有些偏见）。为 CORBA 赋予一个较公正的对待的一本书是由 Andreas Vogel 和 Keith Duddy 编写的《Java Programming with CORBA》，John Wiley&Sons 于 1997 年出版。