Analyse und praktischer Vergleich von neuen Access-Layer-Technologien in modernen Web-Anwendungen unter Java. Oliver Kalz

Transkript

1 Analyse und praktischer Vergleich von neuen Access-Layer-Technologien in modernen Web-Anwendungen unter Java Oliver Kalz

2

3 Analyse und praktischer Vergleich von neuen Access-Layer-Technologien in modernen Web-Anwendungen unter Java Oliver Kalz geb. am in Spremberg Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH) eingereicht an der Fachhochschule Brandenburg Fachbereich Informatik und Medien Betreuer: Prof. Dr. S. Edlich (Fachhochschule Brandenburg) Prof. Dr. Th. Preuß (Fachhochschule Brandenburg) Brandenburg, den

4

5 Danksagung Ich danke hiermit allen, die mich während meines Studiums tatkräftig unterstützt haben. Besonderer Dank gilt meinen Eltern, ohne die dies hier nicht möglich gewesen wäre. Ebenso möchte ich mich bei Prof. Dr. Edlich bedanken, der mir mit vielen Tips und Ideen zur Seite stand. Zu guter letzt danke ich den Korrekturlesern, die hoffentlich alle Tippfehler entdeckt haben. Only two things are infinite, the universe and human stupidity, and I m not sure about the former. Albert Einstein

6

7 Inhaltsverzeichnis 1 Einleitung 9 2 Grundlagen Das Client/Server-Modell Objektpersistenz Der Java-Standard Die Extensible Markup Language Enterprise JavaBeans Die EJB-Architektur Programmier-Restriktionen Bestandteile einer EJB Das Home-Interface Das Komponenten-Interface Die Bean-Klasse Der Deployment-Deskriptor Arten von EJBs Session Beans Entity Beans Message Driven Beans Persistenzmechanismen Bean Managed Persistence Container Managed Persistence Transaktionen Container-gesteuerte Transaktionen Bean-gesteuerte Transaktionen Client-gesteuerte Transaktionen Fazit Java Data Objects Ziele Konzepte Metadaten

8 6 Inhaltsverzeichnis Bytecode Enhancement JDO Query Language Der Entwicklungsprozeß mit JDO Objektidentität Datastore Identity Application Identity Non-durable Identity Die JDO-API Speichern und Löschen von Objekten Objekte laden und manipulieren JDO-Implementierungen Libelis LiDO Triactive JDO XORM JDO und XDoclet Fazit Objektrelationale Mapper Apache ObJectRelational Bridge XML-Metadaten Die PersistenceBroker-API Exolab Castor Konfiguration Mapping-Informationen Abhängige und unabhängige Objekte Die Castor-API Hibernate Mapping-Informationen Die Hibernate-API SessionFactory und Session Oracle9iAS TopLink Deskriptoren und Mapping Mapping Workbench Session und Unit of Work Weitere O/R-Mapper Fazit Objektorientierte Datenbanken Schwächen relationaler Systeme Objektrelationale Datenbanken SQL Beispiel: Intersystems Caché Objektdatenbanken Beispiel: db4o

9 Inhaltsverzeichnis Objektorientierte Datenbanksysteme Der ODMG-Standard Beispiel: Objectivity Fazit Performance Kurzübersicht O/R-Mapping Fazit 127 A Anhang 129 A.1 Servlets und Java Server Pages A.1.1 Servlets A.1.2 Java Server Pages A.2 Java Database Connectivity A.3 Transaktionen und JTA A.4 Key-Generatoren A.5 JavaBeans A.6 Die Beispielanwendung A.7 Die JDO-DTD A.8 Primärschlüssel-Klasse für JDO Application Identity A.9 JDODoclet A.10 JDOMapper Abbildungsverzeichnis 151 Tabellenverzeichnis 153 Literaturverzeichnis 155

10

11 1 Einleitung Haben vor einigen Jahren noch statische HTML-Seiten genügt, um Informationen zu präsentieren, so hat sich das World Wide Web (WWW) in den letzten Jahren zu einem immer wichtiger werdenden Medium entwickelt. Das Spektrum reicht dabei von der einfachen Informationsrepräsentation mit statischen HTML-Seiten bis zu dynamisch erzeugten Webseiten mit PHP/MySQL oder ASP. Das WWW wird immer häufiger auch als Plattform für vollständige, verteilte Anwendungen auf der Basis von Java (J2EE, Servlets, JSPs) genutzt. Da solche komplexen Webanwendungen ihre Daten meist aus Datenbanken beziehen, kommt dem Access Layer als unterste Schicht einer Anwendung eine große Bedeutung zu. Der Access Layer ist dafür verantwortlich, die zu verarbeitenden und anzuzeigenden Daten zuverlässig, vor allem aber performant zur Vefügung zu stellen. Eine der ersten Entwicklungen zum Datenbankzugriff aus Java war die Java Database Connectivity (JDBC), eine Sammlung von Interfaces für einen implementierungsunabhängigen Zugriff auf verschiedene Datenbanken. Da aber hier mit dem Impedance Mismatch der Unterschied zwischen objektorientierter und relationaler Welt negativ zum Tragen kommt, wurden in letzter Zeit neue Möglichkeiten entwickelt, dieses Problem zu umgehen. Aufgabenstellung Im Verlauf der Arbeit sollen alternative Persistenzmechanismen an praktischen Code- Beispielen vorgestellt und in Hinblick auf ihr Handling und ihre Performance verglichen werden. Zunächst soll auf einige theoretische Grundlagen eingegangen werden. Anschließend werden dann die einzelnen Technologien vorgestellt. Schwerpunkte sind Enterprise JavaBeans, Java Data Objects, objektrelationale Mapper und objektorientierte Datenbanken. Sie haben das Ziel, den Impedance Mismatch zu verhindern oder zumindest vor dem Entwickler zu verbergen und so die Entwicklung objektorientierter Anwendungen zu vereinfachen. Außerdem soll eine kleine Webanwendung entstehen, in deren Access Layer einige der vorgestellten Werkzeuge zum Einsatz kommen. Darin werden dann auch die Unterschiede im Handling, in der Performance und der Komplexität der Implementierung deutlich.

12 10 Die Begleit-CD Auf der beiliegenden CD befinden sich die im Rahmen der Arbeit entstandene Webanwendung sowie einige der verwendeten Werkzeuge in der zur Abgabe aktuellen Version. Die Webanwendung liegt im Quelltext als Eclipse-Projekt vor, außerdem wurde sie in einem vorkonfigurierten JBoss-Applikationsserver installiert. Weitere Informationen enthält die Datei readme.html im Hauptverzeichnis der CD.

