Paper (PDF) - STS

Portabilität von Java-Software: 

Eine Untersuchung am Beispiel von Application-Servern 

und dem EJB-Standard 

DIPLOMARBEIT 

Celal Akçiçek 

Fachbereich Informatik 

UNIVERSITÄT HAMBURG 

Betreuung: 

Prof. Dr. Joachim W. Schmidt, 

Arbeitsbereich Softwaresysteme 

TECHNISCHE UNIVERSITÄT HAMBURG-HARBURG 

Dr. Martin Lehmann, 

Fachbereich Informatik 

UNIVERSITÄT HAMBURG 

20. November 2002

Zusammenfassung 

Die objektorientierte Programmiersprache Java erfreut sich immer größerer Beliebtheit. Die 

Ursachen für diesen Erfolg sind nicht nur in den Applets und in den objektorientierten Fähigkeiten 

dieser Sprache zu suchen (das objektorientierte Programmierparadigma besteht 

bereits seit Ende der sechziger Jahre ), sondern auch in der Plattformunabhängigkeit von Java. 

Durch die Plattformunabhängigkeit ergeben sich zahlreiche Vorteile, wie z.B. die Portabilität. 

Bisher gab es keine Möglichkeit, portable serverseitige Komponenten in Java zu entwickeln. 

Dieses Manko soll durch das von Sun eingeführte serverseitige Komponentenmodell – das 

Enterprise JavaBeans Komponentenmodell – behoben werden. Alle nach der EJB-Spezifikation 

entworfenen Komponenten sollen ohne jegliche Modifikation in EJB konformen Servern 

lauffähig sein. Diese Arbeit untersucht das Enterprise JavaBeans Komponentenmodell speziell 

im Hinblick auf die Portabilität der EJB Komponenten. 

I

An dieser Stelle möchte ich Herrn Prof. Dr. Joachim W. Schmidt 

und Herrn Dr. Martin Lehmann für die Betreuung dieser Arbeit danken. 

I

Inhaltsverzeichnis 

1 Einleitung 1 

1.1 Ziel der Arbeit . . ................................... 2 

1.2 Gliederung der Arbeit . . .............................. 2 

2 Portabilität 4 

2.1 Die Programmiersprache Java ............................ 5 

2.2 Portabilität von Software . .............................. 7 

2.3 Vor- und Nachteile der Portabilität . ........................ 7 

2.4 Marktwirtschaftliche Gesichtspunkte der Portabilität . ............. 8 

3 Komponentenmodelle 9 

3.1 Verteilte Anwendungen . .............................. 9 

3.2 Komponenten . . ................................... 10 

3.3 Problemklassen . ................................... 12 

3.4 JavaBeans ....................................... 13 

3.5 Enterprise JavaBeans . . . .............................. 13 

3.6 COM .......................................... 15 

3.7 Vergleich der Komponentenmodelle ........................ 16 

4 Enterprise JavaBeans Komponentenmodell 18 

4.1 Bean-Arten ....................................... 18 

4.2 Persistenz von EJB-Komponenten . . ........................ 20 

4.3 Aufbau der EJB-Arten . . .............................. 21 

4.4 Angebotene Dienste . . . .............................. 23 

4.5 EJB-Container . . ................................... 24 

II

INHALTSVERZEICHNIS 

III 

4.6 Transaktionen . . ................................... 24 

4.7 EJB-Rollen ....................................... 25 

4.7.1 EJB Server-Provider ............................. 25 

4.7.2 EJB Container-Provider . . . ........................ 25 

4.7.3 Bean-Provider . . . .............................. 25 

4.7.4 Application-Assembler . . . ........................ 26 

4.7.5 Deployer . ................................... 26 

4.7.6 System-Administrator ............................ 26 

4.8 Deployment-Deskriptor . .............................. 27 

4.9 Portabilität und Enterprise JavaBeans ....................... 27 

4.10 Java 2 Plattform, Enterprise Edition . ........................ 27 

5 Application-Server 32 

5.1 Evolution der Anwendungssystem-Architekturen . . . ............. 32 

5.1.1 Großrechner Architektur . . . ........................ 33 

5.1.2 Client-Server Architektur . . ........................ 34 

5.1.3 Mehrschichten Architektur . ........................ 36 

5.2 Angebotene Dienste . . . .............................. 37 

5.2.1 Authentifizierung . .............................. 40 

5.2.2 Skalierbarkeit . . . .............................. 40 

5.2.3 Lastausgleich und Ausfallsicherheit . ................... 40 

5.2.4 Transaktionssteuerung ............................ 40 

5.2.5 Datenbankzugriff . .............................. 40 

5.2.6 Zustands- und Sitzungssteuerung . . ................... 41 

5.2.7 HTML-Generierung ............................. 41 

6 Installation einer Beispielanwendung in EJB-Servern 42 

6.1 Beispielanwendung .................................. 42 

6.1.1 EJB-Komponenten der Beispielanwendung . . . ............. 47 

6.2 Beschreibung der Entwicklungs- und Testumgebung . ............. 50 

6.3 Vorstellung der Vergleichskriterien . ........................ 53 

6.4 BEA WebLogic Application-Server . ........................ 55

6.4.1 Installation der EJB-Beispielanwendung .................. 55 

6.4.2 Test der EJB-Komponente . . ........................ 56 

6.4.3 Umsetzung des EJB-Rollenkonzepts . ................... 56 

6.5 SilverStream Application-Server . . ........................ 56 

6.5.1 Installation der EJB-Beispielanwendung ................. 57 

6.5.2 Test der EJB-Komponenten . ........................ 57 


6.6 Borland Application-Server ............................. 58 

6.6.1 Installation der EJB-Beispielanwendung .................. 59 

6.6.2 Test der EJB-Komponente . . ........................ 59 


6.7 Auswertung der Vergleichskriterien ........................ 60 

7 Abbildung eines Objekt-Modells auf ein EJB-Modell 61 

7.1 Generelle Abbildungsprobleme . . . ........................ 61 

7.2 EJB-Komponenten basierend auf künstlichen Primärschlüssel . . ....... 64 

7.3 EJB-Komponenten basierend auf Java-Objektidentität . ............. 66 

7.4 Vergleich der Lösungen . .............................. 68 

8 Zusammenfassung und Ausblick 70 

8.1 Zusammenfassung .................................. 70 

8.2 Ausblick ........................................ 71 

IV

Abbildungsverzeichnis 

4.1 Beispiel eines Deployment-Deskriptors . . . ................... 28 

4.2 Bestandteile einer J2EE Anwendung ........................ 29 

4.3 Überblick der J2EE Architektur . . . ........................ 31 

5.1 Großrechner Architektur . .............................. 33 

5.2 Client-Server Architektur .............................. 34 

5.3 Drei-Schichten Architektur .............................. 37 

5.4 Ohne Einsatz eines Application-Servers . . . ................... 38 

5.5 Mit Einsatz eines Application-Servers ....................... 39 

6.1 UML-Klassendiagramm der Beispielanwendung ................. 44 

6.2 UML-Klassendiagramm des Kompositions Entwurfsmusters . . . ....... 45 

6.3 Ausschnitt der Klasse ElementaryWork . . . ................... 46 

6.4 UML-Klassendiagramm der Beispielanwendung mit EJB-Komponenten . . . 47 

6.5 Home-Interface der Entity-Bean . . . ........................ 49 

6.6 Remote-Interface der Entity-Bean . . ........................ 49 

6.7 Deployment-Deskriptor der Beispielanwendung ................. 51 

6.8 Zentrale Verzeichnis-Klasse ............................. 52 

6.9 Java-Programm zum Testen der Entity-Bean ................... 54 

V

Tabellenverzeichnis 

3.1 Komponentenmodelle im Vergleich . ........................ 17 

4.1 Unterscheidungskriterien zwischen Session- und Entity-Beans . . ....... 20 

6.1 Auswertung der Vergleichskriterien ........................ 60 

VI

VII

Kapitel 1 

Einleitung 

In der heutigen Zeit wird bei der Entwicklung von Anwendungen häufig ein Application- 

Server eingesetzt. Ein Application-Server ist eine Software, die bestimmte Dienste bereitstellt, 

um den Entwickler von Routine-Aufgaben wie z.B. dem Transaktionsmanagement, 

die Integration von Datenbanksystemen und von der Programmierung von Sicherheitsmechanismen 

zu entlasten. 

Jeder Hersteller eines Application-Servers besitzt bisher ein eigenes Rahmenwerk, um verteilte 

Anwendungen zu entwickeln. Zahlreiche Basisdienste werden durch das Rahmenwerk 

und dem Application-Server bereitgestellt. Die Anwendungsentwickler verwenden beim 

Einsatz solcher Rahmenwerke einen Großteil ihrer Zeit für die Implementierung folgender 

Programmteile, wenn die vom Application-Server bereitgestellten Basisdienste die Anforderungen 

der Anwendung bzw. der Anwendungsentwickler nicht erfüllen: 

• Netzwerkkommunikation 

• Transaktionen 

• Datenbankanbindung 

• Objekt-Relationales Mapping 

Für die Implementierung der Anwendungslogik wird in solch einem Fall zwangsläufig weniger 

Zeit aufgewendet. 

Im Falle eines Wechsels des Application-Servers ist jedoch viel Umprogrammierung sowie 

Neuprogrammierung bestimmter Programmteile notwendig, da jeder Hersteller sein eigenes 

Rahmenwerk zur Programmentwicklung besitzt. 

Ein weiteres Problem ist, daß die Geschäftskomponenten der Anwendung nicht zwischen 

den Application-Servern verschiedener Hersteller portabel sind. Die von [Sun ] eingeführte 

Enterprise JavaBeans Spezifikation [Matena, Hapner 99] versucht diese Problematik der Portabilität 

von Geschäftskomponenten durch die Einführung der Enterprise JavaBeans Komponenten 

zu lösen. Durch dieses neue Modell soll es möglich sein, den Hersteller zu wechseln, 

ohne die Geschäftskomponenten modifizieren zu müssen. Zusätzlich soll durch den 

Einsatz des Enterprise JavaBeans Komponentenmodells der Anwendungsentwickler von 

1

KAPITEL 1. EINLEITUNG 2 

der Programmierung der oben ausfgeführten Basisdienste (Netzwerkkommunikation, Transaktionen 

usw.) befreit werden, so daß er sich voll auf die Anwendungslogik und die Geschäftskomponenten 

konzentrieren kann. 

Zum Zeitpunkt dieser Arbeit ist die Enterprise JavaBeans-Spezifikation in der Version 1.1 die 

aktuell gültige. Diese Arbeit bezieht sich ausschließlich auf diese Spezifikation. Während der 

Entstehung dieser Arbeit wurde bereits an der Version 2.0 der EJB-Spezifikation gearbeitet, 

die zahlreiche Neuerungen beinhaltet (vergl. [DeMichiel et al. 00]). Da diese sich noch in der 

Entwicklung befindet und es daher noch keine vollständigen Implementierungen in Form 

von EJB-Containern gibt, wird sie nicht weiter behandelt. Selbst nach erscheinen der EJB- 

Spezifikation 2.0 wird es eine gewisse Zeit dauern, bis die neue Spezifikation von den EJB- 

Serverherstellern implementiert wird. 

1.1 Ziel der Arbeit 

Das von Sun Microsystems Inc. [Sun ] eingeführte Enterprise JavaBeans Komponentenmodell 

verspricht die Portierbarkeit von Enterprise JavaBeans Komponenten (kurz EJB- 

Komponenten). Mit anderen Worten bedeutet dies, daß alle EJB-Komponenten in EJB-Servern 

verschiedener Hersteller lauffähig sind, die entsprechend der EJB-Spezifikation [Matena, 

Hapner 99] implementiert werden. Die Programm-Logik in den EJB-Komponenten wird 

bei der Portierung nicht modifiziert. 

Ziel dieser Arbeit ist es, diese Portierbarkeit von EJB-Komponenten auf unterschiedliche 

EJB-Server anhand eines konkreten Beispiels zu überprüfen. Dabei wird eine Beispielanwendung 

mit Hilfe von EJB-Komponenten realisiert und anschließend in drei ausgewählten 

verschiedenen EJB-Servern installiert. Bei dem letzten Schritt wird geprüft, inwieweit die 

Portabilität von EJB-Komponenten gewährleistet ist. 

1.2 Gliederung der Arbeit 

Diese Arbeit befaßt sich mit der Portabilität von Enterprise JavaBeans Komponenten. Die 

Arbeit ist dabei so aufgebaut, daß zunächst die für den Kontext notwendigen Begriffe – Portabilität, 

Komponenten und Komponentenmodelle, Enterprise JavaBeans Komponentenmodell, 

Application-Server – in einzelnen Kapiteln eingeführt werden. 

Dabei wird in Kapitel 2 der Begriff der Portabilität näher erläutert und in Bezug zur Programmiersprache 

Java gesetzt. 

In Kapitel 3 werden nach der Einführung des Komponentenbegriffes drei Komponentenmodelle 

(JavaBeans, Enterprise JavaBeans und COM) kurz vorgestellt und das Enterprise 

JavaBeans und das COM/DCOM Komponentenmodell miteinander verglichen. 

Anschließend wird in Kapitel 4 das Enterprise JavaBeans Komponentenmodell ausführlich 

behandelt, einschließlich den in der EJB-Spezifikation eingeführten Rollen. 

Zu Beginn des Kapitels 5 wird die Evolution von Anwendungssystem-Architekturen dargestellt. 

Anschließend werden die von Application-Servern generell zur Verfügung gestellten

KAPITEL 1. EINLEITUNG 3 

Dienste aufgeführt. 

In Kapitel 6 wird eine Beispielanwendung basierend auf Enterprise JavaBeans Komponenten 

vorgestellt. In einem weiteren Schritt wird die in der EJB-Spezifikation aufgeführte Portabilität 

von EJB-Komponenten überprüft, in dem die Beispielanwendung auf drei verschiedenen 

EJB-Servern installiert wird. 

Kapitel 7 widmet sich der Abbildung eines Objekt-Modells auf ein EJB-Modell und beschreibt 

die auftretenden Abbildungsprobleme sowie zwei unterschiedliche Lösungsansätze. 

In Kapitel 8 wird zum Abschluß eine Zusammenfassung sowie ein Ausblick dieser Arbeit 

gegeben.

Kapitel 2 

Portabilität 

Im folgenden Kapitel wird der Begriff der Portabilität genauer untersucht, um ein besseres 

Verständnis für portable Enterprise JavaBeans Komponenten (Kapitel 3 und Kapitel 4) zu bekommen. 

Nach der Definition der Portabilität werden in Abschnitt 2.1 die wichtigsten Eigenschaften 

der Programmiersprache Java erläutert, wobei der Schwerpunkt auf der Plattformunabhängigkeit 

von Java liegt. In Abschnitt 2.2 werden die Eigenschaften portabler Software näher 

beschrieben. 

Die sich aus der Portabilität ergebenden Vor- und Nachteile werden in Abschnitt 2.3 vorgestellt. 

Abschnitt 2.4 widmet sich der Portabilität von Software aus marktwirtschaftlicher 

Sicht. 

Portabilität gewährleistet die Lauffähigkeit von Anwendungssoftware auf unterschiedlichen 

Systemen (Hardware/Betriebssystem/-umgebung) (vergl. [Rechenberg, Pomberger 97]). 

In der heutigen Zeit existieren eine Vielzahl von Hardware- und Software-Plattformen. Für 

jede einzelne Hardware-Software bzw. Hardware-Betriebssystem Kombination müssen Anwendungen 

entwickelt werden, was einen erheblichen Kosten- und Zeitaufwand sowohl 

bei der Entwicklung als auch bei der Wartung bedeutet. Das Hauptproblem ist hierbei, daß 

die selbe Anwendung für die jeweilige Hardware-Betriebssystem Kombination umprogrammiert 

werden muß und manche Programmteile sogar eine Neuprogrammierung erfordern. 

Dieser Vorgang ist sehr fehleranfällig, erfordert einen erheblichen Verwaltungsaufwand und 

verursacht erhebliche Kosten. 

Dieser Umstand kann mit Hilfe der Portabilität gemindert werden, denn durch Einsatz der 

Portabilität wird die Software nur einmal entwickelt. Folglich muß auch nur eine Anwendung 

gewartet werden. 

Daraus ergeben sich sowohl Vor- als auch Nachteile, die in Abschnitt 2.3 näher erläutert werden. 

4

KAPITEL 2. PORTABILITÄT 5 

2.1 Die Programmiersprache Java 

Java wurde erst 1991 von [Sun ] entwickelt und ist daher eine noch sehr junge Programmiersprache. 

Das erste Java Development Kit (JDK) war Anfang 1995 verfügbar. Trotz des jungen 

Alters hat Java eine beachtliche Verbreitung gefunden. Der eigentliche Durchbruch von Java 

gelang durch die sog. Applets. Dies sind graphische Java Anwendungen, die innerhalb eines 

Web-Browsers laufen. Bis zu der Einführung der Applets waren die HTML-Seiten (engl. Hypertext 

Markup Language) statische, mit Bildern angereicherte Textdokumente. Mit Hilfe der 

Applets konnten die HTML-Seiten nun mit dynamischen und bunten Grafik-Komponenten 

verschönert werden oder aber ganze Java-Anwendungen in HTML-Seiten integriert werden. 

Von diesem Zeitpunkt an war der Durchbruch von Java nicht mehr aufzuhalten. 

Java hat aber über die Applets hinaus noch weitere Eigenschaften (vergl. [Denninger, Peters 

00]), dazu zählen z.B.: 

• Objektorientierung 

• Dynamik 

• Stabilität 

• Sicherheit 

• Freie Verfügbarkeit von Java 

• Plattformunabhängigkeit 

Da Java eine objektorientierte Programmiersprache ist, bietet sie den Entwicklern die Vorteile 

objektorientierter Techniken. 

Die objektorientierten Eigenschaften von Java bilden auch die Basis für die komponentenorientierte 

Softwareentwicklung. In dieser Arbeit wird in Kapitel 3 ein kurzer Einblick in die komponentenorientierte 

Softwareentwicklung gegeben. Näheres zu diesem Thema kann z.B. in 

[Griffel 98] nachgelesen werden. 

Ein weiterer Vorteil von Java ist die Fähigkeit, Programmteile dynamisch (also zur Laufzeit) 

entweder vom lokalen Dateisystem oder über das Netz in den Adreßraum eines Prozesses 

zu laden und aus diesen zur Laufzeit Objekte zu erzeugen (vergl. [Denninger, Peters 00]). 

Java Programme sind im Vergleich zu Programmen der Programmiersprache C oder C++ 

wesentlich stabiler. Dieses wird durch zahlreiche Mechanismen erreicht. Einer dieser Mechanismen 

ist das Fehlen von Pointern (Zeiger auf Variablen und Funktionen). In [Denninger, 

Peters 00] wird als ein Grund für die Stabilität von Java die Interpreter-Eigenschaft genannt. 

Dadurch führen Laufzeitfehler (z.B. Zugriff auf ungültige Objektreferenzen) nicht zu unkontrollierten 

Systemabstürzen. Die Laufzeitumgebung kann in solchen Fällen das Programm 

kontrolliert beenden. 

Bei der Entwicklung von Java wurde auch auf Sicherheitsaspekte geachtet. Dazu zählen 

z.B. das Fehlen von Zeigern, wodurch ein direkter Zugriff auf Speicherbereiche über Zeiger


verhindert wird. Ein weiterer Sicherheitsaspekt wird von Java durch das sog. sandbox-Prinzip 

bei der Verwendung von JavaApplets angeboten. 

Mit Hilfe des JavaSecurityManagers lassen sich kritische Operationen von Objekten (z.B. das 

Lesen und Schreiben von Dateien, das Öffnen von Netzwerkverbindungen etc.) steuern und 

bei Bedarf verbieten. 

Einer der Hauptgründe für die schnelle Verbreitung von Java ist, daß Java von Anfang an 

frei verfügbar war und so zahlreiche Entwickler sofort anfangen konnten zu entwickeln. Im 

Gegensatz dazu mußte man für vergleichbare Programmiersprachen eine kostenpflichtige 

Lizenz erwerben. 

Obwohl das Prinzip der Plattformunabhängigkeit von Software schon seit längerem exitiert, 

hat die Entwicklung portabler Software und das Prinzip der virtuellen Maschine erst 

mit der Einführung der Programmiersprache Java einen starken Zuwachs erfahren. 

Java setzt das Prinzip der virtuellen Maschine ein, um die hohe Portabilität des Programmcodes 

zu erreichen. In Java wird diese virtuelle Maschine als Java Virtual Machine (JVM) 

bezeichnet. Sie bildet die Schnittstelle zwischen dem übersetzten Java Binärcode und dem 

Mikroprozessor, der die Aktionen ausführt. Dieser sog. Java ByteCode is auf jeder realen Maschine 

ausführbar, für die eine Java Virtual Machine existiert. 

Das Konzept der Java Virtual Machine wird z.B. in [Ernst, Schneider 00] ausführlich behandelt. 

Wie in [Blair 01] beschrieben wird, bietet Java mehrere Ebenen der Portabilität, wobei jede 

Portabilitätsebene durch eine Spezifikation beschrieben wird: 

Source-Code: 

Java-Source-code Portabilität bedeutet, daß ein Java-Quellcode immer das selbe Ergebnis 

liefert, unabhängig von der eingesetzten CPU, des verwendeten Betriebssystems, 

der verwendeten Laufzeitumgebung oder des verwendeten Compilers. 

CPU: 

Ein übersetztes Java-Programm wird auf Computern mit unterschiedlichen CPUs identisch 

ausgeführt. Diese CPU-Portabilität wird von der Java Virtual Machine durch die 

Verwendung eines virtual instruction sets erreicht, in das der Java-Quellcode übersetzt 

wird. Dadurch wird das Verhalten des übersetzten Codes von der eingesetzten CPU 

isoliert. 

OS: 

Betriebssystemportabilität erlaubt es einem Programmierer, auf einheitliche Weise auf 

