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