Skip to main content

IBM WebSphere Developer Technical Journal: Include remote files in your Web application seamlessly with the new Remote Request Dispatcher

Stephan Hesmer (stephan.hesmer@de.ibm.com), Performance Chief Developer, IBM 
Stephan Hesmer is currently working as Performance Chief Developer. In his previous role he worked as Portlet Runtime architect in WebSphere Portal and WebSphere Application Server. He is responsible for integrating the JSR 168 portlet container into WebSphere Application Server. Stephan worked on the JSR 168 Java™ Portlet Specification, and designed and implemented the initial version of the JSR 168 Reference Implementation, Pluto. Stephan received a Diploma of Information Technology from the University of Cooperative Education Stuttgart, Germany, in 2000. After graduating, he joined the IBM Böblingen Development Laboratory to work in the WebSphere Portal Team.
Curtiss Howard (cjhoward@us.ibm.com), Software Engineer, IBM 
Curtiss Howard is currently working as a member of the WebSphere Administrative Console, WebContainer, and RRD teams. He joined IBM WebSphere Application Server in 2005 after graduating from North Carolina State University with a degree in Computer Science.
Max Moldenhauer (mmolden@us.ibm.com), Staff Software Engineer, IBM 
Maxim Moldenhauer is currently working as a member of the WebContainer and RRD teams. Maxim has been the WebContainer focal point for SIP Container integration and architected the current WebContainer test suite framework. He joined IBM WebSphere Application Server in 2003 after graduating from Virginia Tech with a degree in Computer Science.
Todd Kaplinger, WebContainer and RRD Architect, IBM 
Todd Kaplinger is currently working as Architect and Team Lead of the WebContainer and RRD Teams for the WebSphere Application Server. Todd has worked on the JSR 154 Servlet 2.5 Specification and is IBM’s representative in the Servlet Expert Group.
Timo Kussmaul (TIMO@de.ibm.com), Software Engineer, IBM 
Timo Kussmaul is currently working as software developer in WebSphere Application Server and WebSphere Portal. He joined IBM in 1997 after graduating from University of Stuttgart with a diploma in Computer Sciences. Timo wrote three books on application software and software development.

Summary:  Remote Request Dispatcher is a new feature in IBM® WebSphere® Application Server V6.1 that provides a way to seamlessly include remote WAR files from within your Web application. Learn about the powerful capabilities of the Remote Request Dispatcher, how to extend the remote call to pass customized data along the wire to the remote system, and how Remote Request Dispatcher can be applied to a portal environment in which a portlet aggregation framework uses this technology to include remote portlets.

Date:  23 Aug 2006
Level:  Intermediate
Activity:  94 views
Comments:  

From the IBM WebSphere Developer Technical Journal.

Introduction

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

The RRD is an extensible infrastructure that enables other components and stack products to add custom extensions, like generators and handlers, to the RRD extension. The RRD enhances the standard J2EE™ javax.servlet.RequestDispatcher implementation by making it able to locate remote resources using Web services to communicate between machines within a WebSphere Application Server Network Deployment core group. The RRD 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 for security context propagation between servers.

RRD portlet support carries forward the RRD concept to portlets, and enhances the portlet container to enable 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 the 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 different JVMs.

About the examples

The examples provided with this article are designed to demonstrate RRD from a simple, base use case through subsequent, increasingly complex, use cases. The first four examples are designed to build upon what was demonstrated in each prior example. The final example is independent of the others and demonstrates how RRD can be extended to support portlets.

Here, then, is a summary of the examples, each of which is described in more detail in upcoming sections:

  1. Example 1 is an RRD equivalent of the often-used "Hello World" application. In this example, the local server (AppServerLocalNode) makes an RRD call to the remote server (AppServerRemoteNode) and prints out "hello."

  2. Example 2 builds upon Example 1 and also leverages J2EE security. In this example, there are three roles defined: LocalRole, RemoteRole, and BothRole. On both the local and remote servers, the various roles that are associated with the applications are printed out, along with an indication of whether or not the logged-in user is mapped to that role.

  3. Example 3 builds upon Example 2 and also leverages dynacache, a Webphere extension used for caching response content. In this example, the content from AppServerRemoteNode is cached on AppServerLocalNode, which enables the request to be completed without having to contact AppServerRemoteNode, since there is a cached copy of the response from a previous invocation of the request.

  4. Example 4 builds upon Example 3 and also demonstrates how RRD can be extended using the RRD Extension Generator and Handler frameworks. In this example, extension handlers and extension generators have been defined to pass additional information between AppServerLocalNode and AppServerRemoteNode.

  5. Example 5 demonstrates how RRD can be extended to leverage portlets. In this example, the AppServerLocalNode and AppServerRemoteNode servlets are located in two different time zones, each with the same Standard World Clock portlet installed on each application server.

