Mit den momentan verfügbaren Technologien und Standards sind die Einsatzmöglichkeiten von Web Services über die Grenzen eines Unternehmens hinweg stark beschränkt. Konzepte für Sicherheit, Policies und Routing fehlen ebenso wie Mechanismen für zuverlässigen Nachrichtentransfer und Transaktionen. Aus diesem Grund beschränken sich die aktuellen Web-Services-Anwendungen meist auf firmeninterne Point-to-Point-Implementationen. In naher Zukunft dürfte sich das aber ändern. Neue Spezifikationen, die Web Services für zuverlässige und firmenübergreifende Anwendungen salonfähig machen sollen, befinden sich bereits in der Pipeline.
Im April 2001 tagte das W3C über die notwendigen Standards für eine sichere und zuverlässige Web-Services-Architektur. Dieses Meeting sollte sich als richtungsweisend herausstellen, denn bereits ein halbes Jahr später, im Oktober 2001, wurde unter der Bezeichnung Web Services Architecture (WSA) ein Papier präsentiert, in dem die für Business-Web-Services benötigten Spezifikationen aufskizziert wurden. Basierend auf diesem Entwurf haben verschiedene Hersteller damit begonnen, für einzelne Spezifikationen konkrete Vorschläge zu präsentieren. Allen voran IBM und Microsoft, die unter dem Überbegriff Global Web Services Architecture (GXA) die Ausarbeitung von Vorschlägen für das gesamte Spektrum der WSA in Angriff genommen haben.
Es ist eine Novität in der Geschichte der IT-Industrie, dass über geplante Standards weitgehend Einigkeit herrscht. Zwar gab es in den vergangenen Monaten bei einigen Vorschlägen noch Zankereien, die meisten wurden aber mittlerweile beigelegt. Auffällig ist, dass IBM, Microsoft und BEA - die wohl drei wichtigsten Proponenten der Web-Services-Idee - bei fast allen Vorschlägen am selben Strick ziehen. Der Ablauf ist fast immer derselbe: Microsoft und IBM arbeiten jeweils eigene Spezifikationen aus, einigen sich etwas später auf einen gemeinsamen Vorschlag und publizieren diesen gemeinsam mit weiteren gewichtigen Supportern wie BEA, Verisign, SAP oder RSA. Ziel ist es dann, den publizierten Vorschlag nach weiteren öffentlichen Diskussionsrunden an ein Gremium zur Standardisierung zu übergeben. Wie unsere Tabelle auf Seite 46 zeigt, wurden allerdings erst wenige Spezifikationen an ein Komitee weitergereicht. Dieses Bild dürfte sich allerdings in den kommenden Monaten stark ändern.
Trotz der breiten Einigkeit gibt es auf einigen kleinen Schauplätzen noch Auseinandersetzungen. So liegen etwa für die Bereiche Orchestrierung oder Reliable Messaging Alternativvorschläge auf dem Tisch, die von einer Gruppe von Firmen ausgearbeitet wurden, der auch Oracle und Sun angehören. In Branchenkreisen geht man jedoch davon aus, dass auch diese Rangeleien bald beigelegt sein werden.
Eine weitere Entwicklung, die einen breiten Konsens in der Branche verspricht, ist die WS-Interoperability Organization (WS-I), die im Februar 2002 ins Leben gerufen wurde. Das Konsortium soll sicherstellen, dass die Interoperabilität von Web Services zwischen verschiedenen Plattformen, Betriebssystemen und Programmiersprachen in jedem Fall gewährleistet ist. Dies wäre eigentlich bereits das Ziel der Standardisierungskomitees (W3C, OASIS, IETF etc.). Dennoch kommt der WS-I eine bedeutende Rolle zu, denn Standards bieten immer Spielraum für eigene Interpretationen und sind auch nie vor proprietären Erweiterungen sicher (siehe HTML). WS-I ist sozusagen das Anti-Hijacking-Tool, das mit Richtlinien und Testwerkzeugen die konforme Umsetzung von Web-Services-Standards durch die Hersteller sicherstellt.
Erst im August hat die WS-I das Basic Profile 1.0 freigegeben, in dem das Zusammenspiel zwischen den Basistechnologien SOAP, WSDL, UDDI und XML Schema festgelegt wird. Mittlerweile wurde auch eine Arbeitsgruppe für die Profilierung von Security-Spezifikationen gegründet.
Entscheidend für den Erfolg der WS-I dürfte vor allem die Charta sein, in der jedes WS-I-Mitglied beteuert, alle Web-Services-Standards den Profilen entsprechend zu implementieren. Da mittlerweile jedes namhafte Unternehmen der Softwarebranche der WS-Organisation beigetreten ist - darunter auch IBM, Microsoft, Oracle und Sun -, kann man davon ausgehen, dass die Standardisierung vieler wichtiger Web-Services-Technologien ohne grössere Probleme über die Bühne gehen wird.
Einer der wichtigsten Aspekte der vorgelegten Web-Services-Spezifikationen ist, dass sie auf einem modularen Bausteinkonzept beruhen (siehe Diagramm "Die Web-Services Architektur"). Je nach Anforderung einer Anwendung können einzelne Spezifikationen herausgepickt und miteinander kombiniert werden. Basis für diese Flexibilität bildet das Messaging-Protokoll SOAP (Simple Object Access Protocol), in dem das Format der Meldungen festgelegt ist, die zwischen Web Services verschickt werden. SOAP, das unabhängig vom darunter liegenden Transportprotokoll arbeitet (HTTP, TCP/IP, UDP, SMTP etc.), verfügt über eine offene Architektur, die das Anbringen von Zusatzinformationen ermöglicht. So lassen sich beispielsweise im Headerbereich einer SOAP-Meldung Informationen für Routing oder Security anbringen.
SOAP liegt wie die beiden anderen wichtigen Basisstandards WSDL 1.1 (Beschreibung von Web Services) und UDDI 2.0 (Web-Services-Verzeichnisse) als verabschiedeter Standard vor. Allen geplanten Spezifikationen gemein ist, dass sie vollständig auf XML 1.0 und XML Schema beruhen.
Für kommerzielle und firmenübergreifende Web-Services-Anwendungen sind griffige Sicherheitsmechanismen von essentieller Bedeutung. Nicht selten wird heute bei Web Services auf die Secure Sockets Layer (SSL) für die verschlüsselte Kommunikation zwischen zwei Web-Services-Endpunkten zurückgegriffen. Diese Technik kann allerdings lediglich für Point-to-Point-Verbindungen eingesetzt werden und arbeitet nur auf Transportstufe. Sobald mehrere Web-Services-Endpunkte in einen gemeinsamen Sicherheitskontext mit gegenseitigen Vertrauensbeziehungen eingebunden werden sollen, wird echte End-to-End-Security auf Message-Ebene benötigt.
Grundlage für alle Sicherheitsmechanismen der Web-Services-Architektur bildet WS-Security. Diese Spezifikation gibt vor, wie Sicherheitsinformationen in SOAP-Messages eingebettet werden müssen. Zu diesen Informationen zählen insbesondere die sogenannten Security Tokens, mit deren Hilfe sich eine SOAP-Message bei allen angepeilten Web Services authentifizieren kann. Bei einem Token kann es sich etwa um eine Benutzername/Passwort-Kombination, ein X.509-Zertifikat, ein Kerberos-Ticket oder eine SAML-Deklaration (Security Assertion Markup Language) handeln. Dabei kann eine SOAP-Nachricht gleichzeitig mit mehreren Tokens ausgestattet werden.
WS-Security beruht auf einer offenen Architektur und kann dadurch auch mit Security-Modellen verwendet werden, die erst in Zukunft auf den Markt kommen werden. Neben dem Übermitteln von Informationen zur Authentifizierung zeichnet WS-Security auch für die Verschlüsselung und Signierung von SOAP-Messages verantwortlich. Dazu werden auf die zwei ratifizierten Standards XML-Encryption und XML-Signature des W3C zurückgegriffen. Zudem können SOAP-Messages per WS-Security mit einem Zeitstempel versehen werden, um die Gültigkeitsdauer einer Meldung festzulegen.
WS-Policy definiert ein erweiterbares Framework, mit dem Web Services mit Vorgaben, sogenannten Policy Assertions, ausgestattet werden können. Dabei lassen sich Assertions für allgemeine Präferenzen, zwingende Voraussetzungen oder generelle Fähigkeiten formulieren. Für die Definition von Assertions stehen zwei Sub-Spezifikationen bereit:
• WS-PolicyAssertions sind für generelle Angaben wie Encoding-Format, unterstützte Sprache oder verwendete Spezifikationen gedacht.
• WS-SecurityPolicies dienen zum Formulieren von sicherheitsrelevanten Assertions wie Security Tokens, Signaturen, Verschlüsselungen oder Gültigkeitsdauer von Nachrichten.
Assertions lassen sich nicht direkt einem Web Service zuordnen, sondern müssen via WS-Policy zu einer als Policy Statements bezeichneten Einheit zusammengefasst werden. So lassen sich mit einer Kombination von Assertions auch komplexere Richtlinien definieren. Beispielsweise könnte in einem solchen Statement formuliert werden, dass für die Authentifikation ein X.509-Zertifikat bevorzugt, als Alternative aber auch ein Kerberos-Ticket akzeptiert wird.
WS-Policy definiert nur, wie solche Vorgaben formuliert werden müssen, nicht aber, wie diese mit einem Web Service verlinkt oder von einem Client abgefragt werden können. Für diese Aufgabe ist die Spezifikation WS-PolicyAttachment zuständig, die es erlaubt, erstellte Policies mit XML-Elementen, WSDL-Definitionen und UDDI-Einträgen zu verknüpfen.
Die beiden Sicherheitskonzepte WS-Security und WS-Policy lassen sich erst dann nutzen, wenn es einen Mechanismus gibt, mit dem Vertrauensbeziehungen zwischen zwei oder mehreren Parteien aufgebaut werden können. WS-Trust erweitert das Web-Service-Security-Modell um eine Trust Engine, mit der die übermittelten Tokens des Senders mit den Policies des Empfängers verglichen werden. Dabei stellt die Trust Engine sicher, dass die Policies des angepeilten Web Service durchgesetzt werden.
Zudem wird mit WS-Trust auch das Konzept der Security Token Services (STS) eingeführt. Diese agieren ähnlich wie eine Certificate Authority (CA) und können Security Tokens ausstellen. Das ist etwa dann sinnvoll, wenn auf Sender- und Empfängerseite unterschiedliche Tokens unterstützt werden. Ein Security Token Service agiert dann zwischen den beiden Services als Vermittler. Ergänzt wird WS-Trust durch WS-SecureConversation. In diesem Vorschlag wird definiert, wie Services während der Dauer einer Session Daten sicher untereinander austauschen können.
Mit WS-Federation, die erst im Juli dieses Jahres publiziert wurde, wird das Konzept von WS-Trust noch einen Schritt weitergeführt. Diese Spezifikation beschreibt, wie Authentifizierungs-Daten zwischen Web Services mit Vertrauensbeziehungen ausgetauscht werden können. WS-Federation ist vor allem dann von Bedeutung, wenn es um die Realisierung von Single-Sign-on-Systemen geht.
Von den vorgeschlagenen Security-Standards wurde erst WS-Security zur Ratifizierung an ein Gremium (OASIS) übergeben. Alle anderen liegen erst als Entwurf vor oder wurden, wie im Fall von WS-Privacy und WS-Authorization, noch gar nicht publiziert. Die beiden ausstehenden Papiere sollen Anfang 2004 veröffentlicht werden.
Neben Sicherheit ist die zuverlässige Abwicklung von Transaktionen ein weiteres Schlüsselkriterium von vielen kommerziellen Anwendungen. So muss beispielsweise bei einer Auftragsabwicklung, bei der mehrere verteilte Systeme wie die Lagerbewirtschaftung, das Rechnungswesen und ein Kreditkarten-Clearing-Service involviert sind, sichergestellt werden können, dass entweder alle für den Gesamtprozess notwendigen Operationen (Abbuchung im Lagerbestand, Belastung der Kreditkarte etc.) oder im Fehlerfall gar keine durchgeführt werden.
Die Spezifikationen WS-Coordination und WS-Transaction regeln, wie solche sichere Transaktionen abgehandelt werden müssen. Dabei sehen die beiden Vorschläge zwei verschiedene Verfahren vor: Zum einen gibt es ein feinkörniges Two-Phase-Commit-Verfahren (Atomic) nach dem Vorbild von COM+ und IBM CICS, bei dem in einem ersten Schritt alle beteiligten Systeme gesperrt und die Transaktion anschliessend in einem zweiten Schritt vorgenommen wird. Allerdings kann das Two-Phase-Locking schnell einmal problematisch werden, weil Prozesse bei Web-Services-Lösungen schnell einmal mehrere Stunden in Anspruch nehmen können. Das Sperren einer Ressource über einen derart langen Zeitraum ist aber für die meisten Lösungen untauglich.
Darum gibt es als Alternative das besser auf die Web-Services-Welt abgestimmte Business-Activity-Verfahren. Hier werden alle Änderungen immer sofort vorgenommen und können im Fehlerfall sogleich wieder rückgängig gemacht werden.
Von Business-Anwendungen wird verlangt, dass Nachrichten auch dann an ihren Endpunkten ankommen, wenn der angepeilte Service temporär nicht verfügbar ist. Eine E-Shop-Lösung muss zum Beispiel in der Lage sein, eine Bestellung zuverlässig an die Lagerbewirtschaftung des Fulfillment-Partners weiterzureichen, auch wenn diese zum Zeitpunkt des Bestelleingangs nicht erreicht werden kann. Zu diesem Zweck wird heute in IT-Anwendungen auf sogenannte Queuing-Systeme wie etwa IBMs MQ Series, Microsofts Message Queuing (MSMQ) oder die Java Messaging Services (JMS) gesetzt. Allerdings beruhen diese Lösungen auf keinem gemeinsamen Standard. Sollen zwei verschiedene Queuing-Technologien plattformübergreifend zusammengeschaltet werden, muss auf spezielle Adapter oder Gateways zurückgegriffen werden. Web Services unterliegen diesen Einschränkungen zwar nicht, doch fehlt noch ein Mechanismus, mit dem die Nachrichtenübermittlung zuverlässig bewerkstelligt werden kann.
Wie eingangs erwähnt, ist die Softwaregemeinde bei dieser Disziplin noch in zwei Lager gespalten. Während auf der einen Seite der Vorschlag WS-Reliablity von Oracle, Sun, NEC und SAP bereits der OASIS übergeben wurde, versuchen BEA, IBM, Microsoft und Tibco mit WS-ReliableMessaging ihre eigene Spezifikation durchzuboxen. Wer hier das Rennen machen wird, ist noch offen. Zumindest vom technischen Standpunkt aus betrachtet, scheint Experten zufolge WS-ReliableMessaging die Nase vorn zu haben. So ist dieses Protokoll erweiterbar, bezieht WS-Security und WS-Policy ein und kann besser geroutet werden.
Sobald mehrere Web Services in einer bestimmten Reihenfolge in einen Business-Prozess eingebunden werden sollen, wird ein Verfahren benötigt, mit dem sich SOAP-Messages zu verschiedenen Endpunkten leiten lassen. Dies soll sich dereinst mit WS-Addressing (Nachfolger von WS-Routing) bewerkstelligen lassen. Eine SOAP-Nachricht kann damit beispielsweise vom Startpunkt A über die Knoten B und C zum Endpunkt D versandt werden. Dabei wird mit WS-Addressing nicht nur die Route beschrieben, sondern auch spezifiziert, welche Bereiche einer SOAP-Nachricht für welche Knoten bestimmt sind. Mit WS-Addressing können angelaufene Knoten auch Adressänderungen in einer SOAP-Message anbringen, um im Fehlerfall die Meldung an den Absender zurückschicken oder bei Eintritt einer bestimmten Bedingung an einen anderen Web Service umleiten zu können.
Mit WS-Referral wird das Routing-Konzept um eine dynamische Wegfindung erweitert. Damit können einzelne Knoten ermitteln, welche Web Services verfügbar sind, und dementsprechend die Route der Nachricht optimieren. WS-Referral kann auch für das Load-Balancing zwischen mehreren Web-Service-Hosts genutzt werden.
Während sich WS-Addressing nur auf Transport- und Message-Ebene um die Integration von verschiedenen Web Services kümmert, geht es bei der sogenannten Orchestrierung um das Beschreiben und Definieren solcher Abläufe auf Applikationsstufe. Werden mehrere Web Services zu gemeinsamen Business-Prozessen integriert, entstehen sehr schnell aufwendige Workflows mit Bedingungen, parallelen und verschachtelten Abläufen sowie potentiellen Fehlerfällen, die behandelt werden wollen.
Zum Beschreiben solcher komplexen Abfolgen liegen derzeit die beiden Vorschläge BPEL (Business Process Execution Language, auch BPEL4WS genannt) und WS-Choreography auf dem Tisch. Bei BPEL handelt es sich um eine Verschmelzung von IBMs Web Services Flow Language (WSFL) und Microsofts XLANG. Im April wurde dieser Vorschlag an OASIS übergeben. WS-Choreography, das ursprünglich von HP, Sun, Oracle und Tibco initiiert wurde, räumen Experten immer weniger Chancen ein. Denn mittlerweile haben sich nach dem Zugang von gewichtigen Supportern wie SAP und Siebel auch Sun und Oracle dazu entschlossen, dem BPEL-Komitee von OASIS beizutreten.
Da Web Services mit XML und SOAP auf rein textbasierten Technologien beruhen, sind sie von Natur aus nur für den Transport von Textinformationen geeignet. Das mag zwar für viele Anwendungen genügen, doch gibt es hin und wieder auch den Bedarf, im Binärformat vorliegende Daten wie Bilder oder Audio zwischen Web Services zu transportieren. Da die Umwandlung der Binärdateien in ein Textformat via Base64-Encoding zusätzliche Rechenzeit an beiden Endpunkten in Anspruch nimmt und SOAP-Messages unnötig aufbläht, werden Verfahren benötigt, mit der Binärdateien ganz einfach als Attachment mit einer SOAP-Nachricht verschickt werden können. Genau dies wird von den beiden Spezifikationen DIME (Direct Internet Message Encapsulation) und WS-Attachment adressiert. DIME legt fest, wie binäre Daten in SOAP-konforme Pakete umgewandelt werden müssen. WS-Attachments definiert, wie sich DIME-Packages an SOAP-Messages anheften lassen. Alternativ können Daten mit DIME auch als Stream zwischen zwei Web-Services-Endpunkten übertragen werden.
Damit sich Web-Services-Standards und -Spezifikationen in den eigenen Applikationen implementieren lassen, sind Entwickler auf entsprechende Tools angewiesen. Um ihre Produktzyklen überbrücken zu können, warten Plattformhersteller immer wieder mit neuen Versionen kostenloser Toolkits auf, welche die Umsetzung der neuesten Web-Services-Technologien ermöglichen.
So gibt es etwa von IBM das Emerging Technologies Toolkit (IEET), von Sun das Java Web Services Developer Pack (Java WSDP 1.2) oder von Microsoft die Web Service Enhancements (WSE 2.0 Tech Preview), mit deren Hilfe einige der vorliegenden Spezifikationen bereits implementiert werden können. Bei WSE 2.0 erhält man beispielsweise bereits Support für WS-Security, WS-Addressing oder WS-Trust.
Beim Einsatz dieser Werkzeuge ist jedoch Vorsicht geboten: Spezifikationen, die noch nicht ratifiziert sind, werden im Laufe des Standardisierungsprozesses mit Sicherheit noch verändert. Microsoft gibt denn auch zu, dass die meisten WSE-2.0-Features derzeit nur zum Experimentieren geeignet sind.
In unserer Übersichtstabelle auf Seite 46 finden Sie den geschätzten Termin, auf den wir die Ratifizierung der entsprechenden Spezifikationen erwarten. Vorderhand ist auf jeden Fall noch Zurückhaltung angesagt, wenn es um die Adaption der neuen Web-Services-Spezifikationen in Business-Anwendungen geht.
Web-Services-Spezifikationen im Überblick
