Als Teil von "Windows DNA 2000" beziehungsweise jetzt der "Windows.Net"-Strategie präsentierte Microsoft Ende letzten Jahres Soap erstmals der Öffentlichkeit. Gemeinsam mit den Firmen Developmentor und Userland hatte der Softwareriese eine Technologie entwickelt, die Remote Procedure Calls (RPCs) mit Hilfe des Hypertext Transfer Protocol (HTTP) oder anderer Protokolle als Transportmedien sowie die Codierung und Bearbeitung von Messages mit Hilfe der Extensible Markup Language (XML) ermöglicht.

Mit Soap ist die Hoffnung verbunden, ein einfaches, plattform- und systemunabhängiges XML-Messaging/RPC-Protokoll für die Kommunikation zwischen Anwendungskomponenten gefunden zu haben. Dies ist insbesondere im Zeitalter des E-Business und der Ausdehnung der Geschäftsprozesse über das Web interessant, da hierbei Transaktionen zwischen unterschiedlichen, vorab nicht bekannten Systemen und Infrastrukturen laufen müssen. Teil der Vision ist aber vor allem der Aufbau neuer vorzugsweise Web-basierter Anwendungslandschaften. So arbeiten besonders Microsoft und IBM derzeit an "Web-Services". Hinter diesem Begriff verbergen sich Programmbausteine in Form von DCOM/COM+-Komponenten beziehungsweise Enterprise Javabeans (EJB), die sich dereinst innerhalb und außerhalb der Unternehmensgrenzen ansprechen lassen, selbständig miteinander kommunizieren und sich so je nach User-Anforderung zur Laufzeit per dynamischem Binding zu neuen, virtuellen Applikationen zusammenfinden sollen.

Analysten rechnen damit, dass Soap heutigen RPCs, wie sie die Objekttechnologien DCOM, Corba oder Java/RMI seit langem verwenden, vor allem im HTTP-basierten Web den Rang ablaufen könnte. Grund hierfür ist, dass jene Protokolle die Messages üblicherweise nicht durch Firewalls transportieren können. Dies ist nur dann möglich, wenn der Anwender den Kunstkniff des "HTTP-Tunneling" benutzt, um über den HTTP-Port 80 das Internet zu erreichen. Zudem fordern die genannten RPCs eine komplexe, stark hersteller- und plattformspezifische Integration. So können etwa DCOM- und Corba-Objekte bisher nur mit Hilfe einer speziellen "Bridge" miteinander kommunizieren. Soap als nicht-binäres Protokoll verspricht hier als kleinster gemeinsamer Nenner einen einfach zu implementierenden, system- und plattformunabhängigen Kommunikationsmechanismus.

Die Geschichte von Soap ist schnell erzählt. Zunächst fanden die Soap-Initiatoren im letzten Jahr mit Version 1.0 wenig Anklang unter Entwicklern und Herstellern.

Grund hierfür waren technische Defizite. So berücksichtigte der Entwurf, der der Internet Engineering Task Force (IETF) vorgelegt wurde, lediglich das hauseigene XML-Vokabular und ließ nur HTTP als Transportprotokoll zu. Erst in diesem Jahr kam es dann zu einem Sinneswandel, der dem Microsoft-Lager die Unterstützung unter anderem von IBM, Lotus und Sun einbrachte. Mit ihnen gemeinsam wurde schon bald darauf Release 1.1 entwickelt, das insbesondere den Einsatz von XML-Schemata ermöglicht sowie nun neben HTTP auch beliebige andere Übertragungprotokolle wie etwa für "MQ Series" oder FTP zulässt.

