![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Profile concepts
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 設定檔管理工具 graphical
user interface. You can use the 設定檔管理工具 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 設定檔管理工具 does not provide
a deletion function. You can use either the 設定檔管理工具 or the manageprofiles command
to create a cell profile. The 設定檔管理工具 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.
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 設定檔管理工具 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 設定檔管理工具 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 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 設定檔管理工具 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.
- 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 設定檔管理工具 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.
- 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 設定檔管理工具 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.
- 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 設定檔管理工具 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.
- 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
設定檔管理工具. 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
設定檔管理工具. 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.
- 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 設定檔管理工具 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.
- 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, you should 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Addressing a profile in a multiprofile environment: 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
/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.
![[IBM i]](../images/iseries.gif)
manageprofiles
-profileName myprofile
-profilePath /home/QEJBSVR/profiles/myprofile
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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:
![[IBM i]](../images/iseries.gif)