Ein Überblick über die Bedeutung von XML Web Services für Entwickler mit Einführungen in SOAP, WSDL und UDDI. Dieser Artikel enthält Links zu englischen Webseiten.

Auf dieser Seite

 Was ist ein XML Web Service?
 SOAP
 WSDL
 UDDI
 Was bleibt?

Was ist ein XML Web Service?

XML Web services bilden die grundlegenden Bausteine für die Verwirklichung des verteilten Computing im Internet. Offene Standards und die Schwerpunktsetzung auf Kommunikation und Zusammenarbeit zwischen Menschen und Anwendungen haben eine Umgebung geschaffen, in der XML Web Services die Plattform für die Anwendungsintegration bilden. Anwendungen werden unter Verwendung mehrerer XML Web Services aus verschiedenen Quellen erstellt, die unabhängig davon zusammenarbeiten, wo sie sich befinden und wie sie implementiert wurden.

Es gibt wahrscheinlich so viele Definitionen des Begriffs "XML Web service" wie Unternehmen, die diese erstellen. Trotzdem haben fast alle diese Definitionen die folgenden Punkte gemeinsam:

• XML Web Services bieten Webbenutzern nützliche Funktionen über ein Standardwebprotokoll. In den meisten Fällen handelt es sich bei dem verwendeten Protokoll um SOAP.

• XML Web Services bieten eine Möglichkeit zur Beschreibung ihrer Schnittstellen, die detailliert genug ist, damit Benutzer Clientanwendungen zur Kommunikation mit diesen erstellen können. Diese Beschreibung ist in der Regel in einem XML-Dokument mit der Bezeichnung WSDL-Dokument (Web Services Description Language) enthalten.

• XML Web Services sind registriert, damit potenzielle Benutzer sie leicht finden können. Dies erfolgt mit Hilfe der UDDI-Technologie (Universal Discovery Description and Integration).

Wenn in diesem Artikel auch alle drei dieser Technologien behandelt werden, möchte ich zunächst erklären, warum XML Web services für Sie von Bedeutung sind.

Einer der Hauptvorteile der XML Web services-Architektur besteht darin, dass Programme, die in unterschiedlichen Programmiersprachen auf verschiedenen Plattformen erstellt wurden, mit Hilfe standardisierter Verfahren miteinander kommunizieren können. Diejenigen unter Ihnen, die schon eine Weile in dieser Branche arbeiten, werden jetzt sagen: "Moment! Habe ich nicht dieselben Versprechungen von CORBA und vorher von DCE gehört? Worin liegt hier der Unterschied?". Der erste Unterschied besteht darin, dass SOAP wesentlich weniger komplex als frühere Ansätze ist, weshalb die Hürde für eine standardisierte SOAP-Implementierung bedeutend geringer ist. Paul Kulchenko führt eine Liste von SOAP-Implementierungen unter der folgenden Adresse: http://www.soapware.org/directory/4/implementations. Diese enthielt bei der letzten Zählung 79 Einträge. Erwartungsgemäß finden Sie hier SOAP-Implementierungen von den meisten großen Software-Unternehmen, aber es sind auch viele Implementierungen enthalten, die von einzelnen Entwicklern erstellt und verwaltet wurden. Der andere wesentliche Vorteil, den XML Web Services gegenüber früheren Anstrengungen haben, besteht darin, dass diese mit den Standardwebprotokollen XML, HTTP und TCP/IP zusammenarbeiten. Eine beträchtliche Anzahl von Unternehmen verfügt bereits über eine Webinfrastruktur und das Personal mit dem Know-How und der Erfahrung, um diese zu verwalten. Aus diesem Grund sind die Einstiegskosten für XML Web Services wesentlich geringer als bei früheren Technologien.

Wir haben einen XML Web Service als Softwaredienst definiert, der im Web über SOAP zur Verfügung gestellt, mit einer WSDL-Datei beschrieben und in der UDDI-Technologie registriert wird. Die nächste logische Frage lautet: "Was kann ich mit XML Web Services machen?". Die ersten XML Web Services waren vorwiegend Informationsquellen, die Sie einfach in Anwendungen integrieren konnten, also Aktienkurse, Wettervorhersagen, Sportergebnisse usw. Es sind eine ganze Reihe von Anwendungen vorstellbar, die zur Analyse und Sammlung der für Sie wichtigen Daten erstellt und auf verschiedene Art und Weise präsentiert werden können. So verfügen Sie beispielsweise über eine Microsoft® Excel-Kalkulationstabelle, die Ihre gesamte finanzielle Situation zusammenfasst: Aktien, Bankkonten, Darlehen usw. Wenn diese Informationen über XML Web Services verfügbar sind, kann Excel diese ständig aktualisieren. Einige dieser Informationen sind eventuell kostenlos, während andere ein Abonnement des Dienstes erfordern. Zwar sind die meisten dieser Informationen heute im Web verfügbar, jedoch machen XML Web Services den programmatischen Zugriff darauf einfacher und zuverlässiger.

