RAS granularity for HTTP, IIOP, MDB, and optimized local adapter requests

(zos)
RAS granularity for HTTP, IIOP, MDB, and optimized local adapter requests

Reliability Availability and Serviceability (RAS) granularity is the ability to assign different RAS attribute values to different sets of requests within the same application server. We can improve the reliability, availability, and serviceability of the application server and the requests it processes using the finely grained RAS granularity capabilities introduced in version 8.0 of the product.
The application server applies a set of RAS attributes to all the requests it processes. RAS attributes affect the reliability, availability, and serviceability of the server and the requests. Examples of RAS attributes include timeout values, timeout actions, trace settings, and so on.
RAS granularity is the ability to assign different sets of RAS attribute values to different sets of requests. The fineness of RAS granularity depends on how uniquely the application server can distinguish one set of requests from another. Before v8.5 of the product, RAS granularity was limited to a per-server basis or, for a few RAS attributes, a per-protocol basis.
Per-server RAS granularity means that a single set of RAS attribute values is defined in the server configuration. This single set of RAS attribute values applies to all requests that the application server processes. An example of a per-server RAS attribute is the trace setting. We can define only one trace setting to an application server. This trace setting applies to all requests that the application server processes.
Per-protocol RAS granularity means that multiple sets of RAS attribute values can be defined in the server configuration, one set for each protocol. The application server divides requests into sets based on the request protocol, such as the HTTP protocol or the IIOP protocol. The application server then applies the set of RAS attribute values defined for that protocol to the requests for that protocol. An example of a per-protocol RAS attribute is the dispatch timeout. We can define the dispatch timeout for IIOP requests using the control_region_wlm_dispatch_timeout property and for HTTP requests using the protocol_http_timeout_output property.
Start with v8.5 of the product we can achieve finer RAS granularity by defining RAS attribute values on a per-workload-classification basis. Per-workload-classification RAS granularity means multiple sets of RAS attribute values can be defined in the server configuration, one for each workload classification element in the workload classification file. The application server classifies requests based on the workload classification elements defined in the workload classification file. The application server then applies the set of RAS attribute values defined for a workload classification element to the requests that are classified under that workload classification element.
The fineness of RAS granularity that a per-workload-classification scheme achieves depends on how granular the application server can classify requests. The application server classifies a request using various attributes of the request. The following list gives examples of how granular the application server classifies requests.

For HTTP requests, the application server can classify requests as granular as the specific uniform resource identifier (URI).
The application server can assign a unique set of RAS attribute values to HTTP requests on a per-URI basis.

For IIOP requests, the application server can classify requests as granular as the specific EJB method being invoked.
The application server can assign a unique set of RAS attribute values to IIOP requests on a per-EJB-method basis.

For optimized local adapter requests, the application server can classify requests as granular as the service name or JNDI home name of the EJB application to be driven.
The application server can assign a unique set of RAS attribute values to optimized local adapter requests on a per-service name or a per-JNDI home name basis.

For MDB requests, the application server can classify requests as granular as the selector clause in the MDB deployment descriptor.
The application server can assign a unique set of RAS attribute values to MDB requests on a per-selector basis.

Related tasks

Enable request-level Reliability Availability and Serviceability (RAS) granularity