Topologies

RRD requires IBM WebSphere Application Server Network Deployment (hereafter referred to as Network Deployment). This article assumes that RRD users are familiar with Network Deployment, and with the clustering technology associated with Network Deployment. This article is intended for Java™ Web application programmers already familiar with the Java Servlet API. See Resources for links to information that can help you gain those skills.


First steps

The servers in Example 1 will consist of two clusters (LocalCluster and RemoteCluster), each containing a single node and cluster member. The cluster topology, in graphical terms, will be as shown in Figure 1.


Figure 1. Cluster topology containing two clusters each with one node and cluster member
Cluster topology containing two clusters each with one node and cluster member

Install and enable Remote Request Dispatcher for an application

RRD is enabled via two properties (for dispatching and servicing RRD includes) specified at the enterprise application level during application installation:

1. Configure Web applications to dispatch remote includes

You can use either the administrative console or scripting to perform this configuration.

2. Configure Web applications to service remote includes

Again, you can use either the administrative console or scripting to perform this configuration.

a. To install the same application using the wsadmin scripting interface, rather than using the console, execute the following scripting logic:

cd C:\wasinstall\bin
wsadmin
$AdminApp install C:/rrdArticle/RRDExample_v1_remote.ear {-cluster RemoteCluster 
–allowServiceRemoteInclude}
$AdminConfig save

Example 1

This example will illustrate the simplest RRD use case, consisting of a local servlet that performs a remote include on a JSP. To install and run the example:

  1. Install RRDExample_v1_local.ear into AppServerLocalNode using the WebSphere Application Server administrative console. Be sure to select the Allow dispatching includes to remote resources option during installation. Save your changes and start the application.

  2. Install RRDExample_v1_remote.ear into AppServerRemoteNode using the administrative console. Be sure to select the Allow servicing includes from remote resources option during installation. Save your changes and start the application.

  3. Access the example using this URL: http://localhost:9080/rrd_example_v1_local/invoke. Be sure to replace localhost and 9080 with your WebSphere Application Server’s respective host and port values. If the example has been installed correctly, the resulting screen should look like Figure 8.



    Figure 8. Hello world from a remotely included jsp
    Hello world from a remotely included jsp

  4. Examine the local servlet source, located in RRDExample_v1_local.ear, inside RRDExample_v1_local_web.war, as the file WEB-INF/source/com/ibm/ws/rrd/example/servlet/RRDLocalServlet.java. The relevant portion, inside the doPost() method, illustrates the remote include that is performed in this example:

    getServletContext().getContext 
    ("/rrd_example_v1_remote").getRequestDispatcher
    ("/invoke.jsp").include (request, response);

This is a standard request dispatcher include. However, since we have enabled RRD on this local application, as well as on the remote application, the include is seamlessly performed across application servers.


Security

Let's look at the security capabilities in RRD, including SSL (Secure Socket Layer) and Web services token propagation.

Since RRD could be transmitting sensitive information as part of the message between the local and remote servers, it is recommended that this communication take place via a SSL connection, regardless of whether the connection of the initial request was made on HTTP or HTTPS ports. To accommodate this requirement, RRD checks the security property SSLRequired. When this is enabled, SSL will always be used. If disabled, the same connection type used on the initial request will be used. RRD security settings are configurable via the rrdSecurity.props file located in <was_install>/profiles/<profileName>/properties.

Because RRD utilizes Web services, we can also leverage some of features of Web services security (WS Security) to provide propagation of security context to the remote application server. This enables usage of the javax.servlet.HttpServletRequest security methods java.security.Principal getUserPrincipal ()() and boolean isUserInRole (java.lang.String role). The LTPA token propagated by Web services contains this user principal. User-to-role mappings must be provided on both local and remote sides, as would be required between any two different Web modules. The RRD security property LTPAPropagation indicates that this functionality should be enabled. Since security is not checked on includes or forward, as per the Servlet Specfication Version 2.4 SRV.12.2, administrators can disable this property if these APIs are not required.

