Webservice

Das World Wide Web Consortium definiert die Bereitstellung eines Webservices als Unterstützung zur Zusammenarbeit zwischen verschiedenen Anwendungsprogrammen, die auf unterschiedlichen Plattformen und/oder Frameworks betrieben werden. Ein Webservice oder Webdienst ist eine Software-Anwendung, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstelle als XML-Artefakt definiert, beschrieben und gefunden werden kann. Ein Webservice unterstützt die direkte Interaktion mit anderen Software-Agenten unter Verwendung XML-basierter Nachrichten durch den Austausch über internetbasierte Protokolle.

Architektur

Client-Programme senden im Allgemeinen Anfragen an einen Webservice, und dieser antwortet mit der gewünschten Information. Es wird daher gelegentlich behauptet, dass Webservices für Rechner das sind, was Webseiten für den Menschen sind. Auch wenn das nur einen Teil der Möglichkeiten der Webservices beschreibt, ist dieser Vergleich durchaus treffend. Webservices sind nicht für menschliche Benutzer gedacht, sondern für Softwaresysteme, die automatisiert Daten austauschen und/oder Funktionen auf entfernten 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 Konsument, Anbieter und Verzeichnis identifizieren.

Der Anbieter veröffentlicht in einem Verzeichnis die Beschreibung seiner Dienste. Der Konsument 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 Konsument 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 Finden des Webservices (z. B. den Dienst FußballErgebnisse) durch den Konsumenten. 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.

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).

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. Auch Amazon.com bietet seit 2002 auf seinen Portalseiten einen Webservice für verschiedene internetbezogene Dienstleistungen an, die Amazon Web Services.

Ein weiteres Beispiel ist die Interaktion 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.

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

Anwendungsmöglichkeiten

Webservices sind eine Technologie, die unter verschiedenen Aspekten verwendet werden kann. Hier die drei am weitesten verbreiteten:

• Remote Procedure Call (RPC) – Entfernter Funktionsaufruf: WSDL-basierend, die lose Kopplung ist nicht unbedingt gewährleistet
• SOAP – Eine Art Nachrichtendienst, WSDL als Kommunikationsinterface
• REST – Zustandsrepräsentationsübertragung – Der Versuch, 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.

Implementierung über WSDL → SOAP HTTP oder direkt auf SOAP basierend.

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.

Literatur

• Ingo Melzer, et al: Service-orientierte Architekturen mit Web Services. 3. Auflage. Spektrum, Heidelberg Mai 2008, ISBN 978-3-8274-1993-4 (Website zum Buch, abgerufen am 14. Juli 2009).
• Michael Kuschke, Ludger Wölfel: Web Services kompakt. Spektrum Akadademischer Verlag, Heidelberg, Berlin 2002, ISBN 3-8274-1375-3.
• Gustavo Alonso, F. Casati, H. Kuno: Web Services. Springer, Berlin 2003, ISBN 3-540-44008-9.
• 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.

Siehe auch

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

Weblinks

• Seiten des W3C über Web Services
• Definition des W3C über Web Services
• Deutsche Übersicht über alle Web Service Spezifikationen: http://www.ws-universe.com
• Implementation eines WebServices in Java Schritt-für-Schritt-Anleitung für die Implementation eines WebServices in Java (Sprache: deutsch)
• Web-Services im GI-Lexikon