Webservices-Interoperabilität - WS-Policies in der Praxis

Know-how  –  Kommentare

Die Interoperabilität zwischen Webservices auf unterschiedlichen Plattformen und Systemen ist wichtiger Bestandteil jeder strategischen Projektentwicklung im Umfeld einer serviceorientierten Architektur. Der reibungslose Austausch von Transaktions-, sicherheitsrelevanten und Verfügbarkeitsinformationen ist zu gewährleisten. Mit Web Service Policies gibt es einen wichtigen Standard, nach dem ein Webservice solche Metainformationen erhalten kann.

Dienste werden im Allgemeinen durch die Web Service Description Language (WSDL) definiert. Sie beschreibt einen Dienst unabhängig von seiner konkreten Implementierung – sei es nun Java, PHP oder C#. WSDL ist ein XML-Format, das als Elemente die Beschreibung des Aufbaus (Name, Struktur und Operationen) und die Nachrichten verwendet, die die Kommunikation benötigt. Die Beschreibungssprache ist neben der abstrakten Definition eines Dienstes leicht erweiterbar, sodass sie nahezu jedes Nachrichtenformat und Netzprotokoll unterstützt. Das einzige im Standard definierte Protokoll ist jedoch SOAP über HTTP.

Betrachtet man die ursprüngliche Version eines WSDL-Dienstes genauer, lassen sich die folgenden Punkte festhalten:

  • Die Schnittstelle des Dienstes ist definiert.
  • Die Nachricht und ihr Format sind beschrieben.
  • Die Adresse des Dienstes ist definiert.
  • Das Transportprotokoll ist festgelegt.
Mögliche Eigenschaften eines Diensts (Abb. 1)

Was in der Aufzählung jedoch fehlt, ist die modulare Beschreibung von Richtlinien. Möchte man einen Dienstenutzer für einen beliebigen Service entwickeln, musste dazu in der Vergangenheit nicht nur die Beschreibung (WSDL) bekannt sein. Man musste auch die technischen Eigenschaften des Systems kennen, das den Dienst bereitstellt. Hinsichtlich der Sicherheit hatte der Entwickler zu wissen, wie die Nachricht verschlüsselt wird, welchen Algorithmus das System verwendet, wie der Aufbau der Nachricht nach der Verschlüsselung aussieht und wie im speziellen Fall die Eigenschaften der Sicherheitsbeschreibung aussehen. Das Ganze gipfelte darin, dass der Entwickler seinen lokalen Code dem gegenüberliegenden System angepasst hat, in der Hoffnung, dass die Eigenschaften überhaupt umsetzbar waren (siehe Abb. 1). Wenn jetzt der Anbieter des Dienstes etwas änderte, ging das Spiel wieder von vorn los.

Richtlinien an Dienste formulieren

Zusammengefasst ermöglicht die WS-Policy-Spezifikation das Beschreiben und Auswerten einfacher und komplexer Richtlinien für einen Dienst. Das senkt die Abhängigkeit von Anbietern und erhöht die Austauschbarkeit. Nicht zuletzt schont es Nerven und den Geldbeutel – werden doch nicht für jeden Dienst inkompatible Anpassungen notwendig.

  • WS-Policy setzt sich mit den folgenden Fragen und Aufgaben auseinander:
  • Beschreibung optionaler oder benötigter Richtlinien an Dienst und Dienstenutzer
  • Richtlinien dynamisch aktivieren oder deaktivieren, ohne die Implementierung des Dienstes zu verändern
  • Richtlinien dynamisch aktivieren oder deaktivieren, ohne den Dienst zu beenden oder neu starten zu müssen
  • grundlegende Spezifikationen (WS-Policy und Policy Assertion) für ein Rahmenwerk
  • spezielle Spezifikationen für Sicherheit, Transaktionen (WS-SecurePolicy etc.)
  • Richtlinien lassen sich sowohl von Entwicklungswerkzeugen als auch von den Service-Bus-Implementierungen auswerten