Dettagli di implementazione per l'utilizzo di WSRR come PAP (Policy Authoring Point) e di WebSphere DataPower come PEP (Policy Enforcement Point) quando si creano le politiche di mediazione.
È possibile utilizzare WSRR per creare tutte le politiche SOA, incluso le politiche SLA (Service Level Agreement), le politiche di mediazione, le politiche di monitoraggio e le politiche personalizzate. Con l'utilizzo dell'interfaccia utente di Business Space, è possibile creare, aggiornare o eliminare un documento della politica in WSRR. Il documento della politica può contenere un'espressione che specifica un numero di politiche per un particolare dominio della politica. In alternativa, è possibile creare un documento della politica che assembla le politiche esistenti di altri documenti. Le politiche individuali vengono indicate utilizzando gli identificativi della politica, che vengono specificati quando si aggiungono politiche al proprio documento. Un'espressione della politica rappresenta la dichiarazione di una politica ed è equivalente a un elemento <wsp:Policy> in un documento WS-Policy.
Per creare una politica di mediazione in Business Space, consultare Authoring di nuove politiche di mediazione.
Gli SLA (Service Level Agreement) hanno origine da un requisito di business che indica che la qualità fornita da un servizio soddisfa uno specifico standard. Durante la progettazione di un servizio, i requisiti funzionali vengono creati per guidare la logica di esecuzione del servizio. I requisiti non funzionali vengono specificati in parallelo come parte dell'analisi e della progettazione di tale servizio per definire la qualità che si prevede che il servizio fornisca. Ad esempio, l'azienda potrebbe avere un servizio che fornisce informazioni in risposta a una query internet del cliente. L'obiettivo è di restituire la risposta entro 3 secondi. Come parte del processo di progettazione della transazione end-to-end, è stato stabilito che questo servizio deve restituire le relative informazioni entro 2 secondi per soddisfare i requisiti non funzionali di business.
È possibile scrivere una politica che implementa le verifiche di runtime sulle prestazioni del servizio e che agisce quando i requisiti vengono soddisfatti per garantire che il servizio corrisponda ai requisiti SLA. Ad esempio, si potrebbe avere un endpoint primario del servizio che è normalmente (95% delle volte) in grado di fornire la risposta del servizio entro due secondi. L'architettura SOA crea un endpoint secondario su un altro server che può essere utilizzato come modello hot standby per interruzioni dell'endpoint primario, ma se ne consente l'utilizzo per il traffico in eccedenza quando l'endpoint primario non è in grado di tenere il passo con il caricamento della transazione. È possibile scrivere una politica che controlla il tempo di risposta del servizio e reindirizza il traffico quando necessario per soddisfare gli SLA.
Un altro esempio in cui gli SLA vengono conservati attraverso la politica di runtime è quello in cui un servizio risponde alle transazioni che hanno diversi consumer, ognuno con un diverso livello di priorità. Un esempio semplice potrebbe avere clienti “gold” e “bronze”, laddove il business garantisce solo una specifica qualità del servizio per clienti “gold”. In questo esempio, è possibile controllare se il consumer è “gold” ed eseguire il reinstradamento verso l'endpoint secondario, lasciando che il cliente “bronze” gestisca un tempo di risposta più lento. La decisione assunta dal business deriva da incrementi insufficienti dei ricavi da parte di clienti “bronze”, e giustifica i costi di progettazione necessari per ottenere un tempo di risposta che soddisfi l'accordo SLA dei clienti “gold”.
In un terzo esempio, si potrebbe verificare una situazione in cui un servizio si comporta nel migliore modo possibile, ma quando rileva di essere sotto carico, accoda o addirittura rifiuta i messaggi dai servizi consumer con bassa priorità. Un esempio si verifica quando la routine del batch invia al sistema richieste del consumer in tempi non previsti. Per tutelare la qualità del servizio, è possibile creare una politica di runtime attiva solo durante le ore lavorative e che rifiuti tutte le richieste in batch durante questo periodo.
A livello generale, la politica di mediazione consente la convalida e la trasformazione del messaggio in entrata dal client (consumer) prima della presentazione al server (provider).
Le politiche supportano questo tipo di convalida e trasformazione del messaggio. Le politiche possono essere specificate solo per un servizio del provider, per una coppia consumer-provider specifica o per consumer anonimi per un servizio del provider. Le politiche per i clienti anonimi forniscono una modalità di definizione di una politica predefinita che si applica solo ai consumer per cui non vengono applicate altre politiche. L'utilizzo di questa funzione consente di specificare le politiche per consumer anomali che non si identificano. I servizi consumer di questo tipo possono quindi avere le relative transazioni rifiutate. Ciò può essere utile per impedire attacchi DoS (denial of service) dagli hacker consumer che tentano di bloccare il sistema con transazioni che servono a interrompere i servizi del provider.
Le asserzioni della mediazione possono essere effettuate in modo da consentire alla politica runtime di controllare lo SLA del servizio, la trasformazione dei messaggi da consumer a provider, o per convalidare lo schema di messaggio del messaggio consumer.
Le condizioni della politica SLA, un tipo particolare di politica di mediazione, consente un costrutto if-then-else classico con una condizione ed un'insieme di azioni da eseguire a seconda di come viene valutata la condizione. La specifica di una condizione è facoltativa. Se non viene specificata alcuna condizione, la condizione logica è equivalente a quella che si assume con il valore True, e tutte le azioni specificate vengono applicate di conseguenza.
La condizione, se specificata, deve essere costituita da un'espressione booleana o da una specifica di pianificazione, oppure includere entrambe.
Pianificazione
La pianificazione, se specificata, identifica quando la politica è valida. La data e l'ora sono valutate dal PEP (Policy Enforcement Point) locale, mentre il fuso orario utilizzato è quello del PEP (Policy Enforcement Point). Se non viene specificata alcuna pianificazione, la politica inizia non appena viene scaricata dal PAP (Policy Authoring Point) al PEP (Policy Enforcement Point) e continua indefinitamente.
La pianificazione definisce una data di inizio e una data di fine facoltative, un intervallo di tempo giornaliero facoltativo e un elenco di giorni della settimana facoltativi. Ad esempio, una pianificazione può essere definita come valida dal 1° ottobre 2012 al 30 ottobre 2012, dalle ore 8 alle ore 17 tutti i mercoledì e le domeniche.
Espressione della condizione della politica di mediazione
L'espressione della condizione, se specificata, è un elemento non ripetuto che specifica un'espressione Booleana.
L'espressione contiene tre parametri: Attributo, Operatore e Valore, piu i parametri facoltativi Intervallo e Limite. Se l'applicazione dell'Operatore su Attributo e Valore, oltre a Intervallo e Limite quando necessari, assume il valore True, anche l'espressione assume il valore True. L'elemento Limite viene utilizzato solo con gli operatori HighLow e TokenBucket. Se non specificato, il valore di Limite è 0. Se l'intervallo non è specificato, il valore predefinito è 60 secondi.
Attributo | Descrizione e tipo |
---|---|
ErrorCount | Il numero di errori osservati durante questo intervallo di monitoraggio. |
MessageCount | Il numero di messaggi effettivi intercettati durante l'intervallo di monitoraggio. |
InternalLatency | La latenza interna (tempo di elaborazione) in secondi. |
BackendLatency | La latenza dispositivo-a-server in secondi. |
TotalLatency | La somma della latenza backend ed interna in secondi. |
Operatore | Significato |
---|---|
GreaterThan | Un algoritmo numerico semplice che assume il valore True quando Attributo è maggiore del valore definito. |
LessThan | Un algoritmo numerico semplice che assume il valore True quando Attributo è minore del valore definito. |
TokenBucket | Un algoritmo basato sulla frequenza che consente la suddivisione. L'algoritmo consiste di un bucket con una capacità massima di token Limite. Il bucket viene riempito ad una frequenza costante di token Valore per Intervallo, mentre per ciascuna unità di Attributo viene rimosso un token. Questo algoritmo assume il valore True quando non ci sono token nel bucket e il valore False in caso contrario. Di seguito è riportato un esempio che descrive l'algoritmo: Limit=100, Value=5, Interval=1 secondo e Attribute=MessageCount.
|
HighLow | Un algoritmo che assume il valore True quando Attributo raggiunge la soglia superiore specificata come Valore e quindi continua ad assumere il valore True fino a quando Attributo non raggiunge la soglia inferiore specificata come Limite. |
Se wsme:Operator è HighLow, definisce la soglia inferiore mentre wsme:Value definisce la soglia superiore. La soglia specificata deve essere inferiore a quella di wsme:Value. Se non specificato il limite predefinito è 0.
Se wsme:Operator è TokenBucket, definisce la dimensione massima della suddivisione, o il numero massimo di token nel bucket, mentre Valore specifica la frequenza con cui il bucket viene riempito, in numero di token per Intervallo. Se non specificato il limite predefinito è 0 e TokenBucket è equivalente a un'operazione GreaterThan.
Valore | Descrizione |
---|---|
SOAPBody | Il contenuto dell'elemento SOAP Body, senza particolare elaborazione per errori SOAP. (Impostazione predefinita) |
SOAPBodyOrDetails | Il contenuto dell'elemento dettagli per errori SOAP, altrimenti il contenuto di Body. |
SOAPEnvelope | L'intero messaggio SOAP, compresa la busta. |
SOAPIgnoreFaults | Nessuna convalida se il messaggio è un errore SOAP, altrimenti il contenuto dell'elemento SOAP Body. |