2. Web Services

In diesem Kapitel soll zuerst geklärt werden, was man überhaupt unter einem Web Service versteht. Danach wird kurz die Funktionsweise von Web Services erklärt. Um zu begreifen, wie so etwas im Detail funktioniert, werfen wir einen Blick auf die Umsetzung. Diese wird einmal im Überblick angegeben bevor auf die Teile WSDL, SOAP und UDDI genauer eingegangen wird.

2.1 Definition

Es existieren einige verschiedene Meinungen darüber, was man genau unter einem Web Service versteht. Einige Definitionen bestehen nur aus einem Satz [SU02], andere aus langen Erklärungen [SR01] [MA02]. Der Grundgedanken ist jedoch meist derselbe. Wir wollen hier auf die Definition des World Wide Web Consortium (W3C) aufbauen. Das W3C entwickelt unter anderem Spezifikationen, welche durch ihre Standardisierung zur Nutzung des gesamten Potenzials des Webs beitragen sollen. Diese Standards sind weithin anerkannt und werden oft als Grundlagen weiterer Entwicklungen genommen.

Hier nun die Definition:

Ein Web Service ist ein über eine URI identifiziertes Software-System, für welches Public Interfaces und Bindings definiert und mit Hilfe von XML beschrieben sind. Seine Definitionen können von anderen Software-Systemen erschlossen werden. Diese Systeme können dann mit dem Web Service auf die Art und Weise interagieren, die bei seiner Definition vorgeschrieben wurden, indem sie auf XML basierende Messages benutzen, die von Internet-Protokollen übertragen werden. [BH02]

Um diese Definition besser zu verstehen, folgt hier die Erklärung einiger Elemente, die nicht so geläufig sind.

• Interface: Eine logische Gruppierung von Operationen. Ein Interface repräsentiert einen abstrakten Servicetyp, unabhängig vom Übertragungsprotokoll und dem Datenformat.

• Binding: Eine Assoziation zwischen einem Interface, einem konkretem Protokoll und einem Datenformat. Ein Binding spezifiziert das Protokoll und das Datenformat, welches zur Übertragung der durch das assoziierte Interface definierten Messages benutzt werden soll.

• Message: Eine Basiseinheit der Kommunikation zwischen einem Web Service und einem Client.

2.2 Funktionsweise

Hauptsächlich kann man einen Web Service als eine verteilte Peer-To-Peer-Applikation verstehen, welche über Webprotokolle zugänglich ist.

Im allgemeinen Fall muss der Client zuerst den Web Service und seinen Provider ausfindig machen, bevor er ihn nutzen kann. Dazu kann er z.B. Suchmaschinen benutzen oder Sammelverzeichnisse durchsuchen, in welche sich die Service Provider eingetragen haben.
Aus der Service-Beschreibung erhält der Client die nötigen Informationen, um den Provider zu kontaktieren, seine Anfrage zu formulieren und die Antwort auswerten zu können.


Abbildung 2.1: Schema einer Service orientierten Architektur [CF02]

Um die Abbildung 2.1 besser zu verstehen, nachfolgend noch Einläuterungen, wobei auf die Komponenten, die Rollen und die Operationen näher eingegangen wird.

Komponenten:

• Service: Ein Service ist ein Softwaremodul, welches den beschriebenen Web Service umsetzt. Es kann sowohl von Benutzern über das Web aufgerufen werden, als auch selber andere Web-Service-Implementationen aufrufen.

• Service-Description: Die Service-Description beinhaltet die Informationen über den Web Service wie z.B. Datentypen, Operationen oder die Netzwerklage. Auch Metadaten, die das Verständnis und die Benutzung unterstützen, können hier aufgeführt werden.

• Service-Provider: Geschäftlich gesehen ist der Service-Provider der Eigentümer des Services. Architektonisch ist dies jedoch die Plattform, auf welche der Zugriff stattfindet.

