Dienstgüteunterstützung für Web Services

Transkript

1 Freie Universität Berlin Institut für Informatik Technische Informatik & Telematik Dienstgüteunterstützung für Web Services Wissenschaftliche Hausarbeit im Fach Informatik vorgelegt von Andreas Gramm Matrikelnummer betreut durch Prof. Dr.-Ing. habil. Jochen H. Schiller und Dipl.-Inform. Min Tian August 2003

2 KURZFASSUNG Kurzfassung Die Entwicklung von Web Services zur effizienten Abwicklung von Geschäftsvorgängen über das Internet hat in jüngster Zeit enorm an Bedeutung gewonnen. Mit dem Bereitstellen zahlreicher Web Services äquivalenter Funktionalität stellt sich die Frage, welchen Dienst ein Benutzer aus dem bestehenden Angebot auswählt. In diesem Zusammenhang erscheint es sinnvoll, die Dienstgüte, mit der ein Dienst erbracht wird, in die Entscheidung einzubeziehen. Hierbei ist zu beachten, dass unterschiedliche Benutzer eines Dienstes diesbezüglich verschiedene Anforderungen stellen. Die Analyse bisheriger Ansätze zur Dienstgüteunterstützung für Web Services zeigt, dass bislang kein Mechanismus existiert, Dienste dynamisch unter Berücksichtigung der zugesicherten Dienstgüte auszuwählen. Nach einer Diskussion relevanter Dienstgüteparameter und Mechanismen zur Sicherung und Differenzierung von Dienstgüte werden in dieser Arbeit Anforderungen für ein an Dienstgüte orientiertes dynamisches Auffinden von Diensten vorgestellt und eine Erweiterung der bestehenden Web Services Architektur vorgeschlagen. Mit WS QoS wird ein Konzept vorgestellt, das die geforderte Erweiterung realisiert. Danksagung Ich möchte an dieser Stelle der Arbeitsgruppe Technische Informatik und Telematik für die intensive Betreuung und das Bereitstellen einer sehr angenehmen konstruktiven Arbeitsumgebung herzlich danken. 1

3 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES Inhaltsverzeichnis 1 Einleitung Grundlagen Web Services XML basierter Nachrichtenaustausch über SOAP Dienstbeschreibung in WSDL Dynamisches Auffinden von Diensten mit UDDI Dienstgüte Spezifikation von Dienstgütegarantien Probleme des heutigen Internet Differenzierung von Dienstgüteanforderungen Analyse von Dienstgüteparametern und -Mechanismen Klassische Parameter der Kommunikationstechnologie Verzögerung Verzögerungsschwankung Übertragungszuverlässigkeit Übertragungskapazität Mechanismen zum Erbringen von Transportdienstgüte Bündeln von PPP-Verbindungen Statische Dienstgüteklassen bei ATM und UMTS Reservierung von Ressourcen mittels RSVP bei IntServ Relative Prioritäten für Dienstgüteklassen bei DiffServ Koordination verschiedener Technologien Serverseitige Dienstgüteparameter Bearbeitungszeit Maximaler Anfragen-Durchsatz Zuverlässigkeit Verfügbarkeit Dienstgüteunterstützung in serverseitigen Systemen Dienstgütesicherung durch Lastausgleich Differenzierung von HTTP-Anfragen Differenzierung von Transaktionen bei BizQoS Sicherheit Anforderungen an sichere Kommunikation Verwandte Sicherheitsmechanismen Transaktionsunterstützung Kosten Zusammenfassung Bestehende Ansätze zu Dienstgütemanagement für Web Services Elektronische Dienstgüteabkommen des WSLA Rahmenwerks. 41 2

4 INHALTSVERZEICHNIS Service Level Spezifikation Installation und Überwachung WSML basiertes Dienstgütemanagement Modell zur Spezifikation von Dienstgüteparametern SLA Spezifikation mit WSML Überwachen von Grenzwerten Dynamische Auswahl vordefinierter WSOL Dienst-Klassen Spezifikation von Dienstangeboten Web Service Management Unterstützung Dienstgüteaspekte bei Geschäftsprozessmodellen Zusammenfassung Entwurf dynamischer Dienstauswahl nach Dienstgütekriterien Modellierung einer Web Services Dienstgütespezifikation Erweiterung der Architektur um eine Dienstgütevermittlung Anforderungen an eine mögliche Realisierung Standardisiertes Dienstgütemanagement mit WS-QoS Das WS-QoS XML Schema Der Typ tqosdefinition Der Typ tqosinfo Die WS-QoS Ontologie Dynamische Dienstauswahl des WS-QoS Offer Brokers Das WS-QoS Rahmenwerk für C# / ASP.NET Entwickler Dienstgüte-Spezifizierung mit C# - Custom Attributes Überwachen von Anforderungen mit dem Requirement Manager Überwachung von Angeboten mit dem Offer Manager Einbinden des WS-QoS Offer Broker Editieren von WS-QoS Dateien mit dem WS-QoS Editor Überwachen der Dienstauswahl mit dem WS-QoS Monitor StockQuote - ein Beispiel Erreichtes und verbleibende Herausforderungen Quellenverzeichnis Stichwortverzeichnis Anhang Das WS-QoS XML Schema WSDL-Beschreibung des Standard Stock Quote Dienstes WS-QoS Standard Ontologie UML Klassendiagramm für das WS-QoS API CD mit vorgestellten Anwendungen und Quellcode Eidesstattliche Erklärung

