ERKLÄRUNG

Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe.

München, Mai 2003....................................................................................................Thomas Hertz

3

INHALTSVERZEICHNIS

Erkl  ärung.  3

Inhaltsverzeichnis.   5

Abbildungs  - und Tabellenverzeichnis.  7

1  Einleitung.  9

1.1  Motivation.  9

1.2  Einordnung und Vorgehensweise.  10

1.3  Gliederung.  11

1.4  Danksagung.  12

2  Aufbau komplexer Client/Server Anwendungen.  13

2.1  Übersicht und Anforderungen.  13

2.2  Die Mehrschichten-Architektur als mögliche Lösung.  14

2.3  Ausfallsicherheit.  16

2.4  Lastverteilung zur Erreichung von Ausfallsicherheit.  17

3  Datenbanksysteme.  21

3.1  Übersicht.  21

3.2  Die wichtigsten Zugriffsschnittstellen.  22

3.3  Transaktionen.  25

3.4  Praxisbeispiel.  28

4  Java 2 Enterprise Edition.  29

4.1  Übersicht.  29

4.2  Enterprise JavaBeans.  30

4.3  Die EJB-Persistenz-Schnittstellen.  33

4.4  Transaktionen in EJB-Architekturen.  40

5  O/R-Mapping.  45

5.1  Übersicht und Gliederung.  45

5.2  Datenhaltung.  45

5.3  Datenzugriff.  52

5.4  Caching.  59

5

6  CCMP - Cached CMP.  75

6.1  DCache.  76

6.2  CMP2BMP.  87

6.3  J2EEDemo.  94

6.4  Performance.  96

7  Bewertung und Ausblick.  99

Anhang 1:  Nutzung des Prototyps.  103

Allgemein.   103

DCache.   108

CMP2BMP.   112

J2EEDemo.   114

Literaturverzeichnis.   119

6

ABBILDUNGS  - UND  

TABELLENVERZEICHNIS   

Abbildung  1: Strukturierung dieser Arbeit.  

Abbildung  2: Aufbau eines komplexen Client/Server Systems.  

Abbildung  3: Verteiltes Relationales Datenbanksystem (RDBMS)  

Abbildung  4: EJB-Architektur.  

Abbildung  5: Definition eines Enterprise JavaBeans.  

Abbildung  6: Anwendung des Serialized LOB Patterns.  

Abbildung  7: Anwendung des Single Inheritance Patterns.  

Abbildung  8: Brute-Force Datenzugriff nach Amb03  

Abbildung  9: Datenzugriff mittels Data Access Objects (DAO)  

Abbildung  10: Trennung von logischer und physikalischer Schicht beim Datenzugriff.  

Abbildung  11: Nutzung eines Persistenzframeworks.  

Abbildung  12: Synchronisation in verteilten Caches.  

Abbildung  13: Zugriffszeit nach Ort der Datenhaltung.  

Abbildung  14: Wege durch den Intra- und Inter-Transaction Cache.  

Abbildung  15: Automatisches Auffinden von Abhängigkeiten.  

Abbildung  16: Die einzelnen Komponenten des CCMP-Frameworks.  

Abbildung  17: Architekturübersicht DCache.  

Abbildung  18: DCache-Baumstruktur für das Cachen von Entity-Beans.  

Abbildung  19: Sequenzdiagramm eines Cachezugriffs.  

Abbildung  20: Architekturübersicht des JDBCWrappers.  

Abbildung  21: Zwei Wege zur Implementierung einer eigenen EJB-Persistenzschicht.  

Abbildung  22: Mögliche Einsprungpunkte für Cachesysteme.  

Abbildung  23: Ablauf der CMP zu BMP Konvertierung.  

Abbildung  24: Architekturübersicht BMP2CMP-Framework.  

Abbildung  25: Architekturübersicht J2EEDemo.  

Abbildung  26: Performancevergleich CMP / CCMP.  

7

Tabelle 1:  Verfügbarkeit von Systemen nach GS91  17

Tabelle 2:  Isolationslevel bei Transaktionen.  27

Tabelle 3:  Einfaches O/R-Mapping nach CK96  46

Tabelle 4:  Benötigte Metadaten zum Zugriff über ein Persistenzframework.  56

Tabelle 5:  Beispielhaftes Typ-Mapping von Java zu SQL.  58

Tabelle 6:  Gegenüberstellung EJB und CRUD-Pattern.  88

Tabelle 7:  Konfiguration des Microsoft Web Application Stress Tool.  97

Tabelle 8:  Verzeichnisstruktur des Prototyps.  105

Tabelle 9:  Verzeichnisstruktur DCache.  109

Tabelle 10:  Konfigurationsparameter des DCache-Frameworks.  109

Tabelle 11:  Verzeichnisstruktur des CMP2BMP-Frameworks.  113

Tabelle 12:  Konfigurationsparameter des CMP2BMP-Frameworks.  113

Tabelle 13:  Verzeichnisstruktur der J2EE-Demoapplikation.  115

8

1 EINLEITUNG

1.1 Motivation

