Transaktionssteuerung in EJB-Applikationen im Rahmen einer Standardarchitektur für betriebliche Informationssysteme. Diplomarbeit

Transkript

1 Transaktionssteuerung in EJB-Applikationen im Rahmen einer Standardarchitektur für betriebliche Informationssysteme Diplomarbeit Michael Wufka Fachbereich Informatik Fachgebiet Softwaretechnologie Betreuerin: Prof. Dr. Mira Mezini

2 2 Transaktionssteuerung in EJB-Applikationen Erklärung Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegeben Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. München, Michael Wufka An dieser Stelle bedanke ich mich herzlich bei denen, die zu dieser Diplomarbeit beigetragen haben. Herausheben möchte ich dabei meine Betreuerin an der TU Darmstadt, Prof. Dr. Mira Mezini, sowie die Betreuer bei sd&m Research: Prof. Dr. Johannes Siedersleben, Ulrike Hammerschall und Gerd Beneken. Stellvertretend für die vielen anregenden Diskussionen mit sd&m-mitarbeitern sei Markus Uhlendahl genannt. Besonderer Dank gebührt auch meinen Eltern und allen anderen, die mich bei meinem Studium begleitet und unterstützt haben.

3 Transaktionssteuerung in EJB-Applikationen 3 1 EINLEITUNG 5 2 BETRIEBLICHE INFORMATIONSSYSTEME Architekturprinzipien Standardarchitektur Software-Kategorien Transaktionen Einführung Transaktionstypen Sperrstrategien 12 3 ENTERPRISE JAVA BEANS Einführung Einordnung Dienste Programmierung Beispiel Zusammenfassung Architektur von EJB-Applikationen Konventionelle Architekturen nach den Sun-Blueprints sd&m Standardarchitektur EJB Transaktionen bei EJB Deklarative Demarkation von Transaktionen Programmatische Demarkation von Transaktionen Probleme 25 4 VARIANTEN ZUR TRANSAKTIONSSTEUERUNG Übersicht Rahmenbedingungen Anforderungen Beispielanwendung: Telecom Billing System (TBS) 30 5 TRANSAKTIONSSTEUERUNG IN DER SUN-ARCHITEKTUR Pessimistische Sperrstrategie Architektur Bewertung Optimistische Sperrstrategie Architektur Bewertung 35 6 TRANSAKTIONSSTEUERUNG IN DER SD&M-ARCHITEKTUR Architektur Überblick 36

4 4 Transaktionssteuerung in EJB-Applikationen Schnittstellen Sperrstrategie-unabhängige Teile der Implementierung Konfiguration der Schnittstellenimplementierungen Bewertung Optimistische Sperrstrategie Grundsätzliche Probleme und Designentscheidungen Implementierung Bewertung Pessimistische Sperrstrategie Einführung Implementierung Bewertung Einsatz einer Datenbankzugriffsschicht Motivation QDI Beispielimplementierung mit der QDI Bewertung Zusammenfassung 62 7 VERGLEICH UND BEWERTUNG DER SPERRSTRATEGIEN Vorgehensweise Korrektheitstests JUnit Testfälle Performance-Tests Batch-Betrieb Interaktiver Betrieb Verhalten der pessimistischen Sperrstrategie Vorüberlegungen Datenbankverbindungen als knappe Ressource Verhalten mit leistungsfähigerem JDBC-Treiber Bewertung Zusammenfassung 83 8 ZUSAMMENFASSUNG Ergebnisse Ausblick 86 ABBILDUNGSVERZEICHNIS 87 LITERATUR 88

5 Transaktionssteuerung in EJB-Applikationen 5 1 Einleitung Enterprise Java Beans Der Begriff Enterprise Java Beans (kurz EJB) beschreibt eine von SUN erstellte Spezifikation für ein verteiltes Komponentenmodell, das als Grundlage für große Informationssysteme in Unternehmen gedacht ist. Abgesehen von einem Teil des Namens hat EJB nichts mit dem hauptsächlich bei Anwendungen mit graphischen Benutzeroberflächen eingesetzten Komponentenmodell Java Beans zu tun. Da dieses in unserer Arbeit keine Rolle spielt, steht der Begriff Bean im folgenden verkürzend für Enterprise Bean. Der beachtliche kommerzielle Erfolg von EJB, der sich unter anderem an der hohen Zahl kommerzieller Produkte [SUN-Solutions] ablesen lässt, die diesen Standard implementieren, liegt darin begründet, dass die Entwicklung von darauf basierenden Anwendungen durch die zahlreichen gebotenen Services sehr effizient ist. Daneben sind EJB-Applikationen in hohem Maße plattformunabhängig und versprechen durch ihren komponentenbasierten Aufbau ein erhebliches Potential für Wiederverwendbarkeit. In der Praxis zeigen sich jedoch Probleme beim naiven Einsatz von Enterprise Java Beans. Diese liegen vor allem in den Bereichen Performance und Wartbarkeit. Große Anwendungen mit vielen gleichzeitig aktiven Benutzern haben bei der leichtfertigen Benutzung von Entity-Beans starke Performance-Probleme. Daneben gestaltet sich die Wartung von EJB-Anwendungen aus verschiedenen Gründen, auf die später noch im Detail eingegangen wird, schwierig, was wegen ihrer üblicherweise langen Lebensdauer besonders kritisch ist. sd&m Die vorliegende Diplomarbeit entstand in Zusammenarbeit mit sd&m Research, der Forschungs- und Entwicklungsabteilung der sd&m AG [sd&m]. Diese erstellt Individualsoftware vornehmlich für betriebliche Informationssysteme. Die Aufgaben von sd&m Research erstrecken sich unter anderem auf die Evaluierung neuer Techniken, den Wissentransfer zwischen einzelnen Projekten und die Entwicklung von Standardarchitekturen, die als Basis für die Projektarbeit dienen. Aufgabe Es gibt zwei gegensätzliche Sperrstrategien, um die Integrität von Transaktionen zu garantieren: Die pessimistische Strategie sperrt Daten beim ersten Zugriff für alle anderen Benutzer und stellt so die Isolierung untereinander sicher. Die optimistische Strategie dagegen erlaubt den gleichzeitigen Zugriff und prüft erst am Ende einer Transaktion, ob Konflikte aufgetreten sind. Beide Strategien haben Vor- und Nachteile, so dass es vom konkreten Einsatzfall abhängt, welche davon zu bevorzugen ist. In dieser Arbeit untersuchen wir die Frage nach geeigneten vor allem im Sinne von performanten Mechanismen zur Steuerung von Transaktionen im Rahmen der bei sd&m Research entwickelten Standardarchitektur für EJB-Applikationen. Dazu implementieren wir beide Sperrstrategien und nehmen anhand einer Beispielanwendung Messungen zur Beurteilung der Performance unter unterschiedlichen Rahmenbedingungen wie beispielsweise dem Nebenläufigkeitsgrad und der Konfliktwahrscheinlichkeit vor. Abschließend leiten wir daraus Empfehlungen zur Wahl der Sperrstrategie in Abhängigkeit von den Anforderungen der Anwendung ab.

