Introducing WebLogic RMI

Remote Method Invocation (RMI) is the standard for distributed object computing in Java. RMI enables an application to obtain a reference to an object that exists elsewhere in the network, and then invoke methods on that object as though it existed locally in the client's virtual machine. RMI specifies how distributed Java applications should operate over multiple Java virtual machines.

WebLogic implements the JavaSoft RMI specification. WebLogic RMI provides standards-based distributed object computing. WebLogic Server enables fast, reliable, large-scale network computing, and WebLogic RMI allows products, services, and resources to exist anywhere on the network but appear to the programmer and the end user as part of the local environment.

WebLogic RMI scales linearly under load, and execution requests can be partitioned into a configured number of server threads. Multiple server threads allow WebLogic Server to take advantage of latency time and available processors.

WebLogic RMI is completely standards-compliant. If you use another implementation of RMI, you can convert your programs by changing nothing more than the import statement. Differences exist between the JavaSoft reference implementation of RMI and the WebLogic RMI product; however, these differences are completely transparent to the developer.

In addition, WebLogic RMI is fully integrated with WebLogic Java Naming and Directory Interface (JNDI). Applications can be partitioned into meaningful name spaces by using either the JNDI API or the Registry interfaces in WebLogic RMI.

This document contains information about using WebLogic RMI, but it is not a beginner's tutorial on remote objects or writing distributed applications. If you are just beginning to learn about RMI, visit the JavaSoft Web site and take the RMI tutorial.

Like the JavaSoft reference implementation of RMI, WebLogic RMI provides transparent remote invocation in different Java Virtual Machine (JVM)s. Remote interfaces and implementations that are written to the RMI specification can be used with WebLogic RMI without changes.

The following tables highlight important features of WebLogic implementation of RMI.

Table 1-1 WebLogic RMI Performance

Feature	WebLogic RMI
Overall performance	Enhanced by WebLogic RMI integration into the WebLogic Server framework, which provides underlying support for communications, management of threads and sockets, efficient garbage collection, and server-related support.
Scalability	Scales linearly under load. Scales dramatically better than JavaSoft RMI. Even relatively small, single-processor, PC-class servers can support more than 1,000 simultaneous RMI clients, depending on server workload and complexity of method calls.
Management of threads and sockets	Uses a single, asynchronous, bidirectional connection for WebLogic RMI client-to-network traffic. Same connection can support WebLogic JDBC requests or other services.
Serialization	Uses high-performance serialization, which offers a significant performance gain, even for one-time use of remote class.
Resolution of co-located objects	No performance penalty for co-located objects that are defined as remote. References to co-located "remote" objects resolved as direct references to the actual implementation object.
Processes for supporting services	WebLogic RMI registry replaces the RMI registry process. WebLogic RMI runs inside WebLogic Server. No additional processes needed.

Table 1-2 WebLogic RMI Ease of Use

Feature	WebLogic RMI
rmic	Stubs and skeletons dynamically generated by WebLogic RMI at run time, which obviates need to explicitly run weblogic.rmic, except for clusterable or Internet Inter-ORB Protocol (IIOP) clients.
Ease-of-use extensions	Provides ease-of-use extensions for remote interfaces and code generation. For example, it is not necessary for each method in the interface to declare a java.rmi.RemoteException in its throws block. Exceptions that your application throws can be specific to that application and can extend RuntimeException.
Proxies	A class used by the clients of a remote object. In the case of RMI, skeleton and a stub classes are used. The stub class is the instance that is invoked upon in the client's Java Virtual Machine (JVM). The skeleton class, which exists in the remote JVM, unmarshals the invoked method and arguments on the remote JVM, invokes the method on the instance of the remote object, and then marshals the results for return to the client.
Security Manager	No Security Manager required. All WebLogic RMI services provided by WebLogic Server, which provides more sophisticated security options, such as Secure Sockets Layer (SSL) and Access Control Lists (ACL)s. You can comment out the call to setSecurityManager() when converting RMI code to WebLogic RMI.
Inheritance	No requirement to extend UnicastRemoteObject, thus preserving your logical object hierarchy. Remote classes do not have to inherit from UnicastRemoteObject in order to inherit rmi.server package implementation. They can inherit classes from within your application hierarchy and yet retain the behavior of the rmi.server package.
Instrumentation and management	WebLogic Server, which hosts the RMI registry, provides a well-instrumented environment for development and deployment of distributed applications.

Table 1-3 WebLogic RMI Naming and Lookup

Feature	WebLogic RMI
Naming	Fully integrated with WebLogic JNDI. Applications can be partitioned into meaningful name spaces by using JNDI API or the WebLogic RMI registry interfaces. JNDI allows publication of RMI objects through enterprise naming services, such as Lightweight Directory Access Protocol (LDAP) or Novell NDS.
Lookup	For URLs, use the standard rmi:// scheme, https://, iiop://, or http://, which tunnels WebLogic RMI requests over HTTP, making WebLogic RMI remote invocation available through firewalls.
Client-side invocation	Supports client-to-server, client-to-client, and server-to-client invocations. Operates within the well-defined WebLogic Server environment with optimized, multiplexed, asynchronous, and bidirectional client-server connections. Thus a client application can publish its objects through the registry, and other clients or servers can use the client-resident objects as they would any server-resident objects.