1. Vorwort

Application Server sind das Herzstück moderner Web-orientieter Softwarearchitektur. Die Aufgabe des Applikation Server ist vornehmlich die Erzeugung von dynamischen Webinhalten zu steuern. Seitdem Java 2 Enterprise Edition (J2EE) technisch tonangebend ist in diesem Bereich, stehen eine Menge ausgereifter Applikation Server bereit. Die Preise für solche Applikation Server erreichen schnell die 50.000 US$ Marke. Wer sich jedoch nicht auf die „großen“ Anbieter, wie IBM, BEA oder iPlanet festlegen möchte, dem bieten sich heute einige kostengünstige, aber leistungsstarke Alternativen. In diesen Dokument soll auf möglichen Alternativen eingegangen werden und deren Vor- und Nachteile gebenüber den großen Applikation Server beleuchtet werden.

2. Einleitung

Als Mitte der 90er Jahre die Client/Server-Modelle von der 3-Tier Architekturen allmählich abgelöst wurden, entstand der Applikation Server und mit ihm eine Reihe von Implementierungen, Spezifikationen und Standards. Man erinnere sich zum Beispiel an Produkte wir Apptivity von Progress oder an SilverStream, welche damals als Applikation Server zwar in der Lage wahren Java-Code zu verarbeiten, sich jedoch weit entfernt von übergreifenden Standards befanden.

Es folgte die Servlet-Spezifikation und die Enterprise JavaBeans (EJB), welche bis zu einem relativ fortgeschrittenen Grad festlegten, wie ein Java-basierter Server beschaffen sein sollte.

Ein Jahr nach diesen Neuerungen wurde die Java 2 Enterprise Edition (J2EE) geboren. Zahlreiche Hersteller von Applikation Servern, darunter auch SilverStream, bestanden die Zertifizierungs-Tests. Andere hingegen - wie Apptivity - überlebten diese Ära nicht und wurden eingestellt.

Die Architektur des Middle-Tiers die durch die J2EE-Architektur definierte wird, erfreut sich mittlerweile einer hohen Akzeptanz und somit wird sie von vielen Herstellern als De-Fakto-Industriestandard gesehen.

2.1 Die Markt Situation

Je mehr die fortscheitende Standardisierung für gesteigerten Know-how-Transfer sorgt und das Vertrauen der Kunden in die Java-Plattform dadurch anwuchs, desto schwieriger ist es für die Anbieter geworden, nach einem Merkmal zu suchen, das sie von anderen unterscheidet.

Wie will man sich mit Fähigkeiten profilieren, die mittlerweile jeder Anbieter auch anbietet(J2EE)?

Mittlerweile stellt die reine J2EE-Konformität keine Sensation mehr dar, vielmehr geht es darum, J2EE in leistungsfähigen Applikationen für eCommerce und Portale oder in Integrations-Mechanismen für Backend-Systeme einzubetten.

So hat es sich ergeben, dass so genannte Low-Cost-Anbieter wie In-Q-My mit ausgereiften J2EE-Systemen und einer aggressiven Preispolitik den Markt erobern.

Die hohen Preise der „großen“ Anbieter kommen nur zustande, da sie nach dem Motto:

„Wir sind nicht nur Infrastrukturlieferanten, sondern stellen ganze Lösungen bereit“ ihre Pakete schnüren.

Eine Frage die man sich immer stellen sollte wenn man ein J2EE-Projekt realisieren will ist, ob man tatsächlich eine voll ausgewachsene J2EE-Umgebung benötigt oder ob nicht der Einsatz von kostengünstigerer oder sogar kostenloser Systeme für einfache Server-Anwendungen ausreicht.

Wie eine jüngst erschienene Studie des US-Analysten Gartner bescheinigt, verschwenden Unternehmen weltweit eine Menge Geld bei ihren Investitionen in Applikation Server. Diese kommt zustande, weil „Applikation-Server-Händler ihre Kunden dazu ermutigen, High-End-Technologie zu kaufen, die sie gar nicht brauchen. „Es ist, als würde man Gourmet-Essen für ein Kinder-Sommercamp kaufen. Es ist einfach nicht nötig“, so David Smith, Vizepräsident und Research-Direktor von Gartner. Gartner empfiehlt das man sich im Vorfeld darüber Gedanken machen muss, welche Funktionalitäten tatsächlich benötigt werden und welche vielleicht überdimensioniert erscheinen.

2.2 Low-Cost Applikation Server

