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?
