WAS v8.5 > Set up the application serving environment > Manage profiles

Profile concepts

A profile defines the runtime environment. The profile includes all the files the server processes in the runtime environment and that we can change.

We can create a runtime environment using either the manageprofiles command or the Profile Management Tool graphical user interface. Some tasks, such as deleting a profile, require using manageprofiles.sh.


Core product files

The core product files are the shared product binary files. They do not change unless you install a refresh pack, a fix pack, or an interim fix. Default locations...

The default directory for creating profiles is...

We can create a profile anywhere on the machine or system, provided enough disk space is available.

To have binary files at different service levels, use a separate installation of the product for each service level.

If you create a profile in another existing folder in the installation root directory, then a risk exists 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

Multiple product installations save disk space saved. Updating WAS is simplified when we maintain a single set of core files. Creating new profiles is more efficient and less prone to error than full product installations, allowing a developer to create separate profiles of the product for development and testing.

We run PMT.sh or manageprofiles.sh to create a new profile on the same machine as an existing profile. Unique characteristics include profile name and name. Each profile shares all runtime scripts, libraries, the Java SE Runtime Environment 6 (JRE 6) environment, and other core product files.

Each profile has its own dmgr console and administrative scripting interface.


Profile types

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

Multiple directories exist within this directory, which correspond to different profile types and vary with the type of product that is installed. The directories are the paths that you indicate while using the manageprofiles command with the -templatePath option. We can also specify profile templates that exist outside the profileTemplates directory, if we have any. See the -templatePath parameter.

The manageprofiles command can create the following type of profile:

Management profile with an administrative agent server

The basic function of the administrative agent is to provide a single interface to administer multiple application servers.

We can create the profile using the Profile Management Tool or the manageprofiles command. If you create the profile with the manageprofiles command, specify app_server_root/profileTemplates/management for the -templatePath parameter and ADMIN_AGENT for the -serverType parameter to create this type of management profile.

Application server profile

Use the application server to make applications available to the Internet or to an intranet.

An important product feature is the ability to scale up a standalone 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 standalone application server.

Each standalone application server can optionally have its own dmgr console application, which we use to manage the application server. We can also use the wsadmin scripting facility to perform every function that is available in the dmgr console application.

No node agent process is available for a standalone application server node unless you decide to add the application server node to a deployment manager cell. Adding the application server node to a cell is known as federation. Federation changes the standalone application server node into a managed node. Use dmgr console of the deployment manager to manage the node. If you remove the node from the deployment manager cell, then use the dmgr console and the scripting interface of the standalone application server node to manage the process.

We can create the profile using the Profile Management Tool or the manageprofiles command. If you create the profile with the manageprofiles command, specify app_server_root/profileTemplates/default for the -templatePath parameter to create this type of profile.


Default profiles

Profiles use the concept of a default profile when more than one profile exists. The default profile is set to be the default target for scripts that do not specify a profile. We can use the -profileName parameter with most of the scripts to enable the scripts to act on a profile other than the default profile.

The default profile name is <profile_type><profile_number>:


Addressing a profile in a multiprofile environment: When multiple profiles exist on a machine, certain commands require specified the -profileName parameter if the profile is not the default profile. In those cases, it might be easier to use the commands that are in the bin directory of each profile. When you issue one of these commands within the bin directory of a profile, the command acts on that profile unless the -profileName parameter specifies a different profile.


Security policy for application server profiles

In environments where you plan to have multiple standalone application servers, the security policy of each application server profile is independent of the others. Changes to the security policy in one application server profile are not synchronized with the other profiles.


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 Management Tool 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 we do not relocate them: 

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01   
/opt/IBM/WebSphere/AppServer/profiles/AppSrv02
We can specify a different directory, such as /opt/profiles for the profile directory using the manageprofiles command. For example: 
manageprofiles.sh 
   -profileName AppSrv01
   -profilePath /opt/profiles

manageprofiles.sh 
   -profileName AppSrv02
   -profilePath /opt/profiles
Then 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 the profile, AppSrv01, exists:


Subtopics


Reference:

Profiles: File-system requirements


+

Search Tips   |   Advanced Search