• Service-Requestor: Eine Anwendung ist ein Service-Requestor, wenn sie einen Service aufruft und mit diesem interagiert. Dabei kann die Anwendung z.B. ein Browser sein, der von einer Person benutzt wird, aber auch ein anderer Web-Service.

• Discovery Agency: In der Discovery Agency befindet sich eine Anzahl von Service-Descriptions. Benutzer können diese durchsuchen, um Web Services zu finden und die erforderlichen Binding-Informationen zu erhalten.

• Publish: Ein Service-Provider veröffentlicht seine Service-Description, so dass er für Benutzer zugänglich ist und von ihnen auch gefunden werden kann.

• Find: Ein Benutzer durchsucht das Verzeichnis der Discovery Agency nach einem bestimmten Service.

• Interact: Ein Service-Requestor ruft einen Service auf bzw. initiiert eine Interaktion mit dem Service. Dabei kann die Interaktion aus einer einzelnen Nachricht an einen oder mehrere Services bestehen oder aus einer Konversation, die mehrere Nachrichten enthält.

2.3 Umsetzung

Implementiert werden Web Services nicht in einheitlicher Art und Weise, sondern durch eine Sammlung von verschiedenen Technologien.

Dabei beinhaltet die Definition von Web Service nicht, dass z.B. SOAP als Paketformat verwendet wird und WSDL als Service-Definitionssprache benutzt wird. In der allgemein akzeptierten Definition wie z.B. in der Web Service Architektur [CF02] geht man allerdings davon aus. Auf diese wollen wir uns hier beziehen.
Trotzdem sei angemerkt, dass ein Web Service durchaus auch nur ein einfaches HTTP als Datenübertragungsprotokoll und ein abgesprochenes XML Format als Nachrichteninhalt benutzen kann, um als Web Service zu gelten.

Die wichtigsten der verwendeten Protokolle und Standards sind:

• Extensible Markup Language (XML): XML ist ein weithin akzeptiertes Format zum Austausch von Daten und deren entsprechender Semantik. Dadurch, dass XML textbasiert ist, ist es sehr variabel und kann auf allen Plattformen und von allen Programmiersprachen ausgelesen werden. Es ist ein Grundbaustein für andere Technologien.

• Web Services Description Language (WSDL): WSDL ist eine auf XML basierende Beschreibung, wie man einen Web Service im einzelnen kontaktiert. Der grobe Aufbau einer WSDL-Datei wird im Abschnitt 2.3.1 anhand eines Beispieles erklärt.

• Simple Object Access Protocol (SOAP): SOAP ist ein Protokoll für Nachrichten und RPC-ähnliche Kommunikation zwischen Applikationen. Es basiert auf XML und baut auf allgemein anerkannten Transportprotokollen wie HTTP auf, um seine Daten zu transportieren. Hierzu etwas mehr im Abschnitt 2.3.2.

• Universal Description, Discovery and Integration (UDDI): UDDI repräsentiert ein Set von Protokollen und öffentlichen Verzeichnissen zur Registrierung und Echtzeitsuche nach Web Services und anderen Geschäftsprozessen. Etwas mehr Informationen dazu im Abschnitt 2.3.3.

• Common Internet Protocols: Obwohl Web Services nicht an ein spezielles Transportprotokoll gebunden sind, werden sie auf den gegenwärtigen Stand der Internetverbindungen und deren Infrastrukturen aufgebaut. Dies ermöglicht eine universelle Erreichbarkeit und Unterstützung. Insbesondere wird bei HTTP ausgenutzt, dass dies das Verbindungsprotokoll ist, welches von Webservern und Browsern benutzt wird.

Natürlich existieren noch weitere Technologien und neue werden entwickelt. Bei der Abbildung 2.2 lässt sich erkennen, dass XML erst ungefähr 1997 entwickelt wurde. SOAP und WSDL kamen sogar noch einige Jahre später hinzu. Es gibt Arbeitsgruppen, die sich mit der Entwicklung neuer Protokolle und Standards beschäftigen. Im Internet lassen sich dazu aktuelle Informationen einholen.

2.3.1 WSDL