systemspezifische Dienste zurückzugreifen. Java bietet Betriebssystemportabilität durch 

Einsatz eines virtuellen Betriebssystems, welches den Entwicklern eine einheitliche Sicht 

auf systemspezifische Dienste gibt. 

J2EE Applikation: 

Hierbei sind Entwickler in der Lage, Client-Server Komponenten und Anwendungen


zu entwickeln, die sich unabhängig des eingesetzten Servers und Herstellers identisch 

verhalten und identisch installiert werden. 

2.2 Portabilität von Software 

Für den Begriff der portablen Software kann es mehrere Umsetzungen geben. Zum einen 

kann damit die Quellcodeportabilität gemeint sein. Unter Quellcodeportabilität versteht man 

die Tatsache, daß der Quellcode eines Programmes auf unterschiedlichen Betriebssystem- 

Plattformen ohne Modifikation übersetzt werden kann. Der aus diesem Schritt resultierende 

ausführbare Maschinencode ist nur auf dieser speziellen Betriebssystem-Hardware Kombination 

lauffähig. 

Voraussetzung für die Quellcodeportabilität ist jedoch das Vorhandensein der benötigten 

Bibliotheken auf allen Plattformen. Auch ist vor der Ausführung des Programms ein einmaliger 

Übersetzungsvorgang nötig. 

Demgegenüber steht die Binärcodeportabilität, die z.B. von Java angeboten wird. Hierbei wird 

der Quellcode eines Programms einmal in den sog. Java Byte-Code (Binärcode) übersetzt. Dieser 

ist dann auf jeder entsprechenden Java Virtual Machine ohne erneute Übersetzung lauffähig. 

Es spielt dabei keine Rolle, auf welcher Betriebssystem-Umgebung die Java Virtual 

Machine läuft. Jede neue Version der Programmiersprache Java ist in der Lage, den Byte- 

Code einer älteren Java-Version auszuführen. Es ist also eine sog. Abwärtskompatibilität in 

den einzelnen Java-Version vorhanden. 

2.3 Vor- und Nachteile der Portabilität 

Portable Software besitzt sowohl Vor- als auch Nachteile gegenüber nicht-portabler Software. 

Zu den Vorteilen der portablen Software gegenüber nicht-portabler Software zählen: 

• Einfachere Migration zu neuen Versionen und zu neuen Umgebungen 

• Stärkere Neuentwicklung von Anwendungen statt Neuimplementierung bereits vorhandener 

Anwendungen 

• Geringere Entwicklungs- und Verwaltungskosten 

• Einheitliche Anwendungen auf unterschiedlichen Hardware-/Softwareumgebungen. 

Es ist anhand der hier aufgeführten Vorteile schon ersichtlich auf welche Bereiche sich die 

Vorteile portabler Software erstrecken: Entwicklung, Verwaltung, Vermarktung. 

Portable Software hat jedoch auch ein paar Nachteile, die erwähnt werden müssen. Ein 

Nachteil von portabler Software ist, daß nur sehr bedingter Zugriff auf hardwarenahe Funktionen 

möglich ist. Durch die Verwendung hardwarenaher Funktionen bindet man sich an 

eine bestimmte Hardware und folglich ist eine Portabilität des Anwendungsprogrammes


eingeschränkt. 

Einer der größten Nachteile ist, daß portable Software in der Regel eine geringere Ausführungsgeschwindigkeit 

besitzt. Eine Ursache hierfür ist die eingeschränkte Möglichkeit, 

hardwarenahe Funktionen zu verwenden. Allerdings wurde auf dem Gebiet der Ausführungsgeschwindigkeit 

intensiv geforscht, so daß zahlreiche Verbesserungen erzielt worden 

sind. Als Beispiele lassen sich hier erwähnen: 

• JIT-Compiler (Just-In-Time Compiler) 

• Sun’s HOT-Spot Technologie 

Ein Ursache für die geringere Ausführungsgeschwindigkeit ist, daß keine hardwarenahen Implementierungen 

verwendet werden können, da die Software sonst nicht mehr portabel wäre. 

Die Java Virtual Machine z.B. abstrahiert von der tatsächlich vorhandenen Hardware. Durch 

diesen Schritt kann die hohe Portabilität des Java ByteCodes gewonnen werden, aber zum 

Preis von geringerer Ausführungsgeschwindigkeit. 

2.4 Marktwirtschaftliche Gesichtspunkte der Portabilität 

Für ein Unternehmen sprechen einige wirtschaftliche Gründe für die Entwicklung und den 

Vertrieb von portabler Software. 

Zum einen werden Wartungskosten der Software gesenkt, da nur eine Anwendung gewartet 

werden muß. Bei der Entwicklung nicht-portabler Software hingegen muß die selbe Anwendung 

für jede Plattform separat entwickelt und gewartet werden, was einen erheblichen 

Kosten- und Wartungsaufwand bedeuten kann. 

Zum anderen wird die Erweiterung portabler Software vereinfacht. Die Erweiterung von 

nicht-portablen Anwendungen ist hingegen wesentlich komplexer.

Kapitel 3 

Komponentenmodelle 

Im Mittelpunkt dieses Kapitels stehen die Komponentenmodelle. Um ein besseres Verständnis 

für Komponenten und Komponentenmodelle zu bekommen, wird in Abschnitt 3.1 eine kurze 

Einführung in verteilte Anwendungen gegeben. Dabei wird kurz auf die Merkmale von verteilten 

Anwendungen eingegangen. Anschließend wird in Abschnitt 3.2 der Komponenten- 

Begriff eingeführt und erläutert. In Abschnitt 3.3 wird kurz darauf eingegangen, für welche 

Problemklassen sich Komponentenmodelle eignen. Es folgen dann eine kurze Vorstellung 

des JavaBeans Komponentenmodells (Abschnitt 3.4), Enterprise JavaBeans Komponentenmodells 

(Abschnitt 3.5) und des COM Komponentenmodells (Abschnitt 3.6). Zum Abschluß 

dieses Kapitels werden in Abschnitt 3.7 das Enterprise JavaBeans und das COM/DCOM 

Komponentenmodell kurz miteinander verglichen. 

Es wird in dieser Arbeit nicht auf das von der OMG eingeführte CORBA Komponentenmodell 

eingegangen. Ausführliche Information über das CORBA Komponentenmodell kann 

z.B. in [OMG ] nachgelesen werden. 

3.1 Verteilte Anwendungen 

Wegen der gesunkenen Kosten für Rechner und Netzwerktechnologie und der gewachsenen 

Bedeutung von Kooperation unter geographisch verteilten Benutzern sowie der gemeinsamen 

Benutzung von Information, werden in letzter Zeit immer mehr Arbeitsplätze mit Rechnern 

ausgestattet und diese lokal oder auch firmenübergreifend miteinander verbunden. 

Unter verteilten Anwendungen versteht man Dienste, die auf solchen vernetzten Rechnern 

verteilt erbracht werden. Die Verteilung betrifft neben den Daten (z.B. verteilte Dateisysteme) 

auch die Kontrolle und die Verarbeitung. Dadurch kann man eine höhere Zuverlässigkeit 

und Leistung sowie eine erhöhte Fehlertoleranz erhalten. Weiterhin zeichnen sich viele 

verteilte Anwendungen dadurch aus, dass sie von mehreren Benutzern gleichzeitig benutzt 

werden können und auch deren Zusammenarbeit unterstützen. 

Bei der Erstellung von verteilten Anwendungen geht es zuerst um die Unterteilung von Programmpaketen 

in verschiedene Dienste, die von unterschiedlichen Rechnern an verschiedenen 

Orten erbracht werden können. Genau diese Dienste werden von den Komponenten 

9

KAPITEL 3. KOMPONENTENMODELLE 10 

erbracht. 

Durch den Einsatz verteilter Anwendungen erhofft man sich folgende Vorteile (vergl. [CetusLinks 

]): 

• Altsysteme können weiterverwendet werden 

• Entwickler haben die Möglichkeit, Teilkomponenten einer Anwendung auf Computer 

zu verteilen, die der zu erfüllenden Aufgabe am Besten gewachsen sind. Im Falle einer 

Verschiebung einer Komponente auf neue Hardware bleibt die übrige Anwendung 

hiervon unberührt. 

• Verteilte Objekte bzw. Komponenten erscheinen für den Benutzer wie lokale Objekte. 

Der Benutzer bemerkt nicht, daß die Komponente sich auf einem anderen Rechner 

befindet. 

Eine der wichtigsten Bestandteile verteilter Anwendungen sind die Komponenten. Die Definition 

einer Komponente sowie eine Beschreibung werden nun in dem folgenden Abschnitt 

gegeben. 

3.2 Komponenten 

Der Begriff der Komponente wird in der EDV in unterschiedlichen Bereichen verwendet. 

Trotzdem gibt es keine allgemeingültige Definition des Komponentenbegriffs. Beispiele für 

die verschiedenen Definitionen einer Komponente können z.B. in [Szyperski 97] oder [Frank 

] nachgelesen werden. 

In dieser Arbeit wird eine Definition der Softwarekomponente verwendet, wie sie in [Griffel 

98] definiert wird: 

„ Eine Komponente ist ein Stück Software, das klein genug ist, um es in einem 

Stück erzeugen und pflegen zu können, groß genug ist, um eine sinnvoll einsetzbare 

Funktionalität zu bieten und eine individuelle Unterstützung zu rechtfertigen, 

sowie mit standardisierten Schnittstellen ausgestattet ist, um mit anderen 

Komponenten zusammenzuarbeiten.“ 

Die objektorientierte Modellierung führt häufig zu einer großen Anzahl an Klassen, Objekten 

sowie zahlreichen Beziehungen. Da es sich in diesem Fall um „kleine“ Elemente handelt, 

ist es oft schwierig, bestimmte Wiederverwendungs-Einheiten zu finden. Die Zusammenfassung 

von eng zusammengehörigen Klassen zu größeren Wiederverwendungs-Einheiten 

werden Komponenten genannt (vergl. [Henrich 01]). 

Eine Komponente besitzt folgende in der Literatur am häufigsten beschriebenen Eigenschaften 

(vergl. [Griffel 98], [Szyperski 97], [Frank ]): 

• Unabhängigkeit 

• Abgeschlossenheit


• Offenheit 

Komponenten sollen unabhängig voneinander und auch von anderen Anwendungen sein. 

Mit Abgeschlossenheit ist gemeint, daß Komponenten eine in sich geschlossene und vollständige 

Funktionalität bieten sollen. 

Der Begriff der Offenheit meint, daß Komponenten offen mit anderen Komponenten in beliebigen 

Systemumgebungen (z.B. Netzwerken) zusammenwirken können. 

Das Zusammenwirken von Komponenten und das Anbieten von Diensten geschieht bei 

Komponenten ausschließlich über ihre Schnittstellen. 

In [Henrich 01] wird bei der Vorstellung der Component-Based Development (CBD), also der 

komponentenbasierten Software-Entwicklung, eine sog. Legostein-Metapher aufgeführt. Diese 

Metapher beschreibt eine Komponente als Legostein. Durch das Zusammenstecken von 

einfachen Legosteinen entstehen komplexe Modelle. Auf die Komponenten übertragen bedeutet 

dies, daß durch das Zusammenstecken von vorgefertigten Komponenten komplexe 

Anwendungen erstellt werden können. Die vorgefertigten Komponenten sind i.A. schon 

ausgiebig getestet. Beim Zusammenstecken muß nur beachtet werden, daß die Schnittstellen 

zueinander passen. Wie die vorgefertigte Komponente implementiert ist - die technische 

Implementierung der Komponente also - sollte für den Benutzer nicht sichtbar sein. Das 

Kernproblem bei der komponentenorientierten Software-Entwicklung ist es, die richtigen 

Komponenten zu finden. 

Die durch den Einsatz von Komponenten erhofften Vorteile sind vielfältig. So ist einer der 

wichtigsten Vorteile die Wiederverwendbarkeit von Komponenten. Einmal erstellte Komponenten 

sollen in verschiedenen Anwendungsszenarien wiederverwendet werden können, 

ohne die Komponenten modifizieren zu müssen. 

Weitere durch den Einsatz von Komponenten erhoffte Vorteile sind zum Beispiel: 

• Verkürzung der Entwicklungszeit bei der Anwendungserstellung 

• Bessere Wartbarkeit der Komponenten 

• Steigerung der Produktivität der Mitarbeiter 

• Eingrenzung der Auswirkung von Änderungen (Folge: leichtere und billigere Wartung) 

• Bessere Flexibilität, da eine bestehende Komponente durch eine neue ersetzt werden 

kann, die sowohl alte als auch neue Anforderungen erfüllen kann 

Nachdem in diesem Abschnitt der Begriff der Komponente erläutert wurde, wird nun der 

Begriff des Komponentenmodells erläutert. 

Wie in [Henrich 01] beschrieben wird legt ein Komponentenmodell die von den Komponenten 

zu erfüllenden Eigenschaften fest.


Laut [Segev, Bichler 99] beschreibt ein Komponentenmodell eine Menge von Richtlinien, die 

das Aussehen der Komponenten-Schnittstellen festlegen. Dazu soll ein Komponentenmodell 

folgende Möglichkeiten bieten: 

• Properties 

• Introspection 

• Customization 

• Persistence 

• Packaging 

Die aufgeführten Punkte sollen der Austauschbarkeit von Komponenten sowie der Förderung 

der Wiederverwendung der Komponenten dienen. 

Viele der hier beschriebenen Eigenschaften von Komponentenmodellen werden durch das 

Enterprise JavaBeans Komponentenmodell erfüllt. 

3.3 Problemklassen 

In der Softwareentwicklungspraxis gibt es einige zentrale Probleme, die größtenteils auch 

nicht durch den Einsatz der objektorientierten Programmierung zu lösen sind. Zu den zentralen 

Problemen zählen unter anderem: 

• lange Entwicklungszeit der Software 

• unzureichende Qualität und Flexibilität der Software 

• kaum Wiederverwendbarkeit von Software 

Diese Probleme sollen durch den Einsatz von komponentenbasierter Softwareentwicklung 

gelöst werden. 

Komponentenmodelle eignen sich für den Einsatz in Umgebungen, in denen die meisten 

eingesetzten Applikationen ähnliche Strukturen aufweisen. Es lassen sich unter anderem 

folgende Strukturen erkennen: 

• Es existiert eine Datenbank, die Geschäfts-Entitäten enthält 

• Es existieren Prozesse, die diese Geschäfts-Entitäten verändern 

• Die Prozesse sind in der Regel transaktional gesichert 

• Die Applikationen besitzen in der Regel eine graphische Oberfläche 

• Die technischen und funktionalen Aspekte der Applikationen lassen sich trennen


• Teile der Applikationen sind in der Regel auf mehreren Rechnern verteilt, so daß ein 

großer Teil der Applikation für die Kommunikation über Rechnergrenzen hinweg zuständig 

ist 

Besonders der letzte Punkt, die Implementierung technischer Aspekte, ist ein Bereich, der 

die Applikationen kennzeichnet. Durch den Einsatz von Komponentenmodellen können 

sich die Entwickler auf die fachlichen Dinge konzentrieren. Die meisten technischen Aspekte 

werden durch das Komponentenmodell abgedeckt. 

3.4 JavaBeans 

Das JavaBeans-Komponentenmodell wurde von [Sun ] entwickelt und stellt ein clientseitiges 

Komponentenmodell dar, daß auf Java basiert. JavaBeans sind visuelle Komponenten. 

Bei JavaBeans Komponenten handelt es sich um sog. intraprozeß Komponenten, die in einem 

Addressraum mit dem Aufrufer „leben“. Typischerweise werden diese bei der graphischen 

Benutzerschnittstelle (GUI, Graphical User Interface) als Knöpfe, Tabellen o.ä. eingesetzt 

(vergl. [Sun ]). 

3.5 Enterprise JavaBeans 

Das EJB Komponentenmodell wurde von SUN [Sun ] entwickelt und repräsentiert wie in 

[Monson-Haefel 01] und [Monson-Haefel 00] dargestellt die Konvergenz von zwei Technologien: 

• den traditionellen Transaktionsmonitoren (kurz: TP-Monitore) 

• und den verteilten Komponenten-Systemen. 

Bei den TP-Monitoren handelt es sich um zuverlässige und skalierbare Anwendungssysteme. 

Zu den bekanntesten Vertretern der TP-Monitore zählen u.a. 

• CICS (siehe [IBM a]), 

• TUXEDO (siehe [BEA a]) 

• ENCINA (siehe [IBM b]) 

Die Aufgabe der TP-Monitore umfaßt die Kontrolle von z.B. Transaktionen, Sicherheit, Ressourcenmanagement, 

Lastausgleich und Fehlertoleranz. Eine genauere Beschreibung dieser 

Aufgaben wird in Kapitel 5 im Rahmen der Beschreibung von durch Application-Servern 

angebotenen Diensten gegeben. 

Der Zusammenhang von TP-Monitoren und Application-Servern besteht darin, daß mit 

den TP-Monitoren die drei-Schichten-Architektur eingeführt wurde, die für die Application- 

Server die Basis darstellt. Die durch die TP-Monitore überwachten Anwendungen wurden


hauptsächlich in einer prozeduralen Programmiersprache wie z.B. COBOL oder PL/1 geschrieben. 

Die verteilten Komponenten-Systeme stellen gegenwärtig den modernsten Ansatz der drei- 

Schichten-Architektur dar. Hierbei werden Objekte oder Komponenten der mittleren Schicht 

(engl. middle tier) mit Hilfe von Stellvertreter Objekten (sog. proxies) verwendet. Die meist auf 

Clientseite vorhandenen proxies leiten die Anfragen an die verteilten Komponenten über 

das Netz weiter und auch umgekehrt. 

Zu den bekanntesten Vertretern der verteilten Komponentensysteme zählen Java RMI, COR- 

BA und DCOM. Der Vorteil von verteilten Komponenten gegenüber den von TP-Monitoren 

überwachten prozeduralen Anwendungen liegt in der höheren Wiederverwendbarkeit und 

der Flexibilität der Komponenten. 

Was den Verteilten Komponenten jedoch fehlt ist eine robuste Infrastruktur, wie sie von TP- 

Monitoren geboten wird (vergl. [Monson-Haefel 01], [Monson-Haefel 00]). 

Das EJB-Komponentenmodell stellt nun ein Produkt dieser beiden divergierenden Technologien 

dar. So finden sich in der EJB-Architektur die typischen Eigenschaften der TP-Monitore 

wieder, wie z.B. 

• Transaktionsverwaltung, 

• Sicherheitsaspekte, 

• Nebenläufigkeit, 

• Persistenz, 

• Lastausgleich (engl. load balancing), 

• Fehlertoleranz (engl. failover). 

Auch finden sich in der EJB-Architektur die typischen Merkmale der verteilten Komponentensysteme 

wieder, wie z.B. die Komponenten. 

Die in der EJB-Architektur eingesetzten verteilten Komponenten sind die Enterprise JavaBeans, 

die vollständig in Java geschrieben werden. 

Enterprise JavaBeans werden zur Modellierung von Anwendungslogik eingesetzt. Mehrere 

Enterprise JavaBeans können zusammen zu einer Anwendung verknüpft und in einem EJB- 

Server installiert werden. 

Zum Zeitpunkt der Installation der Enterprise JavaBeans kann z.B. das transaktionale Verhalten, 

das Persistenzverhalten und das Sicherheitsverhalten der Enterprise JavaBeans mit 

Hilfe von deklarativen Attributen gesteuert werden. 

Zahlreiche Hersteller haben den EJB-Standard implementiert und in ihren Produkten integriert. 

Als Beispiel lassen sich folgende Hersteller bzw. deren Produkte nennen: 

• IBM Corporation, WebSphere Application-Server ([IBM b])


• BEA Systems, Bea WebLogic Application-Server ([BEA b]) 

• Borland Corporation, Borland Application-Server ([Borland ]) 

• Oracle, Oracle Application-Server ([Oracle ]) 

• Persistence, PowerTierEJB for J2EE ([Persistence ]) 

• Sybase, Sybase Enterprise Application-Server ([Sybase ]) 

• SilverStream, SilverStream Application-Server ([Silverstream ]) 

• SUN Microsystems, NetDynamics Application-Server ([Sun ]) 

Es muß jedoch bemerkt werden, daß nicht jeder Hersteller den vollen EJB-Standard implementiert. 

Einige Hersteller bieten z.B. in ihren EJB-Servern keine Implementierung der 

Entity-Beans an. Eine tiefere Darstellung des EJB Komponentenmodells wird in Kapitel 4 

gegeben. 

3.6 COM 

Das Komponentenmodell COM (Component Object Model) wurde von Microsoft ([Microsoft 

]) für die Windows-Plattformen entwickelt. Es handelt sich hierbei um ein sog. Intraprozeß-Modell, 

das auch als lokales Komponentenmodell bezeichnet wird (vergl. [Lewis ]). 

DCOM (Distributed COM) erweitert das COM-Modell für verteilte Anwendungs-Software. 

Bei DCOM handelt es sich um ein sog. Interprozeß-Modell, das auch als verteiltes Komponentenmodell 

bezeichnet wird. 

In [Lewis ] wird COM als ein Rahmenwerk zum Erstellen und Verwenden von Komponenten 

beschrieben, die auf binärer Stufe wiederverwendet werden können. Die Wiederverwendung 

auf binärer Stufe bedeutet, daß einmal geschriebene COM-Komponenten nur in 

ihrer Binärform (kompilierte Form) eingesetzt und verwendet werden können. Wie in [Lewis 

] weiter beschrieben wird sind COM Komponenten weitestgehend sprachenunabhängig. 

Eine COM-Komponente kann mit verschiedenen auf der Windows-Plattform verfügbaren 

Programmiersprachen erstellt werden. Zu den Vertretern der COM-fähigen Programmiersprachen 

zählen z.B. 

• Microsoft Visual C++ 

• Microsoft Visual Basic 

• Borland Delphi 

