Políticas

Detalhes da implementação para usar o WSRR como o Ponto de Criação de Política e o WebSphere DataPower como o Ponto de Cumprimento de Política ao criar políticas de mediação.

Políticas no WSRR

O WSRR pode ser usado para criar todas as políticas SOA, incluindo políticas SLA (Acordo de Nível de Serviço), políticas de mediação, políticas de monitoramento, políticas customizadas e outros domínios de política que deverão ser suportados no futuro. Usando a interface com o usuário do Business Space, é possível criar, atualizar ou excluir um documento sobre políticas no WSRR. O documento sobre políticas pode conter uma expressão de política que especifica várias políticas de um domínio de política específico. Como alternativa, é possível criar um documento sobre políticas que monta políticas existentes de outros documentos. As políticas individuais são referidas usando identificadores de política, que você especifica ao incluir políticas em seu documento. Uma expressão de política representa a declaração de uma política e é equivalente a um elemento <wsp:Policy> em um documento WS-Policy.

Para criar uma política de mediação no Business Space, consulte Criando Novas Políticas.

Asserções de Política de Mediação

Os Acordos de Nível de Serviço (SLAs) devem se originar de um requisito dos negócios de que a qualidade de serviço fornecida por um serviço deve atender a um padrão especificado. Como um serviço está sendo projetado, requisitos funcionais são criados para orientar a lógica do que o serviço executa. Requisitos não funcionais devem ser especificados em paralelo como parte da análise e design desse serviço para designar a qualidade de serviço que espera-se que o serviço forneça. Por exemplo, a empresa pode ter um serviço que fornece informações em resposta a uma consulta de Internet do cliente. O destino é para retornar a resposta em 3 segundos. Como parte da engenharia da transação de ponta a ponta, é determinado que esse serviço deve retornar suas informações em 2 segundos, a fim de atender aos requisitos não funcionais dos negócios.

Podemos escrever uma política que implemente verificações de tempo de execução sobre o desempenho do serviço e tome uma ação quando o SLA não está sendo atendido de forma a garantir que o serviço atenda a seu SLA. Por exemplo, podemos ter um terminal primário de serviço que é normalmente capaz (95% do tempo) de fornecer resposta de serviço em 2 segundos. O Arquiteto de SOA criou um terminal secundário em outro servidor que é normalmente usado como uma espera a quente para indisponibilidades do terminal primário, mas também está autorizado a ser usado para o tráfego de estouro quando o terminal primário não é capaz de acompanhar o carregamento da transação. Podemos escrever uma política que verifica o tempo de resposta de serviço e roteia novamente o tráfego quando necessário para atender ao SLA.

Outro exemplo em que os SLAs são mantidos por meio da política de tempo de execução é uma situação na qual um serviço está respondendo às transações que possuem uma variedade de consumidores, cada um com um nível diferente de prioridade. Um exemplo simples pode ter clientes “ouro” e “bronze”, em que apenas garantimos uma qualidade de serviço específica para nossos clientes “ouro”. Neste exemplo, podemos verificar se o consumidor é “ouro” e rotear novamente para nosso terminal secundário, deixando nosso cliente “bronze” lidar com um tempo de resposta mais lento. A empresa tomou essa decisão uma vez que os clientes “bronze” fornecem renda incremental insuficiente para justificar a despesa do tempo de resposta de engenharia para atender ao SLA de clientes “ouro”.

Em um terceiro exemplo, podemos ter uma situação em que um serviço fará o melhor possível, mas quando determinar que está com subcarregamento, ele enfileirará ou mesmo rejeitará mensagens de serviços do consumidor de baixa prioridade. Um exemplo disso é quando uma rotina de lote inunda o sistema com as solicitações do consumidor em um momento inesperado. Para proteger a qualidade de serviço, podemos criar uma política de tempo de execução que fique em vigor apenas durante as horas de expediente e que rejeitará todas as solicitações de lote durante esse período.

Mais genericamente, a política de mediação permite a validação e transformação na mensagem recebida do cliente (consumidor) antes da apresentação ao servidor (provedor).

