10 Best Practices for Application Design
This chapter includes the following sections:
Use java.rmi
Oracle recommends RMI users use java.rmi, see http://docs.oracle.com/javase/8/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:
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. 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.