Einmal erstellte COM-Komponenten können in fast allen auf der Windows-Plattform verfügbaren 

Programmiersprachen verwendet werden. 

Durch den Einsatz von DCOM wird die rechnerübergreifende Kommunikation zwischen 

COM-Komponenten ermöglicht. Erst durch DCOM wird die sog. Ortstransparenz von COM- 

Komponenten erreicht. Erreicht wird dies durch Verwendung der Microsoft Windows-Registry, 

die die Rolle einer zentrale Konfigurationsdatei besitzt. In dieser Registry werden neben den


Namen der Komponenten die Orte bzw. Rechneradressen der entfernten Rechner gespeichert, 

auf denen die Komponenten installiert sind. 

Wie in Abschnitt 3.2 beschrieben, bieten alle Komponenten über ihre Schnittstellen Dienste 

an. So besitzen auch COM-Komponenten eine oder mehrere Schnittstellen, über die sie ihre 

Dienste anbieten. 

An dieser Stelle soll nicht näher auf das hier beschriebene Komponentenmodell eingegangen 

werden. Ausführlichere Information kann in den angegebenen Literaturverweisen nachgelesen 

werden. 

3.7 Vergleich der Komponentenmodelle 

Jedes der in den vorangegangenen Abschnitten vorgestellten Komponentenmodelle hat seine 

Vor- und Nachteile. Beim direkten Vergleich zwischen dem Sun EJB-Komponentenmodell 

und dem Microsoft COM/DCOM Komponentenmodell läßt sich dies erkennen. In reinen 

Windows-Netzwerken ist COM/DCOM die bessere Wahl, in reinen Java-Netzwerken der 

EJB-Ansatz. 

Für den EJB-Ansatz spricht, daß es sich um einen offenen Standard handelt sowie die Unterstützung 

durch eine große Anzahl von Partnern. Ein weiterer Vorteil für den EJB-Ansatz 

ist die Unterstützung von heterogenen Plattformen aufgrund der Portabilität von Java. Da 

das EJB-Komponentenmodell relativ jung ist, fehlen noch einige Entwicklungswerkzeuge, 

die sich jedoch in Entwicklung befinden. 

In Tabelle 3.1 werden das EJB- und das COM/DCOM-Komponentenmodell gegenübergestellt 

und anhand einiger Merkmale miteinander verglichen. 

In dem nun folgenden Kapitel 4 wird das Enterprise JavaBeans Komponentenmodell ausführlich 

beschrieben.


Komponentenmodell SUN Microsystems EJB Microsoft COM/DCOM 

Offener bedingt nein 

Standard 

Heterogene ja bedingt 

Plattformen 

Sprachunab- nein bedingt 

hängigkeit 

(C++,VB,Delphi) 

Vorteile offener Standard; viele Komponenten 

große Zahl von Partnern verfügbar 

Nachteile relativ neu und Windowsbasiert 

wenige Werkzeuge 

Tabelle 3.1: Komponentenmodelle im Vergleich

Kapitel 4 

Enterprise JavaBeans 

Komponentenmodell 

In diesem Kapitel wird das Enterprise JavaBeans Komponentenmodell ausführlich beschrieben. 

Es werden in Abschnitt 4.1 zunächst die in der EJB-Spezifikation [Matena, Hapner 99] 

eingeführten Bean-Arten beschrieben. In Abschnitt 4.2 wird daraufhin beschrieben, welche 

Persistenzarten bei den Entity-Beans möglich sind. In Abschnitt 4.3 wird anhand eines einfachen 

Beispiels der allgemeine Aufbau von Enterprise JavaBeans Komponenten gezeigt. In 

Abschnitt 4.4 werden die den Enterprise JavaBeans angebotenen Dienste aufgeführt. Dem 

EJB-Container widmet sich der Abschnitt 4.5. Die mit der EJB-Spezifikation eingeführten Rollen 

mit den dazugehörigen Verantwortlichkeiten werden in Abschnitt 4.7 vorgestellt. 

Der für die Portabilität der Enterprise JavaBeans notwendige Deployment-Deskriptor wird 

in Abschnitt 4.8 behandelt. Abschnitt 4.9 befaßt sich mit der Portabilität von Enterprise 

JavaBeans-Komponenten. 

Abgeschlossen wird dieses Kapitel durch Abschnitt 4.10, in dem die Java 2 Plattform, Enterprise 

Edition (J2EE) vorgestellt wird und ein Zusammenhang zum EJB-Standard hergestellt 

wird. 

4.1 Bean-Arten 

In der EJB-Spezifikation [Matena, Hapner 99] werden zwei grundsätzliche Enterprise Bean- 

Arten vorgestellt: 

• Session-Beans 

• Entity-Beans 

Kurz ausgedrückt handelt es sich bei den Session-Beans um nicht-persistente, transaktionale, 

serverseitige Java Komponenten. 

In [Denninger, Peters 00] werden Session-Beans als Verlängerung des Clients auf dem Server 

angesehen und werden hauptsächlich zur Modellierung von Abläufen oder Vorgängen 

18

KAPITEL 4. ENTERPRISE JAVABEANS KOMPONENTENMODELL 19 

eingesetzt. Eine Session-Bean kann z.B. mehrere verschiedene Entity-Beans verwenden bzw. 

deren Methoden aufrufen, um eine spezifische Aufgabe zu erledigen. Die Hauptaufgabe der 

Session-Beans ist also die Koordination von anderen Session- und Entity-Beans zur Durchführung 

einer Gesamtaufgabe. Ein weiteres Merkmal einer Session-Bean ist, daß sie keinen 

persistenten Zustand besitzt, der z.B. in einer relationalen Datenbank gespeichert wird. Eine 

Session-Bean kann aber dennoch bestimmte Daten in einer Datenbank modifizieren, neue 

Daten einfügen oder sogar bestehende Daten löschen. 

Für Session-Beans existiert noch eine weitere Unterteilung: 

• zustandslos (stateless) 

• zustandsbehaftet (stateful). 

In [Denninger, Peters 00] werden zustandslose Session-Beans so beschrieben, daß zwischen 

den Methodenaufrufen der zustandslosen Session-Bean keine Daten über den Zustand der 

Bean gespeichert werden. Der Bean stehen für den Aufruf einer Methode nur die übergebenen 

Parameter als Daten zur Verfügung. Nach erfolgtem Aufruf einer Methode kann die 

Bean einem anderen Client zugeordnet werden. Die Identität der zustandslosen Session- 

Beans des gleichen Typs ist zur Laufzeit immer gleich, wodurch eine Bean mehreren Clients 

zu Verfügung steht. Folglich hat ein Client nur für die Dauer eines Methodenaufrufes exklusiven 

Zugriff auf die zustandslose Session-Bean. 

Zustandsbehaftete Session-Beans hingegen besitzen einen Zustand. Auch werden zustandsbehaftete 

Session-Beans jeweils genau einem Client zugeordnet und stehen diesem solange 

exklusiv zur Verfügung, bis der Client die Bean nicht mehr benötigt oder der EJB-Server heruntergefahren 

wird. Die Identität von zustandsbehafteten Session-Beans des gleichen Typs 

ist zur Laufzeit verschieden. 

Die in [Matena, Hapner 99] aufgeführte zweite Ausprägung der Enterprise-Beans sind die 

Entity-Beans. Bei Entity-Beans handelt es sich um persistente, transaktionale, serverseitige 

Java Komponenten. Entity-Beans repräsentieren wichtige Geschäftsobjekte, wie z.B. Kunde, 

Ware, Bestellung, Konto usw. Mehrere Clients können eine Instanz eines bestimmten Typs 

gleichzeitig verwenden. Die Daten von Entity-Beans werden in einem dauerhaften Speicher 

wie z.B. einer relationalen Datenbank gespeichert. Jede Entity-Bean besitzt neben den persistent 

gespeicherten Daten noch ein bestimmtes Verhalten. 

Bei den Entity-Beans lässt sich eine weitere Unterteilung vornehmen, und zwar in beanmanaged 

persistence (BMP) Entity Bean und container-managed persistence (CMP) Entity Bean. 

Diese unterschiedlichen Persistenzarten werden in dem folgenden Abschnitt 4.2 näher beschrieben. 

In Tabelle 4.1 sind die Unterscheidungskriterien der beiden Ausprägungen der Enterprise- 

Beans nochmal tabellarisch aufgeführt.


Merkmal Session-Bean Entity-Bean 

Aufgabe der Bean Repräsentiert einen serverseitigen Repräsentiert ein Geschäftsobjekt, 

Dienst, der Aufgaben 

dessen Daten sich in einem 

für einen Client ausführt 

dauerhaften Speicher befinden. 

Zugriff auf die Bean Eine Session-Bean ist für den Die Entity-Bean ist eine zentrale 

Client eine private Ressource. Ressource; die Bean-Instanz wird von 

mehreren Clients gleichzeitig benutzt, 

und ihre Daten stehen allen Clients 

zur Verfügung. 

Persistenz der Bean Nicht persistent; Persistent; 

wenn der verbundene Client Wenn die verbundenen Clients oder 

oder der Server terminiert werden, der Server terminiert werden, 

ist die Bean 

befindet sich der Zustand der 

nicht mehr verfügbar. 

Entity-Bean auf einem persistenten 

Speichermedium; die Bean kann so 

zu einem späteren Zeitpunkt 

wiederhergestellt werden. 

Tabelle 4.1: Unterscheidungskriterien zwischen Session- und Entity-Beans 

4.2 Persistenz von EJB-Komponenten 

In der EJB-Spezifikation [Matena, Hapner 99] werden zwei Persistenz-Arten für EJB-Komponenten 

dargelegt: 

• Container-managed persistence 

• Bean-managed persistence. 

Bei Container-managed persistence wird die Aufgabe der persistenten Speicherung der Entity- 

Beans vom EJB-Container übernommen. Dabei generiert der EJB-Container die für den Zugriff 

auf den Datenspeicher notwendigen SQL-Anweisungen. Bei dem Datenspeicher handelt 

es sich meistens um eine relationale Datenbank. 

Der EJB-Container stellt eine Laufzeitumgebung für die Enterprise JavaBeans bereit. Eine 

genauere Beschreibung des EJB-Containers folgt in Abschnitt 4.5. 

Bei der Bean-Managed persistence ist der Bean-Entwickler für die persistente Speicherung 

der Entity-Bean zuständig. Dies bewerkstelligt er in der Regel mit Hilfe der JDBC-API.


4.3 Aufbau der EJB-Arten 

Ziel dieses Abschnittes ist es, anhand eines einfachen Programmes, dem HelloWorld-Programm, 

den Aufbau der EJBs zu verdeutlichen. Entity-Beans und Session-Beans bestehen 

immer aus drei Teilen: 

• Home-Interface 

• Remote-Interface 

• Entity- oder Session Bean Klasse. 

Für Entity-Beans existiert i.A. noch die primary key Klasse. 

Das Home-Interface dient zum Erstellen und Finden von EJBs. Es dient dabei lediglich als 

Schnittstelle zwischen dem Client und den EJBs. Clients können nur mit Hilfe des Home- 

Interfaces Session-Beans bzw. Entity-Beans erzeugen. Zu jeder EJB-Komponente existiert ein 

eigenes Home-Interface. In gewisser Hinsicht stellt das Home-Interface eine Variation des in 

[Gamma et al. 95] vorgestellten Fabrik-Entwurfsmusters (engl. factory-pattern) dar. 

Das Home-Interface stellt für den Zugriff auf EJBs folgende Methoden bereit: 

• create 

• find 

Die create-Methode liefert immer ein Remote-Interface Objekt der EJB-Komponente zurück. 

Mit Hilfe des Remote-Interfaces kann der Client die Geschäfts-Methoden der EJB- 

Komponente aufrufen. Ein einfaches Home-Interface einer Session-Bean stellt sich folgendermaßen 

dar: 

import java.io.Serializable; 

import java.rmi.RemoteException; 

import javax.ejb.CreateException; 

import javax.ejb.EJBHome; 

public interface HelloHome extends EJBHome 

{ 

} 

Hello create() throws RemoteException, CreateException; 

Das Remote-Interface stellt alle in der EJB-Komponente vorhandenen Geschäfts-Methoden 

bereit, die von Clients verwendet werden dürfen. Die Tatsache, daß die Geschäfts-Methoden 

in zwei Klassen aufgeführt werden, stellt eine gewisse Redundanz dar, die aber von Sun beabsichtigt 

scheint. Die EJB-Spezifikation verbietet es z.B. nicht, die Signaturen der zu veröffentlichenden 

Geschäfts-Methoden in einem eigenen Interface zu schreiben. Dieses Interface 

kann vom Remote-Interface spezialisiert werden und von der EJB-Komponente implementiert 

werden. Dieser Ansatz erhöht die Wartbarkeit im Falle von Signaturänderungen. 

Ein einfaches Remote-Interface sieht folgendermaßen aus:


import javax.ejb.EJBObject; 


public interface Hello extends EJBObject 

{ 

public String sayHello() throws RemoteException; 

} 

In diesem Fall handelt es sich um eine Session-Bean, die nur eine einzige Geschäfts-Methode 

besitzt: sayHello(). 

Die Entity- oder Session-Bean Klasse beinhaltet die Geschäfts-Methoden. 

Neben diesen existieren in der Bean-Klasse noch folgende Methoden: 

• ejbActivate 

• ejbCreate 

• ejbLoad 

• ejbPassivate 

• ejbPostCreate 

• ejbRemove 

• ejbStore 

Diese Methoden spielen eine wichtige Rolle für die verschiedenen Bean-Zustände und erlauben 

je nach Persistenzart der Bean noch bestimmte Aktionen durchzuführen, vor oder 

nach einem Zustandswechsel. 

Tiefer soll hier nicht auf die Bedeutung der einzelnen Methoden eingegangen werden. Dies 

kann z.B. in [Monson-Haefel 00], [Roman 99] oder [Matena, Hapner 99] nachgelesen werden. 

Die zu den oben aufgeführten Home- und Remote-Interface gehörige Session-Bean Klasse 

stellt sich folgendermaßen dar: 


import javax.ejb.SessionBean; 

import javax.ejb.SessionContext; 

public class HelloEJB implements SessionBean 

{ 

public String sayHello() 

{ 

return "Hello"; 

}


public HelloEJB() {} 

public void ejbCreate() {} 

public void ejbRemove() {} 

public void ejbActivate() {} 

public void ejbPassivate() {} 

public void setSessionContext(SessionContext sc) {} 

} 

Ein Client der Bean-Klasse führt seine Methodenaufrufe am Remote-Interface durch und 

nicht an der Bean-Klasse selbst. Die Bean befindet sich nur im EJB-Container. Mit Hilfe der 

Werkzeuge des EJB-Containers wird eine Klasse generiert, die das Remote-Interface implementiert 

und Aufrufe an das Bean-Objekt (HelloEJB) delegiert. 

4.4 Angebotene Dienste 

In diesem Abschnitt werden die von dem EJB-Standard angebotenen Dienste aufgeführt und 

kurz erläutert. 

In der EJB-Spezifikation werden den EJBs zahlreiche Standarddienste zur Verfügung gestellt. 

Diese Dienste lassen sich in fünf Kategorien unterteilen: 

• Lebenszyklus 

• Zustandsmanagement 

• Sicherheit 

• Transaktionen 

• Persistenz 

Der EJB-Container bietet Dienste für die Verwaltung des Lebenszyklus von Beans. Dazu zählen 

die Erzeugung, Aktivierung, Passivierung sowie Zerstörung der Bean. 

Auch werden die Zustände, in denen sich eine Bean befinden kann, vom EJB-Container verwaltet. 

Ein weiterer Dienst betrifft die Vergabe und Überprüfung von Zugriffsberechtigungen, die 

in deklarativer (beschreibender) Form im Deployment-Deskriptor festgelegt werden. Hierbei 

überprüft der EJB-Container zur Laufzeit, ob bestimmte Rechte vorliegen. 

Einer der wichtigsten Dienste für verteilte Komponenten ist die Verwaltung von Transaktionen. 

Der EJB-Container übernimmt die Transaktionssteuerung. Eine Bean kann jedoch so 

konfiguriert werden, daß sie die Transaktionssteuerung selbst durchführt. In diesem Fall


handelt es sich um eine Bean-managed transaction demarcation, in dem anderen Fall handelt es 

sich um eine container-managed transaction-demarcation. 

Aus der Sicht eines Entwicklers sind die Dienste bzgl. der Persistenz von Beans diejenigen, 

die viel Entwicklungsaufwand sparen. Der EJB-Container übernimmt die Aufgabe der 

persistenten Speicherung von Entity-Bean Objekten. Der Entwickler ist bei dieser containermanaged 

persistence von der Programmierung von SQL-Anweisungen befreit. Er hat aber 

auch die Möglichkeit, diese Aufgabe selbst durchzuführen, wobei dies als bean-managed persistence 

bezeichnet wird. 

4.5 EJB-Container 

Der EJB-Container stellt den Enterprise JavaBeans-Komponenten eine Laufzeitumgebung 

zur Verfügung. Weiterhin stellt der EJB-Container den Beans gewisse Dienste in Form von 

Standardprogrammierschnittstellen (engl. API, Application Programming Interface) zur Verfügung. 

Der Hersteller eines EJB-Containers ist laut der EJB-Spezifikation [Matena, Hapner 

99] verpflichtet mindestens folgende Standardprogrammierschnittstellen einer Bean anzubieten: 

• API der Java 2-Plattform 

• API der Spezifikation der Enterprise JavaBeans 1.1 

• API des JNDI 1.2 (Java Naming and Directory Interface) 

• API des JTA 1.0.1 (Java Transaction API) 

• API der JDBC 2.0-Erweiterung (Java Database Connectivity) 

• API von Java Mail 

Über die hier aufgeführten Schnittstellen hinaus, ist der EJB-Container Hersteller berechtigt, 

zusätzliche Schnittstellen anzubieten. 

4.6 Transaktionen 

Das EJB-Komponentenmodell unterstützt auch Transaktionen. Wie in [Matena, Hapner 99] 

beschrieben werden zur Zeit nur flache Transaktionen unterstützt, d.h. innerhalb einer Transaktion 

können keine verschachtelten Transaktionen existieren. Wegen fehlender oder nur 

geringer Unterstützung von verschachtelten Transaktionen in existierenden Transaktionsund 

Datenbank-Systemen wurde darauf verzichtet. In zukünftigen EJB-Versionen könnte 

sich dies jedoch ändern. 

In der EJB-Spezifikation [Matena, Hapner 99] wird der Transaktionskontext durch Propagation, 

also durch Weiterreichung, zwischen den verschiedenen Servern weitergegeben.


4.7 EJB-Rollen 

In diesem Abschnitt und den folgenden Unterabschnitten werden die einzelnen Rollen, die 

mit dem EJB-Standard eingeführt wurden, erläutert. 

Durch die Aufteilung der Entwicklungsverantwortlichkeiten in diverse Rollen soll eine gewisse 

Abstraktion im EJB-Modell erreicht werden. Durch die Aufteilung der Verantwortlichkeiten 

wird eine Strukturierung des Entwicklumgsprozesses von EJBs erreicht, die eine 

arbeitsteilige Entwicklung und Wartung erleichtern soll. 

4.7.1 EJB Server-Provider 

Der EJB Server-Provider (kurz Server-Provider) wird in [Matena, Hapner 99] als ein Spezialist 

auf dem Gebiet der Implementierung systemnaher Dienste beschrieben. Typische 

Server-Provider sind z.B. Hersteller von Betriebssystemen, Hersteller von Middleware oder 

Datenbank-Hersteller. 

Der Server-Provider ist zuständig für die Bereitstellung einer Laufzeitumgebung für die unterschiedlichen 

Container, vor allem den EJB-Containern (siehe Abschnitt 4.5). Dazu zählen 

u.a. die Netzwerkanbindung, Thread- und Prozeßmanagement sowie das Ressourcenmanagement. 

4.7.2 EJB Container-Provider 

Der EJB Container-Provider (kurz Container-Provider) bietet den Enterprise Beans eine Laufzeitumgebung 

und verwendet die vom Server-Provider bereitgestellten Dienste. In [Matena, 

Hapner 99] wird davon ausgegangen, daß die Server-Provider Rolle und die Container- 

Provider Rolle einem Hersteller zugeordnet werden. Dies hat zur Folge, daß ein EJB-Container 

in der Praxis nicht in EJB Servern anderer Hersteller lauffähig ist. Die Trennung zwischen 

diesen beiden Rollen ist eine logische. Es ist dem Hersteller von EJB Servern überlassen, wie 

er die geforderten Leistungen zwischen dem EJB Container und dem EJB Server aufteilt. Der 

Container-Provider kapselt die Enterprise Beans von den technischen Eigenschaften des darunterliegenden 

EJB Servers durch die Bereitstellung einer einfachen API (Application Programming 

Interface) zwischen der Enterprise Bean und dem Container. Diese standardisierte 

API wird in [Matena, Hapner 99] als Enterprise JavaBeans component contract (Enterprise 

JavaBeans Komponentenvertrag) bezeichnet. 

Für die Verwaltung des Containers muß der Container-Provider spezielle Programme bereitstellen, 

die es dem System-Administrator (siehe 4.7.6) ermöglichen, die installierten Beans 

und den Container selbst zu überwachen und zu kontrollieren. 

4.7.3 Bean-Provider 

Die Rolle des Bean-Provider besteht darin, die eigentliche Business-Logik (Anwendungslogik) 

in Form von Komponenten zu implementieren. Bei der Implementierung der Anwendungs-


logik ist der Bean-Entwickler vollständig von der Entwicklung grundlegender Servertechniken 

(Multithreading, Netzwerkanbindung, Transaktionssteuerung etc.) entlastet. Die Implementierung 

dieser Dienste übernimmt der Server- und Container-Provider, so daß sich der 

Bean-Entwickler ganz auf die Anwendungslogik konzentrieren kann. Der Bean-Provider hat 