13 2 Grundlagen In diesem Kapitel sollen einige grundlegende Erklärungen gegeben werden, die für das Verständnis der folgenden Kapitel notwendig sind. Hierzu gehören Konzepte wie Persistenz und Objektorientierung sowie Technologien wie relationale Datenbanken, Java und XML. 2.1 Das Client/Server-Modell Das Client/Server-Modell beschreibt die am häufigsten verwendete Architektur für die Entwicklung verteilter Anwendungen. Ziel solcher Anwendungen ist die gleichmäßige Lastverteilung auf alle verfügbaren Rechner. Eine Client/Server-Architektur ermöglicht Clients die Arbeit mit zentral verfügbaren Diensten und Daten. Ein Server stellt hierbei einen Dienst zur Verfügung, der von anderen Rechnern genutzt werden kann. Es handelt sich meist um einen Hintergrundprozeß, der auf Anfragen von Clients wartet. Ein Client nutzt die von Servern bereitgestellten Dienste bei Bedarf. Zu diesem Zweck baut er eine Kommunikationsverbindung zum Server auf. Voraussetzung für die Kommunikation ist die Nutzung eines gemeinsamen Protokolls, welches die Regeln und Kommunikationskanäle für den Informationsaustausch beschreibt. Die Aufteilung einer Applikation in Schichten legt fest, wie die Programmfunktionalität auf Client und Server aufzuteilen ist. Speziell bei webbasierten Anwendungen hat diese Aufteilung einen großen Einfluß auf die Performance und die Funktionalität eines Systems. Grundsätzlich läßt sich eine Applikation in drei Schichten aufteilen 1 : Präsentationsschicht (Presentation Layer), Geschäftslogik (Business Logic Layer) und Persistenzschicht (Access Layer). Die Präsentationsschicht kann eindeutig dem Client zugeordnet werden. Als Persistenzschicht kommt meist ein zentraler Datenbankserver zum Einsatz. Die zentrale Datenhaltung ermöglicht es, Datenbestände effizient zu verwalten, Redundanzen zu vermeiden und die Integrität der Daten gerade im Mehrbenutzerbetrieb sicherzustellen. Für die Verteilung der Geschäftslogik gibt es verschiedene Möglichkeiten. In der 2-Schichten-Architektur wird die Geschäftslogik vollständig im Client implementiert. Das in der Persistenzschicht verwendete Datenbanksystem ist ausschließlich für die 1 Diese Aufteilung gilt nicht zwangsläufig nur für verteilte Anwendungen, sondern wird auch bei Standalone-Anwendungen eingesetzt.

14 Objektpersistenz Verarbeitung von Anfragen zuständig und sendet die Ergebnisse über ein datenbankspezifisches Protokoll an den Client. Clients in einer zweischichtigen Architektur werden aufgrund ihrer komplexen Programmfunktionalität auch Fat Clients genannt. Sie sind zwar vergleichsweise einfach zu entwickeln, unterliegen jedoch hohen Wartungs- und Installationskosten, da Änderungen der Geschäftslogik bei allen Clients durchgeführt werden müssen. Bei der Kommunikation zwischen Client und Server wird außerdem das Netzwerk stark belastet, da zu keiner Zeit eine Vorverarbeitung von Ergebnissen stattfindet. Vielmehr sendet der Server eine komplette Ergebnismenge an den Client. Erst dort findet die Verarbeitung statt. Zudem ist die Skalierbarkeit einer zweischichtigen Architektur eingeschränkt. Meist bildet der Server einen Flaschenhals, eine Lastverteilung ist nicht möglich. In einer 3-Schichten-Architektur wird eine zusätzliche Schicht zwischen der Präsentationsund Persistenzschicht eingefügt. Diese Schicht kapselt die Geschäftslogik einer Applikation und liegt meist in Form eines Applikationsservers vor. Diese Architektur wird dann eingesetzt, wenn die gleiche Funktionalität von verschiedenen Clients genutzt werden soll. Die Geschäftslogik wird einmal programmiert und allen Clients über den Applikationsserver zentral zur Verfügung gestellt. Dadurch ist das System leichter zu warten und zu erweitern: Bei einer Änderung der Funktionalität ist nur die Geschäftslogik betroffen, die Clients bleiben davon unberührt. Clients, die in einer dreischichtigen Architektur eingesetzt werden, fallen durch eine geringere Komplexität und niedrigen Ressourcenverbrauch auf. Man spricht von sogenannten Thin Clients. Zudem wird die Entwicklung von derartigen Clients vereinfacht, da die Datenspeicherung transparent erfolgt. Der Applikationsserver abstrahiert vom Zugriff auf die Daten und kümmert sich außerdem um deren Konsistenz. Während die Kommunikation zwischen Applikationsserver und Datenbankserver über das datenbankspezifische Protokoll erfolgt, werden für die Kommunikation zwischen Client und Applikationsserver sogenannte Middleware-Lösungen eingesetzt. Dort können standardisierte Protokolle wie zum Beispiel HTTP zum Einsatz kommen. Speziell im Java-Umfeld bieten sich auch Web Services und RMI 2 an. Dreischichtige Architekturen sind somit zwar schwieriger zu realisieren, zeichnen sich allerdings durch hohe Skalierbarkeit, einfache Wartung und gute Erweiterbarkeit aus. 2.2 Objektpersistenz Objekte, die in einer Anwendung erzeugt und benutzt werden, sollen eine beliebige Lebensdauer haben. Der Begriff Objektpersistenz beschreibt den Mechanismus, Objekte über die Laufzeit einer Anwendung hinaus zu erhalten. Solche Objekte werden persistente Objekte genannt und sind solange verfügbar, bis sie explizit gelöscht werden. Neben persistenten Objekten gibt es transiente Objekte, deren Lebenszeit maximal bis zum Ende einer Anwendung reicht. 2 RMI: Remote Method Invocation

