Darstellung der J2EE Architektur

Inhaltsverzeichnis

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

1. EINLEITUNG

2. GRUNDLAGEN
2.1 Client/Server Architekturen
2.2 Das Konzept der Java 2 Enterprise Edition

3. DIE ARCHITEKTUR DER JAVA 2 ENTERPRISE EDITION
3.1 Die Client/Server Architektur
3.2 Die Komponenten der Java 2 Enterprise Edition
3.3 Die Container Architektur
3.3.1. Transaktionsmanagement
3.3 .2. Sicherheitsmanagement
3.4. Die Connector Architektur
3.5. Datenbankmanagement

4. DIE UMSETZUNG DER J2EE ARCHITEKTUR AM BEISPIEL VON JCREW.COM

5. SCHLUSSBETRACHTUNG

LITERATURVERZEICHNIS

Tabellenverzeichnis

Tabelle 1: Geschäftsprozessoptimierung durch J2EE

ABKÜRZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Durch die wachsende Bedeutung des Internet und des E-Commerce unterliegt die Soft­wareindustrie einem starken Wandel. Die Anforderungen an die Softwareentwicklung sind im Laufe der Zeit immer mehr gestiegen. Neben der stark zunehmenden Komplexi­tät der Anwendungen muss auch die Entwicklungszeit möglichst kurz gehalten werden, um auf die sich schnell ändernden Anforderungen der Märkte zu reagieren. Begriffe wie time-to-market sind für die Wettbewerbsfähigkeit der Unternehmen von entschei­dender Bedeutung. Durch die zunehmende Vernetzung und den Kommunikationsbedarf innerhalb der Unternehmen ist auch eine einheitliche Sicht auf Daten und Prozesse er­forderlich, um einen reibungslosen Informationsfluss zu gewährleisten. Insgesamt erge­ben sich folgende Anforderungen an die Softwareentwicklung:

- Kurze Entwicklungszeiten - auf neue Trends und Technologien muss immer schneller reagiert werden
- Produktivität der Programmierung - neue Technologien müssen sinnvoll mit den bestehenden Systemen verbunden werden
- Hohe Verfügbarkeit und Zuverlässigkeit - durch die steigende Bedeutung der EDV richten auch Ausfallzeiten einen größeren Schaden an
- Sicherheit - die intra- und interbetriebliche Vernetzung erfordert umfassende Si­cherheitsmodelle
- Skalierbarkeit - einfacher Ausbau des (Teil-) Systems bei wachsenden Anforde­rungen
- Integration - neue Anwendungen müssen mit den vorhandenen Datenbanksys­temen integriert werden können

Eine Möglichkeit diesen Anforderungen zu begegnen ist die Aufteilung der Systemar­chitektur in mehrere Schichten.^[1]

Die hier vorliegende Arbeit stellt die Architektur der Java 2 Enterprise Edition (J2EE), welche auf einer mehrschichtigen Systemarchitektur basiert, vor. Ziel dieser Arbeit ist es die Grundlegende Architektur und die Vorteile der J2EE aufzuzeigen. Anfangs wird ein kurzer Überblick über die Systemarchitekturen und das Grundkonzept der J2EE gegeben. Anschließend wird gezeigt aus welchen Elementen die Architektur besteht und wie sie aufgebaut ist. Zum Schluss wird die praktische Umsetzung und die Vorteile die­ser Architektur am Beispiel der Firma J.Crew verdeutlicht.

2. Grundlagen

2.1 Client/Server Architekturen

Im Folgenden wird beschrieben wie sich die Systemar­chitekturen aufteilen lassen, um den genannten Anfor­derungen gerecht zu werden. Zuerst wird die klassische 2-Ebenen Architektur beschrieben, um dann anschließend anhand der Nachteile dieser Architektur die Vorteile einer 3-/Mehr-Ebenen Architektur aufzuzeigen.