jedoch immer die Möglichkeit, einen Teil der grundlegenden Servertechniken selbst zu implementieren. 

So ist es z.B. zulässig, daß der Bean-Provider die Transaktionsverwaltung oder 

die Aspekte des Objekt-Relationalen Mappings selbst in der Bean implementiert. In einem solchen 

Fall werden die entsprechenden Dienste des Containers nicht in Anspruch genommen. 

Der Bean-Entwickler muß zu seiner Bean immer einen Deployment-Deskriptor (siehe Abschnitt 

4.8) liefern, der wichtige Informationen über die Bean selbst sowie über externe Abhängigkeiten 

der Bean (z.B. auf welche Serverdienste sie angewiesen ist) enthält. 

Die Beans zusammen mit den Deployment-Deskriptoren übergibt der Bean-Provider dem 

Application-Assembler, der im folgendem Abschnitt behandelt wird. 

4.7.4 Application-Assembler 

Die Aufgaben des Application-Assemblers bestehen darin, mehrere (kleinere) Komponenten, 

die er von Bean-Providern erhält, zu einer neuen (größeren) Komponente zusammenzufassen. 

Mit den Beans erhält der Application-Assembler immer ein oder mehrere ejb-jar Dateien 

vom Bean-Provider. 

Der Application-Assembler dokumentiert seine Arbeit im Deployment-Deskriptor. Er trägt 

z.B. Informationen über verwendete Ressourcen oder Abhängigkeiten zu Nicht-EJB-Komponenten 

in den Deployment-Deskriptor ein. 

4.7.5 Deployer 

Die von dem Container-Provider bereitgestellten Programme zur Verwaltung des Containers 

und der installierten Beans stellen die Hauptaufgabe des Deployers dar. Mit Hilfe dieser 

Werkzeuge installiert der Deployer die Beans in einen Container. Weiterhin ist der Deployer 

dafür zuständig, die im Deployment-Deskriptor aufgeführten externen Abhängigkeiten 

aufzulösen sowie die Anweisungen des Application-Assemblers zu berücksichtigen. 

4.7.6 System-Administrator 

Aus der Sicht der EJB-Spezifikation ist der System-Administrator zuständig für die Konfiguration 

und Administration der Netzwerk-Infrastruktur (vergl. [Matena, Hapner 99]). Die 

Konfiguration und Administration des EJB-Servers und des EJB-Containers sind hier ebenfalls 

eingeschlossen. 

Als Beispiel läßt sich hier die Integration von Ressourcen-Managern (z.B. Datenbanken) in 

EJB-Containern nennen. Eine weitere Aufgabe des System-Administrators ist es, die installierten 

Komponenten zur Laufzeit zu überwachen.


4.8 Deployment-Deskriptor 

Einer der wichtigsten Faktoren für die Portabilität der Beans ist der Deployment-Deskriptor. 

Er beinhaltet nicht nur allgemeine Informationen, wie z.B. den Namen der Bean und die Namen 

ihres Home- und Remote-Interface, sondern auch Informationen für den EJB-Container, 

wie dieser u.a. das transaktionale Verhalten, die Persistenz, die Autorisierung der Enterprise 

JavaBean verwalten soll. 

Dadurch, daß die wichtigen Informationen über eine Bean in dem Deployment-Deskriptor 

gespeichert werden, wird die Portabilität (d.h. genauer die Lauffähigkeit der Bean in verschiedenen 

EJB-Containern unterschiedlicher Hersteller) der Enterprise JavaBeans erst möglich. 

In Abbildung 4.8 ist beispielhaft ein Deployment-Deskriptor aufgeführt. 

Die Hauptaufgabe des Deployment-Deskriptors ist es, die deklarativen Informationen über 

die Enterprise Beans zusammenzufassen. Damit sind Informationen gemeint, die nicht direkt 

in den Enterprise Beans gespeichert werden. Bei dem Deployment-Deskriptor handelt 

es sich zunächst um eine Text-Datei, die mit jedem beliebigen Text-Editor bearbeitet werden 

kann. Dadurch werden Änderungen an dieser Datei recht einfach und schnell durchführbar. 

Wie in der Abbildung 4.8 zu sehen ist, ist der Deployment-Deskriptor entsprechend 

der XML-Syntax aufgebaut (engl., Extendible Markup Language). In der letzten EJB- 

Spezifikation (EJB 1.0) wurde der Deployment-Deskriptor durch eine spezielle Klasse implementert, 

die nach ihrer Initialisierung mit den entsprechenden Werten serialisiert wurde. Die 

Änderung eines Parameters hatte zur Folge, daß die Klasse zunächst deserialisiert werden 

mußte, anschließend die Änderung durchgeführt und schließlich wieder serialisiert werden 

mußte. 

Durch den nun XML-basierten Deployment-Deskriptor ist die Änderung von Parametern 

vereinfacht worden. Nähere Informationen zum Thema XML können z.B. in [Ray 01] oder 

[XML ] nachgelesen werden. 

4.9 Portabilität und Enterprise JavaBeans 

In diesem Abschnitt wird vorgestellt, welche Art von Portabilität der EJB-Standard bietet. 

Enterprise JavaBeans-Komponenten, die entsprechend der Spezifikation entworfen wurden, 

können ohne weitere Modifikation an der Geschäftslogik in anderen EJB-Servern installiert 

werden. 

Die Hilfswerkzeuge des EJB-Servers müssen lediglich die Klassen für die Netzwerkkommunikation 

erstellen. Die Bean-Klassen werden nicht neu übersetzt. Bei den Klassen für die 

Netzwerkkommunikation handelt es sich um die Implementierung der sog. Stubs und Skeletons 

und des EJB-Objektes, vom dem das Remote-Interface die Funktionalität erbt. 

4.10 Java 2 Plattform, Enterprise Edition 

Die Java 2 Plattform, Enterprise Edition (J2EE) wurde von [Sun ] entwickelt. Ziel der J2EE- 

Architektur ist es, die Portabilität von vollständigen mehrschichtigen Anwendungen auf 

unterschiedlichen J2EE-konformen Application-Servern zu realisieren.


 

 

 

 

 

 

This Cabin enterprise bean entity represents a cabin on 

a cruise ship. 

 

CabinBean 

com.titan.cabin.CabinHome 

com.titan.cabin.Cabin 

com.titan.cabin.CabinBean 

Container 

com.titan.cabin.CabinPK 

False 

id 

name 

deckLevel 

ship 

bedCount 

 

 

 

 

 

This role represents everyone who is allowed full access 

to the cabin bean. 

 

everyone 

 

 

everyone 

 

CabinBean 

* 

 

 

 

 

CabinBean 

* 

 

Required 

 

 

 

Abbildung 4.1: Beispiel eines Deployment-Deskriptors


Eine J2EE-Anwendung besteht in der Regel aus einer oder mehreren Enterprise Beans, Web 

Komponenten und J2EE Application Clients. Der Aufbau einer solchen J2EE Applikation ist 

in Abbildung 4.2 dargestellt. Jedes Package (.jar, .war oder .ear - Dateien) enthält einen XML 

Deployment-Deskriptor, der die jeweilige Komponente beschreibt. Die verschiedenen Teile 

einer solchen J2EE-Anwendung können unabhängig voneinander, anhand ihrer Schnittstellen 

implementiert werden. 

J2EE Application 

J2EE App. DD 

(DD= Deployment−Descriptor) 

.ear file 

J2EE App. Client 

Enterprise Java Bean 

Web Component 

J2EE App. Client DD 

Java App. 

.jar file 

EJB DD 

EJB Class 

Remote 

Home 

.jar file 

Web Component DD 

JSP File 

Servlet Class 

GIF File 

HTML File 

.war file 

Abbildung 4.2: Bestandteile einer J2EE Anwendung 

Die Java 2 Platform, Enterprise Edition (J2EE) definiert den Standard für die Entwicklung 

mehrschichtiger Unternehmensanwendungen. Der J2EE-Standard trägt zu einer Vereinfachung 

der Unternehmensanwendungen bei, da er diese aus standardisierten und modularen 

Komponenten zusammenfügt, umfassende Dienste für diese Komponenten bereitstellt 

und zahlreiche Aspekte des Anwendungsverhaltens ohne großen Programmieraufwand automatisch 

verwaltet (vergl. [J2EE ]). 

Die Java 2 Platform, Enterprise Edition stellt viele Leistungsmerkmale der Java 2 Plattform, 

Standard Edition bereit, darunter die 

• "Write Once, Run Anywhere“-Portabilität,


• die JDBC-API für den Datenbankzugriff, 

• die CORBA-Technologie für die Interaktion mit vorhandenen Unternehmensressourcen, 

• ein Sicherheitsmodell zum Schutz der Daten in Internetanwendungen. 

Zusätzlich dazu bietet die Java 2 Plattform, Enterprise Edition auch volle Unterstützung für 

folgende Programmierschnittstellen: 

• Enterprise JavaBeans-Komponenten, 

• Java Servlets 

• sowie Java ServerPages und XML-Technologie 

Der J2EE-Standard schreibt umfassende Spezifikations- und Konformitätstests vor, um die 

Portierbarkeit von Applikationen für die breite Palette vorhandener J2EE-fähiger Unternehmenssysteme 

sicherzustellen (vergl. [J2EE ]). 

Der wichtigste Bestandteil von J2EE ist das EJB-Komponentenmodell. Das EJB-Komponentenmodell 

bildet das Grundgerüst für den J2EE-Standard. 

Die J2EE-Architektur ist in Abbildung 4.3 zu sehen (aus [Sun 01]). In der Abbildung 4.3 sind 

zwei Hauptbestandteile der J2EE zu sehen: der EJB-Container und der Web-Container. 

Durch J2EE soll es möglich werden, vollständige Anwendungen ohne Modifikation der Anwendungslogik 

auf verschiedene J2EE-konforme Application-Server zu installieren. Bei den 

bisherigen konventionellen Lösungen ist es nicht möglich, komplette Anwendungen von einem 

Hersteller zu einem anderen zu migrieren. Die Ursache hierfür liegt in der Tatsache, 

daß es keinen einheitlichen Standard gibt und jeder Hersteller daher sein eigenes Verfahren 

entwickelt hat. 

Design Tipps zu EJB Komponenten und J2EE finden sich z.B. in [Marinescu 02]. 

An dieser Stelle soll nicht näher auf J2EE eingegangen werden, es sollte in diesem Abschnitt 

lediglich der Zusammenhang zwischen dem EJB-Komponentenmodell und J2EE aufgezeigt 

werden. In dem nun folgenden Kapitel werden die Eigenschaften und Merkmale 

eines Application-Servers vorgestellt und erläutert. Die Application-Server nehmen im EJB- 

Komponentenmodell eine wichtige Rolle ein.


J2EE Server 

EJB Container 

Client 

(Web Browser) 

Web Container 

Enterprise 

Bean 

JSP File 

Enterprise 

Bean 

Datenbank− 

Server 

Servlet 

Enterprise 

Bean 

Client 

(Java Application) 

JMS 

JNDI 

RMI/IIOP 

JDBC 

JTA 

Java 

Mail 

JAF 

JMS 

JNDI 

RMI/IIOP 

JDBC 

JTA 

Java 

Mail 

JAF 

JMS 

JNDI 

RMI/IIOP 

JDBC 

J2SE 

J2SE 

J2SE 

Abbildung 4.3: Überblick der J2EE Architektur

Kapitel 5 

Application-Server 

In Kapitel 4 wurde das Enterprise JavaBeans Komponentenmodell ausführlich vorgestellt. 

Zur praktischen Nutzung dieses Modells ist eine Implementierung in Gestalt eines Application-Servers 

erforderlich. Erst mit Hilfe der Application-Server können die Komponenten 

ihre Dienste anbieten. Der Schwerpunkt dieses Kapitels ist daher, das Zusammenspiel von 

Application-Server und Komponenten zu zeigen. 

Um ein besseres Verständnis für die Application-Server zu bekommen, wird zunächst in Abschnitt 

5.1 gezeigt, wie sich die Anwendungssystem-Architekturen entwickelt haben. Abschnitt 

5.1.1 beschreibt dabei die Entwicklungsstufe der Großrechner-Architektur, Abschnitt 

5.1.2 die Stufe der Client-Server Architektur und Abschnitt 5.1.3 schließlich die Mehrschichten 

Architektur, die für die Application-Server relevant ist. 

In Abschnitt 5.2 werden zum Abschluß dieses Kapitels die von Application-Servern üblicherweise 

angebotenen Dienste aufgeführt. 

Es ist zu berücksichtigen, daß viele Prinzipien der Softwareentwicklung wie. z.B. modularer 

Aufbau und Trennung von Anwendungs-, Präsentations- und Datenhaltungslogik schon 

seit längerer Zeit bekannt sind, die Leistungsfähigkeit der Netzwerke (z.B. Ethernet) jedoch 

den Einsatz flexibler Architekturen wie die Mehrschichtenarchitektur verhinderte. Die Antwortzeiten 

waren so lang, daß ein praktischer Einsatz von Anwendungen, die auf mehreren 

Rechnern verteilt waren, nicht möglich war. 

5.1 Evolution der Anwendungssystem-Architekturen 

In diesem Abschnitt wird die Entwicklung von der Großrechner-Architektur, über die zwei- 

Schichten Architektur bis zu der drei-Schichten Architektur dargestellt. 

Zur Klassifikation wird dabei die Verteilung folgender Aufgabenbereiche verwendet: 

• Präsentationslogik 

Hierunter wird die Implementierung der graphischen Benutzerschnittstelle verstanden. 

Unter dem Begriff „Präsentationslogik“ wird jeglicher Programmcode verstanden, 

der für die visuelle Darstellung von Anwendungsinformationen zuständig ist. 

32

KAPITEL 5. APPLICATION-SERVER 33 

• Anwendungslogik. 

• Datenhaltung. 

Für die Datenhaltung hat sich das relationale Datenbankmodell durchgesetzt. In der Praxis 

wird als Datenspeicher fast ausschließlich ein Datenbanksystem eingesetzt. Hierunter 

wird die Art des Datenspeichers verstanden. 

5.1.1 Großrechner Architektur 

Bis Mitte der 80’er Jahre war die Großrechner-Architektur sehr verbreitet. Diese sehr leistungsfähigen 

Großrechner wurden als Host oder aber auch Mainframe bezeichnet. Kennzeichnend 

für Mainframes ist, daß zahlreiche Terminals (Datensichtstation, vergl. [Duden 

93]) an einem Host angeschlossen sind. Diese Terminals bestehen i.d.R. aus einer Tastatur 

und einem zeichenorientierten Bildschirm. Sie sind im Prinzip nur in der Lage, eine Verbindung 

zum Mainframe herzustellen sowie Text zu senden und zu empfangen. 

In Abbildung 5.1 wird schematisch die Großrechner Architektur dargestellt. 

Mainframe 

Präsentationslogik 

GeschäftsKomponente1 

Terminal 

Datenhaltung 


1..* 

Abbildung 5.1: Großrechner Architektur 

Wie in Abbildung 5.1 zu sehen ist, sind alle Programmteile auf einem Mainframe positioniert. 

Die Anwendungslogik, die Präsentationslogik und die Datenverwaltung liegen zentral 

auf einem Mainframe und können so zentral gewartet werden . 

Die Vorteile der Mainframes sind vor allem die Zuverlässigkeit und das große Leistungspotential. 

Sie sind daher in der Lage, eine vielzahl von Benutzern zu unterstützen.


Der Einsatz von Mainframes bringt jedoch auch Nachteile mit sich. Zu nennen sind hier vor 

allem der sehr hohe Preis und die langen Software Entwicklungszyklen. Trotz zentralisierter 

Datenhaltung, sind die zu entwickelnden Anwendungen sehr komplex, da alle Programmteile 

einer Anwendung – Präsentationslogik, Anwendungslogik, Datenhaltung – in einer 

einzigen Anwendung implementiert und gewartet werden müssen. Bei Wartungsarbeiten 

mußten alle Applikationen auf diesem Host gestoppt werden. Ein weiteres Problem mit den 

Mainframes ist die Ausfallsicherheit. Wenn ein Mainframe wegen hardware Problemen ausgefallen 

war, war kein arbeiten möglich. Auch die Terminals sind aufgrund ihrer Zeichenorientierung 

für die Darstellung komplexer Information wenig geeignet. Graphische Terminals 

wurden erst später eingeführt, konnten aber die oben aufgeführten Nachteile nicht vollständig 

beheben. 

Aufgrund der Tatsache, daß die Mainframes sowohl die Anwendungslogik als auch die Präsentationslogik 

enthielten spricht man auch von der sog. ein-Schichten Architektur. 

Erst durch die im nächsten Abschnitt erläuterte Client-Server Architektur konnten einige 

Nachteile der Großrechner Architektur behoben werden. 

5.1.2 Client-Server Architektur 

Ende der 80’er Jahre wurde die Großrechner-Architektur mehr und mehr durch die Client- 

Server Architektur abgelöst. Die Ursache hierfür waren die mittlerweile im Computer-Markt 

verfügbaren Personal Computer (PCs), die über ausreichend Rechenleistung verfügten. Dies 

ebnete den Weg für die Client-Server Architektur. 

Die teuren Mainframes konnten nun durch zahlreiche, günstige und leistungsfähige PCs ersetzt 

werden. Die sich so ergebende Client-Server Architektur wird auch als zwei-Schichten 

Architektur bezeichnet. 

Abbildung 5.2 zeigt den schematischen Aufbau einer zwei-Schichten Architektur. Die eine 

Schicht wird durch den Client repräsentiert. Die zweite Schicht wird durch einen Server 

repräsentiert, auf dem ein Datenbankserver läuft. 

Client 

GUI 

BusinessComponent1 

1..* 

Server 

Datenbank 

BusinessComponent2 

Abbildung 5.2: Client-Server Architektur 

Da die Rechenleistung der PCs ausreichend war um einige Berechnungen durchzuführen,


hat man einen Teil der Anwendungslogik auf die Client-PCs verlagert, um so den Server (ein 

leistungsfähiger PC) zu entlasten und die vorhandene Rechenleistung auf den Clients besser 

zu nutzen. Auf dem Server läuft in der Regel eine Datenbank, in der ein großer Teil der Anwendungslogik 

implementiert sein kann. Abhängig von Verteilung der Anwendungslogik 

auf Client und Server unterscheidet man zwei Arten von Clients: 

• Fat Client. 

Unter einem Fat Client versteht man in der Regel eine Software, die neben der graphischen 

Benutzerschnittstelle einen Großteil der Anwendungslogik ausführt. 

• Thin Client. 

Ein Thin Client ist ein Computer, der außer der graphischen Benutzerschnittstelle sehr 

wenig Anwendungslogik enthält. Thin Clients sind z.B. Web-Browser. In einem solchen 

Fall handelt es sich um webbasierte Thin-Clients. 

Zu den Vorteilen der zwei-Schichten Architektur zählen: 

• Es lassen sich relativ schnell Anwendungen für die zwei-Schichten Architektur entwickeln. 

• Die Einführung von RAD-Werkzeugen (Rapid Application Development, deutsch: schnelle 

Anwendungsentwicklung). 

Durch die Einführung von RAD-Werkzeugen wurden die graphischen Benutzerschnittstellen 

benutzerfreundlicher. Auch wurde durch die leistungsfähigen RAD-Werkzeuge 

der Entwicklungszyklus für Client-Server Anwendungen sehr verkürzt. 

Obwohl die zwei-Schichten Architektur gegenüber der Großrechner Architektur einige Vorteile 

aufweisen kann, überwiegen die Nachteile einer solchen Architektur: 

• Enge Verzahnung von Anwendungslogik, Präsentationslogik und Datenhaltung bereitet 

bei der Programmwartung erhebliche Probleme. 

So ziehen z.B. kleinste Änderungen an Tabellen auf dem Datenbank-Server Modifikationen 

in allen Clients nach sich, da alle Clients die Anwendungslogik besitzen. 

• Ein Fehler in der Anwendungslogik kann die Datenintegrität der Datenbank beeinflussen, 

da alle Clients die Anwendungslogik besitzen. 

• In Unternehmen mit einer großen Anzahl von Clients ist die Verwaltung der Clients 

sehr aufwendig. 

Um den Aufwand gering zu halten, müssen alle Clients einheitlich sein. 

• Die Skalierbarkeit ist eingeschränkt. 

Jede Client-Anwendung benötigt eine eigene Verbindung zu der Datenbank. Die Anzahl 

der offenen Datenbank-Verbindungen ist jedoch meistens durch das eingesetzte 

Datenbankprodukt eingeschränkt. Daher bildet das eingesetzte Datenbanksystem in 

den meisten Fällen einen sog. Flaschenhals.


• Die Anwendung ist an eine feste Darstellung gebunden, die in den Clients in Form der 

Präsentationslogik implementiert ist. 

Ein Wechsel der Darstellung ist nur durch eine Neuimplementierung der Präsentationslogik 

möglich. Dies bedeutet jedoch eine Neuinstallation der Anwendung auf 

sämtlichen Clients. 

• Das Netzwerk wird durch die zahlreichen Datentransfers von Clients zum Server stark 

belastet. 

Wie man aus dem direkten Vergleich der Vor- und Nachteile ersehen kann, überwiegen 

die Nachteile der zwei-Schichten Architektur. Da die zwei-Schichten Architektur zahlreiche 

Nachteile und Einschränkungen besitzt, hat man nach besseren Lösungsansätzen gesucht. 

Als letzte Entwicklungsstufe der Anwendungssystem-Architekturen hat sich die Mehrschichten 

Architektur durchgesetzt, die in dem Folgenden Abschnitt behandelt wird. 

5.1.3 Mehrschichten Architektur 

Mit Hilfe der Mehrschichten Architektur lassen sich die Einschränkungen der zwei-Schichten 

Architektur mindern. 

Ein typischer Vertreter der Mehrschichten Architektur ist die sog. drei-Schichten Architektur 

(im engl.: 3-tier architecture). Wie in [Saake, Sattler 00] beschrieben, wird bei der drei- 

