Der Begriff Webservices wird das Internet für die nächsten
Jahre tiefgreifend prägen – doch was sind Webservices überhaupt,
wie funktionieren sie und wie kann sie ein Webworker nutzen? Auf diese Fragen
gibt dieser Workshop antwort.
Schon der Begriff "Webservices" enthält eine eigentliche Definition.
Webservices sind Dienste, die über das Internet bereitgestellt werden.
Trotz dieser scheinbar recht einfachen Definition, haben sich die "Großen",
Microsoft, IBM, Hewlett Packard, Sun etc. noch nicht auf eine einheitliche Definition
geeinigt. Unter http://www.jeckle.de/webServices/
finden Sie eine Auflistung der verschiedensten Definitionen von, was Webservices
eigentlich sind.
Als kleinster gemeinsamer Nenner kann man sagen, dass über Webservices
dem Client (das ist der Nutzer) Funktionen, Daten und Anwendungen bereitgestellt
werden können.
Dabei ist der Client nicht mehr der vor seinem Computer sitzende Surfer –
es sind eigenständige Anwendungen, welche Webservices für die eigene
Programmfunktion nutzen.
Ein einfaches Beispiel dafür sind die Google Webservices. Dabei kann ein
Programmierer über Webservices auf die mächtige Google Suchfunktionen
zurückgreifen, und diese in die eigene Anwendung integrieren. So können
z.B. siteinterne Suchmaschinen ohne viel Aufwand erstellt werden; dies soll
im dritten Teil dieses Workshops beleuchtet werden.
Über Webservices kann man folglich ganze Anwendungen modellieren. Doch
wie funktioniert die Kommunikation zwischen den verschiedenen Anwendungen? Die
Daten müssen ja in irgendeiner Form von einem Programm zum anderen geschickt
werden.
Das versenden der Daten wird über das http Protokoll bewerkstelligt. Die
Anfragen und Antworten werden in Form von XML gesendet. Man hat sich auf diese
beiden Standards geeinigt, da sie quasi überall "verstanden"
werden. Sie sind plattform- und insbesondere programmiertechnisch unabhängig.
Die Anfragen an den Webservice werden folglich in XML verpackt und über
http versendet. Die XML Nachricht wird vom Webservice interpretiert und wiederum
in Form von XML beantwortet.
Da Webservices für die Integration von Programmfunktionen in anderen Anwendungen
gedacht sind, musste man sich auch hier auf eine einheitliche Form der Datenübertragung
zum Nutzen aller einigen. So entstand SOAP, das Simple Object Access Protocol,
basierend auf XML. Dadurch wurde erreicht, dass alle Webservice Anfragen und
Antworten eine einheitliche Form haben. Zwar gibt es auch Webservices, die nicht
auf SOAP zurückgreifen, jedoch wird sich SOAP in Zukunft durchsetzen, da
nur durch eine einheitliche Datenübertragung die Nutzung von Webservices
eine allgemeine Bedeutung erlangen kann.
Ein Anfrage besteht, wie man im folgenden Diagramm sehen kann aus einem festen
Grundgerüst.
Struktur einer SOAP Nachricht
Das Grundgerüst ähnelt sehr dem einer HTML Seite, bestehend aus einem
Head- und einem Body-Bereich, in welchem die Antwort- bzw. Anfragedaten abgelegt
sind.
In der folgenden Abbildung ist ein einfaches Schema für den Datenfluss
bei der Nutzung von Webservices abgebildet. Dabei besitzt die Anwendung welche
auf den Webservice zurückgreift ebenfalls einen XML Interpreter, über
welchen die XML Daten in ein Format überführt werden, in welchem sie
weiterverarbeitet werden können. Die SOAP Antwort muss folglich von der
Anwendung verarbeitet werden. Auf diese Weise wird die Nutzung von Webservices
nicht nur auf einzelne Programmiersprachen beschränkt. Man kann Webservices
über jede Programmiersprache verwenden, die eine XML bzw. SOAP Schnittstelle
besitzt.
Einfaches Datenflussdiagramm für die Nutzung von Webservices
Man kann dieses einfache Modell noch erweitern, indem man sich den Webservice
auf welchen man zurückgreift selbst als eine Anwendung betrachtet welche
auf verschiedene andere Webservices zurückgreift.
Man kann sich das an einem einfachen Beispiel veranschaulichen. Bei einer Buchbestellung
möchten Sie den Status ihrer Bestellung verfolgen. So können sie bei
dem Verkäufer den Status bis zum versenden betrachten. Bei dem Zusteller
(z.B. der Post) können sie den weiteren Verlauf verfolgen.
Durch Webservices ist es nun möglich, dass der Verkäufer den Status
der Bestellung auch über die eigenen Systemgrenzen verfolgen kann, indem
er auf einen Webservice des Zustellers zurückgreift und dort den Status
des Versandes ermitteln kann und diesen an den Käufer weitergeben kann.
Das ist nur ein einfaches Beispiel der Integration von Webservices in andere
Anwendungen.
Nachdem die grundlegende Funktion von Webservices geklärt ist, müssen
noch weitere Aspekte in Betracht gezogen werden, die sich insbesondere für
den Programmierer ergeben, der von Webservices gebrauch machen möchte.
Den woher weiß der Programmierer auf welche Funktionen er bei der Nutzung
von Webservices zurückgreifen kann, bzw. welche Parameter diese brauchen.
Hierzu wurde von IBM und Microsoft gemeinsam die Webservice Description Language,
kurz WSDL, entwickelt. Sie basiert auf XML und ermöglicht die standarisierte
Beschreibung von Webservices – sie wird auch vom W3C als möglicher
Standard diskutiert.
Ein weiteres Problem, welches Auftritt ist, dass bei einer Vielzahl von Webservices
unklar ist, wer überhaupt was anbietet. Die Webservices müssen irgendwo
verzeichnet sein. Idealerweise sollte der Webservicenutzer nur noch eine Anfrage
an das Webserviceverzeichnis machen müssen; dieses leitet ihn dann direkt
weiter an den für die Anfrage passenden Webservice. Ein solches "Telefonbuch"
für Webservices wurde durch UDDI (Universal Description, Discovery and
Integration) geschaffen. In ihm sind die Webservice Anbieter und die von ihnen
angebotenen Webservices verzeichnet. Bereits viele Anbieter haben UDDI implementiert.
Doch was für Chancen oder Zukunftsaussichten liegen in Webservices? Der
Nutzen für Unternehmen ist eindeutig, da sie bei ihren Anwendungen einfach
gesagt, nicht mehr alles selbst programmieren müssen. Die einzelnen Firmen
werden sich durch ihre Webservices stärker als bisher vernetzen und so
insbesondere in den Beziehungen zu den Kunden verbessern.
Doch was bedeutet das für den Internetnutzer?
Eine Vision ist, dass man über Webservices eine Personalisierung des ganzen
Internets einführen kann. So hat Microsoft bereits über ihr .NET Passport
einen ersten Schritt dahingehend getan. Über einen .NET Passport kann man
auf die verschiedensten Angebote von Microsoft zugreifen ohne jedes Mal ein
neuen Account anlegen zu müssen. Das heißt man müsste seine
persönlichen Daten nur noch in einem virtuellen Pass hinterlegen, über
welchen man dann auf die verschiedensten Internetdienste zurückgreifen
kann.
Dies wird jedoch auch heftig diskutiert, da damit erhebliche Sicherheitsbedenken
verbunden sind.
Webworker selbst können Webservices bisher nur in beschränkten Maße
nutzen. Bei den in diesem Workshop betrachteten Webservices von Google und Amazon
können Webworker auf die Produktpalette von Amazon bzw. auf die Suchfunktion
von Google zurückgreifen und diese in die eigene Webseite integrieren.
Es bleibt also noch zu erwarten in wie weit Webservices das Leben eines Webworkers
beeinflussen wird – im Rahmen dieses Workshops soll der Nutzen der beiden
betrachteten Webservices für den Webworker in den Vordergrund gestellt
werden.
(tf)