Die Nutzung von Applikationsservern im Rahmen geschäftlicher Anwendungsarchitekturen ist heutzutage nahezu zwingend. Durch sie wird eine Reihe von Technologien wie z.B. Webserver, Transaktionsmonitor oder Messaging-System zu einem gut harmonierenden und in sich schlüssigen Framework zusammengefügt. Neben der Bereitstellung einer Umgebung für die Ausführung von Business-Logik realisieren sie auch die so wichtige Verbindung zu Datenbanksystemen. Ziel der Applikationsserver ist es, die Entwicklung eines modularen, ausfallsicheren und hochskalierbaren Systems zu ermöglichen. Im Java-Umfeld setzt sich J2EE (Java 2 Enterprise Edition) [Sun01a] einschließlich der Komponententechnologie EJB ( Enterprise JavaBeans) [ Sun01c] für Applikationsserver immer mehr durch. EJB bietet einen Rahmen für die Entwicklung von Business-Funktionalität und nimmt dem Entwickler immer wiederkehrende Aufgaben wie Security-Management, Transaktionssicherung oder Datenspeicherung ab.

Wie bereits angedeutet ist eine der Hauptaufgaben eines Applikationsservers die Anbindung aller Arten von Datenbanksystemen. Die J2EE-Spezifikation bietet auch hier einige Hilfen für den Entwickler, ist aber leider in diesem Bereich teilweise nur sehr vage formuliert oder adressiert wichtige Punkte gar nicht. Für die Speicherung der Business-Objekte in einem relationalen Datenbanksystem stehen nur vergleichsweise einfache Abbildungs- und Abfragemöglichkeiten zur Verfügung.

Die Integration bestehender Datenbanksysteme mit moderner Komponententechnik kann somit von den heutigen Applikationsservern oft nicht ohne weitere Hilfsmittel geleistet werden. Vor diesem Hintergrund sind Mechanismen notwendig, die eine flexible Abbildung von Operationen und Anfragen der EJB-Objekte auf relationale Datenbanken ermöglichen. Diese Aufgabenstellung wird üblicherweise durch Persistenz-Frameworks erfüllt.

Die EJB-Spezifikation bietet zwei grundsätzliche Varianten für die Objekt-Persistenz an: CMP ( Container-Managed Persistence) [ Sun01d, S. 125ff] und BMP ( Bean-Managed Persistence) [Sun01d, S. 243ff]. Doch muss für die Integration eines Persistenz-Frameworks in den Applikationsserver eine detailliertere Betrachtung erfolgen, da zum einen keine standardisierten Schnittstellen zwischen Applikationsserver und Persistenz-Framework spezifiziert sind und zum anderen der Einsatz der so genannten Entity-Beans nicht bei jedem Applikationsserver eine performante, ausfallsichere und hochskalierbare Architektur gewährleistet.

Bei der Integration ist nicht nur die Frage zu lösen, wie die EJB-Technologie an das Persistenz-Framework angebunden werden kann. Es stellt sich auch die Frage, ob und wann ein Transaktionssystem nötig ist, wie dieses an den Applikationsserver angebunden

9

werden kann und ob das entstehende Gesamtsystem in der Praxis ausreichend viele Transaktionen verarbeiten kann, um in großen verteilten Anwendungsarchitekturen [Web98] einsetzbar zu sein.

1.2 Einordnung und Vorgehensweise

Abbildung 1 verdeutlicht die grobe Strukturierung dieser Arbeit. Der erste Teil widmet sich den einzelnen Architektur-Schichten einer komplexen Client/Server-Architektur. Dies beinhaltet eine Vorstellung der wichtigsten Persistenzmanagementschnittstellen der EJB-Architektur, der Auswahl von geeigneten Datenbanksystemen und Lösungen zur Erreichung von Skalierbarkeit und Ausfallsicherheit auf diesen Bereichen.

Dies ist die Annäherung an den Kern dieser Arbeit, die genauere Betrachtung des Persistenzmanagements, welches vor allem durch das sogenannte O/R-Mapping (Objekt-Relationales Mapping) bestimmt wird. Es werden Architektur- und Entwurfsmuster vorgestellt, mit deren Hilfe man den Zugriff auf relationale Daten von objektorientierten Programmiersprachen und das intelligente Zwischenspeichern (engl. Caching) von häufig benötigten Daten in einem verteilten System lösen kann. Es wird aufgezeigt, wie sich diese Muster in J2EE-Systeme integrieren und damit unter der einheitlichen Programmierschnittstelle für Enterprise JavaBeans nutzbar machen lassen.

Nachdem dieser erste Teil der Diplomarbeit die horizontalen Architekturschichten näher beleuchtet hat, wird im zweiten Teil der praktische Einsatz der erlangten Ergebnisse durch den Entwurf eines Prototyps belegt. Dieser zeigt als eine Art ‚vertikaler Durchstoss’ die beispielhafte Implementierung der vorgestellten Muster. Desweiteren werden anhand von zwei Produktvorstellungen (Oracle Real Application Cluster und HP Traffic Director) in den jeweiligen Kapiteln aufgezeigt, wie die Herausforderungen an komplexe skalierbare und ausfallsichere Systeme im Bereich der Datenhaltung und der Lastverteilung in der Praxis gelöst werden können. Den Abschluss bilden eine Bewertung der heutigen Technologien und Verfahren und ein Ausblick in die nähere Zukuft.

1.3 Gliederung

Kapitel 2, Aufbau komplexer Client/Server Anwendungen, stellt eine Einführung in das Gebiet der Client/Server Anwendungen dar. Es werden die Anforderungen an komplexe und verteilte Mehrschichten-Systeme aufgezeigt. Auch wird die Bedeutung der Lastverteilung für die Erfüllung der wichtigen Anforderungen Skalierbarkeit und Ausfallsicherheit anhand von praxisbezogenen Lösungen erwähnt und beschrieben. Es findet eine Einordnung statt, in welche Bereiche diese Arbeit vordringen will und welche Gebiete nicht oder nicht ausführlich behandelt werden.

