WebSphere Application Server - Express V5.0.2 Administrator Handbook

groupertomatoInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 5 χρόνια και 23 μέρες)

926 εμφανίσεις


ibm.com/redbooks
WebSphere Application cation
Server - Express V5.0.2press V5.0.2
Administrator Handbook
Carla Sadtler
Configure the server environment
Deploy applications
Problem determination
tips
Front cover
WebSphere Application Server - Express V5.0.2
Administrator Handbook
September 2003
International Technical Support Organization
SG24-6976-01
© 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.
Second Edition (September 2003)
This edition applies to Version 5.0.2 of IBM WebSphere Application Server - Express.
Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.
© Copyright IBM Corp. 2003. All rights reserved.
iii
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Chapter 1. Planning and installation approach . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Installation planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Supported platforms and requirements. . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Installation directory references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Planning for Studio Site Developer. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Planning for Express Application Server. . . . . . . . . . . . . . . . . . . . . . . 5
1.1.6 Planning for team development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.7 Planning for security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.8 Planning for a database server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.9 Planning for Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Planning for backup and recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Express configuration backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Application recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Database backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Installation approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Installation scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2 Installation scenario 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.3 Installation scenario 3: Production environment. . . . . . . . . . . . . . . . 16
1.4 Using an external Web server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Finding information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 2. Express Application Server architecture . . . . . . . . . . . . . . . . . 21
2.1 An inside view of the application server . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1 Cells, nodes, and application servers. . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 Application server components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 3. Administration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Administration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Using the administrative console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iv
WebSphere Application Server - Express V5.0.2 Administrator Handbook
3.2.1 Accessing the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Administrative console layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3 Setting console preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.4 Finding an item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.5 Updating existing items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.6 Viewing application server runtime information. . . . . . . . . . . . . . . . . 48
3.2.7 Adding new items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.8 Removing items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.9 Starting and stopping items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.10 Saving work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.11 Getting help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.12 Using variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.13 Recovering from an interrupted session. . . . . . . . . . . . . . . . . . . . . 58
Chapter 4. Managing servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1 Starting and stopping application servers. . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.1 Starting an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.2 Stopping an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.3 Problem determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2 Modifying the server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1 Updating application server end points. . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2 Updating or changing HTTP transport values. . . . . . . . . . . . . . . . . . 65
4.3 Creating an application server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.1 Add the new HTTP transports to the virtual hosts. . . . . . . . . . . . . . . 70
4.3.2 Install the administrative console application . . . . . . . . . . . . . . . . . . 72
4.3.3 Open the administrative console. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4 Session management configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5 Creating a virtual host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chapter 5. Accessing databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.1 Administration task overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 Installing database drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Update the database driver variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4 Database security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.1 Creating a J2C authentication entry . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5 Define database (JDBC) providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.6 Define databases (data sources) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7 Tuning for performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.7.1 Connection pooling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.7.2 Prepared statement cache size. . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.8 Example: using IBM DB2 on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8.1 Install DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.8.2 Working with DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Contents
v
5.8.3 Create a database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.8.4 Authorize a user to the database . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.8.5 Create a schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.8.6 Create the database tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.8.7 Populate the tables with data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.8.8 Grant privileges on the table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.8.9 Define the remote database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.8.10 Open the Express Application Server console . . . . . . . . . . . . . . . 126
5.8.11 Update the WebSphere variable for the database driver . . . . . . . 126
5.8.12 Create the J2C authentication entries. . . . . . . . . . . . . . . . . . . . . . 128
5.8.13 Define the JDBC provider and data sources. . . . . . . . . . . . . . . . . 129
Chapter 6. Managing applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.1 Application packaging (.ear files) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.1.1 Enterprise application files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.1.2 Web module files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.1.3 Install location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.2 Gathering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.3 Installation strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.4 Installing applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.4.1 What to do if the installation fails. . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.5 Managing applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.5.1 Starting or stopping an application . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.5.2 Removing an application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.5.3 Upgrading an enterprise application. . . . . . . . . . . . . . . . . . . . . . . . 157
6.5.4 Updating a resource reference binding. . . . . . . . . . . . . . . . . . . . . . 161
6.5.5 Updating role mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.5.6 Exporting an enterprise application. . . . . . . . . . . . . . . . . . . . . . . . . 161
6.6 Finding information about installed applications . . . . . . . . . . . . . . . . . . . 162
6.6.1 Finding the URL for an application . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.6.2 Finding server information for an application . . . . . . . . . . . . . . . . . 164
6.6.3 Finding the virtual host for a Web module. . . . . . . . . . . . . . . . . . . . 166
6.6.4 Finding the context root of an application. . . . . . . . . . . . . . . . . . . . 168
6.6.5 Finding the entry page of an application. . . . . . . . . . . . . . . . . . . . . 169
6.6.6 Viewing application deployment descriptors. . . . . . . . . . . . . . . . . . 170
6.6.7 Viewing Web modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.7 Defining shared libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Chapter 7. Managing JavaMail resources. . . . . . . . . . . . . . . . . . . . . . . . . 175
7.1 Configuring JavaMail resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.1.1 Configuring the mail provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.1.2 Configuring JavaMail sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.1.3 More information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
vi
WebSphere Application Server - Express V5.0.2 Administrator Handbook
Chapter 8. Using a Web server plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.1 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
8.2 Test the installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.3 Generate the plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 9. Implementing security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.1 Express security overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
9.2 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9.2.1 Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9.2.2 Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.2.3 User registries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.2.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.3 Security implementation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.3.1 Scenario 1: Local OS, SWAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.3.2 Scenario 2: Local OS, SWAM, and SSL. . . . . . . . . . . . . . . . . . . . . 196
9.3.3 Scenario 3: LDAP, LTPA, and SSL. . . . . . . . . . . . . . . . . . . . . . . . . 197
9.4 Defining the server and administrative users . . . . . . . . . . . . . . . . . . . . . 198
9.4.1 Defining the server ID to the user registry. . . . . . . . . . . . . . . . . . . . 199
9.4.2 Defining administration user IDs to the user registry . . . . . . . . . . . 201
9.5 Configuring the user registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
9.5.1 Using the local operating system user registry. . . . . . . . . . . . . . . . 202
9.5.2 Using an LDAP user registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
9.6 Assigning users to administrative roles. . . . . . . . . . . . . . . . . . . . . . . . . . 205
9.6.1 Mapping a user to an administrator role . . . . . . . . . . . . . . . . . . . . . 205
9.6.2 Mapping a group or special subject to an administrator role. . . . . . 206
9.7 Configuring the authentication mechanism. . . . . . . . . . . . . . . . . . . . . . . 207
9.7.1 Using LTPA as the authentication mechanism. . . . . . . . . . . . . . . . 207
9.8 Enabling global security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.9 Using SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.9.1 Storing certificates (key files and trust files) . . . . . . . . . . . . . . . . . . 214
9.9.2 Generating a self-signed certificate. . . . . . . . . . . . . . . . . . . . . . . . . 216
9.9.3 Requesting a certificate signed by a CA. . . . . . . . . . . . . . . . . . . . . 219
9.9.4 Configuring Express Application Server to use a key store . . . . . . 223
9.9.5 Configuring the Web container to use SSL. . . . . . . . . . . . . . . . . . . 225
9.10 Using SSL to the LDAP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9.10.1 Create and exchange certificates . . . . . . . . . . . . . . . . . . . . . . . . . 228
9.11 Using SSL between the plugin and Web container. . . . . . . . . . . . . . . . 236
9.12 Securing applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Chapter 10. Diagnosing problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
10.1 What to do if things go wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
10.2 Administrative console messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
10.3 Server logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Contents
vii
10.3.1 JVM (standard) logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.3.2 Process (native) logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
10.3.3 IBM service (activity) log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
10.4 Dumping the JNDI name space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
10.4.1 dumpNameSpace format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
10.5 Tracing an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
10.5.1 Diagnostic trace service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
10.6 Working with IBM service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
10.6.1 First Failure Data Capture (FFDC) . . . . . . . . . . . . . . . . . . . . . . . . 271
10.6.2 The Collector tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
10.7 IBM Agent Controller settings and status . . . . . . . . . . . . . . . . . . . . . . . 273
10.8 Product installation information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
10.8.1 Locating Express Application Server version information. . . . . . . 274
10.8.2 Finding the JDK version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
10.9 Resources for problem determination. . . . . . . . . . . . . . . . . . . . . . . . . . 278
Appendix A. Classloaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Express Application Server classloader overview . . . . . . . . . . . . . . . . . . . . . 280
Application classloader settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Application classloader policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Application classloader mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Reload settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
WAR classloaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Appendix B. Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
startServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
stopServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
serverStatus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
backupConfig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
restoreConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
viii
WebSphere Application Server - Express V5.0.2 Administrator Handbook
Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
dumpNameSpace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Appendix C. Installing a CVS server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Installing the CVS server on Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Create a directory for the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
© Copyright IBM Corp. 2003. All rights reserved.
ix
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.
x
WebSphere Application Server - Express V5.0.2 Administrator Handbook
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
alphaWorks®
Cloudscape™
DB2®
developerWorks®
Domino™

