Thoughts on enterprise IT

Dustin Amrhein

Subscribe to Dustin Amrhein: eMailAlertsEmail Alerts
Get Dustin Amrhein: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, Apache Web Server Journal, Java Developer Magazine, WebSphere

J2EE Journal: Article

Using the IBM WebSphere Application Server, Advanced Edition

Using the IBM WebSphere Application Server, Advanced Edition

In previous chapters, we learned how to use the IBM WebSphere Test Environment (WTE) inside VisualAge for Java to create and to test servlets. Now we need to understand how to use our servlets outside a test environment. This can be accomplished by deploying our servlets to the IBM WebSphere Application Server, Advanced Edition (WASAE). The WTE is used at development time, whereas the WASAE is used for staging or production purposes.

About the Book
Enterprise Javatm Programming with IBM WebSphere (with CD-ROM)
By Kyle Brown, Gary Craig, Greg Hester, Jaime Niswonger, David Pitt, Russell Stinehour
Addison Wesley Professional
ISBN 0201616173

You may purchase this book with a 10% discount at:

The IBM WebSphere Application Server, Advanced Edition, provides the necessary tools to deliver J2EE-based applications. The IBM WASAE allows a machine—more commonly called a node—to host multiple application servers. Within each application server, both an EJB container and a servlet engine—known in J2EE parlance as a Web container—can exist. Within a servlet engine, multiple Web applications can be defined. Specifically, this chapter covers

  • WASAE architecture
  • Testing the WASAE installation
  • Using the administration console
  • Using the XMLConfig tool
  • Configuration issues
WASAE is available on Windows, Novell, UNIX, and OS400 platforms. For this chapter, we demonstrate installation only under Windows NT.
However, we point out where configuration steps differ in other environments, such as UNIX.

WASAE Architecture
IBM WASAE, is based on the J2EE specification. Most J2EE products provide a container for each application component type: application client container, applet container, Web component container, and Enterprise Bean container. WASAE provides out-of-the box support for all the containers except the applet container. However, WASAE provides this support, using the IBM Java 1.2.2 Java runtime environment (JRE) with enhancements. We discuss applet deployment issues in a later chapter. Figure 6.1 shows the J2EE architecture.

WASAE is designed for a multinode—multiple-machine—environment. WASAE defines an additional container called a WebSphere domain, which consists of a collection of nodes that can be configured and administered together. All the configuration data for all the nodes contained in a WebSphere domain is kept in a single, shared—but, ideally, replicated—repository. This repository, known as the WAS database, is kept in an RDBMS.2 Using a single database for all configuration data provides a single point of communication for all nodes and enhances the possible solutions for workload management and balancing, replicated services, and maintenance. Additionally, using a single database for all configuration data greatly decreases maintenance. If each node had its own set of configuration files, you would have to edit the files on each node individually in order to administer it. In WebSphere’s model, a shared repository contains all the configuration data, so you can manage the configuration remotely from a desktop because WASAE implements its configuration objects as EJBs, using its own EJB support. Therefore, access to the configuration data by multiple nodes is controlled through the use of the transactional and persistent capabilities of the EJB Entity Beans. This access is done through RMI over IIOP, which allows the configuration to be managed securely over the Internet.

Within each node, WASAE allows multiple application servers to be configured. Each application server may contain a servlet engine—a J2EE Web container—and an EJB container. Both the servlet engine and the EJB container within a particular application server operate within a single shared Java Virtual Machine (JVM). Application servlets and various other Web-based services are defined within the context of the servlet engine. EJBs are deployed within the EJB container. A sample WebSphere domain is shown in Figure 6.2. Note that this domain contains three nodes and that you are shown an exploded view of node 1. Also note that only node 3 contains a Web server.3

Because WASAE was designed to work in a multinode environment, you must understand the requirements for each node. Minimally, each node in a WebSphere domain must contain an instance of the WebSphere admin server. The admin server performs many functions, including starting, stopping, and monitoring all configured application servers and providing a location service daemon (LSD), a persistent name server (PNS), and a security server. In addition, the so-called nanny process, a watchdog process, restarts the admin server in case of failure.