Indem vorhandene Anwendungen als XML Web Services zur Verfügung gestellt werden, können Benutzer neue und leistungsfähigere Anwendungen erstellen, die XML Web services als Bausteine verwenden. So könnte beispielsweise ein Entwickler eine Einkaufsanwendung erstellen, um automatisch Preisinformationen von einer Vielzahl von Herstellern abzurufen. Anschließend kann der Benutzer einen Hersteller auswählen, die Bestellung aufgeben und die Auslieferung bis zum Wareneingang verfolgen. Die Herstelleranwendung könnte wiederum neben den im Web zur Verfügung gestellten Diensten die XML Web services verwenden, um die Kreditkarte des Kunden zu überprüfen, das Konto des Kunden zu belasten und die Auslieferung mit einem Versandunternehmen zu arrangieren.

In Zukunft werden einige der interessantesten XML Web Services Anwendungen unterstützen, die das Web nutzen, um Dinge zu tun, die heute noch nicht möglich sind. So wird das Projekt Microsoft .NET My Services unter anderem einen Kalenderdienst unterstützen. Wenn Ihr Zahnarzt oder Ihre Autowerkstatt ihre Kalender über diesen XML Web service veröffentlichen würden, könnten Sie online mit diesen Termine arrangieren, oder diese könnten umgekehrt Termine für Reinigungs- und Wartungsaufgaben direkt in Ihren Kalender eintragen, wenn Sie das wünschen. Mit ein bisschen Phantasie können Sie sich hunderte von Anwendungen vorstellen, die sich erstellen lassen, sobald Sie die Möglichkeit haben, im Web zu programmieren.

Weitere Informationen zu XML Web Services und den Anwendungen, die Sie mit deren Hilfe erstellen können, finden Sie in der Web Services-MSDN-Homepage.

 Zum Seitenanfang

SOAP

SOAP ist das Kommunikationsprotokoll für XML Web Services. Wenn SOAP als ein Kommunikationsprotokoll bezeichnet wird, denken die meisten an DCOM oder CORBA und stellen beispielsweise folgende Fragen: "Wie funktioniert die Objektaktivierung bei SOAP?" oder "Welchen Naming Service verwendet SOAP?". Obwohl eine SOAP-Implementierung diese Dinge wahrscheinlich enthält, legt der SOAP-Standard diese nicht fest. Bei SOAP handelt es sich um eine Spezifikation, die das XML-Format für Nachrichten definiert - mehr enthält der erforderliche Teil der Spezifikation nicht. Wenn Sie über ein wohlgeformtes XML-Fragment verfügen, das in ein paar SOAP-Elemente eingeschlossen ist, haben Sie bereits eine SOAP-Nachricht. Einfach, nicht wahr?

Es gibt andere Teile der SOAP-Spezifikation, die beschreiben, wie Programmdaten als XML darzustellen und wie mit SOAP Remoteprozeduraufrufe (RPC) durchzuführen sind. Diese optionalen Teile der Spezifikation dienen der Implementierung von RPC-artigen Anwendungen. Dabei werden eine SOAP-Anwendung mit einer aufrufbaren Funktion und die Parameter zur Übergabe an die Funkion vom Client gesendet, und der Server gibt eine Nachricht mit den Ergebnissen der ausgeführten Funktion zurück. Die meisten aktuellen Implementierungen von SOAP unterstützen RPC-Anwendungen, da Programmierer, die an COM- und CORBA-Anwendungen gewöhnt sind, den RPC-Stil verstehen. SOAP unterstützt auch Anwendungen im Dokumentstil, bei denen die SOAP-Nachricht nur ein Wrapper um ein XML-Dokument ist. SOAP-Anwendungen im Dokumentstil sind sehr flexibel, und viele neue XML Web Services nutzen diese Flexibilität zur Erstellung von Diensten, die mit RPC schwer zu implementieren wären.