Wenn Kommunikationsprotokolle und Nachrichtenformate standardisiert sind, ist es nicht nur möglich sondern auch wichtig, diese Kommunikationen auf eine strukturierte Weise zu beschreiben. Dafür wurde die Web Services Description Language (WSDL) entwickelt.
WSDL baut, wie bereits erwähnt wurde, auf XML auf. Es stellt das Interface, also die nach außen sichtbare Schnittstelle eines Web Services dar. Dazu gehören die Operationen mit ihren Parametern und Rückgabewerten. Etwas allgemeiner ausgedrückt, bietet WDSL XML-Sprachregeln für die Beschreibung "was" ein Web Service leistet, "wo" er sich befindet und "wie" er aufzurufen ist.

In WSDL werden folgende Elemente verwendet, um einen Web Service zu definieren:

• TYPES - Ein Container für Datentypdefinitionen, z.B. unter Verwendung von XSD.

• MESSAGE - Eine abstrakte, festgelegte Definition der Datenkommunikation.

• OPERATION - Eine abstrakte Beschreibung einer Serviceleistung.

• PORT TYPE - Eine abstrakte Sammlung von Operationen, die von einer bzw. mehreren Schnittstellen unterstützt werden.

• BINDING - Ein konkretes Protokoll und Datenformatspezifikation für einen bestimmten PORT TYPE.

• PORT - Eine einzelne Schnittstellendefinition bestehend aus BINDING und Netzwerkadresse.

• SERVICE - Eine Sammlung von verbundenen Schnittstellen.

Ein WSDL-Dokument definiert Services als eine Sammlung von Netzwerk-Endpunkten, welche mit Nachrichten operieren, die entweder dokumentorientierte oder funktionsorientierte Information enthalten. Die Operationen und Nachrichten werden abstrakt definiert und dann an ein konkretes Netzwerkprotokoll und Nachrichtenformat gebunden, um einen Endpunkt zu definieren. Zusammenhängende konkrete Endpunkte verbindet man zu abstrakten Endpunkten (Services). WSDL ist erweiterbar, um die Beschreibung von Endpunkten und deren Nachrichten zu erlauben, unabhängig vom benutzten Nachrichtenprotokoll und Netzwerkprotokoll.

In dem folgenden WSDL-Dokument (Abbildung 2.3) wird ein Temperaturservice beschrieben. Die Datei wirkt auf den ersten Blick sicher irritierend und umfangreich. Beim näheren Hinschauen und etwas mehr Wissen über den WSDL kann man die Details erkennen.

Im unteren Teil der Datei lässt sich der Name des Web Services TemperatureService finden und seine Aufgabe, die aus dem Zurückgeben der aktuellen Temperatur zu einer gegeben Postleitzahl besteht. Es wird eine Schnittstelle, deren Netzwerkadresse http://services.xmethods.net:80/soap/servlet/rpcrouter lautet, mit dem Namen TemperaturePort definiert. Das dazugehörige Binding heißt TemperatureBinding und wird weiter oben näher beschrieben, wo z.B. die Verwendung von SOAP angegeben wird. Die einzige in dem Dokument angegebene Operation heißt getTemp. Die Input-Nachricht dieser Operation verlangt einen zipcode vom Typ string und die Output-Nachricht liefert ein Element return vom Typ float.

Dies soll als Überblick über WSDL erst mal reichen. Weitere Informationen gibt es beim W3C, wo sich auch weitere Veröffentlichungen finden lassen, die im Zusammenhang mit Web Services stehen. Dazu gehört auch SOAP, welches als nächstes erläutert werden soll.

2.3.2 SOAP

SOAP steht für Simple Object Access Protocol, welches ursprünglich von der Firma Microsoft entwickelt wurde, inzwischen aber vom W3C [MI02] standardisiert wird.
SOAP ist ein Protokoll der Darstellungsschicht für den Austausch von Informationen in verteilten Systemen wie dem Internet. Dadurch wird es Applikationen ermöglicht miteinander über HTTP zu kommunizieren und Komponenten auf anderen Systemen aufzurufen und auszuführen. Dies ist auf anderen Wegen und mit anderen Protokollen meist sehr schwierig, bzw. gar nicht möglich, da Hindernisse wie eine Firewall den zugriff auf Remote-Objekte verhindern. SOAP bildet quasi die Basis für Web Services. Ein weiterer Vorteil ist auch bei SOAP die Plattformunabhängigkeit.

