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.
- 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 WebSphere MQ RA
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
RAs. If service integration support is disabled for the server there
is no CRA, but if you are using the WebSphere MQ
RA in this situation, you need to start the CRA explicitly as described
in WebSphere MQ CRA 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
For WebSphere Application Server Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. You should plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, you should not begin this migration until you are sure the application does not have to work on application servers earlier than WebSphere Application Server Version 7. For example, if you have an application server cluster with some members at Version 6.1 and some at Version 7, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to Version 7.
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.
- WebSphere MQ messaging provider
- The WebSphere MQ messaging provider uses your WebSphere 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 .
- 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 .
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. 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 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.
For simplicity the following topics, which describe messaging flow
for various deployment methods, 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.