Der Markt der kostengünstigen Applikation Server ist nicht so schwer zu überblicken. Konzentriert man sich auf jene die nicht unbedingt das Sigel J2EE tragen, sondern auf solche, die unseren konkreten Bedürfnissen entsprechen, d.h sie unterstützen die für uns notwendigen APIs, so landet man unter anderem bei den OpenSource Applikation Servern Apache Toncat 4.0 und JBoss 3.0. Inzwischen existieren auf dem Markt zahlreiche Produkte die eine J2EE Spezifikation ganz oder teilweise umsetzen.

Apache Tomcat 4.0, JBoss 3.0 und MySQL 3.2 stellen zusammen, eine 100%ig kostenfreie, alternative zu den Lizenz behafteten J2EE-Infrastrukturen da.

Sie unterstützen, wie in Tabelle 1 zu sehen, eine Vielzahl der von J2EE festgeschriebenen APIs.

Tabelle 1: Die wichtigsten Bestandteile des J2EE-Standarts

2.3 Low Cost J2EE Projekte

Stellt man sich ein Portalframework vor, so ergeben sich einige wichtig Kriterien, die von den verwendeten Servern erfühlt werden müssen:

Die für eine Website mit geringem bis mittlerem Durchsatz notwendige Infrastruktur muss vorhanden sein. Es sollte eine integrierte Datenhaltung auf Basis einer relationalen Datenbank sowie das Versenden von E-Mails möglich sein.

Die Server sollten sich soweit als möglich an vorgeschriebene Standards halten.

Die Möglichkeit zur späteren Erweiterung der Anwendung muss gegeben sein. Das bezieht sich sowohl auf die Erhöhung des Durchsatzes(d.h Skalierbarkeit) als auch auf die Implementierung neuer Funktionalitäten auf Basis weitergehender, bis dahin nicht verwendeter APIs.

Last but not least: Der Preis, wer kein Großunternehmen im Nacken hat, für den ist das Preisniveau der High-End-Systeme meist indiskutabel

2.3.1 Rollenverteilung in J2EE Projekten

Aus der Architektur einer J2EE-Applikation ergeben sich die folgenden Rollen für die Mitarbeiter der Entwicklung und Bereitstellung:

·        J2EE Product Provider: Ist der Hersteller eines J2EE konformen Applikation Server. Er stellt die J2EE API durch die Container zur Verfügung.

·        Application Component Provider: Sind die Softwareentwickler, die J2EE-Komponenten entwickeln oder auch im Bereich der JSPs tätig sind.

·        Application Assembler: Der Application Assembler nimmt die von den Application Conponent Provider bereitgestellte Komponenten und fasst diese in Archiven zusammen.

·        Deployer: (englisch: to deploy = auf den Weg bringen, bereitstellen, verfügbar machen) Der Deployer ist dafür verantwortlich, die J2EE-Komponenten in eine operative Umgebung zu bringen. Dabei werden die Deploymenttools des J2EE-Providers verwendet, um gegebenenfalls die notwendigen containerspezifischen Klassen zu generieren. Zusätzlich kümmert sich der Deployer noch um weitere Ressourcen und Einstellungen, die für den Betreib der J2EE-Applikation notwendig sind.

·        Administrator: Er ist für die Installation und Verwaltung der operativen Umgebung verantwortlich und sorgt für den Betrieb der Applikation.

·        Tool Provider: Er stellt Tools zur Verfügung, die bei der Erstellung, dem Deployment und Betrieb der Applikation benutzt werden. Dazu können Entwicklungsumgebungen wie JBuilder oder IBM Visual Age For Java gehören. 

2.3.2 EJB: Ja oder Nein 

Wenn man sich Gedanken darüber macht, welche Server man verwenden will, so muss man sich über den Umfang der benötigten Infrastruktur im Klaren sein.

Die meisten Produkte unterstützen die APIs zur HTML-Generierung, d,h Servlets und JSPs. Wesendliche Teile der JDBC API sind schon im grundlegenden JDK enthalten, und die JDBC 2.0 Extensions, die u.a das für Server-Anwendungen wichtige Connection Pooling definieren, lassen sich nötigenfalls nachrüsten. Java Mail kann ebenfalls problemlos (und kostenlos) von der Sun Website nachinstalliert werden. JAT ist weitgehend transparent für die Anwendung und vor allem da wichtig, wo die Koordination verschiedener Datenhaltungssysteme notwendig ist.

