Message-driven beans and tuning settings on z/OS

When you are running WebSphere® Application Server on the z/OS® operating system, you need to understand a number of concepts to be able to configure the tuning settings that are available for message-driven beans.

WebSphere Application Server on z/OS: a multi-process server

When you are running WebSphere Application Server on z/OS the workload is distributed across several types of regions (processes), as shown in the following diagram.

A WebSphere Application Server installation has a control region (CR), a control region adjunct (CRA), and several servant regions (SR). The inbound workload excluding service integration enters the control region and is distributed to the servant regions. The inbound workload for service integration enters the control region adjunct and is routed through the control region to the servant regions. The control region adjunct contains several messaging engines. The applications running in the servant region communicate with the messaging engines in the control region adjunct. — Figure 1. WebSphere Application Server running on z/OS has a multi-process structure

The control region (also known as the controller): The control region (CR) runs system code and is the communication endpoint for all inbound workload (for example, IIOP, HTTP) except service integration bus inbound workload. The CR classifies the workload and then uses the z/OS workload management function (WLM) to distribute the workload across the servant regions.

The control region adjunct (also known as the adjunct)

The following processes run in the control region adjunct (CRA):

Service integration bus messaging engines
The service integration bus resource adapter (RA)
From WebSphere Application Server Version 7.0 onwards, the IBM MQ Resource Adapter

The CRA is the communication endpoint for service integration inbound workload (that is, for message-driven beans and mediations). This workload is routed through the CR for classification and distribution. If there are multiple messaging engines in the server, they will all run in the same CRA. If there are no messaging engines in the server, the CRA is still required in order to run service integration inbound resource adapters. If service integration support is disabled for the server there is no CRA, but if you are using the IBM MQ Resource Adapter in this situation, you need to start the CRA explicitly as described in JMS provider settings.

Servant regions (also known as servants): Application code (for example, Enterprise Java™ Beans (EJBs), message-driven beans, servlets) runs in the servant regions (SRs). You can configure the server to run with only one servant, but more usually you configure it with multiple servants. z/OS WLM can adjust the number of SRs dynamically in response to varying workload.

The section Workload management classification for message-driven beans explains how workload is distributed between the servants to optimize performance.

WebSphere Application Server messaging providers

Messaging flow depends on how you install your message-driven bean application, which is determined by your choice of messaging provider.

Note: The same messaging provider can provide different deployment methods.

WebSphere Application Server on z/OS supports the following messaging providers:

WebSphere Application Server default messaging provider

The default messaging provider (service integration) supports the Java Connector Architecture (JCA) RA. When you install a message-driven bean application you provide an activation specification.

IBM MQ messaging provider

The IBM MQ messaging provider uses your IBM MQ system as the provider, and it supports the following methods of installing message-driven bean applications:

JCA, by using the RA
Application Server Facilities (ASF), by using the message listener service and message listener ports

JCA is the strategic Java EE technology and is preferred to the older ASF technology, which is deprecated in WebSphere Application Server from Version 7.0 onwards.

Third-party messaging providers that include the optional ASF extensions to the JMS specification

To use a third-party ASF messaging provider, you add it to the WebSphere Application Server configuration as a JMS provider. In the administrative console, you navigate to Resources > JMS > JMS providers.

Third-party messaging providers that include a JCA compliant resource adapter (RA)

To use a third-party JCA messaging provider, you install the JCA resource adapter archive (RAR) in the WebSphere Application Server. In the administrative console, you navigate to Resources > Resource Adapters > Resource adapters.

Note: The same WebSphere Application Server can use multiple, different messaging providers.

Workload management on z/OS

A message-driven bean typically runs on an application server that hosts a heterogeneous workload, including the following types of work:

Other message-driven beans
Enterprise beans accessed through IIOP
Servlets and JSPs that are accessed through HTTP

There are various tuning controls associated with message-driven beans, and their settings provide fine-grained control over the amount of message-driven bean work performed for a given message-driven bean (or set of message-driven beans) in a given server. However, do not use these settings to prioritize message-driven bean work in relation to other work in the server. Instead, to manage a heterogeneous workload on z/OS, use workload management (WLM) classification.

Workload management classification for message-driven beans

Message-driven processing comprises two logical functions:

Listening, which examines each message as it arrives, determines security and transactional context for the message, and identifies the message-driven bean to process it.
Dispatching, which gets the message and activates the onMessage method of the message-driven bean.

These functions are controlled by classifying workload for WLM.

There are two parts to classifying WebSphere Application Server workload for management by WLM when running WebSphere Application Server on z/OS:

Determining an appropriate transaction class for the work item: WebSphere Application Server uses rules that the WebSphere Application Server administrator specifies in an XML document known as the Workload classification file to classify individual workload items into a manageable set of transaction classes that can be given different performance goals. Transaction classes are groupings that you choose: you decide how many classes there are, and what names they have. The WebSphere Application Server administrator specifies the path to the workload classification file by using WebSphere Application Server administration functions.
When WebSphere Application Server receives an HTTP, IIOP, or message-driven bean work request, it determines an appropriate transaction class for the work item. For message-driven bean work, the transaction class is typically determined from the originator of the inbound message, the message attributes, and the target message-driven bean. When WebSphere Application Server uses z/OS WLM to pass WebSphere Application Server work requests from the CR (or CRA) to an SR, WebSphere Application Server specifies the transaction class that it has selected for the work item.

Allocating appropriate resources to process the work item: The z/OS WLM administrator uses the WLM ISPF panels to specify an appropriate WLM service class and report class for each transaction class, as described in the z/OS Internet Library. WLM maps the transaction class onto the appropriate WLM service class and report class to allocate your performance goals. These goals (which are relative to the total workload on z/OS – not just the WebSphere Application Server workload) are achieved by deciding which servant should process the message, and whether to divert extra resources to or from that servant.

For more information about workload management classification, see Classifying z/OS workload.

To classify service integration work in the workload classification document for the z/OS® WLM, refer to Workload classification file.

Messaging flow for message-driven beans

Messaging flow depends on the deployment methods that you use for your message-driven beans, and the messaging provider that WebSphere Application Server is using. The subtopics describe messaging flow for various deployment methods:

Service integration in JCA mode
WebSphere MQ in JCA mode
WebSphere MQ in ASF mode

For simplicity the subtopics assume that your server hosts a single message-driven bean, and that several message-driven bean instances might be running simultaneously on all servant worker threads.