Una clase de trabajo se utiliza para clasificar peticiones para aplicar una política a la petición. Existen dos tipos de políticas que se aplican a una petición: direccionamiento y servicio. Puede crear políticas de direccionamiento para las peticiones HTTP y SOAP. Puede crear políticas de servicio para las peticiones HTTP, IIOP, SOAP y JMS. Asimismo, las clases de trabajo pueden contener normas de clasificación para ambos tipos de políticas, excepto para JMS. Las normas de clasificación no están soportadas para las clases de trabajo JMS. Las políticas de direccionamiento y de servicio de las clases de trabajo no están soportadas para IIOP y JMS para las aplicaciones desplegadas en z/OS. WebSphere Application Server z/OS proporciona la clasificación de servicios IIOP y JMS.
Política de direccionamiento | Descripción |
---|---|
permit:<nombre_aplicación> | En esta política de direccionamiento, nombre_aplicación es el nombre de la aplicación a la que direccionar con un especificador de edición opcional. Esto permite que la petición siga del modo habitual. |
permitsticky:<nombre_aplicación> | La política de direccionamiento permitsticky es la misma que la política de direccionamiento permit, salvo que el direccionador On Demand (ODR) también mantiene afinidad de cliente a servidor para todas las peticiones futuras 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. |
reject:<código_error_HTTP> | Esta política de direccionamiento hace que el ODR rechace todas las peticiones que tengan el código de error HTTP especificado. Por ejemplo, reject:503 devuelve un error 503 Servicio no disponible. |
redirect:<URL> | Con esta política de direccionamiento, el ODR redirecciona la redirección al URL especificado. El URL tiene el patrón protocolo:// ;. Un ejemplo de un URL válido es: http://w3.ibm.com. |
Las políticas de servicio válidas son simplemente la lista de nombres de clase de transacción. La clase de transacción hará referencia a una sola clase de servicio.
Hay cuatro tipos de clases de trabajo:
Clase de trabajo | Descripción |
---|---|
Política de direccionamiento de aplicaciones | Especifica cómo determinar la política de direccionamiento para una petición dirigida a una aplicación instalada en WebSphere Extended Deployment. |
Política de servicio de aplicaciones | Especifica cómo determinar la política de servicio para una petición dirigida a una aplicación que está instalada en WebSphere Extended Deployment. |
Política de direccionamiento de clústeres de servidor genérico | Específica cómo determinar la política de direccionamiento para una petición dirigida a un clúster de servidores genérico. |
Política de servicio de clústeres de servidor genérico | Especifica cómo determinar la política de servicio para una petición dirigida a un clúster de servidores genérico. |
El siguiente diagrama ilustra el flujo de una petición dirigida a una aplicación que está instalada en WebSphere Extended Deployment. La petición se aplica a una clase de trabajo de política de direccionamiento de aplicaciones para determinar la política de direccionamiento. Si la política de direccionamiento resultante es permit o permitsticky, la petición continúa hasta una clase de trabajo de política de servicio de aplicaciones para determinar la política de servicio y el nombre de clase de transacción.
Cada aplicación contiene clases de trabajo por omisión de política de direccionamiento de aplicaciones y de política de servicio de aplicaciones. También puede crear clases de trabajo no por omisión adicionales. Cada clase de trabajo tiene una acción coincidente por omisión. La política de direccionamiento por omisión para una aplicación es permit:<nombre_aplicación>. La política de servicio por omisión es Default_TC, la clase de transacción por omisión.
Cada clase de trabajo contiene una lista opcional ordenada de normas que se evalúan para una petición concreta para determinar la política de dicha petición. Cada norma consta de una expresión booleana y un valor de política. Si la expresión se evalúa en true para una petición concreta, se utiliza la política asociada a dicha norma.
La sintaxis y la semántica de una expresión booleana correspondiente a una norma son parecidas a la cláusula WHERE de una expresión de lenguaje de consulta estructurado (SQL). De forma más precisa, la sintaxis de una expresión se define mediante la especificación JMS (Java Message Service 1.1). Consulte Clasificación de peticiones basadas en normas de ODR para obtener más información.
En la especificación JMS, los identificadores hacen referencia a distintos atributos que pueden asociarse a una petición, por ejemplo, un determinado parámetro de consulta, cookie o cabecera HTTP. Un identificador JMS se puede considerar como si fuera una variable de petición o un operando. Estos operandos pueden ser específicos para un protocolo. Por ejemplo, el nombre de servicio SOAP es un operando que sólo es válido en una clase de trabajo SOAP.
Mientras que la lista de operandos es dinámica, los enumerados aquí son operandos base. Si necesita más información, consulte la documentación del producto que da soporte a la lista ampliada. En la siguiente tabla se listan los operandos y sus protocolos asociados:
Variable de petición | Protocolos válidos | Descripción |
---|---|---|
|
IIOP | El nombre de la aplicación de empresa donde está contenido el EJB. |
clienthost | HTTP SOAP
|
El nombre completo del sistema principal del cliente. Es el valor del nombre de sistema principal de mandatos IP (Protocolo Internet). Este operando no admite operadores numéricos como >, >=, <, <=. |
|
IIOP | El nombre de puerto del cliente. |
clientipv4 | HTTP SOAP |
La dirección IP de la máquina cliente utilizando el tipo de dirección de cuatro elementos con puntos n.n.n.n del Protocolo Internet versión 4 (IPv4). |
clientipv6 | HTTP SOAP |
El tipo de dirección de 128 bits x:x:x:x:x:x:x:x del Protocolo Internet versión 6 (IPv6). |
cookie$<nombre> | HTTP SOAP |
Un nombre de cookie. Por ejemplo, la expresión cookie$My_Cookie_Name='My_Cookie_Value' comprueba si una petición contiene un cookie llamado
My_Cookie_Name con un valor de My_Cookie_Value. Para comprobar si existe o no un cookie determinado, utilice una de las expresiones siguientes:
cookie$MyCookieName IS NOT NULL cookie$MyCookieName IS NULL |
|
IIOP | El nombre de módulo de un EJB. |
|
IIOP | El nombre de un EJB. |
|
IIOP | El nombre de un método en el EJB. |
gid | HTTP SOAP |
Un ID de grupo del remitente de peticiones. |
header $<nombre> | HTTP SOAP |
Nombre de cabecera y el valor. Por ejemplo, la expresión header$Host='localhost' comprueba si una petición contiene una cabecera de sistema principal HTTP con un valor localhost.
Para comprobar si la cabecera host existe o no existe, utilice una de las siguientes
expresiones:
cookie$Host IS NOT NULL cookie$Host IS NULL |
HTTPMethod | HTTP SOAP |
El método HTTP para la petición. Los valores posibles son POST, GET, PUT y DELETE. |
MIMEType | HTTP SOAP |
El tipo MIME de la petición. |
operation | SOAP | El nombre de una operación de servicio Web. |
port | HTTP SOAP IIOP |
El puerto de escucha en el que se ha recibido la petición. |
protocol | HTTP SOAP |
El protocolo de comunicaciones que transmite la petición. Los protocolos soportados actualmente son HTTP, HTTPS, SOAP y SOAPS. |
queryparm$<nombre> | HTTP SOAP |
Nombre de cabecera y el valor. Por ejemplo, la expresión queryparm$timezone='EST' comprueba si una petición contiene un parámetro de consulta HTTP denominado timezone con un valor EST.
Para comprobar si existe o no un parámetro de consulta, utilice uno de los siguientes formatos:
queryparm$timezone IS NOT NULL queryparm$timezone IS NULL |
serverhost | HTTP SOAP
|
El nombre completo del sistema principal del servidor. Este operando no admite operadores numéricos como >, >=, <, <=. |
serveripv4 | HTTP SOAP |
La dirección IP de la máquina servidor utilizando el tipo de dirección de cuatro elementos con puntos IPv4 n.n.n.n. |
serveripv6 | HTTP SOAP |
El tipo de dirección de 128 bits de IPv6 x:x:x:x:x:x:x:x indicado a continuación de RFC 1924 de la máquina servidor. |
service | SOAP |
El nombre de un servicio Web. |
uid | HTTP SOAP |
El ID de usuario del remitente de peticiones. |
clienthost LIKE '%.ibm.com''%.ibm.com' es un literal que se utiliza para comparar con el nombre de sistema principal cliente para una petición. Esta expresión se evalúa como true para todas las peticiones que se originan en una máquina que está en el dominio ibm.com. Indique estos literales de serie entre comillas simples. No indique los literales numéricos entre comillas simples. Los paréntesis, junto los operadores AND, OR y NOT también pueden utilizarse para formar expresiones booleana compuestas. Consulte la especificación JMS 1.1 para ver una descripción detallada.
WebSphere Extended Deployment admite los operadores siguientes en las expresiones de normas. A estos operadores también se les denomina predicados en la terminología SQL porque aparecen dentro de una cláusula WHERE o HAVING. Los operadores no son sensibles a mayúsculas y minúsculas.
Operador | Descripción |
---|---|
OR | El operador OR lógico. |
AND | El operador AND lógico. |
NOT | El operador de negación. |
IN | Expresa un operando con varios valores en una sola expresión.
Su significado es coherente con el significado estándar SQL del operador.
Por ejemplo, si, para un operando denominado port, un usuario
desea expresar que el valor de port podría ser cualquiera entre todos los valores
como 9080, 9090, 9091, el fragmento de expresión sería: port IN (9080,9090,9091) En SQL, la forma como se expresen los valores dentro de los delimitadores dependerá del tipo de datos del puerto. Si port es un entero, los valores sin las comillas sencillas son sintácticamente correctos. Si port es una serie, la expresión correcta sería:
port IN (‘9080’, ‘9090’, ‘9091’) |
LIKE | Expresa una coincidencia de patrón para los valores de
operando de la serie y el uso es coherente con lo que se define mediante el lenguaje
SQL. El valor debe contener el carácter comodín (%) en la posición en la que está previsto que empiece la coincidencia de patrones.
Por ejemplo, la expresión:
host LIKE %blancacoincide con la palabra blanca o con cualquier otra palabra que finalice por blanca, mientras que la expresión: host LIKE blanca%coincide con la palabra blanca o cualquier otra palabra que empiece por blanca. La expresión: host LIKE %blanca%coincide con la palabra blanca con cualquier palabra que incluya la palabra blanca. Desde un punto de vista de la implementación de código, se utiliza la clase java.util.regex.Pattern. |
= | El operador de igualdad expresa una coincidencia de uso de mayúsculas y minúsculas. |
> | El operador mayor que se utiliza con operandos numéricos. |
>= | El operador mayor o igual que se utiliza con operandos numéricos. |
< | El operador menor que se utiliza con operandos numéricos. |
<= | El operador menor o igual que se utiliza con operandos numéricos. |
< > | Operador no es igual a. |
BETWEEN | Se utiliza con AND para seleccionar un rango de valores incluyendo el primer valor (inferior) y el último (superior). Conjuntamente, operan en valores de fechas y números. |
IS NULL | Comprueba si un operando tiene un valor NULL. |
IS NOT NULL | Comprueba si un operando tiene un valor que no sea NULL. |
Related concepts
Clasificación de peticiones basadas en normas de ODR
Related tasks
Definición de política de servicio
Activación de ediciones simultáneas
Validación de ediciones