Configuring and Running the BeenThere Sample


Getting started
Adding the application server nodes
Creating the Web container cluster
Creating the EJB container cluster
Updating the virtual host
Enabling the WebSphere configuration service
Installing the BeenThere.ear file
Configuring security (optional)
Starting the servers
Running the Sample
Verifying the Sample configuration


Getting started

This section describes the steps for configuring the environment, as depicted in Figure 1, and installing and running the BeenThere Sample. It is assumed that the following software is already installed:


Machine Name Software Installed
web IBM HTTP Server
IBM HTTP Server plug-in
app1 IBM WebSphere Application Server
app2 IBM WebSphere Application Server
dm IBM WebSphere Application Server deployment manager


Note:The following instructions assume that the Web server and its administration service are running, and that a Web server definition has been created on the deployment manager to automatically propagate the plugin-cfg.xml file.



Adding the application server nodes

Complete the following steps to add the application server nodes into the cell:


  1. Start the deployment manager.
  2. At the command line on one of the machines where an application server is installed, type the following command (install_root/bin must be in your PATH environment variable, where install_root is the WebSphere Application Server Base installation root):

    On Windows platforms:
    addNode <deploymgr host>

    On Linux and UNIX platforms:
    addNode.sh <deploymgr host>

    On iSeries platforms:
    install_root/bin/addNode <deploymgr host> <deploymgr port> -profileName <profileName> -startingport <portblock>

    where:
    <deploymgr host> is the name of the host running the deployment manager.
    <deploymgr port> is the SOAP connector port for the deployment manager.
    <profileName> is the profileName of the Application Server to be added to the deployment manager.
    <portblock> is a block of unused ports. Used to avoid port conflicts in a multiple instance environment.

  3. Repeat this procedure on the machine where the second WebSphere Application Server instance is installed.

The application servers are now incorporated into the cell.



Creating the Web container cluster

The MyWebCluster cluster provides workload balancing and failover for servlets.

Complete the following steps to create the MyWebCluster cluster:


  1. Open the administrative console web address, http://<host_name>:9060/ibm/console in a browser, where <host_name> is the host name or IP address where the deployment manager is running.
  2. In the administrative console, click Servers > Clusters.
  3. Click New.
  4. Type MyWebCluster in the Cluster name field.
  5. Click Next.
  6. Enter the following values:
  7. Click Next.
  8. Enter the following values:
  9. Click Apply.
  10. Click Next.
  11. Click Finish.
  12. Click Save at the top of the main panel in the administrative console.
  13. Select checkbox toSynchronize changes with Nodes.
  14. Click Save.

The MyWebCluster cluster is now created.



Creating the EJB container cluster

The MyEJBCluster cluster provides workload balancing and failover for enterprise beans.

Complete the following steps to create the MyEJBCluster cluster:


  1. Click Servers > Clusters.
  2. Click New.
  3. Type MyEJBCluster in the Cluster name field.
  4. Clear the Prefer local enabled check box.

    Note:On a distributed platform, selecting the Prefer local option indicates that the request routes to the enterprise bean running on the local node, if available. The Prefer local option is disabled in the Sample configuration to demonstrate the workload management of EJB requests.

  5. Click Next.
  6. Enter the following values:
  7. Click Next.
  8. Enter the following values:
  9. Click Apply.
  10. Click Next.
  11. Click Finish.
  12. Click Save at the top of the main panel in the administrative console.
  13. Click Save.

The MyEJBCluster cluster is now created.



Updating the virtual host

During the creation of the MyWebCluster cluster, the Generate Unique Http Ports option is selected for each new cluster member. Selecting this option avoids HTTP port conflicts by creating a unique port value for each of the new application servers that is created.

Complete the following steps to ensure that each HTTP port value that is dynamically created has an associated host alias entry configured for the default_host virtual host:


  1. In the administrative console, click Servers > Application servers > WebServer1 > Web Container Settings > Web container transport chains > WCInboundDefault.
  2. Take note of the host and port values for the entry where SSL is disabled.
  3. Click Environment > Virtual Hosts > default_host > Host Aliases.
  4. Verify that the Host Aliases list contains the host name and port values from step 2. For values not listed, follow these steps:
    1. Click New.
    2. Type the host name and port using the values previously noted.
    3. Click Apply.
    4. Click Save at the top of the main panel in the administrative console.
    5. Click Save.
  5. Repeat this procedure for WebServer2.

The virtual host is now updated.



Enabling the WebSphere configuration service

The WebSphere configuration service is not enabled for application servers by default. The Sample requires this service to programmatically read WebSphere Application Server configuration files to obtain environment information.