5 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES 1 Einleitung Wie ich auf einem Workshop der IBM zum Thema Web Services erfuhr 1, ließe sich die mit XML Web Services assoziierte Technologie als die bedeutendste Weiterentwicklung der Informatik seit Entwicklung der Objektorientierten Programmierung sehen. Objektorientierung wird auf die Kommunikation im Internet übertragen und von einer Beschränkung auf einzelne Plattformen und proprietäre Protokolle befreit, um eine Allgegenwart von Informationsgebern zu schaffen. Auch wenn dies bislang eine Vision in Forschungslaboren ist und mit CORBA oder RMI ähnliche Konzeptionen bereits zuvor entwickelt wurden, so lässt sich in den jüngsten Ausgaben vieler Fachzeitschriften feststellen, dass Web Services sich auffallend starker Popularität erfreuen. Immer häufiger planen Firmen, ihre Geschäftsbeziehungen mittels der Web Services Technologie zu realisieren, indem sie gegenseitig Dienste für verschiedenste Anwendungen bereitstellen und nutzen. Inzwischen haben sich das XML basierte Kommunikationsprotokoll SOAP und die Dienstspezifikationssprache WSDL zu zuverlässigen Standards entwickelt. Doch der Erfolg von Web Services wirft eine zentrale Frage für den Benutzer auf: Welchen Dienstanbieter wähle ich? Um den schnellen Veränderungen des weltweiten Angebots elektronischer Dienstleistungen im Internet gerecht zu werden, wurde mit UDDI ein Konzept entwickelt, Web Services dynamisch zur Laufzeit zu finden und in den Ablauf einer Anwendung zu integrieren. Ein UDDI Verzeichnisdienst ermöglicht ein automatisiertes Auffinden von Diensten, die eine bestimmte Schnittstelle in Form einer abstrakten Dienstbeschreibung (Interface) implementieren. Die letztendliche Auswahl des Dienstes ist bislang jedoch nicht automatisiert und muss in einer Anwendung individuell realisiert werden. Nach welchen Kriterien die Auswahl erfolgt ist also nicht festgelegt. Werden mehrere Dienste äquivalenter Funktionalität angeboten, so wird die Dienstgüte, mit der diese erbracht wird, ein entscheidender Faktor zur Unterscheidung von Unternehmen [vgl. Mani02]. Es geht aber nicht nur 1 Workshop Introduction to Web Services, veranstaltet vom IBM Solution Partnership Center Paris, Mai

6 EINLEITUNG darum, ein möglichst hohes Maß an Dienstgüte zu liefern: Benutzer auf unterschiedlichen Plattformen (PC, PDA, Mobiltelefon, etc.) mit unterschiedlichen Netzanbindungen (LAN, Modem, Funk, etc.) haben typischerweise verschiedene Anforderungen an die zu erbringende Dienstgüte. Sinnvoll wäre also eine Differenzierung verschiedener Dienstgüteniveaus mit entsprechend variierenden Kosten [vgl. Menasce02]. Dienstanbieter sollten die Möglichkeit haben, für Benutzergruppen mit verschiedenen Dienstgüteanforderungen einen Dienst in verschiedener Qualität zu verschiedenen Preisen anzubieten. Es gibt jedoch erst wenige Ansätze, von verschiedenen Diensten erbrachte Dienstgüte in einer standardisierten Form zu beschreiben, was eine Voraussetzung für eine automatisierte Dienstauffindung unter Berücksichtigung der Dienstgüte ist. Mit DiffServ, IPQoS und Dienstgüteklassen in ATM, UMTS oder RCL stehen uns heute Technologien zur Verfügung, um Dienstgüte in Netzwerken zu differenzieren. Lastausgleich, Transaktionsdifferenzierung und Differenzierung von HTTP Anfragen bieten die Möglichkeit auch im System einzelner Web Services verschiedene Dienstgüteklassen zu unterscheiden. Was fehlt, sind Mechanismen, um ein gewünschtes Niveau an Dienstgüte auf der Ebene einer Anwendung zu formulieren. Um diese Lücke zwischen der Ebene der Web Services und den Dienstgüteunterstützungsmechanismen für zugrunde liegende Technologien zu schließen, habe ich ein XML Schema entwickelt, mit dem sowohl benutzerseitige Dienstgüteanforderungen als auch Dienstgüteangebote von Dienstanbietern in standardisierter Form definiert werden können. So können Anforderungen und verfügbare Angebote automatisch verglichen werden. Ein Dienstgüteangebot kann in diesem Zusammenhang als eine von mehreren möglichen Dienstgüteklassen (Classes of Service (CoS)) gesehen werden, wie sie in Mechanismen zur Dienstgütedifferenzierung in Netzwerktechnologien wie DiffServ oder ATM verwandt werden. Ihre Struktur ist jedoch komplexer und dynamischer als die statischer Dienstklassen. Auf Grundlage dieser Spezifikation schlage ich eine Erweiterung der bestehenden Web Services Architektur vor, die eine an Dienstgüte orientierte 5