IBM®
ibm.com®
Informix®
iSeries™
Lotus®
Notes®
OS/400®
Redbooks™
Redbooks (logo) ™
SecureWay®
SLC™
Tivoli®
WebSphere®
The following terms are trademarks of International Business Machines Corporation and Rational Software
Corporation, in the United States, other countries or both.
XDE™
The following terms are trademarks of other companies:
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. 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.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
© Copyright IBM Corp. 2003. All rights reserved.
xi
Preface
Beginning with WebSphere® Application Server - Express 5.0.1, the
recommended way to administer production servers is through the Web-based
administrative console. This IBM® Redbook describes the installation planning
and administration of WebSphere Application Server - Express on Windows and
Linux in a production environment. The book includes information on
development and production topologies, configuring and securing the server,
and deploying applications. It also provides problem determination information.
Application developers should continue to use IBM WebSphere Application
Server - Express V5.0.2 Developer Handbook, SG24-6555. The server
administration is still available through the Studio Site Developer tool.
iSeries™ users should use WebSphere Application Server - Express V5.0 for
iSeries, REDP3624 for supplemental information specific to iSeries.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Raleigh Center.
Carla Sadtler is a WebSphere Specialist at the International Technical
Support Organization, Raleigh Center. She writes extensively in the
WebSphere and Patterns for e-business areas. Before joining the ITSO in
1985, Carla worked in the Raleigh branch office as a Program Support
Representative. She holds a degree in mathematics from the University of
North Carolina at Greensboro.
Thanks to the following people for their contributions to this project:
Peter Kovari
International Technical Support Organization, Raleigh Center
Mark Edwards
IBM Raleigh
Kevin Postreich
IBM Raleigh
Robin Hackney
IBM Raleigh
xii
WebSphere Application Server - Express V5.0.2 Administrator Handbook
Justin Bogers
ASTECH Solutions Inc.
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 Redbooks™ to be as helpful as possible. Send us your comments
about this 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
P.O. Box 12195
Research Triangle Park, NC 27709-2195
© Copyright IBM Corp. 2003. All rights reserved.
1
Chapter 1.
Planning and installation
approach
WebSphere Application Server - Express consists of two major components:
￿ Express Application Server
￿ Studio Site Developer
In this chapter we provide information on planning activities for WebSphere
Application Server - Express on the Windows and Linux operating systems.
The Express Application Server is also supported on the OS/400® operating
system. For information related to Express Application Server on OS/400, see
WebSphere Application Server - Express V5.0 for iSeries, REDP3624.
1
2
WebSphere Application Server - Express V5.0.2 Administrator Handbook
1.1 Installation planning
WebSphere Application Server - Express consists of two major products that can
be installed together on one machine or separately.
￿ WebSphere Studio Site Developer: A development tool that allows you to
create and test applications.
￿ Express Application Server: A full production server for hosting applications
on the Web.
In addition, an effective installation will have a database product and CVS server
installed and implemented.
Figure 1-1 WebSphere Application Server - Express
Express Application
Server
WebSphere Studio
Site Developer
Express
Test
Environment
Web
projects
Database
Access
Help
Team
Develop
Web
Services
DB2
Cloudscape
Oracle
SQL
Server
Data Access
CVS
Repository
Web Service access
XML
Web client
Server
projects
Configure
and deploy to
test servers
Administratiion
Configure
and deploy to
production
servers
Production server
Test server
Application
Application
Application
Chapter 1. Planning and installation approach
3
When planning for WebSphere Application Server - Express, you need to
consider each of the following areas:
￿ WebSphere Studio Site Developer: Each application developer needs a
copy of Studio Site Developer installed on a workstation.
￿ Express Application Server: The Express Application Server provides the
runtime environment for applications.
￿ Database server product: Though not mandatory, databases are essential
for effective applications. You need to obtain and install a supported database
server product.
￿ Team development server product (optional): Team development is also
recommended. This allows multiple developers to work on the same
application at the same time. Even if you only have a single application
developer, it is still advantageous to use a team development mechanism for
storing applications and tracking changes. Studio Site Developer provides a
CVS client. You need to obtain and install a CVS server.
￿ Security server product (optional): Security can be handled in Express
Application Server using the operating system security. However, you also
have the option of using a security server that implements LDAP. If you elect
to use an LDAP server, you need to obtain and install the LDAP server
product.
1.1.1 Supported platforms and requirements
Platform support information and requirements for WebSphere Application
Server - Express can be found at the following Web site:
http://www.ibm.com/software/webservers/appserv/express/requirements/
1.1.2 Roles
In the course of this book, you will see references to people that perform specific
functions (roles). This doesn’t mean that you need this many people. All of these
roles can be performed by one person. It simply makes it easy for us to
distinguish which “hat” the administrator is wearing at the time:
￿ Application developer: The application developer will build and test
applications using Studio Site Developer. The application developer needs to
have basic Web development skills.
￿ Express Application Server administrator: The administrator will install
and maintain the Express Application Server sites. This includes obtaining
and installing hardware, making the appropriate arrangements for security
and Internet access, and for deploying applications.
4
WebSphere Application Server - Express V5.0.2 Administrator Handbook
￿ Database administrator: The applications will more than likely require
access to one or more databases. The database administrator is responsible
for obtaining, installing, and implementing a database server. This includes
creating and maintaining databases.
￿ CVS administrator: A CVS server is required for the team development
environment. The CVS administrator is responsible for obtaining, installing,
and implementing the CVS environment.
1.1.3 Installation directory references
Throughout this publication there are references to specific file locations within
WebSphere Application Server - Express. We use the following terminology:
￿ <express_install>: Refers to the high-level installation directory, for example,
C:\WebSphere\Express on Windows or /opt/IBM/WebSphere/Express on
UNIX platforms.
￿ <server_install>: Refers to the installation directory for Express Application
Server, for example, C:\WebSphere\Express\AppServer on Windows or
/opt/IBM/WebSphere/Express/AppServer on UNIX platforms.
￿ <studio_install>: Refers to the installation directory for Studio Site Developer,
for example, C:\WebSphere\Express\SiteDeveloper on Windows or
/opt/IBM/WebSphereStudio on UNIX platforms.
￿ <rac_install>: Refers to the installation directory for the IBM Agent Controller,
for example, C:\WebSphere\Express\RAC on Windows or /opt/IBMRAC on
UNIX platforms.
￿ <plugin_install>: Refers to the installation directory for the Web server plugin.
￿ <gsk_install>: Refers to the installation directory for the IBM Global Security
Kit (installed with the Web server plugin).
￿ <ihs_install>: Refers to the installation directory for the IBM HTTP Server (not
included with WebSphere Application Server - Express).
When using this notation, we use a generic indicator for the directory structure
(forward slashes for all operating systems, versus using a backslash for
Windows.)
1.1.4 Planning for Studio Site Developer
Each application developer will need to install Studio Site Developer on their
workstation. Studio Site Developer is supported on Windows and Linux
platforms.
Chapter 1. Planning and installation approach
5
Test server options
The default installation option for WebSphere Application Server - Express
assumes that both Studio Site Developer and Express Application Server will be
installed on the development machine. The assumption in this case is that the
Express Application Server will be used for testing purposes.
Studio Site Developer provides an internal test environment for Express
Application Server. This is installed as a part of Studio Site Developer, so it is not
necessary to install Express Application Server on the development machine
unless you want to test to a stand-alone version of the server.
To install only one component, use the custom install.
Database drivers
Each Studio Site Developer machine will need database drivers installed in order
to access the database server. See 1.1.8, “Planning for a database server” on
page 10.
1.1.5 Planning for Express Application Server
Express Application Server is a member of the IBM WebSphere Application
Server family of products. WebSphere Application Servers host applications in a
runtime environment. Each WebSphere Application Server configuration has
features unique to a particular environment. The Express Application Server
configuration provides a light-weight application server, designed specifically for
applications created with Studio Site Developer.
Web server
The Express Application Server includes an embedded version of the IBM HTTP
Server to server static Web pages (for example, HTML) and an application
server to handle the dynamic content (JSPs, servlets, etc.). There is no need to
install an external Web server.
Database access
Each Express Application Server machine will need database drivers installed in
order to access the database server. See 1.1.8, “Planning for a database server”
on page 10.
Install options
.
The typical install path will install both Express Application Server and Studio
Site Developer. Unless you plan to perform application development on this
system, use the Custom install option to install Express Application Server only.
6
WebSphere Application Server - Express V5.0.2 Administrator Handbook
FTP server or shared file system
To deploy an application it must be accessible to the Express Application Server.
The application developer packages the application into an EAR file (.ear) and
then copies it to a location where the administrator can pick it up for deployment.
In the case of a remote test Express Application Server, applications are
deployed from the Studio Site Developer workbench. Studio Site Developer
allows you to define the mechanism to use to copy the EAR file to the Express
Application Server machine. This can be either FTP or using a shared file
system.
In the case of deployment to a production Express Application Server, the EAR
file is moved manually. In this case, FTP or shared file system are still good
options.
Ensure that one of these mechanisms is in place. This may mean that you need
to install or activate an FTP server on the Express Application Server machines.
TCP/IP ports
Each Express Application Server instance, whether installed separately or used
as a test environment within Studio Site Developer will use a set of TCP/IP ports.
Before installation you must check to see if the default ports used by WebSphere
Application Server - Express conflict with ports already in use. The ports used by
Express Application Server and Studio Site Developer are both configurable.
Once Express Application Server is installed, you can reconfigure the end points
using the administrative console. Each installation of Express Application Server
will use the following defaults:
Table 1-1 Express Application Server end points
For information about altering these values, see 4.2.1, “Updating application
server end points” on page 64.
The Web container in the application server is initially set up to use four TCP/IP
ports for requests coming in from Web browsers:
￿ 7080
￿ 7090
￿ 7043
￿ 7443
Port Application server end point name
7809 BOOTSTRAP_ADDRESS
7880 SOAP_CONNECTOR_ADDRESS
Chapter 1. Planning and installation approach
7
These ports can be changed using the administrative console. They are
configured as HTTP transports in the application server Web container. For
information about how to change these ports, see 4.2.2, “Updating or changing
HTTP transport values” on page 65.
If you have installed Express Application Server and Studio Site Developer on
the same machine, be aware that Studio Site Developer will default to using
ports 7080 and 7443. These can also be reconfigured using by opening the
server configuration and switching to the Ports tab.
Administration of production and test servers
There are two flavors of Express Application Server provided with WebSphere
Application Server - Express:
￿ Studio Site Developer test environment: This server is an Express
Application Server that is internal to Studio Site Developer and runs as a part
of that program. It allows you to test the components of your application
during development without having to install or deploy to a server.
Configuration, operation, and deployment of applications to the test
environment is done from the Studio Site Developer workbench.
￿ Stand-alone Express Application Server: The Express Application Server
can be used for production mode and/or for testing:
– The default installation option for WebSphere Application Server - Express
installs both Studio Site Developer and Express Application Server on the
same machine. Developers can test applications using the internal Studio
Site Developer test environment, then deploy and test on a “real” Express
Application Server. In this case, the administration for the Express
Application Server is done from the Studio Site Developer workbench.
– When installing Express Application Server for production purposes, it is
recommended that you install it stand-alone on a production machine. An
administrator deploys applications to the machine using the Web-based
administrative console.
Note that both the production and test Express Application Server scenarios
discussed here are in fact, the exact same Express Application Server, but
simply used for two purposes and administered in two ways. You should only
use one method or the other to administer. Changes made using the
Note: This discussion assumes that you will be able to start the server and
open the administrative console. If you have port conflicts, this may not be
possible unless you shut down the process using the conflicting ports. You can
change these in the XML configuration after installation manually if this is the
case. For information, see the tip box in 4.2.2, “Updating or changing HTTP
transport values” on page 65.
8
WebSphere Application Server - Express V5.0.2 Administrator Handbook
administrative console will not be recognized by the Studio Site Developer
workbench.
Problem determination
One of the useful problem determination tools for runtime is the server activity
log. In order to analyze the log, the administrator will need access to a Studio
Site Developer machine.
1.1.6 Planning for team development
When multiple application developers are working on the same application, a
team development environment is almost a must. Team development implies that
you are using a version control system to manage copies of the application.
Multiple programmers generally “check out” a copy to work with, then “check in”
the changes. Other programmers working with the same application can merge
their changes with those of others.
Studio Site Developer provides a built-in client to allow team development
activities using the CVS Server (Concurrent Versions System). The server is not
included in the WebSphere Application Server - Express package. The CVS
home site is at http://www.cvshome.org and you can refer to the site
http://www.cvshome.org/docs/manual/ to obtain the CVS manual.
As an administrator, you need to obtain and install a CVS server. This should be
on a system that has nightly backups and is accessible to all application
developers. The machine should have sufficient disk space to store the
applications.
The CVS site recommends that you run the CVS server on a UNIX platform.
However, we have a primarily Windows development shop and chose to use
CVS on Windows. Our installation experiences are documented in Appendix C,
“Installing a CVS server” on page 301.
1.1.7 Planning for security
Express Application Server provides runtime security for protected application
resources, including the administrative console. This security mechanism is
disabled at installation time, but once enabled, will require a user registry to hold
user, group, and password information.
User registry
The user registry function can be performed by the operating system security
mechanism, or can be performed by an LDAP implementation.
Chapter 1. Planning and installation approach
9
If you user the operating system user registry, no immediate action is required.
However, when using the Windows operating system user registry, be aware that
domain user registry takes precedence over the local system user registry.
If you elect to use an LDAP implementation, you need to obtain, install, and
configure the LDAP product. Express Application Server supports the following
LDAP servers:
￿ IBM Directory Server
￿ Lotus® Domino™ Enterprise Server
￿ IBM SecureWay® Directory
￿ Sun ONE Directory Server
￿ Windows 2000 Active Directory 2000
￿ Novell eDirectory
SSL
Express Application Server also supports the use of SSL to provide
confidentiality and integrity of data transported between two components over
the network. The use of SSL relies on the existence of digital certificates that
contain information about the identity of the certificate owner.
A client can trust the contents of a certificate if that certificate has been digitally
signed by a trusted third party. Certificate Authorities (CA) act as a trusted third
party and will get signed certificates on the basis of their knowledge of the
certificate requestor. If you elect to use SSL, you may need to obtain a certificate
from a certifying authority.
The Express Application Server provides a set of certificates that may be used
for testing purposes. However, the identities contained in the certificates are
generic and the expiration dates are set artificially low.
SSL can be used in the following situations:
￿ Studio Site Developer and IBM Agent Controller
￿ Express Application Server and Web client
￿ Using LTPA as the authentication mechanism
￿ Express Application Server and the Web server plugin
Before making any decisions about security, you should review Chapter 9,
“Implementing security” on page 191.
10
WebSphere Application Server - Express V5.0.2 Administrator Handbook
1.1.8 Planning for a database server
One of the primary advantages of running a Web application using the Express
Application Server over a generic Web server is the ability of the application to
access data dynamically. One of the sources of this data is from relational
databases.
WebSphere Application Server - Express provides support for database access
but does not provide a production database server product. Before implementing
a WebSphere Application Server - Express, you need to obtain, install, and
configure a database server product for production use.
A development-use only version of IBM DB2® Express is included with
WebSphere Application Server - Express and is available for install on the
product CD. The DB2 database serves as a testing environment if you wish to
test your applications on DB2.
The samples shipped with Studio Site Developer use an internal runtime copy of
Cloudscape™ for their databases.
WebSphere Application Server - Express supports application access to the
following database products:
￿ Cloudscape
￿ IBM DB2
￿ Oracle 9i
￿ SQL Server 2000
￿ Informix®
￿ Sybase
To find the most current information database product support, refer to the
readme included with the product. The readme is in the <express_install>
directory. For example, c:\WebSphere\Express\readme.html.
The database server can reside on a dedicated machine, or depending on the
volume of database traffic, you might want to put it on the Express Application
Server machine. Having it on the same machine can improve performance by
eliminating network time, but beware that the two products will be competing for
machine resources.
If the database server resides on a separate machine, the Express Application
Server will need access to the JDBC drivers provided by the database server
product. In addition, each Studio Site Developer machine will need access to the
drivers in order to test applications and use the database features.
Chapter 1. Planning and installation approach
11
1.1.9 Planning for Web services
Web services are self-contained, modular applications that can be described,
published, located, and invoked over a network. Web services are hosted by a
service provider and are located using service brokers using a UDDI registry.
Examples of the type of function a Web service could provide are:
￿ Weather forecasting
￿ Airline reservations
￿ Currency conversions
Applications developed for the WebSphere Application Server - Express
environment can take advantage of these Web services. Invoking a Web service
allows you to provide the function to the user without incurring the cost of
developing the application.
There are many Web services available for free. However, free sites can’t always
be relied on to continually provide a service. It is likely that you will need to
register or buy services from a registry or provider before using the Web service.
This will most likely be handled during application development time. Any
development or runtime licensing issues should be addressed before deploying
the application.
1.2 Planning for backup and recovery
As with any other production critical programs, you should plan for backup and
recovery in the event of a system crash. You should choose a backup and
recovery scheme that is the most efficient for the operating system and use it to
backup every server, including the Express Application Server, the Studio Site
Developer machines, the CVS server machine, and the database server.
For example, you could use the Tivoli® Storage Manager to run nightly,
incremental backups of each system,
1.2.1 Express configuration backup
The server configuration is stored as a series of XML files in the
<server_install>/config directory. The Express Application Server provides two
commands that can be used to create a backup copy of the configuration and to
Note: IBM now ships DataDirect Technologies JDBC Drivers for WebSphere
Application Server - Express with V5.0.2.
12
WebSphere Application Server - Express V5.0.2 Administrator Handbook
restore it. You can use these in the event that you want to preserve the
configuration, for example, before making major configuration changes.
The commands are:
￿ <server_install>/bin/backupConfig.bat
￿ <server_install>/bin/restoreConfig.bat
The command syntax and usage notes on these commands can be found in
Appendix B, “Commands” on page 287.
1.2.2 Application recovery
An application is packaged in an EAR file. The EAR file is created in Studio Site
Developer and deployed to Express Application Server. If you lose the Express
Application Server configuration or installation, you can export the EAR file from
Studio Site Developer and redeploy.
If you lose the application from the Studio Site Developer workspace, you can
export a copy of the EAR file from Express Application Server. For instructions,
see 6.5.6, “Exporting an enterprise application” on page 161. If you are using
CVS for team development, you can also recover the application from the CVS
repository.
1.2.3 Database backup
The database server should have nightly backups performed on the operating
system, but if the database product provides a backup scheme it is wise to use it
also. The database product is more likely to provide backups on a database
basis, making it easier to recover quickly.
For information on the backup capabilities of the database product, you will need
to refer to the individual product documentation.
IBM DB2 provides a scheduled backup capability. You can implement this from
the context menu for the database in the DB2 Control Center.
1.3 Installation approach
There are several common installation scenarios for you to choose from. This
section outlines those scenarios and give you an overview of the installation
process you should follow.
Feel free to mix and match!
Chapter 1. Planning and installation approach
13
1.3.1 Installation scenario 1
This scenario has the following features:
￿ Multiple development machines: Developers test applications in the Studio
Site Developer test environment, then deploy to the stand-alone Express
Application Server on their machine to test in a “real” environment.
￿ Product oriented: Each developer installs and maintains a database server
product. They also create the test databases.
￿ Production Express Application Server: The production database server
resides on the same machine.
￿ CVS server: A CVS server is used for team development.
Figure 1-2 System layout option 1
Development server
WebSphere
Studio
Express
Application
Server Test
Environment
Team
Test
database
Express
Application
Server
CVS Server
CVS
Developer
Developer
Express
Application
Server
Development server
WebSphere
Studio
Express
Application
Server Test
Environment
Team
Test
database
Production server
Express
Application
Server
Production
database
Administrator
14
WebSphere Application Server - Express V5.0.2 Administrator Handbook
Table 1-2 shows a summary of what needs to be installed and where.
Table 1-2 Installation summary
1.3.2 Installation scenario 2
This scenario has the following features:
￿ Multiple development machines: Developers test applications in the Studio
Site Developer test environment, then deploy to the stand-alone Express
Application Server on their machine to test in a “real” environment.
￿ Production server: A production Express Application Server is used.
￿ Database administration: There is a database server that contains both
production and test databases. A database administrator creates and
maintains the databases. This frees up the developer from having to deal with
the database server product.
￿ CVS server: A CVS server is used for team development.
Development server(s) Application server CVS server
￿ Express “Typical”
install
￿ Database server
￿ Express Custom
install. Select
Application Server -
Express
￿ Database server
￿ CVS server
Chapter 1. Planning and installation approach
15
Table 1-3 shows a summary of what needs to be installed and where.
Table 1-3 Installation summary
Development server
WebSphere
Studio
Express
Application
Server Test
Environment
Team
Express
Application
Server
CVS Server
CVS
Developer
Developer
Express
Application
Server
Development server
WebSphere
Studio
Express
Application
Server Test
Environment
Team
Production server
Express
Application
Server
Database server
Production
database
Test
database
Administrator
Development
server(s)
Application
server
Database server CVS server
￿ Express
“Typical” install.
￿ Database
drivers for the
appropriate
database
server product.
￿ Express
Custom install.
Select
Application
Server -
Express
￿ Database
server
￿ CVS server
16
WebSphere Application Server - Express V5.0.2 Administrator Handbook
1.3.3 Installation scenario 3: Production environment
This scenario has the following features:
￿ Multiple development machines. Developers test applications in the Studio
Site Developer test environment, then deploy to a remote stand-alone
Express Application Server test in a “real” environment. Multiple developers
can use the same Express Application Server.
Each developer installs and maintains a database server product. They also
create the test databases.
￿ A production Express Application Server.
￿ A production database server. As a variation of this scenario, the production
database server and Express Application Server can be combined on one
machine.
￿ A CVS server for team development.
Development server
WebSphere
Studio
Express
Application
Server Test
Environment
Team
CVS Server
CVS
Developer
Developer
Development server
WebSphere
Studio
Express
Application
Server Test
Environment
Team
Database server
Production
database
Production server
Express
Application
Server
Test
database
Administrator
Test server
Express
Application
Server
Test
database
Chapter 1. Planning and installation approach
17
Table 1-4 shows a summary of what needs to be installed and where.
Table 1-4 Installation summary
See the Getting Started documentation for information on how to manage
application deployment by multiple developers to a remote test server. You can
find this document in <express_install>/gs_pdf.pdf.
1.4 Using an external Web server
Web server plugins work in conjunction with a Web server product to allow HTML
requests to be handled by the Web server, while forwarding requests that must
be handled by servlets and JSPs to the Express Application Server.
WebSphere Application Server - Express provides Web server plugins for the
following Web servers.
￿ IBM HTTP Server 1.3
￿ IBM HTTP Server 2.0
￿ Apache 1.3 Web Server
￿ Microsoft Internet Information Services
￿ Sun ONE 6.0 Web Server
￿ iPlanet 4.1 Web Server
￿ Lotus Domino Web Server
Using a Web server plugin enables you to:
￿ Place Web server in a secure DMZ, providing an additional layer of security
for the application servers.
￿ Use a fully functional HTTP server. Although WebSphere Application Server -
Express provides an internal HTTP server to handle HTML requests, it does
not provide the bells and whistles that some Web servers do and, in addition,
Development
Server(s)
Application
Server
Database server CVS server
￿ Express
“Custom”
install. Select
Studio Site
Developer.
￿ Database
server
￿ Express
Custom install.
Select
Application
Server -
Express
￿ A second copy
of Application
Server
￿ Database
server
￿ CVS server
18
WebSphere Application Server - Express V5.0.2 Administrator Handbook
is not configurable. If you have an existing Web site you can continue to use
your Web server.
￿ Serve requests for static data (HTML pages) from the Web server. This can
reduce traffic moving through the firewall and free up application server
resources for handling more complicated requests.
When a request reaches the Web server, the server checks its configuration file
for information about how to handle the request. If the request cannot be handled
by the Web server, it is passed to the Web server plugin. The plugin inspects its
own configuration file for a matching URI entry. If found, the configuration file
contains the information needed by the plugin to forward the request to the
appropriate application server.
Table 1-4 on page 17 shows a summary of what needs to be installed and where.
Table 1-5 Installation summary
Production server
Web user
Web server
HTML pages
Express
Application
Server
JSPs
servlets
f
i
r
e
w
a
l
l
f
i
r
e
w
a
l
l
DMZ
Internal networ
k
Internet
HTTP / HTTPs
HTTP / HTTPs
plugin
Web Server(s) Application
Server
￿ Web server
product
￿ Express Web
server plugin
￿ Express
Custom install
(Select
Application
Server -
Express)
Chapter 1. Planning and installation approach
19
1.5 Finding information
You can also refer to the following to obtain additional information:
￿ To learn more about Studio Site Developer, see IBM WebSphere Application
Server - Express V5.0.2 Developer Handbook, SG24-6555.
￿ For information about running Express Application Server on OS/400, see
WebSphere Application Server - Express V5.0 for iSeries, REDP3624.
￿ For information about the technical specifications, see
http://www.ibm.com/software/webservers/appserv/express/WASexpress-
spec.pdf
￿ For platform support and requirements, see
http://www.ibm.com/software/webservers/appserv/express/requirements/
￿ For the latest information on supported software, see the readme file shipped
with the product. The file can be found in <express_install>/readme.html.
20
WebSphere Application Server - Express V5.0.2 Administrator Handbook
© Copyright IBM Corp. 2003. All rights reserved.
21
Chapter 2.
Express Application Server
architecture
In order to effectively administer an Express Application Server environment, you
should be familiar with the basics of the server architecture and how an
application flows through the system. The terms introduced in this chapter are
intended to help you as you go along.
2
22
WebSphere Application Server - Express V5.0.2 Administrator Handbook
2.1 An inside view of the application server
Figure 2-1 shows an overview of the runtime architecture in an Express
installation.
Figure 2-1 WebSphere Application Server - Express overview
2.1.1 Cells, nodes, and application servers
As mentioned earlier, Express Application Server is a member of the WebSphere
Application Server family. Each member of the family uses the same architectural
structure. The simplest member, Express, contains a subset of the full
architecture. The Base configuration is slightly more advanced, Network
Deployment, even more advanced, and then Enterprise at the top. As a result of
the common architecture, some concepts will be visible at the Express
configuration level, though not necessarily relevant.
The first concept that falls into this category is the idea of cells and nodes.
Application Server: Server1
Node: DefaultNode
JNDI name space
Security server
Application
Database
Config
repository
(XML files)
Web container
Embedded
HTTP server
adminconsole
application
user
application
virtual host
virtual host
LDAP
Database
Studio Site
Developer
(administrator)
Web browser
(customer)
Web browser
(administrator)
A
g
e
n
t

