XML-Webdienste sind die Grundbausteine für verteiltes Rechnen im Internet. Offene Standards und der Fokus auf Kommunikation und Zusammenarbeit zwischen Benutzern und Anwendungen haben eine Umgebung geschaffen, in der XML-Webdienste zur Plattform für die Anwendungsintegration werden. Anwendungen werden mithilfe von XML-Webdiensten aus mehreren verschiedenen Quellen erstellt, die unabhängig davon, wo sie sich befinden oder wie sie implementiert sind, zusammenarbeiten.
Es gibt so viele XML-Webdienstdefinitionen wie Unternehmen, die XML-Webdienste erstellen. Doch fast allen Definitionen ist folgendes gemeinsam:
XML-Webdienste bieten Webbenutzern über Standard-Webprotokolle nützliche Funktionen. In den meisten Fällen wird das SOAP-Protokoll verwendet.
XML-Webdienste können ihre Schnittstellen sehr detailliert spezifizieren, was es Benutzern ermöglicht, Clientanwendungen zu erstellen, um mit ihnen zu kommunizieren. Diese Beschreibung ist normalerweise in einem XML-Dokument enthalten, das als WSDL-Dokument (Web Services Description Language) bezeichnet wird.
XML-Webdienste werden registriert, damit potenzielle Benutzer sie leicht finden können, was durch Universal Discovery, Description and Integration (UDDI) erreicht wird.
In diesem Artikel werden diese drei Technologien vorgestellt. Zunächst müssen wir jedoch erklären, warum Sie XML-Webdiensten Aufmerksamkeit schenken sollten.
Einer der Hauptvorteile der XML-Webservices-Architektur besteht darin, dass sie einer Vielzahl von Programmen, die in verschiedenen Sprachen auf verschiedenen Plattformen geschrieben sind, ermöglicht, auf standardbasierte Weise miteinander zu kommunizieren. Benutzer, die etwas über diese Branche wissen, könnten sofort sagen: „Moment mal, haben CORBA und die vorherige DCE nicht die gleiche Verpflichtung eingegangen? Was ist der Unterschied zwischen dieser und ihnen?“ Der wichtigste Unterschied ist: SOAP ist besser als zuvor Der Ansatz ist viel einfacher, sodass es weitaus weniger Hürden bei der Implementierung von standardkonformem SOAP gibt. Paul Kulchenko stellt eine Liste der SOAP-Implementierungen unter http://www.soapware.org/directory/4/implementations (auf Englisch) bereit. Bei der letzten Zählung umfasste die Liste 79 Einträge. Wie zu erwarten ist, bieten die meisten großen Softwareunternehmen SOAP-Implementierungen an, es gibt jedoch auch viele Implementierungen, die von einzelnen Entwicklern erstellt und gepflegt werden. Ein weiterer großer Vorteil von XML-Webdiensten gegenüber früheren Lösungen ist die Verwendung von Standard-Webprotokollen – XML, HTTP und TCP/IP. Viele Unternehmen haben bereits eine Web-Infrastruktur aufgebaut und ihre Mitarbeiter verfügen über das Wissen und die Erfahrung, diese zu pflegen. Daher sind die Kosten für die Einführung von XML-Webdiensten viel geringer als für die Einführung früherer Technologien.
Wir definieren einen XML-Webdienst als einen Softwaredienst, der im Web über SOAP bereitgestellt, mithilfe einer WSDL-Datei beschrieben und über UDDI registriert wird. Sie fragen sich vielleicht: „Was können Sie mit XML-Webdiensten machen?“ Die ursprünglichen XML-Webdienste waren häufig Informationsquellen, die leicht in Anwendungen integriert werden konnten, beispielsweise Aktienkurse, Wettervorhersagen, Sportergebnisse usw. Es ist leicht, sich eine ganze Klasse von Anwendungen vorzustellen, die entwickelt werden könnten, um die Informationen, die Ihnen wichtig sind, zu analysieren und zusammenzufassen und diese Informationen auf verschiedene Arten verfügbar zu machen. Sie könnten beispielsweise eine Microsoft® Excel-Tabelle verwenden, um alle Ihre Finanzen zusammenzufassen Informationen – Aktien, 401K, Bankeinlagen, Kredite usw. Wenn diese Informationen über XML-Webdienste verfügbar sind, kann Excel sie kontinuierlich aktualisieren. Einige dieser Informationen sind kostenlos, andere erfordern möglicherweise ein Abonnement, um den entsprechenden Dienst zu erhalten. Viele dieser Informationen sind bereits im Web verfügbar, aber XML-Webdienste können den programmgesteuerten Zugriff einfacher und zuverlässiger machen.
Bestehende Anwendungen werden als XML-Webdienste zur Verfügung gestellt, und neue, leistungsfähigere Anwendungen können mithilfe von XML-Webdiensten als Bausteinen erstellt werden. Beispielsweise kann ein Benutzer eine Einkaufsanwendung entwickeln, um automatisch Preisinformationen von verschiedenen Lieferanten zu erhalten, sodass der Benutzer einen Lieferanten auswählen, eine Bestellung aufgeben und dann den Warenversand bis zum Wareneingang verfolgen kann. Neben der Bereitstellung von Diensten im Web kann die Anwendung des Lieferanten auch den XML-Webdienst nutzen, um die Kreditwürdigkeit von Kunden zu prüfen, Zahlungen einzuziehen und Frachtvorgänge mit Frachtunternehmen abzuwickeln.
In Zukunft werden einige der interessantesten auf XML-Webdiensten basierenden Anwendungen das Web nutzen können, um Aufgaben zu erledigen, die derzeit unmöglich sind. Beispielsweise ist der Kalenderdienst einer der Dienste, die vom Microsoft .NET My Services (Englisch)-Projekt unterstützt werden. Wenn Ihre Zahnärzte und Mechaniker ihre Termine über diesen XML-Webdienst bereitstellen, können Sie bei Bedarf Termine mit ihnen über das Internet vereinbaren. Außerdem können sie Reinigungs- und Wartungstermine direkt in Ihrem Kalender eintragen. Man kann sich leicht vorstellen, dass man Hunderte von Anwendungen erstellen könnte, wenn man das Web programmieren könnte.
Weitere Informationen zu XML-Webdiensten und den Anwendungen, die Sie erstellen können, finden Sie auf der Homepage von MSDN Web Services (Englisch).
SOAP
SOAP ist das Kommunikationsprotokoll des XML-Webdienstes. Bei der Beschreibung von SOAP als Kommunikationsprotokoll denken die meisten Menschen an DCOM oder CORBA und stellen Fragen wie „Wie aktiviert SOAP Objekte?“ oder „Welchen Namensdienst verwendet SOAP?“ Obwohl SOAP-Implementierungen diese Elemente enthalten können, sind sie im SOAP-Standard nicht spezifiziert. SOAP Eine Spezifikation, die das XML-Format von Nachrichten definiert – dies ist ein erforderlicher Teil der Spezifikation. Ein wohlgeformtes XML-Segment, das in einem Paar von SOAP-Elementen enthalten ist, ist eine SOAP-Nachricht. Ist das nicht einfach?
Andere Teile der SOAP-Spezifikation beschreiben, wie Programmdaten als XML dargestellt werden und wie SOAP für Remote Procedure Calls (RPC) verwendet wird. Diese optionalen Teile der Spezifikation werden verwendet, um Anwendungen im RPC-Stil zu implementieren, bei denen der Client eine SOAP-Nachricht ausgibt (die eine aufrufbare Funktion und die an die Funktion zu übergebenden Parameter enthält) und der Server eine Nachricht mit den Ergebnissen zurückgibt der Funktionsausführung. Derzeit unterstützen die meisten SOAP-Implementierungen RPC-Anwendungen, da Programmierer, die mit der Entwicklung von COM- oder CORBA-Anwendungen vertraut sind, mit dem RPC-Format vertraut sind. SOAP unterstützt auch Anwendungen im Dokumentstil, bei denen eine SOAP-Nachricht nur ein Wrapper um ein XML-Dokument ist. Dokumentbasierte SOAP-Anwendungen sind sehr flexibel und viele neue XML-Webdienste nutzen diese Funktion, um Dienste zu erstellen, die mit RPC nur schwer zu implementieren sind.
Der letzte optionale Teil der SOAP-Spezifikation definiert den Stil von HTTP-Nachrichten, die SOAP-Nachrichten enthalten. Diese HTTP-Bindung ist wichtig, da fast alle aktuellen Betriebssysteme (und viele frühere Betriebssysteme) HTTP unterstützen. Obwohl optional, wird die HTTP-Bindung von fast allen SOAP-Implementierungen unterstützt, da es das einzige Standardprotokoll für SOAP ist. Aus diesem Grund wird oft fälschlicherweise angenommen, dass SOAP HTTP verwenden muss. Tatsächlich unterstützen einige Implementierungen auch MSMQ, MQ Series, SMTP oder TCP/IP-Transport, aber weil HTTP so allgegenwärtig ist, verwenden es fast alle aktuellen XML-Webdienste. Da HTTP das Kernprotokoll des Webs ist, unterstützt die Netzwerkinfrastruktur der meisten Unternehmen HTTP und die Mitarbeiter wissen bereits, wie sie es verwalten. Heute ist die Infrastruktur für HTTP-Sicherheit, Überwachung und Lastausgleich eingerichtet.
Wenn man mit der Verwendung von SOAP beginnt, ist der Unterschied zwischen der SOAP-Spezifikation und ihren vielen Implementierungen das Verwirrendste. Die meisten SOAP-Benutzer schreiben SOAP-Nachrichten nicht direkt, sondern verwenden SOAP-Toolkits, um SOAP-Nachrichten zu erstellen und zu analysieren. Diese Toolkits konvertieren normalerweise Funktionsaufrufe aus einer Sprache in SOAP-Nachrichten. Beispielsweise konvertiert das Microsoft SOAP Toolkit 2.0 COM-Funktionsaufrufe in SOAP und das Apache Toolkit konvertiert JAVA-Funktionsaufrufe in SOAP. Die Arten von Funktionsaufrufen und unterstützten Parameterdatentypen variieren je nach SOAP-Implementierung, sodass eine Funktion, die für ein Toolkit funktioniert, möglicherweise nicht für ein anderes funktioniert. Hierbei handelt es sich nicht um eine Einschränkung von SOAP, sondern um die spezifische verwendete Implementierung.
Das mit Abstand überzeugendste Merkmal von SOAP ist, dass es auf vielen verschiedenen Software- und Hardwareplattformen implementiert werden kann. Das bedeutet, dass SOAP verwendet werden kann, um unterschiedliche Systeme innerhalb und außerhalb des Unternehmens zu verknüpfen. In der Vergangenheit wurden verschiedene Ansätze ausprobiert, um ein gemeinsames Kommunikationsprotokoll zu entwickeln, das für die Systemintegration verwendet werden könnte, aber keiner von ihnen hat die breite Akzeptanz gefunden, die SOAP hat. Warum? Weil SOAP kleiner und einfacher zu implementieren ist als viele frühere Protokolle. Beispielsweise dauerte die Implementierung von DCE und CORBA Jahre, sodass nur wenige Implementierungen veröffentlicht wurden. SOAP kann vorhandene XML-Parser und HTTP-Bibliotheken nutzen, um den Großteil der harten Arbeit zu erledigen, sodass eine SOAP-Implementierung in wenigen Monaten abgeschlossen sein kann. Deshalb gibt es mittlerweile über 70 SOAP-Implementierungen. Natürlich verfügt SOAP nicht über alle Funktionen von DCE oder CORBA. Obwohl die Funktionen reduziert sind, ist SOAP einfacher anzuwenden, da seine Komplexität stark reduziert ist.
Die Beliebtheit von HTTP und die Einfachheit von SOAP ermöglichen den Aufruf aus nahezu jeder Umgebung, was sie zu einer idealen Grundlage für XML-Webdienste macht. Weitere Informationen zu SOAP finden Sie auf der Homepage von MSDN SOAP (Englisch).
Wie sicher ist es?
Die erste Frage, die SOAP-Neulinge stellen, ist oft, wie SOAP Sicherheitsprobleme löst. In seinen frühen Entwicklungsstadien wurde SOAP als ein auf HTTP basierendes Protokoll angesehen, sodass die Sicherheit von HTTP für SOAP als ausreichend angesehen wurde. Schließlich verwenden derzeit Tausende von Webanwendungen HTTP-Sicherheit, sodass dies für SOAP tatsächlich ausreichend ist. Daher geht der aktuelle SOAP-Standard davon aus, dass Sicherheit ein Transportproblem ist und nicht als Sicherheitsproblem behandelt wird.
Da sich SOAP zu einem allgemeineren Protokoll ausdehnt und auf zahlreichen Transportmitteln läuft, treten Sicherheitsprobleme immer stärker in den Vordergrund. HTTP bietet beispielsweise mehrere Möglichkeiten zur Authentifizierung von Benutzern, die SOAP-Aufrufe tätigen. Doch wie verbreitet sich diese Identität, wenn Nachrichten vom HTTP- zum SMTP-Transport weitergeleitet werden? SOAP wurde als Bausteinprotokoll konzipiert, daher gibt es glücklicherweise Spezifikationen, um zusätzliche Sicherheitsfunktionen für Webdienste auf Basis von SOAP bereitzustellen. Die WS-Security-Spezifikation (Englisch) definiert ein vollständiges Verschlüsselungssystem und die WS-License-Spezifikation (Englisch) definiert die entsprechende Technologie, um die Identität des Anrufers sicherzustellen und sicherzustellen, dass nur autorisierte Benutzer Webdienste nutzen können.
WSDL
WSDL (Web Services Description Language) steht für Web Services Description Language. Für die Zwecke dieses Artikels können wir uns eine WSDL-Datei als ein XML-Dokument vorstellen, das eine Reihe von SOAP-Nachrichten und deren Austausch beschreibt. Mit anderen Worten: WSDL ist für SOAP das, was IDL für CORBA oder COM ist. Da es sich bei WSDL um ein XML-Dokument handelt, ist es leicht zu lesen und zu bearbeiten. In den meisten Fällen wird es jedoch von Software generiert und verwendet.
Um die Werte der WSDL anzuzeigen, stellen Sie sich vor, Sie möchten eine SOAP-Methode aufrufen, die von einem Ihrer Geschäftspartner bereitgestellt wird. Sie könnten einige Beispiel-SOAP-Nachrichten anfordern und dann Ihre Anwendung schreiben, um Nachrichten zu generieren und zu verwenden, die den Beispielen ähneln, aber dabei kann es leicht zu Fehlern kommen. Beispielsweise sehen Sie möglicherweise die Kunden-ID 2837 und gehen davon aus, dass es sich um eine Ganzzahl handelt, obwohl es sich tatsächlich um eine Zeichenfolge handelt. WSDL gibt durch eine explizite Notation an, was die Anforderungsnachricht enthalten muss und wie die Antwortnachricht aussehen soll.
Die von WSDL-Dateien zur Beschreibung von Nachrichtenformaten verwendete Notation basiert auf dem XML-Schema-Standard, was bedeutet, dass sie programmiersprachenunabhängig und standardbasiert ist und sich daher für die Beschreibung von XML-Webdiensten eignet, auf die von verschiedenen Plattformen und in unterschiedlicher Programmierung zugegriffen werden kann Sprachen. Schnittstelle. WSDL beschreibt nicht nur den Inhalt der Nachricht, sondern definiert auch den Standort des Dienstes und welches Kommunikationsprotokoll für die Kommunikation mit dem Dienst verwendet wird. Das heißt, die WSDL-Datei definiert alles, was zum Schreiben eines Programms erforderlich ist, das XML-Webdienste verwendet. Es gibt mehrere Tools, die WSDL-Dateien lesen und den für die Kommunikation mit XML-Webdiensten erforderlichen Code generieren können. Einige der leistungsstärksten Tools finden Sie in Microsoft Visual Studio® .NET.
Derzeit enthalten viele SOAP-Toolkits Tools zum Generieren von WSDL-Dateien aus vorhandenen Programmschnittstellen, es gibt jedoch nur wenige Tools zum direkten Schreiben von WSDL und die Toolunterstützung für WSDL ist unvollständig. Aber bald wird es Tools zum Schreiben von WSDL-Dateien geben, gefolgt von Tools zum Generieren von Proxys und Stubs (ähnlich wie COM IDL-Tools), und diese Tools werden Teil der meisten SOAP-Implementierungen sein. Bis dahin wird WSDL die bevorzugte Methode zum Erstellen von SOAP-Schnittstellen zu XML-Webdiensten sein.
Eine sehr gute Beschreibung von WSDL gibt es hier (auf Englisch), und Sie können die WSDL-Spezifikation auch unter http://www.w3.org/TR/wsdl (auf Englisch) finden.
UDDI
Universal Discovery, Description, and Integration (UDDI) sind die Gelben Seiten der Webdienste. Wie in den herkömmlichen Gelben Seiten können Sie nach Unternehmen suchen, die die von Ihnen benötigten Dienste anbieten, diese lesen, um mehr über die angebotenen Dienste zu erfahren, und dann jemanden kontaktieren, um weitere Informationen zu erhalten. Natürlich können Sie Webdienste anbieten, ohne sie in UDDI zu registrieren, was so ist, als würden Sie ein Unternehmen in Ihrem Keller führen und sich auf Mundpropaganda verlassen. Wenn Sie jedoch Ihren Markt erweitern möchten, benötigen Sie UDDI, damit Sie von Ihren Kunden entdeckt werden können Kunden.
UDDI-Verzeichniseinträge sind XML-Dateien, die die bereitgestellten Dienste und Dienste beschreiben. Ein UDDI-Verzeichniseintrag besteht aus drei Teilen. „Weiße Seiten“ stellen Unternehmen vor, die Dienstleistungen anbieten: Name, Adresse, Kontaktinformationen usw.; „Gelbe Seiten“ enthalten Branchenkategorien, die auf Standardklassifizierungen basieren (wie z. B. North American Industry Classification System und Standard Industrial Classification); Informationen Greifen Sie auf die Schnittstelle zum Dienst zu, sodass Benutzer Anwendungen schreiben können, um den Webdienst zu nutzen. Die Definition eines Dienstes erfolgt über ein UDDI-Dokument, das als Typmodell (oder tModel) bezeichnet wird. In den meisten Fällen enthält das tModel eine WSDL-Datei, die die SOAP-Schnittstelle für den Zugriff auf den XML-Webdienst beschreibt, aber das tModel ist sehr flexibel und kann nahezu jede Art von Dienst beschreiben.
Das UDDI-Verzeichnis enthält außerdem mehrere Methoden zum Suchen nach den Diensten, die zum Erstellen Ihrer Anwendung erforderlich sind. Sie können beispielsweise nach Dienstleistern an einem bestimmten geografischen Standort oder nach einer bestimmten Unternehmensart suchen. Das UDDI-Verzeichnis stellt dann Informationen, Kontaktdaten, Links und technische Daten bereit, damit Sie die Dienste identifizieren können, die Ihren Anforderungen entsprechen.
Mit UDDI können Sie Unternehmen finden, die die von Ihnen benötigten Webdienste anbieten. Was tun Sie, wenn Sie bereits wissen, mit wem Sie Geschäfte machen möchten, aber noch nicht wissen, was es sonst noch zu bieten hat? Mit der WS-Inspection-Spezifikation (auf Englisch) können Sie die Sammlung der auf einem bestimmten Server verfügbaren XML-Webdienste durchsuchen, um den benötigten Dienst zu finden.
Weitere Informationen zu UDDI finden Sie unter http://www.uddi.org/about.html (auf Englisch).
Andere Inhalte
Bisher haben wir besprochen, wie man mit XML-Webdiensten (SOAP) kommuniziert, wie XML-Webdienste beschrieben werden (WSDL) und wie man XML-Webdienste findet (UDDI). Diese bilden einen grundlegenden Satz von Spezifikationen, die die Grundlage für die Anwendungsintegration und -aggregation bilden. Auf Basis dieser Grundvorgaben können Unternehmen praxistaugliche Lösungen aufbauen und davon profitieren.
Wir haben viel Arbeit in die Implementierung von XML-Webdiensten gesteckt, aber es gibt noch viel zu tun. Heutzutage haben Menschen mit XML-Webdiensten Erfolge erzielt, aber für Entwickler gibt es noch viele Links zu verbessern. Zum Beispiel Sicherheit, Betriebsmanagement, Transaktionsverarbeitung und zuverlässige Nachrichtenübermittlung. Die globale XML-Webservices-Architektur wird XML-Webservices dabei helfen, in die nächste Entwicklungsstufe einzutreten, indem sie ein konsistentes, gemeinsames Modell für das modulare und erweiterbare Hinzufügen neuer erweiterter Funktionen zu XML-Webservices bereitstellt.
Die oben genannten Sicherheitsmodule (WS-Security [Englisch] und WS-License [Englisch]) sind Teil der Global Web Services Architecture-Spezifikation. Betriebsverwaltungsanforderungen (z. B. das Weiterleiten von Nachrichten zwischen mehreren Servern und die dynamische Konfiguration dieser Server für die Verarbeitung) sind ebenfalls Teil der Global Web Services Architecture, die durch die WS-Routing-Spezifikation (Englisch) und die WS-Referral-Spezifikation (Englisch) zu erreichen sind. Im Zuge der Weiterentwicklung der Global Web Services Architecture werden Spezifikationen eingeführt, die diese und andere Anforderungen berücksichtigen.