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