Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs   |   Site Map   |   Search   |   Contact   |   Glossary   |   WebLogic Server Documentation
Programming WebLogic RMI:   Previous topic   |   Next topic   |   Contents

The following sections introduce WebLogic RMI and describe the advantages and features.

• Introducing WebLogic RMI

• Advantages of WebLogic RMI

• WebLogic RMI Features

• WebLogic RMI Performance and Scalability

Introducing WebLogic RMI

Remote Method Invocation (RMI) is the standard for distributed object computing in Java. 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.

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 configurable number of server threads. Multiple server threads allow 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 RMI is WebLogic's implementaion of JavaSoft RMI.

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

The WebLogic RMI compiler generates stubs and skeltons that completely replace the stubs and skeltons produced by RMIC, the RMI compiler. Like RMIC, the WebLogic RMI compiler produces enough compile-time information to support runtime resolution of classes, methods, and instances to override Object methods, and to deliver exceptions raised in the server to the invoking clients.

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

As a service that operates within WebLogic Server, WebLogic RMI has some characteristics that differ from JavaSoft's reference implementation of RMI. These characteristics do not change how you uses WebLogic RMI, but they do affect performance and scalability.

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 RMI and the JavaSoft 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 specification can be compiled with the WebLogic RMI 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.

The following sections identify some of the differences in WebLogic's implementaion of RMI compaired to the JavaSoft RMI implementation.

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 RMI uses a single, multiplexed, asynchronous, bidirectional connection for WebLogic RMI client-to-network traffic. The same connection may also support WebLogic JDBC requests or other services. 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 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. 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 RMI 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 WebLogic RMI services are provided by WebLogic Server, which has other more sophisticated options for security 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 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 http:// which tunnels WebLogic RMI requests over HTTP, thus making WebLogic RMI remote invocation available even through firewalls.

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 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.

This capability enables a client 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.This functionality is built into WebLogic Server and 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.

Instrumentation and management

The reference implementation RMI server obscures RMI operations; it has few tools for debugging or monitoring your RMI classes. WebLogic Server, which hosts the RMI registry, provides a well-instrumented environment for development and deployment of distributed applications.

Like the JavaSoft reference implementation of RMI, WebLogic RMI has a code generator, and a registry and server hosted by a WebLogic Server. But WebLogic RMI provides features that are different or missing from the reference implementation.

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.

With WebLogic RMI 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.

The WebLogic RMI compiler allows a 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. 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.

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). The WebLogic 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.

With WebLogic RMI, the RMI registry is hosted by WebLogic Server, which provides the necessary networking infrastructure and execution model for using RMI in a production environment.

WebLogic Server, and likewise the registry, can be accessed by a variety of client protocols, includinga 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, http://, https://, and iiop://.

WebLogic RMI performance is enhanced by its integration into the WebLogic Server framework, which provides the underlying support for communications, management of threads and sockets, efficient garbage collection, and server-related support.

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.

WebLogic RMI, while offering the flexibility and universality of the JavaSoft standard, provides the power and performance necessary for a production environment. Because WebLogic RMI depends upon and takes advantage of the sophisticated infrastructure of WebLogic Server, it is fast and scalable, with many additional features that support real-world use of RMI for building complex, distributed systems.