7 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES dynamische Dienstauswahl ermöglicht. In einer Erweiterung der Dokumentationssprache WSDL werden standardisierte Dienstgüteangebote deklariert. Ein Vermittlungsdienst ermittelt nun von allen Diensten, die ein von einem Benutzer angefragtes Interface implementieren, das kostengünstigste Dienstgüteangebot, das die Dienstgüteanforderungen des Clients erfüllt. Ein von mir entwickeltes Rahmenwerk für die C# / ASP.NET Entwicklungsumgebung bietet die Möglichkeit, Dienstgüteanforderungen auf einfache Weise auf einem Service Proxy Objekt zu deklarieren, die dann in einem automatisierten Prozess der Dienstauffindung berücksichtigt werden. Abbildung 1 gibt einen Überblick über die Entwicklung des Konzepts in dieser Arbeit und die Kapitel, die die entsprechende Stufe behandeln. Die Arbeit ist wie folgt gegliedert: Nach einer Einführung in die Grundlagen von Web Services und Dienstgüte in Kapitel 2 werden in Kapitel 3 relevante Parameter und Ansätze zur Umsetzung von Dienstgüteunterstützung in Netzwerkkomponenten und Serversystemen analysiert. In Kapitel 4 werden aktuelle Ansätze zur Umsetzung von Dienstgüte für Web Services mittels Service Level Agreements (SLA) diskutiert. Kapitel 5 diskutiert die Erweiterungen der Web Services Architektur, die notwendig sind, um eine an Dienstgüte orientierte dynamische Dienstauswahl zu erreichen. Kapitel 6 stellt mit WS QoS eine Realisierung der geforderten Erweiterung vor. Kapitel 7 fasst schließlich das Erreichte zusammen und gibt einen Überblick auf verbleibende Herausforderungen. Analyse Kapitel 3 und 4 Entwurf Kapitel 5 Implementierung Kapitel 6 Abbildung 1. Analyse - Entwurf - Implementierung 6

8 GRUNDLAGEN 2 Grundlagen Dieses Kapitel erläutert die dieser Arbeit zugrunde liegenden Begriffe und Konzepte. Abschnitt 2.1 führt in die Web Services Technologie ein. Abschnitt 2.2 gibt zunächst eine Definition von Dienstgüte und beschreibt dann Aspekte aktiver Dienstgüteunterstützung. 2.1 Web Services XML Web Services bieten eine neue Technologie der verteilten Programmierung. Es werden vor allem zwei Ziele verfolgt. Zum einen sollen Web Services die elektronische Interaktion zwischen Unternehmen (businessto business) durch ein netzbasiertes Programmieren von Diensten über die Grenzen heutiger Firewalls hinweg fördern. Der andere Bereich ist die Integration von Anwendungen auf verschiedenen Plattformen innerhalb eines Unternehmens (application integration), um Geschäftsabläufe zu vereinfachen und effizienter zu machen. Das größte Potential von Web Services ist ein hohes Maß an Plattformunabhängigkeit durch die Kodierung von Daten in der Extensible Markup Language [XML]. Abbildung 2. Dynamisches Auffinden von Diensten über ein Dienstverzeichnis [vgl. Kreger01]. Die konzeptionelle Architektur der Web Services Technologie sieht die Interaktion von drei Hauptkomponenten vor [vgl. Kreger01]. Abbildung 2 zeigt die drei Hauptkomponenten dieser Web Services Architektur und die drei Schritte einer dynamischen Dienstanbindung. Stellt ein Dienstanbieter 7

9 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES einen neuen Dienst bereit, so registriert er diesen in einem Dienstverzeichnis (Schritt 1). Hier kann auch die Beziehung zu bereits registrierten abstrakten Dienstspezifikationen (service interfaces) hergestellt werden. Ein weiterer Eintrag verweist auf die Dienstbeschreibung des neu registrierten Dienstes. Für eine Benutzeranwendung kann nun ein Dienstnehmer das Dienstverzeichnis nach entsprechenden Diensten befragen (Schritt 2). Hat sich der Dienstnehmer für einen Dienst aus der Liste der möglichen Dienste entschieden, so kann er ihn aufgrund der gelieferten Informationen direkt aufrufen (Schritt 3). Architekturen wie CORBA, DCOM oder RMI verfolgen sehr ähnliche Ziele, unterscheiden sich aber in deren Realisierung. Während hier oft proprietäre binäre Protokolle benutzt werden, baut die Web Services Technologie auf überall verfügbare Web Standards wie HTTP und XML auf. Dies bedeutet einen weitaus geringeren Aufwand für die Realisierung auf einer bereits bestehenden Infrastruktur. D i s c o v e r y U D D I S p e z i f i k a t i o n W S D L T r a n s p o r t S O A P Abbildung 3. Web Services Standard Protokolle Drei Standards bilden den Kern der Web Services Technologie und sollen im Folgenden beschrieben werden. Abbildung 3 gibt einen Überblick: Web Services werden in WSDL beschrieben und über UDDI gefunden, um dann durch den Austausch von Nachrichten in XML Format über das SOAP Protokoll mit ihnen zu kommunizieren. Durch Standards wie WS Security, WS Transaction oder WS Policy wird das Konzept der Web Services entsprechend der Global XML Web Services Architecture (GXA) um wichtige Funktionalitäten erweitert XML basierter Nachrichtenaustausch über SOAP Das vom W3C standardisierte Simple Object Access Protocoll [SOAP] ist ein Protokoll für den Austausch in XML kodierter Daten. Über SOAP lässt sich verteilte Programmierung mittels Remote Procedure Calls realisieren. Der größte Vorteil von SOAP ist, dass es HTTP als Transportprotokoll nutzen 8