In Kapitel 3, Datenbanksysteme, wird der Aufbau von Datenbanksystemen erklärt, es wird der Unterschied zwischen objektorientierten und relationalen Datenbanksystemen aufgezeigt und die Frage beantwortet, warum relationale Datenbanken immer noch die erste Wahl bei der Verwaltung von großen Datenmengen sind. Nach einer Einführung in die Theorie der Transaktionsverwaltung werden die wichtigsten Zugriffsschnittstellen (SQL, JDBC, SQLJ) für die Benutzung in Java-Programmen vorgestellt. Anhand des Produktes Oracle Real Application Cluster wird bestätigt, dass transparente, skalierbare und ausfallsichere Datenbanksysteme auf dem Markt verfügbar sind. Kapitel 4, Java 2 Enterprise Edition, geht nach einer grundsätzlichen Einführung der Java 2 Enterprise Edition (J2EE) und der Komponententechnologie Enterprise JavaBeans (EJB) auf die Persistenzschnittstellen CMP (Container Managed Persistence) und BMP (Bean Managed Persistence) ein. Auch werden die Abfragesprache EJB QL (Enterprise JavaBeans Query Language) und ihre Vor- und Nachteile ausführlich behandelt. Abschließend wird aufgezeigt, welche Unterstützung J2EE im Bereich der Transaktionsverwaltung durch CMT (Container Managed Transactions) anbietet und wie es möglich ist, manuelle Transaktionssteuerung mittels BMT (Bean Managed Transactions) zu betreiben.

Kapitel 5, O/R-Mapping, geht auf die Notwendigkeit ein, eine Schnittstelle zwischen der objektorientierten Geschäftslogikschicht und der relationalen Datenbankschicht zu benutzen. Es werden verschiedene Architektur- und Entwurfsmuster vorgestellt, die dieses sogenannte Objekt-Relationale Mapping lösen können. Es wird im Detail über die Notwendigkeit referiert, Daten in verteilten und skalierten Systemen oberhalb der

11

Datenbankschicht zwischenzuspeichern (zu cachen), und Lösungen hierzu aufgezeigt. Auch die möglichen Folgen für die Transaktionssicherheit bei Verwendung von Caches werden ausführlich erläutert.

Kapitel 6, CCMP - Cached CMP, beschreibt die genaue Architektur und den Aufbau des im Rahmen dieser Diplomarbeit entworfenen und implementierten Prototyps mitsamt seiner drei Komponenten

· DCache, ein Framework für einen verteilten, transaktionssicheren Cache für beliebige Javaobjekte,

· CMP2BMP, ein Konverter, der aus CMP Entity-Beans BMP Entity-Beans erzeugt und unter Nutzung der DCache-Komponente die Persistenzschicht selbst generiert,

· J2EEDemo, eine J2EE-Beispielapplikation, an der das Zusammenspiel von DCache und CMP2BMP demonstriert werden kann.

¹ Die Beschreibungen des Prototyps werden durch UML -Klassen- und Sequenzdiagramme weiter verdeutlicht.

Kapitel 7, Bewertung und Ausblick, fasst die im Zuge dieser Arbeit gewonnenen Erkenntnisse zusammen. Es wird aufgezeigt, welche Probleme bei der Anwendung der J2EE-Plattform im Bereich Skalierbarkeit, Ausfallsicherheit und Performance zur Zeit noch existieren und in welche Richtung die zukünftige Entwicklung geht oder gehen sollte, um möglichst vielen der nötigen Anforderungen gerecht zu werden. Anhang 1, Nutzung des Prototyps, dient als Handbuch für die Benutzung und Weiterentwicklung der einzelnen Prototyp-Komponenten DCache, CMP2BMP und J2EEDemo.

1.4 Danksagung

Ich danke allen, die mir bei dieser Arbeit geholfen haben: Herrn Prof. Dr. Matthes, der es mir ermöglicht hat, über dieses interessante Thema zu schreiben, Thomas Büchner für seine wertvollen Tipps, Martin, Andreas, Tom für das Korrekturlesen, Sabine für ihre Fähigkeit, mich immer wieder auf andere Gedanken zu bringen, Jeanette für die seelische Unterstützung, meinen Eltern und meiner Schwester für die Bereitstellung des sonnigen Gartens, hybris für die Freizeit und R.E.M., deren Musik mich während der gesamten Vorbereitungs- und Schreibarbeit begleitet hat.

¹ UML ist eingetragenes Warenzeichen der Object Management Group (OMG). Für mehr Informationen

2 AUFBAU KOMPLEXER CLIENT/SERVER

ANWENDUNGEN

2.1 Übersicht und Anforderungen

Ein Client/Server-System [Gei95] besteht aus zwei verschiedenen Arten von Rechnern -Client-Rechnern und Server-Rechnern - die durch ein Netzwerk miteinander verbunden sind. Die Client-Rechner sind Arbeitsstationen der einzelnen Anwender, während der Server-Rechner die Geschäftslogik steuert und die Daten (Informationen, Dateien oder Computerprogramme) hält, die für diese Arbeit benötigt werden.