In Figure 6.2, node 3 contains a Web server. As is shown, it is not necessary to have the Web server on all nodes. If an HTTP request is sent to node 3, the Web server uses the WebSphere plug-in, possibly with an additional servlet redirector to route the request to the appropriate local or remote application server. The local node then services the request, if possible, or routes it to the proper node, based on the configuration data contained in the EJB Entity Beans using the database.

Some Definitions of WebSphere Components
Now that you have seen the overall architecture of WebSphere’s process architecture, it’s a good time to learn some of the more detailed definitions of the WebSphere components you will use and how they are configured in WebSphere, Advanced Edition. You will learn about the topology view of the WebSphere administrative console, a view arranged as a tree of configuration objects. But before you begin looking at the view, let’s examine the following objects you will see:

  • Domain: the root of the WebSphere configuration tree. A domain is a set of nodes that all share a single administration database: a single shared WAS database.
  • Node: a server machine. Each node is uniquely identified within the domain by its network name, such as its TCP/IP host name. Server processes—called managed servers in WebSphere—run within a node. WebSphere defines two types of managed servers: an application server, a Java process; and a generic server, or any process, such as a CORBA server or an RMI server. All the processes managed on a node by WebSphere may be started or stopped by a single command in the administrative interface.
  • Application server: a JVM that is managed by WebSphere. Each application server may contain a servlet engine and an EJB container.
  • Servlet engine: a Web container as defined in J2EE. An application server that contains a servlet engine thus has the infrastructure and the classes to execute servlets. A servlet engine contains a set of Web applications, which are isolated logical groups of servlets.
  • Web application: a number of common objects brought together into a unified representation of an application. A Web application may contain a group of logically connected servlets and also defines a class path that the servlet class files and associated files are taken from. The Web application also defines a JSP processor that indicates how JSPs will be interpreted, such as using the JSP 0.91 or the JSP 1.0 specification. In addition, the Web application defines a root URI, which will be a part of the URI of all the servlets it contains, indicating the logical grouping within the URL. Finally, the Web application defines a document root path to locate the JSPs used by this Web application.
  • Servlet: the servlet at the bottom of this particular branch of the topology tree. Servlets can be accessed in a Web application in one of two ways. The most common, and most maintainable, way is to individually define servlets by specifying the servlet class name and servlet name, as well as a set of URLs that the servlet will be identified by. Servlets may also be defined within a Web application by including a special servlet, called the “Invoker” servlet, which allows servlets to be invoked with a URL containing their fully qualified class name.
1. Note that whereas servlets and JSPs can be deployed into WebSphere Application Server, Standard Edition, we discuss the capabilities only of WASAE in this chapter.

2. In WASAE version 3.5, the WAS database can be installed in IBM DB/2, Oracle, or Sybase for standalone or networked use or in the Instant DB database for standalone use.

3. WebSphere supports multiple options for separating the Web server from the application server. The configuration and setup of these options is beyond the scope of this book. See [Ueno] for details.

4. [ROOT_DIR] is usually a drive letter under Windows NT or a directory mount point under UNIX.

5. If you forget to launch the admin server before opening the administrator's console, you will see a dialog box informing you "The Admin Client failed to connect to the admin server." If this happens, first start the admin server and then try opening the administrator's console.

6. Note that it is a best practice not to use the "Invoker" servlet. We will describe these and more best practices later. Nonetheless, we will use this servlet in our example.

7. This lookup is through the "ServletContext.get Context(String uri)" method, which returns a Servlet Context for a particular root URI.

Testing the Installation
Once WASAE is installed, you can then test the installation to ensure that everything is functioning correctly. In this section, you will test the installation of the WASAE by using the default server, which can automatically be installed for this purpose.

