In einer globalen, Web-basierenden Wirtschaft, in der Fusionen und Übernahmen an der Tagesordnung sind und Geschäftsbeziehungen zunehmend dynamisch und flexibel sein müssen, ist es erforderlich, dass bisher proprietäre, komponentenbasierende Anwendungslandschaften einen besseren Weg finden, miteinander zu kommunizieren. Doch traditionelle RPCs sind nicht nur inkompatibel, sondern auch nur sehr bedingt für das Internet geeignet, da sie bisher das komplizierte "Tunneling" des HTTP-Protokolls verwenden. Die Lösung dieses Problems war ursprünglich einer der Beweggründe für Microsoft, gemeinsam mit User-Land Software und DevelopMentor, Soap (Simple Object Access Protocol) zu entwickeln.

Soap bietet einen allgemeinen RPC-Mechanismus, der den Internet-Standard HTTP als Transportprotokoll nutzt und dadurch über den Port 80 ungehindert die Firewall überwinden kann. Zur Beschreibung des Protokolls wurde die insbesondere im Web immer populärer werdende Metasprache Extensible Markup Language (XML) erkoren (zur Funktionsweise siehe Kasten "Soap-Aufruf"). Anfangs war Soap noch sehr COM-orientiert, was angesichts seiner Herkunft nicht überrascht. Inzwischen haben sich jedoch weitere Hersteller an der Weiterentwicklung beteiligt, und die aktuelle Version 1.1 ist nun unabhängig von Komponentenmodell und Transportprotokoll. Neben HTTP, das mit seinem Request/ Response-Mechanismus perfekt für die RPC-Kommunikation geeignet ist, lässt sich mit Soap 1.1 auch HTTP-Messaging (über das HTTP Extension Framework), FTP (File Transfer) und SMTP (E-Mail) nutzen. Damit unterstützt Soap auch die Kommunikation in nur einer Richtung, zum Beispiel die Übergabe von Objekten an entfernte Anwendungen. Im Mai dieses Jahres wurde Soap 1.1 von einer Herstellergruppe, der neben den ursprünglichen drei Gründern auch Ariba, Iona Technologie, Sun Microsystems, SAP und IBM angehören, beim internationalen Internet-Standardisierungs-Gremium W3C eingereicht. Die Anerkennung von Soap als Standard gilt als wahrscheinlich. Die Chancen, dass es als neutrales Kommunikationsprotokoll die Kompatibilitätsprobleme zwischen konkurrierenden Komponentenmodellen lösen wird, stehen gut.

Auch wenn Soap noch kein verabschiedeter Standard ist und als Technologie noch in den Kinderschuhen steckt, wird es zweifellos eine wichtige Rolle bei der Verwirklichung der Vision vom "programmierbaren Web" spielen, nach der Anwendungsentwickler künftig aus einem weltweiten Repertoire von Web-Services schöpfen können. So glaubt zum Beispiel die Gartner Group, dass mit hoher Wahrscheinlichkeit über das Jahr 2004 hinaus Unternehmen, die eine Service-orientierte Architektur implementieren, einen Wettbewerbsvorteil erzielen werden, weil sie schneller und effizienter auf sich ändernde Geschäftsbedingungen reagieren können.

Gestützt wird dies auch durch wachsende Akzeptanz auf der Herstellerseite. So soll Soap das zentrale Kommunikationsprotokoll in Microsofts .NET-Initiative werden. Konsequenterweise hat sich auch für die Komponententechnologie der Fokus in Richtung Internet verlagert. Statt von COM+ ist nun von Web-Services die Rede: Komponenten, deren Funktionalität über das Internet - unter Verwendung von Soap, versteht sich - verfügbar wird. Das Ziel von .NET ist es, sowohl die komplette Infrastruktur für die Nutzung und Erstellung solcher Web-Services bereitzustellen, als auch bestimmte allgemein benötigte Services, die in einem solchen Umfeld wichtig sind (zum Beispiel für Authentisierung, Verzeichnisdienst). Neu: Mit dem .NET-Framework wird es eine gemeinsame Common Language Runtime (CLR) für alle Programmiersprachen geben. Diese Runtime ist klassenorientiert und erinnert auch sonst an die Java Virtual Machine. Primäre Programmiersprache für die Nutzung von CLR wird C# sein, Microsofts Antwort auf Java.