Benutzer der Client-Rechner arbeiten mit einer Client-Software zur Abfrage der benötigten Daten am Server. Dies ist in der Praxis bei webbasierten Anwendungen ein sogenannter Web-Browser, der die Informationen darstellt. Die Server-Software, die auf dem Server-Rechner ausgeführt wird, erhält die Datenabfragen und gibt daraufhin entsprechende Ergebnisse an den Client-Rechner zurück. Typisch für solche Anwendungen ist, dass die Initiative (der Aufruf des Dienstes) vom Client ausgeht, und ein Server von vielen Clients aufgerufen werden kann und somit hohe Transaktionsraten auftreten können. Voraussetzung für das Client/Server-Computing ist die optimale Interoperabilität zwischen den verwendeten Systemen. Das setzt offene Architekturen voraus, die sich durch standardkonforme Implementierungen bei den Schnittstellen und den Funktionen abzeichnen.

Die Verteilung der Serverseite auf mehrere Rechner macht ein verteiltes, skaliertes System aus. Dadurch wird außer der verteilten Präsentation auf mehreren Client-Rechnern auch die Server-Software oder ein Teil von ihr dezentralisiert. An die Entwicklung verteilter Client/Server Anwendungen werden eine Reihe von Anforderungen gestellt:

· Skalierbarkeit. Die Anwendung muss ohne großen Aufwand aufrüstbar sein um auch für eine gesteigerte Last dem einzelnen Benutzer schnelle Antwortzeiten zu bieten. Das System muss verteilbar auf mehrere physikalische Server sein, man spricht hier von Verteilten Systemen (engl. Distributed Systems, [TS01]) · Robustheit. Die Anwendung sollte 24 Stunden an 7 Tagen in der Woche einsatzfähig sein, das bedeutet es soll keine oder eine möglichst geringe ungewollte Ausfallzeit (engl. Downtime) geben. Es darf nicht zu inkonsistenten Zuständen innerhalb der Applikation durch Fehlverhalten oder Absturz der Anwendung kommen.

13

· Portabilität. Die Anwendung sollte plattformunabhängig sein. Dies bedeutet, dass sie ohne oder mit sehr wenigen Anpassungen auf verschiedenen Hardware- und Betriebssystemplattformen eingesetzt werden kann. Die Programmiersprache Java

² bietet beispielsweise eine hohe Portabilität. (Write Once, Run Anywhere )

· Sicherheit. Die Sicherheit des Benutzers darf nicht beeinträchtigt werden. Es muss Konzepte für die Vergabe von Rechten und Zugriffsbeschränkungen auf Teilbereiche der Anwendung geben. Es darf nicht möglich sein, ohne entsprechende Autorisation an schützenswerte Informationen und Daten zu gelangen. · Wiederverwendbarkeit. Die Anwendung soll klare Schnittstellen aufweisen und komponenten-basiert aufgebaut sein. Dadurch können einzelne Teile sehr einfach in anderen Systemen wieder verwendet werden. Dies spart Entwicklungszeit und damit Kosten.

· Integrationsfähigkeit. Die Anwendung soll leicht auf externe Programme und Datenquellen zugreifen können. Des Weiteren muss es möglich sein, die Anwendung oder Teile von ihr in andere Fremdsysteme einzubetten. Hohe Wiederverwendbarkeit fördert meist auch die Integrationsfähigkeit von Systemen.

Änderungen an der Konfiguration müssen schnell und sicher durchgeführt werden können.

2.2 Die Mehrschichten-Architektur als mögliche Lösung

Anwendungen sind von den Anfängen des Internets bis heute durch ganz verschiedene Entwicklungen und Techniken geprägt worden. Neben der so genannten Ein-Schicht-Architektur, z.B. einfaches statisches HTML, sind heutzutage vielfältige Lösungen mit mehr als einer Architektur-Schicht im Internet zu finden. Zahlreiche serverseitige Programmier- und Skriptsprachen bereichern die Anwendungsentwicklung. Der Komplexitätsgrad der Anwendungen steigt hierbei zudem noch durch die Verwendung von unterschiedlichen Hardware- und Softwarelösungen.

Um einigen der im letzten Kapitel vorgestellten und immer wichtiger werdenden Anforderungen an komplexe Client/Server Anwendungen wie Skalierbarkeit, Robustheit, Portabilität, Sicherheit und Integration genügen zu können, wechseln immer mehr Anbieter von den typischen Ein- oder Zweischichtenarchitekturen auf Mehrschichtenarchitekturen mit mindestens drei Ebenen.

² ‚Write Once, Run Anywhere’ ist ein Warenzeichen von Sun Microsystems Inc.

³ Feature verschiedener J2EE Server, bei dem bestimmte Verzeichnisse vom Server zur Laufzeit überwacht

Die mit diesem Wechsel verbundene stärkere Trennung von Präsentationslogik, Geschäftslogik und Datenhaltungsschicht und die Festigung von Schnittstellen zwischen den einzelnen Ebenen hat zu einer viel höheren Modularisierung und damit Wiederverwendbarkeit geführt. Durch das Vorhandensein von klaren Schnittstellen können sich Hersteller auf das Entwickeln einzelner Komponenten spezialisieren. Diese Komponenten können leichter in andere Systeme integriert werden und in zukünftigen Projekten mit wenigen Anpassungen erneut verwendet werden.

Dies macht deutlich, dass wichtige Anforderungen, die an die Entwicklung von verteilten Client/Server Anwendungen gestellt werden, sich mit Hilfe von Mehrschichten-Architekturen lösen lassen.

