+

Search Tips   |   Advanced Search

(ZOS) Message-driven beans and tuning settings on z/OS

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


WAS on z/OS: a multi-process server

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

Figure 1. WAS 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 WAS 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 we are using the IBM 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 we 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.


WAS messaging providers

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

The same messaging provider can provide different deployment methods.

WAS on z/OS supports the following messaging providers:

WAS default messaging provider

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

IBM MQ messaging provider

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

JCA is the strategic Java EE technology and is preferred to the older ASF technology, which is deprecated in WAS from v7.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 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, we install the JCA resource adapter archive (RAR) in the WAS. In the administrative 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 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 WAS workload for management by WLM when running WAS on z/OS:

Determining 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 chosen: we decide how many classes there are, and what names they have. The WAS administrator specifies the path to the workload classification file using WAS administration functions.

When WAS 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 WAS work requests from the CR (or CRA) to an SR, WAS 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 your 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 we use for our message-driven beans, and the messaging provider that WAS 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

  • (ZOS) Tune message-driven bean processing on z/OS using IBM MQ as the messaging provider in ASF mode
  • (ZOS) Optimizing MDB throttle support for debugging in z/OS