J2EE und Persistenz: Ein heißes Eisen (Teil I)

Mit dieser Artikelserie packen wir ein "heißes Eisen" an. Denn wir wollen die Persistenzstrategie in einem größeren, aktuellen Softwareprojekt, das auf J2EE Technologie basiert, darstellen. Das berührt die "uralte" Frage – uralt in den Zeitmaßstäben der Softwarebranche gerechnet – "Wie kommen die Daten aus der Datenbank in die Objekte des Hauptspeichers?"

Im ersten Beitrag steht die Entscheidungsfindung im Mittelpunkt. Wir sehen uns an, wie die Ausgangslage war, welche Alternativen für eine geeignete Persistenzstrategie zur Auswahl standen und wie bzw. anhand welcher Kriterien eine Entscheidung getroffen wurde.

Ausgangslage

In dem Softwareprojekt hat ORDIX zusammen mit dem Kunden ein sehr ehrgeiziges Ziel verfolgt: Das Modernisieren einer klassischen Client Server Anwendung zur Auftragsbearbeitung für Außendienstmitarbeiter eines großen Serviceunternehmens.

Das ließ sich nur mit einer kompletten Neuarchitektur realisieren. Aus so genannten "Fat Clients" mit komplexer GUI und Geschäftslogik auf Laptops sollten "Thin Clients" werden, die auf Kleingeräten (PDA, Handheld) mit minimaler Systemausstattung ablauffähig sind.

Dafür war es notwendig, nahezu die gesamte Geschäftslogik der alten Clients zu bündeln und auf die Serverseite zu verschieben. Und da, wo Geschäftslogik auf Serverseite gefragt ist, kommt man "ruckzuck" zu Geschäftsobjekten – "Auftrag", "Benutzer", "Leistung", "Produkt", etc. Die müssen natürlich dauerhaft gespeichert, d. h. "persistent" gemacht werden.

Rahmenbedingungen und Projektvorgaben

Zu Anfang setzten wir uns mit allen Projektmitgliedern zusammen, als da wären: Entwickler, Architekt, Projektleiter, QS Beauftragte und wer sich sonst noch so im Projektumfeld tummelte. Die technischen Rahmenbedingungen wurden zügig geklärt. Durch eine Vorgabe des Kunden hatte der Borland Enterprise Server 5.2 (BES), der im JBuilder Enterprise Edition 9 enthalten ist, überraschenderweise als Application Server die Nase vorn (wer dazu mehr wissen will, dem sei unsere Reihe Application Server im Vergleich empfohlen – Anmerkung der Redaktion). Den Datenbank Part sollte Oracle in der Version 9.2i ausfüllen. Zudem kristallisierte sich die grundlegende Schichtenarchitektur nach klassischem Muster für J2EE Anwendungen sehr schnell heraus.

In nahezu allen ernst zu nehmenden J2EE Anwendungen – also auch in unserem neu zu erstellenden System – existiert in der Architektur eine Schicht oder ein abgrenzbarer Bereich für die Persistenz, der als Nahtstelle zwischen der eigentlichen Geschäftslogik und der relationalen Datenbank fungiert (siehe Abbildung 1).

Abb. 1: Schichtenarchitektur mit Hervorhebung der Persistenzlogik, die den "Business Layer" mit dem "Data Layer" verbindet.

Alternativen für die Persistenzlogik

Alsdann ging es an die Aufstellung der Möglichkeiten, welcher Speicherstrategie innerhalb der Serverimplementierung der Vorzug zu geben sei. Es kristallisierten sich vier Alternativen heraus, die prinzipiell in die engere Auswahl kamen (eine lose Aufzählung ohne Anspruch auf Vollständigkeit):

1. Stateful Session Beans und JDBC

Stateful Session Beans (SFB) spielen in diesem Ansatz die Rolle der datenhaltenden Objekte. Per JDBC (Java Database Connectivity) hat der Entwickler selbst dafür zu sorgen, wie die Daten aus der Datenbank in die Java Objekte gelangen. Und er muss definieren und entscheiden, wann das zu geschehen hat. Der Ansatz entspricht der Philosophie "Ich mache mal lieber alles selbst, dann hab ich wenigstens alles in der Hand".

Das kann aus vielerlei Gründen problematisch sein. Ein Grundsatz der Programmierung für J2EE Anwendungen lautet: "Nutze die Technologie und Standards, die dir zur Verfügung stehen und setze sie für die Zwecke ein, für die sie gemacht wurden". Und Session Beans sind in der J2EE Philosophie definitiv nicht für die Datenhaltung und für Persistenzaufgaben vorgesehen.

2. Entity Beans mit BMP

In der Architektur von großen, typischen J2EE Anwendungen sollen nach den Vorstellungen von SUN, dem Initiator und Taktgeber der J2EE Spezifikation, die datenhaltenden Entitäten von sogenannten "Entity Beans" repräsentiert werden.