Der letzte optionale Teil der SOAP-Spezifikation definiert das Aussehen einer HTTP-Nachricht, die eine SOAP-Nachricht enthält. Diese HTTP-Bindung ist wichtig, da HTTP von fast allen aktuellen (und vielen nicht so aktuellen) Betriebssystemen unterstützt wird. Obwohl die HTTP-Bindung optional ist, wird sie fast von allen SOAP-Implementierungen unterstützt, da es sich um das einzige standardisierte Protokoll für SOAP handelt. Aus diesem Grund wird oft fälschlicherweise angenommen, dass SOAP das HTTP-Protokoll erfordert. Obwohl einige Implementierungen MSMQ, MQ Series, SMTP oder TCP/IP-Transporte unterstützen, verwenden fast alle aktuellen XML Web Services HTTP, da es überall verbreitet ist. Da HTTP ein Kernprotokoll im Internet ist, verfügen die meisten Organisationen bereits über eine Netzwerkinfrastruktur, die HTTP unterstützt, und das entsprechende Personal für deren Verwaltung. Die Sicherheits-, Überwachungs- und Lastenausgleichsinfrastruktur für HTTP ist heute überall verfügbar.

Eine Hauptursache für Missverständnisse beim Einstieg in SOAP ist der Unterschied zwischen der SOAP-Spezifikation und den vielen Implementierungen der SOAP-Spezifikation. Die meisten Benutzer von SOAP schreiben SOAP-Nachrichten nicht direkt, sondern verwenden ein SOAP-Toolkit zur Erstellung und Analyse von SOAP-Nachrichten. Diese Toolkits übersetzen im Allgemeinen Funktionsaufrufe von einer bestimmten Sprache in eine SOAP-Nachricht. Beispiel: Das Microsoft SOAP Toolkit 2.0 übersetzt COM-Funktionsaufrufe in SOAP, und das Apache Toolkit übersetzt JAVA-Funktionsaufrufe in SOAP. Die Arten der Funktionsaufrufe und die Datentypen der unterstützten Parameter sind je nach SOAP-Implementierung unterschiedlich, so dass eine Funktion, die mit einem Toolkit funktioniert, eventuell nicht mit einem anderen funktioniert. Dies ist keine Einschränkung von SOAP, sondern vielmehr der spezifischen Implementierung, die verwendet wird.

Bei weitem das beeindruckendste Merkmal von SOAP ist die Tatsache, dass es auf vielen unterschiedlichen Hardware- und Softwareplattformen implementiert wurde. Dies bedeutet, dass SOAP zur Verbindung unterschiedlicher Systeme innerhalb und außerhalb Ihrer Organisation verwendet werden kann. In der Vergangenheit wurden viele Versuche unternommen, ein gemeinsames Kommunikationsprotokoll zu finden, das für die Systemintegration verwendet werden konnte, jedoch fand keines davon eine so breite Akzeptanz wie SOAP. Woran liegt das? Der Grund liegt darin, dass SOAP viel kleiner und viel einfacher zu implementieren ist als viele der früheren Protokolle. DCE und CORBA brauchten beispielsweise Jahre für ihre Implementierung, weshalb nur wenige Implementierungen jemals freigegeben wurden. SOAP hingegen kann vorhandene XML-Parser und HTTP-Bibliotheken nutzen, um einen Großteil der schwierigen Arbeit zu erledigen. Auf diese Weise lässt sich eine SOAP-Implementierung in wenigen Monaten abschließen. Aus diesem Grund stehen bereits mehr als 70 SOAP-Implementierungen zur Verfügung. Natürlich kann SOAP nicht alles, was DCE oder CORBA können, aber es ist diese Simplizität kontra Funktionsvielfalt, die SOAP so populär macht.

Die weite Verbreitung von HTTP und die Einfachheit von SOAP machen sie zu einer idealen Basis für die Implementierung von XML Web Services, die von fast jeder Umgebung aus aufgerufen werden können. Weitere Informationen finden Sie in der SOAP-MSDN-Homepage.

Wie sieht es mit der Sicherheit aus?

Eine der ersten Fragen, die neue Benutzer von SOAP stellen, betrifft den Umgang von SOAP mit der Sicherheit. In einem frühen Entwicklungsstadium wurde SOAP als HTTP-basiertes Protokoll angesehen, weshalb man davon ausging, dass die HTTP-Sicherheit für SOAP adäquat wäre. Tatsächlich laufen tausende von Webanwendungen heute unter Verwendung der HTTP-Sicherheit, also müsste diese doch auch für SOAP ausreichend sein. Aus diesem Grund sieht der aktuelle SOAP-Standard die Sicherheit als Transportproblematik und schweigt zu Sicherheitsthemen.