The RRD security property SecurityAttributePropagation can also be enabled to pass custom security tokens as attributes of the LTPA token. The security attribute propagation support uses the same pluggable JAAS Login module as in CSIv2 support. Further discussion of this WS Security feature is beyond the scope of this introductory guide. See Resources for more information.

RRD security settings are configurable via the rrdSecurity.props file located in <was_install>/profiles/<profileName>/properties. The format of this file is (default values in bold):

LTPAPropagation=( True |False)
SecurityAttributePropagation=(True|
False )
SSLRequired=(
True |False)

These properties must be identical across local and remote application servers. For changes to the rrdSecurity.props file to take effect, application servers must be restarted.

Example 2

This example builds upon the applications in Example 1, adding resource constraints and illustrating RRD's ability to propagate authorization information. To install and run the example:

  1. Enable application security using the WebSphere Application Server administrative console. (See the WebSphere Application Server V6.1 Information Center.)
  2. Install RRDExample_v2_local.ear into AppServerLocalNode, as in Step 1 of Example 1.
  3. Install RRDExample_v2_remote.ear into AppServerRemoteNode, as in Step 2 of Example 1.
  4. Using the administrative console, navigate to Applications => Enterprise Applications => RRDExample_v2_local => Security role to user/group mapping.
  5. Select LocalRole and BothRole, then Look up users.
  6. Select a user, then click OK. Save your changes.
  7. Navigate to Applications => Enterprise Applications => RRDExample_v2_remote => Security role to user/group mapping.
  8. Select RemoteRole and BothRole, then Look up users.
  9. Select a user, and click OK. Save your changes.
  10. Access the example via the URL: http://localhost:9080/rrd_example_v2_local/invoke, again changing localhost and 9080 with with appropriate values). If the example has been installed correctly, you will see the screen shown in Figure 9 after logging in as the user that you selected in Steps 6 and 9.

Figure 9. RRD with security propagation
RRD with security propagation

In this example, we enabled a resource constraint on the local servlet for the authorization role LocalRole. This in turn enabled us to propagate the security context to the example application running on AppServerRemoteNode. As the example shows, the user-to-role mappings differ for the local servlet running on AppServerLocalNode and the remote JSP running on AppServerRemoteNode.


Caching

Making an RRD call is expensive. The creation of the message that represents the request and response and the transfer of this data across the network create substantial overhead. Caching on the target server that services the RRD call is helpful, but not always sufficient to provide worthwhile performance improvements.

To enhance performance, the local machine must understand the cache rules of the remote server and know when to cache the response locally to prevent the Web services call altogether. By using existing dynacache APIs to store the RRD unique cache key to response mappings, we can prevent the remote jump for common caching scenarios. Dynacache has long been a performance feature of WebSphere Application Server. More information is available in the WebSphere Application Server Information Center.

To understand the remote cache rules, dynacache is notified by RRD to send a response header that is a representation of the remote application’s cachespec.xml file, the caching configuration file. This response header includes the rules from the cache spec that RRD supports. RRD intercepts the response contents and checks whether the response can be cached locally before sending the result back to the client. Subsequent requests can then be inspected to see if they match any previously cached entry. Disabling local caching is the best practice when the remote cache spec commonly uses rules not supported by RRD, since uncached requests have slightly more overhead. The following rules are supported when servlet caching is enabled on the local and remote machine:

  • parameters -- retrieves the named parameter value.
  • cookie -- retrieves the named cookie value.
  • header -- retrieves the named request header.
  • locale -- retrieves the request locale.
  • requestType -- retrieves the HTTP request method from the request.

Information on all rules, both supported and unsupported by RRD, can be found in the WebSphere Application Server V6.1 Information Center.

Cache rules often have a time period in which to wait to invalidate the cache entry. Remote invalidations have to be propagated back to the RRD cache to be locally invalidated. To support this invalidation, the DynaCacheEsi application must be installed on the same virtual host as the local RRD Web module. This application is provided in <was_install>/installableApps/DynaCacheEsi.ear.