Das sind Java Objekte, die bestimmte Konventionen einhalten und vorgegebene Interfaces implementieren müssen, damit der Application Server sie ordentlich verwalten kann. Das gilt im Übrigen auch für alle anderen Arten von Software Komponenten, die im Application Server in spezialisierten "Containern" residieren – seien es JSP und Servlets in Web-Containern oder Enterprise Java Beans (Session-, Entity-, Message Driven Beans) im EJB-Container.

Der Container entscheidet bei Entity Beans in jedem Fall darüber, wann Daten zu laden bzw. zu speichern sind. Über das wie kann noch explizit nachgedacht werden. Bei Entity Beans mit BMP (Bean Managed Persistence) ist der Entwickler programmatisch dafür verantwortlich. Er hat mit Hilfe von JDBC dafür zu sorgen, dass Datenbankinhalte in die passenden Attribute der Entity Beans "geschaufelt" werden. Die Entity Bean kann also einen Zustand annehmen bzw. umgekehrt den Zustand auch wieder wegschreiben.

3. Entity Beans mit CMP

Mit der Version EJB 2.0 wurde die Alternative Entity Beans mit CMP (Container Managed Persistence) sehr stark um viele nützliche und zuvor schmerzlich vermisste Eigenschaften erweitert. Der manchmal etwas umständlichen Benutzung von Entity Beans mit BMP wurde damit eine echte, komfortablere Alternative zur Seite gestellt.

Bei diesem Ansatz kümmert sich der EJB-Container auch darum, wie die persistenten Daten von bzw. in die entsprechenden Attribute gelangen. Das Mapping von Entity Bean Attributen auf Datenbankfelder geschieht deklarativ in sogenannten DDs (Deployment Deskriptoren), die in XML Dateien abgelegt sind.

Will man die volle Bandbreite der J2EE Möglichkeiten in diesem Bereich nutzen, kann auch CMR (Container Managed Relationships) Verwendung finden. Bei CMR liegt auch das Management von Beziehungen (1:1, 1:n, m:n) in der Verantwortung des Containers.

4. JDO

JDO steht für Java Data Objects. Es handelt sich um eine noch relativ neue Spezifikation von SUN, die die prinzipiellen Schwierigkeiten des Object Relational Mapping aufgreift und Lösungsvorschläge bietet.

Dabei wurde sehr viel Wert darauf gelegt, die sehr mächtigen Konzepte der Objektorientierung wie Vererbung und Polymorphie möglichst umfassend umzusetzen. Hersteller von JDO Implementierungen bieten neben der reinen Umsetzung der Spezifikation häufig auch noch Zusatztools an und sprechen von einer nahtlosen Integrationsmöglichkeit in J2EE Umgebungen.

Entscheidungskriterien

In mehreren, teilweise kontrovers geführten Diskussionsrunden, und nachdem wir einem JDO Hersteller die Möglichkeit gaben, sein Tool vorzustellen, wurden dann die maßgeblichen Kriterien, nach denen eine Entscheidung zu treffen war, aufgestellt:

Kosten

Die Borland Produkte (BES und JBuilder) waren von vornherein gesetzt und damit "automatisch" im Projekt-Budget verplant. Es hätte sehr gewichtiger Gründe bedurft, um für die Persistenzkomponente ein separates Produkt mit eigenen Anschaffungs- und Lizenzkosten zu wählen. Das wäre bei der Verwendung einer JDO Implementierung nötig geworden, so dass für diese Alternative sehr schnell die Luft dünn wurde.

Abb 2: Entscheidungsmatrix mit Bewertungszahlen.

Zu erwartende Komplexität

Bei diesem Punkt halfen die Erfahrungen der ORDIX AG weiter, die in vielen Kundenprojekten immer wieder mit dieser Thematik konfrontiert ist. Des Weiteren hielten wir uns – d. h. das Projektteam, bestehend aus Mitarbeitern des Kunden und der ORDIX – an Empfehlungen aus dem Hause Borland, die der Variante "Entity Beans mit CMP" ein gutes Zeugnis ausstellten.

Im Projektvorfeld bestätigte sich in RAP (Rapid Prototyping) Versuchen der Eindruck, dass man mit CMP und CMR zu guten Ergebnissen kommen kann. Aber auch die Eindrücke und Stellungnahmen, die wir im Projekt zu JDO sammelten und bekamen, ließen ordentliche Ergebnisse für dieses Kriterium erwarten. Dies spielgelte sich auch in der abschließenden Bewertungsmatrix wieder (siehe Abbildung 2).

Zu erwartende Qualität der Persistenzlösung

Dieser Punkt war am schwierigsten zu beantworten und einzuschätzen. In einem Vorprojekt, das beim gleichen Kunden ebenfalls in Java realisiert war, hatte sich gezeigt, dass Eigenentwicklungen in diesem zentralen Bereich ab einer gewissen Größe sehr leicht zu Problemfällen werden können. Das hört und liest man häufig in Erfahrungsberichten zu größeren Softwareprojekten und kann von uns auch nur bestätigt werden. Dadurch rutschte die Alternative "Stateful Session Beans mit JDBC" auch aus der engeren Wahl.

