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.
É 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.
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.
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.
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.
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. |
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.
|
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. |
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.
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. |