Example 3

This example builds upon the applications in Example 2, demonstrating the use of dynacache in an RRD request. To install and run the example:

  1. Follow steps 1 through 9 of Example 2, using the application RRDExample_v3_local.ear and RRDExample_v3_remote.ear. Note that the user-to-role mappings in steps 4 and 7 should be performed on the applications RRDExample_v3_local and RRDExample_v3_remote, respectively.
  2. Access the example via the URL http://localhost:9080/rrd_example_v3_local/invoke, again replacing that values of localhost and 9080, as appropriate.

If the example has been installed correctly, you will see the following result, after logging in as the user selected in Step 1:


Figure 10. RRD with counter value to observe caching behavior
RRD with counter value to observe caching behavior

The counter value at the bottom of the page starts at 0 and increments with every request. If the example is accessed via the URL http://localhost:9080/rrd_example_v3_local/invoke?cache=true, dynacache will be triggered and subsequent requests will be cached. The cache spec used in this example demonstrates the use of caching based on request parameters and can be found in RRDExample_v3_remote.ear, inside RRDExample_v3_remote_web.war, as the file WEB-INF/cachespec.xml.


Extending a remote call with your own data

RRD provides a flexible mechanism that lets applications extend the RRD request by attaching custom data, enabling applications to pass specific application context to the remote system. This section presents the central extension concepts, describes the applicable Java interfaces and extension points defined by RRD, and explains the relation to the Eclipse Modeling Framework (EMF).

An RRD extension consists of an extension generator and extension handler pair. An extension generator is a Java class that is responsible for attaching one extension data element to an RRD request. After an RRD request has been received, it is the responsibility of an extension handler to process the extension data element.

Extension chains

A sequence of extension generators or extension handlers is referred to as an extension chain. RRD invokes the extension generator chain prior to initiating an RRD request. The extension handler chain is executed upon receiving a RRD request by calling each extension handler that matches some extension data that is attached to the RRD request.

An extension generator chain, as well as an extension handler chain, is defined in a respective extension point of the file plugin.xml, which can reside in one of these locations:

  • Another OSGI Bundle
  • Any shared library
  • In the WEB-INF directory of an RRD-enabled Web application.

An extension generator chain is defined in extension point com.ibm.wsspi.rrd.generators; each extension generator is defined by a generator element. Accordingly, an extension handler chain is defined in the com.ibm.wsspi.rrd.handlers extension point and each extension handler is defined by a handler element.

The generator and handler elements are made up of these attributes:

  • id -- assigns a unique identifier that correlates extension generator and extension handler; that is, matching extension generators and extension handlers must declare the same value for this attribute.
  • class -- specifies the class name of the extension generator or extension handler.
  • order -- enforces execution order in an environment where multiple descriptor files are present; each extension generator and extension handler can have an execution order associated with it.
  • type -- defines the type of the generator; currently, the value servlet has to be specified for this attribute.

Additionally, each handler element contains namespaceURI and localName attributes, the combination of which defines the qualified name of the extension element that the extension handler can process. This qualified name and the identifier specified by the id attribute are used by RRD to find the matching extension handler for an extension. Optionally, initialization parameters can be specified for an extension generator or extension handler by including zero or more init-param elements as children of the generator or handler element.

A sample extension generator declaration would be:

    <extension point="com.ibm.wsspi.rrd.generators">
    <generator id="int1" class="com.ibm.ws.rrd.example.extension.IntExtensionGenerator"
            order="1" type="servlet">
      <init-param>
        <param-name>intValue</param-name>
        <param-value>123</param-value>
      </init-param>
    </generator>
    <generator id="string1" 
               class="com.ibm.ws.rrd.example.extension.StringExtensionGenerator"
               order="2" type="servlet">
      <init-param>
        <param-name>stringValue</param-name>
        <param-value>This is an example string.</param-value>
      </init-param>
    </generator>
  </extension>

Following shows an example of an extension handler declaration:

<extension point="com.ibm.wsspi.rrd.handlers">
    <handler id="int1"
             class="com.ibm.ws.rrd.example.extension.IntExtensionHandler"
             namespaceURI="http://www.ibm.com/rrd/example/types"
             localName="ExampleType" order="1" type="servlet" />
    <handler id="string1"
             class="com.ibm.ws.rrd.example.extension.StringExtensionHandler"
             namespaceURI="http://www.ibm.com/rrd/example/types"
             localName="ExampleType" order="2" type="servlet" />