10 GRUNDLAGEN kann und SOAP Anfagen die üblichen Firewalls durchqueren. Kapitel 3.5 zeigt, dass dadurch jedoch Sicherheitsprobleme entstehen, die durch weitere Mechanismen zu lösen sind. Darüber hinaus ist SOAP bereits weit verbreitet, es existieren zahlreiche Implementierungen für alle gängigen Betriebssysteme. POST /MultiplyOnline/SimpleService.asmx HTTP/1.1 Host: lab3.pcpool Content-Type: text/xml; charset=utf-8 Content-Length: 523 SOAPAction: " <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:header> <wsse:security xmlns:wsse= > <wsse:username>gramm</wsse:username> <wsse:password type= wsse:passworddigest >3bsx_07A</wsse:Password> </wsse:security> </soap:header> <soap:body> <Square xmlns =" <input>4</input> </Square> </soap:body> </soap:envelope> Abbildung 4. SOAP Nachricht mit HTTP-Header zum Aufruf der Operation Square des Dienstes MultiplyOnline. Eine SOAP Nachricht ist selbst ein XML Dokument. Sie besteht aus einem Umschlag (envelope), der einen Kopf (header) und einen Rumpfteil (body) enthält. In dem Nachrichtenkopf können Informationen transportiert werden, die nicht für die eigentliche Funktionalität relevant sind, wie zum Beispiel eine Authentifizierung des Aufrufenden. Im Rumpfteil werden die eigentlichen Parameter und Rückgabewerte übermittelt. Abbildung 4 und Abbildung 5 zeigen die SOAP Nachrichten für Aufruf und Antwort eines Beispieldienstes MultiplyOnline auf dem die Operation Square(input) aufgerufen wird. Sie werden als Payload von HTTP Pakten transportiert. 9

11 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: 312 <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <SquareResponse xmlns =" <SquareResult>16</SquareResult> </SquareResponse> </soap:body> </soap:envelope> Abbildung 5. SOAP Nachricht mit HTTP-Header für das Ergebnis des obigen Aufrufs Dienstbeschreibung in WSDL Die vom W3C veröffentlichte XML basierte Web Services Description Language [WSDL] bietet eine Möglichkeit, die Funktionalität eines Web Service detailliert und doch plattformunabhängig zu spezifizieren. Ein Dienst wird in einer WSDL Dienstbeschreibung durch ein Service Element beschrieben, das mehrere Endpunkte in Form von Port Elementen zur Verfügung stellt. Ein solcher Port assoziiert einen konkreten Dienstzugangspunkt (die URL des Dienstes) mit einem abstrakten Binding. Dies wiederum beschreibt die Anbindung des Dienstes an ein Kommunikationsprotokoll, indem es eine Auflistung von Operation Elementen eines abstrakten PortType Elements mit Angaben darüber verbindet, wie diese Operationen über ein bestimmtes Protokoll aufzurufen sind. Eine Operation setzt sich zusammen aus Elementen des Typs Message, das in Part Elementen Angaben über zulässige Parametertypen macht. Es lassen sich auch abstrakte Dienstbeschreibungen ohne Angabe eines Service Tags spezifizieren. So entsteht eine Schnittstelle (Interface), die von verschiedenen konkreten Diensten realisiert wird, die dem Entwickler des Interfaces nicht bekannt sein müssen Dynamisches Auffinden von Diensten mit UDDI Universal Description, Discovery and Integration [UDDI] realisiert ein Verzeichnis für Web Services. Der Verzeichnisdienst ist selbst als Web Service realisiert und stellt jeweils ein API zur Abfrage und Aktualisierung von 10

