Seite 2: WS-Policy im Detail

Inhaltsverzeichnis

WS-Policy im Detail

Richtlinien für einen Dienst sind in seiner Beschreibung (WSDL) abzulegen (siehe Abb. 2). Die Verwendung von WS-Policy in der WSDL zeigt das folgende Quelltextfragment an:

<wsp:UsingPolicy
   wsdl:Required="true"/> 

Betrachtet man Beispiele in der Literatur oder im Web, ist oft die kürzere Form <wsp:UsingPolicy/> zu finden. Zu beachten ist hier, dass einige Service-Bus-Implementierungen existieren, die alle Richtlinien (Policies) ignorieren, wenn das zusätzliche Attribut "Required" nicht gesetzt ist. Deswegen sei es am besten dazu geschrieben, da es nicht stört.

Die folgenden Bestandteile führen die Beschreibung der Richtlinien durch – die abstrakte Beschreibung bezeichnet man auch als Policy Model:

• Policy Assertion: Sie beschreibt ein Mittel, eine Pflicht oder auch eine Verhaltenseigenschaft. Mehrere Richtlinien lassen sich einer Entität (Endpunkt, Nachricht, Operation etc.) in der WSDL zuordnen. Welche existieren, gibt die WS-Policy-Spezifikation nicht vor. Das definieren Domain-spezifische Spezifikationen (Sicherheit, Transaktion etc.). Eine Richtlinie kann für sich selbst festlegen, dass man sie ignorieren darf; zum Beispiel wenn es darum geht, die Kompatibilität zwischen zwei Parteien festzustellen, und der Policy-Vergleich sich nicht im "Lax Mode" befindet. Richtlinien definiert der Autor des Dienstes, sie lassen sich durch Ausdrücke zu Gruppen oder Alternativen zusammenfassen.
• Policy-Alternative: Sie ist eine Menge von Richtlinien. Die Menge kann auch leer sein.
• Policy: Sie stellt eine Menge von Alternativen dar. Auch sie kann leer sein.

Nach der Erarbeitung der grundlegenden Spezifikation durch das W3C, auch als WS-Policy bekannt, konnte man jetzt Domain für Domain betrachten. In jeder der Domains erfolgt eine eigenständige Definition der Richtlinien. Derzeit sind die folgenden wichtigen Spezifikationen zu finden:

• Web Service Security Policy Language (WS-SecurityPolicy): Sie beschreibt Richtlinien, die sich auf die Sicherheit der Nachricht und Nachrichtenübertragung beziehen.
• WS-Transactions: Die Spezifikation oder, besser gesagt, die unterschiedlichen Teilspezifikationen beschreiben Mechanismen für die transaktionale Kopplung von Diensten. Obwohl sie für alle Transaktionsarten definiert sind, unterstützen viele Web-Service-Engines lediglich WS-AtomicTransaction-Richtlinien plattformübergreifend.
• Web Service Reliable Messaging Policy (WS-RM Policy): Sie beschreibt die Domain-spezifischen Richtlinien für WS-ReliableMessaging. Das bedeutet zum Beispiel die garantierte Auslieferung der Nachrichten in festgelegter Reihenfolge, die Beziehungen zu WS-Security und die Qualität der Auslieferung von Nachrichten beim wiederholten Senden (garantiert, wenigstens einmal, höchstens einmal etc.).

Interoperabilität von Java und .NET

Metro ist die Bezeichnung für den Webservice-Stack in der Java Runtime Edition (JRE) sowie der Referenzimplementierung (RI). Eine der wesentlichen Eigenschaften des Stacks ist, dass er über die JAX-WS RI vollständig in die Java Standard Edition (Java SE) integriert ist. Er skaliert von einfachen Diensten bis hin zu sicheren, transaktionalen Anforderungen in nahezu beliebigen Umgebungen (also von der Standard Edition bis hin zur Enterprise-Welt).

Die Web Service Interoperability Technologies, kurz WSIT, sind der Teil von Metro, der sich aktiv mit der Interoperabilität von Diensten zwischen der Java- und der .NET-Welt beschäftigt. Früher getrennt (manch einer erinnert sich bestimmt noch an das Projekt Tango), ist es heute Bestandteil des Metro-Stacks (ab Version 1.3). Um die Interoperabilität auf hohem Niveau zu gewährleisten, arbeiten Sun und Microsoft eng zusammen.

