Detalles de implementación para utilizar WSRR como el punto de creación de políticas y WebSphere DataPower como punto de aplicación de políticas al crear políticas de mediación.
Puede utilizar WSRR para crear todas las políticas SOA, incluidas las políticas SLA (Acuerdo de nivel de servicio), las políticas de mediación, las políticas de supervisión y las políticas personalizadas. Mediante la interfaz de usuario de Business Space, puede crear, actualizar o suprimir un documento de políticas en WSRR. El documento de políticas puede contener una expresión de política que especifique un número de políticas para un dominio de política determinado. De forma alternativa, puede crear un documento de políticas que ensambla políticas existentes de otros documentos. Se hace referencia a las políticas individuales mediante los identificadores de política, los cuales se especifican cuando se añaden políticas al documento. Una expresión de política representa la declaración de una política y es equivalente a un elemento <wsp:Policy> de un documento WS-Policy.
Para crear una política de mediación en Business Space, consulte Creación de nuevas políticas de mediación.
Los Acuerdos de nivel de servicio (SLA) se originan a partir de un requisito empresarial de que la calidad de servicio que proporciona un servicio cumpla un estándar determinado. A medida que se diseña un servicio, se crean requisitos funcionales que guían la lógica de lo que lleva a cabo el servicio. De forma paralela se especifican requisitos no funcionales como parte del análisis y diseño del servicio para identificar la calidad que se espera del servicio. Por ejemplo, la empresa puede tener un servicio que proporciona información en respuesta a una consulta del cliente realizada en Internet. El objetivo es devolver la respuesta en el plazo de 3 segundos. Como parte del diseño de la transacción entre puntos finales, se determina que el servicio debe devolver la información en el plazo de 2 segundos para cumplir los requisitos no funcionales de la empresa.
Puede escribir una política que implemente comprobaciones de tiempo de ejecución en el rendimiento del servicio y actúe cuando se cumplan los requisitos para garantizar que el servicio cumple su SLA. Por ejemplo, puede tener un punto final de servicio primario que normalmente (un 95% del tiempo) puede proporcionar una respuesta de servicio en 2 segundos. El arquitecto SOA crea un punto final secundario en otro servidor que puede utilizarse como repuesto cuando se interrumpe el punto final principal, pero que también puede ser utilizado para el tráfico excesivo cuando el punto final principal no puede hacer frente a la carga de transacciones. Puede escribir una política que controla el tiempo de respuesta del servicio y redirecciona el tráfico cuando sea necesario para cumplir el acuerdo de nivel de servicio.
Otro ejemplo en el que se mantiene el acuerdo de nivel de servicio mediante una política de tiempo de ejecución es cuando un servicio responde a transacciones donde intervienen diversos consumidores, cada uno con un nivel de prioridad diferente. Un ejemplo sencillo es la situación donde existen clientes "Gold" y "Bronze" y sólo se asegura una calidad de servicio determinada para los clientes "Gold". En este ejemplo, puede comprobar si el consumidor es "Gold" y redireccionarlo hacia el punto final secundario, mientras que el cliente "Bronze" recibe un tiempo de respuesta más lento. La empresa lo ha decidido porque los clientes “Bronze” no proporcionan un aumento de beneficios suficiente para justificar los gastos de implementar un tiempo de respuesta que cumpla el acuerdo de nivel de servicio de los clientes “Gold”.
En un tercer ejemplo, puede tener una situación en la que un servicio hace todo cuanto sea posible, pero cuando determine que está sometido a una carga de trabajo, pone en cola o incluso rechaza los mensajes procedentes de servicios de consumidor de prioridad baja. Un ejemplo es cuando una rutina de proceso por lotes inunda el sistema con solicitudes de consumidores en un momento inesperado. Para proteger la calidad de servicio, puede crear una política de tiempo de ejecución que entre en vigor sólo durante el horario de trabajo y rechace todas las solicitudes de proceso por lotes durante este período.
De forma más genérica, la política de mediación permite la validación y transformación del mensaje entrante del cliente (consumidor) antes de presentarlo al servidor (proveedor).
Las políticas dan soporte a este tipo de validación y transformación del mensaje. Se pueden especificar políticas para un servicio de proveedor, para un par consumidor-proveedor específico o para los consumidores anónimos de un servicio de proveedor. Las políticas para consumidores anónimos proporcionan una manera de definir una política predeterminada que sólo se aplica a los consumidores para los que no se aplican otras políticas. Esto permite especificar una política para los consumidores no autorizados que no se identifican. Para esos servicios de consumidor se pueden luego rechazar sus transacciones. Esto puede ser útil para impedir ataques de denegación de servicio de piratas informáticos que intentan inundar el sistema con transacciones para colapsar un servicio de proveedor.
Se pueden realizar aserciones de mediación que permiten que la política de ejecución controle el Acuerdo de nivel de servicio, transforme los mensajes del consumidor al proveedor o valide el esquema del mensaje del consumidor.
Las condiciones de la política de SLA son un tipo especial de política de mediación que permiten utilizar una estructura if-then-else con una condición y luego efectuar un conjunto de acciones dependiendo del resultado de evaluar la condición. Especificar una condición es opcional. Si no se especifica ninguna condición, equivale a que la condición lógica se evalúe en True, y cualquier acción especificada se ejecutará de acuerdo con esto.
Si se especifica la condición, debe ser una expresión booleana o una especificación de planificación, o incluir ambas cosas.
Planificación
Si se especifica una planificación, ésta identifica cuándo entra en vigor la política. El punto de aplicación de políticas local evalúa la fecha y hora y la zona horaria utilizada es la del punto de aplicación de políticas. Si no se especifica ninguna planificación, la política se inicia en cuanto se descarga desde el punto de creación de políticas al punto de aplicación de políticas, y prosigue de forma indefinida.
La planificación define una fecha de inicio opcional y una fecha de detención opcional, un intervalo de tiempo diario opcional y una lista de días de la semana opcionales. Por ejemplo, se puede definir una planificación para que sea efectiva desde el 1 de octubre de 2012 al 30 de octubre de 2012, desde las 8 am hasta las 5 pm en los miércoles y domingos.
Expresión de la condición de la política de mediación
La expresión de la condición, si se especifica, es un elemento no repetitivo que especifica una expresión booleana.
La expresión consta de tres parámetros: Atributo, Operador y Valor, además de los parámetros opcionales Intervalo y Límite. Cuando se aplica el Operador sobre el Atributo y el Valor, más el Intervalo y el Límite cuando sean pertinentes, si el resultado de la evaluación es True, entonces el resultado de evaluar la expresión es True. El elemento Límite sólo se utiliza con los operadores HighLow y TokenBucket. Si no se especifica el Límite, su valor es 0. Si no se especifica el Intervalo, el valor predeterminado es 60 segundos.
Atributo | Descripción y tipo |
---|---|
ErrorCount | Número de errores observados durante el intervalo de supervisión. |
MessageCount | Número de mensajes reales interceptados durante el intervalo de supervisión. |
InternalLatency | Latencia interna (tiempo de proceso) en segundos. |
BackendLatency | Latencia de dispositivo-a-servidor en segundos. |
TotalLatency | Suma de la latencia de dispositivo a servidor y la latencia interna en segundos. |
Operador | Significado |
---|---|
GreaterThan | Algoritmo numérico simple que se evalúa como true cuando el atributo es mayor que el valor definido. |
LessThan | Algoritmo numérico simple que se evalúa como true cuando el atributo es menor que el valor definido. |
TokenBucket | Algoritmo basado en el ritmo de transmisión que permite la
transmisión por ráfagas. El algoritmo consta de un grupo con una capacidad máxima de señales de límite. El grupo se vuelve a llenar a una velocidad constante de señales de valor por intervalo, mientras que para cada unidad de atributo se elimina una señal. Este algoritmo se evalúa como True cuando no hay señales en el grupo y se evalúa como False cuando las hay. A continuación se muestra un ejemplo que ayuda a describir el algoritmo: presuponga que Limit=100, Value=5, Interval=1 segundo y Attribute=MessageCount.
|
HighLow | Algoritmo que se evalúa como True cuando el atributo alcanza el umbral alto especificado como valor, y continúa evaluándose como True hasta que el atributo alcanza el umbral bajo especificado como el límite. |
Cuando wsme:Operator es HighLow, define el umbral bajo, mientras que wsme:Value define el umbral alto. El umbral especificado debe ser menor que el umbral de wsme:Value. Cuando no se especifica el límite predeterminado es 0.
Cuando wsme:Operator es TokenBucket define el tamaño máximo de desbordamiento, o el número máximo de señales del grupo, mientras que el valor especifica la velocidad con que se rellena el grupo, en número de señales por intervalo. Cuando no se especifica el límite predeterminado es 0 y TokenBucket será entonces equivalente a una operación GreaterThan.
Valor | Descripción |
---|---|
SOAPBody | El contenido del elemento Body de SOAP, sin ningún proceso especial de errores de SOAP. (Valor predeterminado) |
SOAPBodyOrDetails | El contenido del elemento de detalles para los errores de SOAP y, de lo contrario, el contenido de Body. |
SOAPEnvelope | Todo el mensaje SOAP, incluido el sobre. |
SOAPIgnoreFaults | No hay validación si el mensaje es un error de SOAP, de lo contrario, el contenido de Body de SOAP. |