SOAP hat das Zeug, vom Enduser unbemerkt zum De-facto-Standard für den Remote-Zugriff auf Objekte zu werden. Für Entwickler top, ein Ärgernis allerdings für Systemadministratoren. Das Simple Object Access Protocol (SOAP) vereinfacht den Remote-Zugriff über das Internet. Bei seiner Verwendung braucht beim Online-Aufruf einer Methode eines Applikationsobjekts nur der Methodenname und die Parameter in ein XML verpackt und über HTTP zu einem Zielrechner geschickt zu werden. Dieser entpackt das XML, ruft die gewünschte Methode auf und gibt das Resultat zurück. So lassen sich neue Arten von Internetapplikationen entwickeln, welche unabhängig von Plattformen, Programmiersprachen und verwendeten Werkzeugen laufen.
SOAP wurde zunächst von den Firmen Microsoft, User-Land Software und DevelopMentor aus der Taufe gehoben, dann unter der Mithilfe von IBM, HP, Ariba, CommerceOne, SAP und Iona weiterentwickelt. Inzwischen hat auch Sun die Unterstützung für diesen Kommunikationsstandard angekündigt. Mit gutem Grund: SOAP bietet viele Vorteile. Das schlagkräftigste Argument: Dieses Protokoll wird bereits von vielen Entwicklungsfirmen verwendet, z.B. für Web Services und im B2B-Umfeld.
Vorgängige Versuche, einen weitverbreiteten Standard zu etablieren, waren bisher wenig erfolgreich: RPC (Remote Procedure Call), RMI (Remote Method Invocation), DCOM (Distributed Component Object Model) oder CORBA (Common Object Request Broker Architecture) werden zwar in der Praxis eingesetzt. Aus verschiedensten Gründen konnte sich keiner durchsetzen.
SOAP gehört zu einer interessanten Art neuer Standards, von denen zu hoffen ist, dass sie vermehrt in Mode kommen werden: Sie bauen auf bewährten Standards wie XML, HTTP und optional SSL auf und kombinieren diese miteinander. Simpel, aber langsam: Das Ver- und Entpacken von XML und HTTP ist aufwendig.
Doch braucht es überhaupt einen neuen Standard, damit beispielsweise eine Applikation über das Internet bei einem fremden Server nach dem aktuellen Wechselkurs zwischen US-Dollar und Euro fragen kann? Für solche Mini-Anwendungen allein wäre das kaum sinnvoll. Mit SOAP lassen sich auch ganze APIs mit einem einzigen Mausklick "einseifen". So können auf einfachste Weise unzählige Objekt-Methoden zum Aufruf via Internet bereitgestellt werden. Das kann durchaus sehr vorteilhaft sein, wenn es die Aufgabe ist, eine vorhandene Applikation Internet-fähig zu machen. Die Ausführung eines Programms wird an einer möglichst sinnvollen Stelle zwischen Client und Server aufgeteilt. Und was auch nicht zu unterschätzen ist: Falls Programmaufrufe geschützt werden sollen, können diverse Sicherheitsmechanismen etwa in Form von SSL mit Client-Zertifikaten recht einfach eingesetzt werden - allerdings nochmals auf Kosten der Performance.
Doch was sollte dies alles einen Systemadministrator kümmern? Ziemlich viel. Denn SOAP verwendet Default-mässig die TCP-Ports 80 für HTTP und 443 für HTTPS. Der Grund? SOAP sollte auch durch Firewalls und via Proxy-Server einfach einsetzbar sein. Die meisten Firewalls können aber nicht zwischen "normalem" HTTP und SOAP unterscheiden. Und in Zukunft werden dazu auch nur Firewalls der oberen Preiskategorie in der Lage sein. Wer eine Firewall einsetzt, will etwas ganz sicher nicht: nämlich dass Funktionen einer internen Applikation ungeschützt, unautorisiert und unkontrolliert aufgerufen werden können.
Wenn SOAP, dann doch bitte über einen eigenen Port. Dieser kann separat überwacht und autorisiert werden. Es steht jedem frei, einen anderen Port als den 80er oder 443er zu verwenden - und hoffentlich wird das auch gemacht. Allerdings werden aber viele Server im Einsatz stehen, bei denen eben "niemand" wusste, dass eine SOAP-fähige Applikation installiert wurde. Solche Sicherheitslöcher sind nie geplant, sie tauchen einfach auf. Dabei spielen Default-Einstellungen immer eine sehr grosse Rolle, was die Entscheidung des Standardisierungsgremiums zur Wahl dieser Ports wirklich fragwürdig macht. Doch solche Probleme werden dem Siegeszug von SOAP wenig anhaben können: Langsam, aber sicher ist die Zeit für das programmierbare Web reif und somit auch für SOAP.
