The WebLogic RMI API fully implements and supports the JavaSoft RMI API with the following: WebLogic implementation of RMI base classes; WebLogic Registry; WebLogic Server packages; WebLogic RMI compiler (covered previously); and WebLogic-provided supporting classes.

WebLogic Implementation of RMI API

Classes developed per the RMI specification, as demonstrated earlier in the "Writing the Remote Interface" section (refer to Listing 11.1), can be executed on WebLogic Server by extending the java.rmi.Remote class. To implement remote access within your RMI client, simply look up the remote object in the WebLogic Registry and execute target methods. The java.rmi.Naming class includes the methods for lookup and name binding within the WebLogic Registry. WebLogic JNDI provides the actual naming and lookup services.

All functionality of the java.rmi package is implemented in WebLogic's RMI implementation, with the exception of methods in the jama.rmi.server.RMIClassLoader class (implements dynamic class loading with RMI) and the java.rmi.server.RemoteServer.getClientHost() method (returns the client host for the remote method invocation being processed within the current thread).

WebLogic RMI Security Classes

The rmi.RMISecurityManager class is implemented as a nonfinal class with public methods. RMISecurityManager is a sample security manager for use by RMI applications that might use downloaded code. WebLogic RMI provides for Secure Sockets Layer (SSL) and access control lists (ACLs) to provide security during RMI processing; therefore, it does not use RMISecurityManager.

The System.setSecurityManager(RMISecurityManager) method is also provided. This method obviously sets RMISecurityManager. Within the WebLogic RMI implementation, no security is associated with this method. Use of this method is not recommended. WebLogic Server provides an internal security manager. You should use the WebLogic security model. Refer to Chapter 28, "Working with WebLogic Server Security Features," for details about security.

WebLogic RMI Registry Classes

The rmi.registry.LocateRegistry class is implemented as a nonfinal class with public methods. The LocateRegistry class obtains a reference to or creates an object registry on a local or remote system. A call to the LocateRegistry.createRegisty(int port) method allows the client to find the JNDI tree on WebLogic Server, but does not create a collocated Registry. The method returns a java.rmi.registry.Registry. This method could be useful when locating JNDI object entries on remote servers.

Other Useful WebLogic Server Classes

The rmi.server.LogStream.write(byte[]) method logs messages through the WebLogic Server log file. The UnicastRemoteObject class defines a nonreplicated (not shared across a network) remote object whose references are only valid when the server is operational. This class is implemented as the WebLogic RMI base class. All associated methods are implemented in the WebLogic RMI base class stub. Therefore, there's no need to extend the UnicastRemoteObject class as required by the JavaSoft RMI specification. You merely write and implement your remote interface. WebLogic provides the rmi.server.RemoteObject class (base class for RMI objects; that is, implements java.lang.Object) to preserve the type equivalence of UnicastRemoteObject. For WebLogic Server development, it's not necessary to implement either of these classes (UnicastRemoteObject or RemoteObject).

Passing Parameters Within WebLogic RMI

Within WebLogic RMI, all parameters are passed by value unless the invoking object resides within the same JVM as the RMI object. In that case, the parameters are passed by reference. Any classes passed to the remote object must be available to the WebLogic Server's classpath.

CAUTION

Modifying parameters could possibly corrupt the caller's state (alter the value of the passed parameters). Critical applications should guard against this possibility.

Passing Java Primitive Data Types

Java primitive or simple data type parameters (boolean, byte, short, int, long, char, float, and double) are always passed by value. Passing by value protects data integrity from possible server-side corruption (a server-side implementation class can possibly modify a parameter passed by reference). When primitive data types are passed during a remote method call, a copy of the parameter is made, serialized across the network, deserialized, and made available to the remote method. If the remote method returns a Java primitive, the value is serialized, deserialized, and returned to the calling client.

Passing Java Objects

When a Java object is passed during a remote method call (nonlocal JVM), the object is passed by value, not just the reference to the object. Passing by value protects the object's data from corruption by the called remote object; that is, it's possible to implement methods within the server-side implementation class that can alter the value of the passed parameter. The passed object and all objects referenced by the passed object are serialized (via object serialization) across the network where they are deserialized by the remote JVM and made available to the remote object. Objects returned to the client are handled likewise. Only Java objects that implement the serializable interface may be passed as parameters.

Passing Remote Objects

RMI implementation also calls for passing remote objects (although returning is more commonly used), as presented in the previous RMI example and as used in EJB applications (see Part V, "Using Enterprise JavaBeans in WebLogic Applications"). If a method returns a local reference to a remote object, a copy of the object is not returned. Instead, a remote proxy class (client-side stub) is returned.