Als SOAP zu einem Allzweckprotokoll erweitert wurde, das über einer Reihe von anderen Transportmechanismen läuft, wurde die Sicherheit zu einem größeren Thema. So bietet HTTP beispielsweise mehrere Methoden, um zu authentifizieren, welcher Benutzer den SOAP-Aufruf durchführt. Wie aber wird diese Identität übertragen, wenn die Nachricht vom HTTP-Protokoll zu einem SMTP-Transport weitergeleitet wird? SOAP wurde als Bausteinprotokoll entworfen, weshalb glücklicherweise schon Spezifikationen für die Erweiterung von SOAP in Bearbeitung sind, um zusätzliche Sicherheitsfunktionen für Web Services zu bieten. Die WS-Security-Spezifikation definiert ein umfassendes Verschlüsselungssystem und die WS-License-Spezifikation definiert Techniken, die die Identität des Anrufers garantieren und sicherstellen, dass nur autorisierte Benutzer einen Web Service verwenden können.

 Zum Seitenanfang

WSDL

WSDL ist die Abkürzung für Web Services Description Language. Für unsere Zwecke können wir sagen, dass eine WSDL-Datei ein XML-Dokument ist, das eine Reihe von SOAP-Nachrichten und die Art ihres Austausches beschreibt. Anders gesagt: WSDL ist für SOAP, was IDL für CORBA oder COM ist. Da WSDL das XML-Format hat, ist es zwar lesbar und editierbar, wird aber in den meisten Fällen von Software generiert und konsumiert.

Um den Wert von WSDL einschätzen zu können, sollten Sie sich vorstellen, Sie möchten eine SOAP-Methode aufrufen, die von einem Ihrer Geschäftspartner zur Verfügung gestellt worden ist. Sie könnten ihn um einige SOAP-Beispielnachrichten bitten und anschließend eine Anwendung erstellen, die ähnliche Nachrichten erzeugt und konsumiert. Dieses Verfahren kann jedoch anfällig für Fehler sein. So könnten Sie beispielsweise die Kunden-ID 2837 für eine ganze Zahl halten, obwohl es sich tatsächlich um eine Zeichenfolge handelt. WSDL legt den verbindlichen Inhalt einer Anforderungsnachricht fest und gibt an, wie die Antwortnachricht in eindeutiger Notation aussehen muss.

Die Notation, die eine WSDL-Datei zur Beschreibung von Nachrichtenformaten verwendet, basiert auf dem XML Schema-Standard, was bedeutet, dass sie sowohl programmiersprachenunabhängig als auch standardisiert ist. Dadurch eignet sie sich für die Beschreibung der Schnittstellen von XML Web Services, auf die von einer Vielzahl von Plattformen und Programmiersprachen aus zugegriffen werden kann. Neben der Beschreibung von Nachrichteninhalten definiert WSDL, wo der Dienst verfügbar ist, und welches Kommunikationsprotokoll für die Kommunikation mit dem Dienst verwendet wird. Dies bedeutet, dass die WSDL-Datei alle erforderlichen Aspekte definiert, die für die Erstellung eines Programms erforderlich sind, das mit einem XML Web Service zusammenarbeitet. Es gibt verschiedene Tools zum Lesen einer WSDL-Datei und zum Generieren des Quelltextes, der für die Kommunikation mit einem XML Web Service erforderlich ist. Einige der leistungsfähigsten dieser Tools sind in Microsoft Visual Studio® .NET enthalten.

Eine Vielzahl der aktuellen SOAP-Toolkits enthalten Tools zur Generierung von WSDL-Dateien aus vorhandenen Programmschnittstellen, jedoch gibt es nur wenige Tools für die direkte Erstellung von WSDL. Außerdem ist die Toolunterstützung für WSDL nicht so umfassend, wie dies der Fall sein sollte. Es wird wohl nicht lange dauern, bis Tools zur Erstellung von WSDL-Dateien und zur anschließenden Generierung von Proxys und Stubs, ähnlich wie bei COM IDL-Tools, Teil der meisten SOAP-Implementierungen sein werden. Dann wird sich WSDL zur bevorzugten Methode für die Erstellung von SOAP-Schnittstellen für XML Web Services entwickeln.

In der MSDN-Hompage steht eine exzellente Beschreibung von WSDL zur Verfügung. Außerdem finden Sie die WSDL-Spezifikation unter der folgenden Adresse: http://www.w3.org/TR/wsdl.

 Zum Seitenanfang

UDDI

Die UDDI-Technologie (Universal Discovery Description and Integration) kann als die "Gelben Seiten" von Web Services bezeichnet werden. Wie bei herkömmlichen Gelben Seiten können Sie nach einer Firma suchen, die die von Ihnen benötigten Dienste anbietet, eine Beschreibung der angebotenen Dienste lesen und anschließend Kontakt aufnehmen, um weitere Informationen zu erhalten. Natürlich können Sie auch einen Web Service anbieten, ohne diesen in UDDI zu registrieren, genauso wie es möglich ist, ein Geschäft bei sich zu Hause zu eröffnen und sich dann auf Mundpropaganda zu verlassen. Wenn Sie jedoch eine größere Zielgruppe erreichen möchten, benötigen Sie UDDI, damit Ihre Kunden Sie finden können.