6 6 Transaktionssteuerung in EJB-Applikationen Überblick über die Arbeit In den Kapiteln 2 und 3 stellen wir mit betrieblichen Informationssystemen und Enterprise Java Beans die Grundlagen dieser Arbeit vor. Anschließend geben wir in Kapitel 4 einen Überblick über die betrachteten Implementierungsvarianten, die vorausgesetzten Rahmenbedingungen und die Anforderungen, die an eine befriedigende Lösung zu stellen sind, sowie die verwendete Beispielanwendung. In den Kapiteln 5 und 6 beschreiben wir daraufhin die Implementierungen beider Sperrstrategien im Rahmen zweier verschiedener Architekturen für EJB-Anwendungen: einer von Sun vorgeschlagenen Architektur und der bei sd&m entwickelten Standardarchitektur EJB. Nach dem Vergleich und der Bewertung der beiden Sperrstrategien im Kapitel 7 schließt Kapitel 8 mit einer Zusammenfassung.

7 Transaktionssteuerung in EJB-Applikationen 7 2 Betriebliche Informationssysteme Mit betrieblichen Informationssystemen behandelt diese Arbeit eine Unterklasse von Software- Applikationen. Wie die Bezeichnung Enterprise Java Beans schon andeutet, liegt der zentrale Fokus des EJB-Komponentenmodells auf Anwendungen, die in Unternehmen eingesetzt werden. Dabei spielt die Art der Organisation (also ein privatwirtschaftliches Unternehmen im Gegensatz z.b. zu einer öffentlich-rechtlichen Behörde) keine Rolle. Wichtig sind vielmehr die Rahmenbedingungen, unter denen Softwaresysteme in solchen Organisationen verwendet werden. Dazu gehören vor allem: Komplexität: Die Komplexität drückt sich durch einen großen Umfang an fachlichen Anforderungen aus, die unterstützt werden. Daneben sind die Anwendungen oft in eine heterogene und komplexe Anwendungslandschaft eingebettet, d.h. sie greifen z.b. auf existierende Datenbanken zu. Größe: Nicht nur der fachliche Umfang, sondern auch die Zahl der Benutzer ist beträchtlich. Dies führt zu schwierig erfüllbaren Anforderungen an die Performance und die Skalierbarkeit. Lebensdauer: Nicht zuletzt wegen der erforderlichen hohen Investitionskosten ist die Lebensdauer von betrieblichen Informationssystemen sehr hoch und überschreitet häufig mehrere Jahrzehnte. Da sich in solchen Zeitspannen Änderungen nicht vermeiden lassen, ist die Wartbarkeit genauso wichtig wie möglichst geringe Kosten zur Erstellung der Software. Kritische Bedeutung: In der Regel hängt die Existenz eines Unternehmens vom reibungslosen Funktionieren seiner betrieblichen Informationssysteme ab, was technische Maßnahmen wie Redundanz, Transaktionen etc. erforderlich macht. Typische Beispiele betrieblicher Informationssysteme sind Buchungssysteme in Banken, Auftragsabwicklungssysteme in Industrieunternehmen oder Bestellungsverwaltungssysteme in Online-Shops. Abschnitt 2.1 beschreibt wichtige generelle Architekturprinzipien für betriebliche Informationssysteme, während 2.2 näher auf Transaktionen eingeht. 2.1 Architekturprinzipien Dieses Unterkapitel beschreibt einige allgemeine Architekturprinzipien, die für die erfolgreiche Entwicklung betrieblicher Informationssysteme von zentraler Bedeutung sind. Viele dieser Konzepte und Begriffe wurden bei sd&m Research unter dem Dach von Quasar (Qualitäts- Software-Architektur) [Quasar] entwickelt oder verfeinert bzw. systematisiert. Zunächst stellt Abschnitt eine Standardarchitektur für komponentenbasierte Applikationen vor, bevor die Aufteilung von Software in Kategorien beschreibt Standardarchitektur Die Motivation, die der Strukturierung von Softwaresystemen in Komponenten zugrunde liegt, kann treffend mit dem lateinischen divide et impera beschrieben werden: Durch das Aufteilen komplexer Systeme in kleinere Module soll ihre Entwicklung besser beherrschbar werden [Heineman].

8 8 Transaktionssteuerung in EJB-Applikationen Der Komponentenbegriff wird in der Literatur relativ uneinheitlich verwendet. Dies trifft insbesondere für die Granularität des Konzeptes zu, d.h. die Frage, wie groß die Software-Einheiten sind, für die der Begriff verwendet wird. Manchmal werden bereits einzelne Klassen als Komponenten bezeichnet. In anderen Fällen wird der Begriff für komplexe Subsysteme großer Software-Anwendungen verwendet. Nach [Siedersleben] ist eine Komponente eine logisch in sich abgeschlossene Einheit, die eine bestimmte Menge an Schnittstellen implementiert, eine weitere Menge von Schnittstellen verwendet und die gegen jede andere Implementierung der angebotenen Schnittstellen austauschbar ist. Diese Definition legt zwar ebenfalls nicht genau fest, wie fein- oder grobgranular der Begriff gemeint ist, tendiert aber doch dazu, eher größere Module wie Auftragsverwaltung im Gegensatz zu einzelnen Klassen wie Kunde als Komponente zu bezeichnen. Dies stimmt mit der Verwendung in dieser Arbeit überein. Weiterhin beschreibt [Quasar] den inneren Aufbau einer Komponente genauer. Jede Komponente besteht aus drei verschiedenen Sorten von Bausteinen: Anwendungsfälle bieten Funktionen für Benutzer bzw. andere Komponenten an, indem sie die exportierten Schnittstellen der Komponente implementieren. Sie stellen somit den einzigen Teil dar, der von anderen Programmteilen direkt benutzt werden kann. Anwendungsentitäten repräsentieren die eigentlichen Business-Objekte der Anwendung wie Kunde oder Auftrag. Für ihre Verwaltung sind die Anwendungsentitäten-Verwalter zuständig. Sie bieten Methoden zur Erzeugung, zum Wiederfinden und zum Löschen der Anwendungsentitäten an, und nehmen damit die Rolle der Fabrik im Sinne des Factory-Patterns [Gamma] ein. Abbildung 1 zeigt den prinzipiellen Aufbau einer komponentenbasierten Anwendung, die diesen Richtlinien folgt. GUI, Batch, Nachbarsysteme A-Fall 1 A-Fall 2 Komponente 1 A-Fall 1 A-Fall 2 A-Fall 3 A-Fall 1 A-Fall 2 A-Fall 3 A-Verwalter + A-Verwalter + A-Entitäten A-Verwalter + A-Entitäten Komponente 2 A-Entitäten Komponente 3 A-Verwalter + A-Entitäten Anwendungskern Abbildung 1: Aufbau einer komponentenbasierten Anwendung Im Beispiel besteht der Anwendungskern aus drei Komponenten. Komponente 1 besteht nur aus Anwendungsfällen, und greift zu deren Implementierung auf die beiden anderen Komponenten zu. Diese bestehen jeweils aus drei Anwendungsfällen, die auf die eigenen Anwendungsentitä-

