【IT168 技术文档】摘要：本文通过实践案例向读者介绍了Java RMI（Remote Method Invocation，远程方法调用）技术的框架，部署要点以及扩展。

   1  引言

   首先开发人员应该清楚的是，Java RMI技术是伴随着分布式处理的需求而诞生出来，虽然从RMI的字面翻译没有看出来。在这一点上DCOM（Distributed Object Component Model，分布式对象组件模型，RPC就是通过DCOM机制来实现）似乎表现得更直白一些。分布式处理的构架就决定了无论是RMI还是RPC都至少是C/S模型，即Server作为对象（远程对象或者COM对象）提供者，而Client端作为使用者。所以从出发点上，如果具有一定Windows开发经验的话，我们就不应该把Java RMI技术看得比较晦涩难懂。

   同样的，RMI也像DCOM一样，Server端需要先注册服务，而Client端调用远程方法之前需要查找已经注册的服务，由此获得通信端口和传递参数等后续工作。所以，如果开发人员熟悉DCOM机制和RPC开发的话，那么就已经可以大致上知道Java RMI是如何开展工作了。

   不同的是，Java平台与生俱来的安全性和良好的扩展性就决定了Java RMI比RPC更加安全和灵活，例如Java RMI可以穿透防火墙，而DCOM机制则不能；Java RMI可以支持嵌入更高级的连接应用，例如结合JNDI，XML技术等，而DCOM机制只有望洋兴叹，从而MS逐步转入到了.NET模型。

   以下笔者将从大家都比较熟悉的DCOM机制的目标着手，通过RMI来实现分布式处理，来将读者逐步引入到RMI技术的应用深处。

   2  部署框架

   实际应用中，我们可以将RMI部署为2层到多层应用。本实例中，我们将RMI部署为3层：客户层─应用层─后台。按照设计模块将RMI部署划分为4个包：Client（客户端），Check（检查，调试），Application（应用层，RMI服务端）和Server（后台服务端，例如：数据库服务器，文件目录服务器等）。以下是各层和包的内容划分：

 
图1：RMI部署框架示意图

   对于上述框架，请注意以下3个容易忽视的点：

（1）客户端和服务器必须同步共享远程接口定义和存根，特别是客户端和服务器端在不同主机的情形下，必须将更新后的远程接口定义和存根同时分发到客户端和服务器端。

（2）当客户端和服务器端在不同主机时要考虑部署策略文件（安全因素）。

（3）任何时候都不要考虑将过多的“权力”下放给客户端，而是尽可能将业务逻辑地放在应用层。这个问题往往产生在为了方便客户端使用服务端的资源。

3  实现步骤

   通过上述的部署框架，我们大致可以做到如何部署自己的RMI应用体系，而不是一锅粥地堆放在一起。接下来，我们还是简要地过一遍RMI应用的实现并强调部分要点。

（1）定义远程接口（继承Remote接口即可）；
（2）定义应用程序服务执行类，该类必须执行远程定义接口且继承UnicastRemoteObject；
（3）定义应用程序服务端程序入口（main函数），绑定远程对象
（4）使用rmic工具生成执行类的存根，程序员并不直接使用该类
（5）启动RMI注册表工具（rmiregistry）
（6）启动应用程序服务器
（7）检查服务注册
（8）将Server目录中远程定义接口和存根复制到Client目录
（9）定义客户端程序入口（main函数），检索远程接口，实现接口调用

   如果顺利，通过上述9个步骤就可以实现一个RMI应用样例。但是，如果需要对该样例进行调整，例如添加部分功能等，那么就必须注意以下3个要点：

（1）更新执行类后要及时更新存根类，并分发最新的存根类到Client目录，否则当执行的时候可能就会报告存放相关的异常错误；

（2）更新远程接口定义或者执行类之后必须重新启动RMI注册表工具和应用服务，否则客户端调用的接口还是旧的内容。

（3）远程方法返回参数为非远程对象时，必须保证为序列化对象，否则无法通过序列化机制完成对象拷贝。这一点，会在下文中进行详细的讨论，因为很多时候你都无法确认你将要返回的类型是否“百分之百”的支持序列化。