3.1 Understanding profiles

The WAS installation process simply lays down a set of core product files required for the run time processes. After installation, create one or more profiles that define the run time to have a functional system. The core product files are shared among the run time components defined by these profiles.

With Base and Express, you can only have stand-alone appservers, as shown in Figure 3-1. Each appserver is defined within a single cell and node. The administration console is hosted within the appserver and can only connect to that appserver. No central management of multiple appservers is possible. An appserver profile defines this environment. You can also create stand-alone appservers with the ND package, though you would most likely do so with the intent of federating that server into a cell for central management.

Figure 3-1 System management topology: Stand-alone server (Base and Express)

With the ND package, you have the option of defining multiple appservers with central management capabilities, as summarized in Figure 3-2. The administration domain is the cell, consisting of one or more nodes. Each node contains one or more appservers and a node agent that provides an administration point management by the deployment manager.

The deployment manager can be located on the same machine as one or more of the appservers. This would be a common topology for single machine development and testing environments. In most production topologies, we recommend that the deployment manager be placed on a separate dedicated machine.

The basis for this run time environment starts with the deployment manager that provides the administration interface for the cell. As you would expect, the deployment manager is defined by a deployment manager profile.

Figure 3-2 System management topology: ND

Nodes can be added to the cell in one of two ways:

Note that the server name for a federated appserver is always going to be "server1".