As políticas suportam este tipo de validação e transformação de mensagem. As políticas podem ser especificadas para um serviço de provedor apenas, para um par de consumidor/provedor específico ou para consumidores Anônimos de um serviço de provedor. As políticas para clientes Anônimos fornecem uma maneira de definir uma política padrão que se aplica apenas aos consumidores para os quais nenhuma outra política se aplica. O uso desse recurso permite que políticas sejam especificadas para consumidores suspeitos que não se identificam. Tais serviços de consumidor podem, então, ter suas transações rejeitadas. Isso pode ser útil para evitar ataques de negação de serviço de hackers consumidores que tentam inundar o sistema com transações destinadas a derrubar um serviço de provedor.

Condições da Política de Mediação

Podem ser feitas asserções de mediação que permitem que a política de tempo de execução controle o SLA do serviço, a transformação de mensagens de consumidor para provedor ou valide o esquema de mensagem da mensagem do consumidor.

As condições da política SLA, um tipo especial de política de mediação, permitem efetivamente uma construção if-then-else clássica com uma condição e, em seguida, um conjunto de ações a serem executadas dependendo de como a condição é avaliada. A especificação de uma condição é opcional. Se nenhuma condição for especificada, ela será equivalente à condição lógica que avalia como Verdadeiro e quaisquer ações especificadas serão impingidas adequadamente.

A condição, se especificada, deve consistir em uma expressão booleana ou uma especificação de planejamento, ou podem ser ambas.

Planejamento

O planejamento, se especificado, identifica quando a política está em vigor. A data e hora especificadas são avaliadas pelo Policy Enforcement Point local e o fuso horário usado é aquele do Policy Enforcement Point. Se nenhum planejamento for especificado, a política será iniciada assim que for transferida por download do Policy Authoring Point para o Policy Enforcement Point, e confinuará indefinidamente.

O planejamento define uma data de início opcional e uma data de parada opcional, um intervalo de tempo diário opcional e uma lista opcional de dias da semana. Por exemplo, um planejamento pode ser definido como efetivo a partir de 1º de outubro de 2012 a 30 de outubro de 2012, das 8h às 17h, nas quarta-feiras e domingos.

Os parâmetros para o planejamento que podem ser especificados são os seguintes:
  • StartDate - Este atributo opcional especifica a data em que o planejamento torna-se efetivo no formato xs:date. StartDate é inclusivo e, se este atributo não estiver presente, o planejamento se tornará efetivo imediatamente hoje.
    Nota: Clique no hiperlink xs:date para entender esse padrão de mercado.
  • StopDate - Este atributo opcional especifica a data em que o planejamento para de ser efetivo no formato xs:date. StopDate é exclusivo e a data especificada deve ser após a data de início. Quando a data de parada é anterior ou igual à data de início, o planejamento nunca é efetivo. Se este atributo não estiver presente, o planejamento será efetivo indefinidamente.
  • Daily - Este elemento opcional especifica o intervalo de tempo diário durante o qual o planejamento é efetivo. Se esse elemento não estiver presente, o planejamento será efetivo o dia inteiro.
    • StartTime – Se Daily estiver especificado, este atributo é obrigatório. Ele especifica o horário em que o planejamento inicia diariamente no formato xs:time. (Nota: clique no hiperlink xs:time para entender esse padrão de mercado).
    • StopTime - Se Daily estiver especificado, este atributo é obrigatório. Ele especifica o horário em que o planejamento para diariamente no formato xs:time. StopTime é exclusivo e, se o horário especificado for anterior ou igual ao horário de início diário, o planejamento parará no horário de parada especificado no dia seguinte.
  • Weekdays - Este elemento opcional especifica os dias da semana inclusos no planejamento. Se este elemento não estiver presente, todos os dias da semana serão inclusos no planejamento. Este elemento afeta apenas o início do intervalo de tempo diário, uma vez que os planejamentos são permitidos executar após a meia-noite. Por exemplo, se um planejamento estiver configurado para iniciar às 23h e for executado por 2 horas às quarta-feiras, o planejamento terminará efetivamente na quinta-feita à 1h.
    • Days - Se Weekdays estiver especificado, este atributo é obrigatório. Ele lista os dias da semana inclusos no planejamento como uma lista de nomes separados com o sinal de mais ('+'), por exemplo, “Monday+Tuesday+Wednesday+Thursday+Friday+Saturday+Sunday”.