Der typische Aufbau einer solchen Mehrschichten-Architektur wird in Abbildung 2 vorgestellt. Es ist eine vorgelagerte Schicht zu sehen, die zwischen der Client- und der Präsentationsschicht liegt. In dieser Schicht werden große Teile der wichtigen Anforderungen Ausfallsicherheit und Skalierbarkeit durch so genannte Loadbalancer (Lastverteilungssysteme) erfüllt. Dieser Vorgang wird unten detaillierter beschrieben.

15

2.3 Ausfallsicherheit

Die Begriffe Ausfallsicherheit oder Verfügbarkeit kann man als den Umfang bezeichnen, in dem ein System gegen Störungen unempfindlich ist und korrekt nach seinen Vorgaben arbeitet. Vor einer genaueren Definition fehlt noch eine Erläuterung, was unter einem System zu verstehen ist, das ‚fehlerfrei’ oder ‚korrekt nach seinen Vorgaben’ arbeitet. Hierbei ist nicht nur die physikalische Funktionstüchtigkeit zu verstehen, also die Verfügbarkeit der Hardware und Netzwerkinfrastruktur, sondern auch die logische Funktionstüchtigkeit. Ein System, welches für die Kunden zu langsam reagiert, also bei bestehender Nutzerlast keine ausreichende Performance bietet, ist nicht verfügbar im Sinne der Definition. Auch fallen logische Fehler im Programmablauf und undeterminiertes Verhalten in diese Kategorie.

Zwei wichtige Begriffe im Zusammenhang mit Ausfallsicherheit sind die folgenden: · MTTF (mean-time-to-failure) ist die durchschnittliche Zeit, welche ein System ohne Fehler arbeitet, nachdem es aufgesetzt oder repariert worden ist. · MTTR (mean-time-to-repair) ist die durchschnittliche Zeit, die benötigt wird, ein fehlerhaftes System zu reparieren.

Mit diesem Hintergrund kann man den Begriff Ausfallsicherheit (engl. Availability) nun wie folgt definieren:

Die Aussage “It is paradoxical that the larger a system is, the more critical is its availability, and the more difficult it is to make it highly-available.” [GS91] macht deutlich, wie schwierig es ist, in komplexen Systemen eine hohe Ausfallsicherheit zu erreichen. Die derzeit ausfallsichersten Systeme liegen nach Tabelle 1 im Bereich der High-availability (Hochverfügbarkeit), sie weisen also eine Ausfallzeit von nur 5 Minuten pro Jahr auf.

16

2.4 Lastverteilung zur Erreichung von Ausfallsicherheit

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable. (Leslie Lamport)

Lastverteilung (engl. Loadbalancing) bezeichnet die Aufgabe, Anfragen von Clients nach einer bestimmten Strategie auf einen bestimmten zuständigen Server weiterzuleiten. Die Aufgabe der Lastverteilung ist immer dann nötig, wenn zur Erreichung von Skalierbarkeit und Ausfallsicherheit bestimmte Bereiche des Systems redundant ausgelegt werden. Diese Redundanz dient dazu, ein System ohne oder mit möglichst wenigen sogenannten einzelnen Ausfallpunkten (engl. Single Points of Failure) zu erhalten [GS96]. Da aber eine Anfrage typischerweise von nur genau einem Server bearbeitet wird, muss darüber entschieden werden, an welchen Server die Anfrage geleitet werden soll. In der Praxis findet man sehr häufig zwei Strategien, nach denen diese Entscheidung getroffen wird. Eine sehr einfach zu implementierende Möglichkeit ist die Anwendung des

4 Verfahrens, welches hintereinander in fester Reihenfolge über so genannte Round-Robin

die Menge aller verfügbaren Server iteriert um danach wieder beim ersten zu beginnen.

⁴ Eine mögliche Herkunft des Wortes Round-Robin ist die französische Bezeichnung rond ruban (rundes Band), mit der eine Petition bezeichnet wurde, bei der die Unterschriften im Kreis herum geschrieben wurden, um

die Reihenfolge zu verschleiern, in der sie geleistet wurden.

17

Eine weitere, aber durchaus anspruchsvollere und schwieriger zu implementierende Strategie ist das Load-based oder lastbasierte Verfahren, bei dem ständig die Auslastung der verfügbaren Server protokolliert wird und diejenigen Server mit hoher Auslastung weniger Anfragen zugewiesen bekommen. Dadurch wird erreicht, dass die hoch ausgelasteten Server entlastet werden. Durch die entstehende Dynamik stellt sich mit fortlaufender Zeit ein Gleichgewicht in der Auslastung aller Rechner ein. Eine gute Einführung zu HTTP-Loadbalancing-Strategien bietet [GT02, Kapitel 20].

Ein kritischer Punkt in einem Lastverteilungssystem ist die Erkennung von Fehlern und die entsprechende Reaktion darauf. Dies entscheidet auch über die Ausfallsicherheit des gesamten Systems. Der Loadbalancer ist dafür verantwortlich zu erkennen, welche unter ihm arbeitenden Server in einem vorher zu definierenden Rahmen korrekt und mit für die Clients erträglicher Performance arbeiten. Anfragen dürfen nicht an Server geleitet werden, die ausgefallen sind, überlastet sind oder in sonstiger Art nicht korrekt arbeiten (z.B. durch Liefern korrupter Ausgaben). Diese müssen aus der Verteilung ausgeschlossen und die Clients auf andere Server geleitet werden. Nur eine gute und zuverlässige Strategie in diesem Punkt garantiert eine weitgehende Ausfallsicherheit des Systems. Aus diesem Punkt kann man die folgende Aussage ableiten: + = nnung Fehlererke gute keit Skalierbar herheit Ausfallsic