Bei der 2-Ebenen Architektur handelt es sich um die klassische Client-Server Architek­tur. Der Client greift auf einen Server zu, wobei die Geschäfts- und Präsentationslogik auf dem Client abgelegt ist. Man spricht in diesem Fall von einem Fat-Client. Dieser Ansatz weist jedoch eine Reihe von Nachteilen auf. Zum einen ist der Wartungsauf­wand sehr hoch, da im Falle von Fat-Clients selbst bei kleinsten Änderungen der An­wendungslogik jeder Client einzeln aktualisiert werden müsste. Zum anderen ist eine 2- Ebenen Architektur nur schwer skalierbar. Ein Großteil der Arbeitslast liegt bei den Clients, wobei auch die Belastung der Netzwerke aufgrund der vielen Datenbankanfra­gen relativ hoch ist.

Seit einiger Zeit existieren aber auch Architekturen, bei denen die Geschäftslogik auf dem Server abgelegt wird. In diesem Fall relativieren sich die Nachteile der klassischen Client-Server Architektur, da das System nun leichter skalierbar ist und die Belastung des Netzwerkes sinkt. Es entsteht aber das Problem, daß auf diese Weise die Geschäfts­logik fest an eine bestimmte Realisierung der Datenschicht gebunden ist.^[2]

Die 3-Ebenen Architektur teilt die Anwendung in drei Schichten auf, bei dem die Be­nutzerschnittstelle auf dem Client-Rechner liegt und die Daten auf dem Backend­Server. Dazwischen liegt die Mittlere-Ebene (Middle-Tier), welche auch Applikations­server genannt wird, die für die Steuerung und Verarbeitung verantwortlich ist. Der Ap­plikationsserver „bietet eine Infrastruktur für die Entwicklung und den Ablauf von Bu- siness-Logik-Komponenten.“^[3] Der Applikationsserver kann wie folgt definiert werden: Ein Applikationsserver ist ein spezielles Computerprogramm (Server) in einem verteil­ten Netzwerk, der die Geschäftslogik für Applikationsprogramme bereitstellt. Er wird oft als Teil einer vielschichtigen Applikation angesehen. Oft verbindet der Applikationsserver seine Dienste mit einem Web-Server. Als Web-Server wird ein Programm bezeichnet, das Anfragen zu dynamischen als auch statischen Dokumenten, Bildern etc. über ein spezielles Protokoll abarbeiten kann. ^[4]

Abbildung in dieser Leseprobe nicht enthalten

Die Multi-Tier (Mehrfach-Ebenen) Architektur erweitert die 3-Ebenen Architektur, indem die Anwendungskomponenten auf mehrere Schich­ten verteilt werden. Die Präsentationsschicht ist weiterhin auf dem Client installiert und die Daten liegen auf dem Backend-Server, welcher auch als EIS-Ebenen (Enterprise Information System) bezeichnet wird. Die Mittlere-Ebene wird hier jedoch weiter differenziert. Es wer­den auf den dazwischen liegenden mittleren Schichten weitere Server implementiert, die sich zum Beispiel gegenüber einem Backend-Server wie ein Client verhalten und be­stimmte Services anfordern, während sie sich gegenüber dem Client-Rechner wie ein Server verhalten, der Dienste zur Verfügung stellt. Ein Beispiel hierfür wäre die Auftei­lung der Middle-Tier in einen Web-Server und einen Server für die Geschäftslogik.^[5] Die 3-Ebenen bzw. Multi-Tier Architektur weist erhebliche Vorteile im Vergleich zur 2- Ebenen Architektur auf. Durch die Zentralisierung der Geschäftslogik kann eine erhöhte Sicherheit realisiert werden, da die schutzbedürftigen Unternehmensdaten sowohl phy­sikalisch als auch logisch z.B. von den Clients getrennt werden. Aber „auch die Leis­tungsfähigkeit des Systems einschließlich der Möglichkeit zur Skalierung wächst, da die relevanten Komponenten nicht mehr über das Netzwerk verteilt sind“^[6]. Als Nachteil ergibt sich jedoch die erhöhte Komplexität des Gesamtsystems. Hieraus resultiert auch der erhöhte Entwicklungs-, Management-, und Administrationsaufwand.^[7] Das Konzept der Multi-Tier Architektur existiert bereits seit einigen Jahren. Das Prob­lem war jedoch, dass es keinen einheitlichen Standard für die Umsetzung dieser Archi­tektur gab. Somit musste das Zusammenspiel zwischen Applikationsserver für jedes Produkt neu angepasst werden. Da keine Definition der Schnittstellen existierte, konnte die Portabilität nicht genutzt und somit die Vorteile der Multi-Tier Architektur nicht ausgenutzt werden. Die Firma Sun versucht dieses Problem mit der Java 2 Enterprise Edition zu lösen.