Expressão de Condição da Política de Mediação

A expressão de condição, se especificada, é um elemento sem repetição que especifica uma expressão booleana.

A expressão inclui três parâmetros necessários, que consistem em Attribute, Operator e Value, além de Interval e Limit opcionais. Se o aplicativo do Operador no Attribute e no Value, além de Interval e Limit quando apropriado, avaliar como Verdadeiro, a expressão avaliará como Verdadeiro. O elemento Limit é usado apenas com os operadores HighLow e TokenBucket. Se não for especificado, o valor de Limit será 0. Se Interval não for especificado, o padrão será 60 segundos.

Os parâmetros para Expression que podem ser especificados são os seguintes:
  • Attribute - A tabela a seguir resume os atributos definidos e seus tipos.
    Tabela 1. Atributos Definidos
    Atributo Descrição e Tipo
    ErrorCount O número de falhas observado durante este intervalo de monitoramento.
    MessageCount O número de mensagens reais interceptadas durante o intervalo de monitoramento.
    InternalLatency A latência interna (tempo de processamento) em segundos.
    BackendLatency A latência de dispositivo-para-servidor em segundos.
    TotalLatency A soma de latência interna e de backend em segundos.
  • Operator - A tabela a seguir resume os operadores disponíveis e seus significados:
    Tabela 2. Operadores
    Operador Significado
    GreaterThan Um algoritmo numérico simples que avalia como Verdadeiro quando o Attribute é maior que o Value definido.
    LessThan Um algoritmo numérico simples que avalia como Verdadeiro quando o Attribute é menor que o Value definido.
    TokenBucket Um algoritmo baseado em taxa que permite bursting. O algoritmo consiste em um depósito com uma capacidade máxima de tokens de Limit. O depósito é reenchido a uma taxa constante de tokens de Value por Interval, enquanto um token é removido para cada unidade de Attribute. Esse algoritmo avalia como Verdadeiro quando não há tokens no depósito e avaliado como Falso caso contrário. Aqui está um exemplo para ajudar a explicar o algoritmo: Suponha Limit=100, Value=5, Interval=1 second e o Attribute=MessageCount.
    1. O depósito inicia integral com uma capacidade máxima de 100 tokens
    2. Quando uma mensagem chega, o algoritmo verifica se o depósito retém quaisquer tokens:
      1. Se sim, o algoritmo avalia como Falso e um token é removido do depósito
      2. Se não, o algoritmo avalia como Verdadeiro.
    3. Nesse período, a cada segundo, o algoritmo inclui 5 tokens novamente no depósito conforme o espaço permite.
    HighLow Um algoritmo que avalia como Verdadeiro quando o Attribute atinge o limite alto especificado como o Valor e, em seguida, continua a avaliar como Verdadeiro até que o Attribute atinja o limite baixo especificado como o Limit.
  • Value – Este é um elemento de número inteiro positivo. “0” é válido.
  • Interval - Este elemento opcional define o intervalo de tempo, usado como uma janela deslizante, para medir o wsme:Attribute ao avaliar a expressão, no formato xs:duration. Se não especificado, o intervalo usado será de 60 segundos. Se especificado, um valor razoável deverá ser especificado, levando em consideração os recursos configurados do Policy Enforcement Point. Ou seja, quanto maior esse valor, mais memória será necessária ao Policy Enforcement Point para manter o controle do atributo.
    Nota: Clique no hiperlink xs:duration para entender esse padrão de mercado.
  • Limit - Este elemento de número inteiro define o argumento Limit adicional requerido quando wsme:Operator é TokenBucket ou HighLow. A unidade depende do wsme:Operator especificado.

    Quando wsme:Operator é HighLow, isto define o limite baixo enquanto wsme:Value define o limite alto. O limite especificado deve ser inferior àquele de wsme:Value. Quando não especificado, o Limite padrão é 0.

    Quando wsme:Operator é TokenBucket, isto define o tamanho máximo do burst, ou o número máximo de tokens no depósito, enquanto Value especifica a taxa em que o depósito é reenchido, em número de tokens por Intervalo. Quando não especificado, o limite padrão é 0 e TokenBucket é, então, equivalente a uma operação GreaterThan.

Ações da Política de Mediação