Complete the following steps to enable the WebSphere configuration service:


  1. Click Servers > Application Servers > WebServer1 > Server Infrastructure > Administration > Administration Services > Custom Properties.
  2. Click New.
  3. Enter the follow values:
  4. Click Apply.
  5. Click Save at the top of the main panel in the administrative console.
  6. Click Save.
  7. Repeat this procedure for WebServer2.

The WebSphere configuration service is now enabled.



Installing the BeenThere.ear file

Complete the following steps to install the BeenThere.ear file:


  1. In the administrative console, click Applications > Install New Application.
  2. Select Remote File system and then Browse....
  3. Select the node for the deployment manager.
  4. Select the <install_root>/samples/lib/BeenThere/BeenThere.ear file, where <install_root> represents the installation directory of the deployment manager.
  5. Click OK.
  6. Click Next.
  7. Verify that the virtual host is set to Default virtual host name for web modules and default_host.
  8. Click Next.
  9. Click Continue.
  10. Select the Map modules to servers step.
  11. Select the MyWebCluster cluster and the Web server from the Clusters and Servers list.
  12. Select the BeenThere WAR module.
  13. Click Apply.
  14. Select the MyEJBCluster cluster and the Web server from the Clusters and Servers list.
  15. Select the BeenThere EJB module.
  16. Click Apply.
  17. Click Step 8 (Summary).
  18. Click Finish.
  19. Click Save to Master Configuration.
  20. Click Save.


Configuring security (optional)

If you do not want to use BeenThere with security, you can skip this section. To use BeenThere with security, click here for instructions on configuring security.



Starting the servers

Complete the following steps to start the servers:


  1. Click Servers > Clusters.
  2. Select the MyWebCluster and MyEJBCluster clusters.
  3. Click Start.

The servers are now started.



Running the Sample

To run the Sample, open the BeenThere web address, http://<host_name>/wlm/BeenThere in a browser, where <host_name> is the host name or IP address where IBM HTTP Server is running.





Verifying the Sample configuration

Note that in WebSphere Version 6 and later, there exists new function which is designed to maximize the throughput of the entire environment. What this ultimately means is that when testing the BeenThere Sample on these versions, The Workload Management component may not route the requests strictly to the exact value of the weights. The weights may be modified at runtime so the verification methods below can be incorrect. In these scenarios, the best method to verify WLM function is to ensure that requests are being routed to all the cluster members, irregardless of whether that routing is being done strictly by the weights. There are also methods to disable these feedback mechanisms, contact IBM support for more details if this is necessary.


Complete the following steps to verify that Web container workload management is working correctly as configured:


  1. Open the BeenThere web address, http://<host_name>/wlm/BeenThere in a browser, where <host_name> is the host name or IP address where the IBM HTTP Server is running.

  2. Note the values in the servlet run summary. An example of this summary is provided:

  3. Reload the BeenThere page in the browser.

    The values in the servlet run summary change, as demonstrated in the following example:


    The servlet node should is now app2 instead of app1. The results show that IBM HTTP Server dispatched the HTTP request to the other member of the MyWebCluster cluster, namely WebServer2 on app2. Repeated runs of the servlet reveal a workload management behavior of the HTTP requests based on the configured weight values for the cluster members of MyWebCluster cluster.

The Web container workload management configuration is now verified.


Complete the following steps to verify that EJB container workload management is working correctly as configured:


  1. Select the Display servlet and bean run summaries option for running the BeenThere servlet.
  2. Enter 7 in the Bean invocations field.
  3. Click Run.

    On a distributed platform, the values in the bean run summary should be similar to the following example:


    From this example, you can see the workload management run behavior of the enterprise bean based on the configured weight values for the cluster members of the MyEJBCluster cluster. Three invocations of the enterprise bean run on app2 for every single invocation run on app1.

    On the z/OS platform, weight values are used to balance HTTP requests, but are not used to balance Internet Inter-ORB Protocol (IIOP) requests.

The EJB container workload management configuration is now verified.


Complete the following steps to verify that the member weights of the bean cluster are set correctly, as configured.


  1. Select the Display bean cluster member weights option for running the BeenThere servlet.
  2. Click Run.

    Compare the results to the following example:


    The results show the weight values for all the members of the MyEJBCluster cluster. EJBServer1 has a weight of 1 and EJBServer2 has a weight of 3.

The bean cluster member weights are now verified.


Congratulations, you have now seen workload management in action and verified that the BeenThere Sample is working correctly as configured!