Overview of IIOP and JMS request flow prioritization
IIOP and JMS request flow prioritization is achieved in WebSphere® Virtual Enterprise with the autonomic managers that control the flow of requests, prioritization of requests, and dynamic workload management. Only IIOP requests from a standalone EJB client are handled by WebSphere Virtual Enterprise IIOP request flow prioritization. EJB calls from servlets for example, are not prioritized. This limitation exists because the system cannot prioritize at multiple tiers, such as the web tier and EJB tier, requests associated with the same overall user request. However, given the asynchronous nature of JMS, there are no restrictions on where the requests originate.
For IIOP and JMS, the back-end application server processes hosting the applications run the autonomic request flow manager (ARFM) gateways, which perform the request flow prioritization function. The request flows are managed to achieve the best balanced performance results, considering the configured service policies and the offered load.
With WebSphere Virtual Enterprise, you 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 your 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 WebSphere Virtual Enterprise application servers and applications that are deployed in the cell, and any service policy and work classes associated with those configuration artifacts. Note: The ODC cannot read environments other than a homogeneous WebSphere Virtual Enterprise environment.
A service policy is a user-defined categorization that is assigned to potential work as an attribute that is read by the ARFM. For IIOP, you 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, you can classify based on destination name, either topics or queues. By configuring service policies, you apply varying levels of importance to the actual work. You 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 administrative console. With DWLM, the system can dynamically modify the weights to stay current with the business goals. DWLM can be shut off. If you 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 WebSphere XD to function properly. For IIOP, these weights are consumed by base WebSphere EJB WLM and factor to where new EJB client requests are directed and factor to where new EJB client requests are directed and it follows:
DWLM has no bearing on JMS traffic and it is shown in Figure 2 and the destinations shown in the figure can be running in the same WebSphere Managed process or a different WebSphere Managed process.
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 executed in the application server less than the long-term average rate of Bronze coming in. In the end, the features of the dynamic operations attempt to keep the work within the target time allotted for completion.
Related tasks
Defining a service policy