O elemento Ação de Mediação especifica as ações a serem tomadas. Embora a sintaxe permita muitas combinações, nem todas elas fazem sentido, e quando ações conflitantes forem especificadas, como pedir que uma mensagem seja tanto enfileirada quanto rejeitada, o comportamento será rejeitado pelo Policy Authoring Point. As ações da política de mediação permissões são:
  • QueueMessage – Esta ação especifica que as transações serão enfileiradas quando a condição lógica for atendida. O processamento de mensagens não recomeçará até que a condição lógica deixe de ser atendida. A metodologia da fila e quaisquer tempos limites associados são conforme definidos pelo Policy Enforcement Point, neste caso, o WebSphere DataPower. Quando várias ações são especificadas, dentro de um único elemento de Ação, QueueMessage deve ser a primeira ação.
  • RejectMessage – Esta ação especifica que as transações serão rejeitadas quando a condição lógica for atendida. As transações continuarão a ser rejeitadas até que a condição lógica deixe de ser atendida. Quando as transações forem rejeitadas, uma falha de SOAP será retornada para o serviço de cliente (consumidor). Quando várias ações são especificadas, dentro de um único elemento de Ação, RejectMessage deve ser a primeira ação. QueueMessage e RejectMessage são mutuamente exclusivos.
  • Notify - Este elemento opcional especifica que uma notificação será produzida quando a condição lógica for atendida. Para o WebSphere DataPower, uma mensagem será gravada no log do sistema do DataPower.
  • RouteMessage - Este elemento opcional especifica que as mensagens serão roteadas para um destino de terminal especificado quando a condição lógica for atendida. As transações continuarão a ser roteadas para o terminal especificado até que a condição lógica deixe de ser atendida.
    • EndPoint – Este parâmetro será necessário quando uma ação de RouteMessage for especificada. O valor de terminal suportado pode ser um endereço IP, nome do host ou host virtual; como grupo de balanceadores de carga.
  • ValidateMessage - Este elemento opcional especifica que as mensagens deverão ser validadas com relação às gramáticas especificadas. As mensagens deverão ser rejeitadas quando a validação falhar. O XSD ou WSDL deve ser especificado como um subparâmetro se ValidateMessage estiver especificado. SCOPE é opcional e, se não especificado, SOAPBody será usado para a validação.
    • XSD - Especifica que as mensagens serão validadas com relação ao esquema XML identificado pelo URI que ele contém.
    • WSDL - Especifica que as mensagens serão validadas com relação à descrição de serviços da web (WSDL) identificada pelo URI que ela contém.
    • SCOPE – Especifica qual parte da mensagem será validada. A tabela a seguir lista os valores possíveis e o que eles significam:
      Tabela 3. Elementos de ValidateMessage
      Valor Descrição
      SOAPBody O conteúdo do elemento de Corpo SOAP, sem o processamento especial para falhas de SOAP. (Padrão)
      SOAPBodyOrDetails O conteúdo do elemento de detalhe para falhas de SOAP e, caso contrário, o conteúdo do Corpo.
      SOAPEnvelope A mensagem SOAP inteira, incluindo o envelope.
      SOAPIgnoreFaults Sem validação se a mensagem for uma falha de SOAP, caso contrário, o conteúdo do Corpo SOAP.
  • ExecuteXSL - Especifica que uma conversão XSL será executada com a Folha de Estilo e os Parâmetros especificados. As transações serão rejeitadas quando a execução falhar. As informações de Stylesheet devem ser especificadas, enquanto as de Parameters são opcionais e devem ser especificadas conforme necessário pela folha de estilo particular especificada.
    • Stylesheet - Especifica que a operação de conversão usará a folha de estilo especificada pelo URI contido. A folha de estilo DEVE ser um arquivo XSLT.
    • Parameter - Este elemento de repetição opcional especifica um parâmetro de folha de estilo a ser usado para a operação ExecuteXSL.
      • Name – Este atributo é necessário para cada Parameter correspondente e especifica o nome do parâmetro.
      • Value - Este atributo é necessário para cada parâmetro Name correspondente e especifica o valor do parâmetro.

Conceito Conceito

Feedback


Ícone de registro de data e hora Última atualização: 14 de novembro de 2012


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