Somit bleiben die Enterprise JavaBeans (EJB) übrig. Einer der unvermeidbaren Fragen in der (objektorientierten) Anwendungsentwicklung ist die nach der Behandlung der Objekt-Persistenz, d.h danach , auf welche Art und Weise die im Programm verwendeten Objekte und Daten auf die Datenhaltung abgebildet werden. Das Spektrum der Lösungen reicht vom direkten Datenzugriff via JDBC und SQL bis hin zu anspruchsvollen Mapping-Framework, die eine weitgehend transparente Abbildung zwischen Objekten und Datenbank-Tabellen realisieren. Die EJB-Spezifikation berücksichtigt genau diesen Aspekt der Persistenz in Form von sogenannten „Entity Enterprise JavaBeans“. Seit der Version 1.1 verlangt die Spezifikation, dass jeder EJB-konforme Server auch sogenannte „Container Managed Persistence“ anbieten muss, d.h die automatische, transparente Abbildung der EJBs auf eine persistente Datenhaltung. Leider ist das Abbildungsmodell in der Version 1.1 sehr primitiv, erst die Version 2.0 der EJB-Spezifikation läst Hoffnung keimen.

Per Definition sind EJB verteilte Objekte, was einen erheblichen Laufzeit-Overhead beim Methodenaufruf mit sich bringt. Diesen Nachteil nimmt man aber gern in Kauf, wenn man die Verteilungseigenschaften von EJBs nutzen will. Ein weiterer Vorteil liegt in dem EJB-Komponentenmodell und der deklarativen Transaktionsbehandlung. So muss man sorgfältig abschätzen, ob für ein Projekt diese Eigenschaften in Frage kommen oder ob der Aufwand dem Nutzen unterliegt.

3. Was muss ein J2EE-Umgebung unterstützen?

3.1 Komponententypen

Wenn man von der J2EE-Spezifikation 1.3 ausgeht, ergeben sich vier Typen von Komponenten, die von J2EE-kompatiblen Applikation Server unterstützt werden müssen:

• Applikation Clients: Das sind typischerweise Programme mit graphischem User-Interface, die auf dem Desktop Computer beim Anwender läuft.
• Applets: Dieses sind GUI-Komponenten , die von einem Web Server in den Web Browser beim Anwender geladen und dort ausgeführt werden.
• Servlets, JavaServer Pages (JSP), Filter und Web Eventlistener: Diese werden als Web-Komponenten bezeichnet und serverseitig ausgeführt.
• Enterprise Java Beans: Sie repräsentieren typischerweise die Geschäftslogik einer Anwendung und werden ebenfalls Serverseitig ausgeführt.

Auf Datenbankschemata, gegebenenfalls Stored Procedures oder eventuell Scripten für die Erstellung von Initialdatenbeständen, wird in der J2EE-Spezifikation nicht näher eingegangen. Sie sind aber ebenso Bestandteil einer Anwendung.

3.2 Container

Für die oben aufgeführten Komponenten gibt es unterschiedlichen Support durch den J2EE Server. Der J2EE Server verwaltet verschiedene Container, die eine Java-kompatible Laufzeitumgebung darstellen und stellen ihnen Dienste wie Security oder Transaktionsmanagement zur Verfügung. Es gibt Komponenten, die auf den J2EE Server deployed, von ihm gemanaged und ausgeführt werden. Dazu gehören die EJB- und Web-Komponenten. Daneben gibt es Komponenten, die zwar auf den Server deployed und von ihm gemanaged, aber nicht ausgeführt werden. In diese Gruppe gehören Applets. Die dritte Kategorie umfasst Komponenten, deren Deployment und Management derzeit nicht vollständig beschrieben sind, wie die Client Applikation.

Die Dienste für Komponenten werden durch die Container bereitgestellt, die ihrerseits auf dem J2EE Server basieren. Zu diesen Diensten gehören unter anderem, wie schon erwähnt, das Transaktionsmanagement, das Secuitymanagement, der Zugriff auf Datenbanken, die Bereitstellung von XML-Parsern oder der Mailzugriff. Eine Komponente greift niemals direkt auf eine andere zu, sondern nur über die definierten Protokolle und Schnittstellen. Somit hat der Container die Möglichkeit, sich transparent um Dinge wie Securitychecks oder das Management von Transaktionen zu kümmern.

Zu den folgenden Containertypen, die Dienste für die jeweiligen Komponenten zur Verfügung stellen, kann man den J2EE-Server durch Ressource Manager-Driver erweitern.