15 2 Grundlagen 13 Um die Verfügbarkeit zu gewährleisten, werden persistente Objekte meist in den Sekundärspeicher ausgelagert. So gehen diese Daten auch nicht bei einem Absturz der Anwendung verloren. Für die Auslagerung gibt es verschiedene Möglichkeiten. Objekte lassen sich zum Beispiel im Dateisystem ablegen. Java bietet hierfür die Serialisierung an. Dabei handelt es sich um eine einfache Lösung, die nicht für große Datenmengen geeignet ist. Alternativ lassen sich Objekte in Datenbanksystemen speichern. Solche Systeme bieten eine effiziente Datenhaltung und ermöglichen Anwendungen die Suche und den schnellen Zugriff auf Daten (vgl. [BG02]). Handelt es sich um eine objektorientierte Anwendung, so würde sich auch ein objektorientiertes Datenbanksystem als Speicher für die Objekte anbieten. Allerdings haben sich objektorientierte Systeme bisher nicht auf dem Markt durchsetzen können. Die meisten Anwendungen speichern ihre Daten derzeit in relationalen Datenbanksystemen. Sie sind in ihrer Entwicklung ausgereift und auf dem Markt weit verbreitet. Allerdings kommt es beim Einsatz relationaler Systeme als Datenspeicher für Anwendungen zum sogenannten Impedance Mismatch. Dieser Begriff steht für das Aufeinandertreffen zweier unterschiedlicher Programmierparadigmen: dem Programmierparadigma der Anwendung und dem relationalen Paradigma der Datenbank. So sind Programmiersprachen satzorientiert und je nach gewählter Sprache imperativ oder objektorientiert. Bei der von relationalen Datenbanken verwendeten Anfragesprache SQL 3 handelt es sich hingegen um eine mengenorientierte und deklarative Sprache. Hinzu kommt, daß die Relationenalgebra der Datenbank durch Anwendung der Mengenlehre mathematisch erfaßbar ist. Auch die Typsysteme unterscheiden sich. So ist der Entwickler dafür verantwortlich, beide Systeme geeignet zu überbrücken und eine funktionierende Anbindung bereitzustellen. In den vergangenen fünf Jahren hat sich die Technik des objektrelationalen Mappings entwickelt, um speziell objektorientierte Anwendungen unter Vermeidung des Impedance Mismatch an relationale Datenbanken anzubinden. Das relationale Modell Im Relationenmodell werden Daten in Tabellen gespeichert. Eine Zeile in einer Tabelle wird Datensatz oder Tupel genannt, die Menge aller Tupel einer Tabelle heißt Relation. Die Informationen eines Datensatzes werden in Feldern oder Attributen organisiert. Das Relationenschema definiert alle Felder für die Relationen einer Tabelle. Diese Definition umfaßt einen Namen sowie einen Datentyp für jedes Feld. Die Tabellen einer relationalen Datenbank können zudem in verschiedenen Beziehungen zueinander stehen. Für die eindeutige Identifizierung eines Datensatzes innerhalb einer Tabelle wird der Primärschlüssel verwendet. Dieser kann aus einem oder mehreren Attributen des Datensatzes bestehen. Beziehungen werden über Fremdschlüssel hergestellt. 3 SQL: Structured Query Language

16 Objektpersistenz Das objektorientierte Modell Die objektorientierte Pogrammierung (OOP) ist ein modernes Programmierparadigma. Viele der heute verwendeten Programmiersprachen sind entweder von Grund auf objektorientiert (Java, Smalltalk) oder wurden um objektorientierte Konzepte erweitert (Basic, Pascal) [GK03]. Objektorientierte Programmierung soll zu robusten, fehlertoleranten und wartungsfreundlichen Programmen führen. Im folgenden sollen die wichtigsten Konzepte kurz vorgestellt werden. In der objektorientierten Programmierung wird mit einem hohen Grad der Abstraktion gearbeitet. So wird zwischen Konzeption und Umsetzung, also Klasse und Objekt unterschieden (nach [GK03]). Eine Klasse stellt einen abstrakten Datentyp dar und faßt Daten und die Methoden, die auf diesen Daten operieren, zusammen. Die in älteren Programmiersprachen wie C und Pascal realisierte Trennung zwischen Daten und Funktionen fällt weg. Die Daten (Attribute) sollen zudem nur über die zur Verfügung gestellten Methoden zugänglich sein. Zu diesem Zweck muß die Signatur einer Methode nach außen bekannt sein. Sie besteht aus einem Namen, einem Rückgabewert sowie einer Parameterliste. Dadurch kommt es zu einer vollständigen Kapselung, die die eigentliche Implementierung einer Klasse vor der Umgebung verbirgt. Eine Klasse faßt die Eigenschaften gleichartiger Objekte zusammen und gilt somit als Bauplan für Objekte. Ein konkretes Objekt entsteht durch Instantiierung einer Klasse. Das Objekt 4 erhält eine eindeutige Identität und hat zu jeder Zeit einen bestimmten Zustand, der durch die Werte der Attribute gegeben ist. Das Konzept der Vererbung bringt Klassen in eine ist-ein -Beziehung. Das bedeutet, daß eine Klasse von einer Oberklasse abgeleitet werden kann. Diese Unterklasse erbt alle Eigenschaften der Oberklasse und kann weitere Eigenschaften definieren. Durch Vererbung kann eine Klassenhierarchie aufgebaut werden, die von abstrakten zu immer konkreteren Klassen führt. Oberklassen gelten in einer solchen Hierarchie als Generalisierung der Unterklassen. Umgekehrt gelten die Unterklassen als Spezialisierung der Oberklassen. Bei der Vererbung wird zwischen Einfachvererbung und Mehrfachvererbung unterschieden. Bei der Einfachvererbung hat jede Klasse höchstens eine direkte Oberklasse, bei der Mehrfachvererbung kann eine Klasse beliebig viele direkte Oberklassen besitzen. Ein weiteres Konzept der Objektorientierung ist der Polymorphismus. Er beschreibt die Möglichkeit, Methoden einer Klasse zu überschreiben oder zu überladen. Erbt eine Klasse eine Methode von der Oberklasse, so kann sie die Implementierung dieser Methode entweder unverändert übernehmen oder eine eigene Implementierung zur Verfügung stellen. Letzteres wird als Überschreiben bezeichnet. Hierbei ändert sich nur die Implementierung einer Methode, nicht jedoch die Signatur. Zur Laufzeit führt der Compiler eine Typüberprüfung durch und führt in Abhängigkeit vom ermittelten Typ eines Objekts die entsprechende Methode aus (späte Bindung). Es ist auch möglich, Methoden mit gleichen Namen, aber unterschiedlichen Parameterlisten zur Verfügung zu stellen. Man spricht dann von überladenen Methoden. Aus Vererbung und später Bindung folgt auch die Substituierbarkeit von Objekten. So 4 auch: Instanz

