Manage Your Applications @ WEBSPHERE JOURNAL

Manage Your Applications

There are significant benefits to clustering servers in a Java 2 Enterprise Edition (J2EE) environment. Increased performance through scaling of cluster members, higher availability and reliability through automatic failover techniques, and load balancing through the use of workload management technology are the primary benefits of clustering. Given that you have deployed your application in such an environment, how do you know that your application is servicing clients in the manner that you expect for your configured environment? How can you see which server is executing a client request?

The purpose of this article is to demonstrate how a J2EE application executing in an IBM WebSphere Application Server (WAS) version 5.0 Network Deployment (ND) Edition environment can obtain runtime information about the server it is executing in. This application, referred to as the BeenThere Workload Management Demonstration application, is used to allow you to actually see workload management (WLM) of HTTP requests and of Enterprise JavaBean (EJB) requests. The underlying systems management infrastructure in WAS is based on the Java Management Extensions (JMX), which provide a standard framework for applications to obtain and modify runtime and system configuration, as well as providing operational control of the entire environment. It is through the use of JMX that the BeenThere application obtains application server runtime information programmatically.

BeenThere Workload Management Demonstration Application
WebSphere Application Server Version 5.0 ND Edition provides workload management of HTTP requests and EJB requests. WLM of HTTP requests is done through the use of the WebSphere Web Server plug-ins. The BeenThere application (being used for this discussion) contains the BeenThere servlet, which is used to demonstrate to which application server in a cluster an HTTP request was dispatched.

Load balancing of EJB requests is managed by the WebSphere WLM Service. The BeenThere application contains the Been-There stateless session EJB used to demonstrate to which application server in a cluster an EJB request was dispatched.

Consider the configuration shown in Figure 1. First, mjmaix is a machine that is executing an IBM HTTP Server (IHS) that will dispatch HTTP requests to the application servers WebServer1 and WebServer2, which make up the members of the cluster, MyWebCluster, and are executing the BeenThere servlet. These application servers are configured on machines mjmnet and mjmthink, respectively.

Furthermore, the WebSphere IHS plug-in has been configured such that WebServer1 has a WLM weight of 2 and WebServer2 has weight of 3. You can think of the weights as counters that start at their configured value and get decremented by 1 after each request the server services. Requests get dispatched in a round-robin fashion to any application server that currently has a weight counter value greater than 0. If the value is 0, it is skipped. Once all weight counters are decremented to 0, then all application server weight counters are reset to their configured value and the dispatch process starts all over again.

Then there is a MyEJBCluster cluster defined that is made up of the application server members EJBServer1 and EJBServer2, which are responsible for executing the BeenThere stateless session EJB. The BeenThere servlet makes a call to the EJB to obtain execution information about the application server in which the EJB is executing. Furthermore, these servers have been configured with weight values of 1 and 3, respectively.

Note that this configured environment is a sample that is being used just for demonstrating the execution of the BeenThere Workload Management application. In a production environment, careful resource capacity planning must be done to determine how many application server members should be created across how many machines based on the expected client request load.

Figure 2 is a screen shot of the execution of the BeenThere servlet for the configuration depicted in Figure 1. A Bean Iterations value of 7 was specified, which means the servlet made 7 invocations of the BeenThere EJB. From this, you can see the workload management execution behavior of the EJB based on the configured weight values for the cluster members of MyEJBCluster. Three invocations of the EJB execute at mjmthink for every single execution on mjmnet. Also notice that the servlet request was serviced by WebServer1 on mjmnet. Furthermore, to add a little interest to the application, Show Bean Execution Statistics was set to true to display, in milliseconds, how long it took for each EJB execution instance and the overall execution statistics.

Figure 3 is a screen shot of the use of the Show Bean Cluster Member Weights option. This displays the weight values for all the members of MyEJBCluster. Later in this article, I will discuss how the application programmatically obtains this configuration information.

Executing the BeenThere servlet a second time, as shown by Figure 4, results in IHS dispatching the HTTP request to the other member of MyWebCluster, namely WebServer2 on mjmthink. Repeated executions of the servlet will reveal a workload management behavior of the HTTP requests based on the configured weight values for the cluster members of MyWebCluster.

Administrative Application Programming Interfaces
WebSphere Application Server version 5.0 provides administrative APIs that allow applications to access runtime and environment configuration information:

