Grundlagen zu XML-Webdiensten
Roger Wolter
Microsoft Corporation
Dezember 2001
Zusammenfassung: Eine Übersicht über den Wert von XML-Webdiensten für Entwickler mit Einführungen in SOAP, WSDL und UDDI. (6 gedruckte Seiten)
Inhalte
Was ist ein XML-Webdienst?
SOAP
WSDL
UDDI
Was ist noch übrig?
Was ist ein XML-Webdienst?
XML-Webdienste sind die grundlegenden Bausteine bei der Umstellung auf verteiltes Computing im Internet. Offene Standards und der Fokus auf Kommunikation und Zusammenarbeit zwischen Personen und Anwendungen haben eine Umgebung geschaffen, in der XML-Webdienste zur Plattform für die Anwendungsintegration werden. Anwendungen werden mit mehreren XML-Webdiensten aus verschiedenen Quellen erstellt, die unabhängig davon zusammenarbeiten, wo sie sich befinden oder wie sie implementiert wurden.
Es gibt wahrscheinlich so viele Definitionen von XML-Webdiensten wie Unternehmen, die sie erstellen, aber fast alle Definitionen haben diese Dinge gemeinsam:
- XML-Webdienste machen Webbenutzern nützliche Funktionen über ein Standardwebprotokoll verfügbar. In den meisten Fällen wird soap als Protokoll verwendet.
- XML-Webdienste bieten eine Möglichkeit, ihre Schnittstellen so detailliert zu beschreiben, dass ein Benutzer eine Clientanwendung erstellen kann, um mit ihnen zu kommunizieren. Diese Beschreibung wird in der Regel in einem XML-Dokument bereitgestellt, das als WSDL-Dokument (Web Services Description Language) bezeichnet wird.
- XML-Webdienste werden registriert, damit potenzielle Benutzer sie leicht finden können. Dies erfolgt mit der Universellen Ermittlungsbeschreibung und -integration (UDDI).
Ich werde alle drei dieser Technologien in diesem Artikel behandeln, aber zuerst möchte ich erklären, warum Sie sich um XML-Webdienste kümmern sollten.
Einer der Hauptvorteile der XML-Webdienstarchitektur besteht darin, dass sie es Programmen ermöglicht, die in verschiedenen Sprachen auf verschiedenen Plattformen geschrieben wurden, auf standardbasierte Weise miteinander zu kommunizieren. Diejenigen von Ihnen, die eine Weile in der Branche waren, sagen jetzt: "Moment mal! Habe ich nicht die gleichen Versprechen von CORBA und vor dem DCE gehört? Wie unterscheidet sich das?" Der erste Unterschied besteht darin, dass SOAP deutlich weniger komplex ist als frühere Ansätze, sodass die Einstiegshürde für eine standardkonforme SOAP-Implementierung deutlich niedriger ist. Paul Kulchenko verwaltet eine Liste der SOAP-Implementierungen unter: http://www.soapware.org/directory/4/implementations die letzte Anzahl enthielt 79 Einträge. Sie werden wie erwartet SOAP-Implementierungen von den meisten großen Softwareunternehmen finden, aber Sie werden auch viele Implementierungen finden, die von einem einzelnen Entwickler erstellt und verwaltet werden. Der andere wesentliche Vorteil von XML-Webdiensten gegenüber früheren Bemühungen besteht darin, dass sie mit Standardwebprotokollen arbeiten – XML, HTTP und TCP/IP. Eine beträchtliche Anzahl von Unternehmen verfügt bereits über eine Webinfrastruktur und Personen mit Kenntnissen und Erfahrungen in derEnthaltung, sodass die Kosten für die Eingabe für XML-Webdienste deutlich niedriger sind als bei früheren Technologien.
Wir haben einen XML-Webdienst als Softwaredienst definiert, der im Web über SOAP verfügbar gemacht wird, mit einer WSDL-Datei beschrieben und in UDDI registriert ist. Die nächste logische Frage lautet. "Was kann ich mit XML-Webdiensten tun?" Die ersten XML-Webdienste waren in der Regel Informationsquellen, die Sie leicht in Anwendungen integrieren konnten– Aktienkurse, Wettervorhersagen, Sportergebnisse usw. Es ist leicht, sich eine ganze Klasse von Anwendungen vorzustellen, die erstellt werden könnten, um die Ihnen wichtigen Informationen zu analysieren und zu aggregieren und ihnen auf verschiedene Weise zu präsentieren. Beispielsweise verfügen Sie möglicherweise über eine Microsoft® Excel-Tabelle, die Ihr gesamtes finanzwirtschaftliches Bild zusammenfasst – Aktien, 401.000, Bankkonten, Darlehen usw. Wenn diese Informationen über XML-Webdienste verfügbar sind, kann Excel sie kontinuierlich aktualisieren. Einige dieser Informationen sind kostenlos, und einige erfordern möglicherweise ein Abonnement für den Dienst. Die meisten dieser Informationen sind jetzt im Web verfügbar, aber XML-Webdienste machen den programmgesteuerten Zugriff darauf einfacher und zuverlässiger.
Wenn Sie vorhandene Anwendungen als XML-Webdienste verfügbar machen, können Benutzer neue, leistungsfähigere Anwendungen erstellen, die XML-Webdienste als Bausteine verwenden. Beispielsweise kann ein Benutzer eine Kaufanwendung entwickeln, um automatisch Preisinformationen von einer Vielzahl von Anbietern abzurufen, dem Benutzer die Auswahl eines Anbieters zu ermöglichen, die Bestellung zu übermitteln und die Sendung dann nachzuverfolgen, bis sie empfangen wird. Die Anbieteranwendung kann zusätzlich zur Offenlegung ihrer Dienste im Web xml-Webdienste verwenden, um die Gutschrift des Kunden zu überprüfen, das Konto des Kunden zu belasten und die Sendung bei einem Versandunternehmen einzurichten.
In Zukunft werden einige der interessantesten XML-Webdienste Anwendungen unterstützen, die das Web verwenden, um Dinge zu tun, die heute nicht mehr möglich sind. Einer der Dienste, die XML-Webdienste ermöglichen würden, ist beispielsweise ein Kalenderdienst. Wenn Ihr Zahnarzt und Mechaniker ihre Kalender über diesen XML-Webdienst verfügbar gemacht haben, können Sie Termine mit ihnen online planen oder Termine für die Reinigung und Routinewartung direkt in Ihrem Kalender planen, wenn Sie möchten. Mit ein wenig Phantasie können Sie sich Hunderte von Anwendungen vorstellen, die erstellt werden können, sobald Sie die Möglichkeit haben, das Web zu programmieren.
Weitere Informationen zu XML-Webdiensten und den Anwendungen, die Ihnen bei der Erstellung helfen, finden Sie im MSDN XML Web Services Developer Center.
SOAP
Soap ist das Kommunikationsprotokoll für XML-Webdienste. Wenn SOAP als Kommunikationsprotokoll beschrieben wird, denken die meisten Leute an DCOM oder CORBA und fragen sich Beispielsweise: "Wie macht SOAP die Objektaktivierung?" oder "Welchen Namensdienst verwendet SOAP?" Während eine SOAP-Implementierung diese Dinge wahrscheinlich enthält, gibt der SOAP-Standard sie nicht an. SOAP ist eine Spezifikation, die das XML-Format für Nachrichten definiert – und zwar für die erforderlichen Teile der Spezifikation. Wenn Sie über ein wohlgeformtes XML-Fragment verfügen, das in ein paar SOAP-Elemente eingeschlossen ist, verfügen Sie über eine SOAP-Nachricht. Einfach nicht?
Es gibt weitere Teile der SOAP-Spezifikation, die beschreiben, wie Programmdaten als XML dargestellt werden und wie SOAP zum Ausführen von Remoteprozeduraufrufen verwendet wird. Diese optionalen Teile der Spezifikation werden verwendet, um Anwendungen im RPC-Stil zu implementieren, bei denen eine SOAP-Nachricht mit einer aufrufbaren Funktion und die an die Funktion übergebenden Parameter vom Client gesendet wird und der Server eine Nachricht mit den Ergebnissen der ausgeführten Funktion zurückgibt. Die meisten aktuellen Soap-Implementierungen unterstützen RPC-Anwendungen, da Programmierer, die com- oder CORBA-Anwendungen gewohnt 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-Webdienste nutzen diese Flexibilität, um Dienste zu erstellen, die mit RPC schwer zu implementieren wären.
Der letzte optionale Teil der SOAP-Spezifikation definiert, wie eine HTTP-Nachricht aussieht, die eine SOAP-Nachricht enthält. Diese HTTP-Bindung ist wichtig, da HTTP von fast allen aktuellen Betriebssystemen (und vielen nicht so aktuellen Betriebssystemen) unterstützt wird. Die HTTP-Bindung ist optional, aber fast alle SOAP-Implementierungen unterstützen sie, da es sich um das einzige standardisierte Protokoll für SOAP handelt. Aus diesem Grund gibt es ein häufiges Missverständnis, dass SOAP HTTP erfordert. Einige Implementierungen unterstützen MSMQ-, MQ-, SMTP- oder TCP/IP-Transporte, aber fast alle aktuellen XML-Webdienste verwenden HTTP, da es allgegenwärtig ist. Da HTTP ein Kernprotokoll des Webs ist, verfügen die meisten Organisationen über eine Netzwerkinfrastruktur, die HTTP unterstützt, und Personen, die bereits wissen, wie es verwaltet wird. Die Sicherheits-, Überwachungs- und Lastenausgleichsinfrastruktur für HTTP ist heute verfügbar.
Ein wichtiger Grund für Verwirrung bei den ersten Schritten mit SOAP ist der Unterschied zwischen der SOAP-Spezifikation und den vielen Implementierungen der SOAP-Spezifikation. Die meisten Personen, die SOAP verwenden, schreiben SOAP-Nachrichten nicht direkt, sondern verwenden ein SOAP-Toolkit, um die SOAP-Nachrichten zu erstellen und zu analysieren. Diese Toolkits übersetzen im Allgemeinen Funktionsaufrufe aus einer Art von Sprache in eine SOAP-Nachricht. Beispielsweise übersetzt das Microsoft SOAP Toolkit 2.0 COM-Funktionsaufrufe in SOAP, und das Apache Toolkit übersetzt JAVA-Funktionsaufrufe in SOAP. Die Typen von Funktionsaufrufen und die Datentypen der unterstützten Parameter variieren je nach SOAP-Implementierung, sodass eine Funktion, die mit einem Toolkit funktioniert, möglicherweise nicht mit einem anderen funktioniert. Dies ist keine Einschränkung von SOAP, sondern eher der jeweiligen Implementierung, die Sie verwenden.
Das bei weitem überzeugendste Feature von SOAP ist, dass es auf vielen verschiedenen Hardware- und Softwareplattformen implementiert wurde. Dies bedeutet, dass SOAP verwendet werden kann, um unterschiedliche Systeme innerhalb und ohne Ihre organization zu verknüpfen. In der Vergangenheit wurden viele Versuche unternommen, ein gemeinsames Kommunikationsprotokoll zu erstellen, das für die Systemintegration verwendet werden konnte. Warum? Weil SOAP viel kleiner und einfacher zu implementieren ist als viele der vorherigen Protokolle. Die Implementierung von DCE und CORBA dauerte beispielsweise Jahre, sodass nur wenige Implementierungen jemals veröffentlicht wurden. SOAP kann jedoch vorhandene XML-Parser und HTTP-Bibliotheken verwenden, um den größten Teil der harten Arbeit zu erledigen, sodass eine SOAP-Implementierung in wenigen Monaten abgeschlossen werden kann. Aus diesem Grund stehen mehr als 70 SOAP-Implementierungen zur Verfügung. SOAP macht natürlich nicht alles, was DCE oder CORBA tun, aber die mangelnde Komplexität im Austausch für Features macht SOAP so leicht verfügbar.
Die Ubiquity von HTTP und die Einfachheit von SOAP machen sie zu einer idealen Grundlage für die Implementierung von XML-Webdiensten, die aus fast jeder Umgebung aufgerufen werden können. Weitere Informationen zu SOAP finden Sie auf der MSDN SOAP-Startseite .
Was ist mit Sicherheit?
Eine der ersten Fragen, die Einsteiger in SOAP stellen, ist, wie SOAP mit Sicherheit umgeht. Zu Beginn seiner Entwicklung wurde SOAP als HTTP-basiertes Protokoll betrachtet, sodass davon ausgegangen wurde, dass DIE HTTP-Sicherheit für SOAP angemessen wäre. Schließlich gibt es tausende von Webanwendungen, die heute mit HTTP-Sicherheit ausgeführt werden, so dass dies für SOAP sicherlich angemessen ist. Aus diesem Grund geht der aktuelle SOAP-Standard davon aus, dass sicherheit ein Transportproblem ist und sicherheitsrelevante Probleme nicht behandelt werden.
Als SOAP zu einem allgemeineren Protokoll erweitert wurde, das zusätzlich zu einer Reihe von Transporten ausgeführt wird, wurde die Sicherheit zu einem größeren Problem. Http bietet beispielsweise mehrere Möglichkeiten, um zu authentifizieren, welcher Benutzer einen SOAP-Aufruf durchführt, aber wie wird diese Identität weitergegeben, wenn die Nachricht von HTTP an einen SMTP-Transport weitergeleitet wird? SOAP wurde als Bausteinprotokoll konzipiert, sodass glücklicherweise bereits Spezifikationen in Arbeit sind, um auf SOAP aufzubauen, um zusätzliche Sicherheitsfeatures für Webdienste bereitzustellen. Die WS-Security-Spezifikation definiert ein vollständiges Verschlüsselungssystem.
WSDL
WSDL (oft ausgesprochen whiz-dull) steht für Web Services Description Language. Für unsere Zwecke können wir sagen, dass eine WSDL-Datei ein XML-Dokument ist, das einen Satz von SOAP-Nachrichten und den Austausch der Nachrichten beschreibt. Mit anderen Worten, WSDL ist für SOAP, was IDL für CORBA oder COM ist. Da WSDL XML ist, ist es lesbar und bearbeitbar, aber in den meisten Fällen wird es von Software generiert und verwendet.
Um den Wert von WSDL zu sehen, stellen Sie sich vor, Sie möchten eine SOAP-Methode aufrufen, die von einem Ihrer Geschäftspartner bereitgestellt wird. Sie können ihn um einige SOAP-Beispielnachrichten bitten und Ihre Anwendung schreiben, um Nachrichten zu erstellen und zu nutzen, die wie in den Beispielen aussehen, aber dies kann fehleranfällig sein. Beispielsweise können Sie eine Kunden-ID von 2837 sehen und davon ausgehen, dass es sich um eine ganze Zahl handelt, wenn es sich tatsächlich um eine Zeichenfolge handelt. WSDL gibt an, was eine Anforderungsnachricht enthalten muss und wie die Antwortnachricht in eindeutiger Notation aussieht.
Die Notation, die eine WSDL-Datei zum Beschreiben von Nachrichtenformaten verwendet, basiert auf dem XML-Schemastandard, d. h. sie ist sowohl programmierspracheneutral als auch standardbasiert, wodurch sie zum Beschreiben von XML-Webdienstschnittstellen geeignet ist, auf die von einer Vielzahl von Plattformen und Programmiersprachen aus zugegriffen werden kann. Neben der Beschreibung des Nachrichteninhalts 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 alles definiert, was zum Schreiben eines Programms für die Arbeit mit einem XML-Webdienst erforderlich ist. Es gibt mehrere Tools zum Lesen einer WSDL-Datei und generieren den Code, der für die Kommunikation mit einem XML-Webdienst erforderlich ist. Einige der fähigsten Tools sind in Microsoft Visual Studio® .NET.
Viele aktuelle SOAP-Toolkits enthalten Tools zum Generieren von WSDL-Dateien aus vorhandenen Programmschnittstellen, aber es gibt nur wenige Tools zum direkten Schreiben von WSDL, und die Toolunterstützung für WSDL ist nicht so vollständig, wie sie sein sollte. Es sollte nicht lange dauern, bis Tools zum Erstellen von WSDL-Dateien und anschließendes Generieren von Proxys und Stubs ähnlich wie COM IDL-Tools Teil der meisten SOAP-Implementierungen sind. An diesem Punkt wird WSDL zur bevorzugten Methode zum Erstellen von SOAP-Schnittstellen für XML-Webdienste.
Eine hervorragende Beschreibung von WSDL ist verfügbar, und Die WSDL-Spezifikation finden Sie unter http://www.w3.org/TR/wsdl.
UDDI
Universal Discovery Description and Integration ist die gelbe Seite von Webdiensten. Wie bei herkömmlichen gelben Seiten können Sie nach einem Unternehmen suchen, das die benötigten Dienstleistungen anbietet, sich über den angebotenen Dienst informieren und sich an jemanden wenden, um weitere Informationen zu erhalten. Sie können natürlich einen Webdienst anbieten, ohne ihn bei UDDI zu registrieren, genauso wie Sie ein Unternehmen in Ihrem Keller eröffnen und sich auf Mundpropaganda verlassen können, aber wenn Sie einen bedeutenden Markt 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 dienste beschreibt, die es anbietet. Ein Eintrag im UDDI-Verzeichnis besteht aus drei Teilen. Die "weißen Seiten" beschreiben das Unternehmen, das den Dienst anbietet: Name, Adresse, Kontakte usw. Die "gelben Seiten" enthalten Industriekategorien, die auf Standardtaxonomien wie dem nordamerikanischen Industrieklassifizierungssystem und der Standard-Industrieklassifizierung basieren. Die "grünen Seiten" beschreiben die Schnittstelle zum Dienst so detailliert, dass jemand eine Anwendung schreiben kann, um den Webdienst zu verwenden. Die Art und Weise, wie Dienste definiert werden, erfolgt über ein UDDI-Dokument, das als Typmodell oder tModel bezeichnet wird. In vielen Fällen enthält das tModel eine WSDL-Datei, die eine SOAP-Schnittstelle zu einem XML-Webdienst beschreibt, aber das tModel ist flexibel genug, um fast jede Art von Dienst zu beschreiben.
Das UDDI-Verzeichnis enthält auch mehrere Möglichkeiten, um nach den Diensten zu suchen, die Sie zum Erstellen Ihrer Anwendungen benötigen. Sie können beispielsweise nach Anbietern eines Diensts an einem bestimmten geografischen Standort oder nach Unternehmen eines angegebenen Typs suchen. Das UDDI-Verzeichnis enthält dann Informationen, Kontakte, Links und technische Daten, damit Sie bewerten können, welche Dienste Ihren Anforderungen entsprechen.
Mit UDDI können Sie Unternehmen finden, von dem Sie möglicherweise Webdienste beziehen möchten. Was ist, wenn Sie bereits wissen, mit wem Sie Geschäfte machen möchten, aber nicht wissen, welche Dienstleistungen angeboten werden? Mit der WS-Inspection-Spezifikation können Sie eine Sammlung von XML-Webdiensten durchsuchen, die auf einem bestimmten Server angeboten werden, um zu ermitteln, welche Ihre Anforderungen erfüllen.
Weitere Informationen zu UDDI finden Sie unter http://www.uddi.org/about.html.
Was ist noch übrig?
Bisher haben wir über die Kommunikation mit XML-Webdiensten (SOAP), die Beschreibung von XML-Webdiensten (WSDL) und die Suche nach XML-Webdiensten (UDDI) gesprochen. Diese stellen eine Reihe von Basisspezifikationen dar, die die Grundlage für die Anwendungsintegration und -aggregation bilden. Anhand dieser Basisspezifikationen erstellen Unternehmen echte Lösungen und profitieren von ihnen.
Obwohl viel Arbeit geleistet wurde, um XML-Webdienste realitätsfern zu machen, ist mehr erforderlich. Heute haben die Menschen Erfolg mit XML-Webdiensten, aber es gibt immer noch Dinge, die als Übung für den Entwickler®verbleiben, z. B. Sicherheit, Betriebsverwaltung, Transaktionen, zuverlässiges Messaging. Die Globale XML-Webdienstarchitektur trägt dazu bei, XML-Webdienste auf die nächste Ebene zu bringen, indem sie ein kohärentes, universelles Modell zum Hinzufügen neuer erweiterter Funktionen zu XML-Webdiensten bereitstellt, die modular und erweiterbar sind.
WS-Security ist eine der Spezifikationen in der Global Web Services Architecture. Betriebsverwaltungsanforderungen wie das Weiterleiten von Nachrichten zwischen vielen Servern und die dynamische Konfiguration dieser Server für die Verarbeitung sind ebenfalls Teil der globalen Webdienstarchitektur und werden durch die WS-Routingspezifikation und die WS-Empfehlungsspezifikation erfüllt. Wenn die Globale Webdienstarchitektur wächst, werden Spezifikationen für diese und andere Anforderungen eingeführt.
Weitere Informationen finden Sie unter Globale XML-Webdienstarchitektur.