Redp 3601

ibm.
com/redbooks
Redpaper
IBM WebSphere V5.0 for
Linux, Implementation and
Deployment Guide
WebSphere Handbook Series
Mark Endrei
Patrick Michel
Michael Myrtek
Implement your WebSphere 5 for Linux
runtime environment
Explore both single-tier and
multi-tier configurations
Deploy applications to
WebSphere 5 for Linux
Front cover
IBM WebSphere V5.0 for Linux, Implementation and
Deployment Guide WebSphere Handbook Series
February 2003
International Technical Support Organization
Copyright International Business Machines Corporation 2003. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
First Edition (February 2003)
This edition applies to Version 5.0 of IBM WebSphere Application Server.
Note: Before using this information and the product it supports, read the information in
Notices on page vii.
Copyright IBM Corp. 2003. All rights reserved. iii
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. WebSphere architecture overview . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 WebSphere Application Server architecture . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 HTTP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Administration service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 WebSphere editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 What is J2EE?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 J2EE benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 J2EE application model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 J2EE application components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.5 J2EE components, containers and services . . . . . . . . . . . . . . . . . . . . 8
1.3.6 More information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapter 2. Implementing a single-tier runtime environment. . . . . . . . . . . . 9
2.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Hardware and software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Hardware used in our test environment . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Software used in our test environment . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 Runtime environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Linux installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Linux kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 File systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Linux software package requirements . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 WebSphere Application Server installation . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Installing WebSphere Application Server V5.0 . . . . . . . . . . . . . . . . . 20
2.3.3 Verify WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4 WebSphere Application Server configuration . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 3. Implementing a multi-tier runtime environment. . . . . . . . . . . . 37
iv IBM WebSphere V5.0 for Linux
3.1 Planning for a multi-tier runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.2 Hardware and software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.3 Hardware used within our test environment . . . . . . . . . . . . . . . . . . . 42
3.1.4 Software used within our test environment . . . . . . . . . . . . . . . . . . . . 42
3.1.5 Linux installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Implementing a two-tier remote Web server runtime . . . . . . . . . . . . . . . . 43
3.2.1 Install the DB2 Server on machine B . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2 Install WebSphere Application Server on machine B . . . . . . . . . . . . 44
3.2.3 Install IBM HTTP Server on machine A . . . . . . . . . . . . . . . . . . . . . . 44
3.2.4 Update the WebSphere plug-in file on machine A . . . . . . . . . . . . . . 44
3.2.5 Verify WebSphere Application Server from machine A. . . . . . . . . . . 45
3.3 Implementing a two-tier remote database server runtime . . . . . . . . . . . . . 45
3.3.1 Install the DB2 server on machine B. . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Install the DB2 client on machine A . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.3 Install WebSphere Application Server on machine A . . . . . . . . . . . . 46
3.4 Implementing a three-tier runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.1 Install the DB2 server on machine C. . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.2 Install the DB2 client on machine B . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.3 Install WebSphere Application Server on machine B . . . . . . . . . . . . 48
3.4.4 Install the IBM HTTP Server on machine A . . . . . . . . . . . . . . . . . . . 48
3.4.5 Update the WebSphere plug-in file on machine A . . . . . . . . . . . . . . 48
3.5 Implementing a Network Deployment cluster . . . . . . . . . . . . . . . . . . . . . . 48
3.5.1 Network Deployment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.2 Network Deployment installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.3 Cluster configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.4 Deploying a sample clustered application. . . . . . . . . . . . . . . . . . . . . 57
Chapter 4. Application deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1 J2EE application packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.1 Assembling and deploying applications . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Deployment considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1 Deployment assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2 General deployment considerations . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.3 Deployment stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.4 Deployment nodes and tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.5 Clustered environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.6 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.7 File transfer methods for deployment . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.8 File system considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Deploying a J2EE application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Contents v
4.3.1 Configuring WebSphere for hosting the application . . . . . . . . . . . . . 72
4.3.2 Deploying the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.3 Testing the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3.4 Separating static and dynamic Web content . . . . . . . . . . . . . . . . . . . 97
Appendix A. Installing IBM HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . 103
Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Install IBM HTTP Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Configure IBM HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Configuring the ServerName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Configuring the HTTP server for SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Creating an HTTP server runtime user account . . . . . . . . . . . . . . . . . . . . 110
Configuring the HTTP administration server . . . . . . . . . . . . . . . . . . . . . . . 111
Verify IBM HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Appendix B. Installing IBM DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Installing IBM DB2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Install the DB2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Verify DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Configure the DB2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Installing IBM DB2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Install the DB2 Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Verify DB2 Client installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Configure the DB2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Appendix C. Service scripts and runlevel configuration. . . . . . . . . . . . . 135
Setting up the WebSphere Application Server as service . . . . . . . . . . . . . . . 136
Creating the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuring the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Maintaining the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Setting up the IBM HTTP Server as service. . . . . . . . . . . . . . . . . . . . . . . . . . 138
Creating the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Configuring the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Maintaining the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
System requirements for downloading the Web material . . . . . . . . . . . . . 142
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
vi IBM WebSphere V5.0 for Linux
Copyright IBM Corp. 2003. All rights reserved. vii
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
viii IBM WebSphere V5.0 for Linux
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
Affinity
CICS
DB2
DB2 Connect
developerWorks
e(logo)server
IBM
Redbooks
Tivoli
WebSphere
The following terms are trademarks of other companies:
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United
States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure
Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
Copyright IBM Corp. 2003. All rights reserved. ix
Preface
This Redpaper provides system administrators, developers, and architects with
the knowledge needed to implement the IBM WebSphere Application Server
V5.0 for Linux runtime environment and to deploy Web applications to that
environment.
Chapter 1 of the Redpaper introduces IBM WebSphere Application Server V5.0
for Linux architecture and editions. It also provides an overview of the J2EE
programming model.
Chapter 2 steps you through the WebSphere Application Server V5.0 for Linux
installation process in a single-tier runtime environment.
Chapter 3 provides instructions for implementing WebSphere Application Server
in a multi-tier runtime environment. It also explains how to implement a cluster
using WebSphere Network Deployment edition.
Chapter 4 introduces J2EE application packaging and guides you through
deployment of a sample J2EE application. It also discusses a range of
deployment considerations.
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Raleigh Center.
x IBM WebSphere V5.0 for Linux
Figure 0-1 The IBM Redpaper team (Left to right: Michael Myrtek, Patrick Michel, Mark
Endrei)
Mark Endrei is an IT Architect at the International Technical Support
Organization, Raleigh Center. He writes about all areas of WebSphere. Before
joining the ITSO early in 2001, Mark worked in IBM Global Services Australia as
an IT Architect. He holds a bachelor's degree in Computer Systems Engineering
from the Royal Melbourne Institute of Technology, and an MBA in Technology
Management from Deakin University/APESMA.
Patrick Michel is an IT System Architect at WestLB Systems in Duesseldorf,
Germany. He has 16 years of experience in IT computing fields including
application design, development, consulting and managing production systems.
He holds certifications from Red Hat as RHCE, Linux Professional Institute, and
IBM as Systems Expert in WebSphere Administration. His areas of expertise
include UNIX, production systems, and application integration. In the past three
years, he has worked extensively on migration and integration of Java-based
e-business applications on WebSphere production platforms.
Michael Myrtek is an IT Architect with IBM in Sydney, Australia working in
Advanced Technical Support. He has 13 years of experience in the IT industry
and has worked for IBM for the last six years in the Hursley Development
Laboratory, UK and in Sydney, Australia. His areas of expertise include
WebSphere Application Server, Linux, and Call Centre applications.
Thanks to the following people for their contributions to this project:
Jakob Carstensen, IBM Baltimore
Preface xi
Dharmesh Bhakta, IBM Austin
Gail Christensen, IBM ITSO Raleigh
Peter Kovari, IBM ITSO Raleigh
Ivan Perez, IBM Chile
Eric Rybczynski, IBM Austin
Margaret Ticknor, IBM ITSO Raleigh
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about
this Redpaper or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HZ8 Building 662
xii IBM WebSphere V5.0 for Linux
P.O. Box 12195
Research Triangle Park, NC 27709-2195
Copyright IBM Corp. 2003. All rights reserved. 1
Chapter 1. WebSphere architecture
overview
This chapter provides a brief introduction to IBM WebSphere Application Server
V5.0 architecture and to the Java 2 Platform, Enterprise Edition programming
model supported by WebSphere Application Server.
1
2 IBM WebSphere V5.0 for Linux
1.1 WebSphere Application Server architecture
This section looks at the major components within IBM WebSphere Application
Server V5.0, including the application server and its containers, the HTTP server
plug-in and embedded HTTP handling, and the virtual host configuration.
Figure 1-1 Major components in WebSphere V5.0 base edition
1.1.1 HTTP server
WebSphere Application Server works with an HTTP server to handle requests for
servlets and other dynamic content from Web applications. (The terms HTTP
server and Web server are used interchangeably throughout the documentation.)
The HTTP server and application server communicate using the WebSphere
HTTP plug-in for the HTTP server. The HTTP plug-in uses an easy-to-read XML
configuration file to determine whether a request should be handled by the Web
server or the application server. It uses the standard HTTP protocol to
communicate with the application server. It can also be configured to use secure
HTTPS, if required. The HTTP plug-in is available for popular Web servers.
1.1.2 Application server
The application server collaborates with the Web server to return customized
responses to client requests. Application code including servlets, JavaServer
Pages (JSP) files, Enterprise JavaBeans (EJB) components, and their
EJB container
Application Server
Embedded JMS Server
Node
Java
client
Client container
Application
Database
A
d
m
i
n