Ressource Management-Driver sind Systemkomponenten, die die Verbindung zu externen Ressourcen erlauben:

·        EJB Container für Enterprise JavaBeans

·        Web Container für Web-Komponenten

·        Applikation Client Container

·        Appletcontainer

3.3 J2EE Infrastruktur

Vor den zusammenbringen der entwickelten Komponenten und den Einbringen in die Zielumgebung muss diese erst bereitgestellt bzw. analysiert werden.

Abbildung 1: J2EE-Architektur als OpenSource Lösung

Um zu entscheiden, wie die Infrastrukturkomponenten auf die zur Verfügung stehende Hardware abgebildet werden, sind die zu erwartenden Last und die Anforderungen an die Verfügbarkeit zu beachten. Zu den Infrastrukturkomponenten gehören:

• Die Verschiedenen Clientvarianten
• Der Tomcat Server und seine einzelnen Container
• Der JBoss EJB Server und sein EJB-Container
• Das Enterprise Information System in Form des MySQL Servers
• Und Mail oder Messaging Systeme

3.3.1 Clustering, Loadbalancing und Failover

Drei zentrale Begriffe, die im Zusammenhang mit dem Betrieb von Web Application Servern immer wieder auftauchen, sind Clustering, Loadbalacing und Failover. Unter Clustering ist die Zusammenschaltung von mehreren Servern zu einem Verbund zu verstehen, meistens zum Zweck der Realisierung der im folgenden beschriebenen Eigenschaften

• Load Balancing: (zu deutsch „Lastverteilung“) bedeutet, dass eingehende Requests von einer zentralen Instanz auf die verschiedenen im Cluster verfügbaren Server so verteilt werden, dass eine gleichmäßige Auslastung der Server gewährleistet ist. Loadbalancing kann in Software oder Hardware erfolgen. Große Websites nutzen meist Hardware-Loadbalancer, da hier Geschwindigkeit und Ausfallsicherheit besonders wichtig sind.
• Failover: bedeutet, dass beim Absturz eines Servers dessen Stelle von einem anderen eingenommen wird, ohne dass die laufende Verarbeitung unterbrochen wird. Dies bedeutet insbesondere, dass Session-Informationen, die den Zustand einer noch nicht abgeschlossenen Benutzer-Interaktion enthalten (z.B. Inhalt des Warenkorbes, aktuelle Seite in einer Liste), auf den neuen Server automatisch und für den Benutzer unbemerkt übertragen werden.

3.3.2 Verteilung der Applikation im Cluster

Die Verteilung der Infrastrukturkomponenten hat Einfluss auf die Gestaltung des Packaging. Mit Packaging ist hier das Strukturieren der Pakete der Applikation in Bezug auf die Entwicklung eines Verteiltensystems gemeint. 

Man kann sich dabei zwei sehr extreme Konfigurationen vorstellen:

1. Bei der ersten Variante handelt es sich vielleicht um eine Applikation, bei der in der Anfangsphase keine besonders hohe Last erwartet wird und die Anforderung an die Verfügbarkeit ebenfalls noch im Rahmen bleibt. Man möchte die Applikation aber trotzdem auf Basis der J2EE-Architektur erstellen, um für zukünftige Anforderungen gewappnet zu sein. In der Startphase wäre damit ein Rechner ausreichend, bei welcher der in Tomcat integriertet Web Server zum Einsatz kommt. Auf dem selben Rechen läuft auch der EJB Server JBoss und die MySQL Datenbank. So kommt man mit einem Rechner aus.

Im Laufe der Zeit entwickelt sich die Anwendung zu einer wichtigen unternehmenskritischen Applikation, die eine hohe Last bewältigen und nahzu ständig verfügbar sein muss.

2. Damit sind wir bei der zweiten Variante, die in der Abbildung 2 dargestellt wird. Man benötig nun mehrere Server. Dahinter werden sowohl die Web Server(Tomcat) als auch die EJB-Container(JBoss) auf jeweils einem Cluster mit mehreren Maschinen betrieben. Was Sinn macht, wenn der Web Layer anders als der EJB Layer skaliert ist. Dazu würde man den Messaging System auch eine eigene Hardware spendieren. Die Datenbank läuft in der Regel sowieso auf einem separaten  Rechner.

Abbildung 2: J2EE Cluster

