+

Search Tips   |   Advanced Search

(zos)

Message-driven beans and tuning settings on z/OS

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


WAS on z/OS: a multi-process server

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

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):

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 WebSphere MQ Resource Adapter in this situation, we need to start the CRA explicitly as described in (zos) 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). We 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 the message-driven bean application, which is determined by the choice of messaging provider.

The same messaging provider can provide different deployment methods.

WAS 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.

WebSphere MQ messaging provider

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

  • JCA, using the RA

  • Application Server Facilities (ASF), 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, we add it to the WAS configuration as a JMS provider. In the 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 WAS. In the console, you navigate to Resources > Resource Adapters > Resource adapters.

The same WAS 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:

  1. Other message-driven beans

  2. Enterprise beans accessed through IIOP

  3. 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:

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 WAS on z/OS:

Determine an appropriate transaction class for the work item

WAS uses rules that the WAS administrator specifies in an XML document known as the (zos) 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 WAS 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. z/OS WLM maps the transaction class onto the appropriate WLM service class and report class to allocate the performance goals. These goals (which are relative to the total workload on z/OS - not just the WAS 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 (zos) Classifying z/OS workload.

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


Messaging flow for message-driven beans

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

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


Subtopics


Related tasks

(zos) Tune message-driven bean processing on z/OS by using WebSphere MQ as the messaging provider in ASF mode

(zos) Optimizing MDB throttle support for debugging in z/OS