WebSphere Extended Deployment, Version 6.0.x     Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Routing- und Service-Policys für Arbeitsklassen

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.

Gültige Routing-Policys

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.

Arbeitsklassen

Es sind vier Arten von Arbeitsklassen verfügbar:

Table 1. Typen von Arbeitsklassen
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.

Regeln

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:

Table 2. Operanden
Anforderungsvariable Gültige Protokolle Beschreibung

[Version 6.0.1 and later] application

IIOP Der Name der Enterprise-Anwendung mit der EJB.
clienthost

HTTP

SOAP

[Version 6.0.1 and later] IIOP

Der vollständig qualifizierte Hostname des Clients. Dies ist der Wert des IP-Befehls "host". Dieser Operand unterstützt keine numerischen Operatoren wie >, >=, <, <=.

[Version 6.0.1 and later] clientport

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

[Version 6.0.1 and later] ejbmodule

IIOP Der Modulname einer EJB.

[Version 6.0.1 and later] ejbname

IIOP Der Name einer EJB.

[Version 6.0.1 and later] ejbmethod

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

[Version 6.0.1 and later] IIOP

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.
Da SOAP über HTTP ausgeführt wird, gelten die HTTP-Operanden gleichermaßen für SOAP-Anforderungen. Die JMS-Spezifikation verwendet Literale, um einen bestimmten Wert für einen Vergleich mit einer Anforderungsvariablen anzugeben. Im Ausdruck
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.

Operatoren

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.

Table 3. Operatoren für Anforderungsklassifizierung
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 %blanca
Dieser 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

Referenzartikel    

Nutzungsbedingungen | Feedback Letzte Aktualisierung: Mar 23, 2006 9:51:53 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/rodrworkclass.html

© Copyright IBM 2005, 2006. Alle Rechte vorbehalten.
Dieses Information Center beruht auf der Eclipse-Technologie. (http://www.eclipse.org)