Remote request dispatcher

Remote Request Dispatcher (RRD) is a pluggable extension to the Web container that allows application frameworks, servlets and JavaServer Pages to include content from outside of the current executing resource’s JVM as part of the response sent to the client.

Remote request dispatcher is an extensible infrastructure to allow other components and stack products to add custom extensions like generators and handlers, to the RRD extension. The remote request dispatcher extension enhances the standard J2EE javax.servlet.RequestDispatcher implementation to be aware of locating remote resources using Web services to communicate between machines within a Network Deployment (ND) core group. The remote request dispatcher extension reports any errors that occur on the remote server back to the originating server. It can also leverage SSL for secure communications and WS-Security security context propagation between servers. See rrdSecurity.props file for more information.

RRD portlet support carries forward the remote request dispatcher concept to portlets and enhances the portlet container to allow invocation of portlets outside of the current executing resource's JVM.

By utilizing the RRD extension, you can share request load across multiple machines and JVMs by including remote servers within the cell. If RRD resource is memory or processor intensive, the calling resource is not affected as much as a standard RequestDispatcher running within the same JVM. RRD solves this problem by separating resources into a different JVM.

Capabilities

• Requests on remote server are treated as include requests. Filters and request listeners are invoked as if the dispatch type is INCLUDE.

• Serializable request attributes and query parameters are sent to remote server.

• Security context is sent to a remote server through LTPA tokens.

• Servlet parameters and OutputStream

  Request parameters are passed to remote server.

• Response headers that are set by the remotely included resource are ignored similar to includes on a local server. Internal headers such as Set-Cookie can still be set and are propagated back.

• All original request headers are passed to remote server

  • Similar to WebSphere Application Server’s plugin

  • Method calls return the state as if they are on local server. For example, getServer returns the local server name or isSecure returns whether the request to the ‘local’ server has been secure.

• Cookies and sessions

  • Cookies are passed to the remote server as part of headers.

  • Sessions in local and remote servers use the same cookie or session id for a given client which is similar to includes in the same server. If a session exists on a remote server, the session cookie contains the information for both the servers to maintain the affinity to the remote server.

• Exceptions

  • If there is a exception on the remote server, the server returns an RRD specific Web services fault which wraps the original exception created by the application.

  • Attempt to recreate the original exception on the local server if the exception class exists on both servers. If the original exception cannot be recreated, an RRD specific ServletException is constructed and used instead.

  • The exception is recreated by the local server for error handling purposes.

• Dynamic cache

  When dynamic cache is enabled, caching is performed on the local and remote machine.

• Security

  You can use SSL to encrypt RRD messages between application servers. This is enabled by default, however, also pass security context needs through RRD to ensure that the security state is available in the remote machine. RRD leverages WS-Security to pass this information, but this security context propagation is disabled by default. See the topic, rrdSecurity.props file, for additional information.

Related concepts

Related tasks

Related Reference