JavaRMI

 

　　RMI（Remote Method Invocation，远程方法调用）是用Java在JDK1.1中实现的，它大大增强了Java开发分布式应用的能力。Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式网络应用的能力上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。　　RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信。JRMP是专为Java的远程对象制定的协议。因此，Java RMI具有Java的"Write Once,Run Anywhere"的优点，是分布式应用系统的百分之百纯Java解决方案。用Java RMI开发的应用系统可以部署在任何支持JRE（Java Run Environment Java，运行环境）的平台上。但由于JRMP是专为Java对象制定的，因此，RMI对于用非Java语言开发的应用系统的支持不足。不能与用非Java语言书写的对象进行通信。　　Java Remote Method Invocation ( RMI -- Java远程方法调用)允许您使用Java编写分布式对象。本文将介绍RMI的优点以及如何将其连接到现有的和原有的系统中，以及与用Java 编写的组件的连接。　　RMI为采用Java对象的分布式计算提供了简单而直接的途径。这些对象可以是新的Java对象，也可以是围绕现有API的简单的Java包装程序。Java体现了“编写一次就能在任何地方运行的模式。而RMI可将Java模式进行扩展，使之可在任何地方运行”。　　因为RMI是以Java为核心的，所以，它将Java的安全性和可移植性等强大功能带给了分布式计算。您可将代理和业务逻辑等属性移动到网络中最合适的地方。如果您要扩展Java在系统中的使用，RMI将使您充分利用其强大功能。　　RMI可利用标准Java本机方法接口JNI与现有的和原有的系统相连接。RMI还可利用标准JDBC包与现有的关系数据库连接。RMI/JNI和RMI/JDBC相结合，可帮助您利用RMI与目前使用非Java语言的现有服务器进行通信，而且在您需要时可扩展Java在这些服务器上的使用。RMI可帮助您在扩展使用时充分利用Java的强大功能。

 

附件例子，留作以后查看。

1.定义远程接口；

2.定义服务器类；

3.实现server（服务器端程序入口）；

4.实现client（客户端程序入口）；

5.启动RMI注册表工具（windows: start rmiregistry）；

6.启动server（eclipse下点击‘运行’）；

7.启动client（eclipse下点击‘运行’）；

1.sever不能和远程接口（product）处于同一个package下，否则会报找不到远程接口（product）的错误，default包除外。

2.执行第五步（启动RMI注册表工具（windows: start rmiregistry））过程时，“start rmiregistry”命令必须要在server（服务器端程序入口）类所在文件路径下执行。

3.注意不要将server（服务器端程序入口）中“NamingEnumeration<NameClassPair> e = namingContext.list("rmi:");”写成““NamingEnumeration<NameClassPair> e = namingContext.list("rmi");”。

4.如果没有重新启动RMI注册表工具而直接重新启动server（服务器端程序入口）会提示相关服务器对象已经注册，解决方法有两个：第一是在重启server（服务器端程序入口）时，首先重启RMI注册表工具；第二种方法是将server（服务器端程序入口）中“namingContext.bind("rmi:toaster", p1);
   namingContext.bind("rmi:microwave", p2);”

改为“

   namingContext.rebind("rmi:toaster", p1);
   namingContext.rebind("rmi:microwave", p2);”。

具体原因可参考bind和rebind的相关API。

 

 

====================================================================++++

Running the Example Programs

A Note About Security

The server and client programs run with a security manager installed. When you run either program, you need to specify a security policy file so that the code is granted the security permissions it needs to run. Here is an example policy file to use with the server program:

grant codeBase "file:/home/ann/src/" { permission java.security.AllPermission; };

Here is an example policy file to use with the client program:

grant codeBase "file:/home/jones/src/" { permission java.security.AllPermission; };

For both example policy files, all permissions are granted to the classes in the program's local class path, because the local application code is trusted, but no permissions are granted to code downloaded from other locations. Therefore, the compute engine server restricts the tasks that it executes (whose code is not known to be trusted and might be hostile) from performing any operations that require security permissions. The example client's Pi task does not require any permissions to execute.

In this example, the policy file for the server program is named server.policy, and the policy file for the client program is named client.policy.

Starting the Server

Before starting the compute engine, you need to start the RMI registry. The RMI registry is a simple server-side bootstrap naming facility that enables remote clients to obtain a reference to an initial remote object. It can be started with the rmiregistry command. Before you execute rmiregistry, you must make sure that the shell or window in which you will run rmiregistry either has no CLASSPATH environment variable set or has a CLASSPATH environment variable that does not include the path to any classes that you want downloaded to clients of your remote objects.