12 GRUNDLAGEN Informationen bereit. Dienstanbieter werden in UDDI als Business verwaltet. Für einen Anbieter können als Service Einträge mehrere Dienste registriert werden. Abstrakte Dienstbeschreibungen werden in Form eines so genannten TModels registriert, für das die URL der WSDL Datei angegeben wird, die das TModel definiert. In dem ServiceInstance Eintrag einer konkreten Implementierung lassen sich nun sowohl die Referenz eines TModels als auch die URL der erweiterten konkreten Dienstbeschreibung angeben. Gesucht werden kann nach Dienstanbietern, Diensten oder TModels. Als Suchparameter für Dienste lassen sich nun eine Menge von Dienstanbietern und/oder Service Interfaces angeben. Dienste können zum Zeitpunkt der Implementierung gesucht und dann hart kodiert werden. Eine flexiblere Lösung bietet eine dynamische Dienstauswahl, bei der für die Implementierung lediglich von einem TModel ausgegangen wird. Die Strategie zur Auswahl eines Dienstes aus der Liste möglicher Dienste ist in der Benutzeranwendung selbst zu realisieren. Im Zusammenhang der Integration von Anwendungen ist auch ein Szenario denkbar, in dem alle verfügbaren Dienste aufgerufen werden. Ein Beispiel hierfür wäre die Abfrage von Umsatzdaten für verschiedene Abteilungen innerhalb eines Unternehmens. Wird hier UDDI eingesetzt, so lassen sich ohne Veränderung der Anwendung beliebig Filialen hinzufügen oder schließen [vgl. Janus02]. Eine der größten Stärken von UDDI ist derzeit auch ein Schwachpunkt: Ohne jegliche Überprüfung können Dienstanbieter Einträge einem öffentlichen UDDI Verzeichnisdienst hinzufügen. Heute existiert daher ein großer Anteil unzuverlässiger Einträge, was die Benutzung von UDDI faktisch auf private Verzeichnisdienste beschränkt. Mit der Web Services Inspection Language [WSIL] wurde daher ein alternativer Ansatz entwickelt, mit einer einfachen Dateistruktur Web Services eines einzelnen Anbieters zu beschreiben [Modi02]. Im Root Verzeichnis des Web Servers eines Unternehmens befindet sich eine Datei inspection.wsil, in der alle angebotenen Web Services aufgelistet sind. Durch Link Elemente lassen sich weitere WSIL Dateien einbinden und so die Deklaration von Web Services 11

13 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES hierarchisch verteilen. 2.2 Dienstgüte In der ITU Empfehlung ITU T E.800 [ITU T94] wird Dienstgüte als die vollständige Wirkung der Leistungsfähigkeit eines Dienstes beschrieben, die den Grad der Zufriedenheit eines Benutzers desselben Dienstes bestimmt. Aspekte für das Erbringen von Dienstgüte durch technische Systeme sind zum Beispiel seine Robustheit, das heißt wie zuverlässig und wie oft verfügbar er ist, seine Skalierbarkeit, das heißt wie viele Anforderungen pro Zeiteinheit ohne Beeinträchtigung der Dienstgüte bearbeitet werden oder die durchschnittliche Verzögerung, die durch Inanspruchnahme des Dienstes entsteht. Eine detaillierte Beschreibung von Dienstgüteparametern auf verschiedenen Protokollebenen wird in Kapitel 3 gegeben. Dienstgüte lässt sich in verschiedenen Dimensionen analysieren. So lässt sich zum einen zwischen benutzerseitigen Dienstgüte Parametern und solchen, die ein Dienstanbieter selbst einfordert, unterscheiden. Ein Benutzer kann zum Beispiel die Einhaltung gewisser maximaler Antwortzeiten für den Aufruf eines Dienstes fordern. Ein Beispiel für einen anbieterspezifischen Dienstgüteparameter wäre die maximale Anzahl bearbeiteter Anfragen für einen Dienst, die über den Erfolg eines E Kommerz Unternehmens entscheidend sein kann. Konkrete Aspekte von Dienstgüte beschränken sich oft auf eine bestimmte Protokollebene. Während zum Beispiel Verzögerungswerte stark von der Bereitstellung entsprechender Systemkomponenten abhängig sind, so werden Sicherheitsaspekte wie etwa die Verschlüsselung von Daten meist auf höheren Schichten vorgenommen Spezifikation von Dienstgütegarantien Je nach Situation können Dienstgütegarantien entweder als statische Grenzwerte oder relative Prioritäten angegeben werden. Für einen Dienstgüteparameter können konkrete Grenzwerte deklariert werden, deren Einhaltung für einen bestimmten Anteil der Betriebszeit garantiert wird. Eine typische statische Dienstgütegarantie wäre zum Beispiel die Aussage, dass die Antwortzeit eines Dienstes für 98% aller Anfragen unter 5 ms liegt. In anderen Fällen ist dagegen eine relative Unterscheidung sinnvoll. Hier 12