Schichten Architektur eine zusätzliche Schicht zwischen Client und Server eingeführt. Die 

Anwendungslogik ist dann in dieser Schicht gekapselt (vergl. Abbildung 5.3), wodurch ein 

Application-Server entsteht. Alle Zugriffe auf den Datenbank-Server (DB-Server) werden 

nur vom Application-Server durchgeführt. Die Clients haben folglich keinen direkten Zugriff 

auf den DB-Server, im Gegensatz zu der zwei-Schichten Architektur. 

Die Clients können nun höherwertige Dienste des Applikationsservers in Form von Funktionen 

oder gar Objekten in Anspruch nehmen. Solche Dienste können z.B. das Suchen eines 

Kunden oder das Anlegen einer Bestellung sein. 

Die drei-Schichten Architektur ist insbesondere dann geeignet, wenn die Anwendungslogik 

in mehreren verschiedenen Clients genutzt werden soll. Gängige Clients sind mittlerweile: 

• Web-Browser 

• Java-Anwendungen 

• Spezielle Geräte, wie z.B. PDAs, Mobiltelefone 

Die dritte Schicht (der Server) dient der Datenhaltung. Hier sind insbesondere Datenbanksysteme 

zu finden. 

Zu bemerken ist noch, daß die Abstraktion der verschiedenen Aufgabenbereiche lediglich 

logische Grenzen kennzeichnet. In der Praxis können die unterschiedlichen Aufgaben durchaus 

auf einem System ausgeführt werden. 

In dem nun folgenden Abschnitt werden die von einem Application Server angebotenen 

Dienste tiefer behandelt.


Application-Server 

Client 

Client 


1..* 

Datenbank-Server 

Datenbank 

1..* 

Präsentationslogik 


Abbildung 5.3: Drei-Schichten Architektur 

5.2 Angebotene Dienste 

Die generell von einem Application-Server angebotenen Dienste und desssen Aufgabe lassen 

sich verdeutlichen, indem man den Application-Server aus der Mehrschichten-Architektur 

nicht betrachtet. Dieses ist in Abbildung 5.4 zu sehen. In dieser Abbildung sind verschiedene 

Clients abgebildet, wie z.B. HTML-Clients, Corba-Clients, D/COM-Clients oder Java 

Applikationen. All diese Clients benötigen einen Zugriff auf bestimmte Ressourcen, wie z.B. 

bestimmte Alt-Anwendungen, Datenbanken oder Dateien. 

Zu den allgemeineren Diensten eines Application-Servers zählen das connection management 

von unterschiedlichen Clients, das Zustands- und Sitzungsmanagement sowie die Anbindung 

an Datenbanksysteme. Das hosting von Anwendungslogik zählt hierbei zu den wichtigsten 

Diensten eines Application-Servers. 

Um diese Dienste den unterschiedlichen Clients anbieten zu können, muß ein Application- 

Server auch viele verschiedene Kommunikations- und Übertragungsprotokolle bereitstellen. 

Daraus folgt die primäre Aufgabe eines Application-Servers: die Weiterleitung von Client- 

Anfragen an unterschiedliche Ressourcen. Dieser Sachverhalt wird in Abbildung 5.5 duch 

die Rolle der Application-Server in der Mehrschichten-Architektur deutlich. 

Neben all diesen primären Diensten bieten die Application-Server weitere an, wie z.B. (vergl. 

[InfoWeek 00]): 

• Koordination von Transaktionen 

• Lastverteilung 

• Sicherheitsmechanismen 

• Dienste zum Bedienen von Web-Schnittstellen 

Durch die zahlreich angebotenen Dienste wird der Anwendungsentwickler bei der Anwendungsentwicklung 

wesentlich unterstützt, was zu einer besseren Produktivität führt. Der 

Produktivitätszuwachs durch Applikations-Server hat jedoch seinen Preis: es ist nur schwer


möglich, eine bestehende Anwendung auf einen anderen Application-Server eines anderen 

Herstellers zu migrieren, da jeder Hersteller ein anderes Rahmenwerk für die Programmentwicklung 

bereitstellt. 

Genau an diesem Punkt setzt der EJB-Standard an: eine nach der EJB-Spezifikation entworfene 

Komponente ist in EJB-Servern verschiedener Hersteller lauffähig. 

Die Anzahl und Komplexität der angebotenen Dienste von neuen Application-Servern nimmt 

stetig zu. 

In den nun folgenden Unterabschnitten werden die allgemeinen Dienste von Application- 

Servern näher erläutert (vergl. [Benfield 99]). 

Ohne Application−Server 

CLIENTS 

BACKEND 

HTML 

Alt−Anwendungen 

Java Applikationen 

DB 

CORBA 

D/COM 

EJB 

Dateien 

Spezielle Geräte 

(PDA,Set−top−Box) 

Abbildung 5.4: Ohne Einsatz eines Application-Servers


Mit Application−Server 

CLIENTS 

BACKEND 

Application−Server 

HTML 

HTTP, CGI, Servlets, JSP 

Komponenten 

CORBA, EJB/RMI, 

D/COM 

Alt−Anwendungen 

Java Applikationen 

Datenzugriff: 

JDBC 

CORBA 

D/COM 

EJB 

Spezielle Geräte 

(PDA,Set−top−Box) 

Transaktionsverwaltung 

XA,JTS/JTA 

Sicherheit: 

SSL,ACL,X.509 

Verzeichnis−Dienste 

JNDI,COS 

Fehlertoleranz 

Lastausgleich 

Ressourcen−Pooling 

DB 

Dateien 

Abbildung 5.5: Mit Einsatz eines Application-Servers


5.2.1 Authentifizierung 

Um Benutzern den Zugriff auf sensible Daten zu gewähren, die in einer Datenbank gespeichert 

sind, muß der Benutzer authentifiziert werden. Für diese Anforderung stellen die 

Application-Server einen Authentifizierungs-Dienst bereit. 

5.2.2 Skalierbarkeit 

Sollte sich die Produktionsumgebung eines Application-Servers ändern, z.B. durch eine Zunahme 

der Benutzerzahl, ist es möglich, einen weiteren oder mehrere Application-Server 

hinzuzufügen, die dann gemeinsam die gestiegene Last verarbeiten können. Wichtig ist hierbei, 

daß die Anwendungen auf dem Application-Server hiervon unberührt sind. 

5.2.3 Lastausgleich und Ausfallsicherheit 

Der Begriff Lastausgleich (im engl.: load-balancing) bezeichnet bei einem Application-Server 

einen Mechanismus, bei dem mehrere Application-Server einen sog. Cluster bilden. Alle 

Application-Server eines Clusters bekommen die Anfragen der Clients von einem zentralen 

Rechner. Dieser sog. request-dispatcher, der für den Lastausgleich zuständig ist, leitet Client- 

Anfragen an den am geringsten ausgelasteten Application-Server weiter. Von diesem Zeitpunkt 

an kommuniziert der Client direkt mit dem Application-Server. 

Bei steigenden Benutzerzahlen nimmt die Last auf den Application-Servern zu. Durch Hinzufügen 

von weiteren Application-Servern kann die Last wieder verringert werden. Daher 

ist das load-balancing ein Mechanismus, der die Skalierbarkeit von Application-Servern mitbestimmt. 

Ausfallsicherheit (im engl. fail-over) im Zusammenhang mit Application-Servern ist ein Mechanismus, 

der in gewissem Maße Fehlertoleranz bietet. Beim Ausfall eines Application- 

Servers aus dem Cluster, werden neue Anfragen nicht mehr an den ausgefallenen Application-Server 

weitergeleitet, sondern an einen der anderen im Cluster. Ausfallsicherheit wird 

daher oft nur in Zusammenhang mit Lastausgleich angeboten. 

5.2.4 Transaktionssteuerung 

Die auf den Application-Servern abgelegte Anwendungslogik muß beim Zugriff auf Ressourcen 

durch den Einsatz von Transaktionen gesichert werden. Die Aufgabe des Application-Servers 

ist hierbei die Kontrolle und Steuerung der Transaktionen sowie die Koordination 

von Transaktionen. 

5.2.5 Datenbankzugriff 

Eine der wichtigsten Anforderungen an Softwaresysteme ist die dauerhafte Speicherung 

von Daten bzw. Informationen. Als Datenspeicher werden zur Zeit hauptsächlich relationale


Datenbanken eingesetzt. Alle zur Zeit verfügbaren Application-Server bieten daher Schnittstellen 

an, mit deren Hilfe auf diverse relationale Datenbanken zugegriffen werden kann. 

Schnittstellen für den Zugriff auf Daten, die nicht in relationalen Datenbanken abgelegt sind, 

sind nicht im Umfang jedes Application-Servers enthalten. 

5.2.6 Zustands- und Sitzungssteuerung 

Während der Sitzungsdauer eines Benutzers, muß der Application-Server Zustandsdaten 

zwischen den einzelnen Anfragen speichern. Ein von Application-Servern zur Speicherung 

von Sitzungsdaten oft angebotener Lösungsansatz liegt im Einsatz von sog. Sitzungs-Objekten 

(im engl. session objects ). Deren Hauptaufgabe ist es, die während einer Sitzungsdauer 

eines Benutzers anfallenden Daten auf dem Server zu speichern, bis diese nicht mehr benötigt 

werden. 

Durch die Speicherung von Sitzungsinformation auf dem Application-Server wird die Entwicklung 

von Anwendungen vereinfacht. 

5.2.7 HTML-Generierung 

Bei den sog. browsergestützten thin-clients muß der Application-Server das HTTP-Protokoll 

(engl. hypertext transfer protocol) „verstehen“. Neben dem Beantworten von Client-Anfragen, 

muß der Application-Server natürlich auch HTML-Code generieren und ggf. mit Daten 

aus einer oder mehreren Datenbanken anreichern. 

Wie man anhand der hier aufgeführten Aufgaben und angebotenen Dienste sehen kann, 

ist ein Application-Server hauptsächlich ein Vermittler zwischen verschiedenen Systemen. 

Diese Eigenschaft is das Kennzeichen der sog. Middleware, die eine zentrale Rolle bei den 

EJB-Servern hat.

Kapitel 6 

Installation einer Beispielanwendung 

in EJB-Servern 

In diesem Kapitel wird zunächst in Abschnitt 6.1 eine Beispielanwendung vorgestellt und 

beschrieben. Im Abschnitt 6.1.1 wird die Beispielanwendung dann als EJB-Anwendung realisiert. 

In Abschnitt 6.2 wird die Entwicklungs- und Testumgebung beschrieben, in der die 

Anwendung entwickelt und getestet wird. Anschliessend werden in Abschnitt 6.3 die Kriterien 

erläutert, die zwischen den verschiedenen Application-Servern verglichen werden sollen. 

Als nächster Schritt wird die Beispiel-Anwendung in den Abschnitten 6.4, 6.5 sowie Abschnitt 

6.6 in verschiedenen Application-Servern installiert. Zum Abschluß dieses Kapitels 

werden in Abschnitt 6.7 die vorgestellten Vergleichs-Kriterien aus Abschnitt 6.3 ausgewertet. 

6.1 Beispielanwendung 

In Abbildung 6.1 ist das UML-Diagramm der hier behandelten Beispielanwendung dargestellt. 

Bei UML (engl. Unified Modelling Language) handelt es sich um eine Standard Notation 

für die Modellierung objektorientierter Systeme. Unterstützend wird UML bei der 

Analyse und dem Entwurf objektorientierter Systeme eingesetzt. Eingeführt wurde UML 

zwischen 1995 und 1997. Eine ausführlichere Behandlung von UML kann z.B. in [Fowler, 

Scott 99] oder [Larman 01] nachgelesen werden. 

Das in Abbildung 6.1 dargestellte konzeptuelle Modell der Beispielanwendung realisiert 

einen Dienst, der das Verknüpfen von einfachen Objekten zu komplexen Objekten erlaubt. 

Die einfachen Objekte werden hierbei durch die Klassen SubjectHeading und Content 

dargestellt. Komplexe Objekte werden durch die Klasse ElementaryWork dargestellt. Ein 

ElementaryWork-Objekt bindet genau ein SubjectHeading-Objekt und ein Content- 

Objekt. Die Komplexität ergibt sich nicht nur durch das Binden von zwei Objekten, sondern 

dadurch, daß ein ElementaryWork aus beliebig vielen weiteren ElementaryWork- 

Objekten zusammengesetzt sein kann, die ihrerseits jeweils ein SubjectHeading- und ein 

Content-Objekt binden. 

42

KAPITEL 6. INSTALLATION EINER BEISPIELANWENDUNG IN EJB-SERVERN 43 

Um die Anwendung besser zu verstehen, muß man wissen, was genau die einzelnen Klassen 

repräsentieren. Die Klasse SubjectHeading repräsentiert Begriffe oder Schlagwörter 

und die Klasse Content repräsentiert einen Inhalt mit einer bestimmten Bedeutung. Die 

Bindung eines Begriffes an einen Inhalt wird als ElementarWerk bezeichnet, was durch die 

Klasse ElementaryWork ausgedrückt wird. Ein ElementarWerk kann als ein Kontext aufgefasst 

werden, in dem ein Begriff eine spezielle Bedeutung hat. 

Die relevante Klasse in dieser Beispielanwendung ist ElementaryWork. In dieser Klasse 

findet sowohl die Bindung der einfachen Klassen Content und SubjectHeading statt als 

auch die Algorithmen zum Verwalten von Knoten und Blättern. 

Blätter sind ElementaryWork-Objekte, die keine Kinder besitzen, d.h. keine weiteren ElementaryWork-Objekte. 

Knoten sind ElementaryWork-Objekte, die Kinder besitzen. 

Bei näherer Betrachtung der Klasse ElementaryWork stellt man fest, daß es sich um eine 

modifizierte Version des Kompositions Entwurfsmusters handelt. Bei den Entwurfsmustern 

(engl. design patterns) handelt es sich um bewährte Lösungsansätze zu immer wiederkehrenden 

Entwurfsproblemen. Bei den Lösungsansätzen handelt es sich nicht um fertig codierte 

Lösungen, sondern um eine Beschreibung für einen möglichen Lösungsweg. Näheres 

zum Thema Entwurfsmuster kann z.B. in [Gamma et al. 95] nachgelesen werden. Das 

UML-Diagramm zur häufig eingesetzten Variante des Kompositions Entwurfsmusters ist in 

Abbildung 6.2 dargestellt. 

Der wichtigste Unterschied zwischen der Beispielanwendung und dem Kompositions Entwurfsmuster 

betsteht darin, daß die Blatt-Klasse und die Kompositum-Klasse in der Beispielanwendung 

zu einer Klasse zusammengefasst sind. Dieses erleichtert die spätere Realisierung 

einer EJB-Anwendung. 

Eine weitere wichtige Klasse in der Beispielanwendung ist CompDir. Diese Klasse ist als 

zentrales „Verzeichnis“ zu verstehen, in dem jede Bindung zwischen einem Content und 

einem SubjectHeading festgehalten wird. Zusätzlich wird der Name des bindenden ElementarWerkes 

ebenfalls in diesem Verzeichnis festgehalten. Durch diesen Ansatz hat man 

die Möglichkeit, komplexere Auswertungen auf Begriffen, Inhalten und ElementarWerken 

durchzuführen. Das Objektmodell erlaubt es, daß ein SubjectHeading von verschiedenen 

ElementarWerken gebunden werden kann. Durch den Einsatz eines solchen zentralen 

Verzeichnisses hat man dann die Möglichkeit, alle ElementarWerke und Content-Objekte 

herauszufinden, an denen ein bestimmtes SubjectHeading gebunden ist. 

Voraussetzung hierfür ist, daß an den Stellen, wo eine Bindung vorgenommen wird, das 

Verzeichnis aktualisiert werden muß. Zusätzlich muß der Zustand des Verzeichnisses persistent 

gespeichert werden. 

Ein Ausschnitt der Klasse ElementaryWork ist in Abbildung 6.3 zu sehen.Diese Klasse ist 

sowohl im Objektmodell als auch im EJB-Modell identisch, d.h. diese Klasse wird bei der 

Überführung in eine EJB-Anwendung nicht modifiziert. 

Das in Abbildung 6.1 dargestellte konzeptuelle Modell der Beispielanwendung wird nun in 

den folgenden Unterabschnitten schrittweise in ein EJB-Modell überführt.


Serializable 

ElementaryWork 

−elementaryWorkVector:Vec 

−title:String 

−content:Content 

−isLeaf:boolean 

−DEBUG:boolean 

+ElementaryWork 



+print:void 

+add:boolean 

+remove:void 

+toString:String 

+findSubject:ElementaryWor 

+findInAllSubjects:Vector 

+contains:boolean 

+equals:boolean 

+alterElement:boolean 

+log:void 

Content 

+Content 


URI:String 

SubjectHeading 

+SubjectHeading 


name:String 

children:Enumeration 

parent:ElementaryWork 

leaf:boolean 

subjectHeading:SubjectHea 

contentURI:Content 

ID:String 

debug:boolean 

Abbildung 6.1: UML-Klassendiagramm der Beispielanwendung


interface 

Component 

0..* 

+sampleOperation:void 

composite:Composite 

Leaf 



Composite 

−componentVector:Vector 


+add:void 

+remove:void 

+components:Enumeration 


Abbildung 6.2: UML-Klassendiagramm des Kompositions Entwurfsmusters


import java.util.Vector; 

import java.util.Enumeration; 

import java.io.Serializable; 

public class ElementaryWork implements Serializable { 

private Vector elementaryWorkVector = null; 

private String title; 

private SubjectHeading subjectHeading; 

private Content content; 

private ElementaryWork parent = null; 

private boolean isLeaf; 

} 

public ElementaryWork(String title, SubjectHeading subjHead, Content cont) { 

... 

CompDir.add(subjHead.getName(), title, cont.getURI()); 

} 

public boolean add(ElementaryWork elementaryWork) { ... } 

public void remove(ElementaryWork elementaryWork) { ... } 

public Enumeration getChildren() { ... } 

public ElementaryWork getParent() { ... } 

public void setLeaf(boolean b) { ... } 

public void setParent(ElementaryWork parent) { ... } 

public ElementaryWork findSubject(String subj) { ... } 

public Vector findInAllSubjects(String subj, boolean exactSearch) { ... } 

public boolean alterElement(ElementaryWork elwork) { ... } 

public SubjectHeading getSubjectHeading() { ... } 

public Content getContentURI() { ... } 

Abbildung 6.3: Ausschnitt der Klasse ElementaryWork


6.1.1 EJB-Komponenten der Beispielanwendung 

Die erste EJB-Komponente in der Beispielanwendung ist die Entity-Bean Komponente Work- 

Bean, der genau ein ElementaryWork Objekt zugeordnet ist. Das Ergebnis ist in Abbildung 

6.4 zu sehen. Bei der EJB-Komponente WorkBean handelt es sich um eine Entity Bean, 

deren Persistenz vom EJB-Container verwaltet werden soll (Container Managed Persistence, 

CMP). Container Managed Persistence ist an den fehlenden JDBC-Anweisungen in 

der Bean-Klasse zu erkennen (vergl. Kapitel 4). 

EntityBean 

WorkBean 

Work 

WorkHome 

java.lang.String 

+work:ElementaryWork 


−context:EntityContext 

+title:String 

+setEntityContext:void 

+ejbActivate:void 

+ejbPassivate:void 

+ejbRemove:void 

+ejbLoad:void 

+ejbStore:void 

+unsetEntityContext:void 

+WorkBean 

+log:void 

−nrOfElements:int 

+ejbCreate:String 

+ejbCreate:String 

+ejbPostCreate:void 

+ejbPostCreate:void 

+findByPrimaryKey:Work 

+print:void 

+add:boolean 

+remove:void 

+getAllChildren:Enumeration 

+getChildren:Vector 

+getParent:ElementaryWork 

+setLeaf:void 


+findSubject:ElementaryWork 



+getSubjectHeading:SubjectHE 

+setSubjectHeading:void 


+getContentURI:Content 

+setContentURI:void 

+setDebug:void 

Serializable 

ElementaryWork 

−elementaryWorkVector:Vector 

−title:String 

−content:Content 

−isLeaf:boolean 





+print:void 

+add:boolean 

+remove:void 


+findSubject:ElementaryWork 



+equals:boolean 


+log:void 

children:Enumeration 

parent:ElementaryWork 

leaf:boolean 

subjectHeading:SubjectHeadin 

contentURI:Content 

ID:String 

debug:boolean 

Content 

+Content 


URI:String 

SubjectHeading 

+SubjectHeading 


name:String 

Abbildung 6.4: UML-Klassendiagramm der Beispielanwendung mit EJB-Komponenten 

Da von der EJB-Spezifikation [Matena, Hapner 99] verlangt wird, daß jede Entity-Bean einen 

Primärschlüssel benötigt, wurde der Entity-Bean WorkBean als Primärschlüssel das Attribut 

title hinzugefügt. Das Objektmodell der Beispielanwendung benötigt diesen Primär-


schlüssel jedoch nicht. 

Die Entity Bean WorkBean besitzt daher als Primärschlüssel das Attribut title. Anhand 

dieses Attributs wird eine Entity-Bean des Typs WorkBean eindeutig gekennzeichnet, d.h. 

es existieren keine zwei Entity-Beans mit demselben title. Da eine Entity-Bean eine objektorientierte 

Sicht auf eine Zeile in der Datenbank darstellt, kann es auch keine zwei Zeilen 

mit demselben Primärschlüssel title geben. 

Durch die Tatsache, daß jeder Entity-Bean vom Typ WorkBean genau ein Objekt vom Typ 

ElementaryWork zugeordnet wird und des Primärschlüssels title, erhält man eine Unterteilung 

in Themengruppen. Eine Themengruppe wird durch das Attribut title in der 

Entity-Bean WorkBean festgelegt. Die Unterteilung in Themengruppen ist keine von der 

Applikation geforderte logische Strukturierung, sondern eine technische, um die Granularität 

der Beans zu vergröbern. 