Before You Start the Admin Server
During the installation of an admin server on a node, the WAS database must be identified. Specifying a JDBC URL and a JDBC driver class identifies the database. This information is stored in the admin.conf file, which can be found in the [ROOT_DIR]\WebSphere\AppServer\bin directory, where [ROOT_DIR] is the root directory where the admin server is installed.4ýFor learning purposes, it is best to start with one node before creating a multinode environment. Here, we will assume that only one node exists in the WebSphere domain and that the WAS database is located on the node itself. If the WAS database is implemented in DB2, using the default database name, you will find the following lines in the admin.conf file:

If you want to force the admin server to create the default server application server when it starts, ensure that the install.initial.config property is set to true, as in the following line:


If you have problems because the database becomes corrupted, you may have to drop and recreate the database. To do this, open a DB2 Command window and use the following DB2 commands.

REM ensure DB2 has the correct computer name
setdb2n.exe %computername%
REM Drop the existing WAS database
DB2 DROP Database WAS
REM create a new WAS database
REM increase the application heap size to 256

At this point, the admin server has been reinitialized. If you ever need to reinitialize the server again, you can perform these same steps. However, you may want to use the XMLConfig tool, described later, to obtain an export of the configuration data so that it can be reimported into the new configuration database.

Starting the Admin Server
Most commonly, the admin server is started from NT services in Windows NT. The service is named IBM WS Admin Server. A shortcut to this service is in the Start menu of Windows NT under IBM WebSphere.Ap-plication Server V3.5>Start Admin Server. If you need to debug the admin server, you can also start it from a command line window. You will find a batch file that can be used to start the admin server in [ROOT_DIR]\WebSphere\AppServer\bin\debug\adminserver.bat, where [ROOT_DIR] is the root directory where the admin server was installed.

Opening the Administrator’s Console
The primary tool used to view and to change the configuration of a WebSphere domain is the WebSphere administrator’s console, a Java-based application that acts as a client to the configuration EJBs that are running in the admin server. In WebSphere 3.5, an administrator’s console can connect to any available admin server in the domain. In this chapter, we assume that the default configuration, in which the administrator’s console connects to an admin server on the same node, will be followed. To start the administrator’s console under Windows NT, choose IBM WebSphere.Application Server V3.5.Administrator’s Console from the Windows NT Start menu.5

Starting the Default Server
When the admin server is started, it automatically starts all the application servers that were in the “started” state before the admin server was last shut down. If this is the first time that you have started the admin server, the default server application server will not automatically start. Instead, you must ensure that it is started. In order to start a server, you must open the administrator’s console as described earlier. The WebSphere Advanced Administrative Console is shown in Figure 6.3.

Select the Default Server. To start this application server, click the Start button. When the server has started, the dialog shown in Figure 6.4 will be displayed.

Starting the Web Server
The last thing that has to be done is to start the Web server. WebSphere supports a number of Web servers, including IBM’s HTTP server, which is supplied with WASAE, and Web servers from Microsoft, Netscape, and the Apache consortium. The Web server will listen, by default, on port 80 for HTTP requests and will forward any requests for servlets through the WebSphere plug-in to the applicable application server. From the NT Services panel, select IBM HTTP Server, and then start it. If you are using a Web server other than the IBM HTTP server, start it by following the instructions provided by the Web server manufacturer.

Test Using the “Snoop” Servlet
The “Snoop” servlet echoes back to the Web browser the details of the request, the requested server, and the servlet context. This servlet is part of the initial configuration that comes with the default server. In order to invoke “Snoop” servlet, open a Web browser and type http://localhost/servlet/snoop on the URL line of the Web browser. If WebSphere is installed correctly, the “Snoop” servlet will display a response as shown in Figure 6.5

Creating the “EmployeeSys” Application Server
Now that you have verified that the WASAE product is installed correctly, you need to create a new application server for the book’s case study. The case study defines an application server named “EmployeeSys” that contains both an EJB container and a servlet engine (Web container). Additionally, the servlet engine defines a Web application with a root URI of /TimeApp. The steps that follow will help you to export the Java classes from VisualAge for Java and to configure the “EmployeeSys” application server in WASAE.