AdminService: Provides the server-side interfaces to obtain application server attribute information, as well as the ability to perform standard JMX MBean management functions.

AdminClient: Provides the client-side interfaces to a remote AdminService. The AdminClient class provides a proxy to the remote AdminService object through one of the supported WebSphere JMX connectors.

ConfigService: The Configuration Service that provides interfaces to query or modify configuration data, locally or remotely, and manages the location and the content of WebSphere's configuration documents.

In order to demonstrate the power and flexibility that applications have at their disposal when using WebSphere's administrative interfaces, the BeenThere application utilizes these interfaces in the following ways:

AdminService: Both the BeenThere servlet and EJB use this interface to obtain the node name, the application server name, and the process ID for the application server they are executing in. See Listing 1 for a code segment demonstrating this.

AdminClient: Used to connect to the Deployment Manager process to retrieve the Cluster Member Weight values for all the application server members of the cluster executing the BeenThere EJB. See Listing 2 for a code segment demonstrating how to obtain an instance of AdminClient.

ConfigService: Used for a couple reasons. First, it is used to read the WebSphere cell.xml configuration document in order to determine if the BeenThere application is executing in a WebSphere Base Edition or Network Deployment Edition environment (see Listing 3). If an ND environment is detected, then the Show Bean Cluster Member Weights option will be enabled and displayed as an available execution option since this is only valid in this type of environment. Otherwise, this option will not be displayed as a selectable execution option. The second use of the ConfigService is to read the WebSphere serverindex.xml configuration document locally to obtain the hostname of the machine running the Deployment Manager and to obtain the port value of the SOAP connector that is used to make the JMX connection to the AdminService object of the Deployment Manager. An AdminClient instance is created using this connection information in order to retrieve the weight values of the cluster members if requested by a user.

Configuring the WebSphere Application Server Environment
This section outlines the steps necessary to configure the environment as depicted in Figure 1, and install the BeenThere application using the WebSphere Administrative Console. It is assumed that an IBM HTTP Server, WebSphere Network Deployment, and two WebSphere Node machines have already been installed. Furthermore, if an option on a console panel is not mentioned below, it is assumed that the default value is adequate.

The BeenThere application can be downloaded from www.sys-con.com/websphere/sourcec.cfm.

Create the Cluster MyWebCluster
1.   From the console, choose Servers -> Clusters -> New.
2.   In the Cluster Name dialog, specify MyWebCluster, then select Next.
3.   To create new clustered servers, enter WebServer1 for the Name, then select the Node. (Select the desired machine in which to create your server. In my case I selected mjmnet.) Enter "2" for the Weight. From the Http Ports menu, choose Generate Unique Http Ports. Select Default application server template (server1) from the Select Template menu, then select Apply. For the second server, enter WebServer2 for the Name, then select the Node. (Select the desired machine in which to create your server. In my case I selected mjmthink.) Enter "3" for the Weight. From the Http Ports menu, choose Generate Unique Http Ports. Select Apply, and then select Next.
4.   Select Finish, then select Save. Check the Synchronize Changes with Nodes check box. Select Save.

Create the Cluster MyEJBCluster
1.   From the console choose Servers -> Clusters -> New.
2.   Enter basic cluster information: for Cluster Name enter MyEJBCluster. Uncheck the Prefer local check box to disable node-scoped routing optimizations. (When enabled, this option specifies whether enterprise bean requests are routed to the node on which the client resides. For demonstration purposes we want the BeenThere application to exhibit workload management without enforcing this optimization so it can be demonstrated that a servlet request to one member of MyWebCluster will dispatch an EJB request to a member of MyEJBCluster on another node.)
3.   Create new clustered servers: for the name enter EJBServer1. For Select Node select the desired machine in which to create your server. In my case I selected mjmnet. For Weight enter 1. From Select Template choose Default application server template (server1). Select Apply. For the second server, enter EJBServer2 as the name. For Select Node select the desired machine in which to create your server. In my case I selected mjmthink. For Weight enter 3. Select Apply, then select Next. Select Finish, Save, and then Save again.