14 GRUNDLAGEN können statistische Dienstgüteklassen definiert werden. So ließen sich drei Klassen Gold, Silber und Bronze folgendermaßen definieren: Silber liefert eine doppelt so hohe Dienstgüte wie Bronze und Gold entsprechend das fünffache Niveau von Bronze. Diese Verhältnisse könnten nun zum Beispiel als Gewichte für das Bedienen von drei Warteschlangen benutzt werden, indem jeweils ein Paket der Schlange für Bronze, zwei Pakete der Schlange für Silber und, wenn vorhanden, fünf Pakete der Warteschlange für die Dienstgüteklasse Gold bearbeitet werden Probleme des heutigen Internet Aufgrund der wachsenden Beliebtheit und Vielfalt von Internet Anwendungen wird Dienstgüte ein entscheidendes Thema, vor allem im Bereich des E Kommerz. Die Forderung nach Dienstgüte bewirkt jedoch Anforderungen an das Internet, die kaum zu erfüllen sind, weil sie jenseits seiner ursprünglichen Entwurfsziele liegen [vgl Vasil00]. Heutige Nutzer des Internet erfahren nur eine sehr grobe Zuteilung von Diensten verschiedener Güte, wie zum Beispiel die Entscheidung, ob ein PC über DSL oder ein herkömmliches Modem angeschlossen wird. Das Internet Protokoll (IP) ist nicht verbindungsorientiert und bietet somit lediglich eine Best Effort Situation. Darüber liegende Protokolle wie TCP oder HTTP nehmen das Verlieren von Informationen in Kauf und implementieren Gegenmaßnahmen wie die wiederholte Anforderung bei nicht Erhalten einer Ressource, die auf Kosten der Effizienz angebotener Dienste gehen. Eine Garantie für die Erbringung eines Dienstes innerhalb bestimmter Dienstgüteparameter ist bislang nicht möglich. Immer wieder wird den Bemühungen um Dienstgütedifferenzierung das Argument der Bereitstellung überdimensional leistungsfähiger Systeme (over provisioning) entgegengestellt. Es bestehen jedoch nach wie vor finanzielle Grenzen, und die steigende Nachfrage nach Internetdiensten bewirkt, dass auch die leistungsstärksten Systeme in einer absehbaren Zeit überlastet sein werden. Es gilt also eine systematische Veränderung der Situation zu bewirken. 13

15 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES Differenzierung von Dienstgüteanforderungen Heutige Anwendungen im Internet unterscheiden sich immer stärker in ihren Dienstgüteanforderungen. Ein Dateitransfer mit FTP zum Beispiel reagiert sensibel gegenüber den Verlust von Daten, nicht aber hohen Verzögerungen. Voice over IP Internet Telephonie dagegen kann einen gelegentlichen Verlust von Daten durch eine mindere Wiedergabequalität kompensieren, hat aber harte Echtzeitanforderungen bezüglich der Verzögerung. Multimediaanwendungen wie Streaming Video benötigen sowohl eine hohe Bandbreite als auch niedrige Werte für Verzögerung und Verzögerungsschwankung, um ihre sequentiellen Daten in Echtzeit wiederzugeben. Die Heterogenität von Anwendungen führt zu der Forderung nach einer Differenzierung von Dienstgüte [vgl. DaSilva00]. Bei steigender Belastung von Ressourcen durch erhöhten Verkehr gewinnt zunehmend auch die Bedarfsorientierung an Bedeutung, das heißt ob sich die Dienstgüte an den Erwartungen der Benutzer orientiert [vgl. Ritter01]. Gewünscht ist also nicht generell ein hohes Maß an Dienstgüte, sie sollte den individuellen Anforderungen angepasst sein. Auf der Basis von Interviews [Simar01] wurden vor allem zwei Felder identifiziert, in denen eine Differenzierung von Dienstgüte am dringendsten benötigt wird. Dies sind Verzögerung und Verzögerungsschwankung für Zeit sensible Anwendungen wie zum Beispiel Internet Telephonie und Übertragungskapazität für Anwendungen die große Datenmengen transportieren wie zum Beispiel Streaming Video. Es erscheint daher sinnvoll, Datenströme für Anwendungen mit ähnlichen Dienstgüteanforderungen zu bündeln und nach einheitlichen Regeln für Dienstgütemanagement zu behandeln. Kapitel 3 stellt Mechanismen vor, die dieses Problem zu lösen versuchen. 14

16 ANALYSE VON DIENSTGÜTEPARAMETERN UND -MECHANISMEN 3 Analyse von Dienstgüteparametern und -Mechanismen Um Dienstgüte für Web Services diskutieren zu können, bedarf es zunächst der Kenntnis relevanter Dienstgüteparameter der zugrunde liegenden Technologien sowie der derzeitigen Möglichkeiten, durch aktive Einflussnahme auf diese Parameter verschiedene Niveaus an Dienstgüte zu unterscheiden. Die gesamte Dienstgüte für eine Kommunikation setzt sich aus der Dienstgüte der benutzten Transporttechnologie und der Dienstgüte des serverseitigen Systems zusammen. Komplexere Ansätze wie das Forschungsprojekt SoLOMon [Frø98] oder das von Hewlett Packard speziell für Dienstgüteanforderungen von Web Services entwickelte Dienstgüteüberwachungssystem Extended Application Response Measurement (XARM) [Sahai00] versuchen, die vom Benutzer erfahrene Dienstgüte zur Grundlage ihrer Betrachtung zu machen. Auch wenn den Dienstnehmer letztlich die endgültige Dienstgüte interessiert, so lassen sich die Verantwortlichkeiten für diese Dienstgüte heute jedoch in den wenigsten Fällen auf einen Verhandlungspartner beschränken. Das heißt, dass sich diese Dienstgüte nur im Nachhinein feststellen lässt. Wünschenswert wäre aber der Abschluss verbindlicher Vereinbarungen, um Dienstgüte planbar zu machen. Dies ist jedoch bislang nur auf einzelnen Ebenen möglich. So werden in den folgenden Abschnitten nun die relevanten Dienstgüteparameter sowie Möglichkeiten zur Beeinflussung dieser Parameter auf den Ebenen Transport 2, System und Anwendung vorgestellt. Abbildung 6 zeigt die verschiedenen Ebenen der Kommunikation über Web Services und die Kapitel, in denen sie behandelt werden. Über das System werden Anfragen und Antworten der Transportebene zugeführt. Aspekte der Sicherheit und Kosten der Kommunikation verlaufen orthogonal. 2 Transport ist im Folgenden als die Kommunikation von Informationen über ein Netzwerk verstanden und meint somit einen weiteren Bereich als die Transportschicht der ISO/OSI Referenzmodells. 15