17 2 Grundlagen 15 kann ein Objekt überall dort eingesetzt werden, wo eigentlich ein Objekt einer Oberklasse erwartet wird. Dies ist möglich, da ein Objekt alle Eigenschaften der Oberklasse erbt. Der Compiler ermittelt durch die eben genannte Typüberprüfung zur Laufzeit den richtigen Datentyp und führt eine aufgerufene Methode entsprechend aus. Objektrelationales Mapping Aus der Darstellung von Daten im relationalen und objektorientierten Modell lassen sich einige Gemeinsamkeiten erkennen (siehe [OTS02]). So definiert das Relationenschema die Struktur von Datensätzen, so wie eine Klasse die Struktur von Objekten definiert. Die Daten eines relationalen Datensatzes werden in den Feldern des Relationenschemas gespeichert, die Daten eines Objekts in dessen Attributen. Der Datentyp eines Feldes ist ebenso unveränderlich (statisch) wie der Datentyp eines Objektattributs. Auch Beziehungen können sowohl in relationalen Datenbanken als auch in einem objektorientierten Datenmodell realisiert werden. Ein Datensatz referenziert andere Datensätze über Fremdschlüssel, Objekte nutzen hierfür Referenzen. Abbildung 2.1: Relationenmodell vs. Klasse Beide Modelle weisen jedoch auch einige signifikante Unterschiede auf. So dienen relationale Datenbanken lediglich der Speicherung von Daten. Sie sind nicht in der Lage, Methoden oder Vererbungshierarchien zu speichern. Auch komplexe Beziehungen können nicht ohne weiteres dargestellt werden. Beziehungen zwischen Tabellen sind immer unidirektional. Hingegen kann im objektorientierten Modell eine Beziehung auch bidirektional, also von zwei Seiten aus navigierbar, sein. Prinzipiell ist es also möglich, Objekte auf relationale Strukturen abzubilden. Diese Abbildung wird objektrelationales Mapping (O/R-Mapping) genannt. Dabei wird genau festgelegt, wie die Daten eines persistenten Objekts und auch seine Beziehungen zu anderen persistenten Objekten in einer relationalen Datenbank abgebildet werden. Im Normalfall wird eine Klasse auf eine Tabelle abgebildet, die Attribute auf Tabellenspalten. Folglich wird ein Objekt über das Mapping mit seiner persistenten Repräsentation in der Datenbank verbunden.

18 Der Java-Standard Werkzeuge, die diese Abbildung realisieren, werden O/R-Mapper genannt. Sie stellen eine Schicht von Java-Klassen zur Verfügung, die zwischen einer Java-Applikation und einer relationalen Datenbank zum Einsatz kommt. Die Schicht agiert als objektorientierter Wrapper um die Datenbank und ermöglicht einer Applikation, ihre persistenten Objekte auf ein Datenbank-Schema abzubilden. Durch eine solche Persistenzschicht wird die Applikation vor Änderungen in der Datenbank geschützt, wodurch Änderungen am Datenbank-Schema einen geringeren Einfluß auf die Applikation haben. Zudem bietet die Persistenzschicht eine API 5 mit einer Reihe von Methoden zum Laden, Speichern und Manipulieren von Objekten an. 2.3 Der Java-Standard Bei Java handelt es sich nicht nur um die Programmiersprache, sondern um eine Menge von Technologien und Konzepten, die zusammen den Java-Standard ausmachen. Zu diesem Standard gehören: Die Programmiersprache Java als objektorientierte Sprache mit C-ähnlicher Syntax. Die Sprache ist an C++ angelehnt, allerdings ohne deren Komplexität, da Features wie zum Beispiel Zeiger fehlen. Die Java Virtual Machine (JVM) als Interpreter für Java-Bytecode. Eine Java-Applikation ist portabel und kann auf jedem System ausgeführt werden, das über eine JVM verfügt. Die Java-Plattform als Menge aller Packages und Klassen, die dem Entwickler als APIs für seine Programme zur Verfügung stehen. Im Jahre 1990 begann Sun Microsystems Inc. die Entwicklung von Java mit dem Ziel, eine Software-Plattform zu schaffen, die anywhere on the network und auf beliebigen Rechnersystemen lauffähig sein sollte (vgl. [EK02]). Mittlerweile liegt Java in Version 2 vor und wurde in drei Editionen mit unterschiedlichen Zielen aufgespaltet: Java 2 Standard Edition (J2SE) mit allen Werkzeugen, um Java-Anwendungen und -Applets zu entwickeln, Java 2 Enterprise Edition (J2EE) für netzwerkzentrische, serverseitige Enterprise- Applikationen, Java 2 Micro Edition (J2ME) für den Einsatz von Java auf Geräten wie Mobiltelefonen und PDAs. Abbildung 2.2 zeigt die wichtigsten Bestandteile von J2SE und J2EE. Es wird deutlich, daß die J2SE mit der integrierten JVM die Grundlage für die Entwicklung mit Java bildet, die J2EE ist als Erweiterung in Form von Spezifikationen und APIs zu sehen. Während 5 API: Application Programming Interface, Programmierschnittstelle

19 2 Grundlagen 17 für Anwendungen auf J2SE-Basis lediglich die JVM für die Ausführung notwendig ist, benötigt man für Enterprise-Applikationen einen Applikationsserver. Ausgehend von der J2SE mit der integrierten JVM bietet J2EE zusätzliche Technologien für komplexe, verteilte Enterprise-Applikationen an. Dazu gehören unter anderem Enterprise JavaBeans, Servlets, Java Naming and Directory Interface (JNDI), Java Messaging Service (JMS), Java Transaction API (JTA) und JavaMail. "! # " Abbildung 2.2: Komponenten von J2SE und J2EE Java-Komponentenmodelle Komponentenmodelle wurden von Sun entwickelt, um die Verteilung, Erweiterung und Pflege von Software zu vereinfachen. Eine Software-Komponente soll benutzerdefinierten Code durch generische, wiederverwendbare Module ersetzen (vgl. [JS01]). Hierbei definiert das Komponentenmodell die Struktur einer Software-Komponente. Die Plattformunabhängigkeit von Java ermöglicht, daß eine einmal entwickelte Komponente auf verschiedenen Systemen einsetzbar ist, solange dort eine Java-Umgebung verfügbar ist. Diese Austauschbarkeit wird außerdem durch die Konfigurierbarkeit von Komponenten gewährleistet. Das Verhalten von fertigen Komponenten wird nicht durch Eingriff in den Code, sondern über Konfigurationsparameter angepaßt. So können selbstentwickelte Komponenten mit zugekauften Komponenten zu einer Applikation zusammengefügt werden. Beispiele für Komponentenmodelle sind Applets (Browser), Servlets und Java Server Pages (Webserver) sowie Enterprise JavaBeans (EJB-Server). In Klammern angegeben ist jeweils der zur Ausführung nötige Container. Dieser Container stellt eine Laufzeitumgebung für Komponenten zur Verfügung. Eine Komponente wird dann im sogenannten Kontext des Containers ausgeführt.

