Remote request dispatcher

Remote Request Dispatcher (RRD) is a pluggable extension to the web container for application frameworks, servlets, and JavaServer Pages to include content from outside of the current Java™ virtual machine (JVM) for the resource, as part of the response sent to the client.

Remote request dispatcher is an extensible infrastructure for 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 Java Platform, Enterprise Edition (Java EE) javax.servlet.RequestDispatcher implementation to be aware of locating remote resources using web services to communicate between machines within a WebSphere® Application Server 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 use SSL for secure communications and WS-Security security context propagation between servers. See the rrdSecurity.props file topic for more information.

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

By using 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 started 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 the plug-in for WebSphere Application Server.
    • 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 an 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. SSL is enabled by default, however, you must also pass security context needs through RRD to ensure that the security state is available in the remote machine. RRD uses WS-Security to pass this information, but this security context propagation is disabled by default. See the rrdSecurity.props file topic for additional information.