Webservices – eine kurze Einführung

Das Projekt ZHistLex soll demonstrieren, wie digital vorliegende lexikalische Ressourcen, Bibliographien und Quellentexte historischer Sprachstadien des Deutschen gemeinsam und übergreifend verknüpft, durchsucht und dargestellt werden können. Um dieses Ziel zu erreichen, müssen zum einen die Daten selbst, aber auch die Zugriffsweisen auf diese Daten so interoperabel wie möglich gestaltet werden.

Die Interoperabilität auf der Datenebene wird prinzipiell durch Formatstandardisierungen erreicht. Auf diesem Gebiet gibt es seit vielen Jahren zum Teil umfangreiche Aktivitäten. Einen Überblick über die Grundprinzipien der technischen Modellierung lexikografischer Daten sowie über wichtige Formate, die hierfür verwendet werden, geben zum Beispiel Herold/Meyer/Müller-Spitzer (2016).

Die Verknüpfung und vor allem das Durchsuchen der Ressourcen erfolgt in ZHistLex dezentral mit Hilfe von Webservices. Jede einzelne Ressource wird von einem eigenen Webservice repräsentiert.

Was ist ein Webservice?

Ein Webservice ist ein Dienst, mit dem „Nutzer“ über ein Netzwerk kommunizieren. Die „Nutzer“ sind selbst wiederum Computerprogramme. Bei diesem Kommunikationsvorgang agiert der Rechner, auf dem der Webservice angeboten wird als Server; der nutzende Rechner als Client. Typischerweise antworten Webservices auf Client-Anfragen oder führen vom Client übermittelte Anweisungen aus. Menschen nutzen Webservices in der Regel nur indirekt – im einfachsten Fall zum Beispiel mit Hilfe eines Webbrowsers oder durch spezialisierte Client-Programme. Im Kern stellen Webservices eine Variante der Maschine-Maschine-Kommunikation im Client-Server-Modell dar. Beide Seiten kommunizieren dabei mit Hilfe von Nachrichten.

Um eine geordnete und eindeutige Kommunikation zwischen Client und Server zu erreichen, folgt die Kommunikation einer Reihe von Protokollen. Diese Protokolle bauen schichtweise aufeinander auf. Die verbreitetste Protokollfamilie ist die TCP/IP-Protokollfamilie, die auch in ZHistLex verwendet wird. Die TCP/IP-Protokollfamilie unterscheidet vier Kommunikationsschichten:

1. die Netzzugangsschicht (elektrische Verbindung, Bitübertragung; beispielsweise Ethernet)
2. die Internet-Schicht (Adressierung und Vermittlung; beispielsweise IPv4 und IPv6)
3. die Transportschicht (Paketierung, Datenstromkontrolle; beispielsweise TCP)
4. die Anwendungsschicht (Anwendungen; beispielsweise E-Mail, WWW, Videokonferenzsysteme)

Die vier Schichten bauen direkt aufeinander auf und sind jeweils Abstraktionen über ihre Vorgängerschichten. Die folgende Darstellung konzentriert sich auf die Anwendungsschicht, in der die ZHistLex-eigene Entwicklung stattfindet. Die übrigen Schichten werden nur am Rande berührt. So werden beispielsweise IP-Adressen (bzw. kanonische Namen) aus der Internet-Schicht für die Adressierung von Rechnern verwendet. Eine ausführlichere Übersicht über die TCP/IP-basierte Rechnerkommunikation auf dem Gebiet der Internetlexikografie bieten Meyer/Herold/Lemnitzer (2016).

Innerhalb der Anwendungsschicht folgt die Kommunikation ebenfalls festgelegten Protokollen, das heißt die Nachrichten, die von Client und Server ausgetauscht werden, haben eine strikt festgelegte Struktur und Bedeutung. Dadurch wird die Eindeutigkeit der Kommunikation sichergestellt.

Neben den direkten Kommunikationspartnern Client und Server können in manchen Szenarien Verzeichnisdienste auftreten, die das Suchen und Auswählen von gelisteten Webservices ermöglichen. Solche Verzeichnisdienste werden typischerweise in komplexeren Systemen mit einer großen Zahl von Webservices verwendet. Das ist bei ZHistLex nicht der Fall. Daher wird auf diesen Aspekt ebenfalls nicht detailliert eingegangen.

Da auf einem Server gleichzeitig verschiedene Webservices angeboten werden können – zum Beispiel verschiedene Wörterbücher oder verschiedene Versionen eines Wörterbuchs –, können Webservices nicht durch eine bloße Angabe eines Rechnernamens bzw. einer IP-Adresse angesprochen werden. Vielmehr muss eine vollständige Pfadangabe verwendet werden, sodass sich ein URI (uniform resource identifier) ergibt, beispielsweise:

https://server.name/woerterbuch1

Ein solcher URI wird auch als Endpoint-Adresse oder verkürzt als Endpoint bezeichnet. Über die Endpointadresse können alle Funktionen oder Teilressourcen des Webservices addressiert werden. Wie die Adressierung genau erfolgt, ist abhängig von den verwendeten Protokollen. Eine oft genutzte Variante ist die Erweiterung des Pfades um die jeweiligen Funktions- oder (Teil)ressourcennamen:

https://server.name/woerterbuch1/artikel
https://server.name/woerterbuch2/artikel/Haus