20 Die Extensible Markup Language Bei allen Komponentenmodellen sind eine Reihe von Interfaces definiert, die von den Komponenten implementiert werden müssen. Diese Interfaces enthalten Callback-Methoden, die dem Container das Management des Objekt-Lebenszyklus sowie die Benachrichtigung der Komponente über Methodenaufrufe ermöglichen. Vor- und Nachteile von Java Die wichtigsten Vorteile von Java sind Plattformunabhängigkeit, Sicherheit und Robustheit. So bietet die Sprache Java moderne objektorientierte Sprachkonzepte und bleibt trotz umfangreicher API einfach und kompakt, da auf Mehrfachvererbung und Operatorüberladung verzichtet wurde. Eine hohe Sicherheit wird unter anderem durch den Verzicht auf Zeigerarithmetik und den Einsatz einer virtuellen Maschine gewährleistet. So ist ausgeschlossen, daß eine Java-Applikation ein System zum Absturz bringen kann. Lediglich die virtuelle Maschine, in der die Applikation läuft, kann abstürzen. Java- Applikationen liegen nicht als nativer Maschinencode vor, sondern als Bytecode. Dadurch sind Java-Applikationen portabel und können auf beliebigen javafähigen Plattformen ausgeführt werden. Der am häufigsten genannte Nachteil ist noch immer die geringere Ausführungsgeschwindigkeit von Java-Applikationen gegenüber Programmen aus anderen Sprachen. Da Java-Applikationen in Bytecode vorliegen und nicht in Maschinensprache, muß die Java Virtual Machine diesen zur Laufzeit interpretieren und ausführen. In den letzten Jahren wurden die sogenannten Just In Time Compiler eingeführt, die den Bytecode zur Laufzeit in Maschinensprache übersetzen und so vor allem bei häufig ausgeführten Codeblöcken zu einer merklichen Erhöhung der Geschwindigkeit führen. 2.4 Die Extensible Markup Language Bei der Extensible Markup Language - kurz XML - handelt es sich um eine textbasierte Beschreibungssprache. Es soll hier kurz auf die wichtigsten Eigenschaften von XML eingegangen werden, da alle im Verlauf der Arbeit vorgestellten Werkzeuge mehr oder weniger extensiv XML einsetzen, um notwendige Information zu speichern. Die Entwicklung von XML begann im Jahre 1996, im Jahre 1998 wurde die XML-Spezifikation in der Version 1.0 vom World Wide Web Consortium (W3C) zum Standard erhoben. Seitdem hat sich XML zur zentralen Technologie der Datenrepräsentation in Java-Systemen entwickelt. Im Jahr 2000 folgten dann einige Detailverbesserungen und Präzisierungen des Standards (vgl. [Se01], [Mc01]). XML ist eine sogenannte Metasprache, mit der weitere Sprachen definiert werden können. Dazu gehören unter anderem HTML 6, WML 7 und SVG 8. Die wichtigste Eigenschaft von XML ist die Strukturierung der Daten durch eigene Tags und Attribute. Dabei definiert der Standard weder Tags noch Grammatik, sondern lediglich die allgemeine Syn- 6 HTML: Hypertext Markup Language 7 WML: Wireless Markup Language 8 SVG: Scalable Vector Graphics

21 2 Grundlagen 19 tax. Dadurch ist XML hochflexibel und erweiterbar und der Inhalt der Daten kann unter Beachtung der Struktur beliebig definiert werden. Der Standard beschreibt zwei grundlegende Konzepte: Zum einen muß ein XML-Dokument wohlgeformt sein; das bedeutet, daß jeder geöffnete Tag einen dazugehörigen schließenden Tag besitzen muß und die Schachtelungsreihenfolge nicht durchbrochen werden darf. Ein XML-Dokument ist also genau dann wohlgeformt, wenn es eine korrekte Syntax in Bezug auf die Spezifikation hat. Zum anderen kann ein XML-Dokument gültig sein, das heißt, es gehorcht einer Document Type Definition (DTD). Die DTD ist Bestandteil der XML-Spezifikation und definiert die Grammatik eines XML-Dokuments, also die Menge der erlaubten Tags und Attribute sowie mögliche Einschränkungen der Attributwerte. Wenn ein XML-Dokument also eine DTD spezifiziert und deren Regeln folgt, so ist es ein gültiges XML-Dokument. Das folgende Beispiel zeigt ein einfaches, wohlgeformtes XML-Dokument, das eine externe DTD einbindet und somit auch gültig ist: <?xml version="1.0" encoding="iso "?> <!DOCTYPE locations SYSTEM "locations.dtd"> <locations> <location> <name>falkensee</name> <position latitude=" " longitude="13.1" /> <zip>14612</zip> </location> </locations> Jedes XML-Dokument besteht aus einem Kopf mit Steueranweisungen für Parser 9 und dem eigentlichen Inhalt. Die erste Zeile jedes XML-Dokuments enthält eine XML-Anweisung, die neben der Version als optionales Attribut das Encoding enthält, also mit welchem Zeichensatz das Dokument verfaßt ist. Standardeinstellung ist UTF-8, werden deutsche Umlaute verwendet, so muß ISO angegeben werden. Die nächste Anweisung gibt den Dokumenttyp sowie den Typ und den Pfad zur DTD an. Dabei steht SYSTEM für eine im lokalen Dateisystem abgelegte DTD, PUBLIC für eine öffentlich zugängliche DTD, die dann über einen vollständigen URI 10 angegeben wird. Zwischen dem öffnenden und schließenden Tag des Wurzelelements stehen dann die eigentlichen Daten. Da es sich bei XML um kein proprietäres Dateiformat handelt, sondern um reinen Text, ist einer der Vorteile von XML die Plattformunabhängigkeit, da solche Dateien auf jeder Plattform gleichartig ausgewertet werden können. Als Folge ergeben sich als weitere Vorteile die hohe Skalierbarkeit sowie die immer stärker werdende Verbreitung. Es ergeben sich allerdings auch zwei Nachteile: Zum einen fehlt ein Sicherheitskonzept, da 9 Programm, das XML-Dateien verarbeitet 10 URI: Uniform Resource Indicator

22 Die Extensible Markup Language XML textbasiert ist. Zum anderen enthält jedes XML-Dokument aufgrund seiner Struktur einen erheblichen Overhead an nicht nutzbaren Daten. Java & XML Aus den vorangegangenen Abschnitten wird klar, warum Java und XML so gut zusammenarbeiten: Während Java portablen Code liefert, der auf jedem Betriebssystem mit einer JVM läuft, steuert XML portable Daten bei (nach [Mc01]). Beide Technologien sind standardisiert, außerdem ist Java die Sprache mit der größten Unterstützung für die Verarbeitung von XML durch eine Vielzahl von Werkzeugen und APIs. Erst durch den Einsatz beider Technologien werden Anwendungen flexibel und können plattformunabhängig eingesetzt werden.