SOAP basiert wie WSDL auf dem offenem Standard XML und besteht aus den folgenden drei Teilen:

• Der SOAP-Envelope definiert den Rahmen, was in einer SOAP Message enthalten und wie diese zu verarbeiten ist.

• Ein Satz von Kodierungsregeln beschreibt die Instanzen von anwendungsdefinierten Datentypen

• Der SOAP-RPC Darstellung, die Remote-Prozeduraufrufe und -antworten wiedergibt.

Potenziell kann SOAP mit einer Vielzahl von Protokollen genutzt werden. Zur Zeit ist aber nur die Verwendung mit HTTP definiert.

SOAP lebt von Nachrichten und kommuniziert asynchron. Eine SOAP Nachricht (Message) besteht aus einem SOAP Envelope, einem optionalen SOAP-Header und einem vorgeschriebenen SOAP-Body. In der SOAP Message steht die Funktion des Web Services, der aufgerufen werden soll und eventuelle Parameter, die diese Funktion benötigt. Auf dem Envelope (Umschlag) steht die Adresse des Web Services.

Abbildung 2.4 zeigt ein Beispiel eines SOAP-Requests von einem Client, der an den Temperature-Service gesendet werden könnte, von dem wir zuvor schon die WSDL-Datei betrachtet haben. Erfragt wird hier die Temperatur für die Postleitzahl 95123.

Nach dem Aufruf einer Web-Service-Methode erfolgt eine sofortige Antwort. Falls der Server die aufgerufene Methode nicht zur Verfügung stellt, enthält die Antwort eine Fehlermeldung. Ist die Methode vorhanden und die Inputparameter sind korrekt, dann gibt es im SOAP-Response die in der WSDL definierten Outputparameter. Abbildung 2.5 zeigt eine erfolgreiche Antwort und im SOAP-Body die Temperatur von 10,3.

2.3.3 UDDI

UDDI steht für Universal Description, Discovery and Integration und ist ein Industrieprojekt [UD02], dem bekannte IT-Firmen wie Ariba, IBM oder Microsoft angehören.

Die UDDI-Technologie soll es ermöglichen, kommerzielle Dienste dynamisch auffindbar zu machen und definiert, wie diese interagieren und Informationen in einer globalen Verzeichnisarchitektur über das Internet teilen können. Damit wird UDDI zur Drehscheibe für dynamische Business-Transaktionen im Internet. Alle Teile von UDDI basieren auf Standards (z.B. XML, HTTP) des W3C und der IETF.

UDDI besteht aus zwei Hauptbestandteilen. Zum Ersten stellt es ein zentrales Repository dar, in dem Unternehmen Web Services registrieren und suchen. Zum Zweiten beschreibt UDDI ein Framework, um die Dienste des Repositories zu nutzen. Derzeit betreiben IBM, HP und Microsoft einen solchen Verzeichnis-Server und seit kurzem auch SAP. Diese gleichen sich großteils untereinander ab.

Die Einträge in einem UDDI-Verzeichnis unterteilen sich in 3 Bereiche:

• Die White Pages enthalten Informationen über das Unternehmen, wie z.B. den Firmennamen und Kontaktinformationen.

• Die Yellow Pages beinhalten eine Kategorisierung von Unternehmen anhand von Standardeinteilungen, beispielsweise Produktcodes.

• In den Green Pages befinden sich die technische Beschreibung zu den angebotenen Diensten und dem Zugriff auf diese Dienste.

Für den Zugriff auf UDDI bedient sich dieses SOAP. Es stützt sich damit auf die Internetstandards XML, HTTP sowie TCP/IP.