Politiche

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.

Politiche in WSRR

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

Asserzioni della politica 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.

Condizioni della politica di mediazione

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.

I parametri per la pianificazione che possono essere specificati sono riportati di seguito:
  • StartDate - Questo attributo facoltativo specifica in formato xs:date la data in cui la pianificazione diventa valida. StartDate è inclusivo e se questo attributo non è presente, la pianificazione diventa valida in modo immediato oggi. Fare clic sul collegamento ipertestuale xs:time per comprendere questo standard del settore.
  • StopDate - Questo attributo facoltativo specifica in formato xs:date la data in cui la pianificazione termina di essere valida. StopDate è esclusivo e la data specificata deve essere successiva alla data di inizio. Quando la data di fine è precedente o uguale alla data di inizio, la pianificazione non è mai valida. Se questo attributo non è presente, la pianificazione è valida indefinitamente.
  • Daily - Questo elemento facoltativo specifica l'intervallo di tempo giornaliero durante il quale la pianificazione è valida. Se questo elemento non è presente, la pianificazione è valida tutto il giorno.
    • StartTime – Se Daily è specificato, questo attributo è obbligatorio. Specifica in formato xs:time l'ora in cui ha inizio la pianificazione durante il giorno. Fare clic sul collegamento ipertestuale xs:time per comprendere questo standard del settore.
    • StopTime – Se Daily è specificato, questo attributo è obbligatorio. Specifica in formato xs:time l'ora in cui ha fine la pianificazione durante il giorno. StopTime è esclusivo e se l'ora specificata è precedente o uguale all'ora di inizio giornaliero, la pianificazione si arresta nell'ora di fine specificata del giorno successivo.
  • Weekdays - Questo elemento facoltativo specifica i giorni della settimana inclusi nella pianificazione. Se questo elemento non è presente, nella pianificazione saranno inclusi tutti i giorni della settimana. Questo elemento influisce solo sull'inizio dell'intervallo di tempo giornaliero, poiché le esecuzioni delle pianificazioni sono consentite dopo la mezzanotte. Ad esempio, se una pianificazione è impostata per iniziare alle ore 23, e viene eseguita per 2 ore ogni mercoledì, la pianificazione termina effettivamente il giovedì alle ore 01:00.
    • Days – Se Weekdays è specificato, questo attributo è obbligatorio. Elenca i giorni della settimana inclusi nella pianificazione, come un elenco di nomi separati con il segno più ('+'); ad esempio, “Monday+Tuesday+Wednesday+Thursday+Friday+Saturday+Sunday”.

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.

I parametri per l'espressione che possono essere specificati sono riportati di seguito:
  • Attribute - La seguente tabella riepiloga gli attributi definiti e il relativo tipo.
    Tabella 1. Attributi definiti
    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.
  • Operator - La seguente tabella riepiloga gli operatori disponibili e il loro significato:
    Tabella 2. Operatori
    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.
    1. Il bucket viene avviato pieno con una capacità massima di 100 token
    2. Quando si riceve un messaggio, l'algoritmo controlla se il bucket contiene eventuali token:
      1. In tal caso, l'algoritmo assume il valore False e un token è rimosso dal bucket
      2. In caso contrario, l'algoritmo assume il valore True.
    3. Durante tutto il periodo, ogni secondo, l'algoritmo restituisce 5 token al bucket in base allo spazio.
    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.
  • Value – Si tratta di un elemento intero positivo. “0” è valido.
  • Interval - Questo elemento facoltativo definisce in formato xs:duration l'intervallo di tempo, utilizzato come finestra scorrevole, per misurare wsme:Attribute durante la valutazione dell'espressione. Se non specificato, l'intervallo utilizzato è di 60 secondi. Se specificato, è necessario indicare un valore ragionevole, considerando le capability configurate del PEP (Policy Enforcement Point). Ossia, più alto è il valore in questione, maggiore è la memoria richiesta dal PEP (Policy Enforcement Point) per tenere traccia dell'attributo. Fare clic sul collegamento ipertestuale xs:duration per comprendere questo standard del settore.
  • Limit - Questo elemento intero facoltativo definisce l'argomento Limite aggiuntivo richiesto quando wsme:Operator è TokenBucket o HighLow. L'unità dipende dal wsme:Operator specificato.

    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.