Seit Juni 2000 liegt Soap nun dem W3C-Konsortium zur Standardisierung vor. Die Spezifikationen umfassen allerdings nur die Kommunikation über HTTP und das HTTP-Extension-Framework (ausführlich unter: www.w3.org/TR/SOAP). Mit einer W3C-Empfehlung ist allerdings erst in einigen Monaten zu rechnen. Kritiker bemängeln zudem, dass die Soap-Spezifikationen sich nicht mit der Steuerung von Transaktionen und der Sicherheitsproblematik beschäftigen sowie keine Empfangsbestätigung nach der Übertragung vorsehen. Eine Evaluierung seitens der "ebXML"-Initiative, an der die Organization for the Advancement of Structured Information Standards (Oasis) und das Handelsgremium der Vereinten Nationen beteiligt sind, fiel denn dieser Tage auch negativ aus. Die Gruppe, in der nach eigenen Angaben über 300 Hersteller und Internet-Service-Provider versammelt sind, um ein XML-Framework für den B-to-B-Handel zu entwickeln, hält Soap momentan noch für unausgereift und nicht für umfangreiches Messaging geeignet.

Abgesehen von diesen grundsätzlichen Schwächen von Soap stehen selbst die Befürworter bei der Implementierung und Erweiterung der bereits veröffentlichten Spezifikationen noch am Anfang. Spezialprodukte wie "Xorba" der Firma Rogue Wave bilden hier die Ausnahme. Dieses ermöglicht, Schnittstellen von C++-basierten Corba-Anwendungen zu wrappen und für die Soap-basierte Kommunikation über HTTP anzupassen. Dadurch lassen sich Corba-Anwendungen über ein Web-Interface aufrufen, ohne dass der Anwender IIOP oder Tunneling verwenden muss.

Zugleich kommt künftig IBM als Gegengewicht zu Microsoft eine besondere Rolle bei der Weiterentwicklung von Soap zu. Dem Unternehmen geht es in erster Linie darum, das Protokoll für den Einsatz mit Java-Technologie beziehungsweise -Komponenten weiterzuentwickeln. Analysten von Gartner stützen diesen Ansatz und erwarten für die Zukunft, dass der XML/HTTP-RPC zur wichtigsten Methode für den Aufruf künftiger EJB-Services avancieren wird. Big Blue hofft dabei auf einen offenen Standard und stellte daher seine Soap-Implementierung für Java-Komponenten "Soap 4J" dem Open-Source-XML-Projekt der Apache-Group (www.xml.apache.org/soap/) zur Verfügung. Sie liegt seit kurzem in einer überarbeiteten Version 2.0 vor.

Zusätzlich hat IBM den Soap-Quellcode veröffentlicht sowie einige Extras vorgestellt, die sich auf der hauseigenen Alphaworks-Entwickler-Site finden. So gibt es Spezifikationen sowohl für die Codierung von Datentypen gemäß Soap 1.1 als auch ein Toolkit für das Extensible Metadata Interchange Format (XMI), mit dem sich Java-Objekte serialisieren lassen. Ferner unterstützt IBM die Mail-Standards SMTP und POP 3, bietet frühe Services-Implementierungen als so genannte Alphabeans sowie erste Werkzeuge. (www.alphaworks.ibm.com/tech/xmitoolkit). Der Support umfasst einen Soap-Generator, einen Serverbasierten Router, mit dem sich laut Hersteller jede Java-Klasse Soap-fähig machen lässt, sowie ein Verwaltungswerkzeug, mit dem neue Services über das Web implementiert werden können.

Trotz dieser ersten IBM-eigenen Spezifikationen befindet sich Soap laut Cristoph Pürckhauer, Solutions Architect bei IBM in Böblingen, noch in einem sehr frühen Stadium. Er ist sich dennoch sicher, dass Soap als zukünftiges Basiskommunikationsmodell geeignet ist. Da Soap jedoch keine Funktionen für Security, Unterstützung für verteilte Transaktionen oder Aktivierung von Objekten bietet, werden auch weiterhin beispielsweise die entsprechenden Corba-Dienste notwendig sein. IBM, so Pürckhauer, entwickle derzeit über Alphaworks und Apache die Basisinfrastruktur weiter und strebe eine nächste Generation der Javabeans an, die Soap generieren und empfangen können.