</extension>
			

Extension generators

An extension generator must implement interface ExtensionGenerator:

public interface ExtensionGenerator {
     ExtensionGeneratorConfig getExtensionGeneratorConfig ();
     void init (ExtensionGeneratorConfig config) throws RRDException;
     void doGenerate (ExtensionGeneratorRequest request,
               ExtensionGeneratorResponse response, ExtensionChain chain)
               throws RRDException, IOException;
     void destroy ();
}
			

An extension generator must obey the extension generator lifecycle:

  • initialization
  • generation
  • destruction.

When the local portion of an RRD-enabled application is initialized, the RRD extension generator descriptor is parsed, and each extension generator is initialized with a parsed ExtensionConfig object. Each extension generator is then placed in an extension generator chain. This chain is executed prior to the sending of each RRD request by calling the doGenerate method on each extension generator in sequence. Each extension generator, with the assistance of the provided ExtensionGeneratorRequest object, is then expected to attach an instance of an EMF object to either the header, body, or both, of the outbound RRD request. ExtensionGeneratorRequest, therefore, provides the respective methods setHeaderObject and setBodyObject. This EMF object is included into the RRD request and will be made available to the matching extension handler on the remote system. Afterwards, each extension generator is responsible for executing the next portion of the extension generator chain by calling the doNext method of the passed ExtensionChain object.

Once the RRD request has been received and processed by the remote RRD-enabled application, a series of extensions may be attached to the RRD response, which is received by the local RRD-enabled application. Each extension generator in the extension generator chain can potentially receive extension data from this RRD response, which can be retrieved from the provided ExtensionGeneratorResponse instance through the getHeaderObject and getBodyObject methods. After this (optional) processing has occurred, the extension generator chain execution is completed until another RRD request is created.

Upon application server termination, each extension generator will be destroyed via a call to its destroy method. At this point, any persistent resources associated with the extension generator should be released.

Extension handlers

An extension handler must implement the following interface:

public interface ExtensionHandler {
     ExtensionHandlerConfig getExtensionHandlerConfig();
     void init (ExtensionHandlerConfig config) throws RRDException;
     void doHandle (ExtensionHandlerRequest request,
          ExtensionHandlerResponse response, ExtensionChain chain)
          throws RRDException, IOException;
     void destroy ();
}
			

Extension handlers adhere to the extension handler lifecycle: initialization, handling, and destruction, which occurs as follows:

When the remote portion of an RRD-enabled application is initialized, each extension handler is initialized with a parsed ExtensionConfig object corresponding to the extension handler descriptor. Each extension handler is then placed in an extension handler chain. This chain is executed upon receiving an RRD request by calling the doHandle method on each extension handler that matches the qualified name of some extension data attached to the RRD request. Each extension handler, with the assistance of the provided ExtensionHandlerRequest object, is then expected to process the received extension data (which may be located in the header, body, or both header and body of the RRD request) in some manner. Afterwards, each extension handler is responsible for executing the next handler of the extension chain.

Once the end of the extension handler chain is reached, an RRD response will be created, and each extension handler has the opportunity to attach an EMF object to the response as extension data via the provided ExtensionHandlerResponse instance; this extension data will then be received by the appropriate extension generator on the local portion of the RRD-enabled application. After this (optional) processing has occurred, the extension handler chain execution is completed until another RRD request is received.

Upon application server termination, each extension handler will be destroyed via a call to its destroy method.

The classes GenericExtensionGenerator and GenericExtensionHandler define abstract classes which handle basic initialization and configuration methods. Both classes provide a base for new extension generator or extension handler classes, which is illustrated in Example 4.

Integration of EMF with RRD

RRD utilizes the Eclipse Modeling Framework (EMF) as a means of serializing and deserializing arbitrary extension data for use with extension generators and handlers. This approach gives RRD a great deal of flexibility and makes the process of adding extension data to remote calls easy to accomplish with off-the-shelf tooling, such as with the EMF plug-in, which is available for Eclipse. The concepts surrounding EMF are beyond the scope of this article, though the article Model with the Eclipse Modeling Framework is an excellent starting point if you are not familiar with EMF. For the purpose of this article, we will assume prior knowledge of EMF.