s
e
r
v
i
c
e
Config
repository
(file)
Admin
application
Scripting
client
application
(EAR)
Web container
HTTP server
Admin
console
WebSphere
plug-in
Web
browser
client
Embedded
HTTP server
Servlets,JSPs
EJBs
Chapter 1. WebSphere architecture overview 3
supporting classes run in an application server. In keeping with the J2EE
component architecture, servlets and JSP files run in a Web container, and
enterprise beans run in an EJB container. You can define multiple application
servers, each running in its own Java Virtual Machine (JVM).
Web container
Servlets and JavaServer Pages (JSP) files are server-side components used to
process requests from HTTP clients, such as Web browsers. They handle
presentation and control of the user interaction with the underlying application
data and business logic. They can also generate formatted data, such as XML,
for use by other application components.
The Web container processes servlets, JSP files, and other types of server-side
includes. When handling servlets, the Web container creates a request object
and a response object, then invokes the servlet service method. The Web
container invokes the servlet destroy() method when appropriate and unloads
the servlet, after which the JVM performs garbage collection.
EJB container
The EJB container provides the runtime services needed to deploy and manage
EJB components, known as enterprise beans. It is a server process that handles
requests for session, entity, and message-driven beans.
The enterprise beans (inside EJB modules) installed in an application server do
not communicate directly with the server; instead, an EJB container provides an
interface between the enterprise beans and the server. Together, the container
and the server provide the bean runtime environment.
The container provides many low-level services, including threading and
transaction support. From an administrative viewpoint, the container manages
data storage and retrieval for the contained beans. A single container can hold
more than one EJB JAR file.
Application client container
Application clients are Java programs that typically run on a desktop computer
with a graphical user interface (GUI). They have access to the full range of J2EE
server-side components and services.
The application client container handles Java application programs that access
enterprise beans, Java Database Connectivity (JDBC), and Java Message
Service message queues. The J2EE application client program runs on client
machines. This program follows the same Java programming model as other
Java programs; however, the J2EE application client depends on the application
client run time to configure its execution environment, and uses the Java Naming
and Directory Interface (JNDI) namespace to access resources.
Embedded JMS server
The embedded JMS server provides built-in support for Java Message Service
(JMS) messaging between WebSphere applications, including message-driven
beans.
Embedded HTTP server
The embedded HTTP server enables HTTP clients to connect directly to the
application server. Or, as described earlier, an HTTP client can connect to a Web
server and the HTTP plug-in can forward the request to the application server.
1.1.3 Administration service
The administration service runs in each server process providing the functions
needed to manage the server. The administration application (adminconsole.ear)
is a J2EE application providing Administrative Console access to the
administration service from a Web browser. The administration scripting client
(wsadmin) provides interactive command-line or Jacl script access to the
administration service.
With WebSphere V5.0, a database is not used for storing WebSphere
configuration information. The administration service stores this information in a
set of XML files called the configuration repository.
1.2 WebSphere editions
Three of the packaging options available to WebSphere V5.0 customers are
shown in Figure 1-2 on page 5:
IBM WebSphere Application Server base V5.0 provides the code and license
for single-node application servers. It is similar to Single Server Edition in
WebSphere V4.0.
IBM WebSphere Application Server Network Deployment V5.0 adds
advanced clustering and Web services capabilities. It also provides edge of
network components bundled in a separate CD called the DMZ CD.
IBM WebSphere Application Server Enterprise V5.0 provides high-end
application functions and integration capabilities with extensions beyond the
J2EE standards. Features include workflow, extended transactions, business
rules beans, and so on.
With WebSphere V5.0, migration between editions is made easier because the
new components are installed on top of the base edition.
Figure 1-2 WebSphere V5.0 editions
Not shown in Figure 1-2 is IBM WebSphere Application Server Express V5.0. It is
a lightweight edition of the application server providing a more affordable
platform for those who do not need the extra features that IBM WebSphere
Application Server base V5.0 provides.
1.3 Programming model
IBM WebSphere Application Server V5.0 provides a runtime environment for
applications developed using the J2EE programming model. The J2EE platform
is the standard for developing, deploying, and running enterprise applications.
WebSphere V5.0 has completed the full J2EE certification test suite. It supports
all of the J2EE 1.3 APIs, and exceeds many with its extensions.
1.3.1 What is J2EE?
J2EE stands for Java 2 Platform, Enterprise Edition. It defines a standard that
applies to all aspects of designing, developing, and deploying multi-tier,
server-based applications.
The standard architecture defined by J2EE is composed of the following
elements:
Standard application model for developing multi-tier applications.
I BM WebSphere
Applicat ion Server
Applicati on Server, IBM
HTTP Server
Applicati on Cl ient
Applicati on Server Toolkit
Dat aDirect Technologies
JDBC Dri ver s f or
WebSpher e Applicati on
Server
IBM WebSphere
Appl ication Server
Network Deployment
Application Server, IBM
HTTP Ser ver
Depl oyment Manager
Edge Components
Application Client
Application Server Tool kit
DataDir ect Technologies
JDBC Drivers for
WebSphere Appl ication
Server
DB2 Universal Dat abase
Enterprise Ser ver Editi on
IBM Dir ector y
I BM WebSphere
Applicati on Server
Ent erprise
Applicati on Server, IBM
HTTP Server
Deployment Manager
Edge Components
Enter pri se Ext ensions
Applicati on Cl ient
Applicati on Server Toolkit
Dat aDirect Technologies
JDBC Dri ver s f or
WebSpher e Applicati on
Server
DB2 Universal Database
Enter pri se Server Edit ion
I BM Directory
WebSpher e MQ
Standard platform for hosting applications.
Compatibility test suite for verifying that J2EE platform products comply with
the J2EE platform standard.
Reference implementation providing an operational definition of the J2EE
platform.
The J2EE platform specification describes the runtime environment for a J2EE
application. This environment includes application components, containers, and
connectors. The elements of this environment communicate with a set of
standard services that are also specified.
1.3.2 J2EE benefits
The J2EE standard empowers customers. Customers can compare J2EE
offerings from vendors and know that they are comparing apples with apples.
Comprehensive, independent compatibility test suites ensure vendor compliance
with J2EE standards.
Some benefits of deploying to a J2EE-compliant architecture are:
A simplified architecture based on standard components, services and clients
that takes advantage of the write-once, run-anywhere Java technology.
Services providing integration with existing systems, including Java Database
Connectivity (JDBC), Java Message Service (JMS), Java Interface Definition
Language (Java IDL), JavaMail, and Java Transaction API (JTA and JTS) for
reliable business transactions.
Scalability to meet demand, for example by distributing containers across
multiple system and using database connection pooling.
A better choice of application development tools, and components from
vendors providing off-the-shelf solutions.
A flexible security model that provides single sign-on support, integration with
legacy security schemes, and a unified approach to securing application
components.
The J2EE specifications are the result of an industry-wide effort that has
involved, and still involves, a large number of contributors. IBM alone has
contributed to defining more than 80 percent of the J2EE APIs.
1.3.3 J2EE application model
As shown in Figure 1-3, the J2EE application model is based on:
Components are the key functional elements that are custom-developed for
applications. Components are implemented by application developers.
Containers provide services for components and connectors, such as
connection pooling, transaction management, state management, naming,
security, and so on. Containers are implemented by application server
vendors, such as IBM with WebSphere Application Server.
Connectors plug into the J2EE platform to provide access enterprise
systems and databases. Connectors are implemented by EIS and database
vendors, such as IBM with CICS or DB2.
Figure 1-3 J2EE application model
1.3.4 J2EE application components
There are four types of custom-developed J2EE application components:
Servlets and JavaServer Pages are server-side components used to
respond to requests from HTTP clients. They provide presentation and
control client interaction with applications.
Enterprise JavaBeans are server-side components that use services such
as life-cycle management, transactions, security, database connectivity, and
more. They provide application business logic and data access.
Application clients are Java programs that typically run on a desktop PC.
They have full access to server-side components and services.
Applets are Java classes that typically run in a browser. They are often used
to enhance the user experience.
You can also access J2EE applications using custom-developed, stand-alone
J2SE application clients that use the established client interfaces.
Connectors
Components
Containers
1.3.5 J2EE components, containers and services
Figure 1-4 shows how J2EE components, containers and services are related:
Enterprise JavaBeans reside in the EJB container
Servlets and JavaServer Pages files reside in the Web container
Application clients reside in the application client container
Applets reside in the applet container
Figure 1-4 J2EE components, containers and services
The custom-developed application components, such as EJBs and servlets, are
deployed in containers. Containers provide services for the components,
including access to external systems using connectors.
1.3.6 More information
For more information, see the Sun Java 2 Platform, Enterprise Edition Web site
at:
http://java.sun.com/j2ee
Database
Applet
J2SE
Applet
Container
Application
Client
Container
Application
Client
J2SE
J
M
S
J
A
A
S
J
A
X
P
J
D
B
C
J
N
D
I
R
M
I
-
I
I
O
P
JSP servlet
J
M
S
J
A
A
S
J
T
A
J
A
X
P
J
D
B
C
C
o
n
n
e
c
t
o
r
s
Java
Mail
JAF
J2SE
Web
Container
J
N
D
I
R
M
I
-
I
I
O
P
EJB
EJB
Container
J2SE
J
M
S
J
A
A
S
J
T
A
J
A
X
P
J
D
B
C
C
o
n
n
e
c
t
o
r
s
Java
Mail
JAF
J
N
D
I
R
M
I
-
I
I
O
P
Chapter 2. Implementing a single-tier
runtime environment
This chapter provides procedures for installing, configuring, and verifying
WebSphere Application Server V5.0, base edition for Linux in a single-tier
runtime environment. Chapter 3, Implementing a multi-tier runtime environment
on page 37 covers two-tier and three-tier runtime environments, but rely heavily
on the component installation details provided in this chapter.
In the single-tier environment, we will install all of the WebSphere components
on the same server, as seen in Figure 2-1 on page 10. This scenario is normally
not used for a production server; however, it can be useful for development,
testing, or proof-of-concept work.
2
Figure 2-1 Single-tier runtime environment
The chapter is organized into the following sections:
Planning
Linux installation
WebSphere Application Server installation
WebSphere Application Server configuration
2.1 Planning
This section defines the hardware and software used within the WebSphere
Application Server V5.0, base edition for Linux runtime environment single-tier
scenario.
This section includes the following topics:
Hardware and software prerequisites
Hardware used in our test environment
Software used in our test environment
Runtime environment
2.1.1 Hardware and software prerequisites
The WebSphere Application Server V5.0, base edition for Linux has the following
hardware and software requirements.
WAS V5.0
DB2 V8.0
Server
RedHat Linux V7.3
IBM HTTP
Server
V1.3.24
80/443
Client
F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
Plugin
80/443
Internet
Chapter 2. Implementing a single-tier runtime environment 11
Hardware
Hardware requirements for IBM WebSphere Application Server base V5.0 for
Linux on Intel include:
Intel x86 processor at 500 MHz or faster
Minimum 300 MB free disk space for installation (includes SDK)
Minimum 256 MB of memory; 512 MB recommended
CD-ROM drive
For further details on requirements, see the following documentation:
WebSphere Application Server
http://www.ibm.com/software/webservers/appserv/
IBM DB2 UDB Enterprise Server Edition
http://www.ibm.com/software/data/db2/udb/
Software
Software requirements for IBM WebSphere Application Server base V5.0
include:
Supported Linux for Intel operating systems
Red Hat Linux Advanced Server for Intel V2.1 (2.4 Kernel)
SuSE Linux for Intel V7.3 (2.4 Kernel)
SuSE SLES for Intel V7 (2.4 Kernel)
Supported Web servers
Apache HTTP Server V1.3.26
IBM HTTP Server V1.3.26
IBM HTTP Server V2.0
Supported databases (optional)
IBM DB2 Connect V7.2 FP7, or 8.1
IBM DB2 Enterprise-Extended Edition V7.2 FP7
IBM DB2 Enterprise Edition V7.2 FP7
IBM DB2 Enterprise Server Edition V8.1
IBM DB2 Workgroup Edition V7.2 FP7
IBM DB2 Workgroup Server Edition V8.1
Oracle 8i Enterprise Release 3 (8.1.7)
Oracle 9i Enterprise Release 2 (9.2)
Note: Please refer to the product documentation for a complete list of
supported software.
2.1.2 Hardware used in our test environment
We used the following system within our single-tier environment:
IBM PC300PL
P-III 667 MHz CPU
512 MB RAM
20 GB hard disk
Ethernet Pro 100 Network Adapter
S3 Savage 4 Video Adapter
2.1.3 Software used in our test environment
We used the following software in our test environment:
Red Hat Linux Advanced Server V2.1
IBM WebSphere Application Server base V5.0
IBM DB2 UDB Enterprise Server Edition V8.1 for Linux
IBM HTTP Server V1.3.26 for Linux
Product installation directories
Table 2-1 lists variable names, default installation directories, and components.
We will reference these variables throughout this document.
Table 2-1 Product installation directories
2.1.4 Runtime environment
We used the following information to build our single-tier environment.
Network settings
The network configuration for our setup was as follows:
Hostname: appsrv1l.itso.ibm.com
IP address: 9.24.105.134
Subnet Mask: 255.255.255.0
Note: Other Web server and database software may be used, as specified in
the product documentation.
Variable Default directory Component
<WAS_HOME> /opt/WebSphere/AppServer WebSphere
<DB2_HOME> /opt/IBM/db2 DB2 Server
<IHS_HOME> /opt/IBMHTTPServer IBM HTTP Server
Default Route: 9.24.105.1
DNS Server: 9.24.104.108
File system layout
The values in Table 2-2 were used during the installation in our test environment.
Linuxs ext2 file systems do not lend themselves well to change. So if you expect
to need more room in a given file system in the future, you should plan for it up
front. Generally, the file systems you need to watch for are ones that will contain
dynamic data such as log files.
Table 2-2 Test environment file system layout
You can use the values provided in Table 2-3 for a quick start installation where
separate file systems are not needed.
Table 2-3 Quick start file system layout
See Table 2-4 for the explanations of the notes from Table 2-2 and Table 2-3.
Table 2-4 File system layout notes
Name Partition type FS type Mount point Size (MB)
hda1
1a
Primary Linux ext3 / 400
hda2
2
Primary swap swap 32 - 2048
hda3
3
Primary Linux ext3 /usr 3300
hda5
5
Logical Linux ext3 /home 1000
hda6
6
Logical Linux ext3 /opt 2000
hda7
7
Logical Linux ext3 /tmp 400
hda8
8
Logical Linux est3 /var 1500
Name Partition type FS type Mount point Size (MB)
hda1
1b
Primary Linux ext3 / 5000
hda2
2
Primary swap swap 32 - 2048
Note Explanation
1a The / partition is flagged as the bootable partition.
1b As in 1a, but this partition is used for the entire Linux distribution, including
user and application storage.
2 The minimum size of your swap partition should be equal to twice your
computer's RAM, or 32 MB, whichever amount is larger, but no more than
2048 MB (or 2 GB).
Users and groups
In our setup we added the users and groups listed in Table 2-5 on page 15 during
the process of installing the software components.
3 The size of 3300 MB ensures that the entire Red Hat distribution can be
installed.
5 This size depends on the amount of storage needed per user and the number
of users, such as 50 MB per user.
6 This size of 1000 MB allows for installation of the Web server, application
server, and database server.
7 We use a separate partition for /tmp to restrict the amount of disk space that
can be used for temporary files.
8 This file system is used for storage of managed content such as Web server
document roots.
Notes:
The current Linux ext2 file system does not provide the capability to alter
the file system size once created; however, there are third-party tools such
as PowerQuest Partition Magic that can be used.
Newer versions of boot managers (such as LILO or GRUB) can address
cylinders beyond the 1024 border. A separate partition for the /boot
directory is no longer needed.
Note Explanation
Table 2-5 Users and groups
2.2 Linux installation
There are many sources of information on how to install Linux. This section
outlines the steps taken to build our single-tier environment. We performed a
server installation and changed the disk layout as described in File system
layout on page 13. For more detailed instructions on possible installation
planning, please refer to these other sources:
IBM ITSO Redbooks site:
http://www.redbooks.ibm.com/
User Groups Home Shell
root
1
root, mqm, mqbrkrs /root /bin/bash
admin
2
admin /home/admin /bin/bash
db2fenc1
3
db2fadm1 /home/db2fenc1 /bin/bash
db2inst1
3
db2iadm1 /home/db2inst1 /bin/bash
dasusr1
3
dasadm1 /home/dasusr1 /bin/bash
mqm
4
mqm /home/mqm /bin/bash
www
5
www /home/www /bin/bash
webas
6
users /home/webas /bin/bash
Notes:
1. The user you use to run WebSphere Application Server must be a member of the
mqm and mqbrkrs groups to use the WebSphere messaging server.
2. By default, Red Hat Linux will refuse telnet logons by the root user, so you need a
user other than root to log in with. The good news is that you can create this user
during the installation of Red Hat.
3. The db2fenc1, db2inst1, and dasusr1 users are created as part of the DB2
installation. If you should choose to install with one of the other supported
databases, you will need to follow its guidelines for database user accounts.
4. The mqm user and mqm and mqbrkrs groups are required for the WebSphere
Application Server messaging server.
5. The www user and group are optionally used to run the Web server processes.
6. The webas user is required for database access by the ITSOBank sample
application.
Tip: Search on Linux.
Red Hat Corporation:
http://www.redhat.com/
Red Hat Linux Advanced Server V2.1 documentation:
http://www.redhat.com/support/docs/
The Official Red Hat Linux x86 Installation Guide, found at:
http://www.redhat.com/support/manuals/
2.2.1 Linux kernel
The IBM WebSphere Application Server base V5.0 requires Red Hat Linux
Advanced Server V2.1, with kernel Version 2.4.
2.2.2 File systems
During the interactive phase of the Red Hat Linux Advanced Server V2.1
operating system installation, you will need to customize the file systems and
allocate the necessary space for the software components installed. See
Table 2-2 on page 13 for the actual file system sizes used during our installation.
Table 2-6 provides guidelines for the space required by each component. The
values in this table were taken from our installed system after the installation
using the file system layout in Table 2-2 on page 13, and using the df and du -ks
commands on each file system/product directory.
Table 2-6 Component disk space minimum requirements
Component Directories Disk
space
required
(MB)
1
Destination
File system
Total
disk
required
(MB)
1
Red Hat Linux
(user-executables,
kernel, dev-nodes,
configuraton-files,
kernel-modules,
system-binaries, etc.)
/bin
/boot
/dev
/etc
/lib
/sbin
7
10
1
12
72
14
/ 120
Red Hat Linux
(software packages,
X-Windows, etc.)
/usr 3300 /usr 3300
2.2.3 Linux software package requirements
If you should decide to use the Apache HTTP Server, instead of the IBM HTTP
Server (Apache + some IBM modules), do the following during the WebSphere
Application Server installation:
Deselect IBM HTTP Server.
Select the Apache module plug-in instead of the IBM HTTP Server plug-in.
IBM HTTP Server /opt/IBMHttpServer 50 /opt 1100
IBM WebSphere
Application Server
/opt/WebSphere
/opt/mqm
/opt/wemps
600
IBM DB2 UDB
Enterprise Server
Edition
/opt/IBM/db2 350
IBM DB2 UDB
Enterprise Server
Edition (user profiles)
/home 50 /home 50
1. These values are the minimum required to install the packages we chose to install.
Your values may vary depending on selected packages and expected growth rate.
If you have the disk space, you should consider being generous with your
allocations.
Note: There are many configuration scenarios to consider if you plan on using
your system for Linux and Windows operating systems. If you plan to boot
multiple operating systems, we recommend that you search for the latest
information available on the Web, such as:
http://www.redhat.com/
Component Directories Disk
space
required
(MB)
1
Destination
File system
Total
disk
required
(MB)
1
Note: We used the standard Linux server installation that includes the Apache
HTTP Server. We also installed the IBM HTTP Server during the WebSphere
Application Server installation.
2.3 WebSphere Application Server installation
We started the WebSphere Application Server V5.0 installation after successfully
installing Red Hat Linux Advanced Server V2.1.
2.3.1 Pre-installation tasks
Prior to installing the IBM WebSphere Application Server V5.0, base edition for
Linux, just a few pre-installation checks and tasks need to be completed:
Create embedded JMS server user and groups.
Check IP ports are unused.
Stop Web server processes.
Create embedded JMS server user and groups
The installation program does not automatically create the embedded JMS
server user and groups. The installation program checks if the prerequisite user
and groups for the embedded messaging are configured. If they have not been
created, the installation of WebSphere Application Server will stop and show an
error message indicating how to rectify the situation.
You need to create the mqm user and two groups, mqm and mqbrkrs. The user
you run WebSphere as (root in our case) and the mqm user must be members of
both groups.
To create the embedded JMS server user and groups:
1. Log in as root and start a terminal session.
2. Create two new groups:
groupadd mqm
Note: WebSphere Application Server V5.0 no longer requires a database to
store its configuration data, because configuration details for the application
server are now stored in XML files. You can install WebSphere Application
Server V5.0 immediately after a successful installation of Red Hat Linux
Advanced Server V2.1. However, most Web applications require a database
to store and retrieve application information. The installation of IBM DB2 UDB
Enterprise Server Edition is covered in Appendix B, Installing IBM DB2 on
page 117.
Important: WebSphere will not install if the required user and groups for the
embedded messaging are not configured, and you choose the embedded
JMS installation option.
groupadd mqbrkrs
3. Create a user mqm and add it to the mqm and mqbrkrs groups.
useradd -g mqm -G mqbrkrs -m mqm
4. Add the root user to the mqm and mqbrkrs groups. You can use the
redhat-config-users command to start the Red Hat User Manager GUI tool,
or edit the /etc/group file directly if you prefer.
5. Log off and then on again to get the new permissions.
Check IP ports are unused
Check that there are no existing active services that use the following IP ports on
the server:
80 (HTTP)
443 (HTTPS - optional)
2809 (Bootstrap port)
9080 (HTTP transport)
9443 (HTTPS transport - optional)
9090 (HTTP administrative console port)
5557 (Internal JMS server)
7873 (Data replication service port)
8880 (SOAP connector port)
We suggest using the following command for this task:
netstat -l
Stop Web server processes
If during the Red Hat Linux Advanced Server V2.1 installation you chose to
install the Apache HTTP Server instead of the IBM HTTP Server, you will need to
stop the Apache HTTP Server before proceeding. This is because the
WebSphere Application Server installation updates the httpd.conf configuration
file as part of the Web server plug-in component installation.
2. Stop the Web server, for example:
cd /usr/sbin
./apachectl stop
2.3.2 Installing WebSphere Application Server V5.0
This section covers the single-tier installation of WebSphere Application Server.
It has step-by-step instructions on how to install WebSphere Application Server
with the least amount of configuration. This single-tier environment is usually not
used in a production setting. For detailed instructions on how to set up a
production environment, please consult Chapter 3, Implementing a multi-tier
runtime environment on page 37.
To install WebSphere Application Server, follow the steps outlined below:
2. Insert and mount the WebSphere Application Server V5.0 CD-ROM:
mount /mnt/cdrom
3. Start the WebSphere Application Server LaunchPad. For example:
cd /mnt/cdrom
./LaunchPad.sh
4. In the language selection window, select English and click OK.
5. In the WebSphere Application Server LaunchPad window, click Install the
product, as shown in Figure 2-2 on page 21.
Note: As well as the interactive installation procedure described here, you can
optionally install WebSphere using the automated or silent installation
procedure. See the WebSphere InfoCenter article Installing silently for
details.
Note: If you are running X-windows with either the Gnome or KDE window
managers, the CD-ROM may automatically be mounted for you. To verify
this, simply run mount | grep /mnt/cdrom. If you get any output, then the
CD-ROM has already been mounted.
Tip: On slower machines, it might take a few seconds for the application to
respond when you click Install the product. Please be patient, because
multiple clicks will also launch multiple installation programs.
Figure 2-2 WebSphere Application Server LaunchPad
6. In the wizard language selection window, select English and click OK.
7. In the Welcome to WebSphere Application Server window, click Next to
continue, as shown in Figure 2-3 on page 22.
Figure 2-3 Installation Wizard Welcome window
8. In the software license agreement window, select I accept the terms in the
license agreement and click Next to agree to the terms of the agreement, as
shown in Figure 2-4 on page 23.
Figure 2-4 Accepting the software license agreement
The installation wizard will check the system prerequisites, then display the
setup type window.
9. In the setup type window, select the Full setup type option and click Next, as
shown in Figure 2-5 on page 24.
Figure 2-5 Selecting the setup type
10.In the setting the installation directories window, you can change the
installation path for the WebSphere Application Server and IBM HTTP Server.
We recommend that the default directories be used, as shown in Figure 2-6
on page 25. Click Next.
Figure 2-6 Setting the installation directories
11.In the node name and host name window, enter the node name and host
name for your installation. In our case we set the node name and host name
to appsrv1l, as shown in Figure 2-7 on page 26. Click Next.
Note: The node name will appear in the Administrative Console.
Figure 2-7 Setting the node name and host name
12.In the next window, verify your installation settings, and click Next to start the
installation, as shown in Figure 2-8 on page 27.
Figure 2-8 Verifying the features selected
The installation of IBM WebSphere Application Server V5.0 will commence.
Depending on the speed of your machine, the installation will finish in a few
minutes.
13.Once the installation is complete, click Finish in the installation wizard
finished window, as shown in Figure 2-9 on page 28.
Figure 2-9 Installation wizard finished
After a successful installation of IBM WebSphere Application Server V5.0, the
First Steps window, as shown in Figure 2-10 on page 29, will automatically start.
If for some reason the First Steps window does not appear, it can be started from
the command line by running /opt/WebSphere/AppServer/bin/firststeps.sh.
Figure 2-10 WebSphere Application Server - First Steps
2.3.3 Verify WebSphere Application Server
To confirm that WebSphere Application Server V5.0 was installed correctly, click
Verify Installation in the First Steps window, as shown in Figure 2-10. This
command will attempt to start the WebSphere Application Server. During the
startup process, additional information will be displayed in the log pane at the
bottom of the First Steps window.
Alternatively, the Verify Installation utility can also be started from the command
line as follows:
cd /opt/WebSphere/AppServer/bin
./ivt.sh
The output should look similar to Example 2-1.
Example 2-1 output from ivt script
IVTL0095I: defaulting to host appsrv1l and port 9080
IVTL0010I: Connecting to the WebSphere Application Server appsrv1l on port:
9080
IVTL0020I: Could not connect to Application Server, waiting for server to start
IVTL0025I: Attempting to start the Application Server
osName = Linux
IVTL0030I: Running /opt/WebSphere/AppServer/bin/startServer.sh server1
>ADMU0116I: Tool information is being logged in file
> /opt/WebSphere/AppServer/logs/server1/startServer.log
>ADMU3100I: Reading configuration for server: server1
>ADMU3200I: Server launched. Waiting for initialization status.
>ADMU3000I: Server server1 open for e-business; process id is 1400
IVTL0050I: Servlet Engine Verification Status - Passed
IVTL0055I: JSP Verification Status - Passed
IVTL0060I: EJB Verification Status - Passed
IVTL0070I: IVT Verification Succeeded
IVTL0080I: Installation Verification is complete
Once the WebSphere Application Server is up and running, you can launch the
Administrative Console. You have the choice to launch the Administrative
Console from the First Steps window, shown in Figure 2-10 on page 29, or by
entering the URL in your browser.
Tip: To start and stop the server, two shell scripts are available in the
<WAS_HOME>/bin directory.
startServer.sh
The command to start server1 is:
<WAS_HOME>/bin/startServer.sh server1
stopServer.sh
The command to stop server1 is:
<WAS_HOME>/bin/stopServer.sh server1
To open the Administrative Console, start your Web browser (Mozilla in our case)
and enter the following URL:
http://localhost:9090/admin
You should see the Administrative Console Login window, shown in Figure 2-11.
Figure 2-11 Administrative Console Login window
WebSphere Application Server security is not enabled yet, so we can enter any
User ID to log into the Administrative Console. In our example, we used admin to
log in.
Tip: Launching the Administrative Console from the First Steps window
requires Netscape. Our Red Hat Linux Advanced Server V2.1 installation did
not install the Netscape browser by default. To use Mozilla instead of
Netscape:
1. First check where Mozilla is installed, for example:
# which mozilla
/usr/bin/mozilla
2. Then create a symbolic link:
# ln -s /usr/bin/mozilla /usr/bin/netscape
The window in Figure 2-12 will be displayed after logging in.
Figure 2-12 Administrative Console
Check that you can access the application server through WebSphere
Application Servers embedded Web server as follows:
1. Start a Web browser window and enter the URL:
http://localhost:9080/snoop
2. The browser should display the snoop servlet page, as shown in Figure 2-13
on page 33.
Figure 2-13 Snoop servlet
Finally, use the following steps to check that you can access the application
server through your Web server:
2. Start the Web server. Use the following command to start IBM HTTP Server,
for example:
<IHS_HOME>/bin/apachectl start
You should get a confirmation similar to:
/opt/IBMHttpServer/bin/apachectl start: httpd started
3. Start a Web browser window and enter the URL:
http://localhost/snoop
Tip: If you have the Apache HTTP Server installed, you may need to stop it
before starting IBM HTTP Server. You can use the following command to
stop Apache HTTP Server:
service httpd stop
4. The browser should display the snoop servlet page, as seen in Figure 2-13 on
page 33.
Congratulations, you have successfully installed IBM HTTP Server and
WebSphere Application Server V5.0.
2.4 WebSphere Application Server configuration
This section describes the following configuration tasks:
Updating the Web server plug-in configuration
Configuring an SSL transport
For details on controlling WebSphere Application Server and IBM HTTP Server
startup at system boot time, see Appendix C, Service scripts and runlevel
configuration on page 135.
Updating the Web server plug-in configuration
Changing certain WebSphere configuration properties makes it necessary to
regenerate the Web server plug-in configuration. To accomplish this, do one of
the following:
From the Administrative Console, select Environment -> Update Web
Server Plugin in the navigation tree, then click OK, as shown in Figure 2-14.
Figure 2-14 Regenerating the Web server plug-in configuration from the console
Use the script GenPluginCfg.sh script from the command line:
<WAS_HOME>/bin/GenPluginCfg.sh
Configuring an SSL transport
SSL configuration for WebSphere Application Server is described in detail in the
redbook, IBM WebSphere V5.0 Security Handbook WebSphere Handbook
series, SG24-6573. This redbook covers the IBM WebSphere Application Server
V5.0 security in great detail. We recommend that you download this book to
familiarize yourself with the various security aspects that an enterprise
installation requires.
We followed the instructions given in the IBM WebSphere V5.0 Security
Handbook WebSphere Handbook series, SG24-6573, and succeeded in
preparing the SSL configuration on the Web server and on the application server
in our Linux environment, with the following notes:
Windows path names must be replaced with the Linux path names. For
example:
C:\WebSphere\AppServer
becomes:
/opt/WebSphere/AppServer
Scripts ending in .bat end with .sh on the Linux platform. For example:
ivt.bat
becomes:
./ivt.sh
We replaced the server names given with the server names used in our Linux
server names.
Chapter 3. Implementing a multi-tier
runtime environment
This chapter provides detailed instructions for implementing a WebSphere
Application Server in a multi-tier runtime environment.
The chapter is organized into the following sections:
Planning for a multi-tier runtime
Implementing a two-tier remote Web server runtime
Implementing a two-tier remote database server runtime
Implementing a three-tier runtime
Implementing a Network Deployment cluster
3
3.1 Planning for a multi-tier runtime
This section defines the hardware and software used within our WebSphere
Application Server multi-tier scenarios (two-tier remote Web server, two-tier
remote database server, and three-tier).
Overview
Hardware and software prerequisites
Hardware used within our test environment
Software used within our test environment
Linux installation
3.1.1 Overview
In this section we describe selected multi-tier environments using the IBM
Patterns for e-business notation. Patterns for e-business are a group of reusable
assets that can help speed the process of developing Web-based applications.
The Runtime patterns (see Figure 3-1 on page 39 through Figure 3-3 on
page 41) interconnect nodes to group the functional and operational
components. The Self-Service Stand-Alone application pattern overlay shows
how presentation logic, application logic, and data are deployed to the Runtime
pattern. For more information on IBM Patterns for e-business, see:
http://www.ibm.com/developerWorks/patterns
The multi-tier environment can be built a number of ways, depending on the
security and business requirements you may have:
1. Two-tier remote Web server:
Machine A: IBM HTTP Server
Machine B: WebSphere Application Server and DB2 Server
In this scenario, the Web server is installed on one machine, and the
database server and the WebSphere Application Server are installed on a
separate machine, as shown in Figure 3-1 on page 39.
This allows for a firewall to be placed in between and keeps all application
code and data behind the firewall. A potential downside to this configuration is
that database-intensive applications may need to use a database server
running on a separate machine for performance reasons.
Chapter 3. Implementing a multi-tier runtime environment 39
Figure 3-1 Runtime pattern: Two-tier remote Web server
2. Two-tier remote database server:
Machine A: IBM HTTP Server, WebSphere Application Server, DB2 Client
Machine B: DB2 Server
In this scenario the Web Server, WebSphere Application Server, and
database client are installed on one machine, and the database server is
installed on a separate machine, as shown in Figure 3-2 on page 40.
This allows the database server to be separately sized and tuned for
database performance, which may differ from the optimal configuration for the
application server. It also still allows for a firewall to be used to protect
application data; however, the application code is more vulnerable to
intruders.
Machine A
Internal Network Demilitarized Zone
(DMZ)
Outside World
I
N
T
E
R
N
E
T
Client
Database
P
r
o
t
o
c
o
l

