[AIX Solaris HP-UX Linux Windows][z/OS]

Intelligent Management: Políticas de direccionamiento y de servicio

Se aplican dos tipos de políticas a una solicitud: direccionamiento y servicio. Puede crear políticas de direccionamiento para solicitudes HTTP y SOAP, y puede crear políticas de servicio para solicitudes HTTP, IIOP, SOAP, JMS y SIP. Asimismo, las clases de trabajo pueden contener reglas de clasificación para ambos tipos de políticas, excepto para JMS. Las reglas de clasificación no están soportadas para las clases de trabajo de JMS.

Políticas de direccionamiento válidas

Tabla 1. Políticas de direccionamiento
Política de direccionamiento Descripción
permit:nombre_aplicación

nombre_aplicación es el nombre de aplicación para direccionar con un especificador de edición opcional.

permitMM:nombre_aplicación

nombre_aplicación es el nombre de aplicación para direccionar con un especificador de edición opcional. El direccionamiento de esta forma permite a la solicitud seguir de modo habitual. Tenga en cuenta que el servidor debe estar en la modalidad de mantenimiento.

permitsticky:nombre_aplicación

La política de direccionamiento permitsticky es la misma que la política de direccionamiento permit, excepto que el direccionador On Demand (ODR) también mantiene la afinidad de cliente y servidor para futuras solicitudes que proceden del mismo cliente. En este caso, el ODR añade una cabecera SET-COOKIE a la respuesta antes de enviar la respuesta al cliente.

La acción permitsticky significa que el ODR establece de forma activa la afinidad entre el cliente y el servidor, si la afinidad no estaba establecida por la aplicación. El ODR lo lleva a cabo añadiendo SET-COOKIE: WSJSESSIONID=xx:serverID; path=webModuleContextRoot a la respuesta, si:
  • La respuesta todavía no tiene SET-COOKIE que establecerá la afinidad de servidor, y
  • La solicitud correspondiente no indica que la afinidad de servidor ya ha sido establecida.
El serverID es el identificador de servidor y también se hace referencia a éste como el ID de clon. webModuleContextRoot es la raíz del contexto del módulo web con el que está correlacionada la solicitud.
permitstickyMM:nombre_aplicación

Esta política de direccionamiento es la misma que la política de direccionamiento permit, excepto que el ODR también conserva la afinidad del cliente con el servidor para futuras solicitudes que proceden del mismo cliente. En este caso, el ODR añade una cabecera SET-COOKIE a la respuesta antes de enviar la respuesta al cliente. Tenga en cuenta que el servidor debe estar en la modalidad de mantenimiento.

reject:código_error_HTTP

Esta política de direccionamiento provoca que el ODR rechace la solicitud y devuelve el código de error HTTP especificado. Por ejemplo, reject:503 devuelve un error 503 Servicio no disponible.

reject:URL

Con esta política de direccionamiento, el ODR redirecciona la solicitud al URL especificado. El URL tiene el patrón de protocolo://URI. Un ejemplo de un URL válido es http://w3.ibm.com.

Políticas de servicio válidas

Las políticas de servicio válidas son la lista de nombres de clase de transacción. La clase de transacción hace referencia a una sola clase de servicio.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwve_odrworkclass
File name: rwve_odrworkclass.html