2. 技术人生
    3. Java RMI实现代码动态下载

    Java RMI实现代码动态下载

    技术2022-05-12  14

     

    SiteFrom：http://www.linux521.com/2009/java/200904/1427.html

    摘要：本译文将向你介绍JavaTM RMI动态类文件下载的应用，学习完本文，你将会对JavaTM RMI有进一步的认识。希望你能参考我的上一篇译文：开始学习Java RMI，远程方法调用－基础篇。

    1.1. 1.概要

    Java平台一个重要的优点就是可以动态的从一个给定的URL下载Java软件到一个正在运行JVM的独立进程中，该进程通常位于一个不同物理系统中。这样可以让一个远程系统运行一个程序，例如一个Applet，它从来没有被安装到本地的存储介质上。在该文档的前几部分，我们先讨论Applet的codebase，以帮助我们更好的介绍有关Java RMI的codebase.

    举例来说，一个运行在浏览器中的虚拟机，可以把java.applet.Applet的子类和其相关类的字节码下载下来（到本地）。运行该浏览器的系统以前从没有运行过该Applet，也没有在本地安装。一旦所有的类从服务端下载完成，浏览器借助本地资源就开始运行这个Applet程序。

    Java RMI正是采用了这个优点，下载、运行这些从来没有在本地安装过的类。调用Java RMI的API的虚拟机，不仅仅像那些浏览器中，能够下载任意Java类文件，其中含有那些特定Java RMI存根类，它使借助服务器资源的远程调用的执行成为可能。

    Codebase观点源于Java程序语言的ClassLoaders的应用。当一个Java程序使用一个ClassLoader时，那么它需要知道它被允许到那里调用类。通常，一个类调用者和HTTP Server一起使用，Server为Java平台应用提供编译过的类。很可能，你提到第一对有关ClassLoader/codebase就是AppletClassLoader和作为HTML标签<applet>的“codebase”属性。本文档假设你有些Java RMI编程经验，同时写过一些含有applet标签的HTML文件。例如，在HTML源文件中（applet标签）将含有一些类似下面的代码：

    <applet height=100 width=100 codebase="myclasses/" code="My.class"> <param name="ticker"> </applet>

    1.2. 什么是codebase

    类代码址可以为一个源文件，或是一个目录，虚拟机可以由此加载类。举个例子来说，如果你邀请一个朋友到家吃晚饭，你需要告诉你朋友你的居住方向，以便你的朋友能够确定你家的位置。同样，你可以把代码库址（Codebase）看作一个你指给JVM的方向，让JVM能够找到它[可能是远程]需要的类。

    你可以把你的classpath看作为是“本地代码库址”，因为它是一系列调用本地代码类目录。当基于本地调用类时，你的classpath环境变量是（JVM的）参照。CLasspath变量可以设定为一个相对，绝对目录或是类文件压缩包。倘若CLASSPATH是一种“本地代码库址”，那么Applets和远程对象使用的codebase也可以认为是一种“远程代码库址”。

    1.3. 工作原理

    1.3.1. Applets如何使用代码库址（codebase）

    为了能和Applet交互，这个applet和其运行中需要的任何类必须能够被客户端访问。虽然applets也可以通过“ftp://”或是“file:///”地址访问，但是它经常是通过Web服务访问。

    客户端浏览器请求的一个applet的类在CLASSPATH中无法找到；通过HTTP，applet（和它需要其他类）从服务端下载到客户端；在客户端执行applet；

    图1 下载Applets的过程

    <applet>标签含有的代码库址（codebase）通常是HTML页面URL的相对地址。

    1.3.2. Java RMI如何使用代码库址（codebase）

    使用Java RMI，应用程序能够创建出远程对象，该对象接受从客户端中JVM方法调用。为了能让客户端调用远程对象中的方法，客户端必须采用一种机制来和远程对象交流。Java RMI使用了一个叫做存根的特殊类，它能够被下载到客户端和远程对象的交流（进行方法的调用），而不是使用（专用）程序使客户端同远程对象的方法进行对话。java.rmi.server.codebase属性代表了一个或是多个URL地址，从该地址那些存根类（和存根需要的其他类）能够被下载。

    像applet，那些要进行远程方法调用的类也要从“file:///”地址下载，但是也像applet，一个“file:///”地址通常要求客户端和服务端位于同样的物理主机上，除非URL使用其他的文件系统，像NFS，这样才能变得有效。

    通常，那些被用来进行远程方法调用的类，都是通过网络资源访问的，像是HTTP或是FTP服务器。

    图2 下载Java RMI存根类

     

    1）                远程对象代码库址（codebase）是通过在远程对象服务端设定java.rmi.server.codebase属性指定的。在Java RMI注册表的帮助下，Java RMI服务端注册了一个远程对象，并绑定了一个名字。服务端JVM中代码库址（codebase）设定->给在Java RMI注册表中的远程对象引用提供了注解。

    2）                Java RMI客户端请求一个（已知）命名的远程对象的引用。客户端使用该引用（远程对象的存根实例）进行对远程对象的方法调用。

    3）                Java RMI注册表向请求的类返回一个引用（存根实例）。客户端会优先于codebase在本地的classpath中寻找存根类，如果发现了，那么它就会在本地调用该类。然而，如果在本地的classpath找不到该stub的存根类，客户端就会试着从远程对象代码库址（codebase）中检索该类。

    4）                客户端从代码库址（codebase）请求类。客户端使用的代码库址（codebase）就是存根实例注解的URL，它是在存根类被注册表加载时注解的。回到第一步1，为导出对象的存根做注解，然后随着绑定的名字被注册到注册表中。

    5）                定义的存根类（和其需要的其他类）被下载到客户端。注意：第4和5是相同的步骤，当远程对象被一个名字绑定到注册表中时，注册表就开始调用该远程对象类。当注册表试着调用远程对象的存根类时，从代码库址（codebase）中，它和远程对象一起请求该类的定义。

    6）                现在客户端已经具备了调用远程对象方法的所有条件。存根（在这过程中）像一个服务端的远程对象的代理一样；不像applet使用代码库址（codebase）运行代码在本地的虚拟机中，Java RMI客户端使用远程的代码库址（codebase）运行代码在另一个，可能是远程JVM中。

    如图3所示：

    图3 Java RMI 客户端远程方法调用

    1.4. 在Java RMI中利用codebase属性，实现非存根（sub）类的下载

    除了下载存根类（stub）和其辅助类到客户端，java.rmi.server.codebase属性还被用来指定其他的，不仅仅是stub类的下载地址。

    当客户端调用远程对象的方法时，该方法可能无参或是有许多的参数，根据方法参数类型，这样就可能有三种不同情况发生。

    (一) 第一种情况，所有的（远程）方法参数（或是返回值）都是原始的数据类型，这样远程对象知道如何的解释他们作为方法的参数，同时也无需检查classpath和codebase属性。

    (二) 第二种情况，至少有一个参数或是返回值是一个对象，然而远程对象可以在本地的classpath中可以找到该对象类的定义。

    (三) 第三种情况（如图4，第六步所示），远程方法收到一个对象参数，然而远程对象在本地的classpath中没有找到对象的定义。这种远程方法的调用情况如图4所示。客户端发送的对象类可能是（远程方法）参数类的子类型，它可能是两者其中之一：

    1) 一个接口的实现，该接口为方法的参数（或是返回值）类型；

    2) 一个类的子类，该类为方法的参数（或是返回值）类型；

    图4 Java RMI客户端远程方法调用，传递一个未知的参数类型的子类型

     

    类似applet的代码库址（codebase），客户端设定的代码库址（codebase），用于其他JVM下载远程类、非远程类和接口地址。如果在客户端的应用中设定了代码库址（codebase）属性，那么客户端在调用子类型时，代码库址（codebase）就被作为参数加到子类型的实例上。如果在客户端没有设定代码库址（codebase），那么远程对象就会错误的使用自己的代码库址（codebase）。

    1.5. 命令行例子

    在applet情况下，代码库址（codebase）是嵌在网页中的，就如我们在本文的第一部分看到的HTML例子。

    在Java RMI应用时，codebase不是依靠一个镶嵌在网页中类的引用实现的，客户端会和Java RMI的注册表沟通获得远程对象的应用。由于远程对象的代码库址（codebase）可以指向任意URL，不能仅是一个相对于已知的URL地址，必须是存根类（stub）和其相关类目录的绝对地址。代码库址（codebase）可以指向：

    §         一个目录地址，该目录中含有类包子目录；

    §         一个Jar文件路径，含有类包的目录压缩文件；

    §         满足以上条件的多个目录或是多个Jar文件，中间用空格间隔；

     

    注意：如果代码库址（codebase）设定为一目录地址，那么结尾一定要是“/”。

     

    例子：

    如果你把要下载类在“webvector”HTTP服务器的export目录下（在Web根目录下），那么的你的代码库址（codebase）就该这样设置：

    -Djava.rmi.server.codebase=http://webvector/export/

     

     

    如果你把要下载类放在“webline”HTTP服务器的public目录下（在Web根目录下），一个名字为“mystuff.jar”的Jar文件，你的代码库址（codebase）就该如此设置：

    -Djava.rmi.server.codebase=http://webline/public/mystuff.jar

     

     

    现在我们假设你把要下载的类分为两个文件“myStuff.jar”和“myOtherStuff.jar”，而且这两个文件放在不同的服务器上（名字是：“webfront”和“webwave”），你的代码库址（codebase）属性就该这样设定：

    -Djava.rmi.server.codebase="http://webfront/myStuff.jar  http://webwave/myOtherStuff.jar"

     

    1.6. 疑难问题解答

    如果你的Java RMI程序配置正确，任何一个可以序列化的类，包含Java RMI存根类，都是可以被下载下来的。动态的存根（stub）能够正常的下载，需要满足几种状况：

    ●        通过URL提供的存根类和存根类依赖的任何类能够被客户端可达。

    ●        在服务程序中通过调用bind或是rebind设定（或是在程序安装的过程中激活）（译注：rebind（String url， Remote obj） 或是bind（String url， Remote obj）），如下情况：如步骤A中设定的URL同时如果设定的为一个目录，那么必须是“/”结尾。

    ●        rmiregistry在它相关的classpath中找不到存根类或是其依赖的其他类。这也是为什么我们在注册表调用存根时，给它加上代码库址（codebase）的参数的原因了，在服务端或是安装代码中，作为一个调用的结果。

    ●        客户端安装的SecurityManager允许存根（stub）下载。在Java 2 SE或是高版本中，这将意味着客户端必须在策略文件中进行合适的配置。

     

    在使用Java RMI的java.rmi.server.codebase系统变量时，有两种经常性的问题，我们将在下边讨论。

    1.6.1. 运行Java RMI服务端可能碰到的问题

    你碰到的第一个问题可能是收到ClassNotFoundException的异常，当你向注册表绑定（bind或是rebind）一个远程对象和名字时。这种异常通常是由不合法的codebase属性引起的，导致了在注册表中不能定位远程对象的存根（stub）或是存根需要的其他类。

    同远程对象本身相比，远程对象的存根（stub）实现了所有同样的接口，这需要特别的注意。因此这些接口，同其他定制的类作为方法参数或是返回值，也必须能够通过指定的代码库址（codebase）下载。

    通常，由于忽略了属性设定时URL中末尾“/”，导致这个异常的抛出。其他的一些原因可能是：属性值不是一个URL；URL路径拼写错误或是不正确；设定的URL中存根类（stub）和其相关的类不存在。

    这种情况下，你遇到的异常可能是这样：

    java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:

                java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:

                java.lang.ClassNotFoundException: examples.callback.MessageReceiverImpl_Stub

                java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:

                java.lang.ClassNotFoundException: examples.callback.MessageReceiverImpl_Stub

                java.lang.ClassNotFoundException: examples.callback.MessageReceiverImpl_Stub

                at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Compiled Code)

                at sun.rmi.transport.StreamRemoteCall.executeCall(Compiled Code)

                at sun.rmi.server.UnicastRef.invoke(Compiled Code)

                at sun.rmi.registry.RegistryImpl_Stub.rebind(Compiled Code)

                at java.rmi.Naming.rebind(Compiled Code)

                at examples.callback.MessageReceiverImpl.main(Compiled Code)

                RemoteException occurred in server thread; nested exception is:

                java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:

                java.lang.ClassNotFoundException: examples.callback.MessageReceiverImpl_Stub

    1.6.2. 运行Java RMI客户端可能碰到的问题

    你可能遇到第二个问题，就是在注册表中查找远程对象时，输出ClassNotFoundException的异常。如果你在运行客户端代码时收到这个堆栈异常信息，那么问题可能是你的Java RMI注册表启动时classpath设定的问题。参考requirement C in section 6.0.这里有一个这样异常例子：

    java.rmi.UnmarshalException: Return value class not found; nested exception is: java.lang.ClassNotFoundException: MyImpl_Stub at sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:109 at java.rmi.Naming.lookup(Naming.java:60) at RmiClient.main(MyClient.java:28)

    1.7. 其他资源

    如果你对代码库址（codebase）还有其他的没有解答的问题，请首先浏览RMI－USER组。

    你可能也想加入RMI－USER邮件列表中。

    2. RMI动态下载类分析

    SiteFrom: http://www.diybl.com/course/3_program/java/javaxl/2008829/138460.html

     

    部署一个分布式应用可能会很困难，系统即使只运行其中的一部分，也必须安装所有的相关部分。对于一个局域网来说，这是很消耗时间的，虽然不会很困难。然而，当部署一个大规模应用且更新频繁的时候，部署过程会困难的多。动态下载是集成在RMI中的一项技术，试图使这个应用容易些。

    一：应用遇到的困难

    部署一个应用需要一下步骤：

           1）配置服务器

           2)向名字服务路径增加stub类和其他相关的类和对象

           3）如果一个重新部署和第一次的部署完全相反，那么你可能会重启名字服务并且重新注册

           4）在每一个客户机上安装和配置应用

           简单来说，部署一个web应用不需要改变客户端或者名字服务。取而代之的是，当一个web浏览器下载一个包含applet标签的web页面时，应用只需更少时间而且更容易正确执行。然而，每次你需要更新或者重新部署，不同点变的越来越大。好消息就是，动态下载允许RMI应用动态从http后者ftp下载类定义的字节码。

    二：ClassLoader原理

           Java虚拟机下载有效独立的类，通过使用classloader类

    1：动态链接

    每个java源代码被编译为.class文件，每一个.class文件包含了一个单独类的字节码。每一个java类单独编译，运行的时候动态链接。大多数传统编程语言使用的是静态连接模型。 为了生成一个可执行的应用，源代码必须编译，并且所有引用的必须立即解决 。也就是说，各个独立的应用部件必须链接在一起。动态链接尽可能的推迟组合过程。对于运行一个java应用，很有可能，一些引用从来都没有实际用过，因为引用方法没有被调用。

           刚开始，这个看起来没有什么特别。C++程序员经常那个在大脑中有一个hard time。但是如果你想一下，为了使得java正常工作，一些动态链接的的形式很有必要，考虑下面典型应用：

           1）用JDK1.2在linux机器写了一个applet

           2）从Macintosh下载一个web页面，applet在MRJ内部使用JDK1.1.6执行应用。

           这些应用场景对C++来说是不可能的，链接必须推迟到直到执行。不幸的是，当应用部分更新的时候，动态链接也会出问题。如果你改变了一些.class文件，你可能有两个不能链接一起的文件。

    RMI采用JVM中采用动态类型加载方式，所以概念上只有当一个类型被应用到时，虚拟机才会加载它。比如，假设类C引用了类D，只有当虚拟机执行到C中引用D的语句时才会去加载D。 其中有Defining Class Loader 和 Initiating Class Loader，Defining class loader是指真正执行加载某个类的动作的那个类加载器实例。在虚拟机中，一个类型C是由其类型名和定义它的那个defining class loader来唯一标识的，即C=<N, L>。Iniating class loader是指发起这个加载动作的类加载器实例。比如在前面的例子中，虚拟机发现C引用D时，就把C的defining class loader作为D的initiating class loader。至于D最终是由谁定义的，则要由class loader的代理机制来决定。

    2：常见Class Loader以及其关系

    Bootstrap class loader：虚拟机运行时必须要用到的类的加载器，比如java.*。它通常是在虚拟机种用本地代码实现，在系统中用null表示。

    Extension class loader：负责加载Java环境中安装的可选包（optional package）中的类。

    Application class loader：负责加载CLASSPATH上的类。有时候也称为system class loader，Java程序可以通过调用java.lang.getSystemClassLoader()获得它的引用。

    Class loader之间有两种层次关系：继承关系和代理（delegation）关系。

    除bootstrap class loader之外的所有其它class loader都是用Java语言来实现的，所以它们之间自然有继承关系。Java API里面定义的类的继承关系如下：java.net.URLClassLoader --> java.security.SecureClassLoader --> java.lang.ClassLoader --> java.lang.Object。

    代理关系是class loader实例之间的动态关系。在创建一个class loader实例时可以给其构造函数传递一个parent参数，这样该parent就成了新创建的class loader在代理层次上的父节点。这个层次树的根节点就是bootstrap class loader实例。Java程序可以通过调用class loader实例的getParent()方法来获取其父节点。比如在JDK1.5中运行HelloWorld程序时class loader的代理继承关系如下：sun.misc.Launcher$AppClassLoader --> sun.misc.Launcher$ExtClassLoader --> null （bootstrap class loader）。

    3：代理机制

    当一个class loader收到加载某个类的请求时，它按照下面的流程处理：

    1）查找这个类是不是已经被自己加载过，如果没有则进行下一步；

    2）请求代理层次中的父加载器加载这个类；

    3）如果父加载器无法加载这个类（抛回异常），则尝试自己加载这个类。如果能够加载，则定义该类，否则抛出异常。

    所以在代理层次结构上的子节点永远只加载父节点（及其祖先节点）所不能加载的类，这样可以保证类始终被合适的class loader加载，比如rt.jar中的类永远被bootstrap class loader加载。

    4：类的下载

           1）当JVM第一次启动，一个独立的classloader类，也就是作为引导程序，被创建。这个classloader负责相爱在和创建在JVM内部使用的类。

           2）一个应用可以创建更多的classloader，每一个classloader，除了引导程序classloader，都有一个父classloader。classloader集合组成了一个树形结构，其中引导类classloader是根结点。

           3）当需要一个类对象，JVM寻找一个合适的classloader并使用loadClass（）来获得类对象。classloader首先想其父节点请求类，如果父节点没有运行，则自己创建一个。

           这个想法的背后是，classloader是一个方式来划分类集合以及其定义。例如，如果两个兄弟classloader被要求同样的类，则这个类被初始化两次。

           classloader在两个应用很有用。第一个，当你想从一个不标准的资源下载类对象。引导classloader试图利用CLASSPATH变量从文件系统下载类。它希望一个类的包和名字映射到一个包含类字节码的.class文件。如果你想从不同资源下载类，你需要安装另一个classloader，例如java.net.URLClassLoader.第二个，相同类的不同版本在同一时间运行。因为classloader只是检查其父节点，而不检查其兄弟节点，来检查类是否被下载，所以所以有可能同一个类的不同版本被下载。

    5：动态下载的实现

           RMI动态下载基于两个思想：

           1）如果一个对象被序列化并且通过线路传送，需要的类定义可能在另一边可获得。

           2）在序列化对喜爱那个内部自动从URLS下载类，这样使得特殊目的的classloader，例如URLClassLoader类，在需要并行化一个对象的时候通过线路自动下载类。

    RMI反序列化思想

           1）一个实例通过线路发送。作为一部分对象序列化信息，所有类定义相关的信息被通过线路发送。每一个类还有URL的字符串序列。

           2）反序列化机制为刚描述的类寻找合适的ClassLoader。之所以可以这样是因为，RMI运行时保持了一个URLCassLoader实例集合的索引。

           3）如果类存在，URLClassLoader的实例就返回他们。如果类不存在则URLClassLoader下载他们。

           因为ClassLoader类在试图下载他们之前先向其父节点请求，第一个试图下载的会从文件系统下载。如果引导ClassLoader不能下载类，则类下载仅仅使用URLs。

    专利

    最新回复(0)