A profile defines the runtime environment. The profile includes all the files that the
server processes in the runtime environment and that you can change.
You can create a runtime environment either through the manageprofiles command or the Profile Management Tool graphical user interface. You can use the Profile Management Tool to enter most of the parameters that are described in
this article. Some parameters, however, require you to use the manageprofiles command. You must use the manageprofiles command to delete a profile, for instance,
because the Profile Management Tool does not provide a deletion function.
You can use either the Profile Management Tool or the
manageprofiles command to create a cell profile. The
Profile Management Tool creates the cell in a single step, whereas the
manageprofiles command requires two separate
invocations.
You can create a runtime environment through the manageprofiles command. Depending on the operation that you
want to perform with the manageprofiles command, you need to
provide one or more parameters. You can use the command to do such actions as creating or deleting
profiles. To create a cell profile, you must invoke the manageprofiles command two separate times.
Core product files
The core product files are the shared product binary files, which are shared by all profiles.
The directory structure for the product has the following two major divisions of files in the
installation root directory for the product:
When you want binary files 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.
If you create a profile in an installation root directory, then a risk exists
that the profile might be damaged or destroyed by routine system maintenance.
Why and when to create a profile
The manageprofiles command-line tool defines each
profile for the product.
Run the Profile Management Tool or the manageprofiles command each time that you want to create a
profile. A need for more than one profile on a machine is common.
Run the command-line tool each time that you want to create a profile.
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 manageprofiles
command to create a new profile on the same machine as an existing profile. Define unique
characteristics, such as profile name and node name, for the new profile.
You can run the Profile Management Tool or the
command-line tool to create a new profile on the same machine as an existing profile. Define unique
characteristics, such as profile name and node name, for the new profile. Each profile shares all
runtime scripts, libraries, the Java™ SE Runtime Environment 6
(JRE 6) environment, and other core product files.
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. You can also specify profile templates that exist outside the
profileTemplates directory, if you have any.
See the -templatePath parameter description in the manageprofiles command topic for more information.
The manageprofiles command in
the WebSphere® Application Server Network Deployment product can create the following types of
profiles:
- Management profile with a deployment manager server
- 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 a managed
node.
You can create the management profile with a deployment
manager server 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 DEPLOYMENT_MANAGER
for the -serverType parameter.
Specify management
for the -templatePath
parameter and DEPLOYMENT_MANAGER
for the -serverType parameter to create this type
of management profile with the manageprofiles
command.
- Management profile with an administrative agent server
- The basic function of
the administrative agent is to provide a single interface to administer multiple unfederated
application servers.
You 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.
Specify management
for
the -templatePath parameter and ADMIN_AGENT
for the -serverType parameter to create
this type of management profile with the manageprofiles command.
- Management profile with a job manager server
- The basic function of the job manager is to provide a single console to administer multiple base
servers, multiple deployment managers, and do asynchronous job submission.
You 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 JOB_MANAGER
for the -serverType parameter to create
this type of management profile.
Specify
management
for the -templatePath parameter and JOB_MANAGER
for the
-serverType parameter to create this type of management profile with the manageprofiles command.
- 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. You 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 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 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. 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 standalone application server node to manage the process.
You 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.
The
application server profile is created by default if you do not specify the -templatePath parameter.
You can alternatively specify default
for the -templatePath parameter on the manageprofiles command to create the application server
profile.
- Cell profile
- Use the cell profile to make applications available to the Internet or to an intranet under the
management of the deployment manager.
Creation of a cell profile generates a
deployment manager and a federated node in one iteration through the Profile Management Tool. The result is a fully functional
cell on a given system.
To create a cell profile using the manageprofiles command, you must create two portions of the
profile: the cell deployment manager portion and the cell node portion. Additionally, you can have
only one cell deployment manager and one cell node associated with each other when you create a
cell. The initial cell profile that you create with the manageprofiles command is equivalent to the cell profile you
create with the Profile Management Tool. After you
create the initial cell profile, you can create custom profiles or standalone profiles and federate
the profiles into the deployment manager.
On the manageprofiles command, specify
app_server_root/profileTemplates/cell/dmgr
for the -templatePath
parameter for the deployment manager and
app_server_root/profileTemplates/cell/default
for the
-templatePath parameter for the cell node.
On the manageprofiles command, specify
app_server_root/profileTemplates/cell/dmgr
on the -templatePath
parameter for the deployment manager and
app_server_root/profileTemplates/cell/default
on the
-templatePath parameter for the cell node. You can read about the cell profile type in the article
on creating a cell profile with the manageprofiles
command.
After you create the two portions that make up the cell
profile, you have a deployment manager and federated node. The federated node contains an
application server and the default application, which contains the snoop servlet, the HitCount
application, and the HelloHTML servlet.
- Custom profile
- Use the custom profile, which belongs to a deployment manager cell, to make applications
available to the Internet or to an intranet under the management of the deployment manager.
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.
You 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/managed
for the -templatePath
parameter to create this type of profile.
Specify
managed
for the -templatePath parameter on the manageprofiles command to create this type of profile.
- Secure proxy profile
- Use the secure proxy server to take requests from the Internet and forward them to application
servers. The secure proxy server resides in the DMZ.
Specify
secureproxy
for the -templatePath parameter on the manageprofiles command 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. You can use the
-profileName parameter with most of the scripts to enable the scripts to act on a profile other than
the default profile.
After installation, use the manageprofiles command to create a cell profile, which
consists of the deployment manager portion of the profile (dmgr) and the default portion of the
profile (default). This default portion of the profile is pre-federated into the cell that the
deployment manager manages and contains the application server (server1). If you create a different
type of profile, the default portion of the profile might be different.
The default profile name is
<profile_type><profile_number>
:
<profile_type>
is a value of AppSrv
,
Dmgr
, Custom
, AdminAgent
,
JobMgr
, or SecureProxySrv
.
<profile_number>
is a sequential number that is used
to create a unique profile name
Tip: When multiple profiles exist on a machine, certain commands require that you
specify 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. You 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 you do
not relocate
them:
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01
/opt/IBM/WebSphere/AppServer/profiles/AppSrv02
You
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 default location is in the user_data_root/profiles
directory. You can change the location in a parameter when using the command-line tool. For example,
assume that you create two profiles with host name, devhost1.
You can specify a different directory, such as
/home/QEJBSVR/profiles/myprofile
, using the -profilePath parameter of the
manageprofiles
command:
manageprofiles
-profileName myprofile
-profilePath /home/QEJBSVR/profiles/myprofile
The following directories exist within a typical profile. This example assumes
that the profile, AppSrv01, exists:
app_server_root/profiles/AppSrv01/bin
app_server_root/profiles/AppSrv01/config
app_server_root/profiles/AppSrv01/configuration
app_server_root/profiles/AppSrv01/etc
app_server_root/profiles/AppSrv01/firststeps
app_server_root/profiles/AppSrv01/installableApps
app_server_root/profiles/AppSrv01/installedApps
app_server_root/profiles/AppSrv01/installedConnectors
app_server_root/profiles/AppSrv01/installedFilters
app_server_root/profiles/AppSrv01/logs
app_server_root/profiles/AppSrv01/properties
app_server_root/profiles/AppSrv01/temp
app_server_root/profiles/AppSrv01/wstemp
The following directories exist within a typical profile. Different profile
types might include different subdirectories. This example assumes that the profile, AppSrv01,
exists and was created in the default directory:
user_data_root/profiles/AppSrv01/bin
user_data_root/profiles/AppSrv01/config
user_data_root/profiles/AppSrv01/configuration
user_data_root/profiles/AppSrv01/etc
user_data_root/profiles/AppSrv01/installableApps
user_data_root/profiles/AppSrv01/installedApps
user_data_root/profiles/AppSrv01/installedConnectors
user_data_root/profiles/AppSrv01/logs
user_data_root/profiles/AppSrv01/PolicyDirector
user_data_root/profiles/AppSrv01/properties
user_data_root/profiles/AppSrv01/temp
user_data_root/profiles/AppSrv01/wstemp