Weitere Baustellen sind Security-Erweiterungen, mit denen sich Teile der Soap-Message verschlüsseln und Zertifikate verschicken lassen, sowie RPC-Spezifikationen, mit denen sich Schnittstellen vergleichbar der Interface Definition Language (IDL) bei Corba beschreiben und generieren lassen. IBM favorisiert hierbei das hauseigene Nassl-API. "Doch die Spezifikationen sind alle noch im Fluss, und es sind auch noch keine Produkte zu erwarten." Zudem ist auch Big Blue Mitglied der ebXML-Gruppe, die wie erwähnt Soap vorerst auf Eis gelegt hat.

Konkretere Pläne mit Soap hat hingegen Microsoft bekannt gegeben. So wird das Protokoll zum Transportmedium für die Version 2.0 des "Biztalk Server 2000" für Enterprise Application Integration (EAI) werden. Letzterer erweitert Soap-Nachrichten durch Funktionen wie Routing und Quality-of-Service-Header. Er steht zudem in direkter Konkurrenz zum ebXML-Framework, an dem sich Mircosoft nicht beteiligt, und wird voraussichtlich früher als dieses auf den Markt kommen. Marktbeobachter erwarten, dass sich so trotz der Kritik an Soap durch Microsofts Marktgewicht ein De-facto-Standard für B-to-B inklusive Soap anbahnen könnte.

Ferner soll Soap das Bindeglied zwischen den bereits genannten Web-Services sein, die sich laut Hersteller in der Entwicklung befinden. Diese als "Building Blocks" bezeichneten Anwendungskomponenten will Microsoft nach eigenen Angaben künftig hosten und Web-Dienstleistern und Inhalteanbietern zur Verfügung stellen. Der erste, bereits erhältliche Dienst dieser Art ist "Microsoft Passport", der der Authentifizierung von Anwendern dient. Weitere angekündigte Building Blocks sind Arbeitsgruppen-Kalender, Benachrichtigungs-Dienste, ein Software-Upgrade-Dienst und ein Web-Suchdienst auf XML-Basis.

