9 Best Practices for Application Design

Use java.rmi

Oracle recommends RMI users use java.rmi, see http://java.sun.com/javase/6/docs/api/java/rmi/package-summary.html. 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:

• weblogic.rmi.registry

• weblogic.rmi.server

• weblogic.rmi.extensions

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 ); 

Use WebLogic Work Areas

A best practice is to use Work Areas:

• Work Contexts allow Java EE 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 Contexts 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 for Oracle WebLogic Server.

How to Handle Changes in Security Context

WLS RMI does not carry forward the security context in the stub. The thread that establishes the stub has the right subject in its thread context. If the stub is later used in a different thread or the stub is used after the current thread context has changed as a result of some operations, subsequent calls using the stub may fail with SecurityException. Operations that can change the context of a thread include establishing a new initial context and running WLST programmatically. Thread context changes often surface as cross-domain security issues when using JMS, JTA, and MDBs in multi-domain configurations.

If an RMI stub is going to be used in a different thread, the application can use a JSR-237 work manager to schedule the new thread in the thread context that the stub is created so that the thread context is propagated to the new thread. For cases where this is not possible, or cases where the context of the original thread changes somehow, the application should reestablish the context under which the stub should be invoked with JAAS. The following public APIs can be used to reestablish the security context:

• weblogic.security.Security.getCurrentSubject()—obtain the current object on the thread.

• weblogic.security.Security.runAs()—resume the subject.

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. Oracle recommends legacy systems implement more appropriate technologies if possible, such as:

• Asynchronous RMI invocations

• JMS and Message Driven Beans (MDBs)

• HTTP servlet applications

If you need to use the RMI timeout for a legacy system, 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 propagated 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.