In depth usage analysis of Java distributed computing
- 2020-04-01 01:56:13
- OfStack
It is easiest if all the components are executed on the same heap space in the same Java virtual machine on the same computer, but in practice we are often not faced with such a single case. What if the client is just a device that can execute Java? What if for security reasons only the program on the server can access the database?
We know that most of the time methods are called between two objects on the same heap. What if you want to call methods on objects on different machines?
Usually, we get information from one computer from another computer through a socket input/outputStream, open a socket connection from another computer, and then get an outputStream to write data. We can, of course, define and design our own communication protocol to call it, then return the result of the execution through the Socket, and still be able to call it like a native method, that is, want to call a remote object (like on the other heap), but also like a normal call.
This is what RMI gives us.
Design of remote procedure call
There are four things to create: the server, the client, the server helper, and the client helper.
1. Create client and server applications. The server application is a remote service, an object with methods that the client will call
They handle all the low-level network input/output details of the client and server so that the client and program act as if they were handling local calls.
Auxiliary facilities as well as the task of auxiliary facilities is in fact the implementation of communication object, they will let the client feel to be in the call native object, the client object looks like in invoke remote methods, but in fact it's just a Socket in the local processing agent and streaming details. On the server side, the server of the auxiliary facilities facilities will be through a Socket connection from the client's request, parse the information package sent to me, and then call the real service, so this call from the local to the service object. The service of the auxiliary facilities after the return value is the packaging and then send it back (through the socke The client's helper unlocks this information and transmits it to the client's object
The procedure of calling a method
1. The client object invokes doBigThing() on the secondary facility object
2. The auxiliary facility of the client to package the call information to the server through the network
3. The server-side helper unwraps the information from the client-side helper and invokes the real service.
The process is described as follows:
< img Alt = "" border = 0 SRC =" / / files.jb51.net/file_images/article/201305/2013050616510714.png ">
Java RMI provides both client-side and server-side secondary facility objects
In Java, RMI has helped us to create client-side and server-side helpers, and it knows how to make client-side helpers look like real services, that is, RMI knows how to provide the same methods to clients.
In addition, RMI has all the infrastructure required for the execution period, including the ability to query the services and to enable the client to find and obtain the client's ancillary facilities (true service agents).
With RMI, you don't need to write any network or input/output programs, and the client calls remote methods the same way it calls methods on the same Java virtual machine.
General calls and RMI is a bit different, although for the client, this method calls look like a local, but the client auxiliary facilities will be calling through the network, this call will eventually involve the socket and streaming, starting with the native calls, will put it into the remote agent. How in the middle of the information from the Java virtual machine to the Java virtual machine depends on auxiliary facilities object used in the agreement.
When using RMI, must decide: JRMP or IIOP, JRMP is RMI native protocol, it is designed for remote calls between Java, on the other hand, IIOP to CORBA, it allows us to call a Java object or other type of remote method, CORBA than RMI often trouble, because if not all Java on both ends, can produce a heap of horrible translation and talk to operation.
We only care about java-to-java operations, so we use a fairly straightforward RMI.
In RMI, the client-side helper is called stub and the server-side helper is called skeleton.
How do I create a remote service
1. Create the Remote interface
A remote interface defines a method that a client can call remotely and is a polymorphic class that ACTS as a service. Both stubs and services implement this interface
2. Implement Remote interface
This is the actual executed class, which implements the method defined on the interface, which is the object that the client will call
3. Produce stubs and skeletons with rmic
There are helpers on both the client and server, and we don't need to create these classes or the source code that produces them, which is automatically disposed of when we execute the rmic tools that come with the JDK
4. Start the RMI Registry (rmiregistry)
Rmiregistry is like a phone book, where the user gets the proxy (client-side stub/helper object)
5. Start the remote service
The service object must be started, and the class that implements the service starts the instance of the service and sends the Registry, there must be a Registry to service users.
Server code
Defines the interface
import java.rmi.Remote;
import java.rmi.RemoteException;
/**
*
* MyRemote.java
*
* work To: TODO
* class Name: MyRemote.java
*
* ver � more day role undertaker � more content
* ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
* V1.00 2013-3-19 The module Su Re years ).
*
* Copyright (c) 2013 dennisit corporation All Rights Reserved.
*
* Email:<a href="mailto:DennisIT@163.com"> Send E-mail </a>
*
*
* Remote It's a token interface , It means there is no way , However it for RMI It has a special meaning , So this rule must be followed ,
* Notice I'm using theta extends, Interfaces can inherit from other interfaces
*
*/
public interface MyRemote extends Remote{
/**
* The remote interface defines the methods that the client can invoke remotely , It is a polymorphic class as a service , That is to say, , The client will
* The deployment implements this interface stub, And this stub Because it's going to execute the network and the input / Output work , So all sorts of things can happen
* The problem , The client snorts or declares exceptions to recognize this type of risk , If the method declares an exception in the interface , Call the party
* All programs must handle or redeclare this exception .
*
* The parameters and return values of the remote method must be primitive or serializable the . The parameters of any remote method will be
* The package is sent over the network , And this is done by serialization , The return value is the same . so , If you are using a custom type
* when , It must be serialized
* @return
* @throws RemoteException
* Methods in all interfaces must be declared RemoteException
*/
public String sayHello() throws RemoteException;
}
Business implementation
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
/**
*
* MyRemoteImpl.java
*
* work To: TODO
* class Name: MyRemoteImpl.java
*
* ver � more day role undertaker � more content
* ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
* V1.00 2013-3-19 The module Su Re years ).
*
* Copyright (c) 2013 dennisit corporation All Rights Reserved.
*
* Email:<a href="mailto:DennisIT@163.com"> Send E-mail </a>
*
* In order to be a remote service object , Objects must have remote-related functionality , The simplest of these is inheritance UnicastRemoteObject
* ( from java.rmi.server) Let the parent class handle the work
*
*/
public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote{
protected MyRemoteImpl() throws RemoteException {
}
@Override
public String sayHello(){
return "server says, rmi hello world !";
}
public static void main(String[] args) {
try {
MyRemote service = new MyRemoteImpl();
Naming.rebind("Remote Hello World", service);
} catch (Exception e) {
e.printStackTrace();
}
}
}
Client code
import java.rmi.Naming;
/**
*
* MyRemoteClient.java
*
* work To: TODO
* class Name: MyRemoteClient.java
*
* ver � more day role undertaker � more content
* ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
* V1.00 2013-3-19 The module Su Re years ).
*
* Copyright (c) 2013 dennisit corporation All Rights Reserved.
*
* Email:<a href="mailto:DennisIT@163.com"> Send E-mail </a>
*
*/
public class MyRemoteClient {
public void exec(){
try {
/**
* The client must obtain stub object , Because the client has to call its methods . It depends on RMI registry the . The client will look like a query call
* Search like a book , Find the service that has a matching name on it .
* Client query RMIRegistry, return stub object
* Naming.lookup("rmi://127.0.0.1/Remote Hello World");
* Parameters that
* rmi://127.0.0.1/Remote Hello World
* 127.0.0.1 Represents the host name or host IP address
* Remote Hello World It must be the same as the registered name
*
*/
MyRemote service = (MyRemote)Naming.lookup("rmi://127.0.0.1/Remote Hello World");
String tmp = service.sayHello();
System.out.println(tmp);
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
new MyRemoteClient().exec();
}
}
Rmic is executed on the implemented class (not the remote interface)
The rmic tool that comes with the JDK produces two core class stubs and skeletons for the implementation of the service. It adds _Stub or _Skeleton to the name of the remote implementation as per the naming convention. Rmic have several options, including the does not produce skeleton, observing produce class source code or use IIOP as communication protocol, etc. To produce the class will be in the current directory, remember rmic must be able to find the implementation class, therefore may need to implement from the directory where execute rmic (practice may need to consider the package directory structure and full names, in order to simple and there is no use to package)
To invoke the command line to start rmiregistry, the easiest way to make sure that it is started from a directory that can be accessed to the class is to run from the directory of the class.
The running screenshot is as follows
< img Alt = "" border = 0 SRC =" / / files.jb51.net/file_images/article/201305/2013050616510715.png ">
Note:
The client side USES the interface to call methods on the stub. The client side of the Java virtual machine must have a stub class, but the client side does not refer to the stub class in the program code. The client side always operates on real remote objects through the interface
There must be stubs and skeletons on the server, as well as the interface between the service and the remote, which requires the stub class because the stub is substituted for the real service that is connected to RMIRegistry.
Common mistakes with RMI:
1. Forget to start rmiregistry before starting the remote service money (rmiregistry must be started before using the Naming. Rebind () registry service)
2. Forget to make parameters and return types serializable (compilation does not detect them, execution does)
3. Forget to give the stub class to the client
RMI is great for writing and running remote services, but we don't use RMI alone to perform web services. Application Server.
The JavaEE server includes the Web server and Enterprise JavaBeans(EJB) server. The EJB server ACTS between the RMI invocation and the service layer.
The application of RMI in JINI
Jini also USES RMI(although other protocols can be used), but with a few more key features.
1. Adaptive exploration (adaptive Discovery)
2. A self-healing network; Networks)
The client of RMI must first get the address and name of the remote service. The client's query code must have the IP address or hostname of the remote service (because RMIRegistry is on it) and the registered name of the service
But with JINI, the user only needs to know one thing, the interface the service implements! That's it.
Jini is lookup Service, the query service than RMI Registry is stronger and more adaptable. Because Jini will automatically advertise on the network. When the query service goes online, it will use IP multicast technology to send information to the whole network. Not only that, if the client goes online after the query service has been broadcast, the client can also send a message to the whole network to ask.
When service launched, it will be on the exploration of dynamic network JINI query service and apply for registration, registration, the service will send out a serialized objects to query service, this object can be the stub of RMI remote service, network device drivers, or even can be executed on the client side of the service itself. And registration is the implementation of the interface. Instead of name.
The operation of adaptive exploration
Jini query service starts on the network and USES IP multicast technology to advertise itself
2. Another Jini service that has been started will seek to register with the newly started query service, which registers the function rather than the name, the implemented interface, and then sends the serialized object to the query service
3. The network client wants to acquire something that implements the ScientificCalculator, but does not know where, so it asks the query service
4. Query service responds to query results
Self - recovery network operation
1. A Jini service requires registration, the query service will give a lease, the newly registered service must update the lease periodically, otherwise the query service will assume that the service has been offline, and the query service will strive to present an accurate and complete state of the available service network
2. Because the service is offline due to shutdown, so the lease is not updated, the query service kicks it off.