9 Transaktionssteuerung in EJB-Applikationen 9 ten und ihre Verwalter sowie teilweise auf die Anwendungsfälle anderer Komponenten zugreifen. Clients in Form von graphischen Benutzeroberflächen (GUI), Batch-Skripten oder anderen Nachbarsystemen verwenden lediglich die von den Anwendungsfällen angebotenen Schnittstellen Software-Kategorien Software-Module, also z.b. Klassen oder Komponenten, lassen sich in verschiedene Kategorien (in Analogie zu Blutgruppen) einteilen [Quasar]: A-Software befasst sich mit den fachlichen Anforderungen der Anwendung. Eine Klasse Kunde oder ein Algorithmus zur Erstellung einer Telefonrechnung sind typische Beispiele. T-Software löst technische Probleme wie z.b. den Zugriff auf eine Datenbank oder die Kommunikation mit anderen Rechnern in verteilten Systemen. 0-Software ist neutral, d.h. von fachlichen und technischen Aspekten unabhängig. Vertreter dieser Kategorie sind z.b. die Klassen im Package java.util, wie etwa Stack oder HashMap. AT-Software vermischt A- und T-Software, hängt also sowohl von fachlichen als auch von technischen Aspekten ab. Beispielsweise fällt eine Klasse Kunde, die Code zur persistenten (d.h. dauerhaften) Speicherung in einer Datenbank enthält, in diese Gruppe. R-Software schließlich ist eine Spezialform von AT-Software. Sie zeichnet sich dadurch aus, dass sie sehr stereotyp und damit generierbar ist. Wenn z.b. aus den Feldern einer Klasse Kunde automatisch der Code zum Datenbankzugriff erzeugt wird, so gehört dieser in die Kategorie R. Die angenehmste Kategorie ist zweifellos 0-Software, da sie durch ihre große Unabhängigkeit von der Umwelt ideal wiederverwendbar ist. Auch A- und T-Software sind gut beherrschbar. A-Software hängt nur von fachlichen Inhalten der Anwendung ab, und ist nicht vom technischen Umfeld sowie Änderungen daran betroffen, während T-Software umgekehrt nur bei technischen Änderungen (wie z.b. dem Umstieg auf ein anderes Datenbanksystem) anzupassen ist. Im starken Gegensatz dazu steht AT-Software, da sie von Fachlichkeit und Technik durchsetzt und damit sehr schwer beherrschbar ist. Somit sollte man sie, falls möglich, durch R-Software ersetzen. Zur Veranschaulichung der unangenehmen Eigenschaften von AT-Software ziehen wir den Aspekt der Wartbarkeit heran. Da betriebliche Informationssysteme eine lange Lebensdauer besitzen, ist zu erwarten, dass sich während des Einsatzes solcher Softwaresysteme sowohl fachliche als auch technische Änderungen ergeben. Fachliche Anpassungen können z.b. bei geänderten Geschäftsprozessen oder Vorschriften nötig werden und in einer Modifikation oder Erweiterung der Funktionen resultieren, während technische Änderungen häufig durch gewandelte Rahmenbedingungen oder technische Fortschritte ausgelöst werden und z.b. aus einem Umstieg auf eine neue Version eines eingesetzten Tools bestehen. Besonders unangenehm ist, dass beide Sorten von Änderungen in voneinander weitgehend unabhängigen Zyklen erfolgen. Dies ist auch die zentrale Motivation zur Vermeidung von AT-Software: Während man bei der sauberen Trennung in A- und T-Software sowohl bei fachlichen als auch bei technischen Änderungen jeweils nur den entsprechenden Teil des gesamten Systems anpassen muss, ist AT-Software von jeder Modifikation betroffen und deshalb besonders teuer in der Wartung. Unglücklicherweise braucht man allerdings eine Verbindung zwischen A- und T-Software. Um beispielsweise eine fachliche Klasse wie Kunde dauerhaft zu speichern, wird sie in irgendeinem Software-Modul auf eine konkrete technische API (wie z.b. JDBC zum Datenbankzugriff) um-

10 10 Transaktionssteuerung in EJB-Applikationen gesetzt. Dieses Modul hängt dann sowohl von technischen Aspekten wie der verwendeten Datenbank als auch von der Fachlichkeit der Anwendung (z.b. den konkreten Attributen der Klasse Kunde) ab, und ist somit der Software-Kategorie AT zuzuordnen. An dieser Stelle kann man sich sehr elegant mit R-Software behelfen. Indem man in unserem Beispiel die Abbildung einer Klasse auf eine Datenbank generiert, erfüllt man den Zweck von AT-Software, ohne sich ihren Nachteil der aufwändigen Wartung einzuhandeln. Ändern sich fachliche Aspekte, kommt z.b. ein neues Attribut zur Klasse Kunde hinzu, so wird das Modul lediglich neu generiert. Bei technischen Änderungen, z.b. dem Umstieg auf ein anderes Datenbanksystem, wird der Generator selbst angepasst und anschließend eine Neugenerierung des Moduls angestoßen. Zusammenfassend bleibt hervorzuheben, dass die Trennung von fachlichen und technischen Aspekten die wichtigste Maßnahme ist, um die insbesondere bei betrieblichen Informationssystemen bedeutsame Wartbarkeit zu erhöhen. 2.2 Transaktionen In diesem Unterkapitel stellen wir die Grundlagen des Transaktionskonzeptes vor. Darauf folgend verfeinern wir den Begriff der Transaktion durch einige Definitionen und behandeln schließlich zwei gegensätzliche Sperrstrategien zur Implementierung von Transaktionen Einführung Der Begriff Transaktion beschreibt eine Sequenz von Operationen, die eine Datenbank (oder allgemeiner: ein zustandsbehaftetes System) von einem Zustand in einen neuen überführt und dabei die folgenden vier Eigenschaften besitzt [Gray]: Atomarität: Alle Aktionen der Transaktion werden entweder vollständig oder gar nicht ausgeführt. Konsistenz: Eine Transaktion überführt die Datenbank von einem konsistenten Zustand in einen neuen konsistenten Zustand. Isolation: Auch wenn mehrere Transaktionen gleichzeitig aktiv sind, hat jede eine isolierte Sicht auf die Daten, als ob sie alleine laufen würde. Dauerhaftigkeit: Wenn eine Transaktion erfolgreich beendet wurde, dann sind die Änderungen, die sie vorgenommen hat, dauerhaft. Wegen der äquivalenten englischen Begriffe atomicity, consistency, isolation und durability werden diese Eigenschaften auch zusammenfassend mit dem Akronym ACID bezeichnet. Genauer besteht ein transaktionsverarbeitendes System nach dem X/Open-Transaktionsmodell 1 aus drei Komponenten [Bernstein], wie Abbildung 2 zeigt. Die Steuerung der Transaktionen erfolgt von einem Anwendungsprogramm aus, das dazu Methoden zum Starten, Abschließen und Verwerfen von Transaktionen aufruft, die der Transaktionsmanager anbietet. Sogenannte Ressourcenmanager (typischerweise Datenbanksysteme) sind für die eigentliche Verwaltung der Daten verantwortlich. Das Anwendungsprogramm benutzt sie direkt zum Zugriff auf die An- 1 Das X/Open-Transaktionsmodell (siehe z.b. [Britton]) ist der grundlegende Standard für verteilte Transaktionen, d.h. Transaktionen, die sich über mehrere Datenbanksysteme erstrecken. Die Begriffe sind jedoch auch für den hier betrachteten einfacheren Fall von lokalen Transaktionen zutreffend.

11 Transaktionssteuerung in EJB-Applikationen 11 wendungsdaten, während die Steuerung der Transaktionen indirekt über den Transaktionsmanager erfolgt. Anwendungsprogramm Ressourcenmanager Transaktionsmanager Abbildung 2: X/Open Transaktionsmodell Transaktionstypen Nach [Quasar] kann man Transaktionen unter zwei Sichtweisen betrachten: aus Anwendungssicht und aus technischer Sicht. Fachliche Transaktionen werden durch die Anwendung gesteuert. Das Augenmerk liegt auf der Festsetzung, wann Transaktionen aus fachlicher Sicht beginnen und enden, was auch als Transaktionsdemarkation bezeichnet wird. Dazu stehen gewöhnlich die Operationen begin, commit und rollback zur Verfügung, die eine Transaktion starten, normal abschließen oder abbrechen. Technische Transaktionen dagegen kümmern sich darum, wie das fachliche Verhalten technisch umgesetzt wird. Eine typische Fragestellung hierbei ist die gewählte Sperrstrategie. Zwischen fachlichen und technischen Transaktionen muss nicht unbedingt eine eins-zu-eins Entsprechung bestehen; häufig wird eine fachliche Transaktion in mehrere technische Transaktionen umgesetzt. Abbildung 3 illustriert dies: Eine fachliche Transaktion Mehrere technische Transaktionen Abbildung 3: Aufteilung einer fachlichen in mehrere technische Transaktionen Fachliche Transaktionen unterscheiden wir weiter nach ihrer zeitlichen Länge. Dabei definieren wir vier Klassen: Einschritt-Transaktionen dauern nur für die Länge eines Methodenaufrufs auf dem Server. Mehrschritt-Transaktionen können mehrere Methodenaufrufe auf dem Server umfassen. Mehrschritt-Transaktionen mit Benutzereingaben erlauben zusätzlich den Aufruf von Methoden, die Benutzereingaben erfordern. Da Menschen im allgemeinen Antwortzeiten haben, die deutlich über den Millisekundenbereich hinausgehen, kann diese Transaktionsklasse um ein Vielfaches länger dauern als die beiden vorigen Klassen.

12 12 Transaktionssteuerung in EJB-Applikationen Lange Transaktionen schließlich bestehen auch nach Neustarts der Applikation weiter und haben oft eine Lebensdauer von Tagen oder Wochen. Diese Arbeit beschränkt sich auf die ersten drei Klassen von Transaktionen. Da lange Transaktionen die persistente Speicherung des Transaktionszustandes erfordern, sieht man für sie aus Performancegründen in aller Regel ohnehin einen völlig anderen Mechanismus vor als für die kürzeren Typen. Zur Verkürzung der Schreibweise bezeichnet im folgenden der Begriff kurze Transaktion zusammenfassend Einschritt-Transaktionen und Mehrschritt-Transaktionen, wogegen längere Transaktion für Transaktionen mit Benutzereingaben steht Sperrstrategien Es gibt zwei gegensätzliche Sperrstrategien [Vossen], um die ACID-Eigenschaften zu garantieren: die pessimistische und die optimistische Strategie. Erstere ist weit verbreitet und liegt vielen Datenbanksystemen zugrunde, wogegen letztere in der Praxis weniger üblich ist. Pessimistische Sperrstrategie Die pessimistische Strategie beruht auf der Idee, Datensätze beim ersten Zugriff zu sperren. Dies bewirkt, dass bis zum Ende der jeweiligen Transaktion kein anderer Benutzer auf diese Datensätze zugreifen kann. In der Praxis setzt man üblicherweise zwei verschiedene Typen von Sperren ein, da man einen möglichst hohen Grad an Parallelität erreichen will: Lese- und Schreibsperren. Dieser Aufteilung liegt die Einsicht zugrunde, dass es zwischen zwei gleichzeitig aktiven Benutzern, die ein Datenelement nur lesen wollen, eigentlich gar keinen Konflikt gibt. Somit verhindert das Setzen einer Schreibsperre den Zugriff für alle anderen Benutzer, während eine Lesesperre nur gleichzeitige Benutzer mit Schreibabsicht ausschließt. Von diesem recht einfachen Schema gibt es eine sehr hohe Zahl an Varianten und Spezialfällen, die sich z.b. mit dem Setzen von Sperren auf hierarchischen Objektstrukturen beschäftigen und oft weitere, komplexere Typen von Sperren definieren. Optimistische Sperrstrategie Im Gegensatz dazu sperrt die optimistische Strategie die Datensätze nicht, sondern erlaubt zunächst völlig unbeschränkten Zugriff darauf (Lesephase). In dieser Phase wird jedoch noch nicht in die Datenbank geschrieben; Änderungen, die der Client vornimmt, erfolgen auf Kopien der Daten. Erst am Ende der Transaktion erfolgt eine Überprüfung, ob Konflikte aufgetreten sind und die Transaktion deshalb abgebrochen werden muss (Schreib- und Validierungsphase). Die Erkennung von Konflikten kann auf verschiedene Weisen geschehen. Ein verbreitetes Verfahren ist die Verwendung von Versionsnummern. Jedes Datenelement hat bei dieser Vorgehensweise ein zusätzliches Feld, das die aktuelle Version dieses Elementes enthält. Am Ende der Transaktion wird geprüft, ob die Version, die in der Transaktion gelesen wurde, mit derjenigen übereinstimmt, die aktuell in der Datenbank steht. Ist dies der Fall, so kann die Transaktion erfolgreich beendet werden. Andernfalls (d.h. wenn in der Datenbank eine höhere Versionsnummer steht) liegt ein Konflikt vor, da das Datenelement zwischen dem Lesen und Zurückschreiben von einer anderen Transaktion verändert wurde. Weil diese Änderung verloren wäre, wenn man den Konflikt ignoriert, wird die gerade in der Validierungsphase befindliche Transaktion abgebrochen. Der Client startet dann die Transaktion erneut oder gibt dem Benutzer eine Fehlermeldung aus. Statt einer Versionsnummer kann man auch Zeitstempel oder sogenannte before-images verwenden, die eine vollständige Kopie der Daten vor dem Start der Transaktion enthalten.