2.2 Das Konzept der Java 2 Enterprise Edition

Die Java-2-Enterprise-Edition (J2EE) definiert einen Standard zur Implementation, Konfiguration, Verteilung und zum Einsatz von unternehmensweiten Anendungen. Es handelt sich hierbei jedoch nicht um ein Produkt, sondern um einen allgemeinen Rah­men zur Erstellung solcher Anwendungen. Er basiert auf dem Komponentenmodell von Java und wurde von Sun definiert. Dabei kann die J2EE-Technologie als konsequente Weiterentwicklung der Java-APIs JDBC, Servlets und Enterprise Java Beans betrachtet werden „Der Kern des J2EE-Modells besteht darin, einfach anpassbare und leicht zu administ­rierende Komponenten unabhängig von Systemdiensten wie Transaktionsverwaltung, Persistenz oder Autorisierung zu entwickeln, welche plattformübergreifend eingesetzt und an existierende Informationssysteme angekoppelt werden können.“^[8] Die Basis bildet eine 3-Ebenen Architektur bzw. eine Multi-Tier Architektur, in der die Geschäftslogik zum einen von Systemdiensten und zum anderen von der Benutzer­schnittstelle abgekoppelt wird. Dies geschieht durch die sogenannte Middleware bzw. durch den Applikationsserver. „Im Vergleich zu anderen Middleware-Techniken [...] erhebt J2EE den Anspruch konsequent auf einem Komponentenmodell zu basieren und portabel zu sein.“^[9] Somit können die Vorteile der Wiederverwendbarkeit und der Platt­formabhängigkeit genutzt werden.^[10]

Ziel der J2EE ist es, die Kosten und die Komplexität des Entwickelns von Multi-Tier Anwendungen zu reduzieren. Dies soll durch die Definition einer Standardarchitektur geschehen, welchen aus folgenden drei Hauptelementen besteht:

- Komponenten - beinhalten die Präsentations- und Geschäftslogik
- Container - setzen die Laufzeitumgebung um
- Connectoren - stellen den Zugang zu den Datenbanksystemen her^[11] Abbildung 3 zeigt die verschiedenen Komponenten, welche in der J2EE enthalten sind. Die hier aufgeführten BluePrints bezeichnen das Standard-Applikationsmodell der

Plattform, die sich mit der Standardlaufzeitum­gebung für J2EE An­wendungen beschäftigt. Des Weiteren gibt es noch eine Referenzimplementation, sowie eine Sammlung von Kompatibilitätstests.^[12]

Die Anwendung der J2EE Architektur bringt eine Reihe von Vorteilen, welche hier kurz erläutert werden:

- Einfache und somit schnellere Entwicklung
Durch die Plattformunabhängigkeit von Java kann einmal entwickelte Software auf ver­schiedenen Rechnertypen und Betriebssystemen eingesetzt werden. Dies beschleunigt die Entwicklungszeiten, da unterschiedliche Programmiermodelle nicht mehr berück­sichtigt werden müssen. Das Komponentenkonzept erlaubt zusätzlich eine leichte Mo­dellierung des Systems nach Funktionalitäten.
- Bessere Skalierbarkeit
Die Multi-Tier Architektur von J2EE erlaubt eine gezielte Skalierung des Systems an genau den Stellen, wo Leistungsengpässe bestehen. So können zum einen mit Hilfe der Container (s.a. Container Architektur) Erweiterungen auf die betroffenen Teile begrenzt werden und zum anderen besteht die Möglichkeit Container so zu implementieren, dass sie sich selbstständig skalieren.
- Integration von bestehenden Datenbanksystemen
Durch die JDBC Treiber können die unterschiedlichsten relationalen EIS über eine ein­heitliche Schnittstelle angeschlossen werden. Die neue Connector Architektur erlaubt zusätzlich das Anbinden von nichtrelationalen EIS, wie z.B. SAP R/3.
- Einheitliches Sicherheitsmodell
Durch das J2EE Sicherheitsmodell ist es möglich, dass Zugriffe über die Grenzen ver­schiedener Systeme kein erneutes Anmelden erfordern.
- Freie Wahl der Produkte