Da Loadbalancer einzelne Anfragen nicht selbst beantworten müssen, sondern diese nur

⁵ weiterleiten , werden keine großen Anforderungen an die Rechenleistung gestellt. Der natürlich vorhandene Bedarf an Netzwerkressourcen kann oftmals durch Maßnahmen wie z.B. Local Triangulation [Rad01] oder Out-Of-Path-Return [Hew03a] noch weiter gesenkt werden. Die dem Autor bekannten Systeme sind im Praxiseinsatz nicht an ihre Leistungsgrenzen gestoßen und waren auch für große verteilte Systeme mit hoher Transaktionszahl geeignet.

Die Technik und Ausgereiftheit dieser Systeme ist weit fortgeschritten. Dies liegt auch größtenteils an ihrem sehr beschränkten und überschaubaren Aufgabengebiet. Loadbalancer sind meist von anderen Komponenten in einem komplexen Systemaufbau unabhängig. Unter dem Loadbalancer arbeitende Ebenen wie die Datenhaltungssysteme müssen nichts von der Existenz eines Loadbalancers wissen. Die vielleicht einzige Ausnahme ist der im Folgenden beschriebene Punkt.

Da der Loadbalancer als Zwischenschicht eingezogen wurde, haben die verarbeitenden (Web-)Server keinen direkten Kontakt mit dem Client. Die Server sehen nun immer die IP-Adresse des Loadbalancers als ihren Client und nicht mehr die des eigentlichen Clients, der die Anfrage initiiert hat. Dadurch wird eventuell eine auf den Servern vorhandene