Bereits verfügbar ist das "Soap Toolkit für Visual Studio 6". Mittels eines "Wizard" kann aus einem COM-Automation-Server ein Web-Service generiert werden. Zusätzlich wird eine Schnittstellen-Beschreibung des Service erzeugt. Die Remote Object Proxy Engine (Rope), ebenfalls Bestandteil des Toolkit, erleichtert die Client-Programmierung, indem sie Services bereitstellt, welche die Schnittstellen-Beschreibung eines Web-Service laden, automatisch den entsprechenden Soap-Request aufbauen und ihn über HTTP an den Web-Service senden. Der übersetzt den Soap-Request in einen entsprechenden COM-Aufruf und liefert das Ergebnis an den Client zurück. Dieser Komfort steht jedoch nur in einer homogenen Microsoft-Welt zur Verfügung. Ein weiteres Anwendungsfeld für Soap innerhalb der .NET-Initiative stellt "Biztalk" dar. Das "Biztalk"-Framework spezifiziert den XML-basierenden Austausch von Business-Dokumenten (zum Beispiel eine Rechnung) über Biztalk-Nachrichten. Letztere ist wiederum ein Soap-Dokument, dessen Header Biztalk-spezifische Einträge hat und dessen Body das eigentliche Business-Dokument enthält - optional ergänzt um Anlagen.

Auf ähnlicher Ebene wie Biztalk bewegt sich ebXML (Electronic Business XML) - eine gemeinsame Initiative der Vereinten Nationen und des Oasis-Gremiums zur Definition eines Rahmenwerks für den Informationsaustausch im Electronic Business. Die mögliche Verwendung von Soap wird hier zurzeit noch untersucht. Für Java-basierende Web-Services gibt es zum einen das "Apache Soap Toolkit" (entstanden aus dem "Soap 4J Toolkit", das IBM der Apache Foundation übergeben hat) und, darauf aufbauend, das "IBM Web Services Toolkit for Java". Das Apache Toolkit liefert die Basisdienste in Form eines generischen "rpcrouter"-Servlets, das aufgrund des Inhalts des Soap-Dokuments und einer XML-Beschreibung des Web-Service die Übersetzung in den entsprechenden Java-Methodenaufruf und zurück in die Soap-Response durchführt.

IBM hat eigene Pläne bei Web-ServicesDer Komfort, den Rope für den Client bietet, fehlt hier, da auf der Client-Seite die Servicebeschreibung nicht verfügbar ist. Dies adressiert das IBM-Toolkit, verfolgt dabei aber ein etwas anderes Konzept als Microsoft: Web-Services werden mittels eines Service-Brokers veröffentlicht. Ein Web-Client benutzt den Service-Broker, um einen geeigneten Service zu finden, und erhält Informationen, die ihm den Aufruf dieses Services ermöglichen. Während die verschiedenen Toolkits auf der Soap-Protokollebene weitgehend kompatibel sind, verfolgen sie unterschiedliche, nicht kompatible Konzepte bei der Beschreibung und Lokalisierung der Web-Services. Weiter gehende Standardisierungsbestrebungen versprechen hier jedoch Abhilfe. Mit WSDL (Web Services Description Language) und vor allem "Universal Description, Discovery and Integration" (UDDI), das auf Soap aufsetzt, wurden bereits entsprechende Standards vorgeschlagen.

Aus dem Corba-Lager unterstützen zwei Hersteller bereits Soap: Iona Technologies, Mitglied der Standardisierungsgruppe, und Rogue Wave. Erstgenannter Hersteller nutzt Soap in seinem Produkt "I-Portal" zur Kommunikation und Integration zwischen E-Commerce-Portalen. Ein Soap-Zusatz für die Corba-Implementierung "Orbix 2000" ermöglicht das Erstellen von Orbix-Soap-Servern und das Umwandeln existierender Corba-Server in Web-Services. "Xorba" von Rogue Wave benutzt das Protokoll, um COM-Komponenten mit Corba- oder Java-Komponenten zu verbinden. Zudem stellt SAP für den Zugriff auf R/3-Funktionen über den Business Connector bereits eine XML-Variante seines RFC (Remote Function Call) bereit. Dieser XRFC benutzt einen Soap-ähnlichen Envelope und soll an den künftigen Soap-Standard angepasst werden.

Weil davon auszugehen ist, dass auch Funktionen von Anwendungen, die nicht auf der Basis eines Komponentenmodells entwickelt wurden (man denke nur an die vielen Cobol-Mainframe-Anwendungen), künftig als Web-Services verfügbar gemacht werden sollen, wird auch für diese Funktionen eine Soap-Übersetzung benötigt. Mit dem "EntireX XML Wrapper" der Software AG ist es bereits möglich, einfache Soap-Requests in Funktionsaufrufe von Legacy-Anwendungen, beispielsweise Cics-Transaktionen, zu übersetzen und sie damit zu Web-Services zu machen. Ebenso unterstützt der XML-Server "Tamino" das Protokoll. So können Soap-Nachrichten zum Beispiel aufgrund ihres Inhalts zu den jeweils zuständigen Servern geroutet werden, was Clients davon entbindet, zu jedem Web-Service die entsprechende Web-Adresse kennen zu müssen.

