Programming WebLogic RMI

Best Practices for Application Design

The following sections discuss recommended design patterns when programming with RMI and RMI over IIOP:

Use java.rmi

BEA recommends RMI users use java.rmi. Although the WebLogic API contains the weblogic.rmi API, it is deprecated and is only provided as a compatibility API. Other WebLogic APIs provided for compatibility are :

Use PortableRemoteObject

To maintain code portability, always use PortableRemoteObject when casting the home interfaces. For example:

Propshome home = (PropsHome)

PortableRemoteObject.narrow(

        ctx.lookup( "Props" ),

        PropsHome.class );

To guarantee a that a WebLogic class is used, implement weblogic.rmi.extensions.PortableRemoteObject.

Use WebLogic Work Areas

Work Contexts allow J2EE developers to define properties as application context which implicitly flow across remote requests and allow downstream components to work in the context of the invoking client. Work Contexts allow developers to pass properties without including them in a remote call. A Work Context is propagated with each remote call-allowing the called component to add or modify properties defined in the Work Context; similarly, the calling component can access the Work Context to obtain new or updated properties.

Work Contexts ease the processing of implementing and maintaining functionality that requires that information to be passed to remote components, such as diagnostics monitoring, application transactions, and application load-balancing. Work Contexts are also a useful mechanism for providing information to third-party components.

Work Conexts can propagate user-defined properties across all request scopes supported by WebLogic Server-a Work Context is available to all of the objects that can exist within the request scope, including RMI calls. For more information, see Developing Applications with WebLogic Server.

Guidelines on Using the RMI 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

If you need to use the RMI timeout for a legacy sytem, review the following guidelines:

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

There is no transparent failover to another cluster node when a request times out. RequestTimeOutException is always propogated to the caller.
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.
If a server times out, the client has the ability to mark the server as unreachable in the client side cluster reference. This prevents calls from being directed to the marked server for a specified time.