Jeder Themengruppe können beliebig viele komplexe ElementaryWork-Objekte zugeordnet 

werden. Man könnte sich z.B. eine Themengruppe „e-mails“ vorstellen, in der alle verfassten 

e-mails abgelegt sind. Um in tiefere Schachtelungsstrukturen (ElementaryWork- 

Objekte) vordringen zu können, muß man den Titel einer Themengruppe kennen. 

Ein Großteil der Methoden der Klasse ElementaryWork wird in der Entity-Bean angeboten. 

Die Implementierung dieser Methoden in der Entity-Bean sieht dabei so aus, daß alle 

diese Methodenaufrufe delegiert werden an das der Entity-Bean zugeordnete ElementaryWork-Objekt. 

Die Entity-Bean übernimmt in diesem Fall eine Schnittstellen-Funktion für das ElementaryWork-Objekt. 

Wie in Kapitel 4 bereits beschrieben wurde, besitzt jede Session- und Entity-Bean ein Homeund 

Remote-Interface sowie einen Deployment-Deskriptor. 

In Abbildung 6.5 ist das Home-Interface der Entity-Bean WorkBean dargestellt. Wie schon in 

Kapitel 4 beschrieben, sind in dem Home-Interface Methoden zum Erzeugen und Auffinden 

von Beans vorhanden. 

Das Remote-Interface der Entity-Bean ist ein sog. Stellvertreter-Objekt (engl. Proxy-Object). 

Für den Client stellt das Stellvertreter-Objekt die Bean dar. Das Remote-Interface bietet alle 

Methoden der Bean an, die Clients verwenden dürfen. Abbildung 6.6 zeigt das Remote- 

Interface der Entity Bean. In der Abbildung wird deutlich, welche Geschäftsmethoden der 

Bean für den Benutzer zur Verfügung stehen. Es stehen Methoden zum Hinzufügen, Modifizieren 

und Suchen von ElementaryWork-Objekten zur Verfügung. 

Da in dem EJB-Komponentenmodell zahlreiche Eigenschaften der Beans deklarativ im Deployment-Deskriptor 

festgelegt werden, hat dieser eine zentrale Bedeutung im EJB-Komponentenmodell 

(vergl. Kapitel 4). Der Deployment-Deskriptor der Beispielanwendung ist in 

Abbildung 6.7 dargestellt. 

Wie in der Abbildung 6.7 dargestellt, wird für alle Methoden des Remote-Interfaces bei jedem 

Aufruf ein neuer Transaktions-Kontext erstellt, d.h. jeder Methodenaufruf läuft in einer 

eigenen Transaktion. Dieses ist erkennbar an den XML-Tags container-transaction 

und method-name.


import java.rmi.RemteException; 

import javax.ejb.*; 

public interface WorkHome extends EJBHome 

{ 

public Work create(String title) 

throws RemoteException, CreateException ; 

} 

public Work create(String title,SubjectHeading subjHead, Content cont) 

throws RemoteException, CreateException ; 

public Work findByPrimaryKey(String pk) 

throws FinderException, RemoteException ; 

import java.util.Vector; 

import java.util.Enumeration; 

import javax.ejb.*; 


Abbildung 6.5: Home-Interface der Entity-Bean 

public interface Work extends EJBObject 

{ 

public void print() throws RemoteException; 

} 

public boolean add(ElementaryWork elementaryWork) 

throws RemoteException; 

public boolean contains(ElementaryWork elementaryWork) 


public boolean alterElement(ElementaryWork elwork) 


public Enumeration getAllChildren() 


public void setLeaf(boolean b) throws 

RemoteException; 

public ElementaryWork findSubject(String subj) 


public Vector findInAllSubjects(String subj, boolean exactSearch) 


Abbildung 6.6: Remote-Interface der Entity-Bean


Da es sich beim Deployment-Deskriptor um eine einfache Textdatei im XML-Format handelt, 

ist es sehr einfach Modifikationen durchzuführen und Informationen aus dem Deployment-Deskriptor 

zu extrahieren. Wie in der Abbildung anhand des XML-Tags cmp-field 

zu sehen ist, wird das ElementaryWork-Objekt als vom Container zu verwaltendes Feld 

deklariert (CMP, container managed persistence). Dies bedeutet, daß der Container zuständig 

für die persistente Speicherung dieses Objektes ist. 

Die zweite Entity-Bean Komponente in der Beispielanwendung ist die Klasse CompDir, die 

in Abbildung 6.8 zu sehen ist. Die Klasse hat, wie bereits beschrieben, die Funktion eines 

zentralen Verzeichnisses. Diese Klasse bietet u.a. eine öffentliche Methode add an, mit deren 

Hilfe die Bezeichner der in Verbindung stehenden Objekte (SubjectHeading, Content, 

ElementaryWork) gespeichert werden. 

Intern verwendet die Klasse CompDir eine Hilfs-Klasse Mapper, um die Bindung der beteiligten 

Objekte besser speichern und handhaben zu können. 

6.2 Beschreibung der Entwicklungs- und Testumgebung 

Die EJB-Beispielanwendung wurde zunächst mit Hilfe der J2EE-Referenzimplementierung 

in der Version 1.2.1 von [Sun ] entwickelt. Die J2EE-Referenzimplementierung ist ein fertiges 

Produkt zum Entwickeln und Testen von EJB-Anwendungen. Dabei handelt es sich 

um einen Java EJB Application-Server, der alle vorgeschriebenen Programmierschnittstellen 

(APIs) des EJB-Standards enthält. Alle EJB-Applikationen, die entsprechend der EJB- 

Spezifikation entwickelt werden, sind auf der Referenzimplementierung lauffähig. 

Die Referenzimplementierung wurde von [Sun ] als Vorlage für die Hersteller von EJB Application-Servern 

entwickelt. 

Bevor eine EJB-Komponente verwendet werden kann, muß diese in den Application-Server, 

genauer gesagt im EJB-Container, installiert werden. Da zu einer Bean immer ein Home- 

Interface, ein Remote-Interface und ein Deployment-Deskriptor gehören, werden diese nicht 

einzeln im EJB-Container installiert, sondern es wird ein sog. JAR-Archiv verwendet. Anschliessend 

wird dieses JAR-Archiv mit Hilfe von Import-Werkzeugen des jeweiligen Application-Servers 

im EJB-Container installiert. Als persistenter Speicher wurde das relationale 

Datenbankmanagement-System von Oracle in der Version 8.1.6 verwendet. 

Die Beispielanwendung wurde mit einem J2EE-Installationswerkzeug, dem Deployment-Tool, 

im EJB-Container installiert. Das Installationswerkzeug schlug nach Auswahl der vom EJB- 

Container persistent zu verwaltenden Entity-Bean Attribute eine passende Tabellenstruktur 

vor. Dabei wurden nicht primitive Java-Typen auf binäre SQL-Typen abgebildet. In der Beispielanwendung 

muß ein Entity-Bean Attribut vom Typ ElementaryWork auf einen passenden 

SQL-Typ abgebildet werden. 

Zum Test der Lauffähigkeit der EJB-Komponente wurde ein Java-Programm geschrieben, 

welches die Komponenten im EJB-Container lokalisiert und anschließend die Geschäftsme-


 

 

 

EJB der Beispielanwendung 

EJB-WorkBean 

 

 

Die EntityBean WorkBean 

WorkBean 

WorkBean 

WorkHome 

Work 

WorkBean 

Container 

java.lang.String 

False 

 

Das zugeordnete ElementaryWork-Objekt 

work 

 

 

Die Themengruppe 

title 

 

title 

 

db 

javax.sql.DataSource 

Container 

 

 

 

 

 

 

WorkBean 

* 

 

Required 

 

 

 

Abbildung 6.7: Deployment-Deskriptor der Beispielanwendung


import java.util.*; 

public class CompDir { 

private static Vector mappedComponents = new Vector(); 

public CompDir() {} 

public static void add(String subject, String title, String content) { 

mappedComponents.add(new Mapper(subject,title,content)); 

} 

public static Vector getAllElemWorksRefBySubj(String subj) { 

Vector v = new Vector(); 

Enumeration iter = mappedComponents.elements(); 

while (iter.hasMoreElements()) { 

Mapper map = (Mapper)iter.nextElement(); 

if (map.getSubjectHeading().equals(subj)) 

v.add(map.getElementaryWork()); 

} 

return v; 

} 

public static void printAllEntries() { 

... 

} 

public static int size() { 

... 

} 

} // CompDir 

class Mapper { 

private String subjectHeading; 

private String elementaryWork; 

private String content; 

public Mapper(String subject, String elWork, String content) { 

this.subjectHeading = subject; 

this.elementaryWork = elWork; 

this.content = content; 

} 

public String getSubjectHeading() {return subjectHeading;} 

public void setSubjectHeading(String v) {this.subjectHeading = v;} 

public String getElementaryWork() {return elementaryWork;} 

public void setElementaryWork(String v) {this.elementaryWork = v;} 

public String getContent() {return content;} 

public void setContent(String v) {this.content = v;} 

}//Mapper 

Abbildung 6.8: Zentrale Verzeichnis-Klasse


thoden aufruft. Ein Ausschnitt des Java-Programms ist in Abbildung 6.9 dargestellt. 

Als nächter Schritt muß die Beispielanwendung in den verschiedenen Application-Servern 

installiert werden. Auf der Grundlage festgelegter Kriterien werden die Ergebnisse miteinander 

verglichen. 

In diesem Kapitel wurde bisher eine Beispielanwendung auf Basis von EJB-Komponenten, 

eine Java-Anwendung zum Testen der EJB-Komponenten sowie die Testumgebung, in der 

die Anwendung entwickelt und getestet werden soll, vorgestellt. In dem nun folgenden Abschnitt 

werden die Vergleichs-Kriterien vorgestellt. 

6.3 Vorstellung der Vergleichskriterien 

In den vorigen Abschnitten dieses Kapitels wurde eine EJB-Beispielanwendung vorgestellt 

und beschrieben. In diesem Abschnitt werden Kriterien vorgestellt, anhand derer ein Vergleich 

zwischen den verschiedenen Application-Servern durchgeführt wird. 

Installierbarkeit der EJB-Komponenten 

Bei diesem Kriterium wird geprüft, ob die EJB-Komponenten ohne Modifikation auf allen 

untersuchten Application-Servern installierbar sind. Das schließt auch die Behandlung des 

Deployment-Deskriptors mit ein. 

Struktur der vom EJB-Container erzeugten Tabelle 

Falls der EJB-Server die automatische Generierung von Tabellenstrukturen für die EJBs 

anbietet, wird die generierte Tabellenstruktur untersucht. 

Wichtig im Zusammenhang mit komplexen Attribut-Typen von Entity-Beans, die persistent 

gespeichert werden müssen, ist die vom Container erzeugte Tabellenstruktur. Hierbei ist die 

Abbildung zwischen nicht primitiven Java Datentypen und den in der Datenbank angebotenen 

Datentypen besonders wichtig. 

Art und Umfang notwendiger Modifizierungen 

Im Falle von notwendigen Modifizierungen an der Beispielanwendung, wird geprüft welche 

Art von Änderungen durchgeführt werden müssen. Zusätzlich wird geprüft, wie Umfangreich 

die Änderungen sind. 

Lauffähigkeit der EJB-Komponenten 

Hierbei werden mit Hilfe einer Java Konsolen-Anwendung die einzelnen Komponenten


import java.util.*; 

import javax.naming.Context; 

import javax.naming.InitialContext; 

import javax.rmi.PortableRemoteObject; 