BeenThere Application Installation
1.   From the console choose Applications -> Install New Application. To prepare for application installation you must select a local path; browse for the BeenThere50.ear file, then select Next. Leave the default virtual host name for Web modules (default_ host) selected and choose Next.
2.   For Step 1, "Provide options to perform the installation," select Next.
3.   For Step 2, "Provide JNDI Names for Beans," select Next.
4.   For Step 3, "Map EJB references to Beans," select Next.
5.   For Step 4, "Map virtual hosts for web modules," select Next.
6.   For Step 5, "Map the modules to application servers," first select the cluster, MyWebCluster. Check the check box for the BeenThere WAR. Select Apply. Now select the cluster, MyEJBCluster. Check the check box for the BeenThere EJB. Select Apply, and then select Next.
7.   For Step 6, "Ensure all unprotected 2.0 methods have the correct level of protection," select Next, then Finish.
8.   Select Save to Master Configuration, then select Save.

Update the Virtual Host
Each application server has its own HTTP transport that receives and responds to HTTP requests. Therefore they must be configured to use a unique hostname and port value for communication. During the creation of the cluster MyWebCluster, the option "Generate Unique Http Ports" was selected for each new cluster member. This option instructs the WebSphere administration to assist with avoiding HTTP port conflicts by creating a unique port value for each of the new application servers being created. It is through the use of a Virtual Host that a single machine can appear to resemble multiple host machines.

Each virtual host has a logical name and a list of associated host aliases where a host alias consists of a TCP/IP hostname and port value that define the HTTP transport channel to be used for an application configured for the logical virtual host. As is the case with the BeenThere application, it has been configured to use the virtual host default_host, therefore you must ensure that the HTTP port value dynamically created has an associated host alias entry configured for the default_host virtual host.
1.   Still using the WebSphere Administrative Console, determine the HTTP port values that were dynamically created: choose Servers -> Application Servers -> WebServer1 -> Web Container -> Http Transports.
2.   Take note of the Host and Port values and now perform the following to configure a host alias entry for the default_host virtual host: choose Environment -> Virtual Hosts -> default_host -> Host Aliases.
3.   Create a new Host Alias entry using the host and port values determined for WebServer1.
4.   Repeat this procedure for WebServer2 to ensure default_host is now correctly configured.

Generate the HTTP Server Plug-In File
1. Choose Environment -> Update WebServer Plugin.
2. You have two choices here:

For this scenario, selecting OK will create the plugin.cfg.xml file and place it in the directory <WAS_ROOT>/config/cells on the machine running the Network Deployment Manager. This is convenient if you are also running your HTTP Server on the same machine, since the HTTP Server will detect that the plugin-cfg.xml file has been updated and automatically reload it. So if your server is configured to refer to this location, it will dynamically reload the new configuration every time you select OK.

Alternatively, if you are running your HTTP Server on a separate machine, you can select View to then perform a save from the browser to save the plugin-cfg.xml file to the machine on which you are using your browser. In my case, I am running the IBM HTTP Server on the machine mjmaix, so using a browser on that machine, I use this method to save a new plug-in-cfg.xml file.

Enabling the WebSphere Configuration Service
The WebSphere Configuration Service by default is not enabled for application servers. As mentioned previously, the BeenThere application requires this service to have the ability to programmatically read WebSphere configuration files to obtain environment information. Perform the following steps in the WebSphere Administrative Console to enable this service:
1.   Choose Servers -> Application Servers -> WebServer1 -> Administration Services -> Custom Properties -> New.
2.   In the Name dialog box, enter "com.ibm.websphere.management.enableConfigMBean". Select Next.
3.   In the Value dialog box, enter "true". Select Apply, then select Save, and again select Save.
4.   Repeat this procedure for WebServer2.

Start Your Servers!
From the console, select Servers -> Clusters. Check the MyWebCluster and MyEJBCluster check boxes. Then select Start.

In the IBM HTTP Server configuration file httpd.conf, ensure it refers to the correct location of the newly generated plugin-cfg.xml file and start the HTTP Server if it is not already started. If it is already started, it will automatically detect that the plugin-cfg.xml file has been updated and reload it.

Congratulations! You should now be able to see workload management in action by entering the URL http://<servername>/wlm/beenthere, where servername is the name of the machine running your IBM HTTP Server.

Conclusion
WebSphere Application Server Workload Management technology provides an enterprise-level platform for J2EE applications that demand a scalable, highly available environment. Verifying that your application is executing in a manner that is expected for your configuration can easily be done by utilizing WebSphere's administrative APIs, as was shown through the use of the BeenThere demonstration application. This application allowed you to see workload management of HTTP and EJB requests in action.

Related Links

About Michael Morton