Skip navigation.
Downloads | Product Documentation | Support

Programming WebLogic RMI

# WebLogic RMI Features and Guidelines

The following sections describe the WebLogic RMI features and guidelines required to program RMI for use with WebLogic Server:

- WebLogic RMI Overview
- WebLogic RMI Security Support
- WebLogic RMI Transaction Support
- Failover and Load Balancing RMI Objects
- Creating Pinned Services
- Dynamic Proxies in RMI
- Using the RMI Timeout

# WebLogic RMI Overview

WebLogic RMI is divided between a client and server framework. The client run time does not have server sockets and therefore does not listen for connections. It obtains its connections through the server. Only the server knows about the client socket. Therefore if you plan to host a remote object on the client, you must connect the client to WebLogic Server. WebLogic Server processes requests for and passes information to the client. In other words, client-side RMI objects can only be reached through a single WebLogic Server, even in a cluster. If a client-side RMI object is bound into the JNDI naming service, it only be reachable as long as the server that carried out the bind is reachable.

# WebLogic RMI Security Support

WebLogic Server implements authentication, authorization, and J2EE security services. For more information see Introduction to Programing WebLogic Security at Programming WebLogic Security.

# WebLogic RMI Transaction Support

WebLogic Server supports transactions in the Sun Microsystems, Inc., JavaTM 2, Enterprise Edition (J2EE) programming model. For detailed information on using transactions in WebLogic RMI applications, see the following:

- Transactions in WebLogic Server RMI Applications in Programing WebLogic JTA provides an overview on how transactions are implemented in WebLogic RMI applications.
- Transactions in RMI Applications in Programing WebLogic JTA provides general guidelines when implementing transactions in RMI applications for WebLogic Server.

# Failover and Load Balancing RMI Objects

The following sections contain information on WebLogic Server support for failover and loadbalancing of RMI objects:

- Clustered RMI Applications
- Load Balancing RMI Objects
- Parameter-Based Routing for Clustered Objects

## Clustered RMI Applications

For clustered RMI applications, failover is accomplished using the object's replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica.

To make J2EE services available to a client, WebLogic binds an RMI stub for a particular service into its JNDI tree under a particular name. The RMI stub is updated with the location of other instances of the RMI object as the instances are deployed to other servers in the cluster. If a server within the cluster fails, the RMI stubs in the other server's JNDI tree are updated to reflect the server failure.

You specify the generation of replica-aware stubs for a specific RMI object using the -clusterable option of the WebLogic RMI compiler. For example:

>     $ java weblogic.rmic -clusterable classes

For more information, see Replication and Failover for EJBs and RMIs in Using WebLogic Clusters.

## Load Balancing RMI Objects

The load balancing algorithm for an RMI object is maintained in the replica-aware stub obtained for a clustered object. You specify the load balancing algorithm for a specific RMI object using the -loadAlgorithm <algorithm> option of the WebLogic RMI compiler. A load balancing algorithm that you configure for an object overrides the default load balancing algorithm for the cluster. The WebLogic Server RMI compiler supports the following load balancing algorithms:

- Round Robin Load Balancing
- Weight-Based Load Balancing
- Random Load Balancing
- Server Affinity Load Balancing Algorithms

For example:

To set load balancing on an RMI object to round robin, use the following `rmic` options:

>     $ java weblogic.rmic -clusterable -loadAlgorithm round-robin classes

To set load balancing on an RMI object to weight-based server affinity, use `rmic` options:

>     $ java weblogic.rmic -clusterable -loadAlgorithm weight-based -stickToFirstServer classes

For more information, see Load Balancing for EJBs and RMI Objects in Using WebLogic Server Clusters.

## Parameter-Based Routing for Clustered Objects

Parameter-based routing allows you to control load balancing behavior at a lower level. Any clustered object can be assigned a CallRouter using the `weblogic.rmi.cluster.CallRouter` interface. This is a class that is called before each invocation with the parameters of the call. The CallRouter is free to examine the parameters and return the name server to which the call should be routed.

`weblogic.rmi.cluster.CallRouter`.

>     Class java.lang.Object
>        Interface weblogic.rmi.cluster.CallRouter
>           (extends java.io.Serializable)

A class implementing this interface must be provided to the RMI compiler (`rmic`) to enable parameter-based routing. Run `rmic` on the service implementation using these options (to be entered on one line):