23 3 Enterprise JavaBeans Bei Enterprise JavaBeans (EJBs) handelt es sich um ein verteiltes, transaktionales, serverseitiges Komponentenmodell speziell für Geschäftsanwendungen. Enterprise JavaBeans sind die zentralen Komponenten der Java 2 Enterprise Edition und werden in einer formalen Spezifikation beschrieben. Neben den EJBs selbst beschreibt diese Spezifikation auch detailliert die Umgebung und die zur Verfügung stehenden Dienste wie Transaktionen, Sicherheit, Persistenz und Namensdienst. Auf der Basis der Spezifikation können Applikationsserver implementiert werden, welche den installierten EJBs die genannten Dienste zur Verfügung stellen. Version 1.0 der EJB-Spezifikation wurde im März 1998 veröffentlicht und im Dezember 1999 durch Version 1.1 aktualisiert. Im August 2001 wurde Version 2.0 verabschiedet, sie bietet wesentliche Verbesserungen und Erweiterungen. Basierend auf der Version 2.0 [EJB2] soll im Rahmen dieses Kapitels ein kurzer Einblick in die Komponenten der Spezifikation gegeben werden. Allerdings soll der Fokus auf der Realisierung der Persistenz innerhalb dieses Komponentenmodells liegen. 3.1 Die EJB-Architektur Die EJBs als Kernkomponenten der EJB-Spezifikation stellen den Clients serverseitige Geschäftslogik in Form von Interfaces zur Verfügung. Enterprise JavaBeans werden in einem EJB-Container installiert (deployt), der ihnen die Laufzeitumgebung zur Verfügung stellt. Er verwaltet die installierten Instanzen, steuert ihren Lebenszyklus und bietet jeder Komponente über Schnittstellen den Zugang zu weiteren installierten Diensten an. Zu diesen Diensten gehören, wie eingangs erwähnt, unter anderem ein Transaktionsdienst (via JTA), Datenbankzugriff (via JDBC) und Messaging (via JMS). Zusammen mit weiteren Containern ist der EJB-Container Bestandteil eines J2EE-konformen Applikationsservers. Der Server hat die Aufgabe, alle Container mit grundlegender Funktionalität wie z.b. Namensdienst, Fehlermanagement, Prozeßmanagement und Lastausgleich zu versorgen. Außerdem gewährleistet er Skalierbarkeit, Verfügbarkeit und die Anbindung an die Kommunikations-Infrastruktur (nach [BG02], [DP02]). Für die Entwicklung und den Einsatz von EJBs definiert die Spezifikation außerdem Szenarien und Rollen, um die Entwicklung von Anwendungen für die Beteiligten zu vereinfachen [BG02]. Zu diesen Rollen gehören unter anderem der Bean-Entwickler, der die eigentliche Entwicklung einer Komponente und ihrer Geschäftslogik übernimmt, der

24 Programmier-Restriktionen Anwendungs-Assembler, der verfügbare Komponenten zu einer Anwendung zusammenstellt sowie der Deployer, der eine J2EE-Anwendung in einem dafür vorgesehenen J2EE-Applikationsserver installiert. 3.2 Programmier-Restriktionen Damit die Portabilität von EJBs gewahrt bleibt und eine EJB in jedem EJB-Container installiert werden kann, muß der Bean-Entwickler laut Spezifikation einige Restriktionen beachten. Der schreibende Zugriff auf statische Variablen ist untersagt, daher sollten alle statischen Variablen in einer EJB als final deklariert werden. Eine EJB darf keine Anweisungen zur Thread-Synchronisation benutzen. Ebensowenig darf eine EJB eigene Threads starten oder stoppen. Eine EJB darf keine AWT 1 -Funktionalitäten benutzen, um Ausgaben zu realisieren oder Eingaben von der Tastatur zu lesen. Die Benutzung des Packages java.io zum Lesen und Schreiben von Dateien ist untersagt. Die Nutzung von Teilen des Packages java.security, um Sicherheitsrichtlinien zu beeinflussen, ist verboten. Das Setzen einer Socket-Factory, die Erzeugung von Sockets und das Akzeptieren von Verbindungen auf Sockets ist verboten. Die Nutzung der Reflection API, um Informationen über Klassen zu erhalten, ist untersagt. Eine EJB darf die Laufzeitumgebung nicht beeinflussen. Das bedeutet, sie darf keinen Classloader erzeugen oder benutzen, keinen Security-Manager setzen, die JVM nicht anhalten und die Ein-/Ausgabestreams nicht verändern. Eine EJB darf keine nativen Bibliotheken laden. Eine EJB darf das Schlüsselwort this nie als Argument oder Rückgabewert eines Methodenaufrufs nutzen. 3.3 Bestandteile einer EJB Eine Enterprise JavaBean ist nicht nur eine einfache Java-Klasse, sondern kann sich je nach Art aus mehreren Komponenten zusammensetzen (siehe auch Tabelle 3.2). Hierzu gehören: 1 Abstract Windowing Toolkit

25 3 Enterprise JavaBeans 23 Home-Interface Das Home-Interface bietet Methoden für die Verwaltung des Lebenszyklus sowie Lokalisierungsdienste an. Komponenten-Interface Das Komponenten-Interface dient als Schnittstelle zu den Geschäftsmethoden einer Bean. Bean-Klasse 2 Die Bean-Klasse enthält die Implementierung der Geschäftslogik. Jede Methode, die in einem der beiden zuvor genannten Interfaces deklariert ist, enthält eine korrespondierende Methode in der Bean-Klasse. Deployment-Deskriptor Der Deployment-Deskriptor enthält die Konfiguration der Bean, unter anderem alle zur Bean gehörigen Interfaces sowie Informationen über das Verhalten der Bean in Bezug auf Transaktionen und Sicherheit. Home- bzw. Komponenten-Interface können als lokale oder Remote-Interfaces vorliegen. Vor der EJB 2.0-Spezifikation war der Zugriff auf eine Bean nur über Remote-Interfaces möglich. Erst mit Version 2.0 der EJB-Spezifikation kamen lokale Beans und damit lokale Interfaces hinzu. Sie vermeiden den Kommunikationsaufwand, der bei Remote Beans durch RMI-IIOP 3 entsteht. Auf lokale Beans kann nur lokal von anderen Beans oder Webkomponenten wie Servlets, JSPs oder Taglibs zugegriffen werden, nicht jedoch von entfernten Clients. Lokal bedeutet in diesem Zusammenhang, daß der Client in der gleichen Java Virtual Machine laufen muß, wie die lokale Bean, auf die er zugreifen möchte. Tut er dies nicht, so handelt es sich um einen entfernten Client, der dann auch die Remote-Interfaces für den Zugriff auf eine Bean benutzen muß. Bei CMP-Entity Beans sind lokale Interfaces die Voraussetzung für die Realisierung von Beziehungen. Bei der Installation einer EJB im EJB-Container - dem sogenannten Deployment - erzeugt der Container mit Hilfe der zur Bean gehörigen Interfaces konkrete Klassen. Aus dem Home-Interface wird das Home-Objekt erzeugt, das als Factory für die Bean-Instanz dient. Die meisten Container erzeugen für eine installierte EJB genau ein Home-Objekt, auf das alle Clients zugreifen. Aus dem Komponenten-Interface wird das EJB-Objekt erzeugt, welches als Wrapper für die Bean-Instanz dient. Hier wird der Container meist genau so viele Objekte erzeugen, wie Clients verbunden sind (nach [BG02]). Mit den erzeugten Home- bzw. EJB-Objekten fängt der Container alle Aufrufe an die Bean ab und kann so vor der Weiterleitung an die eigentliche Bean-Instanz Dienste des Systems ausführen. Ein Client greift also zu keiner Zeit direkt auf eine Bean-Instanz zu, sondern immer über das Home- oder EJB-Objekt. 2 auch: Bean-Implementierung 3 RMI-IIOP: Remote Method Invocation over Internet Inter-Orb Protocol

