My Java Remote Message Invocation (RMI) Turorial

Basically, Java RMI is one of the popular information sending technology in network environment. However, the main merit/point of Java RMI is "Dynamically Distributing Resources (including Source Code and Messages) around Network" than purely passing messages from one network node to the other. So I believe if you are new bee to network communication and what you want is purely network messaging function, it would be better to research on other technologies (like Socket Connection, RPC, and etc.)
Oracle provides RMI tutorial online, however, I think it only provides the most simplest example, which is far from enough to tell new bees what should be done, and why they must do this. So from now on, I will discuss the basic ideas of RMI and show some basic operation patterns. By adopting these examples, I believe you can clearly understand what you are doing, and why you do it.
The main idea of RMI is to "Dynamically distribute computing code and messages", so it becomes natural to think through the following ways:

1. Users of RMI may not know which physical network address (like IP address) they should send message to, because the characteristic "Dynamic Distribution" is highly appreciated in RMI designment. So RMI applies Java "Naming" Service to disclaim and find target resources.
2. Also, It is quite possible that the target node does not have the same copy of used classes/resources. So RMI still permits downloading of classes/resources dynamically. Therefore it becomes quite important to protect some credential resources against malicious downloading, RMI designers pay much attention in securities design. Nearly full package of Javax.Security is applied in RMI to assure the security and authentication.

Due to above consideration, users who want to use RMI must also follow its rules: using Java Naming Service to Declare/Find target Object, setting authentication configuration so that RMI can do valid downloading and data access. 
The general work flow of RMI can be depicted as follows:

Step 1: Registering Remote Object in the Naming Service.

Step 2: Client gets Remote Object information from Naming Service.

Step 3: Client setup connection with Remote Object, download Stub and finish configuration.

 
So let's have a look at where and what kind of Security policy should be applied. Security policy will be applied wherever downloading is happened. In the whole work flow, there are three occasions when downloading might happen.

Possible Downloading Occasions

 

When Client "looks up" target remote object in the naming service:

The naming service replies the real Remote Object Network Address to the client. So Client could setup connection with the remote Object, and download stub for it. During this process, The System must provide enough access control authority to the following items. Code "RMI_Sample_1_Server/Client" is an example.

1. Remote Object Side
1. Remote Object class File
2. Class which creates Stub
3. Class which invokes Registry
2. Client Side
1. Class which invokes Registry
2. Class which lookup "stub" in Registry

 

When Client invokes method of Remote Object (Stub):

The command and parameters will be sent to remote object by the stub. Then actual action will be done remotely. 
So if the remote object has enough definition (primitive types, implementation class file, etc.) of the attached parameters, nothing need to be downloaded. Code "RMI_Sample_1_Server/Client" is an example.
In contrast, if remote object does not have the definition (class file) of parameters, these definition will be downloaded from the client side. So in this occasion, the system must provide authorities to following items. Code "RMI_Sample_2_Server/Client" is an example.

1. Remote Object Side
1. Remote Object class File
2. Class which creates Stub
3. Class which invokes Registry
2. Client Side
1. Class which invokes Registry
2. Class which lookup "stub" in Registry
3. Parameter Implementation Class Files

When Remote Object returns the result of Method Invocation:

The result will be returned. So if the Client side has enough definition file (primitive type, implementation class file, etc.) to parse the returned object, nothing will be downloaded specially. Code "RMI_Sample_2_Server/Client" is an example.
In contrast, if Client side lacks enough information to parse the returned Object, it becomes necessary to download required information from the Remote Object Side. So the following items should have access control authority. Code "RMI_Sample_3_Server/Client" is an example.

1. Remote Object Side
1. Remote Object class File
2. Class which creates Stub
3. Class which invokes Registry
4. Result Object Implementation Class Files
2. Client Side
1. Class which invokes Registry
2. Class which lookup "stub" in Registry

 

RMI Important Notes

1. Interface of Remote Object must Extends "java.rmi.remote"
2. Methods in Remote Object (Interface) must throws "RemoteException"
3. Any parameters/objects which need be transmitted by RMI must implements "Serializable"
4. Security Manager must be setup in both Remote Object side and Client side.

 

Example Code

Download Link

CONTENTS:

1. RMI_Common 
1. Common tools applied in examples
2. Build it, and copy rmi-tool.jar into lib folder of each example projects. Add it to build path.
2. RMI_Sample_1_Server/Client
1. Compile the source code into "bin" folder.
3. RMI_Sample_2_Server/Client
1. Compile the source code into "bin" folder.
2. Copy RMI_Common/dist/rmi-type.jar into lib folder of the Client project. Add it to build path.
4. RMI_Sample_3_Server/Client
1. Compile the source code into "bin" folder. 
2. Copy RMI_Common/dist/rmi-type.jar into lib folder of the Client project. Add to build path.