Die Unternehmen müssen sich nicht auf einen Hersteller festlegen. Serverplattform und Komponenten können von verschiedensten Anbietern angeboten werden. Die Einhal­tung des J2EE Standards garantiert die Kompatibilität zwischen den einzelnen Produk­ten.^[13]

3. Die Architektur der Java 2 Enterprise Edition

3.1 Die Client/Server Architektur

Die Java 2 Enterprise Edition beschreibt eine verteilte, mehrschichtige und Java-basierte Anwendungsarchitektur. Diese teilt sich auf in eine Client-Ebene, eine Mittlere-Ebene, wobei sich diese in eine Web-Ebene und Geschäftsebene aufteilt, sowie eine Enterprise Information System (EIS) -Ebene. Die Aufteilung der Mittleren-Ebene in eine Web- und Geschäftsebene ist nicht zwingend erforderlich und kann auch nur logisch und nicht physikalisch geschehen. In diesem Fall würden beide Ebenen auf dem J2EE-Server lie­gen. Unter dem J2EE-Server versteht man letztendlich nichts anders als einen J2EE konformen Applikationsserver.^[14]

Abbildung in dieser Leseprobe nicht enthalten

Applikationsserver / J2EE Server Abbildung 4: J2EE Architektur Entworfen und gezeichnet: Verfasser, in Anlehnung an: o.V., Developing J2EE Applications, S. 5 Die Aufgabe der Client-Ebene beschränkt sich primär auf das Anzeigen von Informati­onen z.B. durch einen Web-Browser, sowie die Entgegennahme von Benutzereingaben. Ziel ist es möglichst wenig Applikationen, wie z.B. Datenbankabfragen, auf dem Client selbst durchzuführen. Es sollen Thin-Clients realisiert werden. Zu den hier unterstützten Technologien gehören unter anderem auch HTML-Clients, Applets, XML-Dokumente und auch java-basierte Stand-Alone-Programme. Die Client-Ebene stellt also das Front- End der J2EE dar. Als mögliches Front-End kommen sowohl Desktop Anwendungen und Web Browser, als auch Endgeräte wie PDAs oder Mobiltelefone in Frage. Die Client-Ebene kommuniziert primär mit der Web-Ebene, kann aber auch direkt auf die Business-Ebene zugreifen. Ein direkter Zugriff auf die EIS-Ebene ist nicht möglich, wodurch die EIS-Ebene, welche u.a. auch die sensiblen Geschäftsdaten enthält, besser geschützt wird.^[15]

Auf der Web-Ebene wird die Präsentationslogik zur Verfügung gestellt. Gleichzeitig nimmt sie die Benutzereingaben von HTML, Applets und XML Clients entgegen und generiert die entsprechenden Antworten. Diese Ebene kann durch Servlets oder Java Server Pages (JSP) realisiert werden. Die Web-Ebene kommuniziert mit Client- und Business-Ebene. Die Web-Ebene realisiert die Präsentationsschicht einer J2EE- Anwendung und leitet u.a. auch Anfragen der Client-Ebene an die Business-Ebene wei­ter.

Die Business-Ebene stellt die Geschäftslogik bzw. Anwendungslogik zur Verfügung, welche durch Enterprise Java Beans (EJB) realisiert wird. Diese Schicht bildet das Rückrat des gesamten J2EE-Konzepts. Die Business-Eben kommuniziert mit allen drei Ebenen. So startet sie u.a. Abfragen an die EIS-Ebene, leitet Abfrageergebnisse an die Web- oder Client-Ebene weiter, oder empfängt Abfragedaten von der Web- oder Client- Ebene.^[16]