Entwicklungszeiten

Wer den Alltag in größeren Softwareprojekten kennt, weiß, was jetzt kommt. Wie nicht anders zu erwarten, sahen auch wir uns mit einem, um es milde auszudrücken, ehrgeizigen Terminplan konfrontiert. D. h. binnen eines halben Jahres musste alles fertig sein.

Das bedeutete, dass die Entscheidung für die Persistenzfrage noch brisanter wurde, denn eine Fehlentscheidung in diesem zentralen Segment hätte projektgefährdenden Charakter gehabt.

Und eine Umkehr auf halbem Weg oder ein Neuanfang in der Projektmitte hätte ebenfalls katastrophale Folgen nach sich gezogen und musste unter allen Umständen vermieden werden. Es deutete sich bei JDO ein nicht zu unterschätzender Zeitfaktor für die reine Einarbeitung an, was sich in der Bewertung negativ auswirkte.

Entscheidungsmatrix

Nachdem die Alternativen und Kriterien ausgearbeitet und formuliert waren, musste eine Entscheidung gefällt werden. Ein probates Hilfsmittel zur transparenten und nachvollziehbaren Entscheidungsfindung stellt die Entscheidungsmatrix dar.

In die Entscheidungsmatrix trägt man nach bestmöglichem Ermessen für die Frage: "Wie gut erfüllt die Alternative A das Kriterium K?" eine Bewertungszahl in die Zelle [K,A] ein. Dabei sollte Folgendes eingetragen werden:

• eine 0, falls keine oder eine neutrale Antwort vorliegt
• eine negative Zahl bei negativer Antwort
• eine positive Zahl bei positiver Antwort

Bei besonders ausgeklügelten Verfahren können die Spalten zusätzlich noch unterschiedliche Gewichtungsfaktoren bekommen. Das ist in unserem Fall aber nicht passiert. Um nun eine Maßzahl für die Eignung einer Alternative bezüglich der Entscheidungskriterien zu erhalten, summiert man die Bewertungszahlen einer Zeile auf und trägt sie in die Spalte Bewertung ein.

Entscheidungsfindung

Das haben wir für unsere Problemstellung praktiziert. Das Ergebnis stellt Abbildung 2 in einer übersichtlichen Tabelle dar. Wie in den vorhergehenden Abschnitten schon angedeutet, konnte die Entscheidung nur zwischen den Alternativen Entity Beans mit CMP und JDO fallen.

Sehr ungünstig für JDO wirkt sich der Faktor Kosten aus. Aber auch die zu erwartenden, längeren Einarbeitungszeiten in diese für die meisten Projektmitglieder völlig neue Technologie wirkten sich in der Bewertungsmatrix negativ aus.

So haben wir uns auf die Persistenzstrategie "Entity Beans mit CMP, CMR" festgelegt und sind mit diesem Ansatz zuversichtlich in die Design- und Umsetzungsphase gestartet. Die Größenordnung des Datenmodells umfasst ca. 70 Tabellen im relationalen Schema mit etwa ebenso vielen Beziehungen untereinander.

Die erste Designphase und die Initialisierung des Datenmodells erfolgte mit Together Control Center. Das ehemals eigenständige Analyse- und Designwerkzeug ist inzwischen in JBuilder Enterprise Edition 9 fest integriert.

In der eigentlichen Realisierungsphase wurde dann ausschließlich mit dem JBuilder weitergearbeitet. Auch die Änderungen und Erweiterungen am Datenmodell, d. h. an den Entity Beans, erfolgten in der Phase im EJB-Designer, einem spezialisierten Designwerkzeug der JBuilder IDE (Integrated Development Environment).

Wie nicht anders zu erwarten war, gab es während der Projektphase kritische Momente, insbesondere als die "CMP Engine" des BES einen sehr hässlichen, schwer nachvollziehbaren Fehler zeigte. Der wurde nach sehr mühsamer und anstrengender Suche, die in der Hauptsache von unserem Projektteam geleistet wurde, dann vom Application Server Hersteller behoben.

Fazit

Obwohl sich die J2EE Anwendung, auf der dieser Artikel basiert, beim Kunden noch nicht im realen Einsatz befindet und man daher noch nicht von absoluter Praxistauglichkeit sprechen kann, zeichnet sich doch eine ordentliche Stabilität der gewählten Persistenzlösung "Entity Beans mit CMP" ab. Explizite Lasttestszenarien und -durchläufe lassen auch im Hinblick auf die Performance zufriedenstellende Ergebnisse erwarten.

ORDIX hat während des gesamten Projektverlaufs in allen wichtigen Phasen tatkräftige Unterstützung geleistet und gerade beim Thema Persistenz geballtes Know-how und Erfahrung eingebracht. Ein nachfolgender Artikel in Ausgabe 2/2005 wird die Umsetzungsphase und die eigentliche Technologie noch etwas genauer in Augenschein nehmen.

Dr. Hubert Austermeier (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen