Erklärung
Abbildungs- und Tabellenverzeichnis
1 Einleitung
1.1 Motivation
1.2 Einordnung und Vorgehensweise
1.3 Gliederung
1.4 Danksagung
2 Aufbau komplexer Client/Server Anwendungen
2.1 Übersicht und Anforderungen
2.2 Die Mehrschichten-Architektur als mögliche Lösung
2.3 Ausfallsicherheit
2.4 Lastverteilung zur Erreichung von Ausfallsicherheit
3 Datenbanksysteme
3.1 Übersicht
3.2 Die wichtigsten Zugriffsschnittstellen
3.3 Transaktionen
3.4 Praxisbeispiel
4 Java 2 Enterprise Edition
4.1 Übersicht
4.2 Enterprise JavaBeans
4.3 Die EJB-Persistenz-Schnittstellen
4.4 Transaktionen in EJB-Architekturen
5 O/R-Mapping
5.1 Übersicht und Gliederung
5.2 Datenhaltung
5.3 Datenzugriff
5.4 Caching
6 CCMP - Cached CMP
6.1 DCache
6.2 CMP2BMP
6.3 J2EEDemo
6.4 Performance
7 Bewertung und Ausblick
Anhang 1: Nutzung des Prototyps
Allgemein
DCache
CMP2BMP
J2EEDemo
Literaturverzeichnis
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
Tabelle 1: Verfügbarkeit von Systemen nach [ GS91 ]
Tabelle 2: Isolationslevel bei Transaktionen
Tabelle 3: Einfaches O/R-Mapping nach [ CK96 ]..
Tabelle 4: Benötigte Metadaten zum Zugriff über ein Persistenzframework
Tabelle 5: Beispielhaftes Typ-Mapping von Java zu SQL
Tabelle 6: Gegenüberstellung EJB und CRUD-Pattern
Tabelle 7: Konfiguration des Microsoft Web Application Stress Tool
Tabelle 8: Verzeichnisstruktur des Prototyps
Tabelle 9: Verzeichnisstruktur DCache
Tabelle 10: Konfigurationsparameter des DCache-Frameworks
Tabelle 11: Verzeichnisstruktur des CMP2BMP-Frameworks
Tabelle 12: Konfigurationsparameter des CMP2BMP-Frameworks
Tabelle 13: Verzeichnisstruktur der J2EE-Demoapplikation
Die Nutzung von Applikationsservern im Rahmen geschäftlicher Anwendungsarchitektu- ren 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 BusinessFunktionalität und nimmt dem Entwickler immer wiederkehrende Aufgaben wie SecurityManagement, 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 BusinessObjekte 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 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.
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 EJBArchitektur, der Auswahl von geeigneten Datenbanksystemen und Lösungen zur Erreichung von Skalierbarkeit und Ausfallsicherheit auf diesen Bereichen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Strukturierung dieser Arbeit
Dies ist die Annäherung an den Kern dieser Arbeit, die genauere Betrachtung des Persistenzmanagements, welches vor allem durch das sogenannte O/R-Mapping (ObjektRelationales 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.
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
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 gene- riert,
- J2EEDemo, eine J2EE-Beispielapplikation, an der das Zusammenspiel von DCache und CMP2BMP demonstriert werden kann.
Die Beschreibungen des Prototyps werden durch UML1 -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 Weiter- entwicklung der einzelnen Prototyp-Komponenten DCache, CMP2BMP und J2EEDemo.
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.
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.
- 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 Anywhere2 )
- 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.
- Wartbarkeit. Änderungen der Anwendung müssen für Benutzer sofort verfügbar gemacht werden können (z.B. Hot Deployment3 in J2EE-basierten Systemen). Änderungen an der Konfiguration müssen schnell und sicher durchgeführt werden können.
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.
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 MehrschichtenArchitekturen lösen lassen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Aufbau eines komplexen Client/Server Systems
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.
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:
Availability =
MTTF
(MTTF + MTTR)
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.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Verfügbarkeit von Systemen nach [ GS91 ]
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 so genannte Round-Robin 4 Verfahrens, welches hintereinander in fester Reihenfolge über die Menge aller verfügbaren Server iteriert um danach wieder beim ersten zu beginnen.
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:
Ausfallsicherheit = Skalierbarkeit + gute Fehlererkennung
Da Loadbalancer einzelne Anfragen nicht selbst beantworten müssen, sondern diese nur weiterleiten5, 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
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 ].
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 Datenbanksystemen6 eingesetzt:
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, standard- ized, 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 ]
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 in dieser Leseprobe nicht enthalten
Abbildung 3: Verteiltes Relationales Datenbanksystem (RDBMS)
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.
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 (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 JavaUmgebung 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:
Abbildung in dieser Leseprobe nicht enthalten
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 SQLStatements 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.
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, Schlüsseleigenschaften usw.) definiert werden, welche vom DBS automatisch zu überwachen sind. Das DBS garantiert somit, dass am Ende einer jeden Transaktion sämtliche Integritätsbedingungen erfüllt sind. Änderungen, welche zu einer Verletzung der Integritätsbedingungen führen, werden abgewiesen, d. h., sie führen zum Zurücksetzen der Transaktion. Voraussetzung für die logische ist die physische Konsistenz der Datenbank, also die korrekte interne Repräsentation und Speicherung der Daten im Datenbanksystem. Zu beachten ist, dass die Konsistenz im Allgemeinen nur vor und nach Ausführung einer Transaktion gewährleistet wird.
3. Isolation (Isolation)
Datenbanksysteme unterstützen typischerweise eine große Anzahl von Benutzern, die gleichzeitig auf die Datenbank zugreifen können. Trotz dieses Mehrbenutzerbetriebs wird garantiert, dass dadurch keine unerwünschten Nebenwirkungen eintreten, wie z. B. das gegenseitige Überschreiben desselben Datenbankobjektes.
4. Dauerhaftigkeit (Durability)
Das DBS garantiert die Dauerhaftigkeit bzw. Persistenz erfolgreicher Transaktionen, deren Operationen vollständig ausgeführt wurden. Dies bedeutet, dass Änderungen dieser Transaktionen alle künftigen Fehler überleben, insbesondere auch Systemabstürze oder Speicherausfälle.
Eine vollständige Implementierung der Isolation ist in der Praxis nur sehr schwierig umzusetzen, wenn man keine beeinträchtigenden Performanceeinbussen in Kauf nehmen will. Aus diesem Grund werden hier meist auch abgeschwächte Formen der Isolation (Isolationslevel) angeboten, die performanter implementiert werden können.
Um zu verstehen, welche Unterscheidungen in diesem Bereich gemacht werden können, müssen die Begriffe Dirty Read, Nonrepeatable Read und Phantom Read erklärt werden. Dies sind Phänomene, die auftreten können, falls keine vollständige Isolation von der Datenbank implementiert ist.
Dirty Read: Ein Dirty Read liegt vor, wenn Transaktion A einen Wert liest, der von der noch nicht abgeschlossenen Transaktion B gesetzt wurde. Die Datenbank kann sich während der Laufzeit von Transaktion B in einem inkonsistenten Zustand befinden. Falls Transaktion B nicht erfolgreich ausgeführt wird, hat Transaktion A einen nicht gültigen oder ‚schmutzigen’ (engl. dirty) Wert gelesen.
Nonrepeatable Read: Transaktion A liest einen Wert, danach ändert eine gleichzeitig laufende Transaktion B diesen Wert und wird abgeschlossen. Falls nun Transaktion A den Wert erneut liest und den durch Transaktion B geänderten Wert erhält, spricht man von einem Nonrepeatable Read. Dies verstößt gegen die Isolationsbedingung.
Phantom Read: Ein Phantom Read geschieht, wenn eine Transaktion neue Datenbankzeilen sehen kann, die erst nach dem Beginn der eigenen Transaktion von einer anderen Transaktion hinzugefügt wurden.
Datenbanksysteme implementieren einen Schutz vor derartigen Phänomenen meist mit Hilfe von sogeanannten Locks (Sperren). Weitere Informationen hierzu findet man beispielsweise unter [ WV02 ] oder [ Amb00 ]. Eine Einordnung des Schutzgrades wird durch die sogenannten Isolationslevel angegeben. Je höher dieser ist, desto mehr Schutz wird geboten. Tabelle 2 zeigt genau, welche der Phänomene in den vier bekanntesten Isolationsleveln auftreten dürfen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Isolationslevel bei Transaktionen
Unter [ Sim03 ] werden anschauliche Beispiele gegeben, mit denen nachzuvollziehen ist, welche Isolationslevel in bekannten Datenbanksystemen unterstützt werden.
Die ACID-Bedingungen für Transaktionen müssen auch in verteilten Datenbanksystemen garantiert werden können. Dies geschieht durch ein sogenanntes Commit-Protokoll. Das einfachste und meistbenutzte Commit-Protokoll ist das Zwei-Phasen-Commit-Protokoll (2PC; engl. two-phase-commit protocol) [ Bir95, Kap. 13.6.1 ]. Beim 2PC-Protokoll wird ein Koordinator festgelegt. Die anderen beteiligten Rechnerknoten werden als Teilnehmer (oder Agenten) bezeichnet. Nachdem der Koordinator bestimmt wurde, verteilt dieser die Aufträge an die anderen Teilnehmer.
Folgende Phasen werden bei Anwendung des 2PC-Protokolls durchlaufen:
1. Wahlphase
a) Der Koordinator fragt die Teilnehmer, ob sie ein Commit durchführen können.
b) Die Teilnehmer teilen dem Koordinator ihre Entscheidung mit.
2. Entscheidungsphase
a) Der Koordinator entscheidet, indem er die erhaltenen Ergebnisse auswertet.
b) Die Knoten, die mit »ja« geantwortet haben, warten auf die Entscheidung und führen bei positivem Bescheid die Transaktion lokal aus.
Oracle bietet mit dem Oracle 9i Real Application Cluster (RAC) ein Zusatzmodul zur ihrer Datenbank Oracle 9i Enterprise Edition, die eine Skalierung von mehreren Oracle 9i- Instanzen ermöglicht. Der Autor beschreibt die Erfahrungen mit der Benutzung einer RAC-Installation auf einem HP-UX 11i Cluster mit insgesamt 10 PA-RISC/8700 Prozessoren und 20 GB Hauptspeicher verteilt auf 4 physikalische Server. Die Rechner waren mit einem 1GB-Ethernet verbunden, die Anbindung an das Storage-System erfolgte per Fibrechannel.
Der einzelnen Cluster-Knoten können von einer zentralen Stelle administriert werden, der Wartungsaufwand nach erfolgreicher Installation und Konfiguration ist nicht bedeutend höher als bei einer einzelnen Oracle-Instanz. Alle bekannten Konzepte (z.B. Archive-Logs, Initialisierungsfiles) funktionieren entweder exakt sehr ähnlich wie in einer Einzel- Installation.
Als größte Fragestellung vor den ersten Tests blieb die Glaubhaftigkeit der folgenden Aussage aus dem Konzept-Handbuch von Oracle, der sehr viel Bedeutung beigemessen wurde:
The concept of transparency implies that Real Application Clusters environments are functionally equivalent to single-instance Oracle database configurations. In other words, you do not need to make code changes to deploy applications on Real Application Clusters if your applications ran efficiently on single-instance Oracle configurations. [ Ora02a, S. 34 ]
Diese Aussage konnte in der Praxis vollkommen nachvollzogen werden. Für einen Datenbank Client (z.B. einen J2EE-kompatiblen Applikationsserver) verhält sich die RAC- Installation wie eine einzelne Oracle Instanz. Die Logik der Lastverteilung, d.h. die Entscheidung, welchem Cluster-Knoten ein Client zugewiesen wird, und das Failover im Falle von Funktionsstörungen auf einem Cluster-Knoten wird vom OCI-Datenbanktreiber übernommen und erfolgt vollkommen unsichtbar und transparent. Transaktionen werden korrekt ausgeführt und verteilt.
Durch diese Transparenz wurde eine Modularisierung geschaffen, die es ermöglicht, die Skalierbarkeit und Ausfallsicherheit von Datenbanksystemen völlig unabhängig von der des restlichen Systems zu betrachten. Eine Zusammenfassung der Fähigkeiten des Oracle Real Application Cluster findet sich im technischen Whitepaper [ Ora01 ].
Mit der Java 2 Enterprise Edition (J2EE) [ Sun01a ] stellt Sun eine komplette Plattform für server-side-computing zur Verfügung. J2EE versucht eine hardware- und betriebssystemunabhängige, multi-user fähige, portable, sichere Plattform für serverseitige Anwendungen zu sein. Ein Meilenstein von J2EE sind die Enterprise JavaBeans, ein Standard für das Erstellen von serverseitigen Komponenten in Java.
J2EE ist eine Spezifikation und kein fertiges Produkt. Es spezifiziert Regeln, die der Entwickler beim Erstellen von serverseitigen Komponenten einhalten muss. Die Hersteller implementieren dann die J2EE Spezifikation in ihren J2EE-kompatiblen Produkten. Aus diesem Grund ist J2EE nicht an einen Hersteller gebunden, auch nicht an den Erfinder Sun Microsystems. Es gibt eine Reihe kommerzieller Anbieter von Applikationsservern, die die J2EE-Spezifikation implementieren.
J2EE kann man auch als Zusammenfügung verschiedenster sogenannter „middle-ware- services“ oder Dienste begreifen [ NBW+01 ]. Die wichtigsten werden im Folgenden kurz erläutert:
Enterprise JavaBeans (EJB): EJB [ Mon01 ] [ RAJ02 ] definiert, wie serverseitige Komponenten aussehen und definiert einen „Vertrag“ zwischen den Komponenten und dem Applikationsserver, der die Komponenten verwaltet. EJB ist einer der Hauptbestandteile von J2EE und wird im Kapitel 4.2 ausführlich behandelt.
Remote Method Invocation (RMI) and RMI-IIOP: RMI stellt Interprozess- Kommunikation und andere Services für Kommunikation zur Verfügung. RMI-IIOP ist eine Erweiterung von RMI und verwendet das Internet-Inter-ORB Protokoll und kann somit für die Integration von bestehenden CORBA-Komponenten verwendet werden. RMI bildet die Basis für die Kommunikation der einzelnen Komponenten in verteilten J2EE-Systemen.
Java Naming and Directory Interface (JNDI): JNDI lokalisiert den physikalischen Ort von verwendeten Komponenten und anderen Ressourcen im Netzwerk. Diese Ressourcen wie Datenquellen oder Enterprise JavaBeans werden dem zentralen JNDI-Service bekannt gemacht und können von Clients erfragt werden.
Java Database Connectivity (JDBC): JDBC ist die am weitesten verbreitete relationale Datenbankschnittstelle für Javaprogramme. Sie wurde in Kapitel 3.2 bereits ausführlich behandelt.
Java Transaction API (JTA) und Java Transaction Service (JTS): Die JTA und JTSSpezifikation erlaubt sichere und verlässliche Übertragung der Komponenten und deren Daten über das Netzwerk (siehe Kapitel 4.4).
Java Messaging Service (JMS): JMS dient der asynchronen Kommunikation zwischen Komponenten. Message-Driven-Beans, ein Typ der Enterprise JavaBeans, nutzen beispielsweise diese Schnittstelle.
Java Servlets and JavaServer Pages (JSP): Java Servlets und JSP sind Technologien, die zur Entwicklung dynamischer Webseiten eingesetzt werden.
JavaMail: JavaMail ist eine Schnittstelle und dient dem Versenden und Empfangen von E- Mails aus Javaprogrammen.
Connectors: Die Connectors Architecture verbindet J2EE mit bereits bestehenden Mainframe- und Enterprise Resource Planning (ERP) Systemen.
Enterprise JavaBeans sind einer der wichtigsten Teile der Java 2 Enterprise Edition Plattform. Sun Microsystems definiert Enterprise JavaBeans 2.0 folgendermaßen:
The Enterprise JavaBeans (EJB) architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification. [SUN01]
Die EJB-Architektur ist eine neue serverseitige komponentenbasierte Architektur für verteilte unternehmenskritische Geschäftsanwendungen. Sie spezifiziert Schnittstellen, Aufgaben und Zuständigkeiten einzelner Komponenten. Die EJB-Architektur unterstützt durch ein breites Dienstleistungsspektrum die schnelle Realisierung von skalierbaren, robusten und mehrbenutzerfähigen serverseitigen Anwendungssystemen.
Da die EJB-Spezifikation kein Produkt ist, muss sie von den Server- und Applikationsserver-Herstellern umgesetzt werden.
Der Einsatz von EJB eignet sich besonders als serverseitiges Komponentenmodell für verteilte Mehrschichten-Umgebungen. Webbasierte Anwendungen weisen häufig eine Multitier-Architektur auf, wobei die mittlere Schicht für die Anwendungslogik verantwortlich ist. Enterprise JavaBeans stellen ein Komponentenmodell für die Realisierung der Anwendungslogik in dieser mittleren Schicht zur Verfügung, es ist damit eine so genannte Middleware.
EJB bietet zudem Unterstützung für Basisdienste wie Transaktionsverwaltung, Sicherheits-, Persistenz-, oder Ressourcenmanagement. Entwickler von Web-Anwendungen werden dadurch entlastet und können sich auf die Implementierung der eigentlichen Präsentationsund Anwendungslogik konzentrieren.
Im Folgenden werden die wesentlichen Bestandteile der EJB-Spezifikation bzw. EJBArchitektur und -Laufzeitumgebung vorgestellt und detailliert erläutert. Dadurch wird ein Überblick über die einzelnen Bestandteile dieser Architektur gegeben und die Eignung und Praxistauglichkeit von EJB für die Entwicklung von komplexen verteilten Client/Server- Anwendungen kann somit besser erörtert werden. Abbildung 4 gibt eine einfache Übersicht über die EJB-Architektur.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: EJB-Architektur
Der EJB-Server
Zurzeit existiert eine Vielzahl von Anbietern für EJB-Server am Markt. Ein EJB-Server kann als Teil eines Applikationsservers gesehen werden, der nicht nur die Implementierung der EJB-Spezifikation bietet, sondern die aller geforderten J2EE Spezifikationen. In der Praxis gibt es nur sehr wenige Hersteller, die reine EJB-Server, aber viele, die komplette Applikationsserver vertreiben. Der Benutzer der EJB-Plattform ist somit nicht wie bei anderen Frameworks auf einen bestimmten Serverhersteller eingeschränkt, sondern kann
[...]
1 UML ist eingetragenes Warenzeichen der Object Management Group (OMG). Für mehr Informationen über die Unified Modelling Language siehe [ OMG03 ].
2 ‚Write Once, Run Anywhere’ ist ein Warenzeichen von Sun Microsystems Inc.
3 Feature verschiedener J2EE Server, bei dem bestimmte Verzeichnisse vom Server zur Laufzeit überwacht und neue Applikationen automatisch erkannt und aktiviert werden.
4 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.
5 Teilweise ist es nötig, die ankommenden Anfragen auf der Applikationsschicht (Schicht 7 des OSI- Schichtenmodells [ DZ83 ]) zu analysieren (z.B. um Informationen über die HTTP-Session herauszufiltern). Die dafür nötige Rechenleistung ist aber vernachlässigbar.
6 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.
