Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1. Einleitung
2. Web-Services
2.1 Das Konzept einer Serviceorientierten Architektur (SOA)
2.2 Einführung in Web-Services
2.3 Extensible Markup Language (XML)
2.4 Simple Object Access Protocol (SOAP)
2.4.1 Entfernte Methodenaufrufe
2.5 Web-Service Description Language (WSDL)
2.6 Universal Description, Discovery and Integration (UDDI)
2.6.1 UDDI-Informationsklassen
2.6.2 UDDI-Datenmodell
2.6.3 UDDI-API
2.7 Einbindung von Web-Services
2.7.1 Statisch
2.7.2 Dynamisch
3. Dienstgüte
3.1 Zentrale Begriffe
3.1.1 Dienstgüte
3.1.2 Dienstgüte-Parameter
3.1.3 Metrik
3.1.4 Instrumentierung
3.2 Allgemeine Dienstgütetypen
3.2.1 Garantierte Dienste
3.2.2 Vorhersagbare Dienste
3.2.3 Best-Effort-Dienste
3.2.4 Zusammenhang zu Web-Services
3.3 Voraussetzungen einer Dienstgüte-Infrastruktur für Web-Services
3.3.1 Dienstgüte-Kriterien
3.3.2 Spezifikationssprache (QoS-Specification)
3.3.3 Messung (Measurment)
3.3.4 Auffindungsmechanismus (QoS-Discovery)
3.3.5 Vereinbarungen der Dienstgüte (Service-Level-Agreement)
3.3.6 Überwachung (Monitoring)
4. Service-Level-Agreement
4.1 Zentrale Begriffe
4.1.1 Dienstgüteziel
4.1.2 Dienstklasse
4.1.3 Domäne
4.1.4 Dienstgarantie
4.1.5 Dienstgütevereinbarung
4.2 Anforderungen an das Service-Level-Agreement Service-Level-Agreements für Web-Services
4.4 Erweiterungen des WSDL-Schemas
4.4.1 Web-Service Offerings Language (WSOL)
4.4.2 Language for Defining Service Level Agreements (SLAng)
4.5 Erweiterungen von UDDI
4.5.1 UDDI eXtension (UX)
4.5.2 UDDIe
4.6 Frameworks
4.6.1 Web Service Level Agreement (WSLA) Framework
5. Schlussbetrachtung
Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 1: SOA Dreieck (vgl. [1])
Abbildung 2: Struktur eines WSDL-Dokumentes (Eigene Darstellung)
Abbildung 3: UDDI-Datenmodell (Eigene Darstellung)
Abbildung 4: UDDI-Architektur (Eigene Darstellung)
Abbildung 5: Statische Einbindung von Web-Services (Eigene Darstellung)
Abbildung 6: Dynamische Einbindung von Web-Services (vgl. [3])
Abbildung 7: Struktur eines Service-Level-Agreement (Eigene Darstellung)
Abbildung 8: UDDI eXtension – Architektur und Ablauf (vgl. [4])
Abbildung 9: Struktur und Inhalt eines WSLA-Dokuments (vgl. [5])
Tabellenverzeichnis
Tabelle 1: Elemente eines WSDL-Dokumentes (Eigene Darstellung)
Tabelle 2: Anforderungen an die Datenrepräsentation eines SLA (vgl. [1])
Tabelle 3: WSDL Erweiterungen im Rahmen SLA
Tabelle 4: Ansätze für UDDI Erweiterungen
Tabelle 5: Ansätze für Frameworks zum Dienstgüte-Management von Web-Services (Eigene Darstellung)
Tabelle 6: Dienste der WSLA-Überwachungsarchitektur (vgl. [6])
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
Motivation für die Betrachtungen dieser Arbeit bildet die Entwicklung der Kommunikationsformen im Internet. Von der ursprünglichen Mensch-zu-Mensch Kommunikation (z.B. Email) über die Mensch-zu-Maschine Kommunikation (z.B. Nutzung von Web-Applikationen) ist ein weiterer Trend zu erkennen. Der Fokus richtet sich zunehmend auf autonome Maschine-zu-Maschine Kommunikationen. Der Grund dafür ist die Bereitstellung immer mehr Dienste über das Internet. Im Rahmen des Outsourcings von Kompetenzen zielen Unternehmen darauf ab, externe Dienste einfach und ohne menschliche Interaktion in ihre Geschäftsprozesse zu integrieren. Das Problem dabei ist allerdings, dass Dienste meist durch angepasste, proprietäre Lösungen bereitgestellt werden. Somit ist die Aufgabe eine Lösung anzubieten, die es erlaubt bestehende Dienste weiter zu verwenden aber trotzdem möglichst vielen Nutzern in einer heterogenen System-Landschaft die Nutzung zu gewähren. An diesem Punkt setzten Web-Services an. Durch sie werden homogene Kommunikationsmöglichkeiten zwischen Diensten in einer heterogenen System-Landschaft geschaffen. Als Beispiel kann mein ein Online-Reisebüro mit seinen verschiedenen Geschäftspartnern (Kunden, Hotelanbieter, Fluggesellschaften, usw.) betrachten. Die Kunden sollen über das Reisebüro nun Zugriff auf die Daten der Geschäftspartner haben. Anhand dieser Daten müssen Reisebuchungen vorgenommen werden können. Zur Realisierung stehen nun verschiedene Möglichkeiten zur Auswahl. Als erste Variante könnte das Reisebüro eine Datenbank erstellen und alle relevanten Daten der Geschäftspartner darin einpflegen. Als nachteilig kann man den hohen Personalaufwand verbunden mit hohen Personalkosten und Ressourcenaufwand nennen. Als zweite Variante könnte das Reisebüro jede Suchanfrage der Kunden übernehmen und dann die Webseiten seiner Geschäftspartner automatisch zur Ermittlung der angeforderten Daten aufsuchen. Dabei treten zwei wesentliche Probleme auf. Man benötigt entsprechende Netzwerkkapazitäten, um diesen großen Bedarf zu decken. Das größere Problem aber ist, die Interpretation der Webseiten. Durch die gängigen Layouts für Webseiten ist die Semantik für Menschen zwar erkennbar aber geht für Maschinen verloren. Die letzte Variante wäre, dass das Reisebüro Zugriff auf die Datenbanken der Geschäftspartner durch spezielle Middleware erhält. Durch proprietäre Middleware entstehen jedoch hohe Kosten für den Einsatz und die Anpassung. Des Weiteren müssen verschiedene Sicherheitsaspekte beachtet werden. Der Grund dafür ist der direkte Zugriff auf wichtige Daten der Geschäftspartner. Unter diesen Aspekten ist der Einsatz von Web-Services angebracht. Da sich aber das Einsatzgebiet von Web-Services oft auf unternehmenskritische Workflows einzelner Geschäftsprozesse bezieht, muss zusätzlich das Thema Dienstgüte berücksichtigt werden. In anderen Bereichen[1] ist Dienstgüte schon fest integriert. Die Grundlagen zur Dienstgüte im Bezug auf Web-Services sollen nun in den folgenden Ausführungen betrachtet werden.
Im ersten Kapitel sollen zunächst Web-Services allgemein betrachtet werden. Inhaltlich werden dabei Grundlagen und die wesentlichen Basisstandards behandelt. Weiterhin wird gezeigt, wie Web-Services bei der Anwendungsentwicklung eingebunden werden können. Kapitel 2 wendet sich dann konkret der Dienstgüte für Web-Services zu. Im Vordergrund stehen dabei konkrete Kriterien, nach denen die Güte eines Web-Service beurteilt werden kann. Zusätzlich werden die Grundvoraussetzungen zum Aufbau einer Dienstgüte-Infrastruktur dargestellt. Anschließend beschäftigt sich Kapitel 3 mit konkreten Vereinbarungen zwischen Anbietern und Nutzern von Web-Services. Dabei soll gezeigt werden, wie Vereinbarungen aufgebaut sind und wie man die grundlegenden Kriterien der Dienstgüte als Basis für solche Vereinbarungen spezifizieren kann. Kapitel 5 letztendlich enthält eine allgemeine Auswertung der Thematik.
2. Web-Services
2.1 Das Konzept einer Serviceorientierten Architektur (SOA)
Ausgangspunkt von Web-Services ist das Konzept einer Service-orientierten Architektur (SOA). Den Anfang soll dazu die Definition einer SOA machen. Dabei ist zu beachten, dass verschiedene Definitionen existieren und man sich bis jetzt auf keine allgemein Gültige geeinigt hat.
"Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachunabhängige Nutzung und Wiederverwendung ermöglicht."[2]
Bei einer SOA handelt es sich um ein abstraktes Konzept einer Software-Architektur. Auf die Angabe von Details zur Implementierung wird verzichtet. Das Konzept wird dadurch von konkreten Technologien entkoppelt, ist langlebig und bleibt flexibel anpassbar bzw. erweiterbar. Zentrum einer SOA ist das Anbieten, Suchen und Nutzen von Diensten. Die gesamte Kommunikation innerhalb der Architektur erfolgt dabei vollautomatisiert zwischen Maschinen und ist nachrichtenbasiert. Der Mensch wird aus den Betrachtungen ausgeschlossen, auch wenn er der Initiator mancher Maschine-Maschine Kommunikationen ist und ihm die Ergebnisse eines Dienstes eventuell sogar über ein Frontend ausgegeben werden.
Die zentrale Komponente einer SOA sind Dienste. Ein Dienst ist dabei eine Software-Komponente durch die eine bestimmte Leistung erbracht wird. Die konkrete Implementierung des Dienstes findet aber keine Beachtung innerhalb einer SOA. Es gilt das Prinzip der Kapselung[3]. Das Konzept einer SOA setzt nach der Implementierung an.
Ein Dienstanbieter muss nach der Implementierung das Deployment[4] durchführen, eine Dienstbeschreibung erstellen und den Dienst mit seiner Beschreibung veröffentlichen. In einer Dienstbeschreibung werden alle funktionalen[5] und auch nicht-funktionale[6] Anforderungen untergebracht. Die dafür zu verwendende Beschreibungssprache muss auf offenen Standards basieren. Dadurch wendet man sich von proprietären Lösungen ab und vermeidet die Entstehung von heterogenen Diensten. Um eine automatisierte Verarbeitung der Beschreibung zu ermöglichen, muss die Dienstbeschreibung in maschinenlesbarer Form vorliegen.
Nachdem Dienste bereitstehen und beschrieben sind, werden sie veröffentlicht. Zu diesem Zweck existiert ein Dienstverzeichnis. In diesem Verzeichnis findet man durch Dienstanbieter registrierte Dienste, inklusive spezifischer Informationen. Dieses Verzeichnis ist selbst als Dienst implementiert, sodass man es wie jeden anderen Dienst auch über standardisierte Schnittstellen ansprechen kann. Dienstanbieter registrieren aktiv ihre Dienste in diesem Verzeichnis. Die Dienste stehen danach einer bestimmten Nutzergruppe[7], nach bestimmten Kategorien und Kriterien klassifiziert, zur Verfügung.
Ein potentieller Dienstnutzer tritt mit dem Verzeichnisdienst in Verbindung und sucht einen passenden Dienst. Als Ergebnis liefert der Verzeichnisdienst eine Referenz auf die Dienstbeschreibung. Anhand dieser Information lässt sich der Dienstnutzer die konkrete Dienstbeschreibung liefern und erfährt dadurch, wie er den Dienst nutzen kann. Der Dienstnutzer kann die Leistung des Dienstes nun korrekt in Anspruch nehmen.
Zusammenfassend können einige Dinge festgehalten werden. Beteiligte an einer SOA nehmen entweder die Rolle des Dienstanbieters (Provider), des Dienstnutzers (Requestor) oder des Dienstvermittlers (Broker) ein. Die typischen Aktionen innerhalb einer SOA bezüglich der Dienste sind die Veröffentlichung, die Suche[8], die Interaktion und die dynamische Bindung[9]. Ein weiteres Merkmal ist die Verwendung offener Standards bei der Kommunikation innerhalb einer SOA und der Dienstbeschreibung. Dadurch wird die Interoperabilität und Plattformunabhängigkeit in einer SOA gewährleistet.[10]
Ziel ist die Realisierung sicherer Transaktionen[11] in den verteilten Systemen, die durch Implementierung einer SOA entstehen. Die Abbildung 1 zeigt abschließend die Architektur und den generellen Kommunikationsablauf einer SOA.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: SOA Dreieck (vgl. [1])
Mit den hier gezeigten Aspekten ist das Konzept einer SOA allerdings noch nicht vollständig beschrieben.[12]
2.2 Einführung in Web-Services
Ein Web-Service ist nun eine konkrete Implementierung einer SOA. Die hohe Bedeutung von Web-Services hängt mit dem Stand der Entwicklung zusammen. Web-Services dürften "die einzige halbwegs fortgeschrittene Technik zur Implementierung einer Service-orientierten Architektur sein".[13] Den Anfang soll eine Definition von Web-Services bilden, die dem World Wide Web Consortium[14] (W3C) entnommen wurde und alle wesentlichen Aspekte von Web-Services bezogen auf SOA darstellt.
"A Web service is a software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."[15]
[...]
[1] z. B. bei Middleware
[2] [1], S.11
[3] Verbergen der Implementierung eines Dienstes; Zugriff über klar definierte Schnittstellen
[4] Bereitstellung einer Plattform in einem Netzwerk, Konfiguration, Betrieb, Wartung usw.
[5] Schnittstellenbeschreibung
[6] z.B. Kriterien der Dienstgüte
[7] Hängt von der Zugänglichkeit des Verzeichnisdienstes ab
[8] Dynamisch zur Laufzeit
[9] Integration einer Dienstleistung zur Laufzeit
[10] Vgl. [1]
[11] Durch Orchestration einzelner Dienste
[12] Nähere Erläuterungen finden sich in [1]
[13] [1], S. 23
[14] Gremium zur Standardisierung von WWW Techniken
[15] [15]