Políticas

Os detalhes da implementação para usar o WSRR como o Policy Authoring Point e o WebSphere DataPower como o Policy Enforcement Point ao criar políticas de mediação.

Políticas no WSRR

É possível usar o WSRR para criar todas as políticas de SOA, incluindo políticas de SLA (Acordo de Nível de Serviço), políticas de mediação, políticas de monitoramento e políticas customizadas. 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 um número de políticas para um determinado domínio de políticas. Como alternativa, é possível criar um documento sobre políticas que monta políticas existentes de outros documentos. As políticas individuais são encaminhadas para uso de identificadores de políticas, que você especifica quando inclui 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 Criação de Novas Políticas de Mediação.

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

Os Acordos de Nível de Serviço (SLAs) se originam de uma necessidade de negócios de que a qualidade se serviço que é fornecida por um serviço atende a um padrão especificado. À medida que um serviço é projetado, requisitos funcionais são criados para orientar a lógica do que o serviço faz. Requisitos não funcionais são especificados em paralelo como parte da análise e do design desse serviço para designar a qualidade de serviço que se espera 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, determina-se que esse serviço deve retornar suas informações em 2 segundos para atender aos requisitos não funcionais dos negócios.

É possível gravar uma política que implementa verificações de tempo de execução no desempenho do serviço e age quando os requisitos são atendidos para garantir que o serviço atenda ao seu SLA. Por exemplo, você pode ter um terminal primário de serviço que é normalmente (95% do tempo) capaz de fornecer resposta de serviço dentro de dois segundos. O arquiteto da SOA cria um terminal secundário em outro servidor que pode ser usado como uma espera a quente para indisponibilidades do terminal primário, mas está autorizado também a ser usado para tráfego de estouro quando o terminal primário não for capaz de acompanhar o carregamento da transação. É possível gravar uma política que verifica o tempo de resposta do 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 em que um serviço está respondendo a transações que possuem vários consumidores, cada um com um nível diferente de prioridade. Um exemplo simples pode ter clientes “gold” e “bronze”, em que os negócios garantem apenas uma qualidade de serviço específica para os clientes “gold”. Nesse exemplo, é possível verificar se o cliente é “gold” e rotear novamente para o terminal secundário, deixando o cliente “bronze” lidar com um tempo de resposta mais lento. Os negócios decidiram porque os clientes “bronze” fornecem renda incremental insuficiente para justificar a despesa de engenharia de um tempo de resposta para atender ao SLA dos clientes “gold”.

Em um terceiro exemplo, você pode ter uma situação em que um serviço faz o melhor que pode, mas quando ele determina que está com subcarregamento, enfileira ou até mesmo rejeita mensagens de serviços do consumidor de baixa prioridade. Um exemplo é quando uma rotina em lote inunda o sistema com solicitações do consumidor em um tempo inesperado. Para proteger a qualidade de serviço, é possível criar uma política de tempo de execução que esteja em efeito durante o horário comercial apenas e que rejeita todas as solicitações em lote durante esse período.

Mais genericamente, a política de mediação permite 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 aos quais nenhum outra política se aplica. Usar esse 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 nenhuma ação especificada será impingida de acordo.

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 são avaliadas pelo Policy Enforcement Point local e o fuso horário que é usado é o 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 continuará 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 - Esse atributo opcional especifica no formato xs:date a data na qual o planejamento se torna efetivo. StartDate é inclusivo e, se este atributo não estiver presente, o planejamento se tornará efetivo imediatamente hoje. (Clique no hiperlink xs:time para entender esse padrão de mercado).
  • StopDate - Esse atributo opcional especifica no formato xs:date a data na qual o planejamento para de ser efetivo. StopDate é exclusivo e a data especificada deve ser após a data de início. Quando a data de parada for anterior ou igual à data de início, o planejamento nunca se tornará efetivo. Se esse 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, no formato xs:time, o horário no qual o planejamento inicia diariamente. (Clique no hiperlink xs:time para entender esse padrão de mercado).
    • StopTime - Se Daily estiver especificado, este atributo é obrigatório. Ele especifica, no formato xs:time, o horário no qual o agendamento para diariamente. 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. Esse elemento afeta apenas o intervalo de tempo diário, uma vez que a execução de planejamentos é permitida após a meia-noite. Por exemplo, se um planejamento estiver configurado para iniciar às 23h e executar por 2 horas às quartas-feiras, o planejamento efetivamente terminará na quinta-feira à 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 de não repetição que especifica uma expressão booleana.

A expressão compreende três parâmetros: Attribute, Operator e Value, mais parâmetros opcionais de Interval e Limit. 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 que são observadas durante esse intervalo de monitoramento.
    MessageCount O número de mensagens reais que são 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 é preenchido 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 - Esse elemento opcional define no formato xs:duration o intervalo de tempo, usado como uma janela deslizante, para medir o wsme:Attribute ao avaliar a expressão. 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. (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 for HighLow, ele 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 for TokenBucket, ele define o tamanho máximo do burst, ou o número máximo de tokens no depósito, enquanto Value especifica a taxa na qual o depósito é novamente preenchido, em número de tokens por Interval. 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 várias combinações, nem todas elas fazem sentido e quando ações conflitantes forem especificadas, tais como solicitar que uma mensagem seja enfileirada e rejeitada, o comportamento será rejeitado pelo Policy Authoring Point. As ações da política de mediação permissões são:
  • QueueMessage – Essa ação especifica que as transações são enfileiradas quando a condição lógica for atendida. O processamento de mensagens não recomeça 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 Action, QueueMessage deverá ser a primeira ação.
  • RejectMessage – Essa ação especifica que as transações são rejeitadas quando a condição lógica for atendida. As transações continuam a ser rejeitas até que a condição lógica deixe de ser atendida. Quando as transações são rejeitadas, uma falha de SOAP será retornada ao serviço de cliente (consumidor). Quando várias ações são especificadas dentro de um único elemento Action, RejectMessage deverá ser a primeira ação. QueueMessage e RejectMessage são mutuamente exclusivos.
  • Notify - Esse elemento opcional especifica que uma notificação é produzida quando a condição lógica for atendida. Para DataPower, uma mensagem é gravada no log do sistema DataPower.
  • RouteMessage - Esse elemento opcional especifica que as mensagens são roteadas para o destino especificado do terminal quando a condição lógica for atendida. As mensagens continuam 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 - Esse elemento opcional especifica que as mensagens são validadas com relação às gramáticas especificadas. As mensagens são rejeitadas quando a validação falha. XSD ou WSDL deverão ser especificados como um subparâmetro se ValidateMessage for especificado. SCOPE é opcional e, se não especificado, SOAPBody será usado para a validação.
    • XSD - Especifica que as mensagens são validadas com relação ao esquema XML identificado pelo URI que ele contém.
    • WSDL - Especifica que as mensagens sã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 é 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 é executada com a folha de estilo e os parâmetros especificados. As transações são rejeitadas quando a execução falha. As informações da folha de estilo devem ser especificadas, enquanto os parâmetros são opcionais, e devem ser especificados conforme necessários pela folha de estilo particular especificada.
    • Stylesheet - Especifica que a operação de transformação usa a folha de estilo especificada pelo URI contido. A folha de estilo DEVE ser um arquivo XSLT.
    • Parameter - Esse 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: 03/03/2014


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