Ein UDDI-Verzeichniseintrag ist eine XML-Datei, die ein Unternehmen und die angebotenen Dienstleistungen beschreibt. Ein Eintrag in das UDDI-Verzeichnis besteht aus drei Teilen. Die "Weißen Seiten" beschreiben das Unternehmen, das den Dienst anbietet: Name, Adresse, Kontaktpersonen usw. Die "Gelben Seiten" enthalten Industriekategorien auf der Basis von Standardtaxonomien wie dem North American Industry Classification System und der Standard Industrial Classification. Die "Grünen Seiten" beschreiben die Schnittstelle des Dienstes detailliert genug, damit Benutzer eine Anwendung zur Verwendung des Web Service erstellen können. Die Dienste werden über ein UDDI-Dokument definiert, das als "Type Model" bzw. "tModel" bezeichnet wird. In vielen Fällen enthält das tModell eine WSDL-Datei, die eine SOAP-Schnittstelle zu einem XML Web Service beschreibt, jedoch ist das tModell flexibel genug, um fast jede Art von Dienst zu beschreiben.

Das UDDI-Verzeichnis enthält auch verschiedene Möglichkeiten zur Suche nach den Diensten, die Sie zur Erstellung Ihrer Anwendungen benötigen. So können Sie beispielsweise nach Anbietern eines Dienstes in einer bestimmten geografischen Region oder nach einem bestimmten Geschäftstyp suchen. Das UDDI-Verzeichnis liefert dann Informationen, Kontakte, Verknüpfungen und technische Daten, anhand derer Sie einschätzen können, welche Dienste Ihren Anforderungen entsprechen.

UDDI ermöglicht Ihnen die Suche nach Unternehmen, von denen Sie eventuell Web Services erwerben möchten. Was ist, wenn Sie bereits wissen, mit wem Sie Geschäfte machen möchten, aber die angebotenen Dienste noch nicht kennen? Mit Hilfe der WS-Inspection-Spezifikation können Sie eine Sammlung von XML Web Services durchsuchen, die auf einem bestimmten Server angeboten werden, um herauszufinden, welche Ihren Anforderungen entsprechen.

Weitere Informationen zu UDDI finden Sie unter der Adresse http://www.uddi.org/about.html.

 Zum Seitenanfang

Was bleibt?

Bisher wurde erläutert, wie mit XML Web Services kommuniziert wird (SOAP), wie XML Web Services beschrieben werden (WSDL) und wie XML Web Services gefunden werden können (UDDI). Diese Verfahren und Technologien stellen eine Reihe von Basisspezifikationen dar, die die Grundlage für die Anwendungsintegration und -aggregation bilden. Auf der Grundlage dieser Basisspezifikationen erstellen Unternehmen Lösungen für die Praxis und ziehen einen echten Nutzen daraus.

Obwohl schon viel unternommen wurde, um XML Web Services in der Praxis zu etablieren, sind noch weitere Schritte nötig. Schon heute setzen Anwender XML Web Services erfolgreich ein, trotzdem sind noch einige Aufgaben für Entwickler zu erledigen, z.B. Sicherheit, operative Verwaltung, Transaktionen, zuverlässiges Messaging. Die Global XML Web Services-Architektur wird dabei helfen, eine neue Dimension von XML Web Services zu erschließen, indem sie ein kohärentes und universell einsetzbares Modell für das Hinzufügen neuer erweiterter Funktionen zu XML Web Services bietet, das modular und erweiterbar ist.

Die oben genannten Sicherheitsmodule (WS-Security und WS-License) sind nur einige der Spezifikationen in der Global Web Services-Architektur. Teil dieser Architektur sind auch Anforderungen der operativen Verwaltung, wie etwa das Weiterleiten von Nachrichten zwischen einer großen Anzahl von Servern und das dynamische Konfigurieren dieser Server für die Verarbeitung. Diese Anforderungen werden in der WS-Routing-Spezifikation und der WS-Referral-Spezifikation berücksichtigt. Im Laufe der Weiterentwicklung der Global Web Services Architektur werden Spezifikationen für diese und andere Anforderungen eingeführt.

Weitere Informationen finden Sie unter Global XML Web Services Architecture.

 Zum Seitenanfang

Links zu verwandten Themen

• XML Web Services Basics

Zum Seitenanfang