F
i
r
e
w
a
l
l
Stand-Alone application pattern
Presentation Application
Application
Server
Web
Server
Machine B
D
o
m
a
i
n

F
i
r
e
w
a
l
l
Figure 3-2 Runtime pattern: Two-tier remote database server
3. Three-tier remote Web server and database server:
Machine A: IBM HTTP Server
Machine B: WebSphere Application Server and DB2 Client
Machine C: DB2 Server
In this scenario the Web server, the WebSphere Application Server, and the
database server are installed on three separate machines, as shown in
Figure 3-3 on page 41.
The three-tier environment is set up for performance, scalability, and security
reasons. Having the three separate servers, as seen in Figure 3-6 on
page 47, allows for the placement of firewalls between critical servers and
also allows for the addition of servers to either of the three tiers with the least
amount of hassle.
Machine A
(DMZ)
Outside World
I
N
T
E
R
N
E
T
Client
P
r
o
t
o
c
o
l

F
i
r
e
w
a
l
l
Database
Server
Web
Application
Server
Machine B
D
o
m
a
i
n

F
i
r
e
w
a
l
Figure 3-3 Runtime pattern: Three-tier remote Web server and database server
It is up to the reader to decide which configuration best suits their needs. The
choice will require looking at factors such as those given above, size and
capacity of the available systems, and the characteristics of the Web application.
If it makes heavy use of databases, it might make sense to isolate the database
server to give it as much power as possible. If the application is computation
intensive with a lot of static content, it might be better to separate the Web server
and application server.
The following sections provide instructions on how to implement the three
runtime environment scenarios, as well as the hardware and software we used in
our test environment.
3.1.2 Hardware and software prerequisites
The prerequisites for the multi-tier environment are the same as for the single-tier
environment in 2.1.1, Hardware and software prerequisites on page 10.
The only significant difference between the hardware and software prerequisites
for single-tier and multi-tier environments are that the disk space requirements
will be divided up accordingly between multiple servers.
Machine A Machine B Machine C
(DMZ)
Outside World
I
N
T
E
R
N
E
T
Client
Database
Server
P
r
o
t
o
c
o
l

F
i
r
e
w
a
l
l
Application
Server
Web
Server
D
o
m
a
i
n

