RMI Specification - Chapter 2
Java Distributed Object Model
2.1 Distributed Objects Applications RMI applications typically include two separate programs: server programs and client programs. A typical server application will create multiple remote objects that allow these remote objects to be referenced, and then wait for client calling those on remote objects. Typical client programs get a reference to one or more remote objects from the server, and then call the way to remote objects. RMI provides a mechanism for servers and clients. Such applications are sometimes referred to as distributed object applications.
Distributed object applications require:
Positioning Remote Objects Applications can use one of two mechanisms to get references to remote objects. It can register its remote objects with the simple nimell tool RMireGistry of RMI; you can also deliver a remote object reference as part of a regular operation. Details of inter-remote object communication remote objects are handled by RMI; for programmers, remote communication looks on the Java method of the icon. The object loaded by the parameter or returned value is loaded by the RMI allows the caller to pass the pure Java object to the remote object, so the RMI will provide the necessary mechanism, which can load the object's code and data of the object. The server calls the registration service program to associate the name with the remote object. The client uses the remote object in the server registration service program to find the remote object, and then call it. RMI can load the class bytecode with any URL protocol supported by the Java system (such as HTTP, FTP, File, etc.).
2.2 Definition of the term In the Java distributed object model, Remote Object is an object: its method can be called from other Java virtual machines (possibly on different hosts). This type of object is described by one or more Remote Interfaces (which is a Java interface of the declaration remote object method). Remote Method Call (RMI) is the action of calling the remote interface on the remote object. More importantly, the method of the remote object calls the same as the method of calling the local object.
2.3 Comparison Java Distributed Object Models of Distributed and Non-Distributed Models Similar to the Java object model in the following aspects:
The reference to the remote object can be passed in parameter form in any method call (local or remote) or in the form of a reflection. Remote objects can be forced to convert to any remote interface as long as the interface is supported using a built-in Java syntax for enforcement type conversion. Built-in Java Operator InstanceOf can be used to test remote interfaces supported by the remote object. The Java Distributed Object Model is different from the Java object model: the client's client interacts with the remote interface, and never interact with these interfaces. The non-remote parameters of the remote method and the return result are passed by copying instead of reference. This is because the reference is only useful in a single virtual machine.
Remote objects are passed in a reference manner instead of copying the actual remote implementation. Semanti-specific semantics for some Java.lang.Object class definitions are dedicated to remote objects. Because the failure mode of calling the remote object is complicated than the failure mode of the calling local object, the client must handle the extra exception that occurred during the remote method call.
2.4 RMI Interface and Class Overview 2.4.1 Java.rmi.Remote Interface In RMI, remote interface is a method set that can be called from remote Java virtual machines. Remote interfaces must meet the following requirements:
The remote interface must extends the java.rmi.Remote interface directly or indirectly. The method declaration in the remote interface must meet the requirements of the following remote method declaration: Remote method declarations In addition to the exception related to the application in its throws clause (note that the application related to the application does not need to expand java.rmi.RemoteException) In addition, Java.Rmi.RemoteException is exception (or its superclass, such as java.ioException or java.lang.exception). In a remote method declaration, the remote object must be declared as a remote interface, not the implementation class of the interface (in a non-remote object that directly declares or embedded to the parameter in the parameter table). The java.rmi.Remote interface is a tag interface that does not define methods:
Public Interface Remote
The remote interface must extend at least the java.rmi.Remote interface (or other remote interface of the Java.rmi.Remote). However, remote interfaces can extend non-remote interfaces in the following situations:
Remote interfaces can also extend other non-remote interfaces, as long as all methods of extended interfaces (if any) meet the requirements of the remote method declaration. For example, the following interface BankAccount defines a remote interface for the access bank account. It contains a remote way to account deposits to account deposits, balance account balance and from account withdrawal:
public interface BankAccount extends java.rmi.Remote {public void deposit (float amount) throws java.rmi.RemoteException; public void withdraw (float amount) throws OverdrawnException, java.rmi.RemoteException; public float getBalance () throws java.rmi. RemoteException;}
The following example illustrates a valid remote interface Beta. It expands non-remote interface alpha (have remote methods) and
Interface Java.rmi.Remote:
public interface Alpha {public final String okay = "constants are okay too"; public Object foo (Object obj) throws java.rmi.RemoteException; public void bar () throws java.io.IOException; public int baz () throws java. Lang.Exception;
Public interface beta extends alpha, java.rmi.remote {public void ping () throws java.rmi.RemoteException;
2.4.2 RemoteException class Java.rmi.RemoteException class is an exception that is thrown by the RMI runtime during the remote method call. To ensure the robustness of the application of the RMI system, the remote approach declared in the remote interface must specify java.rmi.RemoteException (or its superclars, such as java.io ioException or java.lang. " Exception.
When the remote method calls failure for some reason, it will throw java.rmi.RemoteException. Remaining Remote Method Calling Failure Includes:
Communication failure (remote server is unreachable or rejected; connection is closed, etc.) Parameter or return value transmission or reading failure protocol error RemoteException class is a tested exception (must be processed by the calling program of the remote method and compile Abnormally instead of the instead of RuntimeException. 2.4.3 RemoteObject class and its subclass RMI server function are provided by java.rmi.server.RemoteObject and its subclass java.rmi.server.RemoteServer, java.rmi.server.unicastRemoteObject and java.rmi.activation.activatable.
Java.rmi.Server.RemoteObject provides implementation of the Java.lang.Object method that is sensitive to remote objects, Hashcode, Equals, and Tostring. Create a remote object and export it (allowing them to utilize remote clients) by classes UnicastRemoteObject and Activatable. Subclasses can identify the semantics of remote references,
For example, the server is a simple remote object or an activable remote object (remote object that will be performed). The java.rmi.server.unicastRemoteObject class defines a single (single transmission) remote object, which is only valid when the server process is alive. Class java.rmi.activation.activatable is an abstract class, which defines the Activatable Remote object to start executing while its remote method is called and is shut down if necessary.
2.5 General rules for implementing the remote interface to implement the remote interface are as follows:
This class usually expands java.rmi.server.unicastRemoteObject, thus the remote behavior provided by the inherited java.rmi.server.RemoteObject and Java.rmi.server.Remotserver. This class can achieve any more remote interface. This class can expand other remote implementations. This class can define methods that do not appear in remote interfaces, but these methods can only be used locally and cannot be remote.
use. For example, the following class BankAcctimpl implements the BankAccount remote interface and expands java.rmi.server.UnicastRemoteObject class:
Package mypackage;
Import java.rmi.remoteException; import java.rmi.server.UnicastRemoteObject;
Public Class BankAccountImpl Extends UnicastRemoteObject IMPLEments BankAccount
{private float balance = 0.0;
Public BankAccountImpl (Float InitialBalance) throws RemoteException {Balance = InitialBalance;
Public void deposit (float amount) throws remoteexception {...}
Public void withdraw (float amount) throws overdrawnexception, remoteexception {...}
Public float getBalance () THROWS RemoteException {...}}
Note: If necessary, the class that implements the remote interface can extends some other classes other than the Java.rmi.Server.UnicastRemoteObject class. However, it is necessary to assume a certain responsibility when the class is achieved, that is, the export object (responsible by the UnicastRemoteObject constructor) and implements the correct remote semantic (if needed) from the Java.LANG.Object class. 2.6 Remote Method Call Parameters Pass Parameters Passing to Remote Objects or returned values from it can be arbitrary sequentially sequenceful Java objects. This package
Including Java basic types, remote? Java objects and non-remote Java objects for implementing java.io.serializable interfaces. See Java Object Series for How to make the class sequence
Specification. The class that is not available as a parameter or returned value can be dynamically downloaded via the RMI system.
How to download the parameters and return values when the RMI read parameters, return values, and exceptions
See "Dynamic Class Load" (3.4) section.
2.6.1 Transfer Non-Remote Object Non-Remote Objects Transfer or as the result of the remote method call or as a result of the remote method call, is passed by copying; that is, serializing the object using the Java object serialization mechanism. Therefore, during the remote object call, when the non-remote object is passed as a parameter or return value, the content of the non-remote object will be copied before calling the remote object. When you return to a non-remote object from a remote method, you will create a new object in the called virtual machine.
2.6.2 Transfer Remote Object When the remote object is passed as a parameter or return value called by a remote method, the STUB program of the remote object is passed out. Remote objects that are passed as parameters can only implement remote interfaces.
2.6.3 Reference Integrity If one object's two references are passed from a virtual machine to another in a single remote method call (or return value) from a virtual machine to another, and they point to the same in the sending virtual machine. Objects, two references will point to the same copy of the object in the receiving virtual machine. To be further stated: In a single remote approach, the RMI system will maintain reference integrity in an object that calls parameters or returns.
2.6.4 Class Note When the object is sent from a virtual machine to another in the remote call, the RMI system is invisible to the class descriptor in the call stream in the call stream so that the class can be The receiver is loaded. During the remote method call, calls can be downloaded at any time.
2.6.5 Parameter Transfer To serialize the parameters called the RMI to the destination file of the remote call, you need to write this parameter into the stream of subclasses as the Java.io.ObjectOutstream class. The ObjectOutputStream subclass will override the ReplaceObject method, with its corresponding STUB class to replace each remote object. The object parameters will be written in the stream via the ObjectOputStream WriteObject method. ObjectOutputStream calls the ReplaceObject method for each write stream (the object included in the object) through the WriteObject method. RMIOBJECTOUTSTREAM subclass's replaceObject method returns the following value: If the object transmitted to ReplaceObject is a Java.rmi.Remote instance, return the Stub program of the remote object. The Stub program of the remote object is obtained by calling the java.rmi.server.RemoteObject.Tostub method. If the object that is transmitted to ReplaceObject is not a Java.rmi.Remote instance, only the object is returned. The ObjectOutputStream subclass of RMI also implements an AnnotateClass method, which uses a stream with a class of the class to download the class in the receiver. See "Dynamic Class Load" section for more information on how to use AnnotateClass. Because the parameters are only written to an ObjectOutputStream, the reference to the same object to the calling program will point to the same copy of the object there. On the receiver, the parameters will be read by a single ObjectInputStream. All other default behaviors used to write objectOutputStream (similar to ObjectInputStream for reading objects) will remain in parameter delivery. For example, when writing to WriteReplace calls and read objects, the call to ReadResolve is completed by the parameter grouping and interdictility of the RMI.
Similar to the above RMI parameter transmission mode, return value (or abnormal) will be the same as the subclass of ObjectOutputStream and the alternative behavior of parameter transmission.
2.7 Location Remote Objects We specially provide a simple boot name server for storing a named reference to the remote object. The URL-based method using class java.rmi.naming can store remote object references. The client must call the remote object, you must first get the reference to the object. The reference to the remote object is usually obtained in the form of a return value in the method call. The RMI system provides a simple boot name server that obtains a remote object on a given host. Java.rmi.naming class provides methods based on a single resource locator (URL), used to bind, rebound, unlock and list names located on a host and port - object pairs.