Die Entwicklung von Web-Services wird auch zu den neuen Möglichkeiten in der nächsten Version der Werkzeugsammlung "Visual Studio" zählen. Bereits jetzt ist ein "Soap Toolkit" erhältlich, das zwar ein eigenes Produkt darstellt, zugleich jedoch erste Eindrücke vom kommenden Release von Visual Studio vermittelt (siehe http://msdn.microsoft.com/xml/general/toolkit_intro.asp). Es steht als kostenlose Testversion für Visual Studio 6 im Microsoft Developer Network (MSDN) unter http://msdn.microsoft.com/xml/general/soaptemplate.asp. zum Download bereit. Ziel ist es, Entwicklern eine Infrastruktur zu bieten, mit der sie Web-Services erstellen und verwenden sowie deren Schnittstellen dokumentieren können. Bis auf wenige Ausnahmen basiert das Toolkit laut Hersteller auf den Spezifikationen von Soap 1.1. Es enthält unter anderem die Remote Object Proxy Engine (Rope), mit der sich die grundlegenden Web-Services "Proxy" and "Soappackager" implementieren lassen. Ferner ein Wizard, der eine Reihe von Services beschreiben und generieren hilft, Referenzimplementierungen sowie eine Service Description Language (SDL), die für Soap etwa das Gleiche wie eine Type-Library für COM leistet: identifizieren, was eine Komponente oder Service ist.

Allerdings stecken sowohl Microsofts als auch IBMs Toolkit noch in den Kinderschuhen, wie ein aktueller Vergleich beider Werkzeugsammlungen kürzlich zeigte (siehe http://windows.oreiliy.com/news/soapreview_0600.html). Danach erwies sich IBM-Soap als die derzeit stabilere und leichter zu integrierende Variante.

Was ist SOAP?

Soap definiert weder Anwendungssemantik, noch dient es der Spezifikation einer konkreten Implementierung. Es bietet ein XML-basiertes Message-Format, mit dem sich die Anwendungssemantik von Softwaremodulen beschreiben, verpacken und codieren lässt (siehe Grafik, Seite 16). Es besteht aus drei Teilen: eine Art "Umschlag" definiert ein Framework, das Inhalt und Verarbeitungart einer Nachricht beschreibt. Zweitens ein Satz von Codierungs-Regeln, die Instanzen von anwendungsspezifischen Datentypen ausdrücken, sowie drittens eine Konvention (Soap-RPC), mit der Methodenaufrufe und -rückrufe definiert werden. In einer Soap-Message gibt es Abschnitte, über die die Bindung an HTTP oder andere Protokolle erfolgt, für die Definition des Umschlags-Headers sowie für die Codierung des Payloads (siehe auch http://schemas.xmlsoap/org/soap/envelope und schemas.xmlsoap.org/soap/encoding).

Allgemein gesagt ist Soap:

-Ein einfacher, plattform- und systemunabhängiger RPC, der Messages mit Hilfe von XML codiert und neben HTTP auch zusammen mit anderen Transportprotokollen genutzt werden kann;

-ein künftig vor allem im Web anzutreffendes Protokoll, das dort Methodenaufrufen per IIOP, DCOM und JRMP den Rang ablaufen könnte;

-eine Spezifikation, die dem W3C-Konsortium zur Empfehlung unterbreitet wurde und Teil des Apache-XML-Projekts ist, sowie

-eine Möglichkeit zum Messaging mit Hilfe von HTTP (Port 80) über Firewalls und Router.

Soap ist nicht:

-ein Komponentenmodell und ersetzt daher weder COM/DCOM/COM+ noch Corba, Javabeans oder Enterprise Javabeans;

-eine Programmiersprache, sondern sprachenneutral;

-eine komplette Lösung für die Implementierung von Web-Services. Es fehlen beispielsweise Lookup- oder Codierungs-Mechanismen;

-ein XML-Ersatz für Java, COM etc., könnte aber deren künftiger Transportmechanismus sein;

-eine Antwort auf Sicherheitsprobleme bei der Anwendungskommunikation.

Unterstützer: Activestate Tool Corp., Ariba , Born Information Services, Commerce One, Compaq, Developmentor, Extensibility, Hewlett-Packard, IBM, Iona Technologies, Intel, Lotus Development, Objectspace, Rogue Wave Software, SAP, Scriptics Corp., Secret Labs AB, Sun Microsystems, Userland Software, Zveno Pty. Ltd. und andere.

Informationen- W3C-Spezifikationen: http://www.w3c.org/TR/Soap

Übersichtsartikel zu Soap (Auswahl):

- SOAP-Resource-Center: www.soap-wrc.com

- Einführung: http://msdn.microsoft.com/msdnmag/issues/0300/soap/soap.asp

sowie http://msdn.microsoft.com/workshop/xml/general/SOAP_V09.asp

- Soap for Java: http://www.alphaworks.ibm.com/tech/soap4j,

- Soap Toolkit für Visual Studio 6: http://msdn.microsoft.com/xml/general/toolkit_intro.asp,

- Soap für Python: http://www.pythonware.com/products/soap

- XML-Messaging allgemein: http://www-4.ibm.com/software/developer/library/xml-messaging,

- FAQs: http://www.msdn.microsoft.com/xml/general/soap_faq.asp

Abb: Ablauf eines Soap-Methodenaufrufs: Der Client kontaktiert über ein natives RPC-Protokoll (COM, Corba) einen Client-seitigen Proxy-Layer. Dieser verwendet einen XML-Parser, um den Aufruf in ein Soap-Paket zu übersetzen. Dann erfolgt beispielsweise via HTTP die Übermittlung zur URL eines entfernten Web-Servers. Dieser startet den Soap-Translator, der eine ASP-Seite, eine ISAPI-Erweiterung, ein CGI-Programm etc. sein kann. Mit Hilfe eines lokalen XML-Parser ruft der Translator über einen Object Remote Procedure Call (ORPC) eine lokale Server-Komponente auf und verpackt die Antwort in eine Soap-Message, die vom Client-Proxy wieder ausgepackt wird. Quelle: CW