|
|
The following sections discuss recommended design patterns when programming with RMI and RMI over IIOP:
Oracle 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:
To maintain code portability, always use PortableRemoteObject when casting the home interfaces. For example:
Propshome home = (PropsHome)
PortableRemoteObject.narrow(
ctx.lookup( "Props" ),
PropsHome.class );
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 Cotnexts 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.
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:
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:
If you need to use the RMI timeout for a legacy system, review the following guidelines:
RequestTimeOutException is always propagated to the caller.
|