Webservice
Ein Webservice (auch Webdienst) stellt eine Schnittstelle für die Maschine-zu-Maschine- oder Anwendungs-Kommunikation über Rechnernetze wie das Internet zur Verfügung.[1] Dabei werden Daten ausgetauscht und auf entfernten Computern (Servern) Funktionen aufgerufen. Jeder Webservice besitzt einen Uniform Resource Identifier (URI), über den er eindeutig identifizierbar ist. Außerdem enthält ein Webservice, je nach Implementierung, eine Schnittstellenbeschreibung in maschinenlesbarem Format, die definiert, wie mit dem Webservice zu interagieren ist, z. B. WSDL im XML-Format. Die Kommunikation kann über Protokolle aus dem Internetkontext wie beispielsweise HTTP oder HTTPS erfolgen. Über diese Protokolle können Daten beispielsweise im XML- oder JSON-Format übertragen werden.[2][3] Ein Webservice ist plattformunabhängig und steht in der Regel mehreren Programmen zum Aufrufen bereit.[4]
Architektur
Im Allgemeinen senden Programme Anfragen an einen Webservice, woraufhin dort anfragespezifische Funktionen – wie Rückgabe oder Änderung gespeicherter Informationen – ausgelöst werden. Typischerweise wird der Webservice auf einem anderen Rechner (Server) ausgeführt als das Programm, welches damit von einem Client aus interagiert. Beispielsweise kann von einem Programm, welches hauptsächlich aus einer Benutzeroberfläche besteht, eine Anfrage nach Kartenmaterial für einen bestimmten Ausschnitt an einen Webservice gestellt werden. Als Antwort auf die Anfrage bekommt das Programm den angefragten Kartenausschnitt und präsentiert diesen auf der Benutzeroberfläche. Webservices können aber auch Bestandteile von Softwaresystemen, die automatisiert Daten austauschen oder Funktionen auf entfernten Computern aufrufen, sein.
Webservices orientieren sich an der serviceorientierten Architektur (SOA) und vereinen daher verteilte und objektorientierte Programmierstandards und richten sich auf betriebswirtschaftliche Lösungen im Internet.
Allgemein kann unterschieden werden zwischen Nutzer (Servicekonsument), (Service-)Anbieter und Verzeichnis. Diese interagieren wie folgt: Der Anbieter veröffentlicht in einem Verzeichnis die Beschreibung seiner Dienste. Der Nutzer durchsucht das Verzeichnis und wählt den gewünschten Dienst aus. Nachdem eventuell weitere Protokolldetails ausgetauscht wurden, findet die dynamische Anbindung des Konsumenten an den Anbieter statt. Der Nutzer greift nun auf die Methoden der Webservices dieses Anbieters zurück.
Erreichbar sind Webservices über einen eindeutigen URI. Aufgrund der verwendeten plattformunabhängigen Standards ist es möglich, entfernte Methodenaufrufe beliebiger Plattformen zu dekodieren und an eine Anwendung weiterzuleiten. Dabei wird implizit das Entwurfsmuster Fassade umgesetzt: der Client muss praktisch keine Implementierungsdetails des Webservice kennen, um ihn zu nutzen.[5] Auf diese Weise entsteht eine verteilte Architektur. Die Kommunikation mit Webservices erfolgt über Nachrichten, die über unterschiedliche Protokolle transportiert werden können.
Implementierungsmöglichkeiten
Webservices basieren selbst auf Standardprotokollen, mit denen die Informationen und Befehle übertragen werden. Sie können auf grundsätzlich verschiedene Arten implementiert werden, beispielsweise:[6]
- Remote Procedure Calls (RPC), über entfernte Funktionsaufrufe als Abfrageprotokoll
- SOAP als Netzwerkprotokoll, welches XML für die Übertragung von Daten über ein im Prinzip beliebiges Transportprotokoll verwendet.
- REST als Programmierparadigma stützt sich auf die Interaktion von zustandslosen Ressourcen. Dabei werden Operationen, wie sie im verwendeten Netzwerkprotokoll standardisiert sind – bei HTTP wären dies GET, POST, PUT, DELETE – verwendet. Beispielsweise wird mittels GET eine Ressource (wie eine Reservierung) abgefragt, mittels PUT wird eine neue angelegt oder (sofern bereits vorhanden) geändert.
- WebDAV für die Bereitstellung von Dateien
Grundlage für einige Implementierungen von Webservices bilden Standards, die jeweils auf XML basieren und in den zugehörigen Artikeln näher beschrieben werden:
- UDDI als Verzeichnisdienst zur Registrierung von Webservices. Es ermöglicht das dynamische Auffinden des Webservices (z. B. den Dienst FußballErgebnisse) durch den Nutzer. Allerdings wird UDDI nur in eher kleineren Firmennetzwerken verwendet und hat sich nie global durchgesetzt.[7]
- WSDL zur Beschreibung der unterstützten Methoden (z. B. TorschuetzenKoenig) und deren Parametern (z. B. Datum) für den Programmierer.
Abgrenzung
- Webservices sind nicht gleichzusetzen mit Enterprise Application Integration, jedoch können sie bei einer Enterprise Application Integration Verwendung finden.
- Webservices sind nicht gleichzusetzen mit Webanwendungen, sie können jedoch von Webanwendungen genutzt werden. Ein Webservice wird von einem Rechner oder einem Programm aufgerufen, eine Webanwendung hingegen wird über ihre Benutzerschnittstelle von einem Menschen genutzt.[5] Ein Webservice kann außerdem in verschiedenen Webanwendungen genutzt werden.
Bewertung
Vorteile
- Die verwendeten offenen Standards vermeiden Lizenzkosten. Da zu diesen Standards auch die allgegenwärtigen internetbasierten Technologien gehören, lassen sie sich auch vielerorts einsetzen. Auch hier liegt ein Kostenvorteil.
- Webservices können faktisch auf jedes Übertragungsprotokoll aufsetzen. Bei einer hohen Anzahl von verschiedenen Nutzern im Internet wird üblicherweise HTTP zur Datenübertragung verwendet, da nur selten Probleme mit Firewalls auftreten. Dies ist ein Vorteil gegenüber vergleichbaren Technologien wie CORBA, DCOM oder auch Java RMI. Webservices sind wie beschrieben nicht an HTTP gebunden und lassen sich auch mit anderen Protokollen wie SMTP – zum Beispiel für asynchrone Übertragung – oder FTP – zum Beispiel bei sehr großen Nachrichten – übertragen und sind somit offen für verschiedene Anwendungsszenarien geeignet.
- Durch die Verwendung von bereits bestehenden und weit verbreiteten Internet-Standards (HTTP, XML etc.) entsteht eine offene und flexible Architektur, die unabhängig von den verwendeten Plattformen, Programmiersprachen und Protokollen ist. So können beispielsweise Windows-C#-Clients hinter einer Firewall mit Java-Servern, die auf Linux implementiert sind, kommunizieren. Die weit verbreiteten Standard-Protokolle ermöglichen eine Interoperabilität über jegliche Heterogenitäten im Internet hinweg.
- Die Barrieren zum Einstieg sind vergleichsweise niedrig.
Nachteile
- Die Hauptschwierigkeiten bei der Umsetzung von Webservices dürften Sicherheitsaspekte betreffen. So ist beim Transport zu beachten, dass wichtige Webservices verschlüsselt werden oder dass eine Authentifizierung verlangt wird. Ob hier HTTPS ausreichend ist oder Lösungen wie XML Signature, XML-Encryption oder SAML zu verwenden sind, sollte je nach Anwendungsfall abgewogen werden.
- Ein besonderes Augenmerk liegt auf der Performance, welche durch einen zu hohen Overhead negativ beeinflusst wird.[4] Der Verwaltungsaufwand nimmt bei stark verteilten Systemen zu.
- Es ist mehr Know-how erforderlich als z. B. für Remote Procedure Call (RPC). Programmiersprachen, mit denen man Webservices einbinden will, brauchen spezielle Bibliotheken (z. B. für das Document Object Model).
Anwendungsgebiete
Webservices stellen neue Ansätze im Rahmen von Enterprise Application Integration (EAI) und Grid-Computing dar. Das geplante Haupteinsatzgebiet liegt im Business-to-Business-Bereich. Geschäftsprozesse sollen problemlos über Unternehmensgrenzen hinweg abgewickelt werden. Eine Sprache hierfür ist WS-Business Process Execution Language (BPEL), die es erlaubt, zu orchestrieren.
Eine weitere Anwendung stellen die vom Open Geospatial Consortium standardisierten Geodienste dar, welche als raumbezogene Webservices Geodaten in strukturierter Form zugänglich machen.
Die Mächtigkeit dieses Konzeptes besteht in der Möglichkeit, vorhandene Systeme und Dienste miteinander plattformübergreifend zu kombinieren und diese in den eigenen Anwendungen und Diensten zur Verfügung zu stellen.
Beispiele
Google betreibt für seine Webanwendung und für die Nutzung in anderen Anwendungen sehr viele Webservices. Darüber kann man beispielsweise Computing-Services oder Datenanalyse auf Basis von maschinellem Lernen, die Google bereitstellt, nutzen. Alle APIs bieten eine HTTP-Schnittstelle mit JSON als Protokoll an. Für einige APIs steht zusätzlich eine gRPC-Schnittstelle zur Verfügung. Zur Nutzung benötigt man eine Zugriffskennung (API Key), um auf die teilweise kostenpflichtigen Webservices zugreifen zu können.[8] Google selbst überwacht die Nutzung und vergibt für die Nutzung jeweils bestimmte Kontingente. Damit soll Missbrauch vermeiden werden und die Verfügbarkeit der Webservices gewährleistet werden.[9] Die Google-Services werden in vielen der eigenen Anwendungen verwendet, wie beispielsweise Google Maps oder Google Fotos.
Ein weiteres Beispiel ist ein Computerreservierungssystem zwischen Fluggesellschaften und Reisebüros. Die Fluggesellschaften stellen Möglichkeiten zum Nachschlagen oder Buchen von Flügen über einen Webservice bereit. Die Reisebüros bieten auf ihrer Webpräsenz Flüge verschiedener Fluggesellschaften an, von denen die Reisebüros zur Laufzeit über UDDI erfahren. Der Kunde kann auf der Webpräsenz des Reisebüros nun zentral Preise und Termine verschiedener Flüge vergleichen und gleich buchen.
Erweiterungen
Mit dem Web Services Composite Application Framework (WS-CAF) wurde eine weiterführende Spezifikation beim W3C und bei OASIS zur Standardisierung eingereicht, die Webservices um für die Koordination von Applikationen nützliche Standards, wie z. B. Transaktionsmanagement, erweitern sollen. Über weitere, proprietäre Erweiterungen wird bei verschiedenen Herstellern nachgedacht. Um Problemen der Sicherheit zu begegnen, werden Konzepte auf der Grundlage der Security Assertion Markup Language (SAML) entwickelt.
Des Weiteren befasst sich das Gebiet der Semantic Web Services mit der Erweiterung von Webservices um Semantik, die das Auffinden (Discovery), Auswählen (Selection), Ausführen (Invocation) und die Komposition mit anderen Webservices nach der Idee des Semantic Web ermöglichen und vereinfachen soll.
Testmöglichkeiten
Die nachfolgende Aufzählung listet Programme, die für den Softwaretest von Webservices (bzw. deren Programmierschnittstellen) genutzt werden:
- SoapUI
- Postman
- Apache JMeter
- Katalon Studio
Literatur
- Ingo Melzer et al.: Service-orientierte Architekturen mit Web Services. 4. Auflage. Spektrum, Heidelberg 2010, ISBN 3-8274-2549-2.
- Sanjiva Weerawarana, F. Curbera, F. Leymann: Web Services Platform Architecture. Prentice Hall PTR, Upper Saddle River/NJ 2005, ISBN 0-13-148874-0 (englisch).
- Michael P. Papazoglou: Web Services: Principles and Technology. Prentice Hall, Essex 2007, ISBN 978-0-321-15555-9 (englisch).
Weblinks
- Seiten des W3C über Web Services (englisch)
Einzelnachweise
- Web Services Architecture. World Wide Web Consortium, 11. Februar 2004, abgerufen am 27. Januar 2021.
- Web Services Glossary. Abgerufen am 27. Januar 2020.
- Geoff Bender: XML vs JSON Based Web Services: Which is the Best Choice? 29. März 2013, abgerufen am 27. Januar 2021.
- Webservices: Dienste von Maschine zu Maschine. Abgerufen am 27. Januar 2020.
- Webservcie. DATACOM Buchverlag GmbH, abgerufen am 30. Januar 2021.
- Ressourcenorientierte Webservices auf Basis von REST. 15. Mai 2020, abgerufen am 23. September 2020.
- Webservices: Dienste von Maschine zu Maschine. 1&1 Ionos, 2. März 2020, abgerufen am 30. Januar 2021.
- API-Nutzung deckeln. Google, 19. Januar 2021, abgerufen am 30. Januar 2021.
- Google Cloud APIs. Google, 12. Januar 2021, abgerufen am 30. Januar 2021.