Azioni della politica di mediazione

L'elemento Azione di mediazione specifica le azioni da intraprendere. Nonostante la sintassi consenta molte combinazioni, non tutte hanno un senso e quando vengono specificate le azioni in conflitto, come la richiesta che un messaggio sia accodato e rifiutato, il comportamento viene rifiutato dal PAP (Policy Authoring Point). Le azioni della politica di mediazione consentite sono:
  • QueueMessage – Questa azione specifica che le transazioni sono accodate quando viene soddisfatta la condizione logica. L'elaborazione dei messaggi non riprende fino a quando la condizione logica non è più soddisfatta. La metodologia di accodamento e qualsiasi timeout associato sono definiti dal PEP (Policy Enforcement Point), in questo caso WebSphere DataPower. Quando sono specificate diverse azioni all'interno di un singolo elemento Azione, QueueMessage deve essere la prima azione.
  • RejectMessage – Questa azione specifica che le transazioni sono rifiutate quando la condizione logica è soddisfatta. Le transazioni continuano ad essere rifiutate fino a quando la condizione logica non è più soddisfatta. Quando le transazioni vengono rifiutate, un errore SOAP viene restituito al servizio client (consumer). Quando sono specificate diverse azioni all'interno di un singolo elemento Azione, RejectMessage deve essere la prima azione. QueueMessage e RejectMessage si escludono reciprocamente.
  • Notify - Questo elemento facoltativo specifica che una notifica viene generata quando la condizione logica è soddisfatta. Per DataPower, un messaggio viene scritto nel log di sistema DataPower.
  • RouteMessage - Questo elemento facoltativo specifica che i messaggi vengono instradati verso la destinazione di endpoint specificata quando la condizione logica è soddisfatta. I messaggi continuano ad essere instradati all'endpoint specificato fino a quando la condizione logica non è più soddisfatta.
    • EndPoint – Questo parametro è obbligatorio quando viene specificata un'azione RouteMessage. Il valore di endpoint supportato può essere un indirizzo IP, un nome host o un host virtuale; ad esempio un gruppo bilanciatore di carico.
  • ValidateMessage - Questo elemento facoltativo specifica che i messaggi vengono convalidati rispetto alle grammatiche specificate. I messaggi vengono rifiutati quando la convalida ha esito negativo. XSD o WSDL deve essere specificato come parametro secondario se ValidateMessage è specificato. SCOPE è facoltativo e se non specificato, SOAPBody viene utilizzato per la convalida.
    • XSD - Specifica che i messaggi vengono convalidati rispetto allo schema XML identificato dall'URI che contiene.
    • WSDL - Specifica che i messaggi vengono convalidati rispetto alla descrizione dei servizi Web (WSDL) identificata dall'URI che contiene.
    • SCOPE – Specifica la parte del messaggio che viene convalidata. La seguente tabella elenca i possibili valori e il loro significato:
      Tabella 3. Elementi ValidateMessage
      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.
  • ExecuteXSL - Specifica l'esecuzione di una trasformazione XSL con il foglio di stile e i parametri specificati. Le transazioni vengono rifiutate quando l'esecuzione ha esito negativo. Le informazioni sul foglio di stile devono essere specificate, mentre i parametri sono facoltativi e devono essere specificati come richiesto dal particolare foglio di stile specificato.
    • Stylesheet - Specifica che l'operazione di trasformazione utilizza il foglio di stile specificato dall'URI contenuto. Il foglio di stile DEVE essere un file XSLT.
    • Parameter - Questo elemento facoltativo ripetitivo specifica un parametro del foglio di stile da utilizzare per l'operazione ExecuteXSL.
      • Name – Questo attributo è obbligatorio per ciascun parametro Parameter corrispondente e specifica il nome del parametro.
      • Value - Questo attributo è obbligatorio per ciascun parametro Name corrispondente e specifica il valore del parametro.

Concetto Concetto

Feedback


Timestamp icon Ultimo aggiornamento: 6 Marzo 2014


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