RMI 使用感想

RMI作为将j2ee企业开发中分布式环境的一种方案，在很多方面都得以应用，今天试了一个很小的实验，总体感觉如下。

   功能方面，可以实现异构环境下不同主机之间的不同jvm上运行的java对象之间的相互调用，主要涉及到三方，客户端，服务器端和注册机器端。

  通过继承Remot接口且抛出一些规定的异常得到一个自己的原创接口，该接口用来在服务器端和客户端调用的一种规约，规定了客户端可以调用服务器端对象的哪些方法，服务器端通过一个类来实现该接口定义来提供服务，其实是一种面向接口编程的思想了。 在服务器端，还需要一个Server类（名字可以随意），其主要完成服务器端对象的注册，通过注册将生成的一个服务器对象绑定到一个rmi形式的url上，例如:

   RemtImp rmt=new RemtImp();
 Naming.rebind("rmi://localhost/rem",rmt);

 

 

 客户端代码中通过lookup方法来获得注册的服务器端对象，然后将其转化成协约接口，通过该接口调用其业务方法来完成一定的功能。

   从上面看到， 服务器端需要保留接口类， 服务器端实现类，一个Server类（名字可以随意，主要用来完成注册），和sketon类。客户端需要有接口类，stub类和客户类，其中的sketon类和stub类是通过" rmic  服务器端实现类 " 来自动生成的。 通过执行: javac 服务器端实现类 和javac 客户端类 就可以 编译得到需要的所有的class文件，然后按照服务器端和客户端分别将得到的class类部署。

   运行rmiregistry命令启动rmi的注册，然后在另一个dos窗口执行java 服务器端Server类 来注册服务器端的对象。 下一步就可以在客户端通过运行java 客户端类通过rmi来调用服务器端的方法了。 

   看起来很简单，其实在真正做的过程中会发现很多问题，至少我是头痛过，现在写下来，也是为了参考。我是在将rmi移植到jsp的web应用中的时候遇到的一些问题，不过这些问题在一般java 应用中也是一样的道理。

   首先的问题是， java.lang.ClassNotFoundException: XXX.GetMessageImpl_Stub (no security manager: RMI class loader disabled)， 这个问题很不好查。 主要还是在客户端部署的问题。因为产生了Stub class后， 这个class文件究竟应该放在哪里才能让jsp页面上的java代码能找到呢？ 应该放到classpath下，最后，还是报错。 原因是不仅仅要放在classpath下，而且还要按照与服务器上的包层次一致， 就是说， 在编译这个类的时候，如果是在com.cn.*这样的包层次下的话，那么这个stub类文件一定要放在tomcat服务器上的web应用的WEB-INF/classes/com/cn这个目录下，这是因为在编译class文件的时候，这个class文件内部已经包含了package com.cn;这样的内容，如果在部署的时候，不严格按照这个目录部署的话，服务器就会找不到。 接口的类文件也是一样的道理，也需要按照包层次部署到相应的目录层次下面去。

 

还有一个要非常注意的地方，就是服务器端和客户端的接口类都是由相同的java文件编译得到的类文件，所以必然具有相同的包层次结构，在部署的时候，客户端的接口类的类文件必须严格按照该包结构层次部署，否则就会出现：Java RMI ClassCastException  的异常了。

  最后，说明的是，通过rmi可以很方便的实现不同主机上的jvm对象的调用问题，它相比rpc的优势就是它是面向对象的方法调用，而rpc则是面向过程的。

   同样在web应用中也可以通过在jsp页面或者后台java类中通过rmi来调用远程主机jvm上的对象的方法，不过需要通过rmiregistry的中介来实现，而且一旦服务器对象被注册后，即使该服务器对象的类文件被重新编译了， 最新的修改也不会立即被客户端访问到，除非重新注册一次服务器端的那个对象。