In diesem Abschnitt werden Implementierungsdetails für die Verwendung von WSRR als Richtlinienerstellungspunkt (PAP, Policy Authoring Point) und WebSphere DataPower als Richtliniendurchsetzungspunkt (PEP, Policy Enforcement Point) bei der Erstellung von Mediationsrichtlinien beschrieben.
WSRR (WebSphere Service Registry and Repository) kann zum Verfassen (Authoring) aller SOA-Richtlinien verwendet werden. Dazu gehören SLA-Richtlinien (SLA, Service-Level-Agreement), Mediationsrichtlinien, angepasste Richtlinien und andere Richtliniendomänen, deren Unterstützung für die Zukunft vorgesehen ist. Über die Business Space-Benutzerschnittstelle können Sie ein Richtliniendokument in WSRR erstellen, aktualisieren oder löschen. Das Richtliniendokument kann einen Richtlinienausdruck enthalten, der eine Reihe von Richtlinien für eine bestimmte Richtliniendomäne angibt. Alternativ können Sie ein Richtliniendokument erstellen, das vorhandene Richtlinien aus anderen Dokumenten zusammenstellt. Einzelne Richtlinien werden durch Richtlinienkennungen (IDs) angesprochen, die Sie angeben, wenn Sie Ihrem Dokument Richtlinien hinzufügen. Ein Richtlinienausdruck stellt die Deklaration einer Richtlinie dar und entspricht einem Element <wsp:Policy> in einem WS-Policy-Dokument.
Informationen zur Erstellung einer Mediationsrichtlinie in Business Space finden Sie in Neue Richtlinien erstellen.
Service-Level-Agreements (SLAs) ergeben sich für ein Unternehmen meist aus der Anforderung, dass die Servicequalität, die durch einen Service bereitgestellt wird, einem angegebenen Standard entsprechen muss. Beim Entwurf eines Service werden Funktionsanforderungen ausgearbeitet, um die Logik der Aktionen des Service vorzugeben. Parallel dazu sollten im Rahmen der Analyse und des Entwurfs dieses Service nicht funktionale Anforderungen definiert werden, um die Servicequalität (QOS, Quality of Service) festzulegen, die von diesem Service erwartet wird. Zum Beispiel könnte das Unternehmen einen Service haben, der Informationen als Antwort auf eine Internetabfrage eines Kunden liefert. Ziel ist es, die Antwort binnen drei Sekunden zurückzugeben. Bei der Entwicklung der Gesamttransaktion könnte festgelegt werden, dass dieser Service seine Informationen innerhalb von zwei Sekunden zurückgeben muss, um die nicht funktionalen Anforderungen des Unternehmens zu erfüllen.
Es kann eine Richtlinie verfasst werden, die Laufzeitprüfungen der Leistung des Service implementiert und Aktionen ausführt, wenn das SLA nicht erfüllt wird, um zu garantieren, dass der Service das für ihn definierte SLA erfüllt. Es könnte zum Beispiel ein primärer Serviceendpunkt vorhanden sein, der normalerweise (in 95 % der Fälle) eine Serviceantwort innerhalb von zwei Sekunden liefert. Der SOA-Architekt hat einen zweiten Serviceendpunkt auf einem anderen Server erstellt, der normalerweise als Server im Bereitschaftsmodus für Ausfälle des primären Endpunkts eingesetzt wird, jedoch auch bei hoher Frequentierung genutzt werden darf, wenn der primäre Endpunkt mit der Transaktionslast nicht Schritt halten kann. Für diese Situation kann eine Richtlinie verfasst werden, die die Serviceantwortzeit überprüft und den Netzdatenverkehr umleitet, wenn dies zur Erfüllung des SLA erforderlich ist.
Ein weiteres Beispiel, in dem SLAs durch eine Laufzeitrichtlinie verwaltet werden, ist eine Situation, in der ein Service auf Transaktionen antwortet, die eine größere Anzahl von Konsumenten mit jeweils unterschiedlichen Prioritäten haben. Ein einfaches Beispiel könnten Kunden der Kategorien “Gold” und “Bronze” sein, wobei nur für Kunden der Kategorie “Gold” eine bestimmte Servicequalität garantiert wird. In diesem Beispiel könnte geprüft werden, ob es sich bei dem Kunden um einen Kunden der Kategorie “Gold” handelt. Wenn dies der Fall ist, könnte der Kunde an den sekundären Endpunkt umgeleitet werden, während ein Kunde der Kategorie “Bronze” mit einer langsameren Antwortzeit bedient würde. Das Unternehmen hat diese Entscheidung getroffen, da “Bronze”-Kunden nicht ausreichend Umsatzwachstum generieren, um den Aufwand für die Entwicklung einer Antwortzeit zu rechtfertigen, die das SLA für “Gold”-Kunden erfüllt.
Ein drittes Beispiel könnte eine Situation sein, in der ein Service am Leistungslimit arbeitet, jedoch Nachrichten von Konsumentenservices niedriger Priorität in eine Warteschlange stellt oder sogar zurückweist, wenn er feststellt, dass er sich unter hoher Auslastung befindet. Ein Beispiel dieser Art wäre eine Stapelroutine, die das System mit Konsumentenanfragen zu einem unerwarteten Zeitpunkt überflutet. Zur Aufrechterhaltung der Servicequalität könnte eine Laufzeitrichtlinie erstellt werden, die nur während der Geschäftsstunden in Kraft ist und die alle Stapelverarbeitungsanforderungen in diesem Zeitraum zurückweist.
Allgemeiner formuliert ermöglicht eine Mediationsrichtlinie eine Überprüfung und Transformation der vom Client (Konsumenten) eingehenden Nachricht, bevor die Nachricht dem Server (Provider) zugestellt wird.
Richtlinien unterstützen eine solche Überprüfung und Transformation von Nachrichten. Richtlinien können für einen Provider-Service allein, für ein bestimmtes Konsumenten-Provider-Paar oder für anonyme Konsumenten für einen Provider-Service angegeben werden. Richtlinien für anonyme Konsumenten stellen eine Methode bereit, eine Standardrichtlinie zu definieren, die nur für Konsumenten gilt, für die keine anderen Richtlinien gelten. Mithilfe dieser Funktionalität können Richtlinien für Fremdkonsumenten angegeben werden, die ihre Identität nicht preisgeben. Für solche Konsumentenservices könnten Transaktionen dann zum Beispiel zurückgewiesen werden. Dies kann zum Schutz gegen Denial-of-Service-Attacken von Konsumentenhackern nützlich sein, die versuchen, das System mit Transaktionen zu überfluten, um einen Provider-Service außer Gefecht zu setzen.
Es können Mediationszusicherungen ('Assertions') erstellt werden, die es der Laufzeitrichtlinie ermöglichen, das Service-Level-Agreement (SLA) des Service zu steuern, die Umwandlung (Transformation) von Nachrichten vom Kunden zum Provider zu steuern oder das Nachrichtenschema der Kundennachricht zu validieren.
SLA-Richtlinienbedingungen stellen einen besonderen Typ von Mediationsrichtlinie dar, der ein klassisches If-Then-Else-Konstrukt mit einer Bedingung und einem Satz von Aktionen ermöglicht, die je nach Auswertung der Bedingung ausgeführt werden. Die Angabe einer Bedingung ist optional. Wenn keine Bedingung angegeben wird, ist dies mit der Auswertung der logischen Bedingung als 'wahr' äquivalent, sodass alle angegebenen Aktionen entsprechend umgesetzt werden.
Wenn eine Bedingung angegeben wird, muss sie aus einem booleschen Ausdruck oder einer Zeitplanangabe bestehen. Sie kann auch beides beinhalten.
Zeitplan
Der Zeitplan ('schedule'), sofern angegeben, definiert, wann die Richtlinie in Kraft ist. Der angegebene Wert für Datum und Uhrzeit wird durch den lokalen Richtliniendurchsetzungspunkt (PEP) ausgewertet, wobei die Zeitzone des Richtliniendurchsetzungspunkts verwendet wird. Wenn kein Zeitplan angegeben wird, wird die Richtlinie gestartet, sobald sie vom Richtlinienerstellungspunkt (PAP) auf den Richtliniendurchsetzungspunkt heruntergeladen wird. Die Ausführung wird unbegrenzt fortgesetzt.
Der Zeitplan definiert ein optionales Startdatum und ein optionales Stoppdatum, einen optionalen täglichen Zeitrahmen und eine optionale Liste von Wochentagen. Zum Beispiel kann ein Zeitplan so definiert werden, dass die Richtlinie vom 1. Oktober 2012 bis zum 30. Oktober 2012 jeweils von 08:00 bis 17:00 Uhr mittwochs und sonntags in Kraft ist.
Bedingungsausdruck für eine Mediationsrichtlinie
Der Bedingungsausdruck, sofern er angegeben wird, ist ein sich nicht wiederholendes Element, das einen booleschen Ausdruck angibt.
Der Ausdruck enthält drei erforderliche Parameter, die aus Attribut, Operator und Wert bestehen, sowie zwei optionale Parameter für ein Intervall und eine Begrenzung ('Limit'). Wenn die Anwendung des Operators mit dem Attribut und dem Wert sowie das Intervall und die Begrenzung, sofern zutreffend, als wahr ausgewertet werden, wird der Ausdruck als wahr ausgewertet. Das Begrenzungselement 'Limit' wird nur in den Operatoren 'HighLow' und 'TokenBucket' verwendet. Wenn es nicht angegeben wird, ist der Wert von Limit gleich 0. Wenn kein Intervall angegeben wird, gilt der Standardwert von 60 Sekunden.
Attribut | Beschreibung und Typ |
---|---|
ErrorCount | Die Anzahl der Fehler, die in diesem Überwachungsintervall festgestellt wurden. |
MessageCount | Die Anzahl der tatsächlichen Nachrichten, die während des Überwachungsintervalls abgefangen wurden. |
InternalLatency | Die interne Latenzzeit (Verarbeitungszeit) in Sekunden. |
BackendLatency | Die Gerät-zu-Server-Latenzzeit in Sekunden. |
TotalLatency | Die Summe der Back-End-Latenzzeit und der internen Latenzzeit in Sekunden. |
Operator | Bedeutung |
---|---|
GreaterThan | Ein einfacher numerischer Algorithmus, der das Auswertungsergebnis 'wahr' liefert, wenn das Attribut größer als der definierte Wert ist. |
LessThan | Ein einfacher numerischer Algorithmus, der das Auswertungsergebnis 'wahr' liefert, wenn das Attribut kleiner als der definierte Wert ist. |
TokenBucket | Ein ratenbasierter Algorithmus, der eine Geschwindigkeitssteuerung (Bursting) ermöglicht.
Der Algorithmus besteht aus einem Bucket (Tokenbehälter) mit einer maximalen Kapazität von 'Limit' Tokens. Der
Bucket wird mit einer konstanten Rate von 'Value' Tokens pro Intervall neu gefüllt, während gleichzeitig für
jede Attributeinheit ein Token entfernt wird. Dieser Algorithmus liefert das Ergebnis 'wahr', wenn
keine Tokens im Bucket vorhanden sind. Ansonsten liefert er das Ergebnis 'falsch'. Das folgende Beispiel soll
diesen Algorithmus veranschaulichen. Nehmen Sie folgende Werte an: Limit = 100, Value = 5 und Interval = 1 Sekunde sowie
Attribute=MessageCount.
|
HighLow | Ein Algorithmus, der das Ergebnis 'wahr' liefert, wenn das Attribut den oberen Schwellenwert, der als 'Value' angegeben ist, erreicht, und anschließend so lange das Ergebnis 'wahr' liefert, bis das Attribut den unteren Schwellenwert erreicht, der als 'Limit' angegeben ist. |
Wenn für 'wsme:Operator' der Wert 'HighLow' angegeben wird, definiert dieses Element den unteren Schwellenwert, während 'wsme:Value' den oberen Schwellenwert definiert. Der angegebene Schwellenwert muss niedriger als der für 'wsme:Value' angegebene Wert sein. Wenn es nicht angegeben wird, ist der Standardwert für 'Limit' gleich 0.
Wenn für 'wsme:Operator' der Wert 'TokenBucket' angegeben wird, definiert dieses Element den maximalen Steigerungswert (Burst) bzw. die maximale Anzahl von Tokens im Bucket, während 'Value' die Rate als Anzahl von Tokens pro Intervall angibt, mit der der Bucket wieder gefüllt wird. Wenn dieses Element nicht angegeben wird, ist das Standardlimit 0 und 'TokenBucket' ist in diesem Fall mit einer GreaterThan-Operation äquivalent.
Wert | Beschreibung |
---|---|
SOAPBody | Der Inhalt des SOAP-Body-Elements ohne besondere Verarbeitung in Bezug auf SOAP-Fehler (Standardwert). |
SOAPBodyOrDetails | Der Inhalt des Detailelements für SOAP-Fehler sowie ansonsten der Inhalt des Hauptteils (Body). |
SOAPEnvelope | Die gesamte SOAP-Nachricht, einschließlich Umschlag (Envelope). |
SOAPIgnoreFaults | Keine Überprüfung, ob die Nachricht ein SOAP-Fehler ist, ansonsten der Inhalt des SOAP-Hauptteils (Body). |