In der EIS-Ebene werden die unternehmenskritischen Daten gehalten. Hierbei kann es sich um verschieden Arten von Datenbanken handeln, sowohl relationale als auch nicht­relationale Datenbanksysteme. Die Aufgaben der EIS-Ebene erstrecken sich von ge­wöhnlichen Datenbanksystemen über das Enterprise Resource Planing (ERP), soge­nanntes Mainframe Transaction Processing und andere Informationssysteme. Der Zugriff auf die Datenbanken wird durch eine Reihe von Standard APIs realisiert. Die Anbindung relationaler Datenbanken erfolgt primär über die Java Database Connectivi­ty (JDBC) Treiber, während für die Anbindung nichtrelationaler Datenbanken die Java Connector-Architektur vorgesehen ist.^[17]

3.2 Die Komponenten der Java 2 Enterprise Edition

In dem folgenden Abschnitt wird kurz das allgemeine Komponentenmodell beschrie­ben. Anschließen wird auf dessen Umsetzung in der J2EE eingegangen, wobei hier das Hauptaugemerk auf den serverseitigen Komponenten, nämlich den Enterprise Java Beans liegt.

Die Komponententechnik dient der Entwicklung von Komponentensoftware, die eine anwendungsübergreifende Wiederverwendung der Komponenten, eine Art Software­Baustein, unterstützt. Ziel ist es hierdurch Anwendungssysteme zu erstellen, die aus beliebig austauschbaren Komponenten zusammengesetzt werden können. Für jede Komponente muss jedoch ihre Funktionalität und ihre Schnittstellen zur Umgebung genau definiert sein.17^[18] Das Komponentenmodell legt einen Rahmen für die Entwicklung und Ausführung von Komponenten fest. Es bietet eine Infrastruktur, die häufig benötig­te Mechanismen implementieren kann.^[19]

Die J2EE Spezifikation definiert vier verschiedene Komponentenarten, die eine J2EE Anwendung unterstützen muss:

- Java Applikationen
- Applets
- Servlets und Java Server Pages (JSP)
- Enterprise Java Beans (EJB)

Diese vier Komponentenarten lassen sich in drei Kategorien aufteilen: Die Client­Komponenten - zu denen Java Applikationen und Applets gehören - , die Web­Komponenten - die die Servlets und JSP beinhalten - und die Business-Komponenten.^[20] Die Client-Komponenten stellen im Wesentlichen die grafische Benutzeroberfläche zur Verfügung. Sie können durch Applets, welche in einem Web-Browser ausgeführt wer­den, oder auch eigenständige Anwendungen realisiert werden, wobei sie nicht durch den J2EE-Server ausgeführt werden und ihre Konfiguration in der J2EE-Spezifikation auch nur teilweise beschrieben wird.^[21]

Die Web-Komponenten werden als Benutzerschnittstelle in Web-basierten J2EE- Anwendungen benutzt und unterstützen die dynamische Generierung von Webseiten. Hierbei muss zwischen Servlets und Java Server Pages (JSP) unterschieden werden. Java Servlets sind serverseitig ausführbare Java-Klassen, also eine Art serverseitige Applets, die dynamisch vom Server geladen werden können, um so dessen Funktionali­tät zu erweitern. Ein Servlet erhält vom Client eine Anfrage, wertet sie aus und generiert eine entsprechende Antwort. Bei den Java Server Pages handelt es sich um eine Erwei- terung der Servlets. Eine JSP ist eine HTML-Seite mit eingebetetem Java Code. Durch die Einbettung wird es möglich, dynamische HTML-Seiten zu erzeugen. So können z.B. Daten aus einer Datenbank gelesen werden und mit Hilfe einer einfachen Schleife dy­namisch in einer Tabelle auf der HTML-Seite dargestellt werden.

Unter den Business-Komponenten versteht man die Geschäftslogik, also die eigentliche Anwendungslogik. Dies sind z.B. Vorgänge wie Ware bestellen, Rechnungen zu erstel­len, Lager buchen etc. Realisiert wird die Geschäftslogik mit Hilfe von Enterprise Java Beans, bei der es sich um eine serverseitige Komponente handelt. Eine Besonderheit der EJBs stellt ihre vollständige Portabilität dar.^[22]

