Webservice

Ein Webservice (auch Webdienst) ermöglicht die Maschine-zu-Maschine-Kommunikation auf Basis von HTTP oder HTTPS über Rechnernetze wie das Internet. Dabei werden Daten ausgetauscht und auf entfernten Computern Funktionen aufgerufen. Jeder Webservice besitzt einen Uniform Resource Identifier (URI), über den er eindeutig identifizierbar ist, sowie eine Schnittstellenbeschreibung in maschinenlesbarem Format (als XML-Artefakt, z. B. WSDL), die definiert, wie mit dem Webservice zu interagieren ist. Die Kommunikation kann (muss aber nicht) über Protokolle aus dem Internetkontext wie HTTP laufen und kann XML oder JSON basiert sein.

Architektur

Client-Programme senden im Allgemeinen Anfragen an einen Webservice, und dieser antwortet mit der gewünschten Information. Webservices sind Bestandteil von Softwaresystemen, die automatisiert Daten austauschen oder Funktionen auf fernen Rechnern aufrufen.

Funktionsweise

Webservices orientieren sich an der serviceorientierten Architektur (SOA) und vereinen daher verteilte und objektorientierte Programmierstandards und richten sich auf betriebswirtschaftliche Lösungen im Internet.

Es lassen sich die Instanzen Nutzer (Servicekonsument), (Service-)Anbieter und Verzeichnis identifizieren.

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.

Die Grundlage hierbei bilden drei 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.
• WSDL zur Beschreibung der unterstützten Methoden (z. B. TorschuetzenKoenig) und deren Parametern (z. B. Datum) für den Programmierer.
• SOAP (oder XML-RPC) zur Kommunikation. Hier wird der eigentliche Aufruf gestartet.

Webservices bilden die drei wichtigsten Teile der Zusammenarbeit zwischen Client und Server ab: das Zusammenfinden, Binden und den Datenaustausch.

Erreichbar sind Webservices über einen eindeutigen URI. Die verwendeten plattformunabhängigen Standards sind in der Lage, entfernte Methodenaufrufe beliebiger Plattformen zu dekodieren und an eine Anwendung weiterzuleiten. 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 können auf verschiedene Arten implementiert werden. Am weitesten verbreitet sind dabei:

• Remote Procedure Call (RPC), über entfernte Funktionsaufrufe: WSDL-basierend, eine lose Kopplung ist nicht unbedingt gewährleistet
• SOAP als eine Art Nachrichtendienst, WSDL-basierend
• REST, Es wird versucht, das Interface auf eine Menge “definierter” Standard-Operationen (an HTTP angelehnt: GET, PUT, POST, DELETE) zu beschränken. Der Schwerpunkt liegt auf der Interaktion von zustandslosen Ressourcen.

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, jedoch können sie von Webanwendungen genutzt werden (die Webanwendung stellt zusätzlich eine Benutzerschnittstelle zur Eingabe oder Anzeige von Informationen für oder vom Webservice zur Verfügung).

Bewertung

Vorteile

• Die verwendeten offenen Standards vermeiden einige 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 eine Authentifizierung stattfinden kann. Ob hier HTTPS ausreichend ist oder Lösungen wie XML Signature, XML-Encryption oder SAML zu bevorzugen sind, sollte abgewogen werden.
• Ein besonderes Augenmerk liegt auf der Performance. Diese wird durch XML, Parsen und Dateigröße negativ beeinflusst. Der Verwaltungsaufwand nimmt bei stark verteilten Systemen zu. Der Overhead ist teilweise erheblich.
• 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 (B2B). 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.

Webservices können Daten und Funktionen für beliebige weitere Computersysteme, die sich lediglich in einem gemeinsamen Netzwerk befinden müssen, für deren Programme zur Verfügung stellen. So gibt es auch die Möglichkeit, die Rechtschreibprüfung in OpenOffice von einem Webservice der Universität Leipzig überprüfen zulassen.

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 Inc. betrieb ab 2002 einen Webservice, der durch seine Funktionalitäten die gleichen Möglichkeiten bot wie die Benutzerschnittstelle auf der Google-Webseite selbst. Programme konnten nun mit einem Ansprechen der Schnittstelle direkt nach Informationen im Internet suchen, erhielten über die Schnittstelle die Ergebnisdaten und konnten diese für ihre eigenen Aufgaben verwenden. Das Parsen der Google-Webseite war dazu keine auch nur annähernd gleichwertige Alternative. Allerdings stellte Google seit Dezember 2006 keine neuen Zugriffskennungen (API Keys) mehr dafür aus und hat Mitte 2009 den Service eingestellt.

Ein praktisches 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.

Siehe auch

• WS-* (modulare Erweiterungen zu SOAP/WSDL)

Literatur

• Ingo Melzer et al.: Service-orientierte Architekturen mit Web Services. 4. Auflage. Spektrum, Heidelberg 2010-04, ISBN 3-8274-2549-2 (Website zum Buch).
• Sanjiva Weerawarana, F. Curbera, F. Leymann: Web Services Platform Architecture. Prentice Hall PTR, Upper Saddle River/NJ 2005, ISBN 0-13-148874-0.
• Michael P. Papazoglou: Web Services: Principles and Technology. Prentice Hall, Essex 2007, ISBN 978-0-321-15555-9.

Weblinks

 Commons: Webservices – Sammlung von Bildern, Videos und Audiodateien

• Seiten des W3C über Web Services (englisch)
• Definition des Web Services beim W3C (englisch)
• Implementation eines WebServices in Java - Schritt-für-Schritt-Anleitung für die Implementation eines WebServices in Java
• Beschreibung von Web-Services im GI-Lexikon