F
i
r
e
w
a
l
l
3.1.3 Hardware used within our test environment
We used the systems listed in Table 3-1 within our multi-tier environments.
Table 3-1 Test environment details
3.1.4 Software used within our test environment
The software used in the multi-tier environments is the same as that used in the
single-tier environment:
Red Hat Linux Advanced Server V2.1
IBM WebSphere Application Server base V5.0
IBM DB2 UDB Enterprise Server Edition V8.1 for Linux
IBM HTTP Server V1.3.26 for Linux
3.1.5 Linux installation
All three systems (Web server, application server, and database server) should
be installed with Red Hat Linux following the instructions in 2.2, Linux
installation on page 15.
In our setup, the three systems listed in Table 3-1 were configured with the
network settings shown in Table 3-2.
Table 3-2 Network settings
Type IBM PC300PL IBM PC300PL IBM PC300PL
CPU P-II 433 MHz P-III 667 MHz P-III 667 MHz
RAM 512 MB 512 MB 512 MB
Hard disk 6 GB 20 GB 20 GB
Network IBM 16/4 Token-Ring Ethernet Pro 100 Ethernet Pro 100
Video Adapter S3 Trio S3 Savage 4 S3 Savage 4
Setting Machine A Machine B Machine C
Hostname websrv1l appsrv1l entsrv1l
IP address 192.168.10.6 9.24.105.28 9.24.105.11
Netmask 255.255.255.0 255.255.254.0 255.255.254.0
Network 192.168.10.0 9.24.104.0 9.24.104.0
To establish communication through the firewall (shown in Figure 3-1 on page 39
through Figure 3-3 on page 41) we defined a static route in the file
/etc/sysconfig/static-routes on the Red Hat Linux system of machine B or
machine C. It routes traffic for the 192.168.10.0 DMZ network to the secure
interface of the domain firewall.
cat /etc/sysconfig/static-routes
eth0 net 192.168.10.0 netmask 255.255.255.0 gw 9.24.105.14
In our environment, we configured the same file systems on all servers for
simplicity. In a real-world scenario, the appropriate file systems would be created
on each server. For instance, the database server would primarily need space in
/opt/IBM/db2 and /home/<db2_instance_owner>.
3.2 Implementing a two-tier remote Web server runtime
This scenario is built as shown in Figure 3-4 with the Web server on machine A,
and the database and application servers on machine B.
Figure 3-4 Remote Web server two-tier
Install the DB2 Server on machine B
Install WebSphere Application Server on machine B
Install IBM HTTP Server on machine A
Update the WebSphere plug-in file on machine A
Verify WebSphere Application Server from machine A
Gateway 192.168.10.254 9.24.104.1 9.24.104.1
Setting Machine A Machine B Machine C
Client
80/443
F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
80/443
Internet
Red Hat Linux
WepSphere
Applicaton
Server
DB2
Server
Database &
Application Server
IBMHTTP
Server
V1.3.19
Red Hat Linux
IBMHTTP
Server
P
l
u
g
i
n
Web Server
Optional
9080/
9443
F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
9080/
9443
Machine A
Machine B
3.2.1 Install the DB2 Server on machine B
Refer to the steps in Installing IBM DB2 Server on page 118 to install the DB2
server software on the database server system (machine B).
3.2.2 Install WebSphere Application Server on machine B
In this scenario, the installation of the application server is the same as in the
single-tier installation (see 2.3, WebSphere Application Server installation on
page 18) except that the IBM HTTP Server and the WebSphere plug-in need to
be deselected during the custom installation step.
Perform the installation on machine B, as seen in Figure 3-4 on page 43.
3.2.3 Install IBM HTTP Server on machine A
Use the procedure described in Appendix A, Installing IBM HTTP Server on
page 103 to install, configure, and verify IBM HTTP Server for Linux on the Web
server machine (machine A).
3.2.4 Update the WebSphere plug-in file on machine A
One main requirement when separating the WebSphere Application Server from
the IBM HTTP Server on separate machines is that the WebSphere plug-in has
to be transferred to the Web server after being (re)generated on the application
server.
1. Log in as root on machine B and start a terminal session.
2. If not already done during the WebSphere Application Server installation,
update the plug-in configuration, for example:
/opt/WebSphere/AppServer/bin/GenPluginCfg.sh
See Updating the Web server plug-in configuration on page 34 for details.
3. Copy the plug-in configuration file to the Web server on machine A, for
example:
export WASCFG=<WAS_HOME>/config/cells
scp $WASCFG/plugin-cfg.xml <webserver>:$WASCFG/plugin-cfg.xml
Note: You can substitute your favorite file transfer mechanism/program for
scp in the above command. The advantage of using scp is security and the
ability to pass through firewalls. The scp command uses the SSH protocol,
which is an encrypted protocol. Most corporate firewalls will block FTP
access to their public Web servers, but will allow SSH traffic.
For example, on our two-tier system we used the following commands:
export WASCFG=/opt/WebSphere/AppServer/config/cells
scp $WASCFG/plugin-cfg.xml websrv1l:$WASCFG/plugin-cfg.xml
4. Log in as root on the Web server and restart the IBM HTTP Server to ensure
the plug-in configuration is re-read:
/opt/IBMHTTPServer/bin/apachectl restart
3.2.5 Verify WebSphere Application Server from machine A
The Web server plug-in configuration can be verified by requesting a servlet
through the Web server that will be served by the WebSphere Application Server
on machine B. Using a Web browser, enter the following URL:
http://<webserver>/snoop
For example, in our case we used:
http://websrv1l/snoop
3.3 Implementing a two-tier remote database server
runtime
In this scenario, shown in Figure 3-5 on page 46, the Web server and application
server are installed on machine A, and the database server is installed on a
separate system, machine B.
Tip: In the above commands we set up a variable, WASCFG, to
temporarily store the path to the plugin-cfg.xml file. This was purely to
make the above commands look more readable in this document. There is
no reason you couldnt substitute the actual path for the $WASCFG portion in
the scp commands above and drop the export command altogether.
Figure 3-5 Remote database server two-tier
This section includes the following tasks:
Install the DB2 server on machine B
Install the DB2 client on machine A
Install WebSphere Application Server on machine A
3.3.1 Install the DB2 server on machine B
3.3.2 Install the DB2 client on machine A
Refer to the steps in Installing IBM DB2 Client on page 129 to install the DB2
client software on the application server system (machine A).
3.3.3 Install WebSphere Application Server on machine A
On the application server system, machine A, install the WebSphere Application
Server. Refer to 2.3, WebSphere Application Server installation on page 18,
being sure to include the IBM HTTP Server during the installation.
also on machine A. Using a Web browser, enter the following URL:
Optional
Client
80/443
F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
80/443
Internet
Database Server
DB2
Server
Red Hat Linux
Web and
Application Server
Red Hat Linux
Plugin
WebSphere
App Server
IBMHTTP
Server F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
DB2
Client
Machine A Machine B
3.4 Implementing a three-tier runtime
This scenario is built as shown in Figure 3-6 with the Web server, application
server, and database server on three separate machines: machine A, machine B,
and machine C.
Figure 3-6 WebSphere Application Server for Linux three-tier runtime environment
Install the DB2 server on machine C
Install the DB2 client on machine B
Install WebSphere Application Server on machine B
Install the IBM HTTP Server on machine A
Update the WebSphere plug-in file on machine A
3.4.1 Install the DB2 server on machine C
3.4.2 Install the DB2 client on machine B
Refer to the steps in Installing IBM DB2 Client on page 129 to install the DB2
client software on the application server system (machine A).
80/443
Client
80/443
Internet
IBMHTTP
Server
V1.3.19
RedHat Linux
IBMHTTP
Server
P
l
u
g
i
n
Database Server
DB2 Server
Red Hat Linux
Application Server
WebSphere
Application
Server
RedHat Linux
Web Server
Optional
9080/
9443
F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
9080/
9443
F
i
r
e
w
a
l
l
F
i
r
e
w
a
l
l
DB2 Client
3.4.3 Install WebSphere Application Server on machine B
In this scenario, the installation of the application server is the same as in the
single-tier installation (see 2.3, WebSphere Application Server installation on
page 18) except that the IBM HTTP Server and the WebSphere plug-in need to
be deselected during the custom installation step.
Perform the installation on machine B, as seen in Figure 3-6 on page 47.
3.4.4 Install the IBM HTTP Server on machine A
Use the procedure described in Appendix A, Installing IBM HTTP Server on
page 103 to install, configure, and verify IBM HTTP Server for Linux on the Web
server machine (machine A).
3.4.5 Update the WebSphere plug-in file on machine A
Update the WebSphere plug-in configuration file on machine A as described in
3.2.4, Update the WebSphere plug-in file on machine A on page 44.
on machine B. Using a Web browser, enter the following URL:
3.5 Implementing a Network Deployment cluster
This section guides you through the implementation of an IBM WebSphere
Application Server Network Deployment V5.0 cluster. We cover the following
tasks:
Network Deployment overview
Network Deployment installation
Cluster configuration
3.5.1 Network Deployment overview
IBM WebSphere Application Server Network Deployment V5.0 consists of the
base WebSphere Application Server and the Network Deployment add-on
module. Network Deployment enables distributed configurations and workload
management.
WebSphere V5.0 introduces some new terminology for distributed systems
management:
A cell is a network of nodes in a logical administration domain.
A node is a machine on which you are running an application server.
The deployment or cell manager manages the nodes in a cell.
A node agent resides on each node and manages the servers running on the
node.
A managed process or server is an application server, JMS server, node
agent, or deployment manager. Each server runs in its own JVM.
A cluster is a set of servers that are managed together and participate in
workload management. Servers in a cluster can be on one node (vertical
clustering) or on multiple nodes (horizontal clustering).
Figure 3-7 show a basic WebSphere Application Server Network Deployment
topology.
Figure 3-7 WebSphere Application Server Network Deployment topology
Cell
Node
Application
server
Application
server
Application
server
Node Node
Node agent Node agent
Deployment
manager
3.5.2 Network Deployment installation
This section has step-by-step instructions on how to install IBM WebSphere
Application Server Network Deployment V5.0.
To install IBM WebSphere Application Server Network Deployment V5.0:
2. Insert and mount the IBM WebSphere Application Server Network
Deployment V5.0 CD-ROM:
mount /mnt/cdrom
3. Start the WebSphere Application Server LaunchPad. For example:
cd /mnt/cdrom
./LaunchPad.sh
4. In the Language Selection window, select English and click OK.
5. In the Network Deployment LaunchPad window, click Install the product, as
shown in Figure 3-8.
Figure 3-8 Network Deployment LaunchPad
6. In the wizard language selection window, select English and click OK.
7. In the Welcome to WebSphere Application Server Network Deployment
window, click Next to continue.
8. In the software license agreement window, select I accept the terms in the
license agreement and click Next to agree to the terms of the agreement.
9. Click Next in the features selection window, as shown in Figure 3-9.
Figure 3-9 Selecting features to install
10.In the setting the installation directories window, click Next to accept the
default installation directory: /opt/WebSphere/DeploymentManager.
11.In the node, host and cell name window, enter the node name, host name,
and cell name for your installation. Our settings are shown in Figure 3-10 on
page 52.
Make a note of the following names, because we will need them later:
Node Name
Host Name or IP Address
Cell Name
Click Next.
Figure 3-10 Setting the node, host, and cell names
12.In the next window, verify your installation settings, and click Next to start the
installation.
13.Once the installation is complete, click Finish in Installation Wizard finished
window.
After a successful installation of IBM WebSphere Application Server Network
Deployment V5.0 the First Steps window will automatically start. Click Exit to
close First Steps, then click Exit to close LaunchPad.
Congratulations, you have successfully installed the IBM WebSphere Application
Server Network Deployment V5.0.
3.5.3 Cluster configuration
In this section we create and configure a horizontal cluster, as shown in
Figure 3-11 on page 53. One machine runs IBM HTTP Server and the
Tip: You can monitor the installation progress by checking the log file. For
example:
tail -f /tmp/log.txt
WebSphere plug-in, two machines run the default installation of WebSphere
Application Server, and a fourth machine runs only the default installation of IBM
WebSphere Application Server Network Deployment V5.0.
Figure 3-11 Horizontal configuration
Cell configuration
WebSphere Application Server Administration server and the Network
Deployment Manager utilize the same port. Therefore, it is necessary to stop the
WebSphere Application Server administration server. That only applies if you
have both servers installed on the Deployment Manager machine.
2. Start the Deployment Manager, for example:
cd /opt/WebSphere/DeploymentManager/bin
./startManager.sh
3. To open the Administrative Console, start your Web browser and enter the
following URL:
4. The Administrative Console Login window should appear. Enter a user ID and
click OK.
5. Once we have started the Deployment Manager, we can add a node to the
cell. To add a node to the cell:
a. On the machine you want to add to the cell, log in as root and start a
terminal session.
Client
Internet
IBM HTTP
Server
V1.3.19
IBM HTTP
Server
Plug-
in
Web Server (websrv1l)
Application Server (appsrv1l)
WebSphere
Application Server
WebSphere
Node Agent
Red Hat Linux
Application Server (appsrv2l)
WebSphere
Application Server
WebSphere
Node Agent
Red Hat Linux
Red Hat Linux
IBM HTTP
Server
V1.3.19
Deployment Manager (appsrv3l)
WebSphere
Network
Deployment
Red Hat Linux
b. Use the addNode command to add the node to the cell:
./addNode.sh <cell_host> <cell_port> -includeapps
Where:
<cell_host> is the host name of the deployment manager. Use the
host name you noted during the installation.
<cell_port> is by default port 8879.
The -includeapps option will include the installed applications on this
server node.
For example:
./addNode.sh appsrv3l.itso.ral.ibm.com 8879 -includeapps
Repeat for the second node, or any additional nodes.
6. Back in the Deployment Manager Administrative Console, select System
Administration -> Nodes in the navigation pane. In the Nodes list, you
should be able to see the nodes in your cell with the host name of your
machines. Our nodes are shown in Figure 3-12. The first two nodes displayed
are the remote machines we just added to the Network Deployment cell.
Figure 3-12 Cell nodes list from Administrative Console
Cluster configuration
In the following sections, we describe the steps to create and configure a cluster.
1. In the left navigation pane of the Administration Console, select Servers ->
Clusters, as shown in Figure 3-13 on page 55.
Figure 3-13 Cluster management
2. In the Server Cluster form, click New.
3. In the Create New Cluster form, enter a Cluster Name, for example
ITSOCluster, leave the remaining fields at their default values, and click Next.
4. In the Create New Clustered Servers form, enter a name, for example
ITSO_WLM_Server1, select the node, for example appsrv1l, leave the
remaining fields at their default values, and click Apply, as shown in
Figure 3-14.
The application server will be added to the list at the bottom of the Create
New Clustered Servers form.
Figure 3-14 Create New Clustered Servers
5. Still in the Create New Clustered Servers form, add a second cluster server
by entering the name, for example ITSO_WLM_Server2, selecting the node,
for example appsrv2l, then clicking Apply.
Both application servers should now be listed at the bottom of the Create New
Clustered Servers form.
6. Click Next to continue.
7. In the Summary form, review the configuration and click Finish.
The Server Cluster form is displayed with the ITSOCluster listed.
8. Save this configuration by clicking Save in the menu bar.
Starting the cluster
The next step is to start the cluster:
1. In the left navigation pane, select Servers -> Clusters.
2. In the Server Cluster form, check ITSOCluster, then click Start, as shown in
Figure 3-15.
Figure 3-15 Starting the server cluster
3. To verify if the ITSOCluster has started, open a terminal window on each of
the cluster server nodes and tail the cluster server log.
In our example, we opened a terminal session on appsrv1l and entered the
following command:
tail -f /opt/WebSphere/AppServer/logs/ITSO_WLM_Server1/SystemOut.log
We then opened a terminal session on appsrv2l and entered the following
command:
tail -f /opt/WebSphere/AppServer/logs/ITSO_WLM_Server2/SystemOut.log
You should see an entry similar to Server ITSO_WLM_Server[1|2] open for
e-business in both logs, when each cluster server has started.
The Server Cluster pane in the Administrative Console should also display
the green running icon in the status column for the ITSOCluster.
3.5.4 Deploying a sample clustered application
In this section we install a sample enterprise application in our new cluster.
Instructions for finding the Hello.ear sample application are in Appendix D,
Additional material on page 141.
To install a sample clustered application:
1. Copy your enterprise application archive (EAR) file to the Deployment
Manager installableApps folder, for example:
cp Hello.ear /opt/WebSphere/DeploymentManager/installableApps
2. To open the Network Deployment Administrative Console, start your Web
browser and enter the following URL:
3. The Administrative Console Login window should appear. Enter a user ID and
click OK.
4. Select Applications -> Install New Application in the navigation pane on
the left.
5. In the Preparing for the application installation window, browse to the
installableApps folder, select the EAR file you want to install, and click Next,
as shown in Figure 3-16. In our case the EAR file to install is
/opt/WebSphere/DeploymentManager/installableApps/Hello.ear.
Figure 3-16 Preparing for the application installation
6. Click Next in the following window to use the existing bindings and mappings
defined in the EAR file.
7. In the Install New Application window, click Next to accept the defaults for
Step 1: Provide options to perform the installation.
8. Click Next to accept the defaults for Step 2: Map virtual hosts for Web
modules.
9. In Step 3: Map modules to application servers, check HelloWeb in the
module list, select ITSOCluster from the list of clusters and servers, and click
Apply.
You should see the HelloWeb module mapped to the ITSOServer cluster, as
shown in Figure 3-17.
Click Next.
Figure 3-17 Mapping modules to application servers
10.In Step 4: Summary, review your selections and click Finish to deploy the
enterprise application.
11.To monitor the installation progress, type the following command in a terminal
session on the deployment manager node:
tail -f /opt/WebSphere/DeploymentManager/logs/dmgr/SystemOut.log
12.Dont forget to click Save after successfully installing the application.
13.By default, the newly installed applications are not started. To start the
application, select Applications -> Enterprise Applications, check Hello in
the application list, and click Start, as shown in Figure 3-18 on page 59.
Figure 3-18 Starting the enterprise application
14.Select Environment -> Update Web Server Plugin in the navigation tree,
then click OK to update the Web server plug-in configuration file.
15.Copy the plug-in configuration file from the Deployment Manager node to the
Web server machine. For example:
scp /opt/WebSphere/DeploymentManager/config/cells/plugin-cfg.xml \
websrv1l:/opt/WebSphere/AppServer/config/cells/plugin-cfg.xml
16.Restart the Web server to ensure the plug-in configuration is re-read:
/opt/IBMHTTPServer/bin/apachectl restart
17.Using a Web browser, enter the URL for the application, for example:
http://websrv1l/Hello/hello.jsp
Requests should be workload managed across the available cluster servers.
As shown in Figure 3-19 on page 60 and Figure 3-20 on page 60, our user
requests are workload managed across the ITSO WLM Server1 and ITSO
WLM Server2.
Important: WebSphere Network Deployment is not installed on our Web
server machine, so we also must edit the plugin-cfg.xml file and replace all
paths to /opt/WebSphere/DeploymentManager with
/opt/WebSphere/ApplicationServer. See the WebSphere InfoCenter article,
Situations requiring manual editing of the plug-in configuration for details.
Figure 3-19 Hello page for ITSO WLM Server1
Figure 3-20 Hello page for ITSO WLM Server2
Chapter 4. Application deployment
Throughout this chapter, we utilize the ITSOBank sample application developed
for the IBM WebSphere V5.0 Security Handbook WebSphere Handbook series,
SG24-6573 redbook. We use this sample application to demonstrate the
deployment and installation of an enterprise application in a WebSphere
Application Server runtime environment.
This chapter is organized into the following sections:
J2EE application packaging
Deployment considerations
Deploying a J2EE application
4.1 J2EE application packaging
The J2EE specification provides instructions for assembling, packaging, and
deploying J2EE applications. As shown in Figure 4-1 on page 62, J2EE
components are packaged into modules, modules are then packaged into
applications, and applications are then deployed. Each module and application
contains a J2EE deployment descriptor.
4
Figure 4-1 J2EE 1.3 packaging
4.1.1 Assembling and deploying applications
J2EE modules are used to assemble application components into deployable
units. Assembly is the process of specifying which files make up the module,
creating deployment descriptor files for the module, and packaging these files in
an archive. Modules are used to represent any of the following:
One or more Web components. Web components are servlets or JavaServer
Pages (JSPs).
One or more enterprise beans.
Application clients.
A J2EE application consists of any combination of the above.
Figure 4-2 on page 63 provides an overview of the roles, tasks, tools, and stages
involved in assembling and deploying J2EE applications on IBM WebSphere
Application Server V5.0:
Application component providers use an IDE such as WebSphere Studio to
develop J2EE application components, including servlets, JSPs, EJBs, and
utility classes.
Message-driven
(new in J2EE 1.3)
EJB
Stateful
EJB
Stateless
EJB
Session
Web deployment
descriptor
EJB deployment
descriptor
Application client deployment
descriptor
servlet
JSP
HTML
etc
Java
class
CMP
EJB
BMP
EJB
Entity
Application deployment
descriptor
Web module
.war file
EJB module
.jar file
Client module
.jar file
Resource adapter
.rar file
(new in J2EE 1.3)
J2EE application
.ear file
Chapter 4. Application deployment 63
Application assemblers use a tool such as WebSphere Studio or the
Application Assembly Tool to assemble application components into modules,
and modules into an enterprise archive.
Deployers can use the WebSphere Administrative Console or the wsadmin
command-line tool to deploy enterprise archives to WebSphere Application
Server.
System administrators can use the WebSphere Administrative Console or the
wsadmin command-line tool to administer enterprise applications running on
WebSphere Application Server.
Figure 4-2 Roles, tasks, tools and stages
4.2 Deployment considerations
This section discusses considerations when setting up a WebSphere Application
Server runtime environment for deployment of an enterprise application. Issues
WebSphere
Application
Server
Application
Assembler
Deployer
System
Administrator
Application
Component
Provider
Set of
Components
develop package deploy administer
Development Stage
Testing Stage
Production/Staging Stage
Application
Assembly
Tool
(AAT)
WebSphere
Studio
WebSphere
Admin
Console
wsadmin
Command
Line Tool
WebSphere
Admin
Console
Web
EJB
JAR
WebSphere
Studio
Enterprise
Archive
Enterprise
Archive
Task Role Tool
Legend:
wsadmin
Command
Line Tool
such as deployment stages, multi-tiered environments, Linux users, file systems,
file transfers, and security are discussed.
There are a number of factors to consider when developing assets in a Windows
environment and deploying them to a Linux runtime environment. The term
deployment in this chapter refers to the movement of developed assets from the
development environment to a usable form in the runtime environment.
The following issues should be taken into consideration:
Deployment assets
General deployment considerations
Deployment stages
Deployment nodes and tiers
Clustered environments (shared file systems)
Security (user access, file transfer mechanisms)
File transfer methods for deployment
File system (location of temporary files, user access)
4.2.1 Deployment assets
The WebSphere Application Server J2EE deployment modules include the
following:
JAR files - Java archive consisting of Java classes, Enterprise JavaBeans
and associated deployment descriptors, and Java property files.
WAR files - Web application archive consisting of JSPs, servlets, Java code,
XML configuration files, and static content such as HTML files and images.
EAR files - Enterprise application archive consisting of JAR files (EJB, Java
code), WAR files, and XML configuration files.
Static content - HTML, images (GIFs, JPEGs), and Cascading Style Sheets
(CSS) should be considered as separate deployable assets even though they
can also be packaged in WAR files. Typically, production environments
separate the static content (HTTP server) from the dynamic content (Web
application server) when deployed.
4.2.2 General deployment considerations
This section includes considerations for general deployment issues regarding
enterprise Web assets.
Separation of static and dynamic content
WAR files provide the flexibility to package the static content (HTML, Images,
CSS, etc.) in the same WAR file as dynamic content, such as JSPs and servlets.
This requires that the WebSphere Application Server serve the static HTML and
image files. The advantage of this is the capability to have a single WAR file that
contains the entire Web application. This is useful when testing and when quick
packaging and deployment are needed. However, this method should not be
used in production.
The preferred production method is to separate the static content that can be
served by an HTTP server. This allows you to separate the HTTP server node
from the Web application server node. Separation of static from dynamic content
also provides performance benefits, since the HTTP server is tuned for file
serving functions.
This will be demonstrated with the ITSOBank application in 4.3.4, Separating
static and dynamic Web content on page 97.
Package common Java classes in a separate JAR file
Typically in a Web application, there are a number of utility Java classes that are
used by various components of the enterprise application. These common
classes should be packaged in a separate JAR file and assembled as part of the
enterprise application (EAR file), not as part of the EJB deployment JAR or the
Web application (WAR file).
4.2.3 Deployment stages
In a typical Web application life cycle, there are multiple stages that the
application goes through. A typical scenario includes, but is not limited to:
Development stage (source code development and unit testing)
Testing stage (may be multiple testing stages)
Staging stage (production-like environment for final verification before going
into production)
Production stage
Development stage
A typical scenario begins with the development stage where the Web application
assets are developed and unit tested for single-unit functionality. With the use of
the integrated testing facilities of WebSphere Studio V5.0, the unit testing is
typically done in the development environment.
Deploying from development to testing
The next stage is typically some type of integration testing stage where multiple
functions are brought together for the first time for integration testing. There may
be multiple testing stages: one for integration testing, one for multi-tiered testing,
etc.
Integration testing is typically done on the target runtime platform so this is the
first time that developed assets must be deployed to a separate runtime
environment. Since the test environment is typically in a very controlled
environment, the deployment considerations are not as rigorous as they are
when deploying to a staging or production environment. This means that your
choice of file transfer mechanism and user access security can typically be
focused on what's easier for the development and test teams.
Deploying from testing to staging
After successfully completing the development and test cycle, the Web
application is ready to be deployed to a staging environment. A staging
environment is a near-production environment where Web applications can go
through final verification before going live. This allows all involved parties to
ensure that the staged Web application is indeed functioning as required.
It is at this point where security and file system issues become more important.
The staging and production environments are typically in environments that are
exposed to many other groups outside your immediate development team.
Deploying from staging to production
Typical staging and production environments are identical in every way except
that the production environment is accessible by the intended users of the
enterprise application, while the staging environment is only accessible by select
individuals or teams.
Deployment from staging to production is a simple, but secure, file propagation
from the staging server file system to the production server file system.
4.2.4 Deployment nodes and tiers
Deployment of an enterprise application typically involves multiple nodes and
tiers. Typical separation of server nodes is as follows for a three-tier runtime
environment:
HTTP server node (for example, IBM HTTP Server)
Web application server node (for example, IBM WebSphere Application
Server V5.0)
Database server node (for example, IBM DB2)
4.2.5 Clustered environments
WebSphere production environments may include a cluster of application
servers for load balancing and scalability. Although WebSphere V5.0 now
provides automatic distribution of application binaries and configuration data in a
cell, some type of shared file system may still be needed for synchronized file
access by multiple Web servers, for example. If this exists in your environment,
then you will need to take the appropriate steps to conform to the file system
structure and user access requirements of your shared file system.
Discussion of shared file systems and deployment is out of the scope of this
paper. However, it is a deployment consideration you must be aware of.
You can find further details on WebSphere clusters in 3.5, Implementing a
Network Deployment cluster on page 48.
4.2.6 Security considerations
Security and user access considerations vary from stage to stage. When
deploying assets from development to a test environment, security issues are
minimal since the test environment is typically in a very controlled environment
and only accessible by the development and test teams. In this environment,
FTP or a Samba server file share are suitable mechanisms for transferring files.
When deploying to a staging or production environment, extra security measures
must be taken to ensure that the Linux server is secure from unauthorized
access.
4.2.7 File transfer methods for deployment
Depending on the stage of deployment security requirements, you may use one
of the following methods to transfer files (Web assets) to the runtime
environment for deployment.
WebSphere built-in application distribution
WebSphere V5.0 can now install enterprise archives from the local machine
hosting your WebSphere Administrative Console browser, or from the
application server machine hosting the adminconsole application.
WebSphere will then transfer application configuration information and
binaries to all the required servers that the application runs on in a multi-node
cell, without manual intervention.
File sharing (Samba)
Direct file system sharing can be set up in non-production environments to
facilitate simple deployment of assets. Linux systems have the ability to share
file and print resources directly with PCs through the Samba package using
the NetBIOS protocol. More information can be found at:
http://www.samba.org/
Network File System (NFS)
The Network File System is a popular protocol for file sharing across TCP/IP
networks that is configured via the /etc/exports file.
FTP
FTP (File Transfer Protocol) can also be used as a transfer mechanism. Linux
comes with an FTP server that should be enabled by default depending on
the firewall settings chosen at install time.
SCP
SCP (Secure CoPy) uses an SSL (Secure Socket Layer) connection to safely
transfer files from one server to another. Typically this is used in a production
environment to enhance security. Production servers are usually hardened
and will not have an FTP server enabled. Red Hat Linux comes bundled with
Open SSH, which includes an SCP client and server. Normally, these files
would be transferred from a staging server to production servers; however, if
needed there are a few Windows-based SCP clients. One example is
WinSCP, found at:
http://winscp.vse.cz/eng/
4.2.8 File system considerations
This section discusses considerations for the target file system in various stages
of deployment.
WebSphere installable and installed applications directory
The organization of deployable and installed applications is important.
WebSphere Application Server creates two directories for this purpose:
Deployable applications: /opt/WebSphere/AppServer/installableApps
Installed applications: /opt/WebSphere/AppServer/installedApps
When an enterprise application is installed to the WebSphere Application Server,
an associated application directory is created in the
/opt/WebSphere/AppServer/installedApps directory containing enterprise
application assets:
HTTP server directories for static content
When separating the static content from the dynamic content, the static content
will be deployed somewhere within the HTTP server document root. In the
ITSOBank sample application, we will use the /var/www.itsobank directory for
storing the Web application static content:
Temporary directories for deployed assets
Unless you are deploying a fully created EAR file, you will need a temporary
location to store your JAR and WAR files on the Linux file system while you use
the Application Assembly Tool to create the final EAR file.
Whatever directory you choose to use, you must ensure that you have the
appropriate user access rights to create directories and files from the
development environment.
In the ITSOBank sample application, we will use a temporary directory,
/home/admin/itsobank, for storing our working files:
4.3 Deploying a J2EE application
The ITSOBank application is a simple enterprise application that manages
account and customer record information for a fictitious bank. The Web-based
application can be accessed either by a Web browser or by a custom-developed
client application. In this section, we will use this application in our example
deployment scenario.
The ITSOBank sample Web application includes the following types of assets:
Static Web content (HTML files, GIFs, JPEGs, CSSs)
Note: This temporary working directory should not be stored in the /tmp
directory. The /tmp directory is meant to be used as a very temporary storage
space. It is usually deleted often (every reboot, or sometimes every few hours)
to keep the system clean.
You may want to create a file system specifically for holding the temporary files
used in creating WebSphere applications. For example:
/opt/WebSphere/tempfiles
You could then create subdirectories for each application you are working with:
/opt/WebSphere/tempfiles/itsobank
These temporary files and directories can be cleaned out as necessary.
Dynamic Web content (JSPs, servlets)
Enterprise JavaBeans
Figure 4-3 shows how the ITSOBank application components (EJBs, Web
components, and application client) are packaged to create a J2EE enterprise
archive (EAR) for the application.
Figure 4-3 ITSOBank application packaging
The ITSOBank application components were packaged into an EAR file using
WebSphere Studio V5.0, but the Application Assembly Tool (AAT) can be used
as well. We exported the ITSOBank enterprise application from WebSphere
Studio V5.0 to an EAR file, as shown in Figure 4-4 on page 71.
Note: The development of Web assets using WebSphere Studio V5.0 is not
discussed in this chapter. For more detailed information regarding the use of
the tools and development of the ITSOBank sample application, refer to the
IBM WebSphere V5.0 Security Handbook WebSphere Handbook series,
SG24-6573 redbook.
itsobankEntityEJB.jar
ITSOBANK
Database
itsobankTransferQ
Message queue
itsobank.ear
itsobankClient.jar
itsobankEJB.jar itsobankWeb.war
BranchAccount
entity bean
CustomerAccount
entity bean
IncomingTransfer
message bean
Transfer
session bean
Consultation
session bean
AccountViewer
+ helper
JMSTransferServlet
+ helper
TransferServlet
+ helper
JSP, HTML,
images
Web
clients
Java
clients
Figure 4-4 Exporting an EAR file from WebSphere Studio
After packaging the application in an EAR file, we then need to configure the
WebSphere Application Server resources and the application database required
for ITSOBank. Once the runtime environment is configured, we deploy the
ITSOBank application to WebSphere Application Server. To complete the
exercise, we will try out the deployed ITSOBank application using a Web browser
and the J2EE application client.
Instructions for finding the ITSOBank sample application are in Appendix D,
The itsobank subdirectory contains the files listed in Table 4-1.
Table 4-1 Contents of the itsobank subdirectory
File name Description
/itsobank.ear Enterprise archive ready for installation on
WebSphere in a single-tier environment.
/itsobank.sql SQL script for setting up customer and account
tables and data. See Example 4-1 for the script
listing.
/itsobankweb.sh Shell script to extract the static Web content from
itsobank.ear for deployment on Web server.
Example 4-1 ITSOBank SQL script
create schema itsobank
create table itsobank.branchaccount (
branchid varchar(8) not null primary key,
branchaddress varchar(40),
branchname varchar(30),
balance int)
create table itsobank.customeraccount (
customerid varchar(8) not null,
accountnumber varchar(20) not null,
customername varchar(40),
accounttype varchar(1),
balance int,
primary key (customerid,accountnumber))
insert into itsobank.branchaccount values (
'raleigh',
'101 Bank street, Raleigh NC',
'Raleigh Grand Office',
100000)
insert into itsobank.branchaccount values (
'london',
'202 Financial street, London UK',
'London City Bank',
100000)
insert into itsobank.customeraccount values (
'johnd',
'11223344-12345678',
'John Doe',
'C',
1000)
4.3.1 Configuring WebSphere for hosting the application
This section describes how to configure the WebSphere Application Server
runtime environment, in preparation for hosting the ITSOBank application. The
tasks involved are:
Set up the database server
Set up the database client
Set up the JDBC provider and data source
Set up the JMS server
Set up the database server
The ITSOBank sample, like most enterprise applications, requires a database.
1. First, we need to create a user ID for accessing the ITSOBank application
database. To create a new operating system user:
a. Log in as root and start a terminal session.
b. Create the webas user, for example:
# useradd webas
c. Set the webas user password to webas, for example:
# passwd webas
Changing password for user webas
New password:
Retype new password:
passwd: all authentication tokens updated successfully
2. Next, we need to create the database and grant the new user access to the
database:
a. Log in as the DB2 instance owner, for example:
su - db2inst1
b. Attach to the database instance as the DB2 instance owner:
db2 attach to db2inst1 user db2inst1
c. Create the ITSOBank application database:
db2 create database itsoban1
d. Grant the webas user access to the application database:
db2 connect to itsoban1 user db2inst1
db2 grant dbadm on database to user webas
db2 disconnect current
3. Lastly, we need to populate the ITSOBank database with some account data.
Launch the itsobank.sql script to create the ITSOBank schema and tables,
and to insert some account data:
db2 connect to itsoban1 user webas
db2 -vf /home/admin/itsobank/itsobank.sql
Now that the database server is ready, lets configure the database client.
Set up the database client
The database client is used by the JDBC data source to access the ITSOBank
application database. To set up the database client:
1. From a DB2 command prompt, add a TCP/IP node entry to the node directory
for accessing the database node:
db2 catalog tcpip node <nodename> remote <hostname> server 50000
In our case, the database node is running locally, so:
Set <nodename> to the host name of the local machine, provided it
conforms to DB2 naming conventions (starts with a letter, no dashes, up to
eight characters, etc.).
Set <hostname> to the host name of the local machine.
Use the hostname command to find out the host name of your local machine.
2. Add the ITSOBank database location information to the system database
directory:
db2 catalog db itsoban1 as itsobank at node <nodename>
In our case, the database node is running locally, so:
Set <nodename> to the host name of the local machine.
3. Check that you can connect to the database:
db2 connect to itsobank user webas
Database Connection Information
Database server = DB2/LINUX 8.1.0
SQL authorization ID = WEBAS
Local database alias = ITSOBANK
db2 disconnect itsobank
4. Close the DB2 command prompt.
The database is now ready to use. We need to configure the WebSphere
resources needed for the ITSOBank application next.
Set up the JDBC provider and data source
In this section, we set up the JDBC data source that the ITSOBank uses to
access the ITSOBank database. To set up the data source:
1. Log in as root and start WebSphere Application Server from the command
prompt, as follows:
./startServer.sh server1
2. Once WebSphere has started, you can verify the WebSphere installation
using the ivt command:
./ivt.sh
You should get a message stating that the IVT verification succeeded.
3. Open the WebSphere Administrative Console in your browser, using the
following URL:
4. In the WebSphere Administrative Console login form, enter a user ID and
click OK. We use admin in our examples.
5. Once in the WebSphere Administrative Console home page, we first need to
create a new J2C authentication data entry for the JDBC data source.
To create a J2C authentication data entry for the JDBC data source:
a. In the navigation tree on the left, click Security -> JAAS Configuration ->
J2C Authentication Data.
b. In the J2C Authentication Data Entries form on the right, click New.
c. In the J2C Authentication Data Entries Configuration form, shown in
Figure 4-5 on page 76:
Set Alias to itsobankds_j2c.
Set User Id to webas.
Set Password to webas.
Click OK to create the entry.
Figure 4-5 New J2C Authentication Data Entries Configuration form
d. Back in the J2C Authentication Data Entries page, click Save to save the
configuration changes to the master repository.
6. To create the JDBC provider for our data source:
a. In the navigation tree, click Resources -> JDBC Providers.
b. In the JDBC Provider form, set the scope to Server - server1, as shown in
Figure 4-6, then click Apply.
Figure 4-6 JDBC Provider Scope
c. Click New to add a JDBC provider.
d. In the JDBC Provider Configuration form, select the DB2 JDBC Provider
(XA) from the list of JDBC providers, and click OK. The XA version of the
driver is required for transaction support.
e. Set the properties for the JDBC provider as follows:
Set the Classpath to /home/db2inst1/sqllib/java/db2java.zip, where
/home/db2inst1/sqllib is the instance path for DB2.
You can accept the defaults for the remaining fields.
Click OK to create the JDBC provider. The new provider should appear in
the JDBC Providers list, as shown in Figure 4-7.
Figure 4-7 JDBC Providers list
7. To create the data source:
a. Click the DB2 JDBC Provider (XA) provider you have just created from
the list.
b. In the DB2 JDBC Provider (XA) Configuration form, scroll down to the
Additional Properties section and click Data Sources.
c. In the Data Source form, click New.
d. In the Data Source Configuration form, shown in Figure 4-8 on page 78:
Set Name to itsobankds.
Set JNDI Name to jdbc/itsobankds.
Enable Use this Data Source in container managed persistence
(CMP). This will create a CMP_Connection_Factory for the
WebSphere Relational Resource Adapter with the name
itsobankds_CF, and with the JNDI name eis/jdbc/itsobankds_CMP.
Set Description to ITSOBank data source.
Set Category to itsobank.
Set both the Component-managed and the Container-managed
Authentication Aliases to itsobankds_j2c.
Click OK to create the data source. The new data source should appear in
the Data Source list.
Figure 4-8 JDBC Data Source General Properties
e. Click the itsobankds data source you have just created from the list.
f. In the Data Source Configuration form, scroll down to the Additional
Properties section and click Custom Properties.
g. In the Custom Properties form, click databaseName, set the value field to
ITSOBANK, then click OK to update the databaseName property.
h. Back in the Custom Properties form, click Save to save the configuration
changes to the master repository.
The JDBC provider and data source are now ready to use. We need to configure
the JMS resources needed for the ITSOBank application next.
Set up the JMS server
The ITSOBank uses a JMS queue to perform internal bank transfers. To
configure the internal JMS server for WebSphere Application Server, do the
following:
1. First, we need to create the queue connection factory that ITSOBank uses to
connect to the JMS provider. To set up the JMS queue connection factory:
a. In the WebSphere Administrative Console navigation tree, click
Resources -> WebSphere JMS Providers.
b. In the WebSphereJMSProvider form, set the scope to Server - server1,
then click Apply.
c. Scroll down to the Additional Properties section and click WebSphere
Queue Connection Factories.
d. In the WebSphere Queue Connection Factories form, click New.
e. In the WebSphere Queue Connection Factories Configuration form,
shown in Figure 4-9:
Set Name to itsobankQCF.
Set JNDI Name to jms/itsobankQCF.
You can leave the remaining fields as they are.
Click OK to create the queue connection factory. The new queue
connection factory should appear in the Queue Connection Factory list.
Figure 4-9 WebSphere Queue Connection Factory General Properties
2. Next, we need to create the queue that ITSOBank uses for internal bank
transfer messages. To set up the JMS queue, do the following:
a. In the WebSphere Administrative Console navigation tree, click
Resources -> WebSphere JMS Provider.
b. In the WebSphere JMS Provider form, set the scope to Server - server1,
then click Apply.
c. Scroll down to the Additional Properties section and click
WebSphere Queue Destinations.
d. In the WebSphere Queue Destinations form, click New.
e. In the WebSphere Queue Destinations Configuration form, shown in
Figure 4-10 on page 80:
Set Name to itsobankTransferQ.
Set JNDI Name to jms/itsobankTransferQ.
You can leave the remaining fields as they are.
Click OK to create the queue. The new queue should appear in the Queue
list.
Figure 4-10 WebSphere Queue Destinations General Properties
3. Now we need to configure the Message Listener Service so ITSOBanks
message-driven bean can receive JMS messages. To set up the Message
Listener Service, do the following:
a. In the WebSphere Administrative Console navigation tree, click Servers
-> Application Servers.
b. In the Application Servers form, click server1.
c. In the server1 Configuration form, scroll down to the Additional Properties
section and click Message Listener Service.
d. In the Message Listener Service Configuration form, scroll down to the
Additional Properties section and click Listener Ports.
e. In the Listener Ports form, click New.
f. In the Listener Ports Configuration form, shown in Figure 4-11 on page 81:
Set Name to IncomingTransferPort.
Set Initial state to Started.
Set Connection Factory JNDI Name to jms/itsobankQCF.
Set Destination JNDI Name to jms/itsobankTransferQ.
Click OK to create the listener port.
Figure 4-11 Listener Ports General Properties
4. We are using the WebSphere internal JMS server as the JMS provider (or
messaging system) for ITSOBank. To enable the WebSphere internal JMS
server:
a. In the navigation tree, click Servers -> Application Servers.
b. In the Application Server form, click server1.
c. In the Application Server Configuration form, scroll down to the Additional
Properties section and click Server Components.
d. In the Server Component form, click JMS Servers.
e. In the Internal JMS Server Configuration form, shown in Figure 4-12:
Add itsobankTransferQ to queueNames to make this queue available
to ITSOBank.
Set Initial State to Started to start the JMS server.
Click OK to update the Internal JMS Server configuration.
Figure 4-12 Internal JMS Server General Properties
f. Back in the Application Server Configuration form, click Save to save the
configuration changes to the master repository.
5. ITSOBank expects the system locale to be English (United States). If your
system locale is not English (United States), then JVM system properties can
be used to set the application servers locale to English (United States). You
can check your current locale using the locale command.
If you need to set the application server locale:
a. In the WebSphere Administrative Console navigation tree, click Servers
-> Application Servers.
b. In the Application Servers form, click server1.
c. In the server1 Configuration form, scroll down to the Additional Properties
section and click Process Definition.
d. In the server1 Process Definition form, scroll down to the Additional
Properties section and click Java Virtual Machine.
e. In the server1 Java Virtual Machine form, scroll down to the Additional
Properties section and click Custom Properties.
f. In the Property form, click New, and in the Property Configuration form:
Set Name to user.language.
Set Value to en.
Click OK.
g. Back in the server1 Java Virtual Machine form, scroll down to the
Additional Properties section and click Custom Properties.
h. In the Property form, click New, and in the Property Configuration form:
Set Name to user.region.
Set Value to US.
Click OK.
i. Back in the server1 Java Virtual Machine form, scroll down to the
Additional Properties section and click the Custom Properties link. Your
list of system properties should now look like Figure 4-13 on page 83.
Figure 4-13 Application server JVM system properties
j. Click Save to save the configuration changes to the master repository.
6. To close your Administrative Console session, go to the console taskbar and
click Logout.
7. Restart the application server. To start the internal messaging system, you
have to stop then restart the application server:
a. Stop WebSphere Application Server from the command prompt, as
follows:
./stopServer.sh server1
b. Re-start WebSphere Application Server, as follows:
./startServer.sh server1
Now that we have set up the resources needed by ITSOBank, we are ready to
deploy the application.
4.3.2 Deploying the application
To install the ITSOBank application in WebSphere Application Server, do the
following:
1. Copy the ITSOBank EAR file to the WebSphere installableApps folder, for
example:
cp /home/admin/itsobank/itsobank.ear \
/opt/WebSphere/AppServer/installableApps
Instructions for finding the ITSOBank sample application are in Appendix D,
2. Log in to the WebSphere Administrative Console.
3. In the navigation tree, select Applications -> Install New Application, to
start the Preparing for application installation wizard.
4. In the Specify the EAR/WAR/JAR module for upload and install form, select
the Server path option and enter
/opt/WebSphere/AppServer/installableApps/itsobank.ear, then click Next,
as shown in Figure 4-14.
Figure 4-14 Specify the EAR/WAR/JAR module for upload and install
5. In the You can choose to generate default bindings and mappings form, leave
the Generate Default Bindings option un-checked. For this example, we use
the bindings and mappings provided in the EAR file. Click Next.
6. Below the Step 1 form, first check that:
You have 11 steps listed for the itsobank.ear file (the number of steps
listed depends on the binding information required by the EAR file).
No steps have red stars.
If there are less than 11 steps, or any red stars, there may be a problem with
the itsobank.ear file, or with the WebSphere configuration from 4.3.1,
Configuring WebSphere for hosting the application on page 72.
We specified all the needed binding information when packaging the
ITSOBank application. It should now be a matter of just verifying the binding
information, as we step through the wizard.
7. In the Step 1 form, the Application Name is set to itsobank.
Click Next, as shown in Figure 4-15 on page 85.
Figure 4-15 Step 1: Provide options to perform the installation
8. In the Step 2 form, the IncomingTransfer message bean is bound to the
IncomingTransferPort Listener Port.
Click Next, as shown in Figure 4-16.
Figure 4-16 Step 2: Provide Listener Ports for Messaging Beans
9. In the Step 3 form, the JNDI Names of the Transfer and Consultation session
beans, and the BranchAccount and CustomerAccount entity beans are
specified.
Figure 4-17 Step 3: Provide JNDI Names for Beans
10.In the Step 4 form, the JNDI Name of the default CMP connection factory for
the itsobankEntityEJB module is specified.
Figure 4-18 Step 4: Provide default data source mapping for modules containing 2.0
entity beans
11.In the Step 5 form, the BranchAccount and CustomerAccount entity beans
both use the default data source specified for the itsobankEntityEJB module,
so there is no need to specify a data source for these CMP beans.
Figure 4-19 Step 5: Map data sources for all 2.0 CMP beans
12.In the Step 6 form, map each EJB reference defined in the application to an
EJBs JNDI Name.
Figure 4-20 Step 6: Map EJB references to beans
13.In the Step 7 form, map the Transfer EJBs JMS resource references to the
required JMS queue connection factory and queue JNDI names.
Figure 4-21 Step 7: Map resource references to resources
14.In the Step 8 form, map the itsobankWeb Web Module to the default_host
Virtual Host.
Figure 4-22 Step 8: Map virtual hosts for web modules
15.In the Step 9 form, you can map each module in the application to a different
application server. Web modules could be installed on one application server
and EJB modules on another, for example. We map the itsobankEJB,
itsobankEntityEJB, and itsobankWeb modules to the server1 application
server.
Figure 4-23 Step 9: Map modules to application servers
16.In the Step 10 form, we are not using security in this exercise, so unprotected
EJB methods can remain unchecked.
Figure 4-24 Step 10: Ensure all unprotected 2.0 methods have the correct level of
protection
17.In the Step 11 form, click Finish to install the ITSOBank application, as shown
in Figure 4-25.
Figure 4-25 Step 11: Summary
18.In the Installing itsobank page, wait until you get the Application itsobank
installed successfully message, as shown in Figure 4-26 on page 90.
Figure 4-26 Installing ITSOBank
19.Once the application has installed successfully, click Save to Master
Configuration to save the configuration changes to the master repository.
20.Now that the ITSOBank application is installed, we need to start it. To start the
ITSOBank application:
a. In the navigation tree, select Applications -> Enterprise Applications.
b. In the Applications form, check itsobank, then click Start, as shown in
Figure 4-27.
Figure 4-27 Starting ITSOBank
After a short delay, the status of itsobank should change to started.
21.Update the Web server plug-in configuration file by selecting Environment ->
Update Web Server Plugin in the navigation tree, then clicking OK in the
Update Web server plug-in configuration page, as shown in Figure 4-28.
Figure 4-28 Update Web server plug-in configuration
22.Click Logout in the console taskbar to close your Administrative Console
session.
The ITSOBank is now installed and started. Lets try it out next.
4.3.3 Testing the application
To try out the ITSOBank application from your browser:
1. Open the URL http://localhost/itsobank to access the ITSOBank Welcome
page, as shown in Figure 4-29 on page 92.
Note: If the application fails to start, look for errors in the application server
log file, /opt/WebSphere/AppServer/logs/server1/SystemOut.log in our
case.
Figure 4-29 ITSOBank Welcome page
2. To transfer between a branch account and a customer account, click
Customer Transfer.
3. In the Customer Transfer page, accept the defaults and click Transfer, as
shown in Figure 4-30, to transfer $100 to johnd.
Figure 4-30 ITSOBank Customer Transfer page
4. The Branch Transfer confirmation window should show that the
customer-to-branch transfer was completed, as shown in Figure 4-31 on
page 93. Click the Back to the start page link to try another transaction.
Figure 4-31 ITSOBank Branch Transfer confirmation page
5. To transfer between two Branch accounts, click the Internal Bank Transfer
link.
6. In the Branch Transfer page, accept the defaults and click Transfer, as
shown in Figure 4-32, to transfer $100 to london.
Figure 4-32 ITSOBank Branch Transfer page
7. The Branch Transfer confirmation page should show that the
branch-to-branch transfer was initiated, as shown in Figure 4-33 on page 94.
Figure 4-33 ITSOBank Branch Transfer confirmation page
You can use the ITSOBank application client to check the account balances.
1. Launch the ITSOBank application client from the command prompt as
follows:
If your system locale is set to English (United States), you can use the
default launchClient.sh script:
cd /home/admin/itsobank
/opt/WebSphere/AppServer/bin/launchClient.sh itsobank.ear
If not, then JVM system properties can be used to set the application client
containers locale to English (United States). To set the application client
container locale:
i. Make a copy of the default WebSphere launchClient script:
cp /opt/WebSphere/AppServer/bin/launchClient.sh
ii. Edit the copy of the launchClient script, as shown in Example 4-2:
vi launchClient.sh
iii. Save your changes.
iv. Launch the ITSOBank application client using the modified
launchClient script:
./launchClient.sh itsobank.ear
Example 4-2 Modified launchClient script
#!/bin/sh
#!echo "Usage: launchClient [<ear-file> | -help | -?]"
# binDir=`dirname $0`
binDir=/opt/WebSphere/AppServer/bin
. $binDir/setupCmdLine.sh
NAMING_FACTORY=com.ibm.websphere.naming.WsnInitialContextFactory
ORB_RAS_MGR=-Dcom.ibm.CORBA.RasManager=com.ibm.websphere.ras.WsOrbRasManager
"$JAVA_HOME/bin/java" \
-Xbootclasspath/p:"$WAS_BOOTCLASSPATH" \
"$CLIENTSAS" \
"$CLIENTSOAP" \
$ORB_RAS_MGR \
$USER_INSTALL_PROP \
-Dwas.install.root="$WAS_HOME" \
-Dws.ext.dirs="$WAS_EXT_DIRS" \
-Djava.security.auth.login.config="$WAS_HOME/properties/wsjaas_client.conf" \
-Dcom.ibm.CORBA.BootstrapHost=$DEFAULTSERVERNAME \
-Dcom.ibm.CORBA.BootstrapPort=$SERVERPORTNUMBER \
-Djava.naming.factory.initial=$NAMING_FACTORY \
-Duser.language=en \
-Duser.region=US \
-classpath "$WAS_CLASSPATH" com.ibm.ws.bootstrap.WSLauncher \
com.ibm.websphere.client.applicationclient.launchClient "$@"
Figure 4-34 Account Viewer Welcome
2. In the Account Viewer window, shown in Figure 4-35 on page 96, click Get
Customer Balance to get the Customer Account Balance for johnd. Click Get
Branch Balance to get the Branch Account Balance for raleigh.
Figure 4-35 Account Viewer - raleigh
You should see that johnd has received the $100 we just transferred from the
raleigh branch. Lets check that the london branch received the $100 we
transferred to it.
3. In the Account Viewer window, shown in Figure 4-36, change the Branch ID to
london and click Get Branch Balance.
Figure 4-36 Account Viewer - london
You should see that london has received the $100 we transferred from the
raleigh branch.
4. Click Close to close the ITSOBank application client.
4.3.4 Separating static and dynamic Web content
Separating your static Web content (HTML, GIF, CSS, etc files) and dynamic
Web content (servlets and JSPs) allows processing capacity to be split between
the Web server and application server. You can then allocate capacity between
the two based on the amount of dynamic and static content in your site. If your
site serves mostly static content, it is more cost effective to add more Web
servers than it is to add more application servers.
To separate the ITSOBank sample application static and dynamic Web content:
1. Disable the WebSphere file serving feature in the itsobank.ear file:
a. Log in as root and start a terminal session on the application server.
b. Start the Application Assembly Tool (AAT):
/opt/WebSphere/AppServer/bin/assembly.sh
c. Select File -> Open... from the AAT main menu and open the
/home/admin/itsobank/itsobank.ear file.
d. Select itsobank -> Web Modules -> itsobankWeb in the navigation tree
on the left. Click the IBM Extensions tab on the right, then un-check the
File serving enabled option, as shown in Figure 4-37.
Click Apply.
Figure 4-37 Disabling file serving using AAT
e. Save your changes and exit AAT.
2. Uninstall the ITSOBank application so we can install the updated EAR file:
a. Open the WebSphere Administrative Console in your browser, using the
following URL:
b. Select Applications -> Enterprise Applications in the navigation tree on
the left.
c. In the Enterprise Applications list on the right, check itsobank and click
Stop.
d. Check itsobank and click Uninstall.
e. Save your changes.
3. Install the updated itsobank.ear file using the same steps we used in 4.3.2,
Deploying the application on page 83.
4. Copy the plug-in configuration file to the remote Web server machine, for
example:
cd /opt/WebSphere/AppServer/config/cells
scp plugin-cfg.xml \
websrv1l:/opt/WebSphere/AppServer/config/cells/plugin-cfg.xml
Example 4-3 shows the plugin-cfg.xml entry when the WebSphere file serving
feature is enabled. WebSphere will serve all URIs starting with /itsobank/....
Example 4-3 UriGroup in plugin-cfg.xml - fileServingEnabled="true"
<UriGroup Name="default_host_server1_appsrv1l_Cluster_URIs">
...
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/*"/>
</UriGroup>
Now that we have disabled the file serving feature of WebSphere, only JSP and
servlet URIs are served by the application server. Regenerating the plug-in
configuration updates the plugin-cfg.xml entry as shown in Example 4-4.
WebSphere has intelligently updated the plug-in file to let the Web server serve
static content. The Web server passes dynamic URIs for servlets and JSPs back
to WebSphere.
Example 4-4 UriGroup in plugin-cfg.xml - fileServingEnabled="false"
<UriGroup Name="default_host_server1_appsrv1l_Cluster_URIs">
...
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/servlets/Transfer"/>
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/servlets/JMSTransfer"/>
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/*.jsp"/>
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/*.jsv"/>
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/*.jsw"/>
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/j_security_check"/>
<Uri AffinityCookie="JSESSIONID" Name="/itsobank/servlet/*"/>
</UriGroup>
Next we need to set up the Web server to serve the ITSOBank static contents.
1. First, extract the static content from the ITSOBank application archive and
copy it to the Web server:
a. Log in as root and start a terminal session on the application server.
b. Use the itsobankweb.sh shell script (see Example 4-5) to extract the static
content from the itsobankWeb.war file, in itsobank.ear, and save it to
itsobankStaticWeb.zip:
./itsobankweb.sh
c. Copy the itsobankStaticWeb.zip file to the Web server, for example:
scp itsobankStaticWeb.zip websrv1l:/tmp
d. Log in as root and start a terminal session on the Web server.
e. Extract the itsobankStaticWeb.zip file to the required Web server folder, for
example:
mkdir /var/www.itsobank
cd /var/www.itsobank
unzip /tmp/itsobankStaticWeb.zip
If you dont have the unzip utility, you can use the jar utility instead:
/opt/WebSphere/AppServer/java/bin/jar xf /tmp/itsobankStaticWeb.zip
Example 4-5 itsobankweb.sh listing
#!/bin/sh
WAS_HOME=/opt/WebSphere/AppServer
EAR_FILE=./itsobank.ear
WAR_FILE=itsobankWeb.war
STATIC_FILE=itsobankStaticWeb.zip
STATIC_CONTENT="error/authZerror.html \
error/error.html \
images/itsobank.gif \
Tip: To prevent errors and to make the process repeatable, it is best to use
some type of script to extract and deploy the static content to the Web
server. Alternatively, intelligent content management software can be used
to automatically route documents around the network when they are
updated.
index.html \
login/login.html \
login/loginerror.html \
style/default.css \
transfer/branchtransfer.html \
transfer/customertransfer.html"
START_DIR=$PWD
if [ ! -e $EAR_FILE ] ; then
echo "$EAR_FILE not found"
exit
fi
echo "Extracting $WAR_FILE from $EAR_FILE..."
$WAS_HOME/java/bin/jar xf $EAR_FILE $WAR_FILE
if [ ! -e $WAR_FILE ] ; then
echo "$WAR_FILE not found"
exit
fi
echo "Extracting static content from $WAR_FILE..."
mkdir /tmp/$WAR_FILE
cd /tmp/$WAR_FILE
$WAS_HOME/java/bin/jar xf $START_DIR/$WAR_FILE $STATIC_CONTENT
echo "Packaging static content in $STATIC_FILE..."
rm $START_DIR/$WAR_FILE
$WAS_HOME/java/bin/jar cfM $START_DIR/$STATIC_FILE *
cd $START_DIR
rm -rf /tmp/$WAR_FILE
2. Next, add an alias for the ITSOBank static content folder to the IBM HTTP
Server configuration:
a. Stop the IBM HTTP Server, for example:
cd /opt/IBMHttpServer/bin
./apachectl stop
b. Open the httpd.conf file in an editor, for example:
cd /opt/IBMHttpServer/conf
vi httpd.conf
c. Add the itsobank alias to the end of the httpd.conf file, for example:
Alias /itsobank/ "/var/www.itsobank/"
d. Save your changes.
e. Restart the IBM HTTP Server, for example:
./apachectl start
3. Try out the ITSOBank application from your browser.
If you open the URL http://localhost/itsobank, the Web server should serve
the ITSOBank Welcome page.
Clicking Transfer on the Customer Transfer page, shown in Figure 4-30 on
page 92, should invoke the Transfer servlet on WebSphere.
If you stop the application server, as follows:
/opt/WebSphere/AppServer/bin/stopServer.sh server1
You should still get the welcome and transfer pages from the Web server, but
the Transfer button will no longer work, because the Transfer servlet cant be
accessed.
For further information, see the WebSphere Developer Domain article Handling
Static Content in WebSphere Application Server available at:
http://www7b.software.ibm.com/wsdd/techjournal/0211_brown/brown.html
Appendix A. Installing IBM HTTP Server
This appendix provides detailed instructions for installing, configuring, and
verifying IBM HTTP Server for Linux.
The appendix includes the following tasks:
Pre-installation tasks
Install IBM HTTP Server
Configure IBM HTTP Server
Verify IBM HTTP Server
A
Prior to installing the IBM HTTP Server, check that the ports listed in Table A-1
are not in use. We suggest using the following command for this task:
netstat -l
Table A-1 IBM HTTP Server ports
Install IBM HTTP Server
The WebSphere Application Server installation wizard will install IBM HTTP
Server along with WebSphere Application Server during the default installation.
In this section, we describe how to install IBM HTTP Server as a stand-alone
install. This procedure is needed to install the remote Web Server.
To install IBM HTTP Server, follow these steps:
2. Mount the IBM WebSphere Application Server V5.0 CD-ROM:
mount /mnt/cdrom
3. Start the IBM HTTP Server installation program, for example:
cd /mnt/cdrom/ihs
./installIHS.sh
4. In the language selection window, select English and click OK.
5. Click Next in the Welcome to the InstallShield Wizard for IBM HTTP Server
window, shown in Figure A-1 on page 105.
Port Comment
http (80) Standard port for Web servers to accept HTTP client requests
https (443) Standard port for Web servers to accept secure HTTP (HTTPS)
client requests
8008 Administration port for IBM HTTP Server
Note: During the installation of Red Hat Linux Advanced Server V2.1, it is
likely that the Apache HTTP Server was installed. While it is not necessary to
uninstall the Apache HTTP Server to use the IBM HTTP Server, it may be
easier to manage one installed HTTP server instead of two.
Appendix A. Installing IBM HTTP Server 105
Figure A-1 IBM HTTP Server installation welcome window
6. In the software license agreement window, select I accept the terms of the
license agreement and click Next to agree to the terms of the agreement.
7. In the next window, click Next to use the default installation directory, as
shown in Figure A-2 on page 106.
Figure A-2 Setting the IBM HTTP Server installation directory
8. In the next window, select the Typical setup type, and click Next.
9. In the next window, verify your installation settings, and click Next to start the
installation.
The install wizard installs the selected components, displaying a message
window when finished. Click Finish to exit the install wizard.
Configure IBM HTTP Server
After the installation of IBM HTTP Server, there are a few tasks that need to be
performed to complete the Web server setup. Some of these tasks are optional
and some should be done in a normal setting.
One choice that will need to be made is whether you will run the HTTP
administration server. This is a second instance of the IBM HTTP Server that
runs by default on port 8008 and allows you to configure most aspects of the
regular IBM HTTP Server running on port 80. Some companies do not wish to
run this administration server for security reasons, since it would leave another
port open to potential attack.
This section describes the following configuration tasks:
Configuring the ServerName
Configuring the HTTP server for SSL
Creating an HTTP server runtime user account
Configuring the HTTP administration server
For details on controlling IBM HTTP Server startup at system boot time, see
Setting up the IBM HTTP Server as service on page 138.
Configuring the ServerName
To set the ServerName setting to the fully qualified host name, complete the
following steps:
1. Stop the IBM HTTP Server, for example:
./apachectl stop
2. Open the httpd.conf file in an editor, for example:
vi httpd.conf
3. Modify the httpd.conf file to update the value of the ServerName keyword as
the fully qualified host name, for example:
ServerName websrv1l.itso.ral.ibm.com
4. Save your changes.
5. Restart the IBM HTTP Server, for example:
./apachectl start
Configuring the HTTP server for SSL
This section is optional. We provide detailed instructions for creating a certificate,
installing the certificate and configuring an IBM HTTP Server for SSL. In our
example, we will create a self-signed test certificate. For a production
environment you will need to request a real certificate from a certificate authority,
such as VeriSign.
1. Stop the IBM HTTP Server, for example:
./apachectl stop
2. Configure SSL for the IBM HTTP Server as follows:
a. Open the <IHS_HOME>/conf/httpd.conf file in for editing, for example:
vi httpd.conf
b. Ensure that the following line is uncommented by removing the # symbol:
Listen 80
c. Add the following lines to the end of the file:
LoadModule ibm_ssl_module libexec/mod_ibm_ssl_<encrypt_level>.so
(Where <encrypt_level> is the appropriate encryption level for your
locale. For example, mod_ibm_ssl_128.so for 128-bit encryption in the US
and Canada.)
Listen 443
<VirtualHost <http_server_hostname>:443>
(You must substitute your fully qualified host name in this line, for example
<VirtualHost websrv1l.itso.ibm.com:443>.)
SSLEnable
</VirtualHost>
SSLDisable
Keyfile "<IHS_HOME>/ssl/keyfile.kdb"
SSLV2Timeout 100
SSLV3Timeout 1000
The value of the KeyFile parameter is the absolute path to the CMS format
keystore database file of your choosing. In this example, we assume that a
keyfile.kdb file is created in the ssl subdirectory of the IBM HTTP Server
installation.
d. Save the changes.
3. Create a new SSL keystore database file, as follows:
a. Start the Web server IBM Key Management Utility, for example:
./ikeyman
b. Select Key Database File from the menu bar, then select New.
c. In the New window, enter the following and then click OK:
Key Database Type: CMS key database file
File Name: keyfile.kdb (must be the same as in httpd.conf)
Location: <IHS_HOME>/ssl/
d. In the Password Prompt window do the following, then click OK to
continue:
Enter your password to protect keystore file contents.
Check Set expiration time? and enter number of days if the password
should expire. If no expiration is required, uncheck this setting.
Check Stash the password to a file?
e. Click OK when the Information window appears with the message:
The password has been encrypted and saved in the file:
<IHS_HOME>/ssl/keyfile.sth
4. Create a new self-signed certificate, using the following steps:
a. Start the Web server IBM Key Management Utility, for example:
./ikeyman
b. Select Key Database File from the main menu, then select Open. Specify
the keystore database file. Our example uses
<IHS_HOME>/ssl/keyfile.kdb.
c. Select Create from the menu bar, then select New Self-Signed
Certificate.
Note: Although not required in a development environment, it is
strongly recommended that all keystores used in a production
environment set an expiration period.
Note: The IBM HTTP Server accesses the password-protected
keystore file <filename>.kdb using the password contained in the
<filename>.sth stashfile. Consequently, the stash option must be
enabled.
Tip: You could see a Java core dump after executing an ikeyman command
function. It is the result of a conflict in library routines caused by the default
loading sequence. To work around this problem, set the LD_PRELOAD
environment variable before running the command:
LD_PRELOAD=/usr/lib/libstdc++-libc6.1-2.so.3
This loads the library first when the application is started.
d. In the Create New Self-Signed Certificate window enter the following
values, then click OK.
Key Label: <user defined label>
Version: X509 V3
Key Size: 1024
Common Name: <http_server_hostname>
Organization: IBM
Organization Unit: ITSO
The new certificate should be listed in the Personal Certificates pane.
e. Close the Web server IBM Key Management Utility.
5. Restart the IBM HTTP Server, for example:
./apachectl start
Creating an HTTP server runtime user account
This section is optional. By default the configuration file (httpd.conf) is set up to
run the HTTP server as user nobody and group nobody. If you prefer, you can
create a separate HTTP server runtime account instead.
To create a separate HTTP server runtime account:
1. First create the desired user and group on the Linux system using a
command such as the following:
useradd www
This will also create a group called www automatically.
2. Edit the httpd.conf file and update the User and Group settings. Change the
following two lines:
User nobody
Group nobody
To:
User www
Group www
Note: If you are enabling SSL for a production environment, select New
Certificate Request instead. It is strongly recommended that self-signed
digital certificates not be used in production.
Configuring the HTTP administration server
If you should decide to run the HTTP administration server, follow the instructions
in this section. Otherwise, this section can be skipped.
This section includes the following tasks:
Creating an HTTP server administration account
Creating an HTTP administration server runtime user account
Accessing the HTTP administration server
Creating an HTTP server administration account
The administration account is used to access the HTTP administration server
configuration GUI. To create the account, perform the following steps:
2. Create the HTTP administration account using the htpasswd command, for
example:
./htpasswd -m ../conf/admin.passwd httpadm
If the admin.passwd file does not exist, use the -c option to create the file, for
example:
./htpasswd -mc ../conf/admin.passwd httpadm
Where httpadm is the administration user account. The htpasswd command
will prompt you for a new password, and then to retype the new password.
Creating an HTTP administration server runtime user account
Although the HTTP administration server process is started under the root
account, it can be configured to then switch to run under another account. A
UNIX account can be created specifically for this purpose.
Perform the following steps to create the UNIX account and configure the HTTP
administration server:
2. Run the setupadm script:
./setupadm
Answer the prompts as follows:
Supply a user ID to run the Administration server, for example:
User ID: httprun
Supply a Group Name to run the Administration server, for example:
Group Name: httpgrp
Supply the directory containing the files for which a change in the
permissions is necessary. The default is /opt/IBMHttpServer/conf.
Press Enter to accept the default.
To perform the change, enter 1. To quit with no changes, enter 2 (default).
Type 1 and press Enter to perform changes.
The configuration file /opt/IBMHttpServer/conf/admin.conf will be saved.
Do you wish to update the Administration Server Configuration file? To
perform the change, enter 1. To exit with no change, enter 2 (default).
Type 1 and press Enter to update configuration file.
3. The setupadm program returns to the command prompt.
Accessing the HTTP administration server
You can use the following steps to access the HTTP administration server for
configuring IBM HTTP Server:
2. Start the HTTP administration server, for example:
./adminctl start
The response from this command should look like:
./adminctl start: admin http started
3. Start your Web browser and open the following URL:
http://localhost
4. In the Welcome to IBM HTTP Server page, shown in Figure A-4 on page 115,
click Configure server.
5. Enter your HTTP server administration account user name (httpadm in our
case) and password when prompted, and click OK.
The IBM Administration Server page will be displayed, as shown in Figure A-3
on page 113.
Figure A-3 IBM Administration Server
Verify IBM HTTP Server
In order to verify the IBM HTTP Server installation, perform the following checks
on the Web server machine:
Check process status
Check request handling
Check process status
Check the HTTP server process status using the following steps:
1. Check that the HTTP server processes are running by issuing the following
command:
ps -ef | grep httpd
The output should list a number of httpd processes. The output should look
similar to the output in Example A-1.
Example: A-1 Web server sample process listing
root 9788 1 2 17:54 ? 00:00:01 /opt/IBMHttpServer/bin/httpd -d
www 9790 9788 0 17:54 ? 00:00:00 /opt/IBMHttpServer/bin/httpd -d
2. Check that the IBM HTTP Server is registered to listen on port 80 and is
therefore ready to handle requests:
netstat -ln | grep :80
3. If you configured the Web server for SSL, check that the IBM HTTP Server is
registered to listen on port 443 and is therefore ready to handle requests:
netstat -ln | grep :443
Check request handling
To check HTTP server request handling, use a Web browser to request the
following URL, representing the Web server home page:
http://<http_server_hostname>/
You should see the IBM HTTP Server welcome page displayed, as shown in
Figure A-4 on page 115.
Figure A-4 Welcome to IBM HTTP Server page
If your Web server is configured for SSL, repeat the previous step using the
following URL:
https://<http_server_hostname>/
Appendix B. Installing IBM DB2
This appendix provides detailed instructions for installing, configuring, and
verifying IBM DB2 UDB Enterprise Server Edition for Linux for use with
WebSphere Application Server V5.0. The topics covered are:
Installing the IBM DB2 Server.
Installing the IBM DB2 Client for accessing a remote DB2 Server.
WebSphere Application Server V5.0 itself does not required access to a
database server for its administrative repository. DB2 is now only required for
applications that required the DB2 database.
B
Installing IBM DB2 Server
The section is organized into the following tasks:
Install the DB2 Server
Verify DB2 Server installation
Configure the DB2 Server
Table B-1 lists the variable names and values used during the DB2 installation.
Table B-1 DB2 installation settings
Prior to installing IBM DB2 UDB Enterprise Server Edition, the following checks
need to be completed:
Verify that there are no existing active services that use the same DB2
TCP/IP ports on the server:
523 (DB2 Server)
50000 (default DB2 instance connection port)
50001 (default DB2 instance interrupt port)
50002 (DB2 Control Server)
We suggest using the following command for this task:
netstat -l
Install the DB2 Server
The DB2 product documentation should be consulted for the official list of
prerequisite software. We installed IBM DB2 UDB Enterprise Server Edition on a
standard installation of Red Hat Linux Advanced Server V2.1.
In order to install IBM DB2 UDB Enterprise Server Edition for Linux, perform the
following steps:
2. Mount the DB2 CD-ROM:
mount /mnt/cdrom
Variable Default value Description
<db2_instance_owner> db2inst1 DB2 instance owner user name
<db2_instance_path> /home/db2inst1 DB2 instance path
Appendix B. Installing IBM DB2 119
3. Start the DB2 setup program:
cd /mnt/cdrom
./db2setup
4. In the IBM DB2 Setup Launchpad window, click the Install Products option,
as shown in Figure B-1.
Figure B-1 IBM DB2 Setup Launchpad
5. In the next window, select the DB2 UDB Enterprise Server Edition option
and click Next, as shown in Figure B-2 on page 120.
Figure B-2 Selecting the product to install
6. In the Welcome to the DB2 Setup wizard window, click Next to continue.
7. In the Software License Agreement window, select Accept and click Next to
agree to the terms of the agreement.
8. In the Select the installation type window, select Custom. You can use the
typical install, but we want you to see each of the options available. Click
Next to continue, as shown in Figure B-3 on page 121.
Figure B-3 Selecting the installation type
9. In the Select the installation action window, select Install DB2 UDB
Enterprise Server Edition on this computer and click Next to continue.
10.In the Select the features to install window, leave the default settings as
shown in Figure B-4 on page 122. If you have changed any of these options,
click Select default. Click Next to continue.
Figure B-4 Selecting the features to install
11.In the Languages window, select any addition languages you want to install
and click Next.
12.In the Set user information for the DB2 Administration Server window, as
shown in Figure B-5 on page 123, select the New user option and enter the
following:
User Name: dasusr1
UID: use default UID
Group name: dasadm1
GID: use default GID
Home directory: /home/dasusr1
Password: user_password
Confirm Password: user_password
Then click Next.
Figure B-5 Setting the user information for the DB2 Administration Server
13.In the Set up a DB2 instance window, select the Create a DB2 instance
option, and click Next.
14.In the Select how the instance will be used window, select Single-partition
instance, and click Next.
15.In the Set user information for the DB2 instance owner window, select the
New user option and enter the following:
User Name: db2_instance_owner
Group name: db2grp1
Home directory: db2_instance_path
Then click Next.
User Name: db2fenc1
Group name: db2fgrp1
Home directory: /home/db2fenc1
Then click Next.
17.In the Configure B2 instance TCP/IP communication window, as shown in
Figure B-6, select Configure, keep the default values, and click Next.
Figure B-6 Configuring DB2 instance TCP/IP communication
18.In the Set instance properties window, confirm that the Authentication type is
set to Server and that the Startup option Autostart the instance at system
startup is also selected, as shown in Figure B-7 on page 125.
Click Next to continue.
Figure B-7 Setting instance properties
19.In next window select Do not prepare the DB2 tools catalog on this
computer, and click Next.
20.In the Set up the administration contact list window, as shown in Figure B-8
on page 126, select Local - Create a contact list on this system, and
ensure that Enable notification is deselected. Click Next.
Figure B-8 Setting up the administration contact list
21.If a warning window appears advising that the Notification SMTP server has
not been specified, click OK.
22.In the Specify a contact for health monitor notification, select Defer this task
until after installation is complete, and click Next.
23.The Start copying files window is displayed, listing the product components to
be installed. Click Finish to start copying files.
The DB2 setup program installs the selected components. Depending on the
speed of your processor, this can take several minutes. When the installation
completes, the Setup is complete window is displayed.
24.In the Setup is complete window, select the Status report tab to check that all
components were installed successfully. Click Finish.
The DB2 installation is now complete.
25.Unmount the CD-ROM:
cd /
umount /mnt/cdrom
Congratulations, you have installed IBM DB2 UDB Enterprise Server Edition for
Linux.
Verify DB2 Server installation
To verify the DB2 Server installation, check that DB2 has the correct internal
release level to meet WebSphere Application Server requirements:
1. Change to user <db2_instance_owner>:
su - <db2_instance_owner>
2. Enter the following command:
db2level
This should generate output similar to the following:
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08010" with level identifier "01010106".
Informational tokens are "DB2 v8.1.0.0", "s021023", "", and FixPak "0".
Product is installed at "/opt/IBM/db2/V8.1".
An internal release level of 8.1.0.0 should be indicated for DB2 V8.1.
Configure the DB2 Server
After the DB2 Server installation, a number of configuration tasks must be
performed so that WebSphere applications can access DB2 application
databases:
Update WebSphere user groups
Update WebSphere user environment
Configure DB2 Server connectivity
Verify DB2 Server connectivity
The user you use to run WebSphere Application Server should be a member of
the db2grp1 group so that WebSphere applications can access the DB2 libraries.
We use the root user to run WebSphere Application Server in our environment.
Perform the following steps to update the root accounts groups:
2. Issue the following command:
groups
3. If db2grp1 is not listed as one of the groups assigned to root, add the root
user to the db2grp1 group. You can use the redhat-config-users command
to start the Red Hat User Manager GUI tool, or edit the /etc/group file directly
if you prefer.
The user you use to run WebSphere Application Server should have access to
the DB2 environment settings.
To update the root accounts environment, edit /root/.bashrc and add the
following content at the end of the file:
# Setup DB2 environment for root user.
if [ -f /home/<db2_instance_owner>/sqllib/db2profile ]; then
. /home/<db2_instance_owner>/sqllib/db2profile
fi
Where <db2_instance_owner> is db2inst1 in our case.
Configure DB2 Server connectivity
To configure the DB2 Server, complete the following steps:
1. Start the database manager:
su - db2inst1
db2start
2. Create the application database(s) as follows:
db2 create db <db_name>
Where <db_name> is itsoban1 in our case with the ITSOBank sample
application.
3. Catalog the database server TCP/IP node as follows:
db2 catalog tcpip node <node_name> remote <db_server_hostname> server
<service/port#>
Where <node_name> and <db_server_hostname> are entsrv1l, and
<service/port#> is 50000 in our case.
4. Catalog the required database(s) as follows:
db2 catalog db <db_name> as <db_alias> at node <node_name>
Where <db_name> is itsoban1, <db_alias> is itsobank, and <node_name> is
entsrv1l in our case with the ITSOBank sample application.
Verify DB2 Server connectivity
To verify the DB2 Server connectivity, complete the following steps:
1. Verify the attach to the TCP/IP node as follows:
db2 attach to <node_name> user <db2_user> using <db2_password>
Where <node_name> is entsrv1l and <db2_user> is db2inst1 in our case with
the ITSOBank sample application.
2. Verify the connection to the database from the application server as follows:
db2 connect to <db_name> user <db2_user> using <db2_password>
Where <db_name> is itsobank and <db2_user> is db2inst1 for the ITSOBank
sample application.
Installing IBM DB2 Client
The steps for installing the DB2 Client software are very similar to the DB2
Server installation, but the steps are outlined here for clarity.
The section is organized into the following tasks:
Install the DB2 Client
Verify DB2 Client installation
Configure the DB2 Client
Install the DB2 Client
In order to install IBM DB2 UDB Enterprise Server Edition for Linux client,
perform the following steps:
1. Log in as root.
2. Start a terminal session.
3. Mount the DB2 CD-ROM:
mount /mnt/cdrom
4. Start the DB2 setup program:
cd /mnt/cdrom
./db2setup
5. In the IBM DB2 Setup Launchpad window, click the Install Products option.
6. In the next window, select the DB2 Administration Client option and click
Next, as shown in Figure B-9 on page 130.
Figure B-9 Selecting the product to install
7. In the Welcome to the DB2 Setup wizard window, click Next to continue.
8. In the Software License Agreement window, select Accept and click Next to
agree to the terms of the agreement.
9. In the Select the installation type window, select Custom and click Next to
continue.
10.In the Select the installation action window, select Install DB2
Administration Client on the computer and click Next to continue.
11.In the Select the features to install window, select the Client support option
and click Next, as shown in Figure B-10 on page 131.
Figure B-10 Selecting the features to install
12.In the Languages window, select any addition languages you want to install
and click Next.
13.In the Set up a DB2 instance window, select the Create a DB2 instance
option, and click Next.
User Name: <db2_instance_owner>
Group name: db2grp1
Home directory: /home/<db2_instance_owner
Then click Next.
15.The Start copying files window is displayed, listing the product components to
be installed. Click Finish to start copying files.
The DB2 setup program installs the selected components. Depending on the
speed of your processor, this can take several minutes. When the installation
completes, the Setup is complete window is displayed.
16.In the Setup is complete window, select the Status report tab to check that all
components were installed successfully. Click Finish.
The DB2 installation is now complete.
17.Unmount the CD-ROM:
cd /
umount /mnt/cdrom
Verify DB2 Client installation
To verify the DB2 Client installation, check that DB2 has the correct internal
release level to meet WebSphere Application Server requirements:
1. Change to user <db2_instance_owner>:
su - <db2_instance_owner>
2. Enter the following command:
db2level
This should generate output similar to the following:
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08010" with level identifier "01010106".
Informational tokens are "DB2 v8.1.0.0", "s021023", "", and FixPak "0".
Product is installed at "/opt/IBM/db2/V8.1".
An internal release level of 8.1.0.0 should be indicated for DB2 V8.1.
Configure the DB2 Client
After the DB2 Client installation, a number of configuration tasks must be
performed so that WebSphere applications can access remote DB2 application
databases:
Configure DB2 Client and Server connectivity
Verify DB2 Client and Server connectivity
The user you use to run WebSphere Application Server should be a member of
the db2grp1 group so that WebSphere applications can access the DB2 Client
libraries.
Perform the following steps to update root accounts groups:
2. Issue the following command:
groups
3. If db2grp1 is not listed as one of the groups assigned to root, add the root
user to the db2grp1 group. You can use the redhat-config-users command
to start the Red Hat User Manager GUI tool, or edit the /etc/group file directly
if you prefer.
The user you use to run WebSphere Application Server should have access to
the DB2 environment settings.
To update the root accounts environment, edit /root/.bashrc and add the
following content at the end of the file:
# Setup DB2 environment for root user.
if [ -f /home/<db2_instance_owner>/sqllib/db2profile ]; then
. /home/<db2_instance_owner>/sqllib/db2profile
fi
Where <db2_instance_owner> is db2inst1 in our case.
Configure DB2 Client and Server connectivity
To configure the DB2 Client, complete the following steps:
1. Catalog the database server TCP/IP node as follows:
su - db2inst1
db2 catalog tcpip node <node_name> remote <db_server_hostname> server
<service/port#>
Where <node_name> and <db_server_hostname> are entsrv1l, and
<service/port#> is 50000 in our case.
Where <db_name> is itsobank in our case with the ITSOBank sample
application.
2. Catalog the required database(s) as follows:
db2 catalog db <db_name> as <db_alias> at node <node_name>
Where <db_name> is itsoban1, <db_alias> is itsobank, and <node_name> is
entsrv1l in our case with the ITSOBank sample application.
Verify DB2 Client and Server connectivity
To verify the DB2 Client and Server connectivity, complete the following steps:
1. Verify the attach to the TCP/IP node as follows:
db2 attach to <node_name> user <db2_user> using <db2_password>
Where <node_name> is entsrv1l and <db2_user> is db2inst1 in our case with
the ITSOBank sample application.
2. Verify the connection to the database from the application server as follows:
db2 connect to <db_name> user <db2_user> using <db2_password>
Where <db_name> is itsobank and <db2_user> is db2inst1 for the ITSOBank
sample application.
Appendix C. Service scripts and runlevel
configuration
This appendix describes how to control WebSphere Application Server and IBM
HTTP Server using System V init under Red Hat Linux.
WebSphere Application Server and IBM HTTP Server start, stop, and runlevel
configuration can be easily controlled by the two Linux command-line tools:
chkconfig
service
The tasks covered in this appendix are:
Creating a shell script for controlling the server application and adding it to the
SysV init services.
Selecting and configuring the runlevels at which the new service should be
available.
Starting, stopping, restarting, and verifying the service at any time.
Instructions for finding the sample scripts are in Appendix D, Additional material
on page 141.
C
Setting up the WebSphere Application Server as service
This section describes how to set up WebSphere Application Server as a service
named websphered.
Creating the service
To create a service for controlling WebSphere Application Server:
1. Create a file named websphered and add the code listed in Example C-1.
Example: C-1 websphered service script
#!/bin/bash
#
# Startup script for IBM WebSphere Application Server
# (C) COPYRIGHT International Business Machines Corp. 2003.
# author: Patrick Michel
# description: IBM's J2EE application server
#
# chkconfig: - 87 17
# processname: java
# pidfile: /var/run/websphered.pid
# config: -
#
websphered=/opt/WebSphere/AppServer/bin/startServer.sh
args=server1
prog="WebSphere Application Server"
proc=/opt/WebSphere/AppServer/java/jre/bin/exe/java
RETVAL=0
# verify installation
if [ ! -x $websphered ]; then
echo "$prog is not installed"
exit 0
fi
# source function library
. /etc/rc.d/init.d/functions
# setup db2 environment if required
. /home/db2inst1/sqllib/db2profile
case "$1" in
start)
echo -n "Starting websphered: "
/opt/WebSphere/AppServer/bin/startServer.sh $args > /dev/null
Appendix C. Service scripts and runlevel configuration 137
RETVAL=$?
if [ $RETVAL = 0 ]; then
touch /var/lock/subsys/websphered
echo_success
else
echo_failure
fi
echo
;;
stop)
echo -n "Shutting down websphered: "
/opt/WebSphere/AppServer/bin/stopServer.sh $args > /dev/null
RETVAL=$?
rm -f /var/lock/subsys/websphered
echo_success
else
echo_failure
fi
echo
;;
restart)
$0 stop
$0 start
;;
status)
status $proc
;;
*)
echo "Usage: websphered {start|stop|restart|status}"
exit 1
esac
exit 0
2. Make the script executable:
chmod +x websphered
3. Move the script to the init.d directory:
mv websphered /etc/rc.d/init.d
4. Add the script to the services managed by chkconfig:
chkconfig --add websphered
5. List the current runlevel status of the new service:
chkconfig --list websphered
Configuring the service
To configure the new WebSphere service:
Make WebSphere automatically start at system boot using the default
runlevel with:
chkconfig websphered on
Reconfigure WebSphere to the desired runlevel with:
chkconfig --level 35 websphered on
Maintaining the service
Independent of the configured runlevels, the WebSphere service can at any time
be:
Started with:
service websphered start
Verified, restarted or stopped with:
service websphered [status|restart|stop]
Setting up the IBM HTTP Server as service
This section describes how to set up IBM HTTP Server as a service named
ibmhttpd.
Creating the service
To create a service for controlling IBM HTTP Server:
1. Create a file named ibmhttpd and add the code listed in Example C-2.
Example: C-2 ibmhttpd service script
#!/bin/bash
#
# Startup script for IBM HTTP Server
# (C) COPYRIGHT International Business Machines Corp. 2003.
# author: Patrick Michel
# description: IBM's Web server powered by Apache
#
# chkconfig: - 86 16
# processname: httpd
# pidfile: /var/run/ibmhttpd.pid
# config: /opt/IBMHTTPServer/conf/httpd.conf
Appendix C. Service scripts and runlevel configuration 139
#
ibmhttpd=/opt/IBMHTTPServer/bin/httpd
conf=/opt/IBMHTTPServer/conf/httpd.conf
prog="IBM HTTP Server"
RETVAL=0
# verify installation
if [ ! -x $ibmhttpd ]; then
echo "$prog is not installed"
exit 0
fi
# source function library
. /etc/rc.d/init.d/functions
case "$1" in
start)
echo -n "Starting ibmhttpd: "
daemon $ibmhttpd
RETVAL=$?
touch /var/lock/subsys/ibmhttpd
fi
echo
;;
stop)
echo -n "Shutting down ibmhttpd: "
killproc $ibmhttpd
RETVAL=$?
rm -f /var/lock/subsys/ibmhttpd
fi
echo
;;
restart)
$0 stop
$0 start
;;
status)
status $ibmhttpd
;;
*)
echo "Usage: ibmhttpd {start|stop|restart|status}"
exit 1
esac
exit 0
2. Make the script executable:
chmod +x ibmhttpd
3. Move the script to the init.d directory:
mv ibmhttpd /etc/rc.d/init.d
4. Add the script to the services managed by chkconfig:
chkconfig --add ibmhttpd
5. List the current runlevel status of the new service:
chkconfig --list ibmhttpd
Configuring the service
To configure the new IBM HTTP Server service:
Make IBM HTTP Server automatically start at system boot using the default
runlevel with:
chkconfig ibmhttpd on
Reconfigure IBM HTTP Server to the desired runlevel with:
chkconfig --level 35 ibmhttpd on
Maintaining the service
Independent of the configured runlevels, the IBM HTTP Server service can at
any time be:
Started with:
service ibmhttpd start
Verified, restarted or stopped with:
service ibmhttpd [status|restart|stop]
Appendix D. Additional material
This Redpaper refers to additional material that can be downloaded from the
Internet as described below.
Locating the Web material
The Web material associated with this Redpaper is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/REDP3601
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the redpaper form number, REDP3601.
Using the Web material
The additional Web material that accompanies this Redpaper includes the
following files:
File name Description
redp3601.zip Zipped Code Samples
D
Hello.ear Sample application for Section 3.5
init-scripts Sample SysV init scripts
itsobank Sample application for Chapter 4
System requirements for downloading the Web material
The following system configuration is recommended:
Hard disk space: 1 MB
Operating System: Red Hat Linux Advanced Server V2.1
Processor: 500 MHz Intel x86
Memory: 256 MB
How to use the Web material
Create a subdirectory (folder) on your workstation, and unzip the contents of the
Web material zip file into this folder.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
Redpaper
IBM WebSphere V5.0 for
Linux, Implementation and
Deployment Guide
WebSphere Handbook Series
Implement your
WebSphere 5 for
Linux runtime
environment
Explore both
single-tier and
multi-tier
configurations
Deploy applications
to WebSphere 5 for
Linux
This Redpaper provides system administrators, developers,
and architects with the knowledge needed to implement the
IBM WebSphere Application Server V5.0 for Linux runtime
environment and to deploy Web applications to that
environment.
Chapter 1 of the Redpaper introduces IBM WebSphere
Application Server V5.0 for Linux architecture and editions. It
also provides an overview of the J2EE programming model.
Chapter 2 steps you through the WebSphere Application
Server V5.0 for Linux installation process in a single-tier
runtime environment.
Chapter 3 provides instructions for implementing WebSphere
Application Server in a multi-tier runtime environment. It also
explains how to implement a cluster using WebSphere
Network Deployment edition.
Chapter 4 introduces J2EE application packaging and guides
you through deployment of a sample J2EE application. It also
discusses a range of deployment considerations.
Back cover

Redp 3601

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Redp 3601

Diunggah oleh

Hak Cipta:

Format Tersedia

ibm.

Anda mungkin juga menyukai