Profile concepts

The WAS profile defines the runtime environment. The profile includes all of the files that the server processes in the runtime environment and can change. This topic discusses the main terms and concepts that are associated with profiles.

We can create a runtime environment either through the wasprofile command or the Profile Creation wizard graphical user interface.

The Profile Creation wizard is an InstallShield for Multiplatforms (ISMP) application. Use the wizard to enter most of the parameters that are described in this topic. Some parameters, however, require you to use the wasprofile command. You must use the wasprofile command to delete a profile, for instance because the Profile Creation wizard does not provide a deletion function.

However, the Profile Creation wizard also performs tasks that the wasprofile command does not. For instance, the wizard assigns nonconflicting ports, based on previous port assignments.

 

Core product files

The core product files are the shared product binaries, which are shared by all profiles.

The directory structure for the product has two major divisions of files in the installation root directory for the product:

When it is desirable to have binaries at different service levels, use a separate installation of WAS for each service level.

The configuration for every defined Application Server process is within the profiles directory unless you specify a new directory when you create a profile. These files change as often as you create a new profile, reconfigure an existing profile, or delete a profile.

All of the folders except for the profiles directory and a few others such as the logs directory and the properties directory do not change, unless you install service fixes. The profiles directory, however, changes each time you add, change, or delete a profile. The profiles directory is the default repository for profiles. However, we can put a profile anywhere on the machine or system, provided enough disk space is available.

If you put a profile in another existing folder in the installation root directory, a risk exists that the profile might be affected by the installation of a service fix that applies maintenance to the folder. Use a directory outside of the installation root directory when using a directory other than the profiles directory for creating profiles.

 

Why and when to create a profile

The wasprofile command-line tool defines each Application Server profile for the product.

Run the wizard or the wasprofile command each time that you want to create a stand-alone Application Server. A need for more than one stand-alone Application Server on a machine is common.

Administration is greatly enhanced when using profiles instead of multiple product installations. Not only is disk space saved, but updating the product is simplified when you maintain only a single set of product core files. Also, creating new profiles is faster and less prone to error than full product installations, allowing a developer to create separate profiles of the product for development and testing.

We can run the Profile Creation wizard or the command line tool to create a new Application Server environment on the same machine as an existing one. Define unique characteristics (such as profile name and node name) for the new profile. Each profile has its own administrative console and administrative scripting interface. Each Application Server process shares all run-time scripts, libraries, the Software Development Kit, and other core product files.

 

Profile types

Templates for each profile are located in the app_server_root/profileTemplates directory.

Within this directory are various directories that correspond to different profile types and that vary with the type of product installed. The directories are the paths that you indicate while using the wasprofile command with the -templatePath option. We can also specify profile templates that lie outside the installation root, if you happen to have any.

See the -templatePath parameter description in the wasprofile command topic for more information.

The wasprofile command in the Network Deployment product can create the following types of profiles:

Deployment manager profile

The basic function of the deployment manager is to deploy applications to a cell of Application Servers, which it manages. Each Application Server that belongs to the cell is referred to as a managed node.

Specify app_server_root/profileTemplates/dmgr for the -templatePath parameter to create this type of profile.

Application Server profile

The basic function of the Application Server is to serve applications to the Internet or to an intranet.

An important product feature for the Network Deployment product is the ability to scale up a stand-alone Application Server profile by adding the Application Server node into a deployment manager cell. Multiple Application Server processes in a cell can deploy an application that is in demand. We can also remove an Application Server node from a cell to return the node to the status of a stand-alone Application Server.

Each stand-alone Application Server has its own administrative console application, which you use to manage the Application Server. We can also use the wsadmin scripting facility to perform every function that is available in the administrative console application.

No node agent process is available for a stand-alone Application Server unless you decide to add the Application Server node to a deployment manager cell. Adding the Application Server to a cell is known as federation. Federation changes the stand-alone Application Server into a managed node. You use the administrative console of the deployment manager to manage the node. If you remove the node from the deployment manager cell, use the administrative console and the scripting interface of the stand-alone Application Server to manage the process.

Specify app_server_root/profileTemplates/default for the -templatePath parameter to create this type of profile.

Custom profile

The basic function of this profile that belongs to a deployment manager cell is to serve applications to the Internet or to an intranet under the management of the deployment manager.

The deployment manager changes a custom profile to a managed node by adding the node into the cell. The deployment manager also changes an Application Server into a managed node when you add an Application Server into a cell. When either node is added to a cell, the node becomes a managed node. The nodeagent process is then instantiated on the managed node. The node agent acts on behalf of the deployment manager to control Application Server processes on the managed node. The node agent can start or stop Application Servers, for example.

A deployment manager can create multiple Application Servers on a managed node so long as the node agent process is running. Processes on the managed node can include cluster members that the deployment manager uses to balance the workload for heavily used applications.

Use the administrative console of the deployment manager to control all of the nodes that the deployment manager manages. You can also use the wsadmin scripting facility of the deployment manager to control any of the managed nodes. A custom profile does not have its own administrative console or scripting interface. We cannot manage the node directly with the wsadmin scripting facility. You must use the administrative interface of the deployment manager to manage a managed node.

A custom profile does not include default applications or a default server as the Application Server profile does. A custom profile is an empty node. Add the node to the deployment manager cell. Then use the administrative interface of the deployment manager to customize the managed node, by creating clusters and Application Servers.

Specify app_server_root/profileTemplates/managed for the -templatePath parameter to create this type of profile.

Installed file set

You decide where to install the files that define a profile.

The default location is in the profiles directory in the installation root directory. We can change the location on the Profile Creation wizard or in a parameter when using the command line tool. For example, assume that you create two profiles on a Linux platform with host name devhost1. The profile directories resemble the following example if you do not relocate them 

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01     
/opt/IBM/WebSphere/AppServer/profiles/AppSrv02

If you specify a different directory, such as /opt/profiles for the profile directory, the profile directories resemble the directories shown in the following example 

/opt/profiles/AppSrv01     
/opt/profiles/AppSrv02

The following directories exist within a typical profile. This example assumes that a profile named AppSrv01 exists:

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/configuration

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/etc

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/firststeps

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installableApps

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedConnectors

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedFilters

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/samples

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/temp

  • /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/wstemp

Concurrent profile creation

Important: Concurrent profile creation is not supported at this time for one set of core product files. Concurrent attempts to create profiles result in a warning about a profile creation already in progress.

Related tasks
Directory conventions Related reference
wasprofile command