Overview of IIOP and JMS request flow prioritization
Internet Inter-ORB Protocol (IIOP) and Java Message Service (JMS) request flow prioritization is achieved with the autonomic managers that control the flow of requests, prioritization of requests, and dynamic workload management. Only IIOP requests from a stand-alone EJB client are prioritized by Intelligent Management IIOP autonomic request flow management (ARFM). IIOP requests from EJB clients embedded within a servlet, a web service, or another EJB are not prioritized. This behavior exists because traffic associated with the same overall user request must not be prioritized at multiple tiers, such as the Web tier and EJB tier. However, given the asynchronous nature of JMS, no restrictions exist on where the requests originate.
For IIOP and JMS, the back-end application server processes that are hosting the applications run the autonomic request flow manager (ARFM) gateways. These ARFM gateways prioritize request flow. The request flows are managed to achieve the best balanced performance results, considering the configured service policies and the offered load.
With Intelligent Management, we can define performance goals and bind them to specific subsets of the incoming traffic. The ARFM and associated autonomic managers are able to support business goals in times of high load by making smart decisions about the work coming into the application servers. Not all work in our configuration is created equal. The ARFM is able to support this concept by forwarding different flows of requests on for execution more or less quickly to achieve the best balanced result.
The ARFM is aware of its environment because of a component called an on demand configuration (ODC). The ODC automatically gets information about all the Intelligent Management application servers and applications that are deployed in the cell, and any service policy and work classes associated with those configuration artifacts.
The ODC cannot read environments other than a homogeneous Intelligent Management environment.
A service policy is a user-defined categorization assigned to potential work as an attribute that is read by the ARFM. For IIOP, we can use a service policy to classify requests based on request attributes, including the application name, EJB method name, EJB module name, such as the EJB jar file, and the EJB name. For JMS, we can classify based on destination name, either topics or queues. By configuring service policies, you apply varying levels of importance to the actual work. We can use multiple service policies to deliver differentiated services to different categories of requests. Service policy goals can differ in performance targets and importance.
The ARFM exists in the application server process and controls request prioritization. The autonomic request flow manager contains two parts: a controller and a gateway. The ARFM function is implemented, for each cell, by a controller plus a collection of gateways in the application servers. The gateways intercept and queue the incoming IIOP requests, while the controller provides control signals, or directions, to the gateways, and the placement controller. The ARFM also includes the work profiler, which estimates the computational load characteristics of the different flows of requests. Working together, these components can properly prioritize incoming requests.
Dynamic workload management (DWLM) is a feature that applies the same principles as workload management (WLM), such as routing based on a weight system, which establishes a prioritized routing system. DWLM is an optional add-on that adds autonomic setting of the routing weights to WLM. With WLM, manually set static weights in the console. With DWLM, the system can dynamically modify the weights to stay current with the business goals. DWLM can be shut off. If we intend to use the automatic operating modes for the components of dynamic operations, then setting a static WLM weight on any of your dynamic clusters might get in the way of allowing the on demand aspect of the product to function properly. For IIOP, these weights are consumed by base WebSphere EJB WLM and factor to where new EJB client requests are directed, as shown in the following diagram:
Figure 1. IIOP flow
DWLM does not influence JMS traffic. The destinations shown in the following figure can be running in the same WebSphere Managed process or a different WebSphere Managed process.
Figure 2. JMS flow
As the previous diagrams depicts, an equal amount of requests flow into the application server, but after the work is categorized, prioritized, and queued, a higher volume of more important Platinum work is sent to be processed while a lower volume of less important Bronze work waits to get queued. However, just because the lower priority work is delayed the most, that does not make the long-term average rate of Bronze work that runs in the application server less than the long-term average rate of Bronze requests that come in. In the end, the features of the dynamic operations attempt to keep the work within the target time allotted for completion.
Subtopics
- (dist)(zos) JMS support in the Intelligent Management environment
Intelligent Management extends the dynamic operations environment to Java Message Service (JMS) by providing the capability to categorize and prioritize JMS messages. JMS messages can be classified by destination, that is, topic or queue. Service policies can be defined to prioritize messages differently based on the destination name.
Related tasks