This article covers the different server types on your system as
well as other terminology used.
In WebSphere® Application
Server for z/OS®,
the functional component on which applications run is called a server.
Servers comprise address spaces that actually run code.

Within each server are two kinds of address spaces: controllers and servants.
A controller runs system authorized programs and manages tasks, such
as communication, for the server. Each server has one controller that you
start with a JCL start procedure when you enter the appropriate start command
on the MVS console.
A
servant is the address space in which the JVM resides. It runs
unauthorized programs such as business applications. Depending on the workload,
a server has one or more servants running at a time. When work builds up,
WLM dynamically starts additional servants to meet the demand.
Note: The
location service daemon and node agent are specialized servers and have no
servants. The control region adjunct (not shown in the diagrams) is a specialized
servant that interfaces with the new service integration busses to provide
messaging services.
Here is a quick breakdown of the different server types on your system:
- Unmanaged (stand-alone) application server
- The application server that was set up during stand-alone configuration
that hosts your J2EE applications.
- Managed (Network Deployment) application server
- The application server set up during Network Deployment configuration
that hosts your J2EE applications.
- Location service daemon
- A server that is the initial point of contact for client requests in either
configuration.
- JMS server
- Hosts the JMS function in the WebSphere Application Server for z/OS,
which controls the MQ broker and queue manager in either configuration. The
JMS server no longer exists as in previous versions of WebSphere Application Server for z/OS.
Its function has been replaced with new service integration busses.
- Deployment manager
- A specialized application server that hosts the administrative console
application (it hosts only administrative applications) and provides cell-level
administrative function in a Network Deployment configuration. The administrative
console application administers servers (grouped into nodes) on many different
systems. The deployment manager is the sole occupant of its own node structure
that does not need a node agent because there are no application servers in
the node, and a cell can have only one deployment manager.
Note: The version
of the administrative console application that runs in the deployment manager
is designed to manage multinode environments, whereas the version in the stand-alone
application server is for single node environments only.
- Node agent
- Provides node-level administrative function in a Network Deployment configuration.
Note: Every element of the configuration (servers,
clusters, nodes and cells) has both a long and short name:
- The "Server name" is the server long name used in the HFS path and the
principal name by which the server is known to WebSphere Application Server for z/OS.
It is used to identify the server through the administrative console and scripting.
It is a mixed case name and greater than 8 characters in length.
- The "Server short name" is the platform-specific native alias and the
principal name by which the server is known to z/OS. It is used to identify the server
to underlying z/OS facilities,
such as the Security Server, JES, WLM and ARM. For example, the server short
name is used as the MVS JOBNAME.
- The "Cluster short name" is used as the WLM application environment name.
A
cluster is a
logical grouping of like-configured servers.
Clusters exist to promote scalability and availability; workload balancing
occurs across the servers in a cluster. Clusters allow you to partition workloads
into separate servers while still referring to them as a single unit. Clustering
is typically applied to a multinode cell, where each node is configured on
a separate system and the cluster has a member (server) on each node. Client
requests are distributed among the cluster members based on workload manager
decisions.
Note: If you intend for your cluster to span multiple systems in
a sysplex, you might need to set up a shared HFS.
A node contains servers that can be part of a cluster. The cluster can
span nodes if all involved nodes are in the same cell.
Here is a quick breakdown of cells, nodes, and clusters:
- cell
- A logical collection of WebSphere Application Server for z/OS nodes that
are administered together. The cell is the largest unit of organization.
- Nodes that comprise a cell can reside on systems in the same sysplex,
differing sysplexes, on the same z/OS monoplex, or on differing systems
entirely. A cell that consists of nodes on differing systems or sysplexes
is called a heteregeneous cell.
- A z/OS sysplex
or monoplex can contain multiple WebSphere Application Server for z/OS cells.
- Different cells can have nodes on the same systems, although a given node
can be a member of only one cell.
- There are two kinds of WebSphere Application Server for z/OS cells: stand-alone
application server cells, and Network Deployment cells.
- node
- A logical collection of servers on a particular z/OS system in the cell.
- The cell to which a node belongs can span several systems, but the node
must remain within a single z/OS system.
- A z/OS system
can contain multiple WebSphere Application Server for z/OS nodes, belonging
to the same or different cells.
- A stand-alone WebSphere Application Server for z/OS cell consists
of a single node. Due to administrative constraints, this node should have
only a single application server in it.
- A Network Deployment cell consists of a deployment manager node, which
is responsible for cell-wide administrative tasks, and any number of managed
nodes. Each managed node contains a node agent, which handles communication
with the cell's deployment manager, and any number of application servers.
- cluster
- A logical collection of like-configured application servers that provides
performance, reliability and administration advantages.
- A cluster can span nodes and systems within the same cell.
- Clusters are not a layer in the cell/node/server hierarchy. Instead, they
are a way of grouping servers that host the same applications within a cell.
A cluster can span nodes and systems within the same cell.
To help you understand the interaction between servers, clusters, nodes
and cells, here is a diagram depicting various configurations you can set
up in your Network Deployment sysplex:

Cells 1 and 3 in the
illustration depict Network Deployment configuration cells. Cell 2 is a stand-alone
configuration cell.
Note: This precise node assignment does not need to apply.
The deployment manager node can exist on one system, other managed nodes (that
have been federated into the deployment manager) can exist on differing systems.
Such a configured cell of differing machines or operating systems is called
a heterogeneous cell and expands the possible topologies you can consider
for your network deployment.