17 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES 4. A n w e n d u n g ( W e b S e r v i c e s ) 3.3/3.4 System 3.1 / 3.2 T r a n s p o r t 3.3/3.4 System 3.5 Sicherheit 3.6 Kos- ten Abbildung 6. Verschiedene Ebenen der Kommunikation und die sie behandelnden Kapitel der Analyse. 3.1 Klassische Parameter der Kommunikationstechnologie Im Kontext der Kommunikationstechnologie spielen vier grundlegende Parameter eine Rolle: Übertragungskapazität (transmission capacity), Übertragungsverzögerung (transmission delay), Verzögerungsschwankung (jitter) und Übertragungszuverlässigkeit (transmission reliability). Je nach Protokollebene werden verschiedene technische Parameter spezifiziert und gemessen. Protokollebenen werden im Folgenden nach dem 7 Schichten ISO/OSI Referenzmodell der ITU TS Empfehlung X.200 angegeben. Nach diesem Modell bietet die Bitübertragungsschicht (Schicht 1 Physical Layer) auf physischer Ebene grundlegende Funktionalität um binär kodierte Informationen über ein Medium zu kommunizieren. Diese Kommunikation wird von der Sicherungsschicht (Schicht 2 Data Link Layer) gesteuert. Auf der Netzwerkebene verbindet die Vermittlungsschicht (Schicht 3 Network Layer) verschiedene Verbindungen zu einem zusammenhängenden Netzwerk. Protokolle wie das Internet Protokoll (IP) implementieren Strategien, um Pakete zu einem gewünschten Ziel weiterzuleiten (routing). Die Transportschicht (Schicht 4 Transport Layer) steuert den Austausch von Nachrichten. Protokolle der Schichten 5 und 6 wie zum Beispiel HTTP oder FTP nutzen die Funktionalität der Transportschicht, um ihrerseits das Management von Netzwerk Ressourcen vor der Anwendungsschicht (Schicht 7 Application Layer) zu verbergen. Abbildung 7 gibt einen Überblick 16

18 ANALYSE VON DIENSTGÜTEPARAMETERN UND -MECHANISMEN über die Bedeutung der vier genannten Dienstgüteparameter auf verschiedenen Protokollebenen, auf die in den folgenden Abschnitten detailliert eingegangen wird. Parameter Bedeutung für Protokollebene Verzögerung Leitungsverzög. Ausbreitungsdauer + Paketgröße / Übertragunsgeschwindigkeit Paketverzögerung Leitungsverzögerung + Warte- und Bearbeitungszeit Antwortzeit 2 x Übertragungsverzögerung + Bearbeitung des Dienstes Verzögerungsschwankung Bit-Verzögerungsschwankung Paketverzögerungsschwankung Antwortzeitverzögerung Zuverlässigkeit Bitfehlerrate Paketverlustrate Dienstausfallrate Kapazität Übertragungsgeschwindigkeit Bits / Sek. Bandbreite Bits / Sek. Skalierberkeit des Dienstes Anfragen / Sek. Schicht Technologie 1: Bitübertragung Kupfer, Glasfaser, Funk 2: Sicherung/ 3: Vermittlung Ethernet, ATM, / IP, 4: Transport / 5-7: Anwendung TCP, / HTTP,SOAP Abbildung 7. Dienstgüteparameter auf verschiedenen Protokollebenen Verzögerung Die Übertragungsverzögerung, die zwei Kommunikationspartner erfahren, wird in der Regel in Millisekunden gemessen. Die Übertragungsverzögerung für ein Datenpaket 3 ist die Zeit, die zwischen Versenden des ersten Bits bis zum Versenden des letzten Bits eines Paketes vergeht. Sie setzt sich aus einer statischen Leitungsverzögerung (wire time) und einer dynamischen Komponente für das Bearbeiten von Paketen und deren Verweildauer in Warteschlangen zusammen. Die Ausbreitungsdauer (propagation time) einer Verbindung beschreibt die Zeit, die benötigt wird um die Information eines Bits vom Eingang der Leitung zu deren Ausgang zu transportieren. Sie hängt sowohl von der physischen Entfernung und den Eigenschaften des benutzten Mediums als auch von der Anzahl zwischengeschalteter passiver oder aktiver 3 In Schicht 2 Protokollen werden synonym zu dem Begriff Paket oft auch Rahmen (frame) benutzt, in Technologien mit konstanter Rahmenlänge (z.b. ATM) ist auch der Begriff Zelle (cell) üblich. 17

