Analysis of stubs/skeletons mechanism and RMI invocation

A stub class is a class that implements an interface, but each method that is implemented is empty.
Its role is: If an interface has many methods, if you want to implement this interface, it is necessary to implement all the methods. But a class may require only one or two of these methods from the business. If you implement this interface directly, you need to implement all the other unrelated methods in addition to implementing the desired method. And if you implement the interface by inheriting the stub class, this is a hassle. (That is, the class that inherits the interface, only needs to be one or several of the empty methods that are declared first, and does not need to be implemented as a regular class.) ）
================================================================
What is RMI
Distributed computing systems require objects that run on different hosts in different address spaces to invoke each other. Various distributed systems have their own invocation protocols, such as CORBA's IIOP (Internet Interorb Protocol), and MTS's DCOM. So what about EJB components. In Java, the complete Sockets communication interface is provided, but the sockets requires that the client and the server must carry out the coding exchange data of the application level protocol, which is very troublesome to use sockets.
An alternative to sockets protocol is RPC (Remote Procedure call), which abstracts the communication interface for procedure invocation, making it easy for programmers to invoke a remote procedure and invoke a local procedure. The RPC system uses XDR to encode the parameters and return values of the remote invocation.
However, RPC does not support objects, and EJB constructs a fully object-oriented distributed system, so object-oriented remote invocation RMI (remote method invocation) becomes an inevitable choice. With RMI, it is also convenient to invoke remote objects and invoke local objects. RMI uses the JRMP (Java Remote method Protocol) communication protocol, which is a remote invocation method built on the TCP/IP protocol.

RMI invocation mechanism
RMI uses stubs and skeletons for remote object communication. Stub acts as the client proxy for a remote object, has the same remote interface as the remote object, and the call to the remote object is actually done by invoking the client proxy object stub of the object.
================================================================
Stub
Each remote object contains a stub of proxy objects, when a program that runs on a local Java virtual machine calls an object method that runs on a remote Java Virtual machine, it first creates a stub of the proxy object for the object locally and then invokes a matching method on the proxy object, and the proxy object works as follows:
Establish a connection with the virtual machine where the remote object resides
Package (marshal) parameters and send to remote virtual machines
Wait for execution results
Che Bao (Unmarshal) return value or error returned
Returns the result of the call to the calling program
Stub objects are responsible for the invocation of parameters and return values of the Fluidization (serialization), packaging unpack, and network layer communication process.

Skeleton
Each remote object also contains a skeleton object, and skeleton runs on the virtual machine where the remote object is located, accepting calls from stub objects. When skeleton receives a call request from a stub object, skeleton does the following:
The parameters of the solution stub
Call the method of a remote object match
Package return value or error send to Stub object

The stub and skeleton objects of the remote object are generated by the Rmic compilation tool.
================================================================
Rmi-iiop
RMI is a good solution to the problem of calling distributed objects in the Java language, but RMI is not a standard invocation protocol, so RMI cannot invoke objects written in a non-Java language.

IIOP (Internet inter-orb Protocol) is CORBA's communication protocol. CORBA is a distributed component standard defined by the OMG (Object Management Group), and CORBA (Interface definition Language), which is matched to a variety of programming languages, can be done with language-independent In other words, CORBA objects written in different programming languages can be invoked with each other.

Javaidl defines a match between the Java language and CORBA, and applications written in the Java language can communicate with any CORBA object through Javaidl.

RMI-IIOP combines RMI usability and corba/iiop language independence, and Rmi-iiop,rmi objects can communicate with IIOP protocol and CORBA object. RMI-IIOP has some very slight restrictions on the invocation parameters of RMI, which must be followed when calling CORBA objects. JDK1.3 has provided support for the RMI-IIOP.

Apusic Application Server support for RMI-IIOP
Apusic Application server is currently using RMI, support for RMI-IIOP is under development and a new version of full support for RMI-IIOP is expected to be launched soon.