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 topic. 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.
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:
- The core product files are shared product binary files that do
not change unless you install a refresh pack, a fix pack, or an interim
fix. Some log information is also updated.
The app_server_root/profiles directory
is the default directory for creating 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.
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.
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 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.
Why
and when to augment a profile
Additional release and service
stream capabilities can require you to augment existing profiles to
use the new capabilities. For instance, if you created a profile when
you first installed the product and then added a feature pack that
requires changes to the profile to take advantage of the new capabilities,
then you have to augment the profile. However, a feature pack might
also support creating a profile that is specific to the feature pack
and that already contains the capabilities needed for the feature
pack. In this situation, do not complete a separate augmentation of
the profile because the profile is automatically augmented when you
create the profile.
Although the management profile, the cell
profile, the custom profile, secure proxy profile, and the application
server profile are the available profile types, a particular feature
pack might support only a subset of these profile types to be created
or augmented with specific feature pack capabilities.
You can create an application server profile,
a cell profile, a custom profile, or a deployment manager profile
that is enabled for the Feature Pack for Service Component Architecture
(SCA). You also can augment Version 7 versions of these profiles
to add SCA capabilities. The secure proxy profile and the management
profile with a job manager server type or with an administrative agent
server type do not require augmentation.
You
can create an application server profile, a cell profile, a custom
profile, or a deployment manager profile that is enabled for the Service
Data Objects (SDO) feature of the Feature Pack for SCA. You also
can augment Version 7 versions of these profiles to add SDO capabilities.
You
can create a new profile with feature-pack functionality or augment
an existing profile with the feature pack using the manageprofiles command or
the Profile Management Tool.
Tip: You can check whether a node has been enabled with the
SDO feature of the Feature Pack for SCA so that SDO applications can
be run. When the node is started and running, use the wsadmin tool
with the getMetadataProperty AdminTask command to check the node.
For example:
AdminTask.getMetadataProperty('[-nodeName node_name -propertyName com.ibm.websphere.SDOFeatureVersion]')
If the return value is 1.0.1, the node has the SDO feature
enabled. Otherwise, nothing is returned.
Profile types
Templates
for each profile are located in the app_server_root/profileTemplates
directory unless they are feature pack templates.
Templates for the Feature Pack for SCA are located
in the app_server_root/profileTemplates/SCA 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 product can create the following types of profiles:
- Management profile with a deployment
manager server for the Feature Pack for SCA or the SDO feature
- 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.
If you want to create a deployment manager profile
that is enabled for the Feature Pack for SCA, 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/SCA/dmgr.scafep for
the -templatePath parameter.
If you want to create a deployment manager profile
that is enabled for the SDO feature of the Feature Pack for SCA, 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/SCA/dmgr.sdofep for
the -templatePath parameter.
- 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.
The management profile with an administrative
agent does not require feature-pack capability. However, you can create
the management profile with an administrative agent for the WebSphere® Application Server product and then
use the profile in a feature-pack environment.
You
can create the management profile with an administrative agent 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 ADMIN_AGENT for
the -serverType parameter to create this type of
management profile.
- 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.
The
management profile with a job manager does not require feature-pack
capability. However, you can create the management profile with a
job manager for the WebSphere Application Server, Network Deployment product
and then use the profile in a feature-pack environment.
- 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.
If you want
to create an application server profile that is enabled for the Feature
Pack for SCA, 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/SCA/default.scafep
for the -templatePath parameter.
If you want to create an application server profile
that is enabled for the SDO feature of the Feature Pack for SCA, 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/SCA/default.sdofep
for the -templatePath parameter.
- 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.
You can create a cell profile
for the Feature Pack for SCA. On the manageprofiles command,
specify app_server_root/profileTemplates/SCA/cell.scafep/dmgr
for the -templatePath parameter for the deployment
manager and app_server_root/profileTemplates/SCA/cell.scafep/default
for the -templatePath parameter for the cell node.
You can create a cell profile
for the SDO feature of the Feature Pack for SCA. On the manageprofiles command,
specify app_server_root/profileTemplates/SCA/cell.sdofep/dmgr
for the -templatePath parameter for the deployment
manager and app_server_root/profileTemplates/SCA/cell.sdofep/default
for the -templatePath parameter for the cell node.
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.
If you want to create a custom
profile that is enabled for the Feature Pack for SCA, 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/SCA/managed.scafep
for the -templatePath parameter.
If you want to create a custom profile that is
enabled for the SDO feature of the Feature Pack for SCA, 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/SCA/managed.sdofep
for the -templatePath parameter.
- 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.
The
secure proxy profile does not require feature pack capability. However,
you can create the secure proxy profile for the WebSphere Application Server, Network Deployment product and
then use the profile in a feature pack environment.
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/secureproxy
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. 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.
![[AIX Solaris HP-UX Linux Windows]](../../dist.gif)
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
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]](../../dist.gif)
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
![[AIX Solaris HP-UX Linux Windows]](../../dist.gif)
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/samples
- app_server_root/profiles/AppSrv01/temp
- app_server_root/profiles/AppSrv01/wstemp