13 Transaktionssteuerung in EJB-Applikationen 13 Beispiel Um die Funktionsweise der beiden Sperrstrategien zu verdeutlichen, betrachten wir mit dem sogenannten Lost-Update-Problem exemplarisch eine typische Fehlerbedingung, die ohne diese Maßnahmen auftreten könnte. Als Beispiel dient eine Tabelle Konto, die unter anderem die Höhe des aktuellen Kontostandes enthält. Wenn nun zwei Benutzer den Kontostand um einen bestimmten Betrag erhöhen wollen, kann es bei gleichzeitigem und unkontrollierten Ablauf zu verschiedenen fehlerhaften Ergebnissen kommen. Jeder der beiden Clients liest zunächst den aktuellen Stand des Kontos, was durch die Operation lesen beschrieben wird, erhöht diesen Wert dann um den zu überweisenden Betrag und schreibt ihn mittels der Operation schreiben zurück. Wenn die Clients z.b. den Kontostand um 20 bzw. 30 erhöhen wollen, und dieser sich am Anfang auf 100 beläuft, dann sieht ein korrekter Ablauf wie folgt aus: x 1 = lesen 1 (konto) = 100 // Client 1 liest x (= 100) x 1 = x = 120 // Client 1 erhöht x um 20 schreiben 1 (konto, 120) // Client 1 schreibt x zurück x 2 = lesen 2 (konto) = 120 // Client 2 liest x (= 120) x 2 = x = 150 // Client 2 erhöht x um 30 schreiben 2 (konto, 150) // Client 2 schreibt x zurück In diesem Fall erfolgen die Operationen von Client 2 vollständig nach denen von Client 1, so dass es zu keinen Problemen kommt. Überschneidet sich jedoch die Ausführung der beiden Clients wie im folgenden Ablauf, kann ein falsches Resultat entstehen: 1 x 1 = lesen 1 (konto) = 100 // Client 1 liest x (= 100) 2 x 2 = lesen 2 (konto) = 100 // Client 2 liest x (= 100) 3 x 1 = x = 120 // Client 1 erhöht x um 20 4 schreiben 1 (konto, 120) // Client 1 schreibt x zurück 5 x 2 = x = 130 // Client 2 erhöht (das alte!) x um 30 6 schreiben 2 (konto, 130) // Client 2 schreibt falsches Ergebnis Das inkorrekte Ergebnis kommt hier zustande, da die Änderung durch den ersten Client vom zweiten einfach überschrieben wird. Dieser Ablauf würde von der pessimistischen Sperrstrategie dadurch verhindert, dass Client 2 in Zeile 2 keinen Zugriff auf den Stand des Kontos bekäme, da Client 1 bereits in Zeile 1 wegen der Absicht zu schreiben eine Schreibsperre darauf erlangt hätte 2. Somit müsste Client 2 warten, bis Client 1 seine Transaktion abgeschlossen hat, so dass sich automatisch der erste gezeigte Ablauf ergeben hätte. Im Falle der optimistischen Sperrstrategie würde der Transaktionsmanager bei der Validierung des Schreibzugriffs in Zeile 6 feststellen, dass die Version des Kontostandes, den Client 2 in der Transaktion gelesen hat, inzwischen veraltet ist, da ja inzwischen Client 1 den Wert verändert und damit den Versionszähler in der Datenbank erhöht hat. Somit würde die Transaktion zurückgesetzt, und Client 2 müsste sie wiederholen. Auch in diesem Fall ergäbe sich dann der erste gezeigte Ablauf. Die zwei Sperrstrategien haben jeweils bestimmte Vor- und Nachteile, die wir später noch ausführlich betrachten. Deshalb haben beide ihre Existenzberechtigung, und es hängt von den Charakteristiken der jeweiligen Anwendung ab, welche zu bevorzugen ist. 2 Der genaue Ablauf hängt von der Implementierung der Sperrstrategie ab. Im hier geschilderten Beispiel gehen wir davon aus, dass es nicht möglich ist, eine Lesesperre auf eine Schreibsperre zu erweitern. Dies ist bei vielen Systemen der Fall, da so zyklische Wartebedingungen (Deadlocks) verhindert werden können. Ohne diese Restriktion würde Client 1 in Zeile 4 keine Schreibsperre erhalten, da ja Client 2 bereits in Zeile 2 eine Lesesperre auf das gleiche Objekt angefordert hat. Somit wäre auch in diesem Fall der gezeigte inkorrekte Ablauf verhindert.

14 14 Transaktionssteuerung in EJB-Applikationen 3 Enterprise Java Beans Nach der Vorstellung der allgemeinen Grundlagen zu Architekturprinzipien und Transaktionen im letzten Kapitel beschäftigen wir uns im folgenden Abschnitt mit Enterprise Java Beans. Dabei führen wir zunächst in das Programmiermodell ein, untersuchen dann Fragen der Architektur und gehen schließlich auf die Transaktionssteuerung ein. 3.1 Einführung Auf eine kurze Einordnung der Technologie in Abschnitt folgt eine Beschreibung der wichtigsten von EJB-Applikationsservern angebotenen Funktionen in Danach wird in ein knapper Überblick über das Programmiermodell gegeben und anhand eines Beispiels in illustriert. Dabei ist hier keine vollständige Einführung in die Entwicklung mit EJB beabsichtigt, da dies den Rahmen dieser Arbeit bei weitem sprengen würde 3. Stattdessen soll dieses Kapitel den Lesern, die keine oder nur wenige EJB-Kenntnisse besitzen, das grobe Verständnis der weiteren Ausführungen erlauben. Zur genaueren Einführung gibt es inzwischen zahlreiche empfehlenswerte Bücher, z.b. [Roman] oder [Monson] Einordnung Anfangs fand die Programmiersprache Java vor allem in Form von kleinen clientseitigen Programmen wie Applets Verbreitung. Schon bald stellte sich jedoch heraus, dass die Sprache wegen ihrer Robustheit und des gebotenen Komforts auch für serverseitige Anwendungen hervorragend geeignet ist. Inzwischen hat dieses Umfeld sogar eine überwiegende Bedeutung erlangt. Als gemeinsame Plattform für solche Applikationen führte Sun die Java 2 Enterprise Edition (kurz J2EE) ein. Sie definiert neben zahlreichen Diensten, die in Abschnitt vorgestellt werden, unter anderem auch das Komponentenmodell Enterprise Java Beans. Die Grundidee von EJB besteht neben der Verwendung von Komponenten als Entwurfseinheit darin, Querschnittsfunktionen wie Transaktionen oder Persistenz zu einem Teil des Programmiermodells zu machen und so den Anwendungsentwicklern diese Aufgaben abzunehmen. Nach der Vorstellung der Version wurde Ende 1999 die Version 1.1 der EJB- Spezifikation [EJB-1.1] veröffentlicht, und seit Mitte 2001 ist die Version 2.0 [EJB-2.0] aktuell. Die Spezifikationen sind weitgehend abwärtskompatibel. Da mit den Neufassungen jeweils erhebliche Verbesserungen und Erweiterungen verbunden waren (siehe Tabelle 1), haben sie sich schnell durchgesetzt. Diese Arbeit baut deshalb auf der aktuellen EJB-Version 2.0 auf. Version Neues Feature Auswirkung EJB 1.1 Unterstützung von Entity-Beans Erhöhte Portierbarkeit von EJBvorgeschrieben Anwendungen zwischen Applikationsservern Deployment-Deskriptoren als XML statt serialisierter Klassen Vereinfachte Handhabung der Deployment- Informationen EJB 2.0 Message-Driven-Beans Unterstützung für asynchron aufrufbare Komponenten Container-Managed-Relationships Vereinfachte Implementierung von komplexen Beziehungen zwischen Entitäten 3 Die aktuelle Version 2.0 der EJB-Spezifikation umfasst 572(!) Seiten.