Dadurch erhält jede Funktion oder Teilressource selbst wiederum einen eindeutigen URI. Es sind aber auch andere Varianten möglich, zum Beispiel über Erweiterungen des HTTP(S)-Protokolls, auf die hier jedoch nicht weiter eingegangen wird, da im Rahmen von ZHistLex nur die Addressierung über URIs vorgesehen ist.

Die Funktionen eines Webservices werden in vielen Fällen parametrisiert. Parameter bezeichnen oft die konkreten Daten, auf denen oder mit deren Hilfe eine Funktion operieren soll. Bei der Abfrage eines Wörterbuchs über einen Webservice mit Hilfe einer Funktion artikel (wie im obigen Beispiel) könnte ein Parameter das Lemmazeichen sein. Die Funktion wird dann alle Artikel ermitteln, die zu dem angegebenen Lemmazeichen im Wörterbuch gebucht wurden. Auch für die Art und Weise der Parameterübergabe gibt es verschiedene technische Möglichkeiten. In ZHistLex kommen Matrixparameter zum Einsatz.

Die Menge der Funktionen eines Webservices bildet zusammen mit den dazugehörigen Parametern und einer Beschreibung möglicher Rückgabewerte eine definierte Schnittstelle für die Kommunikationspartner dieses Services. In Anlehnung an die Terminologie der Computerprogrammierung werden solche Schnittstellen als API (application programming interface) bezeichnet. Die Spezifikation einer API eines Webservices wird oft in speziellen formalen Beschreibungssprachen erstellt. Darauf wird in den Dokumentationen zu den konkreten ZHistLex-Webservices genauer eingegangen.

Webservices im RESTful-Paradigma

Es existieren verschiedene Paradigmen innerhalb derer Webservices konzipiert und implementiert werden können beispielsweise Remote Procedure Calls (RPC, eine sehr frühe technische Lösung zur Client-Server-Kommunikation), das Simple Object Access Protocol (SOAP, das allerdings in der Praxis – anders als der Name es suggeriert – ein sehr komplexes Protokoll ist) oder das RESTful-Paradigma (Representational State Transfer), das auch in ZHistLex verwendet wird.

Details zum RESTful-Paradigma sind in Fielding (2000) zu finden; hier wird nur kurz auf zwei grundlegende Eigenschaften genauer eingegangen, die zum Verständnis der technischen Umsetzung in ZHistLex besonders wichtig sind: die Zustandslosigkeit von Client und Server sowie die variable Repräsentation der Ressourcen.

Ein Kommunikationspartner wird als zustandslos bezeichnet, wenn er erhaltene Nachrichten unabhängig von zuvor erhaltenen Nachrichten verarbeiten kann. Die Voraussetzung hierfür ist, dass jede Nachricht bereits alle Informationen enthält, die zu ihrer Verarbeitung notwendig sind. Bei der Abfrage statischer Ressourcen ist das in der Regel der Fall. Die Zustandslosigkeit vor allem des Servers vereinfacht die Implementation beträchtlich, da zum Beispiel keine aufwändige Sitzungsverwaltung erfolgen muss, die vergangene Aktionen einzelner Nutzer aufzeichnet und gegebenenfalls bei der Verarbeitung von Nachrichten in Betracht zieht.

Die Ressourcen, die über einen Webservice erschlossen werden, können schließlich in ganz unterschiedlichen Repräsentationsformen an anfragende Clients zurückgegeben werden. Insbesondere in der Maschine-Maschine-Kommunikation ist solche Variabilität wünschenswert, da es vorkommen kann, dass ein Client nur eine spezielle Repräsentationsform – ein spezifisches Datenformat – verarbeiten kann. Im RESTful-Paradigma können die Kommunikationspartner über weit verbreitete Mechanismen des HTTP(S)-Protokolls die zu verwendenden Formate „aushandeln“. Das geschieht beispielsweise über spezielle Header (Accept, Content-Type) in den HTTP-Paketen. Im Accept-Header des Clients werden die von diesem akzeptierten Datenformate (in der präferierten Reihenfolge spezifiziert):

Accept: application/xml,application/json;version=1 

Der Server trifft (in Abhängigkeit von den wiederum von ihm selbst unterstützten Formaten) eine Auswahl und teilt diese dem Client in seiner Antwort mit:

Content-Type: application/json 

Dieser Mechanismus kommt bei ZHistLex-Webservices zum Einsatz. Maschinelle Clients erhalten standardmäßig eine strukturierte JSON-Repräsentation der angefragten Daten, während menschliche Clients (über den zur Abfrage verwendeten Webbrowser) in der Regel eine HTML-Repräsentation zu Gesicht bekommen.

Weiterführende Literatur

• Fielding, Roy Thomas (2000). Architectural Styles and the Design of Network-based Software Architectures“. Ph. D., Univ. of California, Irvine.
• Herold, Axel/Meyer, Peter/Müller-Spitzer, Carolin (2016): „Datenmodellierung“. S. 111–152. In: Klosa/Müller-Spitzer (2016).
• Klosa, Annette/Müller-Spitzer, Carolin (2016): „Internetlexikografie. Ein Kompendium“. Berlin/Boston: de Gruyter.
• Meyer, Peter/Herold, Axel/Lemnitzer Lothar (2016): „Technische Rahmenbedingungen der Internetlexikografie“. S. 1–30. In: Klosa/Müller-Spitzer (2016).

Letzte Änderung auf dieser Seite: 6. September 2019