Wie man sich vorstellen kann, sieht das Packaging in den zwei Varianten unterschiedlich aus. Bei der ersten Variante würde man mit einem Enterprise Archive auskommen, das vielleicht sogar die statischen Web-Inhalte umfasst, da der im J2EE Server vorhandene Web Server verwendet wird. Bei der zweiten Variante hingegen müsste man die Applikation so aufteilen, dass die Funktionsgruppen mit hoher Last einen eigenen EJB oder Web Server bekommen. Durch das Konzept des Verteiltensystems können dann die Komponenten der Applikation untereinander ihre Funktionalitäten nutzen und erreichen somit eine bessere Performanz.

Diese zwei extremen Konfigurationen zeigen schon, dass J2EE-Applikationen auf einer sowohl vertikal als auch horizontal gut skalierbaren Architektur aufbauen. Ein wichtiger Punkt ist gegebenenfalls auch die Einbindung in eine vorhandene Security Domain.

Welche konkreten Gestaltungsmöglichkeiten bestehen, hängt stark vom J2EE Server ab.

3.4 Module

Die Erstellung einer J2EE-Applikation beginnt mit der Programmierung der einzelnen Komponenten. Typgleiche Komponenten können dann mit ihren Deploymentdescriptoren zu Module zusammengebaut werden. Deploymentdescriptoren geben den Deployer Informationen darüber, welche externen Resourcen (Datenbanken, Messagedestination, …), welche Sicherheitsanforderungen oder Umgebungsvariablen benötigt werden. Es gibt folgende Typen von Modulen:

• Enterprise Java Beans JAR Files: enthalten eine oder mehrere Entitybeans oder Sessionbeans. Die Komponenten laufen im EJB Container.
• Web-Applikation WAR Files: enthalten eine Web-Applikation mit JSPs, Servlets, Filter, Web Listener und statische Inhalte. Die Web-Applikation läuft in Web-Container.
• Applikation Cient JAR File: enthalten einen Standalone-Java-Applikation.
• Resource Adapter RAR File: enthalten Java-Klassen und Libraries.

Eine J2EE Server Infrastruktur muss die Module, einzeln oder in ein Enterprise Archive(EAR) verpackt, verarbeiten können. Auf die Details des Packaging und des Deployment soll nicht weiter eingegangen werden, da sich der Vorgang von Server zu Server unterschiedlich darstellt.

4.Tomcat, JBoss und MySQL

4.1 Tomcat 4.0

Um Java-Servlets und JSPs auf einem Rechner ausführen zu können, braucht man eine passende Engine, die mit den Servlets umgehen kann. Tomcat ist so eine Engine.
Tomcat ist nicht irgendeine Engine, sondern die Referenzimplementierung von der Java Server Pages (JSP) und Servlet Spezifikation.

Wie in Abbildung 1 zu sehen ist, dient Tomcat in dieser Beispiel Architektur nicht nur als JSP und Servlet-Engine, sondern auch als Webserver. Natürlich besteht die Möglichkeit, noch einen Webserver vor die Engine zu positionieren, hier sei der OpenSource Webserver Apache genannt.

4.1.1 Architektur

Tomcat 4 besteht aus dem Servlet Container Catalina und der JSP Engine Jasper. Die neue Catalina-Architektur stellt den Clients mehrere Services zur Verfügung. Der Client kann über verschiedene Connectoren mit den Kommunikationsprotokollen http, https, AJPV13 oder Warp auf den Service zugreifen. In einer Java VM können verschiedene Web-Applikationen mit unterschiedlichen Konfigurationen aufgesetzt werden. Die Unterstützung für einen Application Service Provider sind also optimal. Dies ist sicherlich eine sinnvolle Design-Entscheidung bei der Flut von zu erwartenden Dienstleistungsangeboten, die im Zuge der Web-Service-Strategien entstehen werden. Tomcat wird als Basis für die SunOne Web-Service-Strategie genutzt. Jeder Tomcat-Service wird durch eine Engine mit mehreren Connectoren realisiert, siehe Abbildung 3. Die Engine bestimmt den richtigen Host bei jeder Anfrage. Der Host hat die Aufgabe, den Context auszuwählen und dann für die Abarbeitung des Requests mit der richtigen Ressource Servlet, JSP, SSI oder CGI zu sorgen.

Abbildung 3: Catalina Container-Architektur

