The Java runtime looks out for these and substitutes the proxy object in its place. This means that the programmer does not deal explicitly with the proxy at all, and seemingly writes code that does not use proxies.
The Java runtime takes care of substituting the proxy when necessary. However, this may be a little confusing, and certainly does not make it clear exactly what is going on: this kind of trick is not one that will be in most programmer's experience.
The most common way to use RMI is simply to declare an object that extends UnicastRemoteObject and implements the Remote interface package jeri; import java. While the intention is to keep things simple, these activities can prove to be a little unsettling. The code in RmiImplicitExportDemo does not mention a proxy object. The runtime will create the proxy when it constructs the RmiImplicitExportDemo object.
But just like most other Java objects it needs to have a class definition for the proxy. The proxy class is created using the rmic compiler. This needs to be run on the implementation class file. An alternative approach makes some of the actions dealing with proxies more explicit package jeri; import java. Again, the proxy class has to be created by running the rmic compiler.
From Jini 2. Jeri stands for "Jini Extensible Remote Invocation". It can support The new Jini trust model. The standard exporter for Jeri is BasicJeriExporter. It's constructor takes parameters that specify the transport protocol e. TCP on an arbitrary port and an invocation object that handles the details of remote method invocation, such as marshalling and unmarshalling parameters and return values, and specifying methods and exceptions.
Other Jeri exporters can wrap around this class. The most common use is to create a TCP-based exporter: package jeri; import java.
BasicJeriExporter; import net. BasicILFactory; import net. Note that there is no need to generate the proxy class as part of the compile-time build. The proxy is generated at runtime by the Jeri system. The exported object, the proxy, is declared to be of the Remote interface. In fact, the specification says that the proxy will implement all of the remote interfaces of the original Remote object.
In the above examples there are none, but in general a remote object will implement one or more Remote interfaces, and so will the proxy. This last point is worth expanding on. Suppose we have an interface Iface which does not extend Remote. Note that the trailing slash in the URL is important: it says that the location is a base directory that contains the class files.
Next we have to set up security. Since we will be loading class files over the network and executing their methods, we must have a security manager in place to restrict the kinds of things those classes may do, at least in the case where they are not coming from a trusted code source. RMI will not load any classes dynamically unless a security manager is installed. One easy way to meet this condition is to install the RMISecurityManager as the system security manager for your application.
It is an example security manager that works with the default system policy and imposes some basic restrictions on what downloaded classes can do. Here is an example policy file—call it mysecurity. Finally, there is one last magic incantation required to enable dynamic class loading. As of the current implementation, the rmiregistry must be run without the classes which are to be loaded being in its class path.
If the classes are in the class path of rmiregistry , it will not annotate the serialized objects with the URLs of their class files and no classes will be dynamically loaded. This limitation is really annoying; all we can say is to heed the warning for now.
If you meet these conditions, you should be able to get the client to run starting with only the MyClient class and the RmtServer remote interface. All of the other classes will be loaded dynamically from a remote location. The StringIterator is a simple list of strings, with some methods for accessing the strings in order. We will make it a remote object, so that implementations of StringIterator stay on the server.
Along with the request, our client passes a reference to a WorkListener object that is to be notified when the WorkRequest is done. Because this is to be a remote object, our interface must extend Remote , and its methods must throw RemoteException s:.
This is the interface that defines how an object should listen for a completed WorkRequest. It has one method, workCompleted , which the server that is executing a WorkRequest calls when the job is done:.
We need to add implementations of the getList and asyncExecute methods, which we just added to the RmtServer interface:. Our implementation of asyncExecute is a little cheesy.
The thread would call workCompleted at a later time, when the computation was done. In this simple example, it would probably take longer to start the thread than to perform the calculation. We have to modify MyClient to implement the remote WorkListener interface. We also add the workCompleted method that the WorkListener interface requires:.
Finally, we want MyClient to exercise the new features. Add these lines after the calls to getDate and execute :. We use getList to get the iterator from the server, then loop, printing the strings. We also call asyncExecute to perform another calculation; this time, we square the number The second argument to asyncExecute is the WorkListener to notify when the data is ready; we pass a reference to ourself this.
Now all we have to do is compile everything and run rmic to make the stubs for all our remote objects:. You should get the following:. And, conversely, you should be able to have the MyServer download the Client stub and WorkRequest related classes when it needs them. We hope that this introduction has given you a feel for the tremendous power that RMI offers through object serialization and dynamic class loading. Java is one of the first programming languages to offer this kind of powerful framework for distributed applications.
One of the newest features of RMI is the ability to create remote objects that are persistent. They can save their state and be reactivated when a request from a client arrives. This is an important feature for large systems with remote objects that must remain accessible across long periods of time.
RMI activation effectively allows a remote object to be stored away—in a database, for example—and automatically be reincarnated when it is needed. Much of the functionality of activatable objects can be achieved by using factories of shorter-lived objects that know how to retrieve some state from a database or other location. The primary users of RMI activation may be systems like Enterprise JavaBeans, which need a generalized mechanism to save remotely accessible objects and revive them at later times.
So this solution is somewhat limited at this time. Skip to main content. Start your free trial. Remote and Non-Remote Objects. Stubs and skeletons. Remote interfaces. The UnicastRemoteObject class. The RMI registry. An RMI Example. Dynamic class loading. Passing remote object references. An In stream in the grammar is paired with the corresponding socket's input stream.
Since output and input streams are paired, the only header information needed on an input stream is an acknowledgment as to whether the protocol is understood; other header information such as the magic number and version number can be implied by the context of stream pairing.
Alternatively, an output stream can contain an invocation embedded in the HTTP protocol. The Messages are wrapped within a particular protocol as specified by Protocol. For the SingleOpProtocol , there may only be one Message after the Header , and there is no additional data that the Message is wrapped in. The SingleOpProtocol is used for invocation embedded in HTTP requests, where interaction beyond a single request and response is not possible.
For the StreamProtocol and the MultiplexProtocol , the server must respond with a byte 0x4e acknowledging support for the protocol, and an EndpointIdentifier that contains the host name and port number that the server can see is being used by the client.
The client can use this information to determine its host name if it is otherwise unable to do that for security reasons. The client must then respond with another EndpointIdentifier that contains the client's default endpoint for accepting connections. This can be used by a server in the MultiplexProtocol case to identify the client. For the StreamProtocol , after this endpoint negotiation, the Messages are sent over the output stream without any additional wrapping of the data.
For the MultiplexProtocol , the socket connection is used as the concrete connection for a multiplexed connection, as described in Section Virtual connections initiated over this multiplexed connection consist of a series of Messages as described below. There are three types of output messages: Call , Ping and DgcAck. A Call encodes a method invocation. A Ping is a transport-level message for testing liveness of a remote virtual machine.
A DgcAck is an acknowledgment directed to a server's distributed garbage collector that indicates that remote objects in a return value from a server have been received by the client. ReturnData is the result of a "normal" RMI call. A PingAck is the acknowledgment for a Ping message. Each method invocation's CallData is written to a Java object output stream that contains the ObjectIdentifier the target of the call , an Operation a number representing the method to be invoked , a Hash a number that verifies that client stub and remote object skeleton use the same stub protocol , followed by a list of zero or more Arguments for the call.
In the JDK1. As of the Java 2 stub protocol Java 2 stubs are generated using the -v1. The hash is described in the section "The RemoteRef Interface". A ReturnValue of an RMI call consists of a return code to indicate either a normal or exceptional return, a UniqueIdentifier to tag the return value used to send a DGCAck if necessary followed by the return result: either the Value returned or the Exception thrown. Note: ObjectIdentifier , UniqueIdentifier, and EndpointIdentifier are not written out using default serialization, but each uses its own special write method this is not the writeObject method used by object serialization ; the write method for each type of identifier adds its component data consecutively to the output stream.
Each class is annotated with the codebase URL the location from which the class can be loaded. In the annotateClass method, the classloader that loaded the class is queried for its codebase URL. If the classloader is non- null and the classloader has a non- null codebase, then the codebase is written to the stream using the ObjectOutputStream. Note: as an optimization, classes in the " java " package are not annotated, since they are always available to the receiver.
The class annotation is resolved during deserialization using the ObjectInputStream. The resolveClass method first reads the annotation via the ObjectInputStream. If the annotation, a codebase URL, is non- null , then it obtains the classloader for that URL and attempts to load the class. The class is loaded by using a java.
URLConnection to fetch the class bytes the same mechanism used by a web browser's applet classloader. This table lists the nonterminal symbols that represent application-specific values used by RMI.
The table maps each symbol to its respective type.
0コメント