Types of profiles
The WAS installation process simply lays down a set of core product files required for the runtime processes. After installation, create one or more profiles that define the run time to have a functional system. The core product files are shared among the runtime components defined by these profiles.
WAS V8.5 introduces a new type of an application server profile called the Liberty profile.
Application server profile
The application server profile defines a single stand-alone application server. Using this profile gives you an application server that can be run in unmanaged (stand-alone) mode or managed mode (by federating it with the administrative agent profile). The environment has the following characteristics:
- The profile consists of one cell, one node, and one server. The cell and node are not relevant in terms of administration, but you see them when you administer the server through the dmgr console scopes.
- The server uses a dedicated, built-in dmgr console.
The primary uses for this type of profile are:
- To build a stand-alone server using the Base or Express installation packages.
- To build a stand-alone server in a ND installation not managed by the deployment manager (a test machine, for example).
- To build a server in a distributed server environment to be later federated and managed by the deployment manager. When you federate this node, the default cell becomes obsolete, the node is added to the deployment manager cell, and the dmgr console is removed from the application server.
Deployment manager profile
The deployment manager profile defines a deployment manager in a distributed server environment. Although we can conceivably have the ND edition and run only stand-alone servers, this action bypasses the primary advantages of ND, which is workload management, failover, and central administration.
In a ND environment, create one deployment manager profile for each cell.
This setup gives you:
- A cell for the administrative domain
- A node for the deployment manager
- A deployment manager with an dmgr console
- No application servers
After we have the deployment manager, we can:
- Federate nodes built either from existing application server profiles or custom profiles.
- Create new application servers and clusters on the nodes from the dmgr console.
Custom profile
A custom profile is an empty node without any server instance intended for federation to a deployment manager. After federation, the deployment manager uses it as a target on which it can create, for example, application server profile instances.
Cell profile
A cell profile combines two profiles: a deployment manager profile and an application server profile. In this case, the deployment manager and application server reside on the same system, and the application server profile is already federated to the deployment manager cell.
Using this type of profile is a good way to quickly set up a distributed server environment. It can be useful for test environments that can have all nodes on one test system.
Administrative agent profile
The administrative agent profile provides enhanced management capabilities for stand-alone application servers. An administrative agent profile is created on the same node as the stand-alone servers and can manage only servers on that node. The node configuration for each stand-alone server is separate from any other servers on the system, but it is managed using the dmgr console on the administrative agent. When a base application server registers with an administrative agent, much of the administrative code that was in the base server is now consumed by the administrative agent.
Job manager profile
A job manager is defined by a job manager profile. The job manager's primary purpose is to...
- support flexible management of WAS profiles
- queue jobs to registered servers.
For stand-alone application servers, to participate in flexible management, first they are registered with the administrative agent. After that, the administrative agent registers the node for the application server with the job manager.
If a deployment manager wants to participate in an environment controlled by a job manager, the deployment manager registers directly with the job manager. No administrative agent is involved in this case.
The new Liberty profile can also participate in the flexible management. Using job manager, it can be installed and managed just like the stand-alone profile.
Both the deployment manager and administrative agents retain autonomy and can be managed without the job manager. A job manager can submit jobs to one or more administrative agents or deployment managers, and an administrative agent or a deployment manager can register with more than one job manager, if desired.
The units of work that are handled by the flexible management environment are known as jobs. The semantics of these jobs are typically straightforward and require few parameters.
The jobs are processed asynchronously and can have an activation time, expiration time, and a recurrence indicator. We can also specify to send an email notification upon completion of a job. Additionally, we can view the current status of a job by issuing a status command.
