Web-Services sind eine Realisierung einer SOA, mit der sich Informationsdienste im WWW automatisieren lassen. Es handelt sich dabei um funktionale Dienste, die über Internetprotokolle und die Internet-Infrastruktur übertragen werden können. In den meisten Fällen sind Web Services Software-Komponenten, die mittels Applikationsserver im Internet „nutzbar“ gemacht werden. Um Daten miteinander auszutauschen, werden XML-basierte Standards verwendet. Etwaige Transaktionen können ohne menschliches Zutun zwischen Web-Services abgewickelt werden.
Die lose Kopplung der Komponenten über Web Services führt zu einer diensteorientierten SOA-Architektur, in der die funktionale Schnittstelle und ihre Semantik die Integration zur Gesamtlösung bestimmt. Die SOA von Web-Services besagt, dass Web Services beschrieben, veröffentlicht (published), gefunden (discovered) und dynamisch aufgerufen (invoked) werden können.
|
Teil 1 |
|
|
Teil 2 |
Beispiele für Web Services
Die mit Web Service Diensten verbundenen Protokolle und Standards wie SOAP, WSDL und UDDI bilden den technologischen Rahmen für die Realisierung solcher Szenarien in verteilten Anwendungen. Das W3C hat eine eigene Arbeitsgruppe eingerichtet, die sich mit der Frage der Web-Services-Architektur und den entsprechenden Szenarien auseinandersetzt.
Web Services haben sich nun schon seit einiger Zeit bei der Integration bewährt und etabliert und spielen nicht nur im Bereich unternehmensweiter „großer“ Lösungen eine Rolle. Sie haben mittlerweile auch die Hardware-, Lösungs- und Anwendungsebene durchdrungen. Im Bereich der Anbindung mobiler Geräte und dedizierter Hardware (embedded devices) erleichtern Web Services die Integration in Anwendungen signifikant.
Seit 2002 gibt es von Google einen Web Service, der durch seine Funktionalität die gleichen Möglichkeiten der Website anbietet, wie die Benutzerschnittstelle auf der Website selbst (http://code.google.com/). Programme können nun mit einem Ansprechen der Schnittstelle direkt nach Informationen im Internet suchen, erhalten über die Schnittstelle die Ergebnisdaten und können diese für ihre eigenen Aufgaben verwenden. Das Parsen der Google-Webseite ist dazu keine auch nur annähernd gleichwertige Alternative.
Weitere Beispiele
Ein weiteres Beispiel ist die Interaktion zwischen Fluggesellschaften und Reisebüros. Die Fluggesellschaften stellen Möglichkeiten zum Nachschlagen bzw. Buchen von Flügen über einen Web Service bereit. Die Reisebüros bieten auf ihrer Webpräsenz Flüge verschiedener Fluggesellschaften an, von denen die Reisebüros zur Laufzeit über den Verzeichnisdienst UDDI erfahren. Der Kunde kann auf der Webpräsenz des Reisebüros nun zentral Preise und Termine verschiedener Flüge vergleichen und direkt buchen.
Web Services sind nicht die erste Realisierung einer SOA. Schon vor Web Services existierten Konzepte, die ähnliche Probleme erfolgreich gelöst haben. Das war zum Beispiel COM/DCOM von Microsoft, RMI von Sun und Corba von OMG.
Von diesen drei Konzepten war allerdings lediglich Corba plattformunabhängig, die anderen waren gebunden an das Betriebssystem des jeweiligen Herstellers. Kern der 1991 veröffentlichten Corba-Spezifikation war das Objektmodell. Corba setzte sich letztendlich deshalb nicht durch, weil es mit verschiedenen Problemen kämpfte - etwa unvollständiger Spezifikation oder unbefriedigender Abbildung der Datentypen in andere Programmiersprachen.
Merkmale von Web Services
Eine allgemeine, einheitliche Beschreibung von Web Services ist schwierig. Trotzdem herrscht in Standardisierungsgremien wie dem W3C eine allgemeine Übereinstimmung darüber, was ein Web Service ist:
-
So sind Web Services immer über programmierbare Schnittstellen erreichbar und mittels Nachrichten-basiertem XML-Datentransfer wie SOAP und WSDL aufrufbar („Programmierbarkeit“).
-
Ein Web Service basiert auf der Internet-Protokollsuite. Operationen und Nachrichten können mehrere Protokolle unterstützen, z.B. das Hypertext Transfer Protocol (HTTP) oder das Simple Mail Transfer Protocol (SMTP) („Protokolltransparenz“).
-
Web Services sind zudem unabhängige, in sich abgeschlossene bzw. gekapselte Anwendungen, die eine genau definierte Aufgabe erfüllen („Kapselung“). Die Implementierungsdetails bleiben Konsumenten und Anbietern verborgen („lose Koppelung“).
-
Web Services können entweder in weitere Web Services zerlegt werden oder mehrere, wieder verwendbare Basis-Web-Services können zu einem neuen Web Service zusammengestellt werden („Komposition“).
-
Web Services sind ortsunabhängig und können jederzeit und von jedem Ort aus aktiviert werden, vorausgesetzt Benutzer und Anwendungen haben entsprechende Zugriffsrechte („Ortstransparenz“). Begleitet wird ein Web Service von Metadaten, die während der Laufzeit von weiteren Web Services ausgewertet werden können („Selbstbeschreibung“). Name, Beschreibung, Version und Dienstgüte sind typische Beschreibungsmerkmale.
-
Darüber hinaus können Web Services entweder von informativer oder von transaktioneller Natur sein. Transaktionelle Web Services können Bestandteil lang laufender Geschäftstransaktionen sein.
Basiskomponenten von Web Services
Die Standardisierung und Automatisierung von Web Services lässt sich nur zu einem bestimmten Teil vorantreiben. Das bekannte Dilemma zwischen Dejure- und Defacto-Standards bleibt bislang noch bestehen.
Das World Wide Web Consortium (W3C), OASIS (Organization for the Advancement of Structured Information Standards) und einige weitere unabhängige Gremien widmen sich der Standardisierung in diesem Bereich. Das W3C konzentriert sich hierbei weitgehend auf horizontale Standards, das heißt, technische Standards, die auf alle Industriezweige angewendet werden können. OASIS dagegen befasst sich mit so genannten vertikalen Standards und verwendet – soweit möglich – bestehende technische Standards.
Folgende Standards bilden das Fundament der Web-Service-Architektur:
SOAP
SOAP („Simple Object Access Protocol“) ist das XML-basierte Format zur Kommunikation und zum Nachrichtenaustausch und dessen Einbettung in ein Transportprotokoll. Der Standard definiert allgemeine Regeln zum Austausch von Nachrichten zwischen Applikationen.
SOAP übernimmt die lose Koppelung, die verteilte Architektur und den Transport über bekannte Internet-Protokolle - unabhängig von der zu Grunde liegenden Software-Architektur. Dem Thema SOAP widmet sich ein eigener Beitrag, der Ende Januar erscheinen wird.
WSDL
WSDL („Web Service Description Language“) ist eine XML-basierte Beschreibungssprache, um Web Services bzw. deren Fähigkeiten zu beschreiben. Genau genommen werden die Schnittstellen von Web Services beschrieben, nicht die Services selbst. Strukturell betrachtet, besteht ein WSDL-Dokument aus einem in XML beschriebenen Schema. In diesem Schema ist eine Grammatik enthalten, mit der Verträge („contracts“) formuliert werden können. Diese Verträge haben ihre Gültigkeit bei der Kommunikation zwischen zwei Endpunkten. Zu WSDL veröffentlichen wir demnächst einen eigenen Beitrag.
UDDI
UDDI („Universal Description, Discovery and Integration“) ist ein Verzeichnisdienst für Web Services. Der Dienst spezifiziert eine standardisierte Verzeichnisstruktur für die Verwaltung von Web-Services-Metadaten. Es handelt sich dabei um eine Art „Gelbe Seiten" (yellow pages), in dem Web Services und ihre Schnittstellen registriert sind.
Zu den Metadaten gehören allgemeine Anforderungen, Web-Services-Eigenschaften oder die benötigten Informationen zum Auffinden von Web Services. Die White-Pages bieten Aufschluss über den Firmennamen, Beschreibung und Ansprechpartner. Die Yellow-Pages enthalten Produkt, Dienst, Industriezweig und geographische Unterteilung, während sich die Green-Pages mit den technischen Details der Datenkommunikation auseinander setzen.
UDDI ist zwar nicht unbedingt notwendig für den Einsatz von Web Services, gehört aber als Infrastrukturkomponenten unbedingt zu einer SOA. UDDI unterscheidet sich von den anderen beiden Spezifikationen darin, dass zur Beschreibung eines Verzeichnisdienstes keine eigene XML-Anwendung verwendet wird. Allerdings sollte ein entsprechender Verzeichnisdienst mit WSDL-Dokumenten umgehen können und selbst auch als Web Services verfügbar sein.
Die folgende Grafik zeigt das Zusammenspiel der drei Standards:
Die im SOA-Beitrag erwähnte Dreiecksbeziehung zwischen Diensteanbieter, -nutzer und –verzeichnis lässt sich nun auf die Basiskomponenten konkretisieren.
Rollen und Aktionen
Wie im erstem Teil unserer SOA-Reihe bereits beschrieben, setzt eine SOA-Architektur drei Rollen voraus.
-
Dienstnutzer (Konsument): Er agiert mittels XML-basierter Nachrichten und Transportprotokollen mit einem Web-Service-Verzeichnis oder -Anbieter. Die dynamische Anbindung mit dem kommunizierenden Web-Service erfolgt über ein Web-Service-Verzeichnis.
-
Dienstanbieter: Er bietet einen Dienst über programmierbare Schnittstellen an.
-
Dienstverzeichnis (Repository): Es enthält eine logische Beschreibung und Angaben über den Aufenthaltsort sämtlicher Web-Service-Anbieter.
Konsument, Anbieter und Verzeichnis sind austauschbar. Ein Konsument kann auch als Zwischenhändler fungieren und somit auch Anbieter eines Web-Service sein.
In ihrer einfachsten Form interagieren zwei Web-Services wie folgt:
-
Ein potentieller Nutzer eines Web-Service stellt eine Suchanfrage an einen Verzeichnisdienst.
-
Das Web-Service-Verzeichnis enthält eine kategorisierte Ansammlung von registrierten, vertrauenswürdigen Web Services.
-
Nachdem der gewünschte Service ausfindig gemacht wurde, können weitere Details über Nachrichtenformate und Protokolle angefragt werden.
-
Basierend auf der Servicebeschreibung, kann eine Protokollanbindung erzeugt werden. Somit können beide Web Services miteinander kommunizieren.
Technisch gestaltet sich der Ablauf wie folgt: Ein Anbieter, der einen Dienst in Form eines Web Services anbieten möchte, erstellt von diesem zunächst eine WSDL-Schnittstellenbeschreibung in Form eines entsprechenden XML-Dokuments. Dieses WSDL-Dokument wird publiziert, indem es ganz oder in bestimmten Teilen zu einem UDDI-basierten Verzeichnisdienst transferiert wird. Anschließend wartet der Diensteanbieter, bis ein Dienstnutzer einen entsprechenden Dienst sucht.
Laut Spezfikation müssen UDDI-Implementierungen zu diesem Zweck eine SOAP-Schnittstelle zur Verfügung stellen. Diese wird vom UDDI-Gremium mittels WSDL-Dokumenten beschrieben.
Hat der Dienstnutzer einen für sich geeigneten Web Service gefunden, so fordert er die Schnittstellenbeschreibung, also das WSDL-Dokument, an. Der Verzeichnisdienst liefert hierzu eine Referenz (URI) auf das WSDL-Dokument. Das fordert der Dienstnutzer in einem weiteren Schritt an. Anschließend werden mit Hilfe der WSDL-Beschreibung die Programmteile erzeugt, welche die Anwendung des Nutzers in die Lage versetzt, mit der Anwendung des Dienstanbieters via SOAP zu kommunizieren.
Web Services Stack – das Schichtenmodell
Für eine vollwertige SOA-Implementierung müssen mehrere Anforderungen an einen so genannten SOA-Tempel realisiert werden. Diese Anforderungen werden üblicherweise in einem Schichtenmodell oder Stack, dem Web Service Stack, dargestellt.
Der gezeigte Stack in der Abbildung ist nur ein Stack unter vielen möglichen. Die Vielzahl möglicher Varianten lässt sich durch die verschiedenen Interessen und Betrachtungsweisen eines Stacks erklären.
Begonnen wird bei einem Stack üblicherweise auf der untersten Ebene mit der Transportschicht. Dadurch kann ausgedrückt werden, dass Web Services nicht an ein bestimmtes Transportprotokoll gebunden sind. Verwendbar sind ganz unterschiedliche Protokolle wie http oder SMTP, die alle XML-Nachrichten transportieren können.
Die nächste Schicht und damit die Grundlage des gemeinsamen Datenmodells bilden XML- und XML-verwandte Technologien wie Schemata oder Namespaces. Die Protokolle zum Nachrichtenaustausch basieren wie die Nachrichten auf XML. Deswegen findet sich auf der folgenden Protokoll-Schicht die SOAP-Spezifikation. Sie beschreibt die Struktur und Semantik der zu verwendenden XML-basierten Nachrichten.
Die fünfte Schicht Federation and Routing verfeinert die bislang erwähnten Konzepte für den Einsatz in verteilten Systemumgebungen und regelt das Zusammenspiel unterschiedlicher Spezifikationen untereinander im Kontext jeweils eines Web Services.
Das Zusammenspiel mehrere Web Services wird durch Spezifikationen auf einer weiteren, darüber liegenden Schicht beschrieben: Integration and Coordination. Hierzu dient etwa BPEL („Business Process Execution Language“), mit der es möglich ist, Prozesse zu modellieren und aus einzelnen Aufgaben eine komplexe Anwendung entstehen zu lassen.
Essentiell sind bei Web Services immer Transaktionseigenschaften. Sie können mit geeigneten Spezifikationen beschrieben werden. Solche zusätzlichen Eigenschaften finden sich im Web Service Stack flankierend in einer vertikalen Metadaten-Komponenten wieder. Auf der Seite gegenüber fasst eine Quality-of-Service-Komponente die bisherigen Schichten ein.
Den Abschluss der Schichten bilden die Enterprise- oder Grid-Komponenten, auf die hier aus Platzgründen nicht weiter eingegangen wird.
Architektur: Nachrichten-, Service-, Ressourcen-, Richtlinien-Modell
In der W3C-Spezifikation werden Web Services aus unterschiedlichen Perspektiven beschrieben: Einem Policy Model, einem Resource Oriented Model, einem Message Oriented Model und einem Service Oriented Model.
Die folgende Grafik zeigt das Message Oriented Model (Web Services Nachrichten). Mit diesem Modell wird der Aufbau einer Web Services Nachricht festgelegt, dessen Beziehung zu einem Agenten und wie eine Nachricht zugestellt wird. Die Kästen stehen für Konzepte, die über gerichtete Graphen miteinander in Beziehung stehen. Dass SOAP als Nachrichtenformat genutzt wird, ist dabei nicht zwingend vorgeschrieben, allerdings sollte man es tunlichst verwenden.
Die nächste Grafik zeigt das Web Services Modell mit Schwerpunkt Serviceorientierung. Services sind Aktivitäten in einer Web-Services-Architektur. Ein Service wird dabei mit Hilfe eines Agenten realisiert. Beschrieben wird ein Service über ein Service-Interface, wie etwa mit WSDL.
Das Architekturmodell der Ressourcen in der nächsten Grafik beschreibt, wie eine Ressource in einer Web-Services-Architektur definiert ist. Dabei ist eine typische Ressource in der Web-Services-Architektur wiederum ein Web-Service. Mit dem Modell wird festgelegt, dass eine Ressource eindeutig über eine URI („Uniform Resource Identifier“) identifiziert ist. Für einen Web Service, der mit http zu erreichen ist, wäre dies eine URL.
Das letzte Modell ist das Richtlinien- oder Policy-Modell. Es beschreibt den Aufbau von Richtlinien in einer Web-Services-Architektur. Eine Richtlinie ist alles, was Einschränkungen oder Bedingungen definiert. Beispiele für solche Policies sind Sicherheitsaspekte oder Qualitätsmerkmale. Meist werden Policies mit XML-Erweiterungen einem Web-Service hinzugefügt.
Fazit
Web Services sind ihren Kinderschuhen entwachsen. Zahlreiche Unternehmen befassen sich zurzeit mit Web Services und arbeiten an ihrer Verwirklichung. Produktive Ansätze in Form von Standards und Spezifikationen, die gewährleisten, dass die weitere Entwicklung koordiniert weitergeführt wird, wurden bereits geschaffen. Die XML-Basis sorgt für eine starke Integration und hohe Flexibilität.
Dennoch haben Web Services auch mit Problemen zu kämpfen. So leidet das Ansehen darunter, dass es eine schwer überschaubare Anzahl von über Hundert Spezifikationen gibt, die sich zum Teil überlappen und in manchen Fällen auch widersprechen. Unternehmen sehen sich damit der Gefahr ausgesetzt, auf eine falsche Spezifikation zu setzen. Hier heißt es derzeit, Augen offen halten, denn in der aktuellen Situation bilden sich die Spezifikationen heraus, die sich langfristig durchsetzen werden. (ala)
|
Teil 1 |
|
|
Teil 2 |