1. From the Projects tab in the VisualAge for Java Workbench, select the CreateEmployeeServlet class. This class is contained in the WS Case Study project and the com.wsbook.casestudy.servlet package. (Remember that you created this project, package, and servlet in the previous chapter.) Using the pop-up menu from the right mouse button, select the Export option, as shown in Figure 6.6.

2. When the dialog appears, select the Directory radio button and click the Next button. When the next dialog appears, type the export directory:

[ROOT_DIR]\WebSphere\AppServer\hosts\ default_host\TimeAppWebApp\servlets

as the export directory. Click the Finish button to start the export. (See Figure 6.7.) At this point, a dialog will appear informing you that this directory has not been created. Click OK to let WebSphere create the directory.

3. Ensure that the IBM WS Admin Server NT service is still running, and open the WebSphere administrator’s console.

4. Inside the administrator’s console, you will now use the Start Wizard pull-down menu to start a wizard that will help you create a new application server.

Select Create Application Server from the pull-down menu. The wizard that begins should resemble Figure 6.8.

5. The first panel that is displayed allows you to include either an EJB container or a Web container or both containers. Select both check boxes so that your new application server can service EJBs and Web applications. Click the Next button.

6. Next, you will specify the application server properties: the application server name, command line arguments, working directory, and standard output and standard error. Type EmployeeSys for the application server name. Change the name of the standard output to empsys_stdout.txt, and change the name of the standard error to empsys_stderr.txt. Click the Next button.

7. Specify that the server not be automatically started after creating it. Click Next.

8. Select your node from the list of nodes and click Next.

9. The next panel allows you to specify Enterprise Beans to be installed on this server. For now, do not make any changes to this panel. Click Next.

10. On the General tab, accept the EJB container name EmployeeSys.Container. Click Next.

11. On the Select Virtual Host page, select the default_host virtual host, and click Next. We will not be defining new virtual hosts for this node, so we will use the default host (which refers to the default host name defined for this node in TCP/IP).

12. On the General tab of the Servlet Engine Properties page, accept the servlet engine name EmployeeSysServletEngine. Click Next.

13. On the General tab of the Web Application Properties page, do not accept the default Web application name; instead, type the Web application name TimeAppWebApp. Select default_host as the virtual host. Type /TimeAppWebApp as the Web application Web path. This path will become the root URI for servlets in this Web application. Select the Advanced tab.

14. On this tab, you can change both the document root and the servlet class path. Accept the default document root [ROOT_DIR]\WebSphere\AppServer\hosts\default_host\TimeAppWebApp\web. Accept the servlet class path as [ROOT_DIR]\WebSphere\AppServer\hosts\default_host\TimeAppWebApp\servlets. Click Next.

15. This last page of the wizard allows you to specify system servlets that will be part of the Web application. Uncheck the Enable File Servlet check box. Check the Enable Serving Servlets By Classname check box.6 Select Enable JSP 1.0 so that the JSP 1.0 page compile servlet will be used by the Web application. Click the Finish button to create the application server.

16. When the process has completed, drill down to the “EmployeeSys” application server to show the configuration as in Figure 6.9.

17. Select the Web application TimeAppWebApp in the administrator’s console. Then, using the pop-up menu by clicking the right mouse button, select the Create-.Servlet option, as shown in Figure 6.10.

18. When the Create Servlet dialog appears, type the servlet name CreateEmployee. Type a Web application name of TimeAppWebApp and a description of Create an employee. Type the class name com.wsbook. casestudy.servlet.CreateEmployeeServlet, as shown in Figure 6.11.

19. Finally, add a servlet Web path. Click the Add button to display the Add Web Path to Servlet dialog. Type a path URI of /TimeAppWebApp/CreateEmployee, as shown in Figure 6.12. Click the OK button to close the dialog.