15 Transaktionssteuerung in EJB-Applikationen 15 Einführung der EJB-Query- Erhöhte Portierbarkeit von EJB- Language Anwendungen zwischen Applikationsservern Lokale Schnittstellen Erhöhte Performance durch effizientere Kommunikation zwischen Beans im selben Applikationsserver Tabelle 1: Wichtigste Neuerungen in EJB 1.1 und EJB Dienste Wie bereits angedeutet, zielt die EJB-Spezifikation darauf ab, es dem Entwickler von EJB- Komponenten oder -Anwendungen zu ermöglichen, sich auf die eigentliche fachliche Logik zu konzentrieren. Der Ansatz dazu ist, dass der sog. EJB-Container, d.h. die Laufzeitumgebung von EJB-Anwendungen, allgemeine Systemdienste zur Verfügung stellt. Die wichtigsten dieser Dienste sind im Detail [Roman]: Ressourcen-Pooling: Durch das Unterhalten eines Pools an Ressourcen (z.b. Datenbankverbindungen oder Beans) kann der EJB-Container mit einer begrenzten Zahl von Instanzen dieser Ressourcen eine deutlich höhere Zahl an Clients bedienen. Diese Sparsamkeit ist eine entscheidende Voraussetzung, um Anwendungen entwickeln zu können, die auf hohe Benutzerzahlen skalieren. Persistenz: Praktisch jedes betriebliche Informationssystem hat persistente Daten. EJB- Container bieten verschiedene Varianten zu deren Speicherung an, die sich voneinander im Grad des gebotenen Komforts und der Flexibilität unterscheiden. Transaktionen: EJB-Container enthalten einen leistungsfähigen Transaktionsmanager, der in der Regel auch mit verteilten Transaktionen umgehen kann. Zugriffskontrolle: Die EJB-Spezifikation definiert Authentifizierungsmechanismen sowie ein rollen- und rechte-basiertes Modell zur Kontrolle von Zugriffsrechten. Damit lässt sich für jede Methode festlegen, welche Benutzer sie aufrufen dürfen und welche nicht. Verteilbarkeit: Enterprise Java Beans sind auch über Rechnergrenzen hinweg mittels RMI (remote method invocation) aufrufbar, ohne dass dem Anwendungsentwickler dadurch ein zusätzlicher Implementierungsaufwand entsteht. Neben den in der Spezifikation enthaltenen Diensten sollte man auch die von kommerziellen Produkten angebotenen zusätzlichen Features erwähnen. Diese sind teilweise transparent für die Applikation, wie z.b. die Unterstützung für Clustering oder gezielte Redundanz zur Ausfallsicherheit. Weiterhin gibt es Werkzeuge zur Administration von Anwendungen im laufenden Betrieb. Schließlich existieren auch eine Reihe von meist proprietären Erweiterungen, die bei der Entwicklung oder der Administration von Anwendungen im produktiven Betrieb helfen. Man sollte den Einsatz dieser herstellerspezifischen Erweiterungen jedoch sehr genau abwägen, da man sonst mit der Portierbarkeit der Applikationen einen der wichtigsten Vorteile von EJB aufgibt Programmierung Beans Die grundlegenden Bausteine von EJB-Anwendungen sind die sog. Beans. Diese bieten nach außen hin (d.h. für andere Komponenten) zwei Schnittstellen an. Das sogenannte home interface dient als Fabrik für das Bean und enthält Methoden zum Anlegen, Löschen und ggf. Wiederfin-

16 16 Transaktionssteuerung in EJB-Applikationen den von Instanzen. Das component interface enthält die eigentlichen Methoden des Beans und kann entweder als local interface vorliegen, das nur innerhalb der Virtuellen Maschine (VM) aufrufbar ist, oder als remote interface, das wegen seiner RMI-Schnittstelle auch von Clients aus verfügbar ist. Die gleiche Unterscheidung gilt auch für das home interface: Es kann entweder als local home oder als home interface vorliegen, die nur innerhalb der VM bzw. auch von Clients aus aufrufbar sind. Es gibt drei verschiedene Sorten von Beans: session beans, entity beans und message driven beans. - Session-Beans enthalten keine persistenten Daten und implementieren die in den Use-Cases definierten Funktionen der Anwendung. Zustandsbehaftete Session-Beans (stateful session beans) speichern den Zustand der enthaltenen Instanzvariablen zwischen zwei Client- Aufrufen, während zustandslose Session-Beans (stateless session beans) dies nicht tun. - Entity-Beans dienen der Speicherung von persistenten Daten. Dabei korrespondiert eine Entity-Bean-Instanz üblicherweise jeweils mit einer Datenbankzeile, und die Attribute des Beans mit den Spalten der Tabelle. Entity-Beans können die Datenbankzugriffe z.b. mittels JDBC selbst durchführen (bean managed persistence) oder diese Aufgabe dem EJB- Container überlassen (container managed persistence). - Message-Driven-Beans sind Komponenten, die über JMS (java message service) gesendete Nachrichten abonnieren. Sie werden somit nicht durch Client-Aufrufe aktiviert, sondern reagieren auf asynchrone Ereignisse. Da wir für unsere Zwecke nur Entity-Beans und Session-Beans benötigen, gehen wir auf Message-Driven-Beans nicht weiter ein. Deployment Ein Applikationsserver stellt die Laufzeitumgebung für die serverseitigen Anteile von betrieblichen Informationssystemen dar. Häufig wird dazu der Begriff EJB-Container synonym benutzt, der streng genommen nur ein Teil des Applikationsservers darstellt. Da die Unterscheidung auch für uns nicht relevant ist, folgen wir diesem Sprachgebrauch. Unter Deployment versteht man die Installation bzw. das Verfügbarmachen von Komponenten oder Anwendungen auf dem Applikationsserver. EJB-Anwendungen bestehen in der Regel aus zahlreichen Beans. Für jedes Bean gibt es neben den bereits erwähnten beiden Schnittstellen eine Implementierungsklasse, die die eigentliche Realisierung enthält. Entity-Beans besitzen zusätzlich noch einen Primärschlüssel, der entweder ein Standardtyp wie String oder eine eigene Klasse sein kann. Diese Klassen und Interfaces werden zusammen mit mehreren XML-Dateien (den sogenannten Deployment-Deskriptoren) als ein java application archive (kurz: JAR-Datei) ausgeliefert. Die Deployment-Deskriptoren enthalten neben der Beschreibung der verschiedenen Bean-Bestandteile wichtige Informationen für den Applikationsserver zur Konfiguration seiner Dienste. Beispielsweise spezifizieren sie, wie die Abbildung der Felder von Entity-Beans auf die Datenbank erfolgt, und welche Benutzerrollen zum Zugriff auf die einzelnen Methoden von Beans berechtigen. Clientsicht Der Aufruf von Beans aus Client-Sicht sieht wie folgt aus: Zunächst legt der Client ein Objekt vom Typ InitialContext an, bei dessen Erzeugung gewöhnlich Informationen darüber nötig sind, auf welchem Rechner und Port der Applikationsserver erreichbar ist. Auf diesem InitialContext-Objekt ruft der Client nun eine Methode namens lookup auf, die als Argument einen String oder Namen hat und ein Objekt zurückliefert. Dabei wird auf den Namensservice JNDI (java naming and directory interface) zurückgegriffen, der eine Zuordnung zwischen Namen und Objekten herstellt. Das zurückgegebene Objekt ist eine Implementierung des