Once code has been generated for your model, it is nearly ready to be used with an RRD extension generator and handler pair. One important matter to note is that RRD serializes and deserializes EMF as XML data using extended metadata annotations, which is not normally the case in general EMF usage. As a result, the root element name used by EMF when extended metadata annotations are enabled is usually not desirable, and should be changed to a name that more closely resembles that which is defined in the model (though this is not a strict requirement). After you have generated model code, find the generated package implementation class (which should be a filename ending with PackageImpl.java). Locate the method createExtendedMetaDataAnnotations(). The first call to the method addAnnotation() should be changed to reflect the desired root element name. The following code, used in Example 4, illustrates this:

addAnnotation (exampleTypeEClass, source, new String[] { "name", "exampleType_._type",
"kind", "elementOnly" });

If the generated code is left as is, the extension data will be serialized and deserialized using exampleType_._type as the root element name. This is acceptable as long as the extension generator and handler extension points reflect this. However, as such, a root element name is unintuitive and therefore undesirable; in our example we will change it to ExampleType, which matches the name used in our model.

Finally, we must ensure that the generated EMF packages being used by RRD extension generators and handlers have been properly initialized prior to use. While this could be done explicitly inside of the extension generators and handlers, a much more convenient way to accomplish this is to let RRD initialize the EMF packages automatically via the com.ibm.wsspi.rrd.rrd-emf-packages extension point. So, along with the definitions of extension generators and handlers inside plugin.xml, the com.ibm.wsspi.rrd.rrd-emf-packages extension point should also be defined and contain an entry for each EMF package that must be initialized.

This is illustrated in this code sample:

<extension point="com.ibm.wsspi.rrd.rrd-emf-packages">
  <emfPackages>
    <emfPackage className="com.ibm.ws.rrd.example.types.impl.TypesFactoryImpl" />
</emfPackages>
</extension>
			

Though RRD is initializing EMF packages, each emfPackage element’s className attribute must point to the factory implementation class generated by EMF. This class ends with FactoryImpl.java. Remember that this same extension point must be defined for both the local and remote applications.

Example 4

This example builds upon the applications in Example 3, demonstrating the RRD's ability to pass along custom data through the use of extension generators and handlers. To install and run the example:

  1. Follow the steps in Example 3, using the application RRDExample_v4_local.ear and RRDExample_v4_remote.ear. The user-to-role mappings should be performed on the corresponding applications RRDExample_v4_local and RRDExample_v4_remote, respectively.
  2. Access the example via the URL: http://localhost:9080/rrd_example_v4_local/invoke, replacing localhost and 9080 with the appropriate values). If the example has been properly installed, you will see the result in Figure 11, after logging in as the user you selected:

Figure 11. RRD with extension generators sending additional data
RRD with extension generators sending additional data

The extra output in the example is produced by the extension generators and handlers. The relevant files for the local application are located in RRDExample_v4_local.ear, inside RRDExample_v4_local_web.war, as the files:

  • WEB-INF/plugin.xml -- contains the definitions for the extension generators.
  • WEB-INF/source/com/ibm/ws/rrd/example/extension/IntExtensionGenerator.java -- contains a sample extension generator that generates integer data.
  • WEB-INF/source/com/ibm/ws/rrd/example/extension/StringExtensionGenerator.java -- contains a sample extension generator that generates string data.

Similarly, the relevant files for the remote application are located in RRDExample_v4_remote.ear, inside RRDExamlpe_v4_remote_web.war, as the files:

  • WEB-INF/plugin.xml -- contains the definitions for the extension handlers.
  • WEB-INF/source/com/ibm/ws/rrd/example/extension/IntExtensionHandler.java -- contains a sample extension generator that handles integer data.
  • WEB-INF/source/com/ibm/ws/rrd/example/extension/StringExtensionHandler.java -- contains a sample extension generator that handler string data.

The file RRDExample_v4_types.src.jar contains the models and generated EMF source code used to manipulate the extension data types leveraged by this example. Both sections Extending a remote call with your own data and Integrating EMF with RRD contain information on the manner in which extension generators and handlers are created and used by RRD.


Portal aggregating remote portlet

