WebSphere Virtual Enterprise, Version 6.1.1
             Sistemas operativos: AIX, HP-UX, Linux, Solaris, Windows,


Políticas de direccionamiento y 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álido

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 consigue 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 ID de servidor 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 redirección 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 hará referencia a una sola clase de servicio.




Tareas relacionadas
Definición de política de servicio
Establecimiento de la modalidad de mantenimiento
Activación de ediciones simultáneas
Validación de ediciones
Referencia relacionada
Operandos del creador de subexpresiones para políticas de direccionamiento y de servicio
Información relacionada
Reglas para las tareas administrativas de política de direccionamiento de ODR
Reglas para las tareas administrativas de política de servicio de ODR
Tema de referencia    

Condiciones de uso | Comentarios

Última actualización: 22-sep-2009 09H39' EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/odoe_task/rodrworkclass.html