Políticas

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.

Políticas en WSRR

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.

Aserciones de 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.

Condiciones de las políticas de mediación

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.

Los parámetros de la planificación se pueden especificar de este manera:
  • StartDate: este atributo opcional especifica la fecha en la que la planificación es efectiva, con el formato xs:date. StarDate es inclusivo y si este atributo no está presente, la planificación será efectiva de forma inmediata en el día actual. (Pulse el hiperenlace xs:time para conocer este estándar del sector).
  • StopDate - este atributo opcional especifica la fecha en la que la planificación deja de ser efectiva, con el formato xs:date. StopDate es exclusivo y la fecha especificada debe ser posterior a la fecha de inicio. Cuando la fecha de detención es anterior o igual a la fecha de inicio, la planificación nunca se hace efectiva. Si este atributo no está presente, la planificación es efectiva de forma indefinida.
  • Daily: este elemento opcional especifica el intervalo de tiempo diario durante el cual la planificación es efectiva. Si este elemento no está presente, la planificación es efectiva todo el día.
    • StartTime: si se especifica Daily, entonces este atributo es necesario. Especifica la hora en que la planificación comienza cada día con el formato xs:time. (Pulse el hiperenlace xs:time para conocer este estándar del sector).
    • StopTime: si se especifica Daily, entonces este atributo es necesario. Especifica la hora en que la planificación se detiene cada día con el formato xs:time. StopTime es exclusiva y si la hora especificada es anterior o la misma que la hora de inicio diaria de la planificación se detiene en la hora de detención especificada del día siguiente.
  • Weekdays: este elemento opcional especifica los días de la semana incluidos en la planificación. Si este elemento no está presente, se incluyen todos los días de la semana en la planificación. Este elemento solo afecta al inicio del intervalo de tiempo diario, ya que las planificaciones pueden ejecutarse pasada la medianoche. Por ejemplo, si una planificación está definida para iniciarse a las 11 pm y se ejecuta durante 2 horas los miércoles, la planificación finaliza el jueves a la 1 am.
    • Days: si se especifica Weekdays, entonces este atributo es necesario. Lista los días de la semana incluidos en la planificación, separados por el signo más ('+'), tal como “Monday+Tuesday+Wednesday+Thursday+Friday+Saturday+Sunday”.

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.

Los parámetros de la Expresión se pueden especificar de este modo:
  • Atributo: la tabla siguiente resume los atributos definidos y su tipo.
    Tabla 1. Atributos definidos
    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: la tabla siguiente resume los operadores disponibles y su significado.
    Tabla 2. Operadores
    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.
    1. Inicialmente el grupo está lleno con una capacidad máxima de 100 señales
    2. Cuando llega un mensaje, el algoritmo comprueba si el grupo contiene las señales:
      1. Si es así, el algoritmo se evalúa como False y se elimina una señal del grupo
      2. Si no es así, el algoritmo se evalúa como True.
    3. Mientras tanto, cada segundo, el algoritmo vuelve a añadir 5 señales al grupo, si el espacio lo permite.
    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.
  • Valor: este es un elemento entero positivo. “0” es válido.
  • Intervalo: este elemento opcional define el intervalo de tiempo, utilizado como intervalo móvil, para medir wsme:Attribute cuando se evalúa la expresión, con el formato xs:duration. Si no se especifica, el intervalo utilizado es 60 segundos. Si se especifica, se debe especificar un valor razonable, teniendo en cuenta las funciones configuradas del punto de aplicación de políticas. Esto es, cuanto mayor sea este valor, más memoria necesitará el punto de aplicación de políticas para hacer un seguimiento del atributo. (Pulse el hiperenlace xs:duration para conocer este estándar del sector).
  • Límite: este elemento entero opcional define el argumento adicional Límite que es necesario cuando wsme:Operator es TokenBucket o HighLow. La unidad depende del wsme:Operator especificado.

    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.

Acciones de la política de mediación

El elemento Acción de mediación especifica las acciones que se deben realizar. Aunque la sintaxis permite muchas combinaciones, no todas ellas tienen sentido, y cuando se especifican acciones conflictivas, tal como solicitar que un mensaje se ponga en la cola y se rechace, el comportamiento es rechazado por el punto de creación de políticas. Las acciones de la política de mediación son:
  • QueueMessage: esta acción especifica que las transacciones se pondrán en cola cuando se cumpla la condición lógica. El proceso de mensajes no se vuelve a comenzar hasta que no se vuelva a cumplir la condición lógica. La metodología de puesta en cola y los tiempos de espera excedidos asociados son los definidos por el punto de aplicación de políticas, en este caso WebSphere DataPower. Cuando se especifican varias acciones dentro de un mismo elemento Acción, QueueMessage debe ser la primera acción.
  • RejectMessage: esta acción especifica que las transacciones se rechazan cuando se cumpla la condición lógica. Las transacciones continuarán siendo rechazadas hasta que no se cumpla la condición lógica. Cuando se rechazan las transacciones, se devuelve un error SOAP al servicio de cliente (consumidor). Cuando se especifican varias acciones dentro de un mismo elemento Acción, RejectMessage debe ser la primera acción. QueueMessage y RejectMessage se excluyen mutuamente.
  • Notify: este elemento opcional especifica que se cree una notificación cuando se cumpla la condición lógica. Para DataPower, se graba un mensaje en el registro del sistema DataPower.
  • RouteMessage: este elemento opcional especifica que los mensajes se direccionen hacia al destino de punto final especificado cuando se cumpla la condición lógica. Los mensajes se siguen direccionando al punto final especificado hasta que no se cumpla la condición lógica.
    • EndPoint: este parámetro es necesario cuando se especifica una acción RouteMessage. El valor de punto final soportado puede ser una dirección IP, nombre de host o host virtual, tal como un grupo de equilibradores de carga.
  • ValidateMessage: este elemento opcional especifica que los mensajes se validan utilizando las gramáticas especificadas. Los mensajes se rechazan cuando la validación falle. Se debe especificar XSD o WSDL como subparámetro si se especifica ValidateMessage. SCOPE es opcional, y si no se especifica, se utiliza SOAPBody para la validación.
    • XSD: especifica que los mensajes se validan con el esquema XML identificado por el URI que contiene.
    • WSDL: especifica que los mensajes se validan con la descripción de servicios web (WSDL) identificada por el URI que contiene.
    • SCOPE: especifica qué parte del mensaje se valida. En la tabla siguiente se muestran los valores posibles y su significado:
      Tabla 3. Elementos de ValidateMessage
      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.
  • ExecuteXSL: especifica que se realizará una transformación XSL con la hoja de estilo y parámetros especificados. Las transacciones se rechazarán cuando falle la ejecución. Se debe especificar la información de la hoja de estilo, mientras que los parámetros son opcionales, y se deben especificar según sea necesario mediante la hoja de estilo especificada.
    • Stylesheet: especifica que la operación de transformación utiliza la hoja de estilo especificada por el URI contenido. La hoja de estilo DEBE ser un archivo XSLT.
    • Parameter: este elemento repetitivo opcional especifica un parámetro de hoja de estilo que se utilizará para la operación ExecuteXSL.
      • Name: este atributo es necesario para cada parámetro correspondiente y especifica el nombre del parámetro.
      • Value: este atributo es necesario para cada parámetro Name correspondiente y especifica el valor del parámetro.

Concepto Concepto

Comentarios


Icono de fecha y hora Última actualización: 06.03.2014


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr25.doc/topics/csoa2_SOA_implementation.htm