26 Bestandteile einer EJB Abbildung 3.1: Bestandteile einer EJB Das Home-Interface Das Home-Interface dient als Factory einer Bean, das heißt, mit Hilfe dieses Interfaces können Instanzen der Bean vom Client erzeugt werden. Hierzu stellt das Interface eine Reihe von Create-Methoden mit unterschiedlichen Signaturen bereit, die aber alle mit dem Präfix create... beginnen müssen. Jede im Home-Interface deklarierte Create- Methode muß in der Bean-Klasse eine korrespondierende Methode haben. Der Rückgabewert einer Create-Methode ist das Komponenten-Interface der Bean, bei einer lokalen Bean das lokale Komponenten-Interface. Auch das Entfernen einer Bean geschieht über das Home-Interface. Hierzu steht die Methode remove() bereit, die jedoch nicht explizit deklariert werden muß, da sie vom Interface EJBHome bzw. im Falle einer lokalen Bean vom Interface EJBLocalHome geerbt wird. Es folgt ein Code-Beispiel für das Home-Interface einer Bean. Da dieses vom Interface EJBHome erbt, handelt es sich um ein Remote Home-Interface, womit jede deklarierte Methode in ihrer throws-klausel mindestens RemoteException deklarieren muß; bei Create-Methoden kommt zusätzlich CreateException hinzu. Methoden lokaler Beans werfen keine RemoteExceptions, da diese Beans nicht über RMI-IIOP kommunizieren.

27 3 Enterprise JavaBeans 25 public interface LocationEntityHome extends EJBHome { } public LocationEntity create(long id, String name) throws CreateException, RemoteException; Der Container stellt beim Deployment das Home-Objekt zur Verfügung, welches das Home-Interface implementiert. Dieses Home-Objekt wird innerhalb des EJB-Servers instantiiert, an den Namensdienst gebunden und somit den Clients als Factory für die Enterprise Bean verfügbar gemacht. Um eine Bean-Instanz zu erzeugen oder aufzufinden, sucht ein Client zunächst im Namenskontext das Home-Interface und kann danach über das erhaltene Objekt mit der Bean arbeiten Das Komponenten-Interface Das Komponenten-Interface enthält alle Geschäftsmethoden einer Bean, die vom Client aufgerufen werden können. Alle deklarierten Geschäftsmethoden müssen eine entsprechende Methode mit übereinstimmender Signatur in der Bean-Klasse haben. Außerdem dürfen als Parameter und Rückgabewert nur primitive oder serialisierbare Datentypen verwendet werden. Handelt es sich um eine Remote Bean, so erbt das Komponenten-Interface vom Interface javax.ejb.ejbobject. Alle deklarierten Methoden müssen außerdem eine Remote- Exception in ihrer throws-klausel deklarieren. Handelt es sich um eine lokale Bean, so erbt das Komponenten-Interface von javax.ejb.localobject. public interface LocationEntity extends EJBObject { public Long getid(); } public String getname(); public void setname(string name); Die serverseitige Implementierung des Komponenten-Interfaces ist das EJB-Objekt. Dieses holt sich der Client zunächst über den Aufruf einer Create-Methode aus dem Home- Interface der Bean. Anschließend kann er auf die Geschäftsmethoden der Bean zugreifen. Dabei soll noch einmal darauf hingewiesen werden, daß der Client nie eine Referenz auf die Bean-Instanz erhält, sondern nur auf das EJB-Objekt. Ruft der Client eine Geschäftsmethode auf, so delegiert der Container diesen Aufruf vom EJB-Objekt zur Bean-Instanz Die Bean-Klasse Die Bean-Klasse enthält die eigentliche Applikationsfunktionalität. Sie implementiert abhängig von der Art der Bean eines der Interfaces SessionBean, EntityBean oder

28 Bestandteile einer EJB Gruppe Create-Methoden Finder-Methoden Home-Methoden Select-Methoden Präfix ejbcreate...() ejbfind...() ejbhome...() ejbselect...() Tabelle 3.1: Spezielle Methoden der Bean-Klasse MessageDrivenBean (siehe Tabelle 3.2). Diese Interfaces enthalten unter anderem Callback-Methoden, die vom Container aufgerufen werden, um den Lebenszyklus einer Bean-Instanz zu verwalten. Neben den Callback-Methoden sind alle in den Home- bzw. Komponenten-Interfaces deklarierten Methoden in der Bean-Klasse mit ihren Implementierungen vorhanden. Keines dieser Interfaces wird jedoch direkt implementiert. Alle speziellen Methoden in der Bean-Klasse beginnen mindestens mit dem Präfix ejb. Hierzu zählen die in Tabelle 3.1 aufgezählten Methoden sowie ejbactivate(), ejbpassivate() usw. Lediglich Geschäftsmethoden, die in den Komponenten-Interfaces deklariert wurden, sind ohne Präfix mit gleicher Signatur in der Bean-Klasse implementiert. Das folgende Beispiel zeigt eine mögliche Bean-Klasse zu den in den beiden vorangegangenen Abschnitten definierten Interfaces (gekürzt um die Callback-Methoden des Containers): public class LocationEntityBean implements EntityBean { public Long create(long id, String name) {... } public Long getid() {... } public void setid(long id) {... }; } public String getname() {... }; public void setname(string name) {... }; Da die Bean-Klasse das Interface javax.ejb.entitybean implementiert, handelt es sich um eine Entity Bean. Neben der im Home-Interface deklarierten Create-Methode sind die Geschäftsmethoden aus dem Komponenten-Interface vorhanden. Nicht aufgeführt ist die Methode setentitycontext(), die vom implementierten Interface geerbt wird. Durch diese Methode erhält die Bean-Klasse den Kontext vom Container und kann ihn in einem Instanzattribut speichern. Ähnliche Methoden existieren für Session Beans und Message Driven Beans ebenfalls. Während alle Methoden in den Remote- Interfaces in ihrer Signatur mindestens RemoteException deklarieren, entfällt die Deklaration in der Bean-Klasse.