Die eigentlich Bearbeitung einer Anfrage an einen der Connectoren wird durch eine Container-Hierarchie des Services via Pipelines geleitet. Die oberste Ebene ist die Engine, die eine Anzahl von Host Containern beherbergt. Die Engine leitet alle Anfragen an einen Default-Host weiter, wenn die Anfragen keine exakte Information zum Host enthalten. Für alle Hosts lassen sich Konfigurationen für Logging, das Autorisierungs-Realm oder Request-Filter (Valve) angeben. Jeder Host hat einen Namen und eine Liste von Aliasnamen. Jeder Host kann über ein eigenes Applikationsverzeichnis verfügen. Es ist möglich, unter verschiedenen Hosts unterschiedliche Versionen einer Applikation in einem Server zu betreiben.

Der Tomcat 4 ist eine vollständige Servlet 2.3 und JSP 1.2 Implementierung. Einen Beweis der Kompatibilität mit den Spezikationen kann mit der Testumgebung JakartaWatchdog 4 innerhalb weniger Minuten erbracht werden. Die Jasper Engine hat erhebliche Fortschritte gemacht. Es ist nur ärgerlich, dass die anderen Anbieter diesen Spezifikationstest ignorieren.

4.2 JBoss

JBoss ist ein OpenSource Projekt der JBoss-Group. Es handelt sich dabei um einen vollständig in Java implementierten Enterprise JavaBeans Applikations-Server, der modular aufgebaut ist. An der Entwicklung des JBoss EJB Applikation Server sind mehr als 1000 Entwickler weltweit beteiligt.

In seinen Anfängen nannte sich das Produkt EJBoss. Nachdem sich jedoch herausstellte, dass EJB ein geschützter Namen von Sun ist, wurde der Name EJBoss in JBoss umgewandelt. Der EJB-Server JBoss ist 100% in Java geschrieben und steht somit für alle Betriebssysteme zur Verfügung. Die Homepage von JBoss bietet diverse Download-Typen abhängig vom jeweiligen Betriebssystem an. Die Windows-Version des Servers wird mit einem einfachen Installationsprogramm geliefert.

In der Abbildung 4 ist das Entwickeln einer EJB-Applikationskomponente unter JBoss stichpunktartig Schritt für Schritt erläutert.

Abbildung 4: Entwicklungsprozess von EJB Anwendungen mit JBoss

Wie schon obern erwähnt, wollen wir an dieser Stelle nicht näher auf die Details des Packaging und des Deployment eingehen. Auf der JBoss Homepage finden sich des weiterem alle Informationen, die für die Installation des Servers und das Deployment einer Applikation wichtig sind.

4.3 MySQL

Die Open Source-Software MySQL ist ein Relationales Datenbank-Management-System (RDBMS). Aufgrund seiner einfachen Handhabung und Schnelligkeit wird es für den Einsatz im Rahmen kleinerer und mittlerer Projekte sehr gerne gewählt. Vor allem in der PHP-Szene ist MySQL mittlerweile de facto Standard.

MySQL versteht einen Grundstock von SQL-Statements. Sie sind allen SQL-RDBMS gemeinsam. Die wichtigsten vier sind INSERT, SELECT, DELETE und UPDATE. Daneben hat beinahe jedes RDBMS eine ganze Reihe eigener Funktionen an Bord, die innerhalb solcher Statements verwendet werden. Der Einsatz im Rahmen eines SELECT ist dabei der häufigste Fall. MySQL bietet unter anderem arithmetische, logische, mathematische sowie Datums-, String- und Kontrollfluß-Funktionen. Sie dienen dazu, bei SQL-Abfragen die Datensätze schon auf der Datenbank-Ebene zu verändern oder vorzuverarbeiten. Dadurch werden die Daten in die benötigte Form gebracht.

MySQL repräsentiert in dieser Applikation das Enterprise Information System. Da bei der Programmierung der Datenbankzugriffe unter Java ( JDBC ) die Integrität der Datenbank ohnehin in Händen des Programmierers liegt sollte, ist es nicht von Nachteil, dass MySQL nicht alle Integritätsbedingungen behandelt.

5. Glossar

6. Quellen

6.1 Internet

http://www.ssw.uni-linz.ac.at

http://www.ideenreich.com

http://www.mysql.com

http://www.jboss.org

http://www.javamagazin.de

http://www.derentwickler.de

http://www.java.sun.com

http://jakarta.apache.org

6.2 Literatur

Java Magazin Ausgabe 08.2000

Java Magazin Ausgabe 11.2001

Java Magazin Ausgabe 12.2001

Java Magazin Ausgabe 03.2002

Professional Java server programming J2EE Edition (Wrox Press 2000)