C
o
n
t
r
o
l
l
e
r
Cell: DefaultNode
Chapter 2. Express Application Server architecture
23
Application servers
The application server is the primary runtime component. This is where the
application actually executes. All WebSphere Application Server configurations
can have one or more application servers. However, there is no workload
distribution or common administration among application servers until you reach
the Network Deployment level.
Nodes
A node is a logical grouping of WebSphere managed server processes that
share common configuration and operational control. A node is generally
associated with one physical installation of WebSphere Application Server.
In the Express configuration of WebSphere Application Server, there is only one
node, called DefaultNode. As you move up through the more advanced
WebSphere Application Server configurations, the concept of configuring
multiple nodes from one common administration server and workload distribution
among nodes is introduced.
Cells
A cell is an administrative concept, used in the more advanced WebSphere
Application Servers. Beginning with the Network Deployment configuration, a cell
can consist of multiple nodes, all administered from a single point.
Application servers are attached to nodes and nodes belong to a cell. In the
Express configuration, there is one cell, called “DefaultNode”.
2.1.2 Application server components
The application server is the primary component of WebSphere. It runs in a Java
Virtual Machine (JVM), providing the runtime environment for the application's
code. The application server provides “containers” that specialize in enabling the
execution of specific Java application components.
At installation, one application server called “server1” is created. One application
is installed by default on this server. The application is the administrative console
application (adminconsole.ear). As user applications are developed, they are
installed on server1.
Additional servers can be created, but no workload distribution is supported.
Web container
The Web container processes servlets, JSP files, and other types of server-side
inclusions.
24
WebSphere Application Server - Express V5.0.2 Administrator Handbook
The Web container configuration provides information about the application
server component that handles servlet requests forwarded by the Web server.
Each application server runtime has one logical Web container, which can be
modified, but not created or removed. The administrator specifies Web container
properties.
The types of things you would configure in relation to the Web container are:
￿ Embedded HTTP server: The Web container runs an embedded HTTP server
for handling HTTP(S) requests from external Web server plugins or Web
browsers.
Web browser clients access applications through the embedded HTTP server
in the Web container by using the URL:
http://server_host:port_number/application_root_context
By default, the port number is 7080, but this can be changed in the Web
container configuration.
￿ Session management.
￿ Default virtual host.
Embedded IBM HTTP Server
Web site applications that consist of static content (HTML pages, graphics, etc.)
are traditionally provided through the use of Web server products, such as the
IBM HTTP Server. Using an application server product, such as WebSphere
Application Server, allows you to extend those applications to use dynamically
created elements in Web pages.
In a typical application server environment, you will have a Web server that
serves HTML pages. Requests that require dynamic content (using a JSP or
servlet) are passed through to the application server.
As with other members of the WebSphere Application Server family, the Express
Application Server provides an embedded Web server based on IBM HTTP
Server. This embedded server can be used to serve the static Web pages for the
application. Although not a fully configurable Web server, it provides the function
needed by applications running in a WebSphere Application Server - Express
environment. The embedded HTTP server runs within the Web container.
Virtual hosts
A virtual host is a configuration enabling a single host machine to resemble
multiple host machines. It allows a single physical machine to support several
independently configured and administered applications. It is not associated
with a particular node. It is a configuration, rather than a "live object", which is
why it can be created, but not started or stopped.
Chapter 2. Express Application Server architecture
25
Suppose an Internet Service Provider (ISP) has two customers whose Internet
sites it would like to host on the same machine. The ISP would like to keep the
two sites isolated from one another, despite their sharing a machine. The ISP
could associate the resources of the first company with VirtualHost1 and the
resources of the second company with VirtualHost2.
Each virtual host has a logical name and a list of one or more DNS aliases by
which it is known. A DNS alias is the TCP/IP host name and port number used to
request the servlet, for example yourHostName:80. Common aliases are the
machine's IP address, short host name, and fully qualified host name. The alias
comprises the first part of the path for accessing a resource such as a servlet.
When a request is made, the server name and port number entered into the
browser are compared to a list of all known aliases in an effort to locate the
correct virtual host and serve the servlet. If no match is found, an HTTP 404 error
is returned to the browser.
Multiple virtual hosts can be associated with an application server. Conversely,
multiple application servers can use the same virtual host. One virtual host is
designated as the default for an application server for configuration purposes.
There are two virtual hosts defined during installation, default_host and
admin_host.
￿ The default_host virtual host is intended for access to user applications,
either through the HTTP transport or via a Web server. At installation time, it
is configured as the default virtual host for the server1 application server. It is
configured to match requests to ports 80, 7080, and 7443 for any host name.
￿ The admin_host virtual host is used for access to the WebSphere
administrative console. It is configured to match requests to the secure ports
7090 (HTTP transport) and 7043 (Web server) for any host name.
When you install an application, you associate a virtual host with each Web
module in the application. By associating a virtual host with a Web module,
requests that match the host aliases for the virtual host should be processed by
servlets/JSPs in this Web module.
A single virtual host can be associated with multiple Web modules unless each
application has unique URIs. If there are multiple applications that have a
common URI, different virtual hosts must be created and associated with each of
the applications.
26
WebSphere Application Server - Express V5.0.2 Administrator Handbook
Figure 2-2 Virtual hosts
Naming service
The WebSphere naming implementation is composed of JNDI and CosNaming.
JNDI provides the client-side access to naming and presents the programming
model used by application developers. CosNaming provides the server-side
implementation and is where the name space is actually stored. JNDI essentially
provides a client-side wrapper of the name space stored in CosNaming, and
interacts with the CosNaming server on behalf of the client.
The naming architecture is used by clients of WebSphere applications to obtain
references to objects related to those applications. These objects are bound into
a mostly hierarchical structure, referred to as a
name space
. The name space
structure consists of a set of
name bindings
, each consisting of a name relative to
a specific context and the object bound with that name.
The name space can be accessed and manipulated through a
name server.

