A profile defines the runtime environment. The profile includes all of the files that the server processes in the runtime environment and that you can change.
You 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. You can 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. Use the Profile Creation wizard to
complete tasks that the wasprofile command
does not support. For instance, the wizard assigns
nonconflicting ports, based on previous port assignments.
The core product files are the shared product binaries, which are shared by all profiles.
When you want binaries at different service levels, you must use a separate installation of the product 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.
Each 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, you can put a profile anywhere
on the machine or system, provided enough disk space is available.
If
you create a profile in another existing folder in the installation root directory,
then 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.
The wasprofile command-line tool defines each profile for the product.
Run the wizard
or the wasprofile command
each time that you want to create a profile. A need for more than one profile
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 a single set of product core files. Also, 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.
You can run the Profile Creation wizard or
the command-line tool to create a new profile on the same machine as an existing
one. Define unique characteristics, such as profile name and node name, for
the new profile. Each profile shares all runtime scripts, libraries, the Java
runtime environment, and other core product files.
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 wasprofile command with the -templatePath option. You can also specify profile templates that exist outside the installation root, if you have any.
See the -templatePath parameter description in the wasprofile command topic for more information.
Specify app_server_root/profileTemplates/dmgr
for the -templatePath parameter to create this type of profile.
An important product feature 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. You 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. You 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 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 stand-alone application server node 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, then use the administrative console and the scripting interface of the stand-alone application server node to manage the process.
Specify app_server_root/profileTemplates/default
for the -templatePath parameter to create this type of profile.
The deployment manager converts a custom profile to a managed node by adding the node into the cell. The deployment manager also converts an application server node into a managed node when you add an application server node into a cell. When either node is added to a cell, the node becomes a managed node. The node agent 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. You cannot manage the node directly with the wsadmin scripting facility.
A custom profile does not include default applications or a default server like the application server profile includes. A custom profile is an empty node. Add the node to the deployment manager cell. Then, you can use the administrative interface of the deployment manager to customize the managed node, by creating clusters and application servers.
Otherwise, specify app_server_root/profileTemplates/managed
for the -templatePath parameter to create this type of profile.
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. You can use the -profileName parameter with most of the scripts to enable the scripts to act on a profile other than the default one.
You decide where to install the files that define a profile.
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01 /opt/IBM/WebSphere/AppServer/profiles/AppSrv02If you specify a different directory, such as /opt/profiles for the profile directory, then the profile directories resemble the directories shown in the following example:
/opt/profiles/AppSrv01 /opt/profiles/AppSrv02