Als Fazit lässt sich festhalten: Soap ist zwar noch kein verabschiedeter Standard und steckt als Technologie noch in den Kinderschuhen. Doch es wird bei der Verwirklichung der Vision vom "programmierbaren Web", nach der Anwendungsentwickler künftig aus einem weltweiten Repertoire von Web-Services schöpfen können, zweifellos eine wichtige Rolle spielen. Gestützt wird dies nicht nur durch die breite Akzeptanz auf Herstellerseite, sondern auch durch Analysten-Einschätzungen. So glaubt zum Beispiel die Gartner Group, dass mit 80-prozentiger Wahrscheinlichkeit über das Jahr 2004 hinaus Unternehmen, die eine Service-orientierte Architektur implementieren, einen Wettbewerbsvorteil erzielen werden, weil sie schneller und effizienter auf sich ändernde Geschäftbedingungen reagieren können.*Angelika Siffring ist Product Marketing Manager bei der Software AG in Darmstadt.

AngeklicktMit dem Simple Object Access Protocol (Soap) reift derzeit ein Kommunikationsstandard heran, der aus zweierlei Sicht eine große Bedeutung für die Komponentenentwicklung haben wird. Zum einen verspricht er einen XML-basierenden Remote-Procedure-Call-Mechanismus, der mit den proprietären Lösungen aufräumen könnte und die Objektkommunikationen über Firewalls erleichtert. Zum anderen ist Soap ein wichtiger Baustein in der Vision vom "programmierbaren Web", in dem Anwendungsentwickler künftig aus einem weltweiten Repertoire von Web-Services schöpfen können.

Soap-AufrufEin Soap-Aufruf im Einzelnen: Das Top-Element muss der so genannte Envelope sein, der selbst aus einem oder mehreren optionalen Soap-Header-Elementen und dem obligatorischen Soap-Body besteht. Der Soap-Envelope definiert die Regeln für den Aufbau eines Soap-Dokuments (XML Namespace) und (optional) Regeln für die Darstellung von Daten in der Soap-Nachricht (Encoding Style) durch Verweis auf entsprechende Web-Adressen (siehe http://schemas.xmlSoap.org/Soap/envelope/ und http://schemas.xmlSoap.org/Soap/encoding/). Anwender, die nichts voneinander wissen, können mit Hilfe der Soap-Header zusätzliche Informationen für die Verarbeitung des Soap-Requests austauschen. Hier kann zum Beispiel gefordert werden, dass eine bestimmte Funktion unterstützt werden muss (Attribut "must understand"). Kann die Empfängeranwendung diese Funktion nicht erbringen, reagiert sie mit einer entsprechenden Fehlermeldung. Der Header könnte auch für Vereinbarungen in Bezug auf Security oder Transaktionsunterstützung verwendet werden. Beide Bereiche werden von Soap bewusst zugunsten der Einfachheit außen vor gelassen. Aus dem gleichen Grund wird auch die Behandlung von Statusinformation der jeweiligen Server-Implementierung überlassen.

Der Soap-Body enthält die eigentlichen Daten für den Aufruf der entfernten Funktion, deren Ergebnis oder Fehlerinformation. Ein typischer Soap-RPC läuft im Prinzip so ab, dass der Client ein entsprechend aufgebautes Soap-PXML-Dokument über HTTP POST versendet. Das Zielsystem wird über die zugehörige Web-Adresse (URL) adressiert. Im Zielsystem wird der Soap-Request abhängig von der Art der aufzurufenden Komponente in den entsprechenden lokalen RPC übersetzt. Das Ergebnis dieses Aufrufs muss nun wieder in ein Soap-Dokument übersetzt und mittels HTTP OK an den Client zurückgeliefert werden. Soap ist also kein Ersatz für die herkömmlichen Komponentenmodelle, sondern eine konsequente Weiterentwicklung der Komponententechnolgie für das Internet-Zeitalter. Soap steht und fällt mit der Verfügbarkeit entsprechender Übersetzerbausteine, die Soap-Nachrichten in das passende lokale RPC-Format umsetzen.

Abb.1: Soap im Einsatz

Das Soap-Protokoll ermöglicht den standardisierten Zugriff über Internet auf externe Funktionen. Beim Empfänger wird der Soap-Aufruf in das Kommunikationsprotokoll des jeweiligen lokalen Komponentenmodells (COM, CORBA, EJB) beziehungsweise einen anderen lokalen RPC übersetzt. Quelle: Software AG

Abb.2: Verbindung via Soap

Ablauf eines Soap-Methodenaufrufs: Der Client kontaktiert über ein natives RPC-Protokoll 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