WebSphere Application Server for z/OS terminology

Become familiar with the z/OS terminology that is required when using WebSphere® Application Server for z/OS®.

In WebSphere Application Server for z/OS, the functional component on which applications run is a server. The following diagram shows a z/OS server running two J2EE applications:

Servers comprise address spaces that run code. A z/OS server has two types of address space: 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 Java Virtual Machine (JVM) resides. A servant runs unauthorized programs such as business applications. A server can have one or more servants running at a time, depending on the workload. When work builds up, Work Load Manager (WLM) dynamically starts additional servants to meet the demand.
Note: The control region adjunct (not shown in the diagram) is a specialized servant that interfaces with service integration busses to provide messaging services.

The following types of server can be present on a z/OS system:

Unmanaged (standalone) application server: This application server is set up during standalone configuration to host your J2EE applications.
Managed (Network Deployment) application server: This application server is set up during Network Deployment configuration to host your J2EE applications.
Location service daemon: This server is the initial point of contact for client requests in either standalone or Network Deployment configuration. The location service daemon is a specialized server that have no servants.
JMS server: This server hosts the JMS function in WebSphere Application Server for z/OS, which controls the MQ broker and queue manager in either standalone or Network Deployment configuration. The JMS server no longer exists as in previous versions of WebSphere Application Server for z/OS. Its function has been replaced with service integration busses.
Deployment manager: This is 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. It does not need a node agent because there are no application servers in the node, and a cell can have only one deployment manager.
The version of the administrative console application that runs in the deployment manager is designed to manage multi-node environments, whereas the version of the administrative console application that runs in the standalone application server is for single node environments only.
Node agent: A node agent provides node-level administrative function in a Network Deployment configuration. A node agent is a specialized server that has no servants.

A node can contain servers that are part of a cluster. The cluster can span nodes if all the involved nodes are in the same cell.

cluster

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 your cluster to span multiple systems in a sysplex, you might need to set up a shared HFS.

node

A node is a logical collection of servers on one particular z/OS system.

A node belongs to one 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 that belong to the same or different cells.

cell

A cell is 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 heterogeneous 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 cell:
- A standalone 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 federated nodes. Each federated node contains a node agent, which handles communication with the cell's deployment manager, and any number of application servers.

administrative agent

An administrative agent provides a single interface to administer multiple unfederated WebSphere Application Server for z/OS nodes in environments such as development, unit test, or that portion of a server farm that resides on a single machine.

Every element of the configuration (servers, clusters, nodes and cells) has both a long and short name:

Server name: This is the 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 longer than 8 characters.
Server short name: This 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, Job Entry Subsystem (JES), WLM and Application Response Management (ARM). For example, the server short name is used as the MVS JOBNAME.
Cluster short name: This is used as the WLM application environment name.

The following diagram illustrates the interaction between servers, clusters, nodes and cells. It shows various configurations that you can set up in a Network Deployment sysplex:

Configurations of WebSphere Application Server for z/OS

Cells 1 and 3 illustrate Network Deployment configuration cells. Cell 2 is a standalone configuration cell.

Node assignments can vary according to your requirements. The deployment manager node can exist on one system while other nodes that have been federated into the deployment manager can exist on different systems. Such a configured cell comprising differing machines or operating systems is called a heterogeneous cell and expands the possible topologies you can consider for your network deployment.