To start the registry on the server, execute the rmiregistry command. This command produces no output and is typically run in the background. For this example, the registry is started on the host zaphod.

 

---

Microsoft Windows (use javaw if start is not available):

start rmiregistry

 

Solaris OS or Linux:

rmiregistry &

---

By default, the registry runs on port 1099. To start the registry on a different port, specify the port number on the command line. Do not forget to unset your CLASSPATH environment variable.

 

---

Microsoft Windows:

start rmiregistry 2001

 

Solaris OS or Linux:

rmiregistry 2001 &

---

Once the registry is started, you can start the server. You need to make sure that both the compute.jar file and the remote object implementation class are in your class path. When you start the compute engine, you need to specify, using the java.rmi.server.codebase property, where the server's classes are network accessible. In this example, the server-side classes to be made available for downloading are the Compute and Task interfaces, which are available in the compute.jar file in the public_html\classes directory of user ann. The compute engine server is started on the hostzaphod, the same host on which the registry was started.

 

---

Microsoft Windows:

java -cp c:\home\ann\src;c:\home\ann\public_html\classes\compute.jar -Djava.rmi.server.codebase=file:/c:/home/ann/public_html/classes/compute.jar -Djava.rmi.server.hostname=zaphod.east.sun.com -Djava.security.policy=server.policy engine.ComputeEngine

 

Solaris OS or Linux:

java -cp /home/ann/src:/home/ann/public_html/classes/compute.jar -Djava.rmi.server.codebase=http://zaphod/~ann/classes/compute.jar -Djava.rmi.server.hostname=zaphod.east.sun.com -Djava.security.policy=server.policy engine.ComputeEngine

---

The above java command defines the following system properties:

• The java.rmi.server.codebase property specifies the location, a codebase URL, from which the definitions for classes originating from this server can be downloaded. If the codebase specifies a directory hierarchy (as opposed to a JAR file), you must include a trailing slash at the end of the codebase URL.
• The java.rmi.server.hostname property specifies the host name or address to put in the stubs for remote objects exported in this Java virtual machine. This value is the host name or address used by clients when they attempt to communicate remote method invocations. By default, the RMI implementation uses the server's IP address as indicated by the java.net.InetAddress.getLocalHost API. However, sometimes, this address is not appropriate for all clients and a fully qualified host name would be more effective. To ensure that RMI uses a host name (or IP address) for the server that is routable from all potential clients, set the java.rmi.server.hostname property.
• The java.security.policy property is used to specify the policy file that contains the permissions you intend to grant.

Starting the Client

Once the registry and the compute engine are running, you can start the client, specifying the following:

• The location where the client serves its classes (the Pi class) by using the java.rmi.server.codebase property
• The java.security.policy property, which is used to specify the security policy file that contains the permissions you intend to grant to various pieces of code
• As command-line arguments, the host name of the server (so that the client knows where to locate the Computeremote object) and the number of decimal places to use in the  calculation

Start the client on another host (a host named ford, for example) as follows:

 

---

Microsoft Windows:

java -cp c:\home\jones\src;c:\home\jones\public_html\classes\compute.jar -Djava.rmi.server.codebase=file:/c:/home/jones/public_html/classes/ -Djava.security.policy=client.policy client.ComputePi zaphod.east.sun.com 45

 

Solaris OS or Linux:

java -cp /home/jones/src:/home/jones/public_html/classes/compute.jar -Djava.rmi.server.codebase=http://ford/~jones/classes/ -Djava.security.policy=client.policy client.ComputePi zaphod.east.sun.com 45

---

Note that the class path is set on the command line so that the interpreter can find the client classes and the JAR file containing the interfaces. Also note that the value of the java.rmi.server.codebase property, which specifies a directory hierarchy, ends with a trailing slash.

After you start the client, the following output is displayed:

3.141592653589793238462643383279502884197169399

The following figure illustrates where the rmiregistry, the ComputeEngine server, and the ComputePi client obtain classes during program execution.

 

 

When the ComputeEngine server binds its remote object reference in the registry, the registry downloads the Compute andTask interfaces on which the stub class depends. These classes are downloaded from either the ComputeEngine server's web server or file system, depending on the type of codebase URL used when starting the server.

Because the ComputePi client has both the Compute and the Task interfaces available in its class path, it loads their definitions from its class path, not from the server's codebase.

Finally, the Pi class is loaded into the ComputeEngine server's Java virtual machine when the Pi object is passed in theexecuteTask remote call to the ComputeEngine object. The Pi class is loaded by the server from either the client's web server or file system, depending on the type of codebase URL used when starting the client.