Ausgehend von den in der JRE vorhandenen APIs, erweitert WSIT sie um neue Funktionen für die Arbeit mit Diensten. Die Abbildung 3 zeigt einen Überblick über die durch das WSIT-Projekt implementierten, unterstützten und getesteten Standards (angelehnt an Quelle metro.dev.java.net/guide.

Bootstrapping und Konfiguration

"Bootstrapping and Configuration" bezeichnet die Phase in der Entwicklung, die sich mit dem Erzeugen eines Dienstenutzers beschäftigt. Dazu wird die URL des Dienstes genutzt, um seine WSDL zu holen. Woher die Dienst-URL kommt, ist nicht Bestandteil der Spezifikation. Sie ließe sich zum Beispiel über ein Repository beziehen. Der Prozess des Bootstrappings und der Konfiguration besteht aus den folgenden Schritten:

1. Voraussetzung: Die URL für den Dienst ist vorhanden.
2. Mit der URL und dem wsimport-Werkzeug (oder einem Ant-Task) lässt sich eine WS-MetadataExchange-Anfrage zum Dienst senden. Als Antwort erhält man die Beschreibung und die Eigenschaften (Policies) des Dienstes (Sicherheit, Verfügbarkeit, Transaktionen etc.) zurück
3. Mit der WSDL ist es jetzt möglich, einen Dienstenutzer aufzubauen.
4. Ergebnis: Der Dienstenutzer kann auf den Dienst zugreifen und ihn nutzen.

Message Optimization Technology

Dienste tauschen Nachrichten unter sich oder mit dem Dienstenutzer aus. Dabei reichen die Nachrichten von einfachen Anfragen bis hin zu großen binär kodierten Dokumenten. Eine einfache Anfrage ist zum Beispiel das Buchen von Theaterkarten. Die Nachrichten sind einfach zu kodieren, und es ist sicherlich wenig Anstrengung erforderlich, um die Übertragung zu optimieren. Die Dokumente können groß sein und sind schlimmstenfalls durch einen binären Standard zu repräsentieren. Das Dokument, eingefügt in die Nachricht, führt unweigerlich zu einer großen SOAP-Nachricht. In ihr müssten zudem die binären Daten noch als Text kodiert sein.

Schließlich ist die Performance der Anwendung und des Netzwerks negativ betroffen. Im schlimmsten Fall geht das so weit, dass die Anwendung nicht mehr zu nutzen ist. Als Lösung bietet es sich an, solche Nachrichten immer in der optimalen Form zu kodieren. Das kann zum Beispiel bedeuten, große binäre Dateien getrennt von der Nachricht zu übertragen. WSIT bietet hierzu eine Lösung, und zwar die Empfehlung, die Optimierung von Nachrichten ab einer Größe von einem KByte zu nutzen.

Reliable Messaging Technology

Verlässliche Dienste (oder genauer gesagt die verlässliche Auslieferung von Nachrichten) sind eine der Grundlagen moderner serviceorientierter Konzepte. Darunter ist der garantierte Transport einer Nachricht von Punkt A zu Punkt B zu verstehen. Die Reliable Messaging Technology sichert zu, dass Nachrichten garantiert nur einmal ausgeliefert werden. Im Weiteren lässt sich die Reihenfolge der Nachrichten in einer Sequenz bestimmen, die es einzuhalten gilt. Sollte wirklich einmal eine Nachricht verloren gehen oder die Reihenfolge beeinträchtigt sein, kann das zugrunde liegende System den Ursprung wieder herstellen.

Ein Hinweis sei jedoch gestattet. Reliable Message Technology bedeutet das Speichern von Nachrichten, bis ein eindeutiges OK vom Empfänger das Eintreffen bestätigt. Der Anwender benötigt also mehr Speicherplatz und unter Umständen mehr Rechenzeit. Dienste, die Reliable Messaging nutzen, können nicht mit Dienstenutzern interagieren, die das Prinzip nicht kennen.

Security Technology

Der Metro-Stack implementiert zusätzlich zur Sicherheit auf der Transportebene (SSL) den WS-Security-Standard. Neben den grundlegenden sicherheitsrelevanten Standards ist die Web Services Security Policy vorhanden und implementiert. Das bedeutet, dass gesicherte Dienste klar ihre Fähigkeiten und Anforderungen in Bezug auf die Sicherheit formulieren und in der WSDL ablegen können. Die Dienste sind somit kompatibel zu anderen Diensten und Dienstenutzern, die die Policies verstehen (Java Metro oder auch .NET).