29 3 Enterprise JavaBeans Der Deployment-Deskriptor Der Deployment-Deskriptor enthält die Konfiguration einer oder mehrerer Enterprise JavaBeans. Diese umfaßt die Angabe aller zur Bean gehörigen Interfaces sowie der Bean- Klasse, Referenzen zu anderen EJBs, Sicherheitsrollen usw. Mit den Konfigurationsangaben wird auch das Verhalten der Bean in Bezug auf Transaktionen kontrolliert. Der Deployment-Deskriptor liegt im XML-Format vor und ist somit zwischen den unterschiedlichen benutzten Plattformen und Werkzeugen portabel. <ejb-jar> <enterprise-beans> <session /> <entity> <ejb-name>locationejb</ejb-name> <home>locationhome</home> <remote>location</remote> <local-home>locationentitylocalhome</local-home> <local>locationentitylocal</local> <ejb-class>locationentitybean</ejb-class> [...] </entity> <message-driven /> </enterprise-beans> <assembly-descriptor /> </ejb-jar> Das Wurzelelement enthält ein Element <enterprise-beans>, in dem alle Enterprise JavaBeans mit ihren Konfigurationsdaten enthalten sind. Dabei existiert für jede Art EJB ein eigenes Element. Mindestangaben für eine EJB sind ein eindeutiger Name für die Komponente (<ejb-name>) und die Bean-Klasse (<ejb-class>). Abhängig davon, ob eine EJB lokale und/oder Remote-Interfaces anbietet, werden diese in entsprechenden Elementen angegeben: <home> für das Remote Home-Interface, <remote> für das Remote Komponenten-Interface, <local-home> für das lokale Home-Interface, <local> für das lokale Komponenten-Interface. Der Name der zugehörigen Klasse bzw. des zugehörigen Interfaces muß in allen Fällen vollqualifiziert angegeben werden. Unterhalb des optionalen <assembly-descriptor>-elements können Sicherheitsrollen und Transaktionsattribute definiert werden sowie Angaben zur Zugriffskontrolle für Methoden gemacht werden. 3.4 Arten von EJBs Die EJB 2.0 Spezifikation definiert drei Arten von Enterprise JavaBeans: Session Beans, Entity Beans und Message Driven Beans. Eine Session Bean bietet einen Dienst in Form von

30 Arten von EJBs Geschäftsmethoden an und liegt in einer von zwei Varianten vor: als Stateless Session Bean oder als Stateful Session Bean. Eine Stateless Session Bean ist zustandslos und kann von mehreren Clients gleichzeitig benutzt werden. Eine Stateful Session Bean speichert einen Zustand und wird mit genau einer Client-Sitzung assoziiert. Eine Entity Bean repräsentiert ein persistentes Objekt mit seinen Daten und Zugriffsmethoden. Die Verwaltung der Persistenz kann von der Bean selbst übernommen werden oder dem EJB-Container überlassen werden. Eine Message Driven Bean stellt einen Nachrichtenempfänger dar, der auf asynchrone Nachrichten reagiert. Tabelle 3.2 gibt einen Überblick über die Arten von Enterprise JavaBeans sowie deren Aufgabe und Bestandteile. Session Beans und Entity Beans können vom Container bei Bedarf aus dem Hauptspeicher entfernt und in den sekundären Speicher ausgelagert werden. Dies geschieht entweder bei Speichermangel oder nach einem bestimmten Timeout. Der Vorgang des Auslagerns wird laut Spezifikation als Passivierung bezeichnet. Derart ausgelagerte EJBs werden durch Aufruf einer Geschäftsmethode durch den Client wieder reaktiviert, also im Hauptspeicher wiederhergestellt. Dieser Prozeß wird als Aktivierung bezeichnet. Um eine EJB über die Passivierung bzw. Aktivierung zu benachrichtigen, stehen die Callback-Methoden ejbpassivate() und ejbactivate() zur Verfügung. Der Container ruft ejbpassivate() unmittelbar vor der Auslagerung auf. Eine Bean sollte in dieser Methode alle Systemressourcen freigeben, die nicht ausgelagert werden dürfen (z.b. Datenbank-Verbindungen). Die Methode ejbactivate() wird vom Container aufgerufen, sobald eine Bean aktiviert wurde; in ihr können dann alle bei der Passivierung freigegebenen Ressourcen wieder angefordert werden Session Beans Eine Session Bean repräsentiert einen serverseitigen Dienst und modelliert Abläufe oder Vorgänge der Geschäftslogik einer Applikation. Session Beans werden daher auch als verlängerter Arm des Clients auf dem Server beschrieben [EK02]. Session Beans implementieren das Interface javax.ejb.sessionbean und werden im Deployment-Deskriptor unterhalb des Elements <enterprise-beans> deklariert. Für Session Beans steht das Element <session> zur Verfügung, darunter erfolgen alle Angaben gemäß Abschnitt sowie zusätzlich die Angabe der Ausprägung im <session-type>-element, gültige Werte sind Stateful und Stateless. <session> [...] <session-type>stateless</session-type> </session> Stateful Session Beans Stateful Session Beans werden verwendet, um eine Client-Sitzung zu verwalten und sitzungsbezogene Aufgaben auszuführen. Wenn ein Client eine Stateful Session Bean instantiiert, so folgt daraus eine eindeutige Zuordnung der Session Bean-Instanz zum entsprechenden Client [BG02]. Die Bean-Instanz ist für den Client dann exklusiv verfügbar

31 3 Enterprise JavaBeans 29 Zweck Session Bean Entity Bean Message Driven Bean Prozeß für einen Client Darstellung von Daten, Objekt im persistenten Speicher Nachrichtenempfänger Ausprägung Stateless, Stateful Bean Managed - Persistence, Container Managed Persistence gemeinsame Stateful Session gemeinsame Nutzung keine direkte Zuord- Nutzung Bean einem Client durch mehrere nung zu Clients zugeordnet; Clients bei Stateless Session Beans keine Zuordnung Persistenz transient, Lebenszyklus persistent, Zustand transient, stirbt durch Client bleibt im persisten- bei Container-Ter- bestimmt ten Speicher auch minierung nach Container- Terminierung erhalten Home- lokal, remote lokal, remote nein Interface Komponenten- lokal, remote lokal, remote nein Interface Deployment- ja ja ja Deskriptor Bean-Klasse ja ja, abstrakt bei CMP ja Bean-Klasse implementiert javax.ejb. SessionBean EntityBean MessageDriven- Bean Tabelle 3.2: Überblick über Enterprise JavaBeans (nach [BG02], [EK02])