74.JAVA编程思想——远程方法
为通过网络执行其他机器上的代码,传统的方法不仅难以学习和掌握,也极易出错。思考这个问题最佳的方式是:某些对象正好位于另一台机器,我们可向它们发送一条消息,并获得返回结果,就象那些对象位于自己的本地机器一样。Java 1.1 的“远程方法调用”(RMI)采用的正是这种抽象。将引导大家经历一些必要的步骤,创建自己的RMI 对象。
RMI 对接口有着强烈的依赖。在需要创建一个远程对象的时候,我们通过传递一个接口来隐藏基层的实施细节。所以客户得到远程对象的一个句柄时,它们真正得到的是接口句柄。这个句柄正好同一些本地的根代码连接,由后者负责通过网络通信。但我们并不关心这些事情,只需通过自己的接口句柄发送消息即可。
创建一个远程接口时,必须遵守下列规则:
(1) 远程接口必须为public 属性(不能有“包访问”;也就是说,它不能是“友好的”)。否则,一旦客户试图装载一个实现了远程接口的远程对象,就会得到一个错误。
(2) 远程接口必须扩展接口java.rmi.Remote。
(3) 除与应用程序本身有关的违例之外,远程接口中的每个方法都必须在自己的throws 从句中声明java.rmi.RemoteException。
(4) 作为参数或返回值传递的一个远程对象(不管是直接的,还是在本地对象中嵌入)必须声明为远程接口,不可声明为实施类。
下面是一个简单的远程接口示例,它代表的是一个精确计时服务:
import java.rmi.*;
interface PerfectTimeI extends Remote {
long getPerfectTime() throws RemoteException;
}/// :~
它表面上与其他接口是类似的,只是对Remote 进行了扩展,而且它的所有方法都会“掷”出
RemoteException(远程违例)。记住接口和它所有的方法都是public 的。
服务器必须包含一个扩展了UnicastRemoteObject 的类,并实现远程接口。这个类也可以含有附加的方法,但客户只能使用远程接口中的方法。这是显然的,因为客户得到的只是指向接口的一个句柄,而非实现它的那个类。
必须为远程对象明确定义构建器,即使只准备定义一个默认构建器,用它调用基础类构建器。必须把它明确地编写出来,因为它必须“掷”出RemoteException 违例。
下面列出远程接口PerfectTime 的实施过程:
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
import java.net.*;
public class PerfectTime extends UnicastRemoteObjectimplementsPerfectTimeI {
//Implementation of the interface:
public longgetPerfectTime() throws RemoteException {
return System.currentTimeMillis();
}
// Mustimplement constructor to throw
//RemoteException:
public PerfectTime() throws RemoteException {
// super(); // Called automatically
}
//Registration for RMI serving:
public staticvoidmain(String[] args){
System.setSecurityManager(new RMISecurityManager());
try {
PerfectTime pt = new PerfectTime();
Naming.bind("//toad: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 远程对象注册表注册至少一个远程对象。一个远程对象拥有的方法可生成指向其他远程对象的句柄。这样一来,客户只需到注册表里访问一次,得到第一个远程对象即可。
1. 设置注册表
在这儿,大家可看到对静态方法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 环境中调查自己机器的名字,可进入控制面板,选择“网络”,选择“标识”卡片,其中列出了计算机的名字。就我自己的情况来说,我的机器叫作“toad”。似乎大写形式会被忽略。
(2) 除非计算机有一个活动的TCP/IP连接,否则RMI 不能工作,即使所有组件都只需要在本地机器里互相通信。这意味着在试图运行程序之前,必须连接到自己的ISP(因特网服务提供者),否则会得到一些含义模糊的违例消息。
考虑到这些因素,bind()命令变成了下面这个样子:
Naming.bind("//toad:2005/PerfectTime",pt);
若使用默认端口1099,就没有必要指定一个端口,所以可以使用:
Naming.bind("//toad /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()。
若编译和运行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)。现在,我们已准备好让服务器与客户互相沟通了。
RMI 全部的宗旨就是尽可能简化远程对象的使用。我们在客户程序中要做的唯一一件额外的事情就是查找并从服务器取回远程接口。自此以后,剩下的事情就是普通的Java 编程:将消息发给对象。下面是使用PerfectTime 的程序:
import java.rmi.*;
import java.rmi.registry.*;
public class DisplayPerfectTime {
public staticvoidmain(String[] args){
System.setSecurityManager(new RMISecurityManager());
try {
PerfectTimeI t = (PerfectTimeI)Naming.lookup("//127.0.0.1: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 违例)。
RMI 只是一种创建特殊对象的方式,它创建的对象可通过网络发布。它最大的优点就是提供了一种“纯Java”方案,但假如已经有许多用其他语言编写的代码,则RMI 可能无法满足我们的要求。目前,两种最具竞争力的替选方案是微软的DCOM(根据微软的计划,它最终会移植到除Windows 以外的其他平台)以及CORBA。CORBA 自Java1.1 便开始支持,是一种全新设计的概念,面向跨平台应用。在由Orfali 和Harkey编著的《Client/Server Programming withJava and CORBA》一书中(John Wiley&Sons 1997 年出版),大家可获得对Java 中的分布式对象的全面介绍(该书似乎对CORBA 似乎有些偏见)。为CORBA 赋予一个较公正的对待的一本书是由Andreas Vogel 和Keith Duddy 编写的《Java Programming with CORBA》,JohnWiley&Sons 于1997 年出版。
还有其他许多涉及连网的概念没。Java 也为URL 提供了相当全面的支持,包括为因特网上不同类型的客户提供协议控制器等等。除此以外,一种正在逐步流行的技术叫作Servlet Server。它是一种因特网服务器应用,通过Java 控制客户请求,而非使用以前那种速度很慢、且相当麻烦的CGI(通用网关接口)协议。这意味着为了在服务器那一端提供服务,我们可以用Java 编程,不必使用自己不熟悉的其他语言。由于Java 具有优秀的移植能力,所以不必关心具体容纳这个服务器是什么平台。
所有这些以及其他特性都在《Java Network Programming》一书中得到了详细讲述。该书由ElliotteRustyHarold 编著,O'Reilly 于1997 年出版。