19 DIENSTGÜTEUNTERSTÜTZUNG FÜR WEB SERVICES Komponenten (Verstärker, Bridges, Switches) ab. Für eine Folge von Bits muss darüber hinaus die Zeit zum Einspeisen der gesamten Folge in die Leitung (Serialisierung) beachtet werden. Sie hängt ab von der Paketgröße und der Übertragungsgeschwindigkeit (transmission speed) der Leitung, das heißt in welchem Abstand einzelne Signalschritte aufeinander folgen und wie viele Bits in einem Signalschritt kodiert sind. Die Leitungsverzögerung für ein Datenpaket lässt sich also folgendermaßen berechnen: Leitungsverzögerung = Ausbreitungsdauer + Paketgröße / Übertragungsgeschwindigkeit Wird ein Paket von einer Netzwerkkomponente zu einer anderen weitergeleitet, so muss eine weitere dynamische Verzögerung für die Bearbeitung des Pakets und einem eventuellen Zwischenaufenthalt in einer Warteschlange berücksichtigt werden. Diese Warte und Bearbeitungszeit (queuing and processing delay) hängt maßgeblich von der aktuellen Netzlast ab, unter der die bearbeitende Komponente steht. Werden Daten von einer Protokollebene an ein zugrunde liegendes Protokoll übergeben, so werden Pakete oft in kleinere Fragmente zerteilt und später wieder zusammengefügt. In diesem Fall beschreibt die Verzögerungszeit für das Übertragen eines Paketes die Zeit zwischen dem Senden des ersten Teil Paketes und dem Erhalt des letzten Teil Paketes. Hierbei ist zu beachten, dass die Teilpakete unterschiedlich große Übertragungsverzögerungen erfahren (siehe Abschnitt zu Verzögerungsschwankung). Die Verzögerung für das gesamte Paket hängt also von der Verzögerung des langsamsten Teil Paketes der Anzahl zu versendender Teil Pakete ab. Auf der Ebene einer Anwendung setzt sich die Antwortzeit für eine Anfrage zusammen aus der Übertragungsverzögerung für die Anforderung, der Bearbeitungszeit des Dienstes für die Anforderung sowie der Übertragungsverzögerung für die angeforderte Ressource. Anwendungen werden weiterhin eine Verzögerung für den Aufbau von Transportverbindungen erfahren. 18

20 ANALYSE VON DIENSTGÜTEPARAMETERN UND -MECHANISMEN Verzögerungsschwankung Die Verzögerungsschwankung (jitter oder delay variation) bezieht sich auf die durchschnittliche Schwankung von Verzögerungswerten. Wie auch die Verzögerung wird die durchschnittliche Schwankung meist in Millisekunden angegeben. Auch hier finden sich unterschiedliche Bedeutungen auf verschiedenen Protokollebenen. Auf der Bitsicherungsschicht beschreibt ein Jitter Wert die Schwankung in den Ankunftszeiten einzelner Bits. Je höher die Verzögerungsschwankung ist, umso flexibler muss der Empfänger reagieren, wenn er versucht, sich auf die Übertragungsgeschwindigkeit zu synchronisieren. Verzögerungsschwankung für ein Paket ist die durchschnittliche Differenz der Verzögerungswerte für verschiedene Pakete. Hier spielt vor allem die dynamische Verzögerung durch verschieden lange Warteschlangen bei wechselnd starker Auslastung von Netzwerkkomponenten eine Rolle. Die Verzögerungsschwankung ist ein wichtiger Dienstgüteparameter, weil im Fall von Fragmentierung und Reassemblierung der Verzögerungswert des fragmentierten Paketes vor allem von dem Verzögerungswert des langsamsten Teil Paketes abhängt. In diesem Zusammenhang helfen also niedrige Werte für die Verzögerungsschwankung auch die Verzögerungswerte überhaupt klein zu halten. Darüber hinaus werden Angaben über Verzögerungswerte verlässlicher und können somit von beteiligten Komponenten besser berücksichtigt werden Übertragungszuverlässigkeit Übertragungszuverlässigkeit (transmission reliability) beschreibt die Wahrscheinlichkeit, dass der Empfänger gesendete Daten in ihrem Originalzustand erhält. Abbildung 8 gibt einen Überblick über die Auswirkungen von Übertragungsfehlern auf verschiedenen Protokollebenen. Auf der Bitsicherungsschicht können Bitfehler ermittelt werden, indem eine Prüfsumme ausgewertet wird, die mit Hilfe einer Hash Funktion über dem betroffenen Datenpaket gebildet wurde. So lässt sich der Parameter Bitfehlerrate (bit error rate BER) als das Verhältnis korrupter Bits zur gesamten gesendeten Datenmenge ermitteln. Einige Bitfehler lassen sich zum Beispiel durch redundantes versenden 19