Una classe di lavoro viene utilizzata per classificare le richieste in modo da applicare una politica a una richiesta. Esistono due tipi di politica che vengono applicati a una richiesta: una politica di routing e una politica di servizio. È possibile creare le politiche di routing per le richieste HTTP e SOAP. Le politiche di servizio possono invece essere create per le richieste HTTP, IIOP, SOAP e JMS. Inoltre, le classi di lavoro possono contenere le regole di classificazione per entrambi i tipi di politiche ad eccezione di JMS. Le regole di classificazione non sono supportate per le classi di lavoro JMS. Le politiche di routing e di servizio per le classi di lavoro non sono supportate per IIOP e JMS per le applicazioni distribuite su z/OS. WebSphere Application Server per z/OS fornisce la classificazione di servizi IIOP e JMS.
Politica di routing | Descrizione |
---|---|
permit:<nome_applicazione> | In questa politica di routing, nome_applicazione è il nome dell'applicazione su cui eseguire l'instradamento con una edizione opzionale. Ciò consente alla richiesta di proseguire come normale. |
permitsticky:<nome_applicazione> | La politica di routing permitsticky è uguale alla politica di routing permit, tranne per il fatto che il router on demand (ODR) mantiene un'affinità client-server per qualsiasi richiesta futura che proviene dallo stesso client. In questo caso, l'ODR aggiunge un'intestazione SET-COOKIE alla risposta prima di inviare la risposta al client. |
reject:<codice_errore_HTTP> | Questa politica di routing implica che l'ODR rifiuti qualsiasi richiesta che ha il codice di errore HTTP specificato. Ad esempio, reject:503 restituisce un errore 503 Servizio non disponibile. |
redirect:<URL> | Con questa politica di routing, l'ODR reindirizza la richiesta all'URL specificato. L'URL ha il modello protocollo:// ;. Un esempio di URL valido è: http://w3.ibm.com. |
Le politiche di servizio valide sono semplicemente l'elenco dei nomi delle classi delle transazioni. La classe della transazione fa riferimento a una sola classe di servizio.
Esistono quattro tipi di classi di lavoro:
Classe di lavoro | Descrizione |
---|---|
Politica di routing dell'applicazione | Specifica come determinare la politica di routing per una richiesta a un'applicazione installata su WebSphere Extended Deployment. |
Politica di servizio dell'applicazione | Specifica come determinare la politica di servizio per una richiesta a un'applicazione installata su WebSphere Extended Deployment. |
Politica di routing del cluster di server generici | Specifica come determinare la politica di routing per una richiesta a un cluster di server generico. |
Politica di servizio del cluster di server generici | Specifica come determinare la politica di servizio per una richiesta a un cluster di server generico. |
Il seguente diagramma illustra il flusso di una richiesta diretta a un'applicazione installata su WebSphere Extended Deployment. La richiesta viene applicata a una classe di lavoro della politica di routing dell'applicazione per determinare la politica di routing stessa. Se la politica di routing risultante è permit o permitsticky, la richiesta continua a una classe di lavoro della politica di servizio dell'applicazione per determinare la politica del servizio e il nome della classe di transazioni.
Ogni applicazione contiene le classi di lavoro della politica di routing dell'applicazione e della politica di servizio dell'applicazione. È possibile creare ulteriori classi di lavoro non predefinite. Ogni classe di lavoro ha un'azione corrispondente predefinita. La politica di routing dell'applicazione per un'applicazione è permit:<nome_applicazione>. La politica di servizio predefinita è Default_TC, la classe delle transazioni predefinita.
Ogni classe di lavoro contiene un elenco di regole opzionale ordinato valutate per una particolare richiesta per determinare la politica per la richiesta. Ogni regola è costituita da un'espressione booleana e da un valore della politica. Se l'espressione è true per una determinata richiesta, viene utilizzata la politica associata alla regola.
La sintassi e la semantica di una espressione booleana per una regola sono simili alla clausola WHERE di una espressione SQL (structured query language). Più precisamente, la sintassi di una espressione è definita dalla specifica Java Message Service (JMS) 1.1. Fare riferimento a aClassificazione delle richieste basate sulle regole ODR per ulteriori informazioni.
Nella specifica JMS, gli identificativi fanno riferimento ai vari attributi che possono essere associati a una richiesta, ad esempio un determinato parametro della query, un cookie o un'intestazione HTTP. Un identificativo JMS può essere considerato come una variabile di richiesta o operando. Tali operandi possono essere specifici per un protocollo. Ad esempio, il nome del servizio SOAP è un operando che è valido solo in una classe di lavoro SOAP.
Mentre l'elenco di operandi è dinamico, gli operandi qui riportati sono gli operandi di base. Per ulteriori informazioni, fare riferimento alla documentazione del prodotto. Nella seguente tabella sono riportati gli operandi e i relativi protocolli associati:
Variabile di richiesta | Protocolli validi | Descrizione |
---|---|---|
|
IIOP | Il nome dell'applicazione enterprise su cui è presente l'EJB. |
clienthost | HTTP SOAP
|
Il nome host client completo Questo è il valore del nome host del comando IP. Questo operando non supporta operatori numerici quali >, >=, <, <=. |
|
IIOP | Il nome della porta client. |
clientipv4 | HTTP SOAP |
L'indirizzo IP della macchina client che utilizza il tipo di indirizzo puntato IPv4 (Internet Protocol version 4) n.n.n.n. |
clientipv6 | HTTP SOAP |
Il tipo di indirizzo a 128 bit IPv6 (Internet Protocol version 6) x:x:x:x:x:x:x:x che segue la RFC (Request for Comments) 1924 della macchina client. |
cookie$<nome> | HTTP SOAP |
Il nome di un cookie. Ad esempio, l'espressione cookie$My_Cookie_Name='My_Cookie_Value' valuta una richiesta per verificare se contiene un cookie denominato My_Cookie_Name con valore My_Cookie_Value. Per verificare la presenza o l'assenza di un determinato cookie, utilizzare le seguenti espressioni: cookie$nomecookie IS NOT NULL cookie$nomecookie IS NULL |
|
IIOP | Il nome del modulo di un EJB. |
|
IIOP | Il nome di un EJB. |
|
IIOP | Il nome di un metodo all'interno dell'EJB. |
gid | HTTP SOAP |
Un ID del gruppo mittente della richiesta. |
header $<nome> | HTTP SOAP |
Il nome e il valore dell'intestazione. Ad esempio, l'espressione header$Host='localhost' valuta una richiesta per verificare se contiene un'intestazione host HTTP con il valore localhost.
Per verificare la presenza o l'assenza dell'intestazione host, utilizzare una delle seguenti espressioni: cookie$Host IS NOT NULL cookie$Host IS NULL |
HTTPMethod | HTTP SOAP |
Il metodo HTTP per la richiesta. I valori possibili sono POST, GET, PUT e DELETE. |
MIMEType | HTTP SOAP |
Il tipo MIME della richiesta. |
operation | SOAP | Il nome di un'operazione di un servizio Web. |
port | HTTP SOAP IIOP |
La porta di ascolto su cui viene ricevuta la richiesta. |
protocol | HTTP SOAP |
Il protocollo di comunicazione che trasmette la richiesta. I protocolli supportati sono HTTP, HTTPS, SOAP e SOAPS. |
queryparm$<nome> | HTTP SOAP |
Il nome e il valore dell'intestazione. Ad esempio, l'espressione queryparm$timezone='EST' valuta una richiesta per verificare se contiene un parametro di query HTTP denominato timezone con valore EST. Per verificare la presenza o l'assenza di un parametro di query, utilizzare uno dei seguenti formati: queryparm$timezone IS NOT NULL queryparm$timezone IS NULL |
serverhost | HTTP SOAP
|
Il nome host completo del server. Questo operando non supporta operatori numerici quali >, >=, <, <=. |
serveripv4 | HTTP SOAP |
L'indirizzo IP della macchina del server che utilizza il tipo di indirizzo puntato IPv4 n.n.n.n. |
serveripv6 | HTTP SOAP |
Il tipo di indirizzo a 128 bit IPv6 x:x:x:x:x:x:x:x che segue la RFC 1924 della macchina server. |
service | SOAP |
Il nome di un servizio Web. |
uid | HTTP SOAP |
L'ID utente del mittente della richiesta. |
clienthost LIKE '%.ibm.com''%.ibm.com' è un letterale utilizzato per confrontare il nome host del client per una richiesta. Questa espressione è true per tutte le richieste che provengono da una macchina nel dominio ibm.com. Racchiudere i letterali delle stringhe tra virgolette. Non racchiudere i letterali numerici tra virgolette. È possibile utilizzare anche le parentesi con gli operatori AND, OR e NOT in modo da formare espressioni booleane composte. Fare riferimento alla specifica JMS 1.1 per una descrizione dettagliata.
WebSphere Extended Deployment supporta gli operatori riportati di seguito nelle espressioni delle regole. Tali operatori sono detti predicati in quanto vengono visualizzati all'interno di una clausola WHERE o HAVING. Gli operatori non sono sensibili al maiuscolo/minuscolo.
Operatore | Descrizione |
---|---|
OR | L'operatore logico OR. |
AND | L'operatore logico AND. |
NOT | L'operatore di negazione. |
IN | Viene utilizzato per esprimere un operando con più valori in un 'unica espressione. Il suo significato è coerente con il significato standard
SQL dell'operatore. Ad esempio, se per un operando denominato port, un utente vuole esprimere che il valore di porta può essere qualunque di tutti i seguenti valori 9080,
9090, 9091, il frammento dell'espressione è: port IN (9080,9090,9091) In SQL, il modo in cui i valori vengono espressi tra parentesi dipende dal tipo di dati della porta. Se port è valore intero ,un numero, in generale) allora i valori senza virgolette sono corretti dal punto di vista della sintassi. Se invece il valore di port è unastringa, l'espressione corretta è:
port IN (‘9080’, ‘9090’, ‘9091’) |
LIKE | Utilizzato per esprimere le associazioni dei modelli per i valori dell'operando stringa e il suo significato e utilizzo è coerente con quanto definito dal linguaggio SQL. Il valore deve contenere il carattere jolly (%)
nella posizione in cui inizia il modello corrispondente. Ad esempio, l'espressione:
host LIKE %blancacorrisponde alla parola blanca o a qualsiasi altra parola che termina in blanca, mentre l'espressione: host LIKE blanca%corrisponde alla parola blanca o a qualsiasi altra parola che inizia con blanca. L'espressione: host LIKE %blanca%corrisponde alla parola blanca o a qualsiasi altra parola che ha la parte blanca all'interno di essa. Dal punto di vista di implementazione del codice, verrà utilizzata la classe java.util.regex.Pattern. |
= | L'operatore di uguaglianza utilizzato per esprimere un'associazione in formato sensibile al maiuscolo/minuscolo. |
> | L'operatore maggiore di da utilizzare con gli operandi numerici. |
>= | L'operatore maggiore o uguale a da utilizzare con gli operandi numerici. |
< | L'operatore minore di da utilizzare con gli operandi numerici. |
<= | L'operatore minore o uguale a da utilizzare con gli operandi numerici. |
< > | L'operatore diverso da. |
BETWEEN | Utilizzato insieme all'operatore AND per selezionare una scala di valori che includono il primo valore (basso) e l'ultimo valore (alto). Insieme, operano sui numeri e sulle date. |
IS NULL | Verifica che un operando abbia un valore NULL. |
IS NOT NULL | Verifica che un operando abbia un valore diverso da NULL. |
Related concepts
Classificazione delle richieste basate sulle regole ODR
Related tasks
Definizione di una politica di servizio
Attivazione di edizioni simultanee
Convalida di un'edizione