Detailed explanation of remote method invocation RMI, which is very similar to the idea of ​​RPC

[[268642]]

Definition of RMI

RPC (Remote Procedure Call): Remote method call is used by one process to call a procedure in another process, thus providing the distribution capability of the process.

RMI (Remote Method Invocation): Remote method invocation is a step forward on the basis of RPC, providing communication between distributed objects. It allows objects running in one Java virtual machine to call methods of objects running in another Java virtual machine. These two virtual machines can be running in different processes on the same computer or in different computers on the network.

The full name of RMI is to simplify the calling of remote interface objects as much as possible.

RMI greatly enhances Java's ability to develop distributed applications. For example, programs with complex calculation methods can be placed on other servers. The main server only needs to call them, and the actual calculations are performed on other servers. Finally, the calculation results are returned to the main server, which reduces the burden on the main server and improves efficiency (but there are also other overheads).

RMI Network Model

At the initial design stage, what we really wanted was a mechanism where client programmers could make method calls in a regular way without having to worry about sending data to the network or parsing responses. So we have the following network model: install a proxy for the remote object on the client. The proxy is an object located in the client virtual machine that appears to the client program as the remote object to be accessed. When the client calls this proxy, it only needs to make a regular method call. The client proxy is responsible for using the network protocol to contact the server.

Now the question is how do agents communicate with each other? There are usually three ways:

1. CORBA: Through the object request broker architecture, it supports method calls between objects written in any programming language.

2. SOAP

3. RMI: JAVA's remote method invocation technology, which supports method invocations between Java distributed objects.

CORBA and SOAP are completely language independent and can be written in C, C++, and JAVA, while RMI is only applicable to JAVA.

How RMI works

1. Terminology

1. Stub: When a client calls a method of a remote object, it actually calls a normal method on the proxy object, which we call a stub. The stub is located on the client machine, not on the server.

2. Parameter marshalling: The stub will pack the parameters required by the remote method into a group of bytes. The process of encoding parameters is called parameter marshalling. The purpose of parameter marshalling is to convert the parameters into a format suitable for transmission between virtual machines. In the RMI protocol, objects are encoded using a serialization mechanism.

2. Programming Model

To introduce the RMI programming model, I will write a demo below. The remote object represents a warehouse, and the client program asks the warehouse for the price of a product.

1. Interface definition

The capabilities of a remote object are expressed by an interface that is shared between the client and the server:

The interface of the remote object must extend the Remote interface, which is located in the java.rmi package. All methods in the interface must declare that they throw RemoteException. This is because remote methods always have the possibility of failure, so the Java programming language requires that each remote method call must capture RemoteException and specify the corresponding processing operations that should be performed when the call is unsuccessful.

2. Interface implementation

You can tell that this class is the target of a remote method call because it extends UnicastRemoteObject, whose constructor makes its objects accessible remotely.

3. RMI Registry: Publishing RMI Services via JNDI

1. To access a remote object on the server, the client must first obtain a local stub object, which is a proxy object on the client machine. So the question is, how can we get this stub?
2. To this end, JDK provides a bootstrap registry service, and the server program should use the bootstrap registry service to register at least one remote object.
3. To register a remote object, you need an RMI URL and a reference to the implementation object.
4. The RMI URL starts with rmi:, followed by the domain name or IP address (host), followed by the port number (port), and finally the service name (service).

For example: rmi://regserver.mycompany.cmo:99/central_warehouse

If we publish the RMI service locally, the host is "localhost". In addition, the default port number of RMI is "1099". Of course, we can set it ourselves as long as it does not overlap with other ports. Service is actually a unique service name based on the same host and port.

Publish the RMI service:

Running results:

 Constructing server implementation
 Binding server implementation to registry
 Waiting for invocations from clients ...

1. Line 20 creates a registry in JNDI by simply providing a port.
2. Line 21 binds the RMI address and the RMI service implementation class through the bind method.
3. After executing this method, the RMI service is automatically published. The next thing to do is to write an RM client to call the published RMI service.

4. Calling RMI service

Running results:

 RMI registry binding:
 mate7:3700.0

1. The service call only needs to know two things: 1. RMI request path; 2. RMI interface name
2. In line 15, the interface name Warehouse is used here instead of the implementation class. It must not be the implementation class of the RMI interface, otherwise it will be a local call.
3. Looking at the running results, we know that the remote call demonstrated by this DEMO is successful.

5. Let's take a look at the network diagram of RMI:

1. With the help of JNDI, the so-called naming and directory service, we successfully published and called the RMI service. In fact, JNDI is a registry, the server puts the service object into the registry, and the client obtains the service object from the registry.
2. On the server side, we published the RMI service and registered it in JNDI. At this time, a Skeleton was created on the server side. When the client successfully connected to JNDI for the first time and obtained the remote service object, a Stub was immediately created locally.
3. Remote communication is actually accomplished through Skeleton and Stub, and data is sent on the "transport layer" based on the TCP/IP protocol.
4. Undoubtedly, in theory, RMI must be faster than WebService. After all, WebService is based on the http protocol, and the data carried by http is transmitted through the "application layer". The transport layer is lower than the application layer, and the lower the layer, the faster it is.

Limitations of RMI

1. It can only realize calls between JAVA systems, while WebService can realize calls between systems across languages.
2. RMI uses the default serialization method of JAVA. For systems with higher performance requirements, other serialization solutions may be needed.
3. RMI services are bound to have failures when running. For example, if the RMI service cannot connect, the client will be unable to respond.