public class ElemWorkClient { 

public static void main(String[] args) { 

WorkHome elworkHome = null; 

Work elemwork = null; 

try { 

Context initial = new InitialContext(); 

Object objref = initial.lookup("dipl2009"); 

elworkHome = (WorkHome)PortableRemoteObject.narrow(objref, 

WorkHome.class); 

... 

ElementaryWork elwork = new ElementaryWork("ElWork1", 

new SubjectHeading("subject1"), 

new Content("content1")); 

ElementaryWork elwork2 = new ElementaryWork(elwork,"ElWork2", 



CompDir.printAllEntries(); 

ElementaryWork finalWrk = new ElementaryWork("FinalElWork"); 

ElementaryWork f1 = finalWrk; 

ElementaryWork fnl = f1; 

String startTxt = "FinalElWork"; 

long start = 0, stop = 0; 

start = System.currentTimeMillis(); 

for (int i=0;i


der EJB Anwendung getestet. Es werden mehrere Tests der Komponenten durchgeführt, unter 

anderem wird das Erstellen und Entfernen von WorkBean-Objekten, das Erstellen von 

komplexen ElementaryWork-Objekten im EJB-Container sowie auf Client-Seite getestet. 

Umsetzung des Rollenkonzepts 

Bei diesem Kriterium wird bei jedem hier betrachteten Application-Server geprüft, inwieweit 

das durch die EJB-Spezifikation [Matena, Hapner 99] eingeführte Rollenkonzept 

umgesetzt wurde. 

In den folgenden Unterabschnitten werden die verschiedenen Application-Server anhand 

der hier aufgeführten Kriterien miteinander verglichen. 

6.4 BEA WebLogic Application-Server 

Beim BEA WebLogic Application-Server handelt es sich um ein Produkt der Firma [BEA b]. 

Der Bea Application-Server in der Version 5.1 ist überwiegend kommandozeilenorientiert, 

d.h. viele Funktionen zum Installieren, Überwachen und Kompilieren von EJB-Komponenten 

sind nur mit Hilfe von Befehlen auf der Kommandozeile durchzuführen. Es existiert zwar 

ein graphisches Überwachungswerkzeug für den Application-Server. Mit Hilfe dieser sog. 

Konsole können einige Parameter des Application-Servers verändert werden. 

Zusätzlich gibt es die Möglichkeit, über HTML einige Parameter des Application-Servers zu 

konfigurieren. 

Für die Installation von EJB-Komponenten im Container gibt es eine einfache Java-Anwendung 

mit graphischer Oberfläche. 

Für die Entwicklung von EJB-Komponenten liefert BEA keine eigene Java Entwicklungsumgebung, 

sondern bietet sog. Plug-Ins für existierende Java Entwicklungsumgebungen an. 

Die Kommunikation zwischen Clients und den EJB-Komponenten findet bei BEA hauptsächlich 

mit Hilfe des BEA-eigenen t3-Protokolles statt. 

6.4.1 Installation der EJB-Beispielanwendung 

Die Werkzeuge für die Generierung der Anwendungslogik des Objekt-Relationalen Mappings 

waren auf Anhieb nicht in der Lage, das ElementaryWork-Objekt auf einen passenden 

Datentyp in der Datenbank abzubilden. Dieser Fehler wird nicht bei der Generierung 

der notwendigen SQL-Anweisungen erkannt, sondern erst zur Laufzeit. Die Fehlermeldung 

lautet in diesem Fall Ungültiger Spaltentyp. Die Referenzimplementierung von [Sun ] hatte 

mit diesem komplexen Java-Typ keine Schwierigkeiten. Das Installationswerkzeug der Referenzimplementierung 

wählte als passenden Datentyp in der Datenbank einen Binär-Typ. 

Das Installationswerkzeug des BEA Application-Servers bietet auch keine Möglichkeit, die 

Tabellenstruktur automatisch generieren zu lassen. So muß die Tabellenstruktur vor der Installation 

der EJB-Komponenten bekannt und vorhanden sein. Erst danach kann der Installierer 

der EJB-Komponente, was in der EJB-Spezifikation der Rolle des Deployers entspricht,


die Installation der Komponenten durchführen. Dabei muß der Installierer eine Zuordnung 

zwischen den Spaltennamen und den persistent zu speichernden EJB-Attributen vornehmen. 

6.4.2 Test der EJB-Komponente 

Die Lauffähigkeit der EJB-Komponenten wird anhand einer Java-Anwendung überprüft. Da 

nicht erkennbar war, welcher Datentyp in der Datenbank bei der Abbildung des ElementaryWork-Attributes 

vom Installationswerkzeug gewählt wurde, konnte der Test zunächst 

nicht durchgeführt werden. 

Um den Test dennoch in geringerem Umfang durchführen zu können, mußte das betroffene 

Attribut der Entity Bean als „nicht vom EJB-Container zu verwaltendes Feld“ deklariert 

werden. Nach dieser Änderung lief der Test problemlos, da vom EJB-Container nur primitive 

Java-Typen auf die Datenbank abgebildet werden mußten. 

Wichtig in diesem Zusammenhang ist jedoch, daß keine Änderungen an der Bean durchgeführt 

wurden, sondern mit Hilfe der Werkzeuge des EJB-Containers lediglich der Deployment-Deskriptor 

modifiziert wurde. 

6.4.3 Umsetzung des EJB-Rollenkonzepts 

Das Rollenkonzept wird bei [BEA b] für jede Rolle eingeführt. Die Rolle des System-Administrators, 

Application-Assemblers des Deployers (Installierer) sowie des Bean-Entwicklers 

ist klar erkennbar. 

Ein Grund für das Fehlen von Funktionen zum Hinzufügen und Entfernen von EJB-Komponenten 

in der Konsole ist die Einhaltung des Rollenkonzeptes. Dies verhindert Überschneidungen 

in den Aufgabenbereichen zwischen der Rolle des System-Administrators und der 

Rolle des Installierers. 

So ist es dem Installierer möglich mit Hilfe vo Installationswerkzeugen des EJB-Containers 

EJB-Komponenten zu installieren oder zu entfernen, ohne das selbe Werkzeug des System- 

Administrators zu benutzen. Da zu den Aufgaben der System-Administratoren auch die 

Administration des EJB-Servers und EJB-Containers zählt, wären bei gemeinsamer Benutzung 

des Administrations-Werkzeugs Fehlbedienungen nicht ausgeschlossen. 

6.5 SilverStream Application-Server 

Der Silverstream Application-Server der Firma [Silverstream ] in der Version 3.7 besitzt 

zwei graphische Werkzeuge: die Manager-Konsole und den Designer, mit deren Hilfe der 

Application-Server konfiguriert werden kann und Anwendungen für den Application-Server 

entwickelt werden können. Der Designer stellt eine Applikation dar, in der mehrere Funktionen 

vereint sind: Entwicklungsumgebung, Oberflächengestaltung (GUI-Erstellung) sowie 

Installationswerkzeug für die EJB-Komponenten.


Die Manager-Konsole integriert zahlreiche Funktionen zum Starten, Beenden und Konfigurieren 

des Application-Servers. 

Im Designer sind mehrere Formular-Designer vorhanden, mit denen HTML- sowie Javabasierte 

Clients für die EJBs auf Basis eines silverstreameigenen Rahmenwerkes erstellt werden 

können. 

Im SilverStream Application-Server ist ein EJB-Installations-Assistent für verschiedene Java- 

Entwicklungsumgebungen vorhanden, wie z.B. Borland JBuilder und Visual Cafe. Mit dessen 

Hilfe ist der Bean-Entwickler in der Lage, aus einer vom Application-Server unterstützten 

Entwicklungsumgebung EJB-Komponenten in den Application-Server, genauer gesagt 

im EJB-Container, zu installieren. 

Im SilverStream Application-Server ist eine Java Entwicklungsumgebung integriert, so daß 

eine Anwendungsentwicklung nur mit Hilfe der Management-Konsole sowie des Designers 

möglich ist. 

Beim SilverStream Application-Server müssen die EJB-Komponenten sowie der Deployment- 

Deskriptor immer zuerst in einem Repository des Application-Servers installiert werden. Dieses 

Repository wird in einer Datenbank abgelegt. Anschliessend muß mit mehreren Assistenten, 

wie z.B. Jar-, EJB-Jar, Tabellen-, Formular- oder Deployment-Assistent die EJB- 

Komponente im EJB-Container installiert werden. 


Der erste Versuch, die EJB-Komponenten der Beispielanwendung in dem Application-Server 

zu installieren, schlug fehl, weil beim SilverStream Application-Server alle EJB-Komponenten 

in einem Java-Package abgelegt sein müssen. Dies hatte zur Folge, dass der Programmcode 

der EJB-Komponenten geändert werden mußte. Diese Einschränkung ist auch nicht in der 

EJB-Spezifikation aufgeführt. 

Es ist allerdings in der Programmiersprache Java gängige Praxis, zusammengehörige Klassen 

in einem gemeinsamen Package abzulegen. Daher sollte die Änderung der EJB-Komponenten 

in diesem Fall vernachlässigt werden. 

Die Klassen der Beispielanwendung wurden anschliessend in einem Java-Package abgelegt 

und erfolgreich in dem EJB-Container installiert. 

6.5.2 Test der EJB-Komponenten 

Die im SilverStream Application-Server installierten EJB-Komponenten wurden durch eine 

Java-Anwendung auf ihre Lauffähigkeit getestet. Die EJB-Komponenten konnten im EJB- 

Container lokalisiert und verwendet werden.



Beim SilverStream Application-Server sind zwei große Rollen erkennbar: die Rolle des Bean- 

Entwicklers und die Rolle des Administrators. 

Diese Rollenunterteilung wird auch in den zur Verfügung stehenden Werkzeugen deutlich: 

die Manager-Konsole sowie der Designer. In der Manager-Konsole sind die Funktionen 

zum Konfigurieren sowie Starten und Herunterfahren des Application-Servers enthalten. 

Die Manager-Konsole ist ein typisches Werkzeug für die Rolle des System-Administrators. 

Der Designer ist ein Werkzeug, in dem zahlreiche weitere Werkzeuge zusammengefasst 

sind, wie z.B. Formular-Assistent, Jar-Assistent oder Tabellen-Assistent. Jedes dieser Werkzeuge 

ist graphisch aufwendig gestaltet und bietet einen hohen Bedienkomfort. Das von der 

EJB-Spezifikation eingeführte Rollenkonzept für die bessere Aufteilung von Zuständigkeiten 

und einfachere Entwicklung von EJB-Komponenten wird hierdurch jedoch nicht eingehalten. 

So sind im Designer die Rolle des Application-Assemblers, Installierers und des Bean-Entwicklers 

vereint. 

Für die schnelle Anwendungsentwicklung ist diese Zusammenfassung von mehreren Rollen 

vorteilhaft, für die Administration jedoch nachteilig. Speziell der Übergang einer Anwendung 

aus der Testumgebung in die Produktionsumgebung wird durch fehlende Rollenverteilung 

erschwert. 

6.6 Borland Application-Server 

Der Borland Application-Server der Firma [Borland ] in der Version 4.1 ist ebenfalls wie der 

SilverStream Application-Server graphisch-orientiert. Es existiert eine Management-Konsole 

mit zahlreichen integrierten Funktionen. 

In dieser Management-Konsole sind Funktionen zum Starten, Herunterfahren Konfigurieren 

des Application-Servers sowie Funktionen zum Installieren und Entfernen von EJB- 

Komponenten vorhanden. 

Der Borland Application-Server besitzt keine integrierte Java Entwicklungsumgebung wie 

der SilverStream Application-Server, da Borland eine eigenständige Java Entwicklungsumgebung 

besitzt, und zwar den Borland JBuilder. Diese Entwicklungsumgebung besitzt Funktionen 

zum Installieren, Testen und Entwickeln von EJB-Komponenten. 

Seit der Version 4.5 ist dieses Produkt J2EE zertifiziert. Es besitzt als integrierten ORB (Object 

Request Broker) den ebenfalls von Borland entwickelten VisiBroker, der in der Praxis 

seit längerem eingesetzt wird.



Das Installieren von Komponenten in den Borland Application-Server kann entweder mit 

Hilfe der Management-Konsole oder aber aus einer Java Entwicklungsumgebung, z.B. JBuilder, 

durchgeführt werden. Die Management-Konsole bietet zahlreiche Hilfsfunktionen, wie 

z.B. die automatische Generierung des herstellerabhängigen Deployment-Deskriptors für 

den Borland Application-Server. Dieser Schritt ist nötig, weil jeder Hersteller seine eigenen, 

herstellerspezifischen Einstellungen in einem zweiten Deployment-Deskriptor ablegt. 

Aufgrund dieser Tatsache wird beim Versuch, eine EJB-Komponente eines anderen Herstellers 

zu installieren, ein Fehler angezeigt. Anschliessend muß der Deployment-Deskriptor 

einmal mit dem ebenfalls im Borland Application-Server integrierten Deployment-Deskriptor 

Editor geöffnet und ohne Modifikation wieder abgespeichert werden, damit die borlandspezifischen 

XML-Informationen in den Deployment-Deskriptor abgelegt werden. Erst nach 

diesem Schritt können die Komponenten in den EJB-Server installiert werden. 

Die Installation verlief ohne Probleme. Die Objekt-Relationale Abbildung zwischen den vom 

EJB-Container persistent zu speichernden Attributen in der Entity-Bean und der Datenbank 

verlief ebenfalls ohne Probleme. 

Die Tabellen für die Entity-Beans müssen manuell erstellt werden. Der Bean-Installierer muß 

den Namen der Tabelle angeben sowie eine Zuordnung der vom EJB-Container persistent 

zu speichernden Attribute und den Tabellenattributen vornehmen. 

Für das in der Beispielanwendung existierende Entity-Bean Attribut vom Typ Elementary- 

Work wurde in der Tabellendefinition ein binärer Datentyp in der Datenbank ausgewählt. 

6.6.2 Test der EJB-Komponente 

Für den Test der EJB-Komponenten wird eine einfache Client-Anwendung verwendet. Diese 

benötigt ein Jar-Archiv, in dem sich das Home- und das Remote-Interface befinden. Zusätzlich 

werden mit Hilfe von EJB-Server-Tools Client- und Server-Stubs generiert, mit Hilfe 

derer der Client mit dem EJB-Server kommuniziert. 

Die Client-Anwendung ruft bei einer Kommunikation zunächst eine Methode des Home- 

Interfaces auf, um ein Exemplar einer Bean zu erzeugen. 

Mit Hilfe dieser Java-Anwendung konnten die Beans in dem EJB-Container lokalisiert und 

verwendet werden. 

Der Test der EJB-Komponenten verlief ohne Probleme. Die EJB-Komponenten konnten lokalisiert 

und verwendet werden. 


Das Rollenkonzept wird beim Borland Application-Server, ähnlich wie beim SilverStream 

Application-Server, nur teilweise umgesetzt. So sind in der Manager-Konsole mehrere Rollen 

wiederzufinden: die Rolle des System-Administrators, die Rolle des Bean-Entwicklers 

sowie die Rolle des Installierers und des Application-Assemblers. 

Fast alle Rollen sind in diesem einzigen Werkzeug zusammengefasst.


6.7 Auswertung der Vergleichskriterien 

Die in diesem Kapitel betrachteten Application-Server stellen einen kleinen Ausschnitt aus 

den verfügbaren EJB Application-Servern dar. Obwohl alle Hersteller die Spezifikation einhalten, 

gibt es Bereiche, in denen sie einen bestimmten Freiraum haben, die Anforderungen 

der Spezifikation umzusetzen. 

Genau an diesen Stellen sind die Hauptunterschiede zwischen den verschiedenen Herstellern 

zu sehen. 

Die Einführung einer Pakethierarchie, die vom SilverStream Application-Server verlangt 

wird, kann einen großen Aufwand bei der nachträglichen Einführung einer Pakethierarchie 

bedeuten, wenn zahlreiche Klassen vorhanden sind. 

In der Programmierpraxis werden Pakethierarchien jedoch sehr häufig eingesetzt. 

Trotz der EJB-Spezifikation gibt es immer wieder Hindernisse bei der Portabiliät von EJB- 

Komponenten. Als Konsequenz wird man sich für einen Hersteller entscheiden und Kompromisse 

bei der Portabilität eingehen müssen. 

In der Tabelle 6.1 ist die Auswertung der Vergleichskriterien nochmal tabellarisch aufgeführt. 

In der Abbildung sind die einzelnen Kriterien sowie der jeweilige Erfüllungsgrad der 

betrachteten Application-Server aufgeführt. Mit „SUN RI J2EE 1.2.1“ in Tabelle 6.1 ist die 

J2EE-Referenzimplementierung von [Sun ] gemeint. 

Vergleichskriterium SUN RI J2EE 1.2.1 BEA 5.1 SilverStream 3.7 Borland 4.1 

Installierbarkeit ja ja ja ja 

der EJB-Komponenten 

Automatische ja nein nein nein 

Tabellengenerierung 

durch Container 

Umfang notwendiger keine gering gering keine 

Modifizierungen 

Lauffähigkeit der ja ja ja ja 

EJB-Komponenten 

Umsetzungsgrad des mittel hoch niedrig niedrig 

EJB-Rollenkonzepts 

Tabelle 6.1: Auswertung der Vergleichskriterien 

In diesem Kapitel wurde eine Beispielanwendung vorgestellt und in eine auf EJB-Komponenten 

basierte Anwendung überführt. Anschliessend ist diese Beispielanwendung in verschiedenen 

EJB-Servern installiert worden. In den folgendem Kapitel werden nun die Probleme 

beschrieben, die bei der Abbildung eines Objekt-Modells auf ein EJB-Modell entstehen 

können.

Kapitel 7 

Abbildung eines Objekt-Modells auf 

ein EJB-Modell 

In diesem Kapitel werden die Probleme aufgeführt, die bei der Abbildung eines objektorientierten 

Modells auf EJB-Komponenten entstehen können. Es werden dabei zwei mögliche 

Lösungen vorgestellt und miteinander verglichen. 

In Abschnitt 7.1 werden zunächst die generellen Probleme aufgeführt, die bei der Abbildung 

eines objektorientierten Modells auf EJB-Komponenten entstehen können. Abschnitt 

7.2 beschreibt die auf künstlichen Primärschlüssel basierende Lösung, während Abschnitt 

7.3 die auf Java-Objektidentität basierende Lösung beschreibt. In Abschnitt 7.4 werden zum 

Abschluß dieses Kapitels die in vorgestellten Lösungsansätze miteinander verglichen. 

In diesem Kapitel meint der Begriff „EJB-Anwendung“ immer Java-Anwendungen, die Entity-Beans 

als EJB-Komponenten einsetzen. Der Begriff Abbildung bezeichnet alle notwendigen 

Schritte zur Implementierung einer auf EJB-Komponenten basierenden Java-Anwendung 

ausgehend von einem objektorientierten Modell. 

7.1 Generelle Abbildungsprobleme 

Bei der direkten Abbildung eines Objektmodells auf ein EJB-Modell entstehen i.A. zahlreiche 

Entity-Beans. Jede Entity-Bean besteht aus dem Home- und Remote-interface sowie aus 

dem Primärschlüssel. Für die Verwaltung dieser Bestandteile einer Entity-Bean ist der EJB- 

Container zuständig, was bei zahlreichen Entity-Beans zu Laufzeitproblemen führen kann. 

Die Anwendungen werden „relational gedacht“, da zum Erzeugen und Auffinden von Entity-Beans 

die Primärschlüssel verwendet werden müssen. Auch das Setzen von Beziehungen 

zwischen Entity-Beans geschieht mit Hilfe der Primärschlüssel. Die EJB-Anwendungen 

erscheinen letztendlich als eine „objektorientierte Verpackung“ von relationalen Datenbankstrukturen. 

Das folgende Beispiel verdeutlicht diese Sichtweise: 

... 

Cabin cabin1 = home.create(1); 

cabin1.setName("Master Suite"); 

61

KAPITEL 7. ABBILDUNG EINES OBJEKT-MODELLS AUF EIN EJB-MODELL 62 

cabin1.setDeckLevel(1); 

cabin1.setBedCount(3); 

//Setzen der Beziehungen zwischen Cabin und Ship 

Ship ship = shipHome.create(1); 

cabin1.setShip(1); 

CabinPK pk = new CabinPK(); 

pk.id = 1; 

Cabin cabin2 = home.findByPrimaryKey(pk); 

... 

Es wird eine Entity-Bean vom Typ Cabin angelegt, die anhand einer Nummer identifiziert 

wird. Ebenfalls aus dem Beispiel ersichtlich ist der Einsatz von Fremdschlüsseln in der EJB- 

Anwendung. Durch die Anweisung cabin1.setShip(1) wird über eine assoziative Identifikation 

(vergl. [Schmidt, Matthes 98]) mit Hilfe des Fremdschlüssels eine Beziehung zu 

einem Objekt vom Typ Ship mit dem Primärschlüsselwert 1 hergestellt. 

In objektorientierten Anwendungen werden Beziehungen zwischen Objekten durch direkte 

Referenzen ausgedrückt. In dem folgenden Beispiel ist das eben gezeigte EJB-Beispiel in 

objektorientiertem Programmierstil dargestellt: 

... 

Cabin cabin1 = new Cabin(); 

cabin1.setName("Master Suite"); 




Ship ship = new Ship("Traumschiff"); 

cabin1.setShip(ship); 

... 

Wie aus diesem direkten Vergleich ersichtlich ist, unterscheiden sich EJB-Anwendungen 

von „normalen“ Java-Anwendungen in der Referenzierung von EJB-Komponenten. In EJB- 

Anwendungen werden Entity-Beans immer über einen Primärschlüssel referenziert. Im Falle 

eines komplexen Primärschlüssels, der sich z.B. aus mehreren Attributen der Entity-Bean 

zusammensetzt, wird eine separate PrimaryKey Klasse benötigt (vergl. Kapitel 4). 

In der Beispielanwendung aus Kapitel 6 wurde versucht, die Modifikationen an der Anwendung 

so gering wie möglich zu halten, um eine EJB-Anwendung zu erhalten. Daher wurde 

die Entity-Bean WorkBean so entworfen, daß alle relevanten Geschäftsmethoden der Klasse 

ElementaryWork auch in der Entity-Bean angeboten werden. 

Die Entity-Bean hat dann neben der automatischen persistenten Speicherung die Aufgabe 

einer Schnittstelle für die ElementaryWork-Klasse. Die Entity-Bean delegiert alle Aufrufe 

der Geschäftsmethoden weiter an ein ihr zugeordnetes ElementaryWork-Objekt. 

In [Alur et al. 01] wird betont, daß es nicht sinvoll ist, jedes persistent zu speichernde Objekt 

einer Anwendung als Entity-Bean zu realisieren, da dies i.A. zu Lasten der Performanz der 

Anwendung geht. Viel wichtiger sei die Entscheidung, ob feingranulare oder grobgranulare 

Entity-Beans eingesetzt werden sollten.


Feingranulare EJB-Komponenten enthalten für jedes Attribut jeweils eine Methode zum 

Auslesen (engl. accessor) und eine Methode zur Manipulation (engl. mutator). Dies hat zur 

Folge, daß mehrere Methodenaufrufe notwendig sind, um den Zustand aller Attribute Auszulesen. 

Das gleiche gilt für die Manipulation von Attributen. 

Grobgranulare EJB-Komponenten fassen i.A. logisch zusammengehörige Attribute zu größeren 

Strukturen zusammen. Dies geschieht meistens mit Hilfe von abhängigen Objekten 

(engl. dependent objects). 

Bei der direkten Abbildung eines objektorientierten Modells auf ein EJB-Modell entstehen 

häufig feingranulare EJB-Komponenten. 

Ein weiteres Problem bei feingranularen Entity-Beans entsteht durch die Beziehungen zwischen 

den Entity-Beans. Da Referenzen zwischen Entity-Beans mit Hilfe der Home- oder 

Remote-Interfaces bzw. der Primärschlüssel aufgebaut werden, müssen die Referenzen auf 

andere EJB-Komponenten einer Entity-Bean geändert werden, sobald sich an den referenzierten 

EJB-Komponenten etwas ändert. Ein Beispiel für eine Änderung wäre z.B. das Löschen 

einer Entity-Bean. Auch müssen diese Beziehungen i.A. dynamisch mit Hilfe der 

Home- oder Remote-Interfaces bzw. den Primärschlüsseln neu aufgebaut werden. 

Dies bedeutet eine Zunahme der Komplexität des Programmcodes in den Entity-Beans aufgrund 

der zusätzlichen Pflege von Referenzen. Die Ursache hierfür liegt in der Tatsache, daß 

die Gültigkeit der Referenzen zwischen Entity-Beans nicht garantiert werden kann (vergl. 

[Alur et al. 01]). 

Ein weiteres Problem mit feingranularen Entity-Beans ist ihre Abhängigkeit vom Datenbankschema, 

da feingranulare Entity-Beans i.A. eine Zeile in einer Datenbanktabelle repräsentieren. 

Dies bedeutet wiederum, daß feingranulare Entity-Beans eine direkte Repräsentation 

des Datenbankschemas darstellen. Jede Schemaänderung hat auch eine Änderung der 

feingranularen Entity-Bean zur Folge, was wiederum auch Änderungen an den Programmen 

bedeutet, die diese Entity-Beans verwenden. Der Aufrufer der Bean und die Bean selber 

befinden sich auf der selben Granularitätsstufe. Es existiert also eine enge Abhängigkeit 

zwischen feingranularen EJB-Komponenten, dem Datenbankschema sowie den Anwendungen, 

die die EJB-Komponenten verwenden. 

Bei der Wahl der passenden feingranularen oder grobgranularen Entity-Bean sollte das Transaktionale 

Verhalten der EJB-Komponente ebenfalls berücksichtigt werden. Ein Benutzer einer 

Entity-Bean hat nur für die Dauer eines Methodenaufrufs exklusiven Zugriff auf die 

Bean. Alle anderen Benutzer müssen solange warten, bis der Aufruf beendet ist. Diese Aufruf 

kann in einem Transaktionskontext ablaufen. Wenn zu viel Logik in einer Methode implementiert 

wird, so kann dies zu langen Antwortzeiten bzw. Wartezeiten für die anderen 

Benutzer führen. 

Wie in [Holland 01] beschrieben, ist in der EJB-Spezifikation 1.1 (vergl. [Matena, Hapner 99]) 

keine Unterstützung für Beziehungen zwischen Entity-Beans vorhanden. Weiterhin wird beschrieben, 

daß der Zustand aller Attribute einer Entity-Bean, die nicht vom EJB-Container 

persistent gespeichert werden sollen, sich jederzeit ändern kann. 

Die Ursache hierfür liegt in den Lebenszyklen der Beans sowie in der Funktion der Entity- 

Beans: die Repräsentation von persistent gespeicherten Daten. 

Eine Bean kann sich, wie in [Matena, Hapner 99] und [DeMichiel et al. 00] beschrieben, 

in verschiedenen Zuständen befinden. Bei dem Wechsel von dem Zustand „Ready“ in den


Zustand „Pooled“, was einer Passivierung der Bean entspricht, und umgekehrt, was einer 

Aktivierung der Bean entspricht, können Attribute, die nicht persistent gespeichert werden 

sollen, ihren Zustand verlieren. 

In [Holland 01] wird ein Verfahren vorgestellt, mit dem man komplexe Beziehungen zwischen 

Entity-Beans realisieren kann. Das Verfahren beruht im wesentlichen auf die sog. 

callback-Methoden der EJB-Komponenten, die der Container bei bestimmten Zustandsänderungen 

der Bean aufruft. Auf die callback-Methoden wird hier nicht näher eingegangen. 

Eine ausführliche Behandlung findet sich z.B. in [Matena, Hapner 99], [Monson-Haefel 00] 

oder [Roman 99]. 

Das in [Holland 01] beschriebene Verfahren extrahiert mit Hilfe der Methode getPrimaryKey() 

des remote-Interfaces den jeweiligen Primärschlüssel und speichert diesen in ein 

vom EJB-Container persistent zu speicherndes Attribut. Da der EJB-Container selbst über 

dieses zusätzliche Feld keine weiteren Informationen besitzt, müs der Bean-Entwickler in 

bestimmten Callback-Methoden die Extrahierung des Primärschlüssels bzw. die Erzeugung 

einer Entity-Bean Referenz aus dem Primärschlüssel sowie die persistente Speicherung implementieren. 

Der Aufbau von komplexen Beziehungen zwischen Entity-Beans ist nicht so einfach wie 

beim Aufbau von Beziehungen zwischen „normalen“ Objekten (vergl. [Holland 01]). Die 

Ursache hierfür liegt darin, daß die persistent zu speichernden Attribute von Entity-Beans 

darauf ausgelegt sind, Daten zu halten, die einem Feld in einer relationalen Datenbank oder 

einem anderen persistenten Datenspeicher. In den meisten Fällen enthalten die persistenten 

Attribute der Entity-Beans Datentypen, die einen entsprechenden Typ in der Datenbank besitzen. 

Für den Typ „Objekt-Referenz“ gibt es in der Regel aber keinen passenden Typ in der Datenbank. 

Wie man anhand der in diesem Abschnitt beschriebenen Probleme sehen kann, sind mehrere 

Faktoren bei der Abbildung eines Objektmodells auf ein EJB-Modell zu berücksichtigen. 

Diese Tatsache erschwert die Entwicklung von EJB-Anwendungen, da zahlreiche Faktoren 

berücksichtigt werden müssen. 

7.2 EJB-Komponenten basierend auf künstlichen Primärschlüssel 

Da die EJB-Spezifikation für Entity-Beans einen Primärschlüssel bzw. eine Primärschlüsselklasse 

vorschreibt, entstehen hierdurch EJB-Anwendungen, die stark abhängig von Primärschlüsseln 

sind. Dieser Effekt wird durch den Aufbau von Beziehungen zwischen Entity- 

Beans noch verstärkt, da hier auch Fremdschlüssel betrachtet werden müssen. Hierdurch 

werden relationale Strukturen in die EJB-Anwendung integriert. Dies hat zur Folge, daß 

man in einer EJB-Anwendung nach zwei Paradigmen entwickelt, das objektorientierte Paradigma 

und das relationale Paradigma. 

Das folgende Beispiel zeigt, wie der Einsatz eines Primärschlüssels und Fremdschlüssels die 

Anwendung beeinflusst: 

... 

Cabin cabin1 = home.create(1); 

cabin1.setName("Master Suite");





Ship ship = shipHome.create(1); 

cabin1.setShip(1); 

CabinPK pk = new CabinPK(); 

pk.id = 1; 

Cabin cabin2 = home.findByPrimaryKey(pk); 

... 

Da die meisten verfügbaren Datenbanksysteme häufig Optimierungen für numerische oder 

alphanumerische Primärschlüssel besitzen, ist es sinnvoll einen numerischen oder alphanumerischen 

Datentyp für einen Primärschlüssel zu wählen. 

Dieses Verfahren wird in dem oben aufgeführten Beispiel angewendet, es wird ein numerischer 

Primärschlüssel (pk.id=1) verwendet. 

Das Remote-Interface einer Entity-Bean bietet u.a. die Methode getPrimaryKey() an. Mit 

Hilfe dieser Methode kann der Primärschlüsselwert der Entity-Bean ermittelt werden. Wenn 

mit Hilfe der Primärschlüssel Beziehungen zwischen Entity-Beans aufgebaut werden, entstehen 

zwangsläufig relational entwickelte EJB-Anwendungen, da z.B. Methoden geschrieben 

werden müssen, die nur numerische Werte der Primärschlüssel zurückgeben. Dies wird 

durch das folgende Beispiel verdeutlicht: 

public class ReservationBean implements javax.ejb.EntityBean { 

public int customerID; 

public int cruiseID; 

public int cabinID; 

public double price; 

public javax.ejb.EntityContext ejbContext; 

public ReservationPK ejbCreate(Customer customer, Cruise cruise, 

Cabin cabin, double price) { 

try { 

this.customerID = ((CustomerPK)customer.getPrimaryKey()).id; 

this.cruiseID = ((CruisePK)cruise.getPrimaryKey()).id; 

this.cabinID = ((CabinPK)cabin.getPrimaryKey()).id; 

this.price = price; 

} 

catch (RemoteException re) { 

throw new EJBException(re); 

} 

return null; 

} 

... 

public int getCabinID( ) {| 

return cabinID; 

} 

public int getCustomerID( ){


return customerID; 

} 

public int getCruiseID( ){ 

return cruiseID; 

} 

... 

7.3 EJB-Komponenten basierend auf Java-Objektidentität 

Die in Kapitel 6 beschriebene Beispielanwendung wurde aus EJB-Komponenten entworfen, 

die auf Java-Objektidentität basieren. Es wurde anstatt einen künstlichen Primärschlüssel 

einzuführen ein Attribut title der EJB-Komponente als Primärschlüssel ausgewählt. 

In der Beispielanwendung aus Kapitel 6 sind Beziehungen zwischen den Objekten der Klasse 

SubjectHeading, Content und ElementaryWork sowie zwischen Objekten der Klasse 

ElementaryWork vorhanden. Diese Beziehungen werden in der Beispielanwendung 

über die Java-Objektidentität festgehalten, wie in dem folgenden Ausschnitt der Klasse ElementaryWork 

zu sehen ist: 

public class ElementaryWork implements Serializable { 

private Vector elementaryWorkVector = null; 

private String title; 

private SubjectHeading subjectHeading; 

private Content content; 

private ElementaryWork parent = null; 

... 

public ElementaryWork(String title) { 

this.title = title; 

elementaryWorkVector = new Vector(); 

} 

public ElementaryWork(String title, SubjectHeading subjHead, 

Content cont) { 


this.subjectHeading = subjHead; 

this.content = cont; 

elementaryWorkVector = new Vector(); 

} 

} 

... 

CompDir.add(subjHead.getName(), title, cont.getURI()); 

Jedes ElementaryWork-Objekt besitzt durch die Attribute subjectHeading und content 

direkte Referenzen auf die Typen SubjectHeading bzw. Content. Die Grundlage


dieser Referenzen ist die Java-Objektidentität. 

Die persistente Speicherung der Objekte wird durch die Zuordnung eines ElementaryWork- 

Objektes zu der Entity-Bean WorkBean realisert, wobei das ElementaryWork-Objekt als 

Wurzel-Objekt fungiert. Dieses ElementaryWork-Objekt ist dabei ein Attribut der Entity- 

Bean und wird vom EJB-Container automatisch persistent gespeichert. Der folgende Ausschnitt 

aus der Klasse WorkBean macht dies deutlich: 

public class WorkBean implements EntityBean { 

public ElementaryWork work = null; 

/** 

* EJB-Attributes 

*/ 

private EntityContext context; 

public String title; 

} 

public String ejbCreate(String title) { 

work = new ElementaryWork(title); 


return null; 

} 

... 

Der Vorteil dieser Lösung liegt darin, daß die Anwendung in objektorientierter Weise entwickelt 

werden kann. Es findet keine „Beeinflussung“ durch relationale Strukturen wie z.B. 

Primärschlüssel statt. Es ist bei dieser Lösung möglich, Beziehungen zwischen Objekten des 

Typs ElementaryWork in objektorientierter Weise aufzubauen und zur persistenten Speicherung 

einer Entity-Bean zuzuordnen, wie das folgende Beispiel zeigt: 

... 

WorkHome elworkHome = null; 

Work elemwork = null; 

elworkHome = (WorkHome)PortableRemoteObject.narrow(objref, 

WorkHome.class); 

... 

ElementaryWork elwork1 = new ElementaryWork("ElWork1", 



ElementaryWork elwork2 = new ElementaryWork("ElWork2", 



elwork1.add(elwork2); 

elemwork = elworkHome.create("Themengruppe");


elemwork.add(elwork1); 

... 

Jeder Primärschlüssel ist eindeutig innerhalb eines EJB-Containers. Zwei wertgleiche Primärschlüssel 

zweier EJB-Container des selben Herstellers sind nicht untereinander austauschbar. 

Es ist z.B. nicht möglich, mit einem Primärschlüssel ContentPK mit dem Wert 1 eine 

Entity-Bean in einem zweiten EJB-Container über die Home-Interface Methode findBy- 

PrimaryKey zu instantiieren (vergl. [Monson-Haefel 00]). 

7.4 Vergleich der Lösungen 

In Abschnitt 7.3 wurde ein Beispiel aufgeführt, bei dem Referenzen zwischen Objekten mit 

Hilfe der Java-Objektidentität festgehalten wurden. Kennzeichnend für dieses Beispiel war, 

daß alle referenzierten Objekte „normale“ Java-Objekte waren, d.h. es handelte sich nicht 

um Enterprise JavaBeans Komponenten. 

Im Gegensatz dazu wurde in Abschnitt 7.2 ein Beispiel aufgeführt, daß Primärschlüssel einsetzt. 

Der Vorteil der auf Java-Objektidentität basierenden Lösung liegt darin, daß die objektorientierte 

Anwendungsentwicklung nicht durch relationale Strukturen beeinflusst wird. 

Ein weiterer positiver Aspekt ist, daß das Objektmodell fast ohne Modifikation in ein EJB- 

Modell überführt werden kann. Weiterhin wird die komplexe Behandlung von Beziehungen 

zwischen Entity-Beans mittels der Primärschlüssel vermieden. 

Es gibt jedoch auch einen Nachteil dieses Lösungsansatzes. Wenn ein Objektmodell ohne 

größere Modifikationen in ein EJB-Modell überführt wird, dann bedeutet dies, daß die auf 

Java-Objektidentität basierenden Objekte nur dann vom EJB-Container persistent gespeichert 

werden können, wenn sie als Attribute von Entity-Beans definiert werden. Eine vom 

EJB-Container automatisch verwaltete persistente Speicherung muß im EJB-Komponentenmodell 

immer über die Entity-Beans erfolgen. Daher muß in dem hier betrachteten Fall eine 

Entity-Bean als persistente Hülle oder als Dekorierer (vergl. decorator-pattern in [Gamma et al. 

95]) bzw. als Zustandsträger der persistenten Speicherung eingeführt werden. 

In einem solchen Fall entstehen grobgranulare Entity-Beans, die ein abhängiges Objekt als 

Attribut besitzen. Diese abhängigen Objekte können jedoch weitere komplexe Objekte aggregieren. 

Dieses Verfahren birgt den Nachteil, daß unter Umständen sehr viele Objekte 

an einer Entity-Bean hängen und auch nur über diese Entity-Bean erreichbar sind. In einer 

Umgebung, in der hunderte von Benutzern gleichzeitig diese Entity-Bean verwenden 

wollen, kann es zu Performanzproblemen kommen. Die Ursache hierfür liegt in der EJB- 

Spezifikation, in der parallele bzw. nebenläufige Zugriffe auf Entity-Beans nicht erlaubt werden 

(vergl. [Matena, Hapner 99] und [Monson-Haefel 00]). Es können mehrere Clients mit 

einem EJB-Objekt einer Entity-Bean verbunden sein, aber es kann zu jedem Zeitpunkt nur 

ein Client eine Geschäfts-Methode der Entity-Bean aufrufen. Für die Dauer eines Methodenaufrufs 

ist die Entity-Bean für andere Clients nicht verfügbar (vergl. [Monson-Haefel 00]). 

Bei dem in Abschnitt 7.2 aufgeführten Beispiel wurden Referenzen zwischen Entity-Beans 

mit Hilfe von Primärschlüsseln festgehalten. Da in [Matena, Hapner 99] die Behandlung 

von Beziehungen zwischen Entity-Beans nicht betrachtet werden, ist der Bean-Entwickler


für diesen Bereich selbst verantwortlich, d.h. der EJB-Container stellt keinerlei automatischen 

Dienste für die Verwaltung von Beziehungen zwischen Entity-Beans zur Verfügung. 

Um dennoch die vom EJB-Container angebotenen Dienste bezüglich der automatischen persistenten 

Speicherung in Anspruch nehmen zu können, muß der Bean-Entwickler wie in 

[Holland 01] beschrieben mit Hilfe der Callback-Methoden die Beziehungen zwischen den 

Entity-Beans selbst verwalten. 

Dieser Ansatz beruht jedoch auf den Einsatz von Primärschlüsseln, die in gewisser Weise 

die Anwendungsentwicklung nach objektorientierten Verfahren behindern.

Kapitel 8 

Zusammenfassung und Ausblick 

8.1 Zusammenfassung 

Die in dieser Arbeit betrachteten EJB-Komponenten einer Beispielanwendung ließen sich 

ohne Modifikation an den EJB-Komponenten auf allen behandelten Application-Servern installieren. 

Auch die Lauffähigkeit war auf allen betrachteten Application-Servern gegeben. 

Die Beispielanwendung wurde ausgehend von einem objektorientierten Modell entwickelt. 

Bei der anschliessenden „Abbildung“ auf eine EJB-Anwendung gab es eine Schwierigkeit 

zu überwinden: die Abbildung der Objektidentität auf einen Primärschlüssel. Das Problem 

ergibt sich aufgrund der assoziativen Identifikation bei relationalen Datenbanksystemen und 

der referentiellen Identifikation (vergl. [Schmidt, Matthes 98]) bei objektorientierten Systemen. 

Da man bei Entity-Beans den Primärschlüssel verwenden muß, entsteht eine relational gedachte 

Anwendung. Die Begriffe aus der relationalen Welt wie Primärschlüssel oder Fremdschlüssel 

werden in die objektorientierte Anwendung „hineingetragen“. Dies erschwert die 

Anwendungsentwicklung in objektorientierter Weise. 

Die Wahl des EJB-Servers kann entscheidend für den Erfolg oder Mißerfolg des EJB-Einsatzes 

sein. Wenn man sich mit den Werkzeugen eines EJB-Servers auskennt, bedeutet dies noch 

lange nicht, daß man mit den Werkzeugen anderer EJB-Server ebenso gut zurechtkommt. 

Als Beispiel lassen sich BEA aufführen, bei dem die Werkzeuge überwiegend kommandozeilenorientiert 

sind und SilverStream, bei dem die Werkzeuge fast ausschließlich graphischorientiert 

sind. 

Erschwerend kommt noch hinzu, daß sich zwischen zwei Releases eines Herstellers die Bedienung 

des EJB-Server verändert. So z.B. beim Releasewechsel von 5.1 auf 6 bei Bea. In der 

Version 5 gibt es die Möglichkeit EJB-Komponenten mit Hilfe einer grafischen Oberfläche 

zu installieren. In der Version 6 gibt es eine HTML-Schnittstelle, über die EJB-Komponenten 

auf dem EJB-Server installiert werden müssen. 

Dieses Beispiel zeigt, daß es schwierig sein kann, selbst bei einem Produkt eines Herstellers 

auf dem Laufenden zu bleiben. 

70

KAPITEL 8. ZUSAMMENFASSUNG UND AUSBLICK 71 

Wie in Kapitel 6 bereits beschrieben, wird das Rollenkonzept der EJB-Spezifikation bei den 

Herstellern unterschiedlich behandelt. Einige Hersteller legen mehr andere wiederum weniger 

Wert auf die Umsetzung der einzelnen Rollen in dem Application-Server. Erschwehrend 

kommt hinzu, daß die Umsetzung der Rollenkonzepte zwischen Versionssprüngen eines 

Application-Servers unterschiedlich sein können. 

Obwohl alle Hersteller ihre Produkte auf Basis der EJB-Spezifikation aufbauen, gibt es z.T. 

erhebliche Unterschiede in Konfiguration, Installation sowie Art und Umfang der Werkzeuge. 

8.2 Ausblick 

In der heutigen Softwareentwicklung unterliegt die Software einem sehr schnellen Alterungsprozeß. 

Innerhalb eines Jahres werden in manchen Fällen mehrere Versionen einer 

Software entwickelt und herausgegeben. So sind auch die Application-Server hiervon betroffen. 

Zum Ende dieser Arbeit ist z.B. bereits die Version 7 des BEA Application-Server 

fertiggestellt, die zu Beginn der Arbeit in der Version 5.1 vorlag. 

Auch die Spezifikation des EJB-Komponentenmodells wird von [Sun ] stetig weiterentwickelt 

und optimiert. In der EJB-Spezifikation 2.0 [DeMichiel et al. 00] wurde u.a. die automatische 

Verwaltung von Beziehungen zwischen Entity-Beans (Container-Managed Relations, CMR) 

hinzugefügt. Dieses reduziert den Programmieraufwand für den Bean-Entwickler, denn bisher 

müssen komplexe Beziehungen zwischen Entity-Beans manuell in den Beans programmiert 

werden. 

Ein weiteres Problem bei Entity-Beans in der hier betrachteten EJB-Spezifikation 1.1 ist, daß 

alle Methodenaufrufe einer Entity-Bean letztendlich entfernte Aufrufe sind, selbst wenn der 

Aufrufer eine Bean im selben EJB-Container ist. Konkret bedeutet dies, daß ein Aufruf einer 

Methode einer lokalen Bean sämtliche Protokolle durchläuft wie ein Aufruf, der einer Bean 

gilt, die an einem ganz anderen Ort liegt. 

Diese Tatsache hat starken Einfluß auf die Performanz von Anwendungen, die auf EJB- 

Komponenten aufbauen. Um solchen Fällen differenzierter begegnen zu können, wurden 

u.a. die sog. local interfaces in der EJB-Spezifikation 2.0 eingeführt. 

Um das Problem der Beziehungen zwischen EJB-Komponenten zu lösen, besteht die Möglichkeit 

sog. Objekt-Relationale Mapping-Werkzeuge einzusetzen (vergl. [ObjRelMapping a], 

[ObjRelMapping b]). Diese Werkzeuge sind in der Lage, Objekte persistent in einer relationalen 

Datenbank zu speichern. Das Problem beim Einsatz dieser Werkzeuge ist, daß diese 

Werkzeuge nicht für jeden Application-Server verfügbar sind, was die Portabilität der EJB- 

Anwendungen einschränken würde. 

Die EJB-Spezifikation erlaubt es, wie in dieser Arbeit anhand einer Beispielanwendung gezeigt, 

EJB-Komponenten zu schreiben, die ohne Modifikation in verschiedenen Application- 

Servern installierbar und lauffähig sind, sofern keine produktspezifischen Erweiterungen 

verwendet werden. In den meisten Fällen wird es wohl nicht gelingen, ohne den Einsatz 

von produktspezifischen Funktionen auszukommen.

KAPITEL 8. ZUSAMMENFASSUNG UND AUSBLICK 72 

Ein Verzicht auf den Einsatz solcher Zusatzfunktionen bedeutet in der Regel, daß Eigenentwicklungen 

durchgeführt werden müssen. Dies hat wiederum zur Folge, daß mehr Zeit 

und mehr Programmieraufwand für die Durchführung eines Projektes eingeplant werden 

müssen. Es müssen sozusagen Entscheidungen darüber getroffen werden, ob der herstellerunabhängige 

und EJB-konforme Weg oder der herstellerabhängige und nicht EJB-konforme 

Weg gewählt wird. 

Eine der größten Herausforderungen bei der Entwicklung von neuen EJB-Anwendungen ist 

die Behandlung von Primärschlüsseln und Objektidentitäten. In objektorientierten Anwendungen 

wird kein zusätzlicher künstlicher Schlüssel für die eindeutige Identifizierung benötigt, 

da jedes Objekt per se eindeutig ist. Bei zwei in Beziehung stehenden Objekten hat das 

eine beteiligte Objekt schon aufgrund der Beziehung mit dem anderen Objekt eine Identität.

Literaturverzeichnis 

Alur et al. 01: Alur, Deepak, Crupi, John, und Malks, Dan. Core J2EE Patterns: Best Practices 

and Design Strategies. Prentice Hall / Sun Microsystems Press, 2001. 

BEA a: BEA Systems Inc., http://www.bea.com/products/tuxedo/index.shtml). 

BEA b: BEA Systems Inc., http://www.beasys.com, http://www.bea.com. 

Benfield 99: Benfield, Steve. What Do Application Servers Really Do? Web Techniques, Februar 

1999. http://www.webreview.com/1999/02_26/developers/02_26_99_5.shtm. 

Blair 01: Blair, Liz. Build to Spec! Java Developer’s Journal, Juli 2001. 

http://www.JavaDevelopersJournal.com/, 

http://developer.java.sun.com/developer/technicalArticles/J2EE/build/. 

Borland : Borland Corporation, http://www.borland.com. 

CetusLinks : http://www.cetus-links.org/oo_distributed_objects.html. 

DeMichiel et al. 00: DeMichiel, Linda G., Yalcinalp, L. Ümit, und Krishnan, Sanjeev. Enterprise 

JavaBeans Specification Version 2.0, Public Draft. Technical report, Sun Microsystems Inc., 

Mai 2000. http://java.sun.com/products/ejb. 

Denninger, Peters 00: Denninger, Stefan und Peters, Ingo. Enterprise JavaBeans. Addison- 

Wesley, 2000. 

Duden 93: Duden Informatik. Dudenverlag, 2. edition, 1993. 

Ernst, Schneider 00: Ernst, Matthias und Schneider, Daniel. Konzepte und Implementierungen 

moderner virtueller Maschinen: Nebenläufigkeit, automatische Speicherverwaltung und dynamische, 

optimierende Compiler für Java. Diplomarbeit, Fachbereich Informatik, Universität 

Hamburg, Germany, Dezember 2000. 

Fowler, Scott 99: Fowler, Martin und Scott, Kendall. UML Distilled - A brief guide to the Standard 

Object Modelling Language. Addison-Wesley, 2nd edition, 1999. 

Frank : Frank, Ulrich. Software-technische Konzepte und Perspektiven für die Gestaltung betrieblicher 

Informationssysteme. 

Gamma et al. 95: Gamma, Erich, Helm, Richard, Johnson, Ralph, und Vlissides, John. Design 

Patterns. Addison-Wesley, 1995. 

73

LITERATURVERZEICHNIS 74 

Griffel 98: Griffel, Frank. Componentware – Konzepte und Techniken eines Softwareparadigmas. 

dpunkt-Verlag, 1998. 

Henrich 01: Henrich, Andreas. Komponentenbasierte Architekturen und Systeme. Universität 

Bamberg, 2001. 

http://ai1.inf.uni-bayreuth.de/lehre/ss_2001/rechner_und_systemarchitekturen/ 

vorlesungsskript/3komponenten.pdf. 

Holland 01: Holland, Grant. Entity bean relationships in EJB 1.1. Java Report, April 2001. 

http://www.javareport.com. 

IBM a: IBM Corporation, http://www-4.ibm.com/software/ts/cics/about/ 

gim/dfhe2ch1.html. 

IBM b: IBM Corporation, http://www.ibm.com. 

InfoWeek 00: Middleware. Application-Server: IT-Welten in Verbindung. Information Week, 

April 2000, Nr. 11. 

http://www.informationweek.de/index.php3?/channels/channel23/001142.htm. 

J2EE : http://de.iplanet.com/products/infrastructure/app_servers/migration/j2ee.html. 

Larman 01: Larman, Craig. Applying UML and Patterns - An Introduction to Object-Oriented 

Analysis and Design and the Unified Process. Pearson Education, 2nd edition, 2001. 

Lewis : Lewis, Thomas. VB COM - A Visual Basic Programmer’s Introduction To COM. Wrox 

Press. 

Marinescu 02: Marinescu, Floyd. EJB Desin Patterns: Advanced Patterns, Processes, and Idioms. 

John Wiley & Sons, 2002. 

Matena, Hapner 99: Matena, Vlada und Hapner, Mark. Enterprise JavaBeans Specification 

v1.1, Final Release. Technical report, Sun Microsystems Inc., Dezember 1999. 

http://java.sun.com/products/ejb. 

Microsoft : Microsoft Corporation, http://www.microsoft.com. 

Monson-Haefel 00: Monson-Haefel, Richard. Enterprise JavaBeans. O’Reilly, 2nd edition, 

2000. 

Monson-Haefel 01: Monson-Haefel, Richard. Enterprise JavaBeans in a Nutshell , 2001. 

http://www.ejbnow.com/articles/ejb_nutshell.html. 

ObjRelMapping a: http://www.object-relational.com/articles/objectrelational_mapping.html. 

ObjRelMapping b: http://www.objectarchitects.de. 

OMG : OMG, Object Management Group, http://www.omg.org. 

Oracle : Oracle Corporation, http://www.oracle.com. 

Persistence : Persistence Corporation, http://www.persistence.com.

LITERATURVERZEICHNIS 75 

Ray 01: Ray, Erik T. Einführung in XML. O’Reilly, 2001. 

Rechenberg, Pomberger 97: Rechenberg, Peter und Pomberger, Gustav. Informatik-Handbuch. 

Hanser Verlag, 1997. 

Roman 99: Roman, Ed. Mastering Enterprise JavaBeans and the Java 2 Platform. John Wiley & 

Sons Inc., 1999. 

Saake, Sattler 00: Saake, Gunter und Sattler, Kai-Uwe. Datenbanken & Java: JDBC, SQLJ und 

ODMG. dpunkt.verlag, Mai 2000. 

Schmidt, Matthes 98: Schmidt, Joachim W. und Matthes, Florian. Datenbankhandbuch Kapitel 

1: Datenbankmodelle und Datenbanksprachen. (unpublished manuscript), 1998. 

Segev, Bichler 99: Segev, A. und Bichler, M. Handbook on Electronic Commerce, S. 313–337. 

Springer Verlag, 1999. 

Silverstream : http://www.silverstream.com. 

Sun : Sun Microsystems Inc., http://www.sun.com. 

Sun 01: The Java 2 Platform, Enterprise Edition Blueprints , 2001. 

http://java.sun.com/j2ee/blueprints/. 

Sybase : Sybase Corporation, http://www.sybase.com. 

Szyperski 97: Szyperski, Clemens. Component Software Beyond Object-Oriented Programming. 

Addison-wesley, 1st edition, 1997. 

XML : http://www.w3.org/XML.

Erklärung 

Hiermit erkläre ich, daß ich die vorliegende Diplomarbeit selbständig durchgeführt und keine 

anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. 

Hamburg, den 20. November 2002 

(Celal Akçiçek)

Paper (PDF) - STS

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?