Richtlinien

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.

Richtlinien in WSRR

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.

Zusicherungen für Mediationsrichtlinien

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.

Bedingungen für Mediationsrichtlinien

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.

Für den Zeitplan können die folgenden Parameter angegeben werden:
  • StartDate - Dieses optionale Attribut gibt das Datum im xs:date-Format an, an dem der Zeitplan wirksam wird. Das Attribut 'StartDate' wird inklusiv interpretiert. Wenn dieses Attribut nicht vorhanden ist, tritt der Zeitplan unverzüglich am selben Tag in Kraft.
    Anmerkung: Klicken Sie auf den Hyperlink 'xs:date', um Informationen zu diesem Industriestandard anzuzeigen.
  • StopDate - Dieses optionale Attribut gibt das Datum im xs:date-Format an, an dem der Zeitplan beendet wird. Das Attribut 'StopDate' wird exklusiv interpretiert und das angegebene Datum muss nach dem Startdatum liegen. Wenn das Stoppdatum vor dem Startdatum liegt oder mit dem Startdatum identisch ist, wird der Zeitplan nie wirksam. Wenn dieses Attribut nicht angegeben wird, wird der Zeitplan für unbegrenzte Zeit in Kraft gesetzt.
  • Daily - Dieses optionale Element gibt den täglichen Zeitrahmen an, in dem der Zeitplan in Kraft ist. Wenn dieses Element nicht angegeben wird, ist der Zeitplan für die Dauer des gesamten Tags in Kraft.
    • StartTime – Dieses Attribut ist bei Angabe von 'Daily' erforderlich. Es gibt die Uhrzeit im xs:time-Format an, zu der der Zeitplan täglich gestartet wird. (Anmerkung: Klicken Sie auf den Hyperlink 'xs:time', um Informationen zu diesem Industriestandard anzuzeigen.)
    • StopTime - Dieses Attribut ist bei Angabe von 'Daily' erforderlich. Es gibt die Uhrzeit im xs:time-Format an, zu der der Zeitplan täglich beendet wird. Das Attribut 'StopTime' wird exklusiv interpretiert. Wenn die angegebene Zeit vor der Startzeit liegt oder mit dieser identisch ist, wird der Zeitplan zur angegebenen Zeit am darauf folgenden Tag gestoppt.
  • Weekdays - Dieses optionale Element gibt die Tage der Woche an, die in den Zeitplan einbezogen werden. Wenn dieses Element nicht angegeben wird, werden alle Wochentage in den Zeitplan einbezogen. Dieses Element betrifft nur den Start des täglichen Zeitrahmens, da Zeitpläne über Mitternacht hinaus ausgeführt werden können. Wenn ein Zeitplan zum Beispiel zum Start um 23:00 Uhr und zur Ausführung für 2 Stunden am Mittwoch eingestellt ist, wird der Zeitplan tatsächlich am Donnerstag um 01:00 Uhr beendet.
    • Days - Dieses Attribut ist bei Angabe von 'Weekdays' erforderlich. Es listet die Wochentage auf, die in den Zeitplan einbezogen werden. Dies erfolgt in Form einer Liste von Namen, die durch ein Pluszeichen ('+') getrennt werden. Beispiel: “Monday+Tuesday+Wednesday+Thursday+Friday+Saturday+Sunday”.

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.

Die folgenden Parameter können für den Ausdruck angegeben werden:
  • Attribut - In der folgenden Tabelle sind die definierten Attribute mit ihrem jeweiligen Typ aufgeführt.
    Tabelle 1. Definierte Attribute
    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 - In der folgenden Tabelle sind die verfügbaren Operatoren und ihre Bedeutung aufgeführt:
    Tabelle 2. Operatoren
    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.
    1. Der Bucket beginnt voll mit einer maximalen Kapazität von 100 Tokens.
    2. Wenn eine Nachricht eintrifft, überprüft der Algorithmus, ob der Bucket Tokens enthält:
      1. Ist dies der Fall, liefert der Algorithmus das Ergebnis 'falsch' und ein Token wird aus dem Bucket entfernt.
      2. Ist dies nicht der Fall, liefert der Algorithmus das Ergebnis 'wahr'.
    3. Währenddessen fügt der Algorithmus jede Sekunde je nach Platz fünf Tokens dem Bucket wieder hinzu.
    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.
  • Value – Dies ist ein Element für den Wert einer positiven ganzen Zahl (Integer). Der Wert “0” ist gültig.
  • Interval - Dieses optionale Element definiert im xs:duration-Format das Zeitintervall, das als gleitendes Fenster zum Messen des Elements 'wsme:Attribute' bei der Auswertung des Ausdrucks verwendet wird. Wenn dieses Element nicht angegeben wird, wird ein Intervall von 60 Sekunden verwendet. Wenn es angegeben wird, muss ein angemessener Wert angegeben werden, der die konfigurierten Funktionen des Richtliniendurchsetzungspunkts (PEP) berücksichtigt. Das heißt, je höher dieser Wert ist, desto mehr Speicher benötigt der Richtliniendurchsetzungspunkt zur Verfolgung des Attributs.
    Anmerkung: Klicken Sie auf den Hyperlink 'xs:duration', um Informationen zu diesem Industriestandard anzuzeigen.
  • Limit - Dieses optionale Ganzzahlelement definiert das zusätzliche Begrenzungsargument, das erforderlich ist, wenn für 'wsme:Operator' der Operator 'TokenBucket' oder 'HighLow' angegeben wird. Die Einheit hängt vom angegebenen Element 'wsme:Operator' ab.

    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.