20. Click OK on the Create Servlet dialog to finish the addition of the servlet to the “TimeAppWebApp.”

21. Having configured all the items, start the application server by selecting the application server “EmployeeSys” and then click the Start button.

22. To test the deployed servlet, ensure that the Web server has been started, and then open a Web browser on http://localhost/TimeApp/ CreateEmployee, as shown in Figure 6.13.

Using XMLConfig
In addition to using the administration console to create and to configure application servers, WebSphere offers an XML configuration management tool called XMLConfig, which allows you to export a complete or a partial configuration from a node or to import configuration into a node. This tool can be used to create and to restore a configuration backup or to copy a configuration between WebSphere domains. If you have staged your servlets and EJBs on one node and now want to move them to another node, the XMLConfig tool is ideal for helping speed this process. You can use XMLConfig to export the entire configuration from a node to an XML file. Change directories to the [ROOT]\WebSphere\AppServer\bin directory and enter the following command to perform the export on the node named my_node.

xmlconfig -export myNodeConfig.xml -adminNodeName my_node

You must then edit the exported file to remove any items that you do not want on the new node and to change most of the tags with action5 "update" on them to action5 "create." In order to import an XML file containing a WAS configuration, type the following command:

xmlconfig -import myNodeConfig.xml -adminNodeName my_node

The XML schema that the XML configuration utility uses is quite simple. Its structure mirrors that of the topology view in the administration console. For instance, consider the following minimal XML configuration file template:

<node name="nodename" action={"create" | "locate" | "update}>
<application-server name = "name"
action = {"create"|"locate"|"update"}>
...insert the parts of the application server here...

If you wanted to update an application server with a new value—for instance, to change its trace-output file—you would simply insert the appropriate tags into the minimal file. To change the trace-output file, you would insert the tag <trace-output>(ROOT)\mytrace.trc</traceoutput> between the <application-server...> and the </application-server> tags. If you wanted to change the definition of a servlet, you would need to also include the tags defining the servlet engine and Web application, and so on.

The CD-ROM that accompanies this book contains a sample XML file (employee_sys.xml) that can be used to configure the “EmployeeSys” application server in the same way that we configured it using the administrator’s console. You would configure the new application server by changing the node name in the XML file to match your node name and then running the xmlconfig import as shown previously. You can learn more about how to use the XML configuration tool by reading the product documentation and by browsing through this example output file.

Configuration Issues
Earlier, we went through the steps of setting up an application server with an EJB container, a Web application, and a servlet. In this section, we will present some best practices for configuring your application servers and Web applications.

Application Server Versus Web Application
To understand the best practices for using application servers and Web applications, you need to consider a few more facts about Web applications. Each application server contains a single JVM, whereas a Web application is contained within an application server and shares the JVM with other Web applications. However, each Web application has its own class path and document root because a specialized class-loader class enforces isolation between the Web applications. As such, servlets within one Web application cannot directly invoke or directly utilize public static variables from a servlet within another Web application. In effect, having multiple Web applications divides up a JVM such that each Web application acts as if it has its own JVM. The only way servlets in different Web applications can communicate with one another is through the ServletContext object. You might recall that each Web application has its own ServletContext associated with it. The Servlet API allows a servlet to “look up” other servlet contexts,7 thus allowing communication with servlets in other Web applications.

Earlier, you learned that a Web application is a logical grouping of servlets that share a common root URI. Each Web application also defines a class path; what has not been discussed so far is the fact that each Web application within an application server can be independently “restarted,” or made to reload its servlets from the files on the class path. This can happen in two ways. First, a feature called autoreload can be set on each Web application. If autoreload is enabled, whenever a file changes on the class path for that Web application, the application server will dump all the current servlet instances and any other objects that were loaded with the servlets and reload the servlets from the new files on the class path. Second, an administrator can force a reload of a Web application by choosing the Restart Web App menu option from the menu in the topology tree.

This ability to force a reload of a particular Web application makes it possible to change the files related to a particular Web application while leaving running and unaffected all the servlets in the other Web applications within the application server. Thus, you can administer servlets and their associated classes, such as controllers and domain classes, on an individual Web application basis. The only limitation to this administration ability is that you cannot add or remove named servlets from the Web application unless you shut down the entire application server. These facts are key to making the decision between choosing to create a Web application or an application server.

For example, let’s say that we have two logically independent sets of servlets that run within the same intranet, although the same notion applies to different applications running within an Internet portal or application service provider (ASP). We will assume that one Web application contains our time card application—“TimeApp,” which was built for the human resources department of our fictional company. We can also assume that another set of servlets was developed for the sales department representing an application for setting and monitoring sales quotas: “QuotaApp.” Now let’s say that both applications have relatively low utilization rates—no more than five concurrent users at a time total—well within the processor utilization capabilities of a single-processor Windows NT or UNIX server.

If we create two application servers, one for each set of servlets, we will need to either deploy the two application servers on different nodes or equip our server with a substantial amount of RAM to run the two servers simultaneously. The reason is that each application server has a substantial memory overhead. An empty application server occupies between 30MB and 60MB of RAM—just the overhead to create the JVM and to load the base WebSphere classes. If you add more application classes, this figure will grow. However, adding a new Web application to an existing application server will not substantially increase its base memory size. So, to avoid the overhead of a new JVM, you should add a new Web application instead of creating a new application server. Your applications can still remain largely independent of one another through the Web application class path feature, but you will not have the unnecessary extra overhead.

Finally, you need to understand the autoreload feature. Autoreload is a computationally intensive process; WebSphere has a thread for each Web application that will “wake up” every few seconds—set in the reload interval—and scan the class path for changes. Although this is fine for servers with low utilization or that are in a test or quality assurance (QA) environment, it becomes an unacceptable amount of “wasted cycles” when in a higher transaction-volume environment. Therefore, we recommend that you turn off the autoreload feature for production WebSphere servers in all but the least-active server environments.

Some advantages of using a Web application are as follows.

  • KServlets within the same application server can use the RequestDispatcher object to forward (transfer control to) or to include the output of other servlets in the same application server.

  • A running Web application can be restarted apart from restarting the application server so as to pick up configuration changes.

  • Less system resources are needed, as only one JVM is needed for several Web applications.

    Some disadvantages of using Web applications are as follows.

  • In order to add servlets or to delete servlets from the Web application, the entire application server must be restarted.

  • Less isolation between “applications” exists.

    When should you use one rather than the other? The general rule of thumb is to use one application server per set of related applications and to apply Web applications as a way to segment the application into subapplications within a larger application. We would caution you to not group several unrelated projects with different delivery schedules into one application server, as you will inevitably force the other Web applications to have to restart when new servlets are added.

    “Invoker” Servlet
    As discussed earlier, the “Invoker” servlet can find other servlets by their Java class names and then load and/or invoke them on request. Generally, this servlet should be used only during testing and staging. Using “Invoker” can open up security holes. When “Invoker” is used, the HTML contains the class name of the servlet. As such, the user has more information than is necessary for calling a servlet. This small bit of information might lead an unscrupulous user to attempt to break into your system by using that information. Using “Invoker” can also decrease performance. In order for it to find a servlet by its class name, “Invoker” must use the Java Reflection API to find and to load the servlet. This API is generally slower than using a direct reference in Java. Finally, using “Invoker” limits how you can pass parameters to your servlet. You can only supply initialization parameters to a servlet that has been defined in the administrator’s console.

    Summary and Preview
    In this chapter, you have seen how the WASAE can be used to deploy both servlets and EJBs. You learned about how WASAE implements the containers in the J2EE architecture, how to verify a WASAE installation, how to configure an application server in WASAE by using the administrator’s console and the XMLConfig tool, and some best practices for configuration. In the next chapter, we look at WebSphere Studio and how it can be used to manage and deploy a Web application’s resources.

  • Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.