![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Visión general de la prioridad del flujo de solicitudes IIOP y JMS
La priorización del flujo de solicitudes IIOP (Internet Inter-ORB Protocol) y Java™ Message Service (JMS) se consigue con los gestores autónomos que controlan el flujo de solicitudes, la priorización de solicitudes y la gestión de carga de trabajo dinámica. Sólo las solicitudes IIOP procedentes de un cliente EJB (Enterprise JavaBeans) autónomo las prioriza el flujo de solicitudes autónomo IIOP de Intelligent Management. Las solicitudes IIOP procedentes de clientes EJB incrustados dentro de un servlet, un servicio web u otro EJB, no se priorizan. Este comportamiento existe porque asociado a la mima solicitud de usuario general no debe priorizarse en varios niveles, como el nivel web y el nivel de EJB. Sin embargo, dada la naturaleza asíncrona de JMS, no existe ninguna restricción sobre dónde se originan las solicitudes.
Para IIOP y JMS, los procesos del servidor de aplicaciones de fondo que alojan las aplicaciones ejecutan las pasarelas del gestor de flujo de solicitudes autónomo (ARFM). Estas pasarelas ARFM priorizan el flujo de solicitudes. Los flujos de solicitudes se gestionan para lograr un rendimiento equilibrado óptimo, teniendo en cuenta las políticas de servicio configuradas y la carga ofrecida.
Con Intelligent Management, puede definir los objetivos de rendimiento y enlazarlos a subconjuntos específicos del tráfico de entrada. El ARFM y los gestores autónomos asociados pueden dar soporte a objetivos empresariales en momentos de una alta carga tomando decisiones inteligentes relacionadas con el trabajo que entra en los servidores de aplicaciones. No todo el trabajo de la configuración se crea igual. El ARFM permite dar soporte a este concepto remitiendo distintos flujos de solicitudes para su ejecución más o menos rápidamente para obtener el mejor resultado equilibrado.
Una política de servicio es una categorización definida por un usuario que se asigna a un trabajo potencial como un atributo leído por ARFM. Para IIOP, puede utilizar una política de servicio para clasificar solicitudes basadas en atributos de solicitudes, incluido el nombre de aplicación, el nombre de método EJB, el nombre de módulo EJB, por ejemplo, el archivo jar de EJB y el nombre de EJB. Para JMS, puede realizar la clasificación basándose en el nombre de destino, ya sea tema o cola. Al configurar las políticas de servicio, se aplicarán distintos niveles de importancia al trabajo real. Puede utilizar varias políticas de servicio para entregar servicios diferenciados a distintas categorías de solicitudes. Los objetivos de la política de servicio pueden diferir en los destinos de rendimiento y también en la importancia.
El ARFM existe en el proceso del servidor de aplicaciones y controla la prioridad de las solicitudes. El gestor de flujo de solicitudes autónomo consta de dos partes: un controlador y una pasarela. La función de ARFM la implementa, para cada célula, un controlador más una colección de pasarelas en los servidores de aplicaciones. Las pasarelas interceptan y ponen en cola las solicitudes IIOP de entrada, mientras que el controlador proporciona las señales de control, o indicaciones, a las pasarelas y al controlador de ubicación. El ARFM también incluye el perfilador de trabajo, que calcula las características de carga de cálculo de los distintos flujos de solicitudes. El funcionamiento conjunto de estos componentes permite establecer correctamente las prioridades de las solicitudes de entrada.
La gestión de carga de trabajo dinámica (DWLM) es una característica que aplica los mismos principios que la gestión de carga de trabajo (WLM) como, por ejemplo, el direccionamiento basado en un sistema de peso, que establece un sistema de direccionamiento priorizado. DWLM es un complemento opcional que añade los valores autónomos de los pesos de direccionamiento a WLM. Con WLM, establezca manualmente pesos estáticos en la consola administrativa. Con DWLM, el sistema puede modificar dinámicamente los pesos para que se mantengan actualizados con los objetivos de la empresa. DWLM se puede concluir. Si tiene pensado utilizar las modalidades operativas automáticas para los componentes de operaciones dinámicas, al establecer un peso estático de WLM en alguno de los clústeres dinámicos podría impedir que la función on demand del producto opere con normalidad. Para IIOP, estos pesos son consumidos por el WebSphere EJB WLM base y se incluyen factores como donde se direccionan las nuevas solicitudes de cliente EJB, tal como se indica en el diagrama siguiente:

DWLM no influye en el tráfico JMS. Los destinos mostrados en la siguiente figura se pueden ejecutar en el mismo proceso gestionado de WebSphere o en un proceso gestionado diferente de WebSphere.

Como muestra el diagrama anterior, la cantidad de flujo de solicitudes de entrada en el servidor de aplicaciones es la misma, pero después de clasificar el trabajo, se asignan prioridades y se pone en cola, un volumen elevado del trabajo más importante se envía a proceso mientras que un volumen menor de trabajo Bronce menos importante espera a ponerse en cola. Sin embargo, sólo porque el trabajo de prioridad más baja es el que más se demora, esto no hace que la velocidad media a largo plazo del trabajo Bronce que se ejecuta en el servidor de aplicaciones sea menor que la velocidad media a largo plazo de Bronce entrante. En la práctica, las funciones de las operaciones dinámicas intentarán mantener el trabajo dentro del tiempo asignado para su finalización.