WebSphere Application Server for z/OS is a comprehensive and sophisticated J2EE application server platform. It integrates with the IBM's zSeries portfolio of hardware and z/OS software assets and exploits the qualities of service of the platform such as close proximity to data, intense scalability, continuous availability, failover support, and stalwart security.

Most developers working with WebSphere for z/OS today don't have IBM zSeries server experience. They'e good at J2EE and are more familiar with WebSphere on distributed platforms. This article intends to help folks understand the server architecture and workload management differences between WebSphere for z/OS and distributed platforms. We'll also discuss how to leverage the unique features in WebSphere for z/OS.

WebSphere for z/OS used to be a totally different product from WebSphere for distributed platforms before WebSphere V5. IBM has been trying hard to make them share the same code base since WebSphere V5. The products look quite similar now, but there are major differences in server architecture, installation, security, workload management, performance tuning, and problem determination. Many of the areas where they deviate let the z/OS version take advantage of qualities of service of the zSeries platform.

Defining Terms
Before we start, I would like to introduce some basic z/OS terminology.
Address Space - An address space is the area of contiguous virtual addresses that z/OS assigns to a user (or separately running program) for executing instructions and storing data. It's equivalent to a process on distributed platforms.
TCB - TCB stands for Task Control Block. It represents a task executing in an address space at any one time. A Java thread is implemented as a TCB on z/OS.
WLM - WLM is the z/OS Workload Manager.
Enclave - An enclave is a transaction or unit of work that can span multiple dispatchable units in one or more address spaces. It's equivalent to a unit of work that can cross multiple processes on a distributed platform.
Service Class - Service Class is a z/OS WLM term. It's used to group similar kinds of work with same performance goal.

WebSphere for z/OS Server Architecture
WebSphere for z/OS is equivalent to the WebSphere Network Deployment (ND) on distributed platforms. The ND architectures and concepts are same on all the platforms. The biggest difference is the server architecture. On most distributed platforms, the server is a managed process with a JVM instance. It has a J2EE Web container and an EJB container. Figure 1 depicts a server for distributed platform.

On z/OS the server is split into different address spaces. Figure 2 shows the server architecture.

There are two kinds of address spaces in the WebSphere for z/OS server: the controller and the servant. A controller region runs system-authorized programs and manages tasks such as communications for the server. A servant region is the address space equivalent to the server on a distributed platform that has a J2EE web container and an EJB container. WebSphere for z/OS server has only one control region. However it can have multiple servant regions. WebSphere for z/OS provides four types of servant regions: Normal, CPUBOUND, IOBOUND, and LONGWAIT. Each type of servant region was designed to handle different types of workloads.

Client requests (including HTTP, MDB, IIOP, etc.) arrive at the control region, which has multiple types of listeners. After receiving the requests, it works with the z/OS workload manager (zWLM) to dispatch the work to the servant regions. All the servant regions in a WebSphere for z/OS server are identical and host the same J2EE application. The granularity of the J2EE application deployment is at the server level.

The WLM Difference
zWLM is totally different from the WLM in WebSphere for distributed platform. WLM on distributed platforms is just a WebSphere service for weighting the priority of cluster members whereas zWLM is part of the z/OS. It ensures that long-running tasks don't monopolize system resources, interactive tasks execute consistent and guaranteed response times, and resources are allocated according to business goals. User requests are classified, prioritized, and allocated to system resources based on operational policies that are bound to business goals.

zWLM lets organizations specify a set of work classification rules that identify all incoming requests. These rules can be established using a variety of business-oriented parameters that include transaction names or types, specific user names or user types and time of day. The user requests are classified by the classification rules. Each work unit is assigned a service class that represents a group of work with similar performance requirements expressed in terms of a service-level goal and relative business importance. For example, a user request is classified to a service class called CBFAST, which has as a performance goal that 80% of the work should be finished in 0.5 second. The importance of the service class is 3 (a number with a value of 1 to 5 specifies the priority of the work). Besides a factor of response time, service level goals can be expressed as execution velocity or discretionary.

zWLM manages resources to meet the performance goals. If all performance goals can't be met, zWLM favors transactions and address spaces with the highest importance level. (If you want to know more about z/OS WLM, please refer to Resource 1.)

How Does the Server Work?
Let's take a look at how the WebSphere for z/OS server and zWLM work together.

When the control region starts, it connects to zWLM as a work manager. It defines the application environment that provides the start procedure name used to start the servant region. Whenever a client request arrives, the control region classifies the work request, associates it with a service class (defined in the zWLM policy), and creates an enclave for the request. Then the control region inserts the work request into the zWLM queue associated with the specified service class. At this point the application environment and the enclave token are sent to zWLM as input.

When the first request is queued to an application environment, if zWLM detects that there's no active servant region exists it will automatically start one. As workloads fluctuate, zWLM adjusts the number of servant region address spaces to reach the defined performance goal.

When a servant region starts up, it connects to the zWLM as well. It selects a work request from the specific zWLM queue and assigns it to a TCB (Java thread) for processing. At this point the TCB joins the enclave created by the control region. The enclave represents the client request processing start from the control region to the servant region and other subsystems such as DB2. Even the business logic written in a J2EE application only runs in the servant region. Since the enclave has been associated with a specific service class that's tied to a performance goal, zWLM manages the resources cross address spaces to meet the request process performance goal. Once the process finishes, the enclave is deleted.

As you might guess all the client requests sent to a J2EE application are classified before they can be processed. The business logic in the application occurs in an enclave. zWLM doesn't treat workloads in WebSphere in a special way.