Mit einer Arbeitsklasse können Sie Anforderungen klassifizieren, um eine Policy auf eine Anforderung anzuwenden. Auf eine Anforderung können zwei Arten von Policys angewendet werden: Routing-Policys und Service-Policys. Sie können Routing-Policys für HTTP- und SOAP-Anforderungen erstellen. Sie können Service-Policys für HTTP-, IIOP-, SOAP- und JMS-Anforderungen erstellen. Außerdem können Arbeitsklassen Klassifizierungsregeln für beide Policy-Typen enthalten. Dies gilt jedoch nicht für JMS. Klassifizierungsregeln werden für JMS-Arbeitsklassen nicht unterstützt. Routing- und Service-Policys für Arbeitsklassen werden für IIOP- und JMS-Anforderungen für Anwendungen, die unter z/OS implementiert sind, nicht unterstützt. WebSphere Application Server z/OS unterstützt die IIOP- und JMS-Serviceklassifikation.
Routing-Policy | Beschreibung |
---|---|
permit:<Anwendungsname> | In dieser Routing-Policy steht Anwendungsname für den Namen der Zielanwendung, der eine optionale Editionsangabe enthalten kann. Auf diese Weise kann die Anforderung normal weiterverarbeitet werden. |
permitsticky:<Anwendungsname> | Die Routing-Policy permitsticky entspricht im Wesentlichen der Routing-Policy "permit". Die einzige Ausnahme ist, dass der On Demand Router (ODR) auch die Client/Server-Affinität für künftige Anforderungen verwaltet, die von demselben Client stammen. In diesem Fall fügt der ODR der Antwort den Header SET-COOKIE hinzu, bevor er die Antwort an den Client sendet. |
reject:<HTTP-Fehlercode> | Diese Routing-Policy bewirkt, dass der ODR alle Anforderungen mit dem angegebenen HTTP-Fehlercode zurückweist. reject:503 gibt beispielsweise einen Fehler vom Typ 503, Service ist nicht verfügbar, zurück. |
redirect:<URL> | Mit dieser Routing-Policy leitet der ODR die Anforderung an den angegebenen URL um. Der URL hat das Muster Protokoll:// ;. Ein Beispiel für einen gültigen URL ist http://w3.ibm.com. |
Die gültigen Service-Policys sind nicht anderes als eine Liste mit Namen von Transaktionsklassen. Die Transaktionsklasse verweist auf eine einzelne Serviceklasse.
Es sind vier Arten von Arbeitsklassen verfügbar:
Arbeitsklasse | Beschreibung |
---|---|
Routing-Policy für Anwendung | Gibt an, wie die Routing-Policy für eine Anforderung an eine in WebSphere Extended Deployment installierte Anwendung bestimmt wird. |
Service-Policy für Anwendung | Gibt an, wie die Service-Policy für eine Anforderung an eine in WebSphere Extended Deployment installierte Anwendung bestimmt wird. |
Generische Routing-Policy für Server-Cluster | Gibt an, wie die Routing-Policy für eine Anforderung an einen generischen Server-Cluster bestimmt wird. |
Generische Service-Policy für Server-Cluster | Gibt an, wie die Service-Policy für eine Anforderung an einen generischen Server-Cluster bestimmt wird. |
Die folgende Abbildung veranschaulicht einen Anforderungsfluss, der für eine Anwendung bestimmt ist, die in WebSphere Extended Deployment installiert ist. Zur Bestimmung der Routing-Policy wird auf die Anforderung eine Arbeitsklasse für Routing-Policys für Anwendungen angewendet. Wenn das Ergebnis permit oder permitsticky ist, wird auf die Anforderung eine Arbeitsklasse für Service-Policys für Anwendungen angewendet, um die Service-Policy und den Namen der Transaktionsklasse zu bestimmen.
Jede Anwendung enthält Standardarbeitsklassen für Routing- und Service-Policys für Anwendungen. Sie können jedoch weitere Arbeitsklassen erstellen. Jede Arbeitsklasse hat eine Standardaktion. Die Standard-Routing-Policy für eine Anwendung ist permit:<Anwendungsname>. Die Standard-Service-Policy ist Default_TC, die Standardtransaktionsklasse.
Jede Arbeitsklasse enthält eine optional sortierte Liste mit Regeln, die für eine bestimmte Anforderung ausgewertet werden, um die Policy für diese Anforderung zu bestimmen. Jede Regel setzt sich aus einem Booleschen Ausdruck und einem Policy-Wert zusammen. Wenn die Auswertung des Ausdrucks für eine bestimmte Anforderung den Wert "true" ergibt, wird die Policy verwendet, die dieser Regel zugeordnet ist.
Die Syntax und die Semantik eines Booleschen Ausdrucks für eine Regel gleichen der WHERE-Klausel eines SQL-Ausdrucks (Structured Query Language). Genauer gesagt, die Syntax eines Ausdrucks wird durch die Spezifikation Java Message Service (JMS) 1.1 definiert. Nähere Informationen hierzu finden Sie im Artikel Regelbasierte Anforderungsklassifizierung für ODR.
In der JMS-Spezifikation verweisen Kennungen auf verschiedene Attribute, die einer Anforderung zugeordnet werden können, z. B. ein bestimmter Abfrageparameter, ein Cookie oder ein HTTP-Header. Eine JMS-Kennung ist mit einer Anforderungsvariablen (oder Operanden) vergleichbar. Diese Operanden können protokollspezifisch sein. Der SOAP-Servicename ist beispielsweise ein Operand, der nur in einer SOAP-Arbeitsklasse gültig ist.
Die Liste der Operanden ist zwar dynamisch, aber die hier aufgeführten sind die Basisoperanden. Eine erweiterte Liste finden Sie in der Dokumentation zum jeweiligen Produkt. In der folgenden Tabelle sind die Operanden und die zugehörigen Protokolle aufgelistet:
Anforderungsvariable | Gültige Protokolle | Beschreibung |
---|---|---|
|
IIOP | Der Name der Enterprise-Anwendung mit der EJB. |
clienthost | HTTP SOAP
|
Der vollständig qualifizierte Hostname des Clients. Dies ist der Wert des IP-Befehls "host". Dieser Operand unterstützt keine numerischen Operatoren wie >, >=, <, <=. |
|
IIOP | Der Name des Client-Port. |
clientipv4 | HTTP SOAP |
Die IP-Adresse der Clientmaschine im IPv4-Format (Internet Protocol Version 4) n.n.n.n. |
clientipv6 | HTTP SOAP |
Die 128-Bit-Adresse der Clientmaschine im IPv6-Format (Internet Protocol Version 6) x:x:x:x:x:x:x:x gemäß RFC (Request for Comments) 1924. |
cookie$<Name> | HTTP SOAP |
Der Name eines Cookie. Der Ausdruck cookie$Mein_Cookie-Name='Mein_Cookie-Wert' prüft
beispielsweise, ob eine Anforderung ein Cookie mit dem Namen Mein_Cookie-Name und dem Wert
Mein_Cookie-Wert enthält. Verwenden Sie die folgenden Ausdrücke, um zu prüfen, ob ein bestimmtes
Cookie vorhanden bzw. nicht vorhanden ist:
cookie$MeinCookieName IS NOT NULL cookie$MeinCookieName IS NULL |
|
IIOP | Der Modulname einer EJB. |
|
IIOP | Der Name einer EJB. |
|
IIOP | Der Name einer Methode in der EJB. |
gid | HTTP SOAP |
Eine Gruppen-ID des Anforderungssenders. |
header $<Name> | HTTP SOAP |
Ein Header-Name und -Wert. Der Ausdruck header$Host='localhost' prüft beispielsweise, ob eine Anforderung
einen HTTP-Host-Header mit dem Wert localhost enthält.
Verwenden Sie die folgenden Ausdrücke, um zu prüfen, ob der Host-Header vorhanden bzw. nicht vorhanden ist:
cookie$Host IS NOT NULL cookie$Host IS NULL |
HTTPMethod | HTTP SOAP |
Die HTTP-Methode für die Anforderung. Die gültigen Werte sind POST, GET, PUT und DELETE. |
MIMEType | HTTP SOAP |
Der MIME-Typ der Anforderung. |
operation | SOAP | Der Name einer Web-Services-Operation. |
port | HTTP SOAP IIOP |
Der Port, an dem die Anforderung empfangen wurde. |
protocol | HTTP SOAP |
Das Kommunikationsprotokoll, mit dem die Anforderung übertragen wird. Die derzeit unterstützten Protokolle sind HTTP, HTTPS, SOAP und SOAPS. |
queryparm$<Name> | HTTP SOAP |
Ein Header-Name und -Wert. Der Ausdruck queryparm$timezone='EST' prüft beispielsweise,
ob die Anforderung einen HTTP-Abfrageparameter mit dem Namen timezone und dem Wert
EST enthält. Verwenden Sie die folgenden Ausdrücke, um zu prüfen, ob ein bestimmter
Abfrageparameter vorhanden bzw. nicht vorhanden ist:
queryparm$timezone IS NOT NULL queryparm$timezone IS NULL |
serverhost | HTTP SOAP
|
Der vollständig qualifizierte Hostname des Servers. Dieser Operand unterstützt keine numerischen Operatoren wie >, >=, <, <=. |
serveripv4 | HTTP SOAP |
Die IP-Adresse der Servermaschine im IPv4-Adressformat n.n.n.n. |
serveripv6 | HTTP SOAP |
Die 128-Bit-Adresse der Servermaschine im IPv6-Format x:x:x:x:x:x:x:x gemäß RFC 1924. |
service | SOAP |
Der Name eines Web Service. |
uid | HTTP SOAP |
Die Benutzer-ID des Anforderungssenders. |
clienthost LIKE '%.ibm.com'ist '%.ibm.com' beispielsweise ein Literal, das mit dem Clienthostnamen der Anforderung verglichen wird. Für alle Anforderungen, die von einer Maschine in der Domäne ibm.com stammen, wird dieser Ausdruck mit "true" ausgewertet. Schließen Sie Zeichenfolgeliterale in einfache Anführungszeichen ein. Numerische Literale dürfen nicht nicht in einfache Anführungszeichen eingeschlossen werden. Zum Erstellen zusammengesetzter Boolescher Ausdrücke können Sie runde Klammern zusammen mit den Operatoren AND, OR oder NOT verwenden. Eine detaillierte Beschreibung finden Sie in der Spezifikation JMS 1.1.
WebSphere Extended Deployment unterstützt die folgenden Operatoren in Regelausdrücken. Diese Operatoren werden in der SQL-Terminologie auch als Prädikate bezeichnet, weil sie innerhalb einer Klausel WHERE oder HAVING verwendet werden. Bei der Schreibweise von Operatoren wird nicht zwischen Groß- und Kleinschreibung unterschieden.
Operator | Beschreibung |
---|---|
OR | Der logische Operator OR. |
AND | Der logische Operator AND. |
NOT | Der Operator für Negation. |
IN | Wird für die Angabe von Operanden mit mehreren Werten in einem Ausdruck verwendet.
Die Bedeutung dieses Operators ist mit der SQL-Standardbedeutung konform.
Wenn Sie beispielsweise für einen Operanden mit dem Namen port ausdrücken möchten,
dass der Port-Wert einem der angegebenen Werte oder allen angegebenen Werten, wie z. B. 9080,
9090, 9091 entsprechen kann, geben Sie das folgende Ausdrucksfragment an:
port IN (9080,9090,9091) Wie die Werte in den eckigen Klammern in
SQL ausgedrückt werden, richtet sich nach dem Datentyp von port.
Wenn port den Datentyp integer hat, sind die Werte ohne einfache Anführungszeichen
syntaktisch korrekt. Wenn port den Datentyp string hat, ist der korrekte Ausdruck wie folgt:
port IN ('9080','9090','9091') |
LIKE | Dieser Operator wird verwendet, um die Mustererkennung für
die Werte von Zeichenfolgeoperanden auszudrücken. Bedeutung und Verwendung dieses Operators entsprechen der Definition
in der Programmiersprache SQL.
Der Wert muss das Platzhalterzeichen (%) an der Position enthalten, an der die Mustererkennung
beginnen soll.
Beispiel:
host LIKE %blancaDieser Ausdruck entspricht dem Wort blanca und allen anderen Wörtern, die mit blanca enden. Der folgende Ausdruck hingegen entspricht dem Wort blanca und allen anderen Wörtern, die mit blanca beginnen: host LIKE blanca%Der folgende Ausdruck entspricht dem Wort blanca und allen anderen Wörtern, in denen blanca eingebettet ist: host LIKE %blanca% Aus Sicht einer Codeimplementierung wird die Klasse java.util.regex.Pattern verwendet. |
= | Der Gleichheitsoperator wird verwendet, um eine exakte Übereinstimmung inklusive Groß-/Kleinschreibung zu finden. |
> | Der Größer-als-Operator wird für numerische Operanden verwendet. |
>= | Der Größer-gleich-Operator wird für numerische Operanden verwendet. |
< | Der Kleiner-als-Operator wird für numerische Operanden verwendet. |
<= | Der Kleiner-gleich-Operator wird für numerische Operanden verwendet. |
< > | Nicht-gleich-Operator. |
BETWEEN | Dieser Operator wird zusammen mit dem Operator AND verwendet, um einen Bereich von Werten einschließlich des ersten (niedrigsten) und des letzten (höchsten) Wertes auszuwählen. Diese Operationen werden für Zahlen und Datumsangaben verwendet. |
IS NULL | Prüft, ob ein Operand den Wert NULL hat. |
IS NOT NULL | Prüft, ob ein Operand einen anderen Wert als NULL hat. |
Related concepts
Regelbasierte Anforderungsklassifizierung für ODR
Related tasks
Eine Service-Policy definieren
Editionen gleichzeitig aktivieren
Eine Edition validieren