Die EJBs teilen sich in drei Arten auf: Die Session Beans (transistentes Verhalten), die Entity Beans (persistentes Verhalten) und die Message-Driven Beans, die hier nur am Rande erwähnt werden. Jede Art entspricht einer anderen Abstraktion der Geschäftslo­gik. Verallgemeinert lässt sich sagen, „dass die Session Beans für die Interaktion mit dem Benutzer und die Entity Beans für die Verarbeitung von Daten in Datenbanken benutzt werden.“^[23]

Session Beans werden für eine vorübergehende Kommunikation verwendet, da sie sich transistent verhalten und somit zur Realisierung der Anwendungslogik geeignet sind. Die Entity Beans, bei denen eine dauerhafte Speicherung stattfindet, folglich ein per­sistentes Verhalten aufzeigen, eignen sich zur Realisierung der Datenhaltung.^[24]

3.3 Die Container Architektur

Die Laufzeitumgebung für J2EE Anwendungen wird durch sogenannte Container reali­siert. Der Container stellt dabei eine einheitliche Sicht auf die in ihm verborgenen Komponenten dar. Diese einheitliche Sicht wird durch das zur Verfügung stellen von Systemschnittstellen realisiert. Der Container „ummantelt“ also eine Reihe von Kom­ponenten und stellt ihnen eine einheitliche Schnittstelle zur Verfügung. Dies hat mehre­re Vorteile. So müssen sich die Entwickler der Komponenten nun nicht mehr um die Integration und Programmierung von Schnittstellen für ihre Komponenten kümmern. Dadurch kann die Entwicklungszeit verkürzt und die Konzentration auf die Funktionali­tät der Komponente gerichtet werden. Zusätzlich erhöht diese einheitliche Schnittstel­lenumgebung die Portabilität von Komponenten und Applikationen.

Die Container bieten den Komponenten den Zugang zu den verschiedensten Technolo­gien und APIs von J2EE. Zu diesen APIs gehören:

- Java Database Connectivity (JDBC) - die dazu dient verschiedenste Datenbank­systeme anzubinden (s.a. Datenbankmanagement)
- Java Transaction API (JTA) - die den Zugriff von Anwendungen auf gemein­sam genutzte Ressourcen wie Datenbanken oder Message-Systeme regelt und eine korrekte Durchführung von globalen Transaktionen garantiert
- Java Naming and Directory Interface (INDI) - das den Zugriff auf Namens­und Verzeichnisdienste durch Java-Programme ermöglicht
- Remote Method Invocation (RMI) / Corba Internet Inter ORB Protocol (IIOP) - Die RMI ermöglicht die Kommunikation zwischen Java-Objekten in verschie­denen virtuellen Maschinen, die RMI-IIOP ermöglicht zusätzlich die Integration von CORBA-Objekten in J2EE Anwendungen
- Java Message Service (JMS) - bietet Zugriff auf sogenannte Message-Queuing- Systeme
- Java Mail - definiert Schnittstellen und abstrakte Klassen mit denen E-Mails abgerufen oder verschickt werden können
- Java Beans Activation Framework (JAF) - ermöglicht den Umgang mit MIME­Datentypen (Multipurpose Internet Mail Extensions)^[25]

Insgesamt ergeben sich vier verschiedene Dienste, die durch die Container angeboten werden und allen Komponenten zur Verfügung stehen. Dazu gehört der Namensdienst, der Transaktionsdienst, der Sicherheitsdienst und der Konfigurationsdienst.

Abbildung in dieser Leseprobe nicht enthalten

Der Namensdienst kann von Komponenten und Applikationen gleichermaßen genutzt werden. Er stellt eine JNDI-Namensumgebung zur Verfügung. Diese Umgebung erlaubt unter anderem die Konfiguration von Komponenten ohne Kenntnis des Quellcodes.

Der Transaktionsdienst gehört zu den wichtigsten Diensten einer J2EE Anwendung, er wird daher auch in dem Abschnitt Transaktionsmanagement ausführlich erläutert. Das Gleiche gilt auch für den Sicherheitsdienst.