17 Transaktionssteuerung in EJB-Applikationen 17 Home-Interfaces und erlaubt es dem Client nun, Instanzen des Beans anzulegen, zu löschen oder im Falle von Entity-Beans auch wiederzufinden. Somit kennt der Client lediglich die vom Bean implementierten Home- und Remote-Schnittstellen sowie seinen JNDI-Namen. Das gilt auch für Beans, die über den gleichen Mechanismus auf andere Beans zugreifen. Pooling und Bean-Lebenszyklus Um Ressourcen zu sparen, betreibt der Applikationsserver das sogenannte Pooling von Beans. Die Grundidee liegt darin, dass der Container stets einen Pool von Bean-Instanzen hält, die keinem bestimmten Client zugeordnet sind. Wenn ein Client eine Methode auf einem Bean aufruft, erhält er eine Instanz aus dem Pool. Dies spart im Vergleich zur Erzeugung einer neuen Instanz in erheblichem Maße Rechenzeit, und kostet wesentlich weniger Speicher, als für jeden Client eine eigene Instanz des Beans anzulegen. Das Pooling soll transparent für die Clients geschehen. Um dies zu erreichen, ist abhängig von der Art des Beans ein unterschiedlich großer Aufwand nötig. Zustandslose Session-Beans beispielsweise werden ohne weitere Maßnahmen nach jedem Methodenaufruf wieder in den Pool eingefügt. Für Entity-Beans ist mehr Aufwand nötig, da der EJB-Container die Instanzvariablen speichern und beim nächsten Clientaufruf wiederherstellen muss 4. Ferner hat der Applikationsserver die Möglichkeit, längere Zeit nicht benutzte Beans vorübergehend aus dem Speicher auszulagern. Bevor dies erfolgt, ruft er die sogenannte Callback- Methode ejbpassivate auf, in der die betroffene Bean-Instanz üblicherweise benutzte Ressourcen wie z.b. offene Datenbankverbindungen schließt. Vor dem nächsten Aufruf auf dem Bean erfolgt dessen Aktivierung, die mit einem Aufruf von ejbactivate verbunden ist. In dieser Methode würde das Bean in unserem Beispiel die Datenbankverbindung wieder öffnen. Die Vorstellung der weiteren Callback-Methoden, die der Applikationsserver bei den Übergängen zwischen den verschiedenen Zuständen im Lebenszyklus eines Beans aufruft, geht jedoch über den Rahmen dieser Arbeit hinaus Beispiel Um einen Eindruck von der Programmierung mit EJB zu geben, zeigen wir hier den Code eines Session-Beans, das eine triviale Operation implementiert, sowie eines Clients, der darauf zugreift. Das Session-Bean ist zustandslos und bietet lediglich eine Methode getstring an. Da diese direkt vom Client aufrufbar sein soll, besitzt das Session-Bean Remote-Schnittstellen. Das Home-Interface sieht wie folgt aus: public interface TestHome extends EJBHome { Test create() throws RemoteException, CreateException; Das Remote-Interface hat folgendes Aussehen: 4 Diese Darstellung ist etwas vereinfacht, aber für unsere Zwecke ausreichend. Genau genommen werden nicht einzelne Variablen gesichert und wiederhergestellt, sondern die tatsächlichen Instanzen der Beans. Der Client interagiert nie direkt mit dem Bean, sondern stets über Stellvertreterobjekte, die sogenannten stubs und skeletons. Diese bleiben für die Lebensdauer der Remote-Referenz des Clients bestehen, wogegen die Bean-Instanzen selbst in einem Pool verwaltet werden.

18 18 Transaktionssteuerung in EJB-Applikationen public interface Test extends EJBObject { String gettext() throws RemoteException; Die Bean-Klasse muss neben den in der Remote-Schnittstelle deklarierten Methoden auch einige im Interface SessionBean deklarierte Lebenszyklus-Methoden implementieren. Diese können jedoch in unserem einfachen Beispiel eine leere Implementierung aufweisen: pubilc class TestBean implements SessionBean { // method from remote interface Test public String gettext() { return Hello World! ; // lifecycle-methods from SessionBean public void ejbremove() { public void ejbactivate() { public void setsessioncontext(sessioncontext ctx) { public void ejbcreate() throws CreateException { Der Deployment-Deskriptor ejb-jar.xml lautet wie folgt: <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' ' <ejb-jar> <enterprise-beans> <session> <ejb-name>helloworldtestbean</ejb-name> <home>testhome</home> <remote>test</remote> <ejb-class>testbean</ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>helloworldtestbean</ejb-name> <method-name>*</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> <assembly-descriptor> </ejb-jar> Im ersten (durch das Tag <enterprise-beans> eingeschlossenen) Teil werden die Bestandteile des Beans deklariert und festgelegt, dass das Session-Bean zustandslos sein soll sowie dass die Transaktionssteuerung durch den Container erfolgt. Auf den zweiten Teil, der diese Steuerung näher beschreibt, gehen wir in Abschnitt näher ein. Neben diesem von der EJB- Spezifikation vorgegebenen Deskriptor gibt es noch weitere, die Applikationsserver-spezifische Aspekte deklarieren, wie z.b. die Definition eines JNDI-Namen für jedes Bean und die Zuordnung zwischen Entity-Beans und Datenbanktabellen. Wurde das Session-Bean unter dem JNDI-Namen Hello registriert, so könnte ein einfacher Client, der es aufruft und das Resultat des Aufrufes ausgibt, wie folgt aussehen:

19 Transaktionssteuerung in EJB-Applikationen 19 public class HelloWorldClient { public static void main(string argv[]) throws Exception { Properties p = new Properties(); //... Context ctx = new InitialContext(p); TestHome testhome = (TestHome) PortableRemoteObject.narrow(ctx.lookup( Hello ), TestHome.class); Test test = testhome.create(); System.out.println(test.getText()); Zunächst legt der Client einen InitialContext an, wozu in den übergebenen Properties Informationen über die Erreichbarkeit des Applikationsservers nötig sind. Diese sind produktspezifisch und werden deshalb hier nicht gezeigt. Danach wird per JNDI eine Implementierung des Home-Interfaces angefordert, die dann zur Erzeugung einer Bean-Instanz benutzt wird. Die Ausführung des Clients ergibt, wie bei solchen Beispielen üblich, die Ausgabe Hello World Zusammenfassung Wie bereits in der Einleitung dieses Unterkapitels erwähnt, verspricht die EJB-Spezifikation die Bereitstellung einer komfortablen Entwicklungs- und Laufzeitumgebung für komponentenbasierte, serverseitige Anwendungen. Die Mittel zur Erreichung dieses Ziels sind die Entkopplung zwischen den Beans durch die konsequente Programmierung gegen ihre Home- und Komponentenschnittstellen sowie die Nutzung von JNDI zur Lokalisierung der jeweiligen Implementierung. Somit ist es möglich, die verschiedenen Teile einer Anwendung getrennt zu entwickeln oder auch zuzukaufen. Durch die vom EJB-Container übernommenen Funktionen wie Ressourcen-Pooling, Persistenz und Transaktionen wird der erforderliche Implementierungsaufwand erheblich gesenkt. 3.2 Architektur von EJB-Applikationen Nachdem das letzte Unterkapitel in das Programmiermodell von EJB eingeführt hat, beschäftigt sich dieser Abschnitt damit, wie man zweckmäßigerweise die Architektur von EJB- Applikationen gestaltet. Zunächst stellen wir zwei einfache Architekturen vor, die jedoch beide erhebliche Schwächen wie z.b. die fehlende Trennung von A- und T-Software haben. Abschließend zeigen wir mit der bei sd&m entwickelten Standardarchitektur des technikneutralen Anwendungskerns einen Ansatz, der Abhilfe für diese Probleme bietet Konventionelle Architekturen nach den Sun-Blueprints Naive Architektur Die Tatsache, dass Home- und Remote-Schnittstellen von Clients außerhalb des Applikationsservers fast wie lokale Objekte benutzt werden können, verleitet bei naivem Herangehen zu der in Abbildung 4 gezeigten Architektur.

20 20 Transaktionssteuerung in EJB-Applikationen Client Entity- Bean 1 Entity- Bean 4 Symbole RMI- Aufrufe Entity- Bean 2 Entity- Bean 3 EJB-Container Abbildung 4: Naive Architektur von EJB-Applikationen Abgesehen vom nötigen JNDI-Lookup zum Finden des Home-Interfaces und den RemoteExceptions, die jeder Aufruf eines Beans aufgrund des verwendeten RMI-Protokolls werfen kann, ist der EJB-Container aus der Sicht des Client-Programmierers weitgehend transparent. Diese Architektur hat zahlreiche Nachteile, zu denen unter anderem eine sehr schlechte Wartbarkeit zählt, da alle Teile der Anwendung von fachlichen und technischen Aspekten durchsetzt sind. Darauf gehen wir jedoch hier nicht näher ein, weil die Performance von derart aufgebauten Anwendungen völlig unzureichend ist und sich diese Architektur somit von selbst verbietet. Der Grund dafür ist der hohe Aufwand für die bei jedem Zugriff auf die Entity-Beans erfolgenden RMI-Aufrufe, die um Größenordungen langsamer sind als lokale Methodenaufrufe. Das Performance-Problem hat zur Einführung der lokalen Schnittstellen für Home- und Komponenten-Interfaces in der Version 2.0 der EJB-Spezifikation geführt. Aufrufe dieser Schnittstellen sind wesentlich effizienter als Remote-Aufrufe, und verringern deshalb den Kommunikationsaufwand bei Verwendung des sogenannten Session-Facade-Patterns [Marinescu] deutlich. Session-Facade-Architektur Abbildung 5 zeigt, wie eine solche Architektur aussieht. Der Client interagiert nur noch mit einer Schicht von Session-Beans. Diese implementieren die Use-Cases der Anwendung. Anstatt dabei direkt mit den zugrundeliegenden Entity-Beans zu arbeiten, enthält die Schnittstelle der Session-Beans sogenannte Transferobjekte, die die gleichen Attribute wie die Entity-Beans besitzen. Somit können feingranulare Zugriffe von get- und set-methoden innerhalb des Clients als lokale Methodenaufrufe erfolgen. RMI-Aufrufe sind nur noch zwischen dem Client und den grobgranularen (und damit weniger zahlreichen) Use-Case-Methoden nötig. Innerhalb des EJB- Containers greifen die Session-Beans über lokale Schnittstellen auf die Entity-Beans zu, was gegenüber normalen Methodenaufrufen nur einen kleinen Zusatzaufwand bedeutet.

21 Transaktionssteuerung in EJB-Applikationen 21 Client Symbole Session- Bean 1 Session- Bean 2 RMI- Aufrufe Entity- Bean 1 Entity- Bean 2 Entity- Bean 3 EJB-Container lokale Aufrufe Abbildung 5: Session-Facade-Architektur von EJB-Applikationen Zwar entschärft diese Architekturvariante das Performance-Problem des naiven Ansatzes erheblich, da die Zahl der nötigen Client-Server-Interaktionen deutlich sinkt. Dennoch leidet sie wie jener an einer sehr schlechten Wartbarkeit. Dafür gibt es zwei Ursachen: die fehlende Trennung von A- und T- Software sowie die zu feine Granularität des Komponentenbegriffs. Mangelnde A-T-Trennung Alle Teile der Anwendung enthalten neben den fachlichen auch technische Aspekte. Beim Client ist das z.b. die nötige Behandlung der RMI-spezifischen Ausnahmen. Die Session- und Entity-Beans sind durch die von der EJB-Spezifikation gemachten Vorgaben (wie z.b. die zu implementierenden Callback-Methoden) technikabhängig. Unangenehme Konsequenz dieser A-T-Vermischung ist die mangelnde Lokalisierbarkeit von Änderungen. So muss z.b. beim Umstieg auf eine neue EJB-Version oder einen anderen EJB-Container der komplette Code auf nötige Änderungen und mögliche Seiteneffekte untersucht werden. Ein Beispiel hierfür ist der Umstieg von EJB 1.1 auf 2.0: Die persistenten Attribute von Entity-Beans mit containermanaged-persistence wurden in EJB 1.1 als Felder definiert, wogegen sie bei EJB 2.0 in der Form von abstrakten Methoden implementiert werden. Deshalb sind beim Umstieg alle Entity- Beans von Modifikationen betroffen. Da die Session-Beans direkt auf die Entity-Beans zugreifen, ist es notwendig, auch sie auf mögliche Folgen zu untersuchen und ggf. anzupassen. Inadäquater Komponentenbegriff Die EJB-Spezifikation ist bezüglich des Komponentenbegriffs nicht allzu präzise; im wesentlichen wird der Begriff des Beans mit dem der Komponente gleichgesetzt (siehe z.b. [Seifert]). Wie man aber bei Entity-Beans besonders leicht erkennen kann, sind Beans recht feingranular, da im allgemeinen eine Entity-Bean-Instanz einer Datenbankzeile entspricht. Zusammen bedeutet dies, dass komplexe EJB-Applikationen aus einer sehr hohen Zahl an Bean-Komponenten bestehen und wegen der zahlreichen gegenseitigen Abhängigkeiten zwischen diesen kaum überschaubar sind. Um dem abzuhelfen, bietet es sich an, auf höherer Abstraktionsebene Komponenten zu bilden, die aus mehreren Beans bestehen. Problematisch ist dabei allerdings, dass man von der EJB-Spezifikation in diesem Fall keinerlei Unterstützung erhält, um z.b. unkontrollierte Aufrufe und damit Abhängigkeiten zwischen verschiedenen Komponenten zu verhindern. So könnte man zwar beispielsweise per Konvention nur die nach außen sichtbaren Teile der Komponenten mit Remote-Interfaces ausstatten, und die internen Details mit lokalen Schnittstellen. Damit wären allerdings zulässige Aufrufe zwischen verschiedenen Komponenten (wegen des RMI-Overheads) unnötig aufwändig, und die Benutzung der Interna durch andere Beans im EJB-Container wäre dennoch nicht sicher verhindert.