Remote Request Dispatcher can also be used together with portlets. For this, we leverage the portlet aggregation framework that comes along with the portlet container in WebSphere Application Server V6.1. (Aggregation capabilities are detailed well in the article Exploiting the WebSphere Application Server V6.1 portlet container, Part 2.)

The portlet aggregation framework enables aggregating multiple portlets on one page using a tag library. The framework leverages the URL addressability feature to include portlet application. Include is meant literally in this context, because the framework uses the include method of the servlets request dispatcher. Consequently, the Remote Request Dispatcher applies to this scenario as well.

To use RRD for portlets, we need one portal framework application, at least one portlet application, and a deployment setup, as mentioned in the previous sections. The portal framework has to be deployed with the Allow dispatching includes to remote resources option, and the portlet application has to be installed into a different server with the Allow servicing includes from remote resources option.

Example 5

The example application consists of one application that uses a JSP to render a table with two columns, each column containing one instance of the world clock portlet (which can be downloaded from the article Exploiting the WebSphere Application Server V6.1 portlet container: Part 1. ).

Using the same setup as in the previous section, we install the RRDSamplePortal.ear into server AppServerLocalNode. You must check the option Allow dispatching includes to remote resources, otherwise remote request dispatching will not work.

After both applications have been installed and started, we can access the portal application with: http://localhost:9080/sample/portal. Figure 12 shows how the portal application looks after everything has been correctly deployed.


Figure 12. Aggregation of two portlets using RRD
Aggregation of two portlets using RRD

Conclusion

Remote request dispatching provides increased flexibility for application deployment by enabling applications to be installed anywhere within the WebSphere Application Server Network Deployment core group without requiring significant changes to the applications. By leveraging this increased flexibility, applications can be better isolated from each other, minimizing the single point of failure that is common for most Web-based applications.



Download

DescriptionNameSizeDownload method
Sample applicationrrd_article_examples.zip156 KBHTTP

Information about download methods


Resources

Learn

Get products and technologies

About the authors

Stephan Hesmer is currently working as Performance Chief Developer. In his previous role he worked as Portlet Runtime architect in WebSphere Portal and WebSphere Application Server. He is responsible for integrating the JSR 168 portlet container into WebSphere Application Server. Stephan worked on the JSR 168 Java™ Portlet Specification, and designed and implemented the initial version of the JSR 168 Reference Implementation, Pluto. Stephan received a Diploma of Information Technology from the University of Cooperative Education Stuttgart, Germany, in 2000. After graduating, he joined the IBM Böblingen Development Laboratory to work in the WebSphere Portal Team.

Curtiss Howard is currently working as a member of the WebSphere Administrative Console, WebContainer, and RRD teams. He joined IBM WebSphere Application Server in 2005 after graduating from North Carolina State University with a degree in Computer Science.

Maxim Moldenhauer is currently working as a member of the WebContainer and RRD teams. Maxim has been the WebContainer focal point for SIP Container integration and architected the current WebContainer test suite framework. He joined IBM WebSphere Application Server in 2003 after graduating from Virginia Tech with a degree in Computer Science.

Todd Kaplinger is currently working as Architect and Team Lead of the WebContainer and RRD Teams for the WebSphere Application Server. Todd has worked on the JSR 154 Servlet 2.5 Specification and is IBM’s representative in the Servlet Expert Group.

Timo Kussmaul is currently working as software developer in WebSphere Application Server and WebSphere Portal. He joined IBM in 1997 after graduating from University of Stuttgart with a diploma in Computer Sciences. Timo wrote three books on application software and software development.

Comments



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=155111
ArticleTitle=IBM WebSphere Developer Technical Journal: Include remote files in your Web application seamlessly with the new Remote Request Dispatcher
publish-date=08232006
author1-email=stephan.hesmer@de.ibm.com
author1-email-cc=
author2-email=cjhoward@us.ibm.com
author2-email-cc=
author3-email=mmolden@us.ibm.com
author3-email-cc=
author4-email=todkap@us.ibm.com
author4-email-cc=
author5-email=TIMO@de.ibm.com
author5-email-cc=

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular type of content or application that you're viewing.

My tags shows your tags for this particular type of content or application that you're viewing.

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular type of content or application that you're viewing. My tags shows your tags for this particular type of content or application that you're viewing.

Special offers