⁵ Teilweise ist es nötig, die ankommenden Anfragen auf der Applikationsschicht (Schicht 7 des OSI-

Programmlogik, die z.B. auf die IP-Adresse des Clients reagiert, gestört. Hier bieten fortgeschrittene Loadbalancer die Möglichkeit, die ursprüngliche Adresse in einem zusätzlichen HTTP-Header an die verarbeitenden Server durchzureichen. Diese haben dann die Möglichkeit, die IP-Adresse auszulesen und entsprechend darauf zu reagieren. Die Aufgabe der Lastverteilung wird entweder durch Hardware-Loadbalancer oder Software-Loadbalancer übernommen. Software-Loadbalancer nutzen eine vorhandene Serverinfrastruktur und bestehen aus einer Software, welche die für die Lastverteilung nötigen Aufgaben übernimmt, während Hardware-Loadbalancer eigene physikalische Server sind, die dediziert Lastverteilungsaufgaben übernehmen. Beispiel für eine softwarebasierte Loadbalancing-Lösung:

Das Modul mod_oc4j des im Oracle 9iAS integrierten Apache Webservers leitet nach dem Round-Robin Verfahren eingehende HTTP(S) Anfragen an eine der verfügbaren Applikationsserver-Instanzen im Cluster weiter [Ora02b]. Beispiel für eine hardwarebasierte Loadbalancing-Lösung: Der E-Commerce Traffic-Director SA8220 von Hewlett Packard kann eingehende HTTP-Requests an einen der verfügbaren Webserver weiterleiten. Es ist ein Loadbalancer in 2U Rackgröße, der sehr einfach einzurichten und zu konfigurieren ist. Um Ausfallsicherheit auch auf der Loadbalancer-Ebene zu gewährleisten, lässt sich ein baugleiches Gerät in einem so genannten ‚Backup-Modus’ betreiben. Dieser gleicht über ein serielles Kabel Konfigurationseinstellungen mit dem primären Gerät ab und überprüft ständig dessen Betriebsbereitschaft um im Fehlerfall automatisch alle Aufgaben zu übernehmen. Weitere Informationen zu diesem Hardware Loadbalancer findet sich unter [Hew03a].

19

3 DATENBANKSYSTEME

3.1 Übersicht

Ein Datenbanksystem ( DBS) ist ein System zur dauerhaften Speicherung und zum effizienten Suchen in großen Datenmengen. Moderne Datenbanksysteme bestehen aus folgenden zwei Komponenten:

· Die Datenbank (DB): Sammlung von Daten. Diese werden meist mittels geeigneter Hardware wie z.B. Festplatten persistent gehalten. · Das Datenbank-Management-System (DBMS): Programm zum Management von Datenbanken beliebiger Anwendungen in einem spezifizierten Format. In der Praxis werden heutzutage meist zwei unterschiedliche Arten von Datenbanksyste- ⁶ eingesetzt: men

Die sogenannten relationalen Datenbank-Management-Systeme (RDBMS) [ Kel98] speichern die Daten und die Verknüpfung (Relationen) verschiedener Datensätze in zweidimensionalen Tabellenstrukturen. Der Zugriff auf die Daten erfolgt über eine Datenbankabfragesprache und erzeugt, ändert und findet einzelne Zeilen und Spalten in dieser Tabellenstruktur.

Einen anderen Weg gehen die objektorientierten Datenbank-Management-Systeme (OODBMS), die sich an objektorientierte Programmiersprachen anlehnen und den Zugriff auf die Daten über Objekte kapseln. Die Daten werden nicht in einer Tabellenstruktur gespeichert, sondern entweder in XML-Dateien, serialisierten Java-Objekten oder proprietären Herstellerformaten. Diese Art der Datenbanksysteme ist noch sehr neu, für den Praxiseinsatz in großen Systemen sind OODBMS oft noch nicht ausgereift genug oder bieten keinen ausreichend performanten Zugriff.

Richard Monson-Haefel beschreibt die erste Regel für den Entwurf und die Architektur von verteilten Systemen folgendermaßen:

Use relational database systems for persistence. They are ubiquitous, proven, standardized, maintainable, robust, and well supported by third-party tools. While Object-Databases are a better fit for object-based systems, they are not well supported by third-party tools like reporting systems and data warehousing systems. In addition, standardization in OODBS is not as mature as it is in relational database systems, so applications tend to be less portable across database products. [Mon00]

⁶ Im weiteren Verlauf dieser Arbeit wird mit dem Begriff Datenbank ein komplettes Datenbanksystem im Sinne der angegenbenen Definition referenziert, nicht ausschliesslich die Sammlung der Daten.

21

Der Autor dieser Arbeit schließt sich dieser Aussage an.

In großen Projekten ist der Einsatz bekannter erprobter relationaler Datenbanksysteme erste Wahl. Aus diesem Grund konzentriert sich diese Arbeit vor allem auf diese Systeme. Eine Übersicht über die derzeit bekanntesten relationalen und objekt-orientierten Datenbanksysteme findet sich unter [Jav03].

Abbildung 3 zeigt schematisch die Einbettung eines RDMBS und seiner Schnittstellen in den Kontext einer zugreifenden Applikation. Die Sprache SQL und Javaschnittstelle JDBC werden in den folgenden Unterkapiteln adressiert.

Abbildung 3: Verteiltes Relationales Datenbanksystem (RDBMS)

3.2 Die wichtigsten Zugriffsschnittstellen

3.2.1 SQL (Structured Query Language)

SQL ist die Computersprache, mit der die meisten relationalen Datenbanken erstellt, manipuliert und abgefragt werden. SQL ist eine sogenannte 4GL (Fourth-Generation Language). Sie ist nichtprozedural, d. h. der Fragesteller stellt eine Frage, gibt aber keinen Algorithmus zur Lösung vor. In einer höheren Programmiersprache (3GL) wie Pascal, C oder Java müsste er angeben, wie die gesuchten Informationen gefunden werden können, z. B. vom Öffnen der Datei bis zum schrittweisen Iterieren über die Datensätze. Zur weiteren Spracheinordnung von SQL siehe auch [SM90].

SQL ist ein ISO- und ANSI-Standard, der mehrfach spezifiziert wurde bzw. noch wird. Die größten Meilensteine in der Entwicklung waren: · SQL 86 (1986 definiert).

· SQL 89 (1989 definiert). Zwei mögliche Ebenen des Sprachumfangs: Level 1 und Level 2.

· SQL 92 oder SQL2 (1992 definiert). Vier mögliche Ebenen des Sprachumfangs: Entry Level, Transitional, Intermediate Level und Full Level. · SQL3 (Spezifikation ist gerade in Arbeit). Informationen zu den Neuerungen in SQL3 sind in [Sey94] zu finden.

Neben einem bestimmten SQL-Standard unterstützen Datenbanksysteme meist Teile höherer Standards sowie eigene SQL-Erweiterungen. SQL 89 Level 2 ist auch heute noch Basis des von vielen Datenbanksystemen unterstützen SQL, bei SQL 92 sind die meisten Systeme nur Entry Level-Compliant (z. B. Oracle).

Trotz aller Bestrebungen, mittels SQL eine einheitliche Spezifikation für den Zugriff auf relationale Datenbanksysteme zu schaffen, ist dies in der Praxis oft nicht erreicht worden. Die Wahrscheinlichkeit, dass eine komplexe SQL-Anfrage auf mehreren relationalen Datenbanksystemen ohne jegliche Anpassungen syntaktisch korrekt ist und semantisch gleich abgearbeitet werden kann, ist sehr gering. Es zeichnet sich in naher Zukunft hier auch keine komplette Vereinheitlichung ab, dies ist aus der Sicht des Autors aber auch nicht unbedingt notwendig. Im Falle eines Wechsels der Datenbank ist eine Umstellung im Bereich der SQL-Abfragen zwar oft nötig, der Aufwand hierfür aber vernachlässigbar. Das größere Problem ist die Tatsache, dass häufig proprietäre Zusatzfunktionalität des Datenbankherstellers eingesetzt wurde, dessen Umstellung einen meist um Faktoren größeren Aufwand hervorruft.

3.2.2 JDBC (Java Database Connectivity)

JDBC ist eine Java Standardschnittstelle, die die Anbindung relationaler Datenbanken erlaubt. Es bietet eine Möglichkeit, verschiedene Datenbanksysteme anzusprechen, SQL-Befehle abzusetzen und die Ergebnisse auszulesen. Auch werden explizit Möglichkeiten zum Steuern von Transaktionen (siehe Kapitel 3.3) angeboten. Zu der Mehrzahl der relationalen Datenbanksysteme gibt es Java-Treiber, die die JDBC-Spezifikation erfüllen. Diese wurden entweder vom Hersteller der Datenbank oder von Fremdherstellern entwickelt.

Im Gegensatz dazu bieten die meisten OODBMS keine JDBC-Treiber. Dies widerspräche auch der Intention der objektorientierten Systeme, da JDBC die nicht objektorientierte Abfragesprache SQL kapselt. Um kompatibel zu JDBC-basierten Programmen zu sein, tauchen trotzdem vereinzelt Implementierungen auf, die eine Art R/O-Mapping

23

(Relational auf Objekt-Mapping) betreiben - es werden relationale Anfragen in SQL formuliert und anschließend in die objektorientierte Darstellung der Datenbank gewandelt. Die Schnittstelle JDBC ist Bestandteil der Java 2 Standard Edition (J2SE). Die benötigten Klassen und Interfaces befinden sich im java.sql-Package. Eine installierte Java-Umgebung und ein JDBC-Treiber für die gewünschte Datenbank sind also ausreichend, um SQL-Anfragen abzusetzen.

Der folgende Programmausschnitt zeigt ein einfaches Beispiel, welches demonstriert, wie mittels JDBC mit einem Oracle-Datenbanksystem gearbeitet werden kann:

//--register the Oracle JDBC-Driver

Class.forName( oracle.jdbc.OracleDriver.class.getName() );

//--connect to the database

Connection conn =

DriverManager.getConnection( "jdbc:oracle:thin:@SERVER:1521:SID",

"username",

"password" );

//--enable transactions

conn.setAutoCommit( false );

//--create statement object

Statement stmt = conn.createStatement();

//--execute the two SQL-statements

stmt.executeUpdate( "UPDATE Konto SET Amount=235 WHERE KTONr=71113" );

stmt.executeUpdate( "UPDATE Konto SET Amount=0 WHERE KTONr=172329" );

//--commit the transaction

conn.commit();

//--close the connection

conn.close();

3.2.3 SQLj (Embedded SQL for Java)

Eine zweite Möglichkeit, aus Java heraus auf relationale Datenbanken zuzugreifen, ist SQLj [SQL03]. Es ist durch den Zusammenschluss führender Datenbankhersteller wie Oracle, Sybase, SUN, IBM, Informix, Microsoft sowie Sun Microsystems entstanden und stellt einen ANSI-Standard für Embedded SQL dar. Durch den ebenfalls standardisierten Präprozessor SQLj Translator ist es möglich, Java-Programme mit eingebettetem, statischem SQLj zu entwickeln.

Im Unterschied zu JDBC fügt der Programmierer in seinen Java-Sourcecode spezielle Befehle ein, die von einem Präprozessor übersetzt werden.

System.out.println(“now performing select query..”);

#sql {SELECT * FROM bsp_tabelle};

SQLj bietet einige Vorteile, zu nennen sind vor allem die im Vergleich zu JDBC viel kompaktere Schreibweise und die durch den Präprozessor gegebene Möglichkeit einer Syntaxkontrolle noch vor der Laufzeit.

Allerdings kann gerade die Pflicht der Benutzung eines Präprozessors auch als Nachteil angesehen werden. Es macht die Entwicklung und Einbettung in Drittapplikationen komplexer und schwieriger. Des Weiteren ist es durch die Präkompilierung aller SQL-Statements nicht möglich, zur Laufzeit dynamische Anfragen zu generieren. Diese Arbeit wird nicht weiter auf SQLj als Schnittstelle zu relationalen Datenbanken eingehen. SQLj hat sich in der Praxis beim Einsatz in Applikationsservern nicht durchsetzen können.

3.3 Transaktionen

Eine Transaktion bezeichnet eine Folge von logisch zusammengehörenden Datenbankanweisungen. Sie dient dazu, einen konsistenten Datenbankzustand in einen anderen konsistenten Datenbankzustand zu überführen [GR93]. Bezüglich der Ausführung von Transaktionen garantiert das Datenbanksystem die Einhaltung von vier grundlegenden Eigenschaften: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Man spricht hierbei von den sogenannten ACID-Eigenschaften, abgeleitet von den Anfangsbuchstaben der englischen Begriffe Atomicity, Consistency, Isolation und Durability [HR01]. Diese im Folgenden näher erläuterten Eigenschaften charakterisieren zugleich das Transaktionskonzept.

1. Atomarität (Atomicity, "Alles oder Nichts")

Die Ausführung einer Transaktion soll aus Sicht des Benutzers ununterbrechbar verlaufen, so dass sie entweder vollständig oder gar nicht ausgeführt wird. Dies bezieht sich vor allem auf die im Rahmen der Transaktion auszuführenden Änderungen der Datenbank. Tritt während der Ausführung einer Transaktion ein Fehler auf (Programmfehler, Hardware-Fehler, Absturz des Betriebssystems usw.), der die ordnungsgemäße Fortführung verhindert, werden seitens des DBS sämtliche bereits erfolgten Änderungen der Transaktion zurückgesetzt.

2. Konsistenz (Consistency)

Die Transaktion ist die Einheit der Datenbankkonsistenz. Dies bedeutet, dass sie die Datenbank von einem konsistenten in einen wiederum konsistenten (nicht notwendigerweise unterschiedlichen) Zustand überführt. Von besonderer Bedeutung ist dabei die Einhaltung der logischen Konsistenz, so dass die Inhalte der Datenbank einem möglichst korrekten Abbild der modellierten Wirklichkeit entsprechen. Hierzu können beim Datenbankentwurf semantische Integritätsbedingungen (zulässige Wertebereiche,

25