Corporate Info | News | Solutions | Products | Partners | Services | Events | Download | How To Buy

# Overview of RMI in the WebLogic Framework Remote Method Invocation (RMI) is the standard for distributed object computing in Java. This whitepaper describes the features of WebLogic's implementation of the JavaSoft RMI specification, and discusses the benefits of using WebLogic RMI rather than the JavaSoft reference implementation. More detailed technical information is available in the Developers Guide, Using WebLogic RMI. Contents Introduction WebLogic RMI Advantages Performance-related issues Power and flexibility Ease of use Naming/Registry issues Client-side invocation Inheritance Support for RMI in applets Instrumentation and management Features of WebLogic RMI architecture WebLogic RMI's compiler WebLogic proxy classes WebLogic RMI registry and server WebLogic RMI performance and scalability Summary # Introduction WebLogic RMI provides standards-based distributed object computing. RMI allows an application to obtain a reference to an object that exists elsewhere in the network, and then to 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 (JVMs). WebLogic's implementation of the RMI specification takes full advantage of the power of the WebLogic Framework. WebLogic 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 -- because the WebLogic Server is finely configurable -- execution requests can be partitioned into a configurable number of server threads. Multiple server threads allow the WebLogic Server to take advantage of latency time and available processors. There are differences in the JavaSoft reference implementation of RMI and WebLogic's RMI product; however, these differences are completely transparent to the developer. WebLogic's RMI is a drop-in replacement for JavaSoft's RMI. # WebLogic RMI Advantages As a service that operates within WebLogic, WebLogic RMI has some characteristics that differ from JavaSoft's reference implementation of RMI. These characteristics do not change how a developer uses WebLogic RMI, but they do affect performance and scalability. Unlike other implementations of RMI that change object names and add a non-standard layer of access on top of the standard JavaSoft API, WebLogic RMI is completely standards-compliant. If you are an RMI user, you can convert your programs by changing nothing more than the import statement and running your remote classes through the WebLogic RMI compiler. Here is a brief comparison of WebLogic's RMI and JavaSoft's RMI reference implementation. In general, like JavaSoft's reference implementation of RMI, WebLogic RMI provides transparent remote invocation in different JVMs. Remote interfaces and implementations that are written to the RMI spec can be compiled with WebLogic RMI's compiler and used without changes. But there are significant differences in the fundamental implementation of WebLogic RMI that enhance the many aspects of distributed computing. Performance-related issues Management of threads and sockets. The reference implementation uses multiple sockets -- an expensive, limited resource -- to support communications among the server, clients, and the RMI registry. WebLogic's implementation uses a single, multiplexed, asynchronous, bidirectional connection for WebLogic RMI client-to-network traffic. The same connection may also support WebLogic JDBC requests, WebLogic Remote calls, and WebLogic Events, all part of the integrated services in WebLogic. With WebLogic RMI, the complicated virtual circuit that is maintained by the reference implementation is replaced by a single connection to the WebLogic Server. Serialization. WebLogic RMI uses WebLogic's serialization, which offers a significant performance gain, even for one-time use of a remote class. Resolution of co-located objects. Unlike the reference implementation, with WebLogic RMI there is no performance penalty for co-located objects that are defined as remote. References to co-located "remote" objects are resolved as direct references to the actual implementation object, rather than to the generated proxies. Processes for supporting services. The WebLogic RMI registry, a functional replacement for the RMI registry process, runs insides the WebLogic Server; no additional processes are needed for WebLogic RMI. Moving server-side implementation classes to the WebLogic Server's registry requires nothing more than adding a registration to WebLogic's weblogic.property file. Garbage collection. JavaSoft's RMI implementation supports distributed garbage collection, which is an expensive task. With WebLogic RMI, garbage collection is handled more efficiently at the session level by the WebLogic Server. Power and flexibility SmartStub™ support. Stubs in WebLogic RMI can be "SmartStubs," which are custom stubs that allow for application-specific partitioning of logic and data at the object level between client and server. SmartStubs override the generated stubs and permit custom optimizations of WebLogic RMI infrastructure. Ease of use Fewer things to implement. WebLogic's implementation provides ease-of-use extensions for the use of remote interfaces and code generation. For example, a remote method does not need to declare RemoteException, and WebLogic RMI does not require a separate stub and skeleton class for every remote class. Security without a Security Manager. There is no requirement in WebLogic RMI to set a Security Manager. You may comment out the call to setSecurityManager() when converting RMI code to WebLogic RMI. Since all of WebLogic RMI's services are provided by the WebLogic Server, which has other more sophisticated options for security (like SSL and ACLs), there is no need for separate functionality that applies only to the WebLogic RMI service. Naming/Registry issues Flexible naming and lookup. WebLogic's RMI allows you to chose among several schemes for naming, binding, and looking up remote objects. In your URLs, you can use the standard rmi:// scheme, or you can take advantage of other protocols supported by WebLogic, including the t3s:// scheme, which tunnels WebLogic RMI requests over WebLogic's efficient protocol with SSL for security, or http:// which tunnels WebLogic RMI requests over HTTP, thus making WebLogic RMI remote invocation available even through firewalls. (For more information on WebLogic's client access protocols, see the Developers Guide, Writing a WebLogic client application.) Beginning with release 3.0, WebLogic RMI is fully integrated with WebLogic JNDI. Applications can be partitioned into meaningful name spaces by using either the Java Naming and Directory Interface (JNDI) API or the registry interfaces in WebLogic RMI. JNDI allows publication of RMI objects through enterprise naming services, such as LDAP or NDS. Client-side invocation Client-to-server, client-to-client, or server-to-client invocations. Since WebLogic RMI operates within a well-defined server environment, where clients and servers are connected with optimized, multiplexed, asynchronous, bidirectional connections, WebLogic RMI can support client-side callbacks into applets and applications. This architecture allows clients to host remote objects with levels of service and resource access that are similar to those supported by the WebLogic Server itself. This capability enables a client applet or application to publish its objects through the registry. Other clients or servers can use the client-resident objects just like any server-resident objects. No performance penalty is imposed on the publishing client for using its own objects, even though stubs and skeletons will exist for accessing the objects remotely. When a second client looks up the object and then invokes on it, the request will be routed through the WebLogic Server to the first client, which will broker the request and invoke the remote object within its local JVM. Inheritance Preservation of a logical object hierarchy. There is no requirement in WebLogic RMI to extend UnicastRemoteObject. With WebLogic RMI, this functionality is built into WebLogic. This preserves your object hierarchy. There is no artificial need for every remote class to inherit from UnicastRemoteObject in order to inherit implementation from the rmi.server package; rather, your remote classes can inherit from classes within your application hierarchy and yet retain the behavior of the rmi.server package. JDK support Support for RMI in applets. WebLogic RMI supports clients of remote objects even under browsers that are not yet fully JDK-1.1-compliant. With WebLogic RMI, you can use RMI in applets, as long as your browser is Netscape version 3.0 or later, or Microsoft 3.0.2 or later. Instrumentation and management The reference implementation RMI server obscures RMI operations; it has few tools for debugging or monitoring your RMI classes. WebLogic, which hosts the RMI registry, provides a well-instrumented environment for development and deployment of distributed applications. # Features of WebLogic RMI architecture Like JavaSoft's reference implementation of RMI, WebLogic's RMI has a code generator, and a registry and server hosted by a WebLogic Server. But WebLogic's implementation of RMI within WebLogic's Framework provides features that are different or missing from the reference implementation. ### WebLogic RMI's compiler The WebLogic RMI code generator (compiler) produces a stub and a skeleton that support the interfaces implemented by the remote object. The object's implementation is bound to a name in the RMI registry, and any client can acquire a remote stub of the object upon which it can invoke by looking up the object in the registry. Unlike JavaSoft's RMIC, however, it is possible to specify that platform-specific compilers should be used. In addition, the WebLogic RMI compiler accepts and passes on any additional Java compiler options to the Java compiler. Other features of the WebLogic RMI compiler address some of the limitations of the reference RMI compiler that increase the flexibility of how Exceptions are thrown and handled. The WebLogic RMI compiler allows a much more flexible inheritance structure; remote classes can also implement non-remote interfaces, and code generation can be done on the descendants of a class, or on an abstract class. This means that your distributed application can exist in a meaningful object hierarchy, rather than the artificial hierarchy that results under the reference RMI where every remote class must inherit from a single interface. ### WebLogic proxy classes The WebLogic RMI compiler increases efficiency in its use of proxies. Proxy classes are the resulting skeleton and stub classes that any RMI compiler produces when run against a remote class (that is, one that implements a remote interface). WebLogic's RMI compiler by default produces proxies for the remote interface, and the remote classes share the proxies. This is a much more efficient system than the reference implementation's model of producing proxies for each remote class. When a remote object implements more than one interface, the proxy names and packages are determined by encoding the set of interfaces, unless you choose to produce class-specific proxies. When a class-specific proxy is found, it takes precedence over the interface-specific proxy. SmartStubsTM offer further potential for very efficient RMI. For instance, a custom SmartStub might allow dynamic routing of invocations to local objects for just some method calls on a remote object. With application-dependent knowledge built into a SmartStub, RMI message traffic can be highly optimized. ### WebLogic RMI Registry and Server With WebLogic RMI, the RMI registry is hosted by the WebLogic Server, which provides the necessary networking infrastructure and execution model for using RMI in a production environment. The WebLogic Server, and likewise the registry, can be accessed by a variety of client protocols, including WebLogic's own TCP-based high-performance protocol, a multiplexed, asynchronous, bidirectional communications link that may host traffic for multiple services simultaneously; as well as a secure (SSL) mode of WebLogic's protocol, HTTP tunneling, HTTPS, and IIOP. A call to look up an object in the WebLogic registry may use various URL schemes, including the default rmi:// scheme, as well as t3:// or t3s://, http://, https://, and iiop://. # WebLogic RMI performance and scalability In general, WebLogic RMI performance is enhanced by its integration into the WebLogic framework, which provides the underlying support for communications, management of threads and sockets, efficient garbage collection, and server-related support. Testing done at WebLogic has provided some basic performance numbers for comparison with other related technologies and implementations. We have proven that WebLogic RMI scales dramatically better than the reference implementation, and provides outstanding performance and scalability. Even relatively small, single-processor, PC-class servers can support well over a thousand simultaneous RMI clients, depending on the total workload of the server and the complexity of the method calls. # Summary This paper has described how WebLogic RMI, while offering the developer the flexibility and universality of the JavaSoft standard, provides the power and performance necessary for a production environment. Because WebLogic's RMI implementation depends upon and takes advantage of the sophisticated infrastructure of WebLogic, WebLogic RMI is fast and scalable, with many additional features that support real-world use of RMI for building complex, distributed systems. For more technical information, read the Developers Guide, Using WebLogic RMI. Scalable RMI is but one of the required features of a true Java application server. WebLogic RMI is the only production-quality implementation of RMI. For more information on Java application servers, see our whitepaper What is a Java application server?

Copyright © 2000 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher. Last updated 01/14/1999