Bild: Photo Alto
Über die Ursprünge von Web-Services kursieren unterschiedliche Anekdoten. Don Box, einer der Miterfinder von Soap und heute Mitarbeiter von Microsoft, erklärt ihre Entstehung damit, dass er und einige andere Fachbuchautoren herausfinden wollten, wer von ihnen den höchsten Rang in der Verkaufsliste von Amazon einnimmt. Zu diesem Zweck wollten sie aber nicht ständig die Web-Site des Online-Händlers besuchen, sondern die betreffenden Informationen maschinell auslesen. Allerdings bot Amazon seine Kataloge damals nur als HTML-Seiten an, so dass derartige Scripts die gewünschten Informationen aus Bergen von Layout-Angaben extrahieren mussten. Deshalb entstand der Wunsch, Inhalte in Form strukturierter Daten gezielt aus dem Web abrufen zu können.
In allgemeiner Form erfüllen Web-Services nach wie vor derartige Bedürfnisse: Sie erlauben die Kommunikation zwischen Anwendungen auf Basis von Web-Standards wie HTTP, Uniform Resource Identifiers (URIs) und XML. Letzterer definiert dabei die Syntax zur Beschreibung der übertragenen Daten. Die ursprünglich starke Ausrichtung auf dokumentorientierte Anwendungen bleibt weiterhin ein Merkmal von Web-Services, auch wenn der umfangreiche "offizielle" Technologiestapel immer mehr für die Transaktionsverarbeitung ausgebaut wird.
Web-Services werden komplizierter
Um das Ziel einer umfassenden Web-Service-Infrastruktur zu erreichen, über die Geschäfte verlässlich und sicher abgewickelt werden können, ergänzen diverse Gremien und Herstellerkonsortien die Kernstandards Soap, Web-Service Description Language (WSDL) und die Universal Description, Discovery and Integration (UDDI) um weitere Technologien. Dazu zählt etwa ein ganzes Paket an XML-bezogenen Sicherheitsstandards, die sich unter dem Begriff WS-Security versammeln. Darüber hinaus soll für derartige Anwendungen gewährleistet werden, dass Soap-Nachrichten den Empfänger garantiert erreichen. Dieses Anliegen verfolgt ein eigenes Komitee für Reliable Messaging unter dem Dach des Konsortiums Oasis.
Zusätzliche Erweiterungen des Technologiestapels für Web-Services betreffen Verfahren für das Weiterleiten von Nachrichten über mehrere Stationen sowie die Orchestrierung von Geschäftsprozessen. Für Ersteres unterbreitete Microsoft bereits vor zwei Jahren den Vorschlag für ein Soap Routing Protocol, für die Definition von Geschäftsprozessen im Rahmen von Web-Services hob die Gates-Company zusammen mit IBM die Business Process Execution Language (BPEL) aus der Taufe. Auch hierfür wurde zur weiteren Ausarbeitung eine Arbeitsgruppe bei Oasis eingerichtet.
Das REST-Prinzip
Zu den wichtigsten Forderungen von REST zählt, dass jede Ressource, die durch Datenoperationen manipuliert werden kann, eine URI erhalten soll. Die für das Lesen und Schreiben von Daten notwendigen Anweisungen werden bei REST aber nicht in die Nutzlast eines XML-Protokolls verpackt. Da dieser Ansatz die Web-Standards HTTP, URI und XML in den Vordergrund stellt, greift er auf die Basisoperatoren von HTTP zurück. Dieses verfügt mit GET, PUT, POST und DELETE über die nötigen Befehle zum Abfragen, Einfügen, Update sowie Löschen von Daten und damit über Äquivalente zu SELECT, INSERT, UPDATE und DELETE in SQL. Die Verfechter von REST bemängeln an Soap, dass es nur POST nutze, um seine Informationen über HTTP zu tunneln. Die eigentliche Adresse der angesprochenen Ressource sowie die vorgesehenen Datenoperationen sind dabei nur der Soap-Nutzlast zu entnehmen. Aus der Sicht von REST sind Programmierschnittstellen HTTP-Manipulationen von XML-Dokumenten, die
über URIs erreicht werden können - und keine Methodenaufrufe mit Parametern.
Beim Ausbau der Infrastruktur für Web-Services sind besonders die großen Hersteller bestrebt, alle wesentlichen Funktionen der Komponentenmodelle Corba beziehungsweise COM nachzubauen. So übernimmt etwa schon der Kernstandard WSDL die Aufgabe einer Interface Definition Language (IDL), UDDI lässt sich etwa mit dem Corba Trader Service vergleichen. Die Mächtigkeit dieser Technologien geht zwangsläufig mit einer erheblichen Komplexität einher.
Diese entsteht im Fall der Web-Services freilich nicht nur durch die zahlreichen neu hinzukommenden Co-Standards, sondern auch durch den Ausbau der Kerntechnologien. So basiert etwa das kürzlich vom W3C verabschiedete Soap 1.2 auf XML Schema und erbt davon etwa die umfangreiche Definition von Datentypen. Dennoch können Web-Services ihr Versprechen nicht vollständig einlösen, Anwendungen über Plattformgrenzen hinweg zu verbinden - gerade der Austausch komplexer Datenstrukturen bereitet Probleme. Das vor kurzem publizierte "Basic Profile" der Web Services Interoperability Organization ist nur ein erster Schritt in diese Richtung.
Wenn Anwendungen nicht die Funktionsfülle des ganzen Web-Service-Stapels benötigen, dann steht Entwicklern natürlich die Möglichkeit offen, nur Soap alleine zu verwenden. Für derartige Anforderungen bietet sich als Alternative aber auch XML-RPC an. Der Name der Technologie verweist darauf, dass sie wie Soap für den Aufruf entfernter Methoden (Remote Procedure Call) gedacht ist. Diese Übereinstimmung ist kein Zufall, weil beide auf den gleichen Ursprung zurückgehen. Der zweite Initiator von Soap neben Don Box, Dave Winer von der Firma Userland, wollte nicht warten, bis die Technologie durch die Mühlen der großen Hersteller und von Gremien gedreht wird. Er spezifizierte auf Basis der ersten Soap-Konzepte ein eigenes leichtgewichtiges XML-Protokoll.
XML-RPC ist nicht überholt
Nur weil sich XML-RPC eng an die anfänglichen Soap-Entwürfe anlehnt und relativ einfach geblieben ist, gilt es noch lange nicht als überholt. Dutzende vorwiegend freie Implementierungen zeigen, dass die Technologie noch viel Rückhalt in der Entwicklergemeinde genießt. Sie ist mittlerweile für praktisch jede Scriptsprache und jede Plattform verfügbar. Zu den bekanntesten Vertretern zählen die Java-Version von Apache sowie die entsprechenden Toolkits für Perl und Python. Eine Ausführung für .NET existiert ebenfalls, so dass Anwendungen auch mit ihren Gegenspielern auf der Microsoft-Plattform kommunizieren können.
Aufgrund seiner Entstehung repräsentiert XML-RPC erwartungsgemäß keinen offiziellen Standard, die Spezifikation ist aber frei zugänglich und kann ohne Einschränkungen umgesetzt oder weiterentwickelt werden. Die vielen quelloffenen Implementierungen garantieren weitgehend, dass kein einzelner Anbieter die Technologie nach Gutdünken proprietär verbiegen kann. Aufgrund eines einfachen und plattformübergreifenden Modells für Datentypen ermöglicht XML-RPC derzeit sogar eine bessere Interoperabilität zwischen heterogenen Systemen als Soap.
Die Akzeptanz von XML-RPC besonders bei Open-Source-Projekten belegen einige prominente Beispiele. Dazu zählen das Content-Management-System "Zope (www.zope.org)", der Linux-Desktop "KDE (www.kde.org)" und die meisten Weblog-Systeme, darunter Blogger.com oder Movable Type. Letztere implementieren das ebenfalls von Dave Winer stammende Blogger-API.
Wie schon sein Name verrät, repräsentiert der XML-RPC genauso wie Soap einen Mechanismus für den entfernten Funktionsaufruf über das Web. Verfechter des Representational State Transfer (REST) reklamieren für ihren Ansatz, dass er nicht Techniken aus der Transaktionsverarbeitung auf das Web aufpfropfe, sondern dessen Architektur besser angepasst sei. Auch wenn der Terminus REST nur geringe Bekanntheit erlangt hat (er wurde von Roy Fielding, dem Architekten von HTTP 1.1 und Mitbegründer des Apache-Projekts in seiner Doktorarbeit geprägt), so beschreibt er dennoch ein Verfahren, das längst weite Verbreitung gefunden hat. Es handelt sich dabei um keine Spezifikation und kein Toolkit, sondern um eine Sammlung von Design-Prinzipien.
REST: einfach und flexibel
Die in diversen Mailing-Listen und Foren emotional geführte Debatte ist akademisch geprägt und versucht eine ohnehin gängige Praxis mit einer Systematik zu versehen. Letztlich läuft REST darauf hinaus, XML-Daten ohne den zusätzlichen Protokollüberbau von Soap oder XML-RPC direkt über HTTP zu versenden. So lassen sich etwa über eine URL von Typ xml.amazon.com/onca/xml3?....&mode=books&KeywordSearch=XML in den Katalogen von Amazon alle Bücher finden, in denen es um XML geht. Das Ergebnis wird nicht als HTML-Seite, sondern als XML-Dokument an den Client gesandt. Diese strukturierten Informationen können vom aufrufenden Programm sehr einfach ausgelesen, transformiert, gefiltert oder an eine andere Web-Ressource weitergeleitet werden. REST-Anhänger sehen darin eine Parallele zum Unix-Konzept, Programme über Pipelines miteinander zu verknüpfen: Die Ausgabe eines Befehls wird zum Input für den nächsten.
Verlinkung wird damit für die Maschinen-zu-Maschinen-Kommunikation genauso wichtig wie für das von Menschen genutzte Web.
Weiterführende Links
Amazon nutzt REST
Die enge Anlehnung an Basisstandards des Web macht REST einige dort verfügbare Dienste leicht zugänglich. So lässt sich der Transport über das Internet per SSL absichern, der Zugriff auf Ressourcen erfordert die allseits praktizierte Authentifizierung am Web-Server, und Proxy-Server können die per URI identifizierbaren Daten im Cache zwischenspeichern. Als Schwächen von REST gelten aber, dass Design-Prinzipien - etwa bei Namenskonventionen von URIs - nicht von allen Entwicklern eingehalten werden. Darüber hinaus lassen sich auftretende Fehler (Faults) nur schwer behandeln.
Ironischerweise zeigt das Beispiel Amazon, dass REST dem Maschinen-Web, das den Soap-Erfindern seinerzeit vorschwebte, näher ist als die Web-Services la Microsoft und IBM. Der E-Commerce-Riese bietet Geschäftspartnern seit einigen Monaten sowohl über REST-APIs als auch über Soap Zugang zu zahlreichen Funktionen seines Online-Shops. Mehrere tausend Websites nutzen Amazon bereits als Plattform für die Anwendungsentwicklung. Colin Bryar, bei Amazon verantwortlich für das Web-Service-Programm, gab im Gespräch mit der COMPUTERWOCHE an, dass mehr als zwei Drittel davon statt Soap die REST-Schnittstellen einsetzen.
Die Flexibilität von REST zeigt sich, wenn Clients mit verschiedenen Datenformaten bedient werden sollen. So definiert Rich Site Summary (RSS), der neue Star unter den Web-Services, im Gegensatz zu den anderen Ansätzen keine Protokolle oder Design-Prinzipien, sondern ein Dokumentenformat für eine Zusammenfassung von Inhalten einer Website. Es ist dem ursprünglichen Zweck, Schlagzeilen für News-Dienste darzustellen längst entwachsen, und wird zunehmend als Medium zur Aggregierung von Daten aus verschiedenen Quellen. Als XML-Format kommt es ebenfalls dem Bedürfnis nach einem maschinenlesbaren Web entgegen. Amazon betätigt sich auch hier als Vorreiter und bietet etwa für Bestsellerlisten so genannte RSS-Feeds. Technisch gesehen wird dabei bloß die URI der entsprechenden REST-Schnittstelle um einen Parameter zu XSLT-Transformation ergänzt.