Aktionen von Mediationsrichtlinien

Das Mediationsaktionselement gibt die Aktionen an, die auszuführen sind. Obwohl die Syntax viele Kombinationen zulässt, sind nicht alle von ihnen sinnvoll. Wenn widersprüchliche Aktionen angegeben werden, zum Beispiel, dass eine Nachricht sowohl in die Warteschlange gestellt als auch zurückgewiesen werden soll, wird dieses Verhalten vom Richtlinienerstellungspunkt zurückgewiesen. Die folgenden Aktionen sind für Mediationsrichtlinien zulässig:
  • QueueMessage – Diese Aktion gibt an, dass Transaktionen in die Warteschlange eingereiht werden, wenn die logische Bedingung zutrifft. Die Nachrichtenverarbeitung wird erst wieder begonnen, wenn die logische Bedingung nicht mehr erfüllt ist. Die Warteschlangenmethodik und damit verbundene Zeitlimits werden durch den Richtliniendurchsetzungspunkt definiert. In diesem Fall ist dies WebSphere DataPower. Wenn mehrere Aktionen innerhalb eines Aktionselements angegeben werden, muss 'QueueMessage' die erste Aktion sein.
  • RejectMessage – Diese Aktion gibt an, dass Transaktionen zurückgewiesen werden, wenn die logische Bedingung zutrifft. Transaktionen werden so lange zurückgewiesen, bis die logische Bedingung nicht mehr zutrifft. Wenn Transaktionen zurückgewiesen werden, wird ein SOAP-Fehler an den Client-Service (Konsumentenservice) zurückgegeben. Wenn mehrere Aktionen innerhalb eines Aktionselements angegeben werden, muss 'RejectMessage' die erste Aktion sein. Die Aktionen 'QueueMessage' und 'RejectMessage' schließen sich gegenseitig aus.
  • Notify - Dieses optionale Element gibt an, dass eine Benachrichtigung generiert wird, wenn die logische Bedingung zutrifft. Für WebSphere DataPower wird eine Nachricht in das DataPower-Systemprotokoll geschrieben.
  • RouteMessage - Dieses optionale Element gibt an, dass Nachrichten an das angegebene Endpunktziel geleitet werden, wenn die logische Bedingung zutrifft. Nachrichten werden so lange an den angegebenen Endpunkt geleitet, bis die logische Bedingung nicht mehr zutrifft.
    • EndPoint – Dieser Parameter ist erforderlich, wenn die Aktion 'RouteMessage' angegeben wird. Als Endpunktwert wird eine IP-Adresse, ein Hostname oder ein virtueller Host, zum Beispiel die Lastausgleichsgruppe, unterstützt.
  • ValidateMessage - Dieses optionale Element gibt an, dass Nachrichten an den angegebenen Grammatiken überprüft werden sollen. Nachrichten sollen zurückgewiesen werden, wenn die Überprüfung fehlschlägt. Wenn 'ValidateMessage' angegeben wird, muss als Unterparameter entweder 'XSD' oder 'WSDL' angegeben werden. 'SCOPE' ist optional. Wenn 'SCOPE' nicht angegeben wird, wird 'SOAPBody' für die Überprüfung verwendet.
    • XSD - Gibt an, dass Nachrichten an dem XML-Schema überprüft werden, das durch die enthaltene URI-Adresse angegeben wird.
    • WSDL - Gibt an, dass Nachrichten an der Web-Service-Beschreibung (WSDL) überprüft werden, die durch die enthaltene URI-Adresse angegeben wird.
    • SCOPE – Gibt an, welcher Teil der Nachricht überprüft wird. In der folgenden Tabelle sind die möglichen Werte mit ihrer Bedeutung aufgeführt:
      Tabelle 3. ValidateMessage-Elemente
      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).
  • ExecuteXSL - Gibt an, dass eine XSL-Transformation mit dem angegebenen Style-Sheet und den angegebenen Parametern ausgeführt wird. Transaktionen werden zurückgewiesen, wenn die Ausführung fehlschlägt. Für 'Stylesheet' müssen Informationen angegeben werden, während Informationen für 'Parameter' optional sind und angegeben werden sollten, wie dies für das jeweils angegebene Style-Sheet erforderlich ist.
    • Stylesheet - Gibt an, dass die Transformationsoperation das durch die enthaltene URI-Adresse angegebene Style-Sheet verwendet. Das Style-Sheet muss eine XSLT-Datei sein.
    • Parameter - Dieses optionale, sich wiederholende Element gibt einen Style-Sheet-Parameter an, der für die ExecuteXSL-Operation zu verwenden ist.
      • Name – Dieses Attribut ist für jeden entsprechenden Parameter 'Parameter' erforderlich und gibt den Namen des Parameters an.
      • Value - Dieses Attribut ist für jeden entsprechenden Parameter 'Name' erforderlich und gibt den Wert des Parameters an.

Konzept Konzept

Feedback


Timestamp icon Letzt aktualisiert: 16. Oktober 2012


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