Administer application servers

An application server configuration provides settings that control how an application server provides services for running applications and their components.

After you install the product, we might have to perform one or more of the following tasks. Unless the task to perform is dependent on the existence of an application server, we can perform these tasks in any order.

Best practice: IBM recommends starting processes that run on the same profile with user IDs that have mutually compatible file permissions, meaning that each process can read or update files that the other processes create. This ensures that the processes can access the same files without encountering a permission-denied error. For example, if you run the deployment manager as user wasuser and then also run the tool to generate plug-ins on that same profile, you should run the tool as user wasuser.bprac

• Create an application server.

• Create clusters for workload balancing.

• Configure the server startup process such that only server components that are initially needed are started.

  When the server is configured such that only the components that are initially needed are started during the startup process, the remaining components are dynamically started as they are needed.

  Avoid trouble: If we are running other WebSphere products on top of this product, make sure that those other products support this functionality before you select this property.gotcha

• Configure transport chains to handle client requests.

• Develop custom services.

• Define processes for the application server.

  (zos) As part of defining processes, you might want to:

  1. Define process execution statements for starting or initializing a UNIX process.

  2. Configure monitoring policies to track the performance of a process.

  3. Configure the process logs to which standard out and standard error streams write.

  4. Configure name-value pairs for properties.

• Configure the Java virtual machine.

• (zos) Optional: Run WebSphere Application Server for z/OS controllers and daemons in reusable address spaces whenever possible. For more ceptual information, see the documentation in this information center about the reusable address space.

Results

Any new application servers we create are displayed in the list of servers on the console Application servers page.

What to do next

• Manage the application servers. Any newly created application servers are configured with many default settings that do not display when you run the Create New Application Server wizard. We might need to change some of these settings to better fit the needs of the environment.

• Deploy an application or component on the application server.

• View the status of the applications running on the application server.

Subtopics

• (zos) Test and production phases
  Before explaining the test and production configurations for the product, you must understand which test phase should be done on the z/OS platform and which should be done on other platforms.

• Configure virtual hosts
  Virtual hosts let you manage a single application server on a single machine as if the application server were multiple application servers each on their own host machine. We can separate and control which resources are available for client requests by combining multiple host machines into a single virtual host, or by assigning host machines to different virtual hosts.

• Create, editing, and deleting WebSphere variables
  We can use WebSphere variables to provide settings for any of the string data type attributes contained in the product configuration files.

• Manage shared libraries
  Shared libraries are files used by multiple applications. Each shared library consists of a symbolic name, a Java class path, and a native path for loading Java Native Interface (JNI) libraries. We can use shared libraries to reduce the number of duplicate library files on the system.

• (zos) Set up peer restart and recovery
  To allow the product to restart on an alternate system, the following prerequisites must be installed on every system (your original system as well as any systems intended for recovery) before reconfiguring the ARM policies to enable peer restart and recovery.

• Create application servers
  During the installation process, the product creates a default application server, named server1. Most installations require several application servers to handle the application serving needs of their production environment. We can use the command-line tool or the console to create additional application servers.

• Manage application servers
  We can use either the console or command-line tools to manage the application servers.

• Directory conventions
  References in product information to app_server_root, profile_root, and other directories imply specific default directory locations. Become familiar with the conventions in use for WebSphere Application Server.

• (iseries) Manage the QWAS85 subsystem for WebSphere Application Server
  WebSphere Application Server runs in its own subsystem, called QWAS85, which is installed with the product. For each WebSphere Application Server profile, the number of jobs that run in the QWAS85 subsystem depends on which product and which services you are using.

• Create generic servers
  A generic server is a server that is managed in the WAS administrative domain even though the server is not a server supplied by WebSphere Application Server. The WebSphere Application Server generic servers function enables you to define a generic server as an application server instance within the WAS administration, and associate it with a non-WebSphere WebSphere Application Server or process.

• (iseries) Enable user profiles to run application servers with System i Navigator
  Except for the default user profile (QEJBSVR), all user profiles used to run an application server must be enabled through the System i Navigator for the WAS.

• Configure transport chains
  A transport chain consists of one or more types of channels, each of which supports a different type of I/O protocol, such as TCP or HTTP. Network ports can be shared among all of the channels within a chain. The channel framework function automatically distributes a request arriving on that port to the correct I/O protocol channel for processing.

• Create custom services
  We can create one or more custom services for an application server. Each custom services defines a class that is loaded and initialized whenever the server starts and shuts down. Each of these classes must implement the com.ibm.websphere.runtime.CustomService interface. After creating a custom service, use the console to configure that custom service for the application servers.

• Define application server processes
  To enhance the operation of an application server, we can define command-line information for starting or initializing an application server process. Such settings define runtime properties such as the program to run, arguments to run the program, and the working directory.

• Configure the JVM
  As part of configuring an application server, you might define settings that enhance the way the operating system uses of the JVM.

• Tune application servers
  The product contains interrelated components that must be harmoniously tuned to support the custom needs of the end-to-end e-business application.

Related tasks

Add members to a cluster

Create clusters

Tune the application serving environment

Get started with wsadmin scripting

(zos) Enable the reusable ASID function

Commands (AdminTask)

Server collection

Application server settings

(zos) Application server custom properties for z/OS