Der Konfigurationsdienst führt die Konfiguration der Container anhand von Deploy­ment Deskriptoren durch. Diese werden bei der Erstellung, Zusammenstellung und An­passung der Komponenten angelegt. Es handelt sich hierbei um eine XML-Datei, die beschreibt wie Komponenten zu Aggregaten zusammenzufassen sind, die Informationen enthält die im Code einer Komponente nicht zu finden sind und dem Container mitteilt wie er Komponenten zur Laufzeit zu behandeln hat. Zusätzlich beschreibt er noch die Struktur der Komponente und ihre externen Abhängigkeiten. Beispielsweise können Servlets so konfiguriert werden, so dass sie beim Start des Container automatisch instal­liert werden.

„Die Aufgabe des Containers besteht darin abhängig vom Inhalt der Deskriptoren auto­matisch die gewünschte Laufzeitumgebung bereitzustellen, also z.B. eine Transaktion zu starten oder die Sicherheitsbedingungen zu überprüfen.“25^[26] Dabei stellt sich die Frage wie ein Container die richtige Laufzeitumgebung bereitstellen kann, wenn ein externer Client auf eine Komponente zugreift. Er tut dies, indem er den Aufruf abfängt. Dieser Vorgang wird auch als Interception-Mechanismus bezeichnet. Der Client erhält also keine direkten Zugriff auf die Komponente, auch wenn es aus seiner Sicht so aussieht.

3.3.1. Transaktionsmanagement

Das Transaktionsmanagement muss dafür sorgen, dass Transaktionen korrekt durchge­führt werden und gegebenenfalls bei Unvollständigkeit zurückgenommen werden. Bei der Durchführung von Transaktionen muss das ACID-Prinzip gewährleistet sein. Dieses besagt, dass Transaktionen entweder gar nicht oder komplett ausgeführt werden (Ato­micity), eine Transaktion die Datenbank von einem konsistenten wieder in einen konsi­stenten Zustand überführt (Consistency), Transaktionen unabhängig voneinander ablau­fen (Independency) und dauerhaft gespeichert werden (Durability). Anhand des ACID- Prinzips kann erkannt werden, welche Schäden ein schlechtes Transaktionsmanagement anrichten kann.

Zur Verdeutlichung sei folgendes Beispiel angeführt. Die Abbildung zeigt eine simulta­ne Aktualisierung von mehreren Datenbanken. Die Transaktion wird von einem Client gestartet der die EJB X aufruft. X aktualisiert nun die Datenbanken A und B. Anschlie­ßend ruft X die EJB Y auf. Y aktualisiert nun die Datenbank C. Die Aufgabe des EJB- Servers ist es sicherzustellen, dass entweder alle Aktualisierungen durchgeführt oder zurückgenommen werden.^[27] Das J2EE Modell definiert zwei Arten zur Kennzeichnung von Transaktionen.

Dabei handelt es sich um die deklarative Transaktionsbegrenzung und die pro­grammierte Transaktionsbegrenzung.

Bei der deklarativen Transaktionsbe­grenzung werden neben den Eigenschaf­ten auch die Grenzen, d.h. Anfang und Ende einer Transaktion, innerhalb des Deployment Deskriptors festgelegt. Die Implementierung der Transaktionsverwaltung muss also nicht vom Komponentenent­wickler durchgeführt werden. Die Transaktionsverwaltung wird komplett vom Contai­ner übernommen. Es müssen lediglich die Transaktionsattribute festgelegt werden, so dass der Container weiß wie er die Transaktionen durchführen soll. Die deklarative Transaktionsbegrenzung kann jedoch nur von EJB genutzt werden.

Die andere Möglichkeit ist die programmierte Transaktionsbegrenzung, bei der die Komponente die Transaktionsverwaltung in eigener Verantwortung übernimmt. In die­sem Fall werden die Eigenschaften der Transaktion in der Komponente selber, also di­rekt im Quell-Code, angegeben. Diese Variante muss von Web-Komponenten verwen­det werden, da ihnen die deklarative Transaktionsbegrenzung nicht zur Verfügung steht.^[28]

[...]

---

^[1] Vgl. Cattell, Rick: J2EE Technology in Practice, Online im Internet: http://developer.java.sun.com/developer/Books/J2EETech/ch2.pdf, Abruf 15.10.2001, S. 12-14