Users of a name server are referred to as naming clients. Naming clients
typically use Java Naming and Directory Interface (JNDI) to perform naming
operations. Naming clients can also use the Common Object Request Broker
Architecture (CORBA) CosNaming interface.
Session management
In many Web applications, users dynamically collect data as they move through
the site based on a series of selections on pages they visit. Where the user goes
next, and what the application displays as the user's next page (or next choice),
http://www.myhost.com:7081/OnlineCatalog
http://www.myhost.com:7082/OrderApp
Express Application Server
TCP/IP: www.myhost.com
server1
virtual host: vhost1
alias: *
port: 7081
OnlineCatalog
server2
http://www.myhost.com:7083/TestApp1
OrderApp
virtual host: vhost2
alias: *
port: 7082
TestOrderApp
alias: *
port: 7083
Chapter 2. Express Application Server architecture
27
may depend on what the user has chosen previously from the site. For example,
if the user clicks the checkout button on a site, the next page must contain the
user's shopping selections. In order to maintain this data, the application stores it
in a “session”.
Express Application Server maintains the user’s session information in an
in-memory local cache. It passes the user an identifier known as a session ID,
which correlates an incoming user request with a session object maintained on
the server.
WebSphere supports three approaches to track sessions:
￿ SSL session identifiers: SSL session information is used to track the HTTP
session ID.
￿ Cookies: Express Application Server session support generates a unique
session ID for each user, and returns this ID to the user’s browser via a
cookie. The default name for the session management cookie is
JSESSIONID. Using cookies is the most common method of session
management.
￿ URL rewriting: This is another method used for session management.
The Servlet 2.3 specification defines session scope at the Web application level,
meaning, session information can only be accessed by a single Web application.
However, there may be times when there is a logical reason for multiple Web
applications to share information, for example, a user name.
WebSphere V5.0 provides an IBM extension to the specification allowing session
information to be shared among Web applications within an enterprise
application. This option is offered as an extension to the application deployment
descriptor. No code change is necessary to enable this option. This option is
specified during application assembling.
Security
Express Application Server uses a declarative security model in which an
application expresses security constraints in a form that is external to the
application. This external form of the constraint allows the application to be
independent of the chosen security mechanism. Security mechanisms are
defined and configured as part of the global application server security.
￿ Global security: This specifies a global security configuration for the Express
Application Server installation and applies to all applications. It determines
whether security will be applied at all, sets up the user registry against which
the authentication will take place, defines authentication mechanisms, and so
on. Global security is managed from the administrative console. You will
notice that many of the values for global security act as defaults.
28
WebSphere Application Server - Express V5.0.2 Administrator Handbook
￿ Application security: This determines application specific requirements. In
some cases, these values may override global security settings, but in most
cases they complement them. Application security includes such elements
as: a method for authenticating the users, a mechanism for authorizing the
users into application specific resources, role-based access control to these
resources, mapping of roles to user/user groups, etc. Application security is
administered during the assembly phase using Studio Site Developer and
during the deployment phase using the administrative console.
JAAS programming models allows the developer to design application
authentication in a pluggable fashion, which makes the application independent
from the underlying authentication technology.
Each application server JVM hosts a security service that uses the security
settings held in the configuration repository to provide authentication and
authorization functionality.
A security collaborator in the Web container is responsible for enforcing security
constraints specified in deployment descriptors. It communicates with the
security server every time when authentication and authorization actions are
required. The Web collaborator provides the following services to the application:
￿ Checks authentication
￿ Performs authorization according to the constraint specified in the
deployment descriptor
￿ Logs security tracing information
The following user registries are supported by Express Application Server:
￿ local operating system
￿ LDAP
￿ Custom user registry
The following authentication mechanisms are supported:
￿ Light Weight Third Party Authentication (LTPA)
￿ Simple WebSphere Authentication Mechanism (SWAM)
SSL is supported between the Web browser and the embedded HTTP server,
and between the Web container and the LDAP server.
TCP/IP ports
Each application server will use a set of TCP/IP ports. TCP/IP ports are
associated with the embedded HTTP server to receive requests from Web
browsers. These ports are referred to as HTTP transports. In addition, there are
TCP/IP ports (called end points) used for application server processes.
Chapter 2. Express Application Server architecture
29
Each application server is created with a default set of end points that can be
tailored to suit your needs. In general the defaults are fine, but there may be
occasions when another application or operating system component on the
same system is using one of the default port values.
The administrative console will expose end points that are relevant for more
advanced configurations. In Express Application Server, the following end points
are used:
￿ Bootstrap port: The bootstrap port setting together with the bootstrap host
name forms is used by naming clients to specify the naming server to look up
the initial context.
￿ SOAP connector address: The port used by the HTTP transport for
incoming SOAP requests. The SOAP connector can be used by
administration clients
The default application server, server1, is pre-configured with TCP/IP ports as
follows:
￿ Non-SSL port corresponding to the default_host virtual host
￿ SSL port corresponding to the default_host virtual host
￿ Non-SSL port corresponding to the admin_host virtual host
￿ SSL port corresponding to the admin_host virtual host
Resource providers
Resource providers provide resources needed by running Java applications, and
J2EE applications in particular. In Express Application Server, resource
providers are used to access the following applications:
￿ Relational databases: In order for an application to use a database, for
example, an database on an IBM DB2 database server, you would need to
define a JDBC provider and data source to identify the database and how to
access it. The JDBC provider defines the classes provided by the database
vendor required to interact with the database server. The data source
represents the database.
When a data source is created it is registered with the JNDI naming service.
An application can retrieve it from the naming service and use it to make a
connection to the data source it represents.
￿ JavaMail: The JavaMail APIs provide a platform and protocol-independent
framework for building Java-based mail client applications. The JavaMail APIs
30
WebSphere Application Server - Express V5.0.2 Administrator Handbook
require service providers, known in WebSphere as protocol providers, to
interact with mail servers that run the pertaining protocols.
A JavaMail provider encapsulates a collection of protocol providers. Express
Application Server has a Built-in Mail Provider that encompasses three
protocol providers: SMTP, IMAP and POP3. These protocol providers are
installed as the default and should be sufficient for most applications.
– Simple Mail Transfer Protocol (SMTP): This is a popular transport
protocol for sending mail. JavaMail applications can connect to an SMTP
server and send mail through it by using this SMTP protocol provider.
– Post Office Protocol (POP3): This is the standard protocol for receiving
mail.
– Internet Message Access Protocol (IMAP): This is an alternative
protocol to POP3 for receiving mail.
To use other protocols, you must install the appropriate service provider for
those protocols.
In addition to service providers, JavaMail requires the JavaBeans Activation
Framework (JAF) as the underlying framework to deal with complex data
types that are not plain text, like Multipurpose Internet Mail Extensions
(MIME), Uniform Resource Locator (URL) pages, and file attachments.
The JavaMail APIs, the JAF, the service providers and the protocols are
shipped as part of Express Application Server using the following Sun
licensed packages:
– mail.jar: Contains the JavaMail APIs, and the SMTP, IMAP, and POP3
service providers.
– activation.jar: Contains the JavaBeans Activation Framework.
Express Application Server supports JavaMail Version 1.2 and the JAF
Version 1.0.
As you can see, using resource providers introduces a level of abstraction
between the application and the server. It eliminates the need to hardcode
implementation level information in the application, making the code more
portable and easier to maintain.
2.2 Administration
Each application server has an administration service. This service provides the
necessary functions to manipulate configuration data for the server and its
components. The configuration is stored in a repository; a set of XML files is
stored in the server's file system.
Chapter 2. Express Application Server architecture
31
There are multiple administration interfaces:
￿ Administrative console: This is the primary interface for Express
Application Server administrators. It is a Web-browser based interface that
provides configuration and operation capability. The administrative console is
actually an enterprise application running on server1. Therefore, in order to
use the console, server1 must be running. If you create additional servers,
you can configure them using the administrative console application on
server1 but will have no runtime capabilities. You can install the
adminconsole.ear application on each server in order to have full operational
capabilities.
￿ Studio Site Developer: In situations where Express Application Server has
been installed as a test installation, application developers can manage the
application server using the Server perspective in Studio Site Developer. If an
application server is managed in this way, the administrative console should
not be used to manage the same system. Although nothing will prevent you
from doing this, changes made by the administrative console will not be seen
by Studio Site Developer.
￿ Commands: Express Application Server provides a set of commands in the
<server_install>/bin directory that allow you to perform a subset of
administrative functions. For example, to start an application server, you must
use the startServer command. This can not be done using the administrative
console.
￿ wsadmin: A scripting interface called wsadmin is provided for advanced
users.
IBM Agent Controller
When an Express Application Server is used to test applications from the Studio
Site Developer, server administration and operation is typically done by the
developer from the Studio Site Developer workbench. Communications between
the workbench and the Express Application Server are done via the IBM Agent
Controller. The IBM Agent Controller is installed automatically when the Express
Application Server is installed.
The IBM Agent controller is installed in the <express_install>/RAC directory.
Important: Using wsadmin requires knowledge of one of the supported
scripting languages and in depth familiarity with application server
architecture. It is not recommended for WebSphere Application Server -
Express users.
32
WebSphere Application Server - Express V5.0.2 Administrator Handbook
© Copyright IBM Corp. 2003. All rights reserved.
33
Chapter 3.
Administration overview
In this chapter we provide an overview of the administrative processes for
maintaining a production Express Application Server. We start with the basics of
administering the system and introduce the administrative console used in a
production environment.
Note that application developers will administer the Studio Site Developer test
environment and test Express Application Servers from the Studio Site
Developer workbench. This is considered a development topic and is not
covered in this chapter. For information on administering a test environment and
a test Express Application Server from Studio Site Developer, see IBM
WebSphere Application Server - Express V5.0.2 Developer Handbook,
SG24-6555.
3
34
WebSphere Application Server - Express V5.0.2 Administrator Handbook
3.1 Administration overview
Administration tasks are required to configure the Express Application Server,
deploy applications to it, and operate, monitor, and troubleshoot the environment.
All configuration information is stored as a set of XML files stored in the
<server_install>/config directory. You may hear this set of files referred to as the
configuration repository.
Configuration changes are made using the administrative console. Changes are
temporarily stored until the administrator saves them. At that point, the new
configuration is stored in the config directory.
3.2 Using the administrative console
The administrative console is accessed using a Web browser. It is actually an
application that runs on the Express Application Server, meaning that the server
must be up and running for the administrative console to be used.
At installation, the administrative console can be accessed by anyone with Web
browser access to the server. It has a built-in security mechanism that allows you
to require a user sign-in and restricts activity based on role. However, this
requires that the WebSphere global security (which is disabled by default) be
enabled. Before enabling security, you need to understand the options and
implications. For that reason, enabling the administrative console security will be
discussed later in Chapter 9, “Implementing security” on page 191.
3.2.1 Accessing the console
Every installation of Express Application Server has one server, called server1,
defined. The administrative console is actually an application that runs on
server1, so in order to access the administrative console, you need to ensure
that server1 is started.
1.On the Express Application Server machine, you can check the status of
server1 with the serverStatus.bat (.sh) command:
– Windows: <server_install>\bin\serverStatus server1
– Linux: <server_install>/bin/serverStatus.sh server1
Chapter 3. Administration overview
35
Figure 3-1 Checking the status of server1.
2.If the server is stopped, you can start it with the startServer.bat (.sh)
command:
– Windows:
cd <server_install>\bin
startServer server1
or
Start

Programs

IBM WebSphere Application Server - Express
V5.0.2

Start Application Server
– Linux:
cd <server_install>/bin
startServer.sh server1
Figure 3-2 Starting server1
3.Open a Web browser (from any machine) and use the following URL to open
the administrative console:
http://<Express_host>:7090/admin
C:\>cd WebSphere\Express\AppServer\bin
C:\WebSphere\Express\AppServer\bin>serverStatus server1
ADMU0116I: Tool information is being logged in file
C:\WebSphere\Express\AppServer\logs\server1\serverStatus.log