>     $ java weblogic.rmic -clusterable -callRouter <callRouterClass> <remoteObjectClass>

The call router is called by the clusterable stub each time a remote method is invoked. The router is responsible for returning the name of the server to which the call should be routed.

Each server in the cluster is uniquely identified by its name as defined with the WebLogic Server Console. These are the names that the method router must use for identifying servers.

Example: Consider the `ExampleImpl` class which implements a remote interface Example, with one method `foo`:

>     public class ExampleImpl implements Example {
>       public void foo(String arg) { return arg; }
>     }

This `CallRouter` implementation `ExampleRouter` ensures that all `foo` calls with `arg' < "n" go to server1 (or server3 if server1 is unreachable) and that all calls with `arg' >= "n" go to server2 (or server3 if server2 is unreachable).

>     public class ExampleRouter implements CallRouter {
>       private static final String[] aToM = { "server1", "server3" };
>       private static final String[] nToZ = { "server2", "server3" };

>       public String[] getServerList(Method m, Object[] params) {
>         if (m.GetName().equals("foo")) {
>           if (((String)params[0]).charAt(0) < 'n') {
>             return aToM;
>           } else {
>             return nToZ;
>           }
>         } else {
>           return null;
>         }
>       }
>     }

This `rmic` call associates the `ExampleRouter` with `ExampleImpl` to enable parameter-based routing:

>     $ rmic -clusterable -callRouter ExampleRouter ExampleImpl

### Custom Call Routing and Collocation Optimization

If a replica is available on the same server instance as the object calling it, the call will not be load-balanced, because it is more efficient to use the local replica. For more information, see Optimization for Collocated Objects in Using WebLogic Server Clusters.

# Creating Pinned Services

You can also use `weblogic.rmic` to generate stubs that are not replicated in the cluster. These stubs are known as "pinned" services, because after they are registered they are available only from the host with which they are registered and will not provide transparent failover or load balancing. Pinned services are available cluster-wide, because they are bound into the replicated cluster-wide JNDI tree. However, if the individual server that hosts the pinned services fails, the client cannot failover to another server.

You specify the generation of non-replicated stubs for a specific RMI object not using the -clusterable option of the WebLogic RMI compiler. For example:

>     $ java weblogic.rmic classes

# Dynamic Proxies in RMI

A dynamic proxy or proxy is a class used by the clients of a remote object. This class implements a list of interfaces specified at runtime when the class is created. In the case of RMI, dynamically generated bytecode and proxy classes are used. The proxy class is the instance that is invoked upon in the client's Java Virtual Machine (JVM). The proxy class marshals the invoked method name and its arguments; forwards these to the remote JVM. After the remote invocation is completed and returns, the proxy class unmarshals the results on the client. The generated bytecode—which exists in the remote JVM—unmarhsals 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.

# Using the RMI Timeout

WebLogic Server allows you to specify a timeout for synchronous remote call. This allows an RMI client making a remote call to return before the remote method that it invoked has returned from the server instance it called. This can be useful in legacy applications where a client wants to be able to return quickly if there is no response from the remote system.

To implement a synchronous RMI timeout, use the `remote-client-timeout` deployment descriptor element found in the `weblogic-ejb-jar.xml`. For more information, see the weblogic-ejb-jar.xml Deployment Descriptor Reference in Programming WebLogic Enterprise JavaBeans.

## Guidelines on Using the RMI Timeout

This section provides implementation guidelines for appropriate use of the RMI client timeout:

- This feature provides a work around for legacy systems where the behavior of asynchronous calls is desired but not yet implemented. BEA recommends legacy systems implement more appropriate technologies if possible, such as:

- Asynchronous RMI invokations
- JMS and Message Driven Beans (MDBs)
- HTTP servlett applications

- The RMI timeout should be used only when the following three conditions are met:

- The method call is idempotent or does not introduce any state change
- The method call is non-transactional
- No JMS resources are involved in the call

- The client is required to handle the `RequestTimeOutException` and the management of state.
- The server continues to process requests that have timed out. The client is required check the state of the request on the server before reattempting the call.
- There is no transparent failover to another cluster node when a request times out. `RequestTimeOutException` is always propogated to the caller.
- Users may see server warning messages similar to:

>     <Warning> <RJVM> <BEA-000510> <Unsolicited response: 4,690>