^[2] Vgl. Stahlknecht, Peter u.a.: Einführung in die Wirtschaftsinformatik, 8.Aufl., Berlin 1999

^[3] Vgl. Hranitzky, Norbert: Applikationsserver, Online im Internet:

http://www.hranitzky.purespace.de/docs/appserver.pdf, Stand 4.11.1998, Abruf 2.9.2001, S. 55

^[4] Vgl. o.V.: Online im Internet: www.whatis.com, Abruf 5.10.2001.

^[5] Vgl. Stahlknecht, Peter u.a., a.a.O., S. 145-150.

^[6] Husemann, Martin: Java 2, Enterprise Edition Einführung und Überblick, Online im Internet: http://wwwdbis.informatik.uni-kl.de/courses/seminar/SS2001/, Abruf 27.9.2001, S. 6.

^[7] Vgl. Cattell, Rick, a.a.O., S. 13-14.

^[8] Turau, Volker u.a.: Java Server Pages und J2EE:unternehmensweite Web-basierte Anwendungen, 1. Aufl., Heidelberg 2001, S. 1.

^[9] Turau, Volker u.a., a.a.O., S. 1.

^[10] Vgl. o.V., Developing Java 2 Platform, Enterprise edition (J2EE) Compatible Applications:Role-based Training for Rapid Implementation, Online im Internet: http://java.sun.com/j2ee/white/j2ee.pdf, Stand 10.1.2001, Abruf 4.10.2001, S. 2-3; (im folgenden zitiert als: Developing J2EE Applications)

^[11] Vgl. o.V., Developing J2EE Applications, a.a.O., S. 3.

^[12] Vgl. o.V., Setting the Standard for Enterprise Applications, Online im Internet: http://java.sun.com/j2ee/overview3.html, Abruf 14.10.2001, S. 2-4;(Im folgenden zitiert als: Setting the Standard)

^[13] Vgl. o.V., Frequently Asked Questions, Online im Internet: http://java.sun.com/j2ee/faq.html, Stand 17.9.2001, Abruf 17.9.2001, S. 1-2.

^[14] Vgl. Pawlan, Monica: Introduction to the J2EE Platform, Online im Internet: http://developer.java.sun.com, Stand 23.3.2001, Abruf 3.9.2001, S. 2-3.

^[15] Vgl. o.V. What is the Java 2 Platform, Enterprise Edition?, Online im Internet: http://java.sun.com/j2ee/sdk_1.2.1/techdocs/guides/j2ee-overview/OverviewTOC.fm.html, Stand 1999, Abruf 3.9.2001, S. 4-6.

^[16] Vgl. Turau, Volker u.a., a.a.O., S. 4.

^[17] Vgl. Cattell, Rick, a.a.O., S. 14-17

^[18] Vgl. Stahlecker, Peter u.a., a.a.O., S. 341

^[19] Vgl. o.V.: Online im Internet: http://www-sst.informatik.tu- cottbus.de/~db/doc/SoftwareEngineering/Components.pdf, Abruf 3.9.2001, S. 19

^[20] Vgl. Shannon, Bill u.a.: Java 2 Platform Enterprise Edition: platform and component specifications, 1. Aufl., New Jersey 2000, S. 5-6

^[21] Vgl. Turau, Volker u.a., a.a.O., S. 4

^[22] Stal, Michael: Reich der Mitte: Die Komponententechnologien COM+, EJB und “CORBA Compo­nents”, Online im Internet: http://www.sigs.de/assets/images/stal.pdf, Abruf 27.9.2001, S. 4-5.

^[23] Stampfli, Marc: Seminar Java Aktuell:SS1999, Online im Internet: www.ifi.unizh.ch/~riedl/lectures/EJB.htm, Abruf 3.9.2001, S. 6

^[24] Vgl. Pawlan, Monica, a.a.O., S. 13.

^[25] Vgl. Turau, Volker u.a., a.a.O., S. 11-13.

^[26] Stal, Michael, a.a.O., S. 2.

^[27] Vgl. Shannon, Bill u.a., 2000, a.a.O., S. 504

^[28] Vgl. Turau, Volker u.a., a.a.O., S. 9