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

Vor genau einem Jahr stellten wir ein Kundenprojekt vor, in dem es um die Fragestellung ging, mit welcher Strategie und Technologie die Persistenzschicht in einer J2EE-Anwendung umzusetzen sei. Nun greifen wir das Thema wieder auf und beleuchten die Projekterfahrungen.

Teil I beleuchtete die Entscheidungsfindung: Wir betrachteten die Ausgangslage, welche Alternativen für eine geeignete Persistenzstrategie zur Auswahl standen, nach welchen Kriterien eine Entscheidung getroffen wurde, um den Zugriff auf Geschäftsdaten in der relationalen Datenbank Oracle 9i aus der Business Logik heraus zu vollziehen. Damals fiel die Entscheidung auf den Einsatz von Entity Beans im Zusammenspiel mit Container Managed Persistence (CMP) und Container Managed Relationship (CMR).

Entwurfsphase

Am Anfang aller Bemühungen stand das Datenmodell. Wie in Teil I beschrieben, waren die Produkte aus dem Hause Borland gesetzt. So war auch schnell klar, dass möglichst die mitgelieferten Werkzeuge für alle Aufgabenstellungen sowohl in der Entwurfs- als auch in der Realisierungsphase zu nutzen seien.

Datenmodellierung mit Together Control Center

Der technische Architekt des Projektteams und der fachliche Ansprechpartner setzten sich zusammen und konstruierten einen ersten Entwurf für das Datenmodell. Als Werkzeug kam dabei Together Control Center (TCC) zum Einsatz, das im Entwicklerbaukasten von JBuilder Enterprise Edition enthalten ist.

Die Datenmodellierung mit TCC ging zunächst sehr zügig voran, da es sich für allgemeine Modellierungstätigkeiten um ein erwiesenermaßen gutes und geeignetes Werkzeug handelt. Auch unter den Diagrammtypen findet man alle wichtigen Vertreter, und so war es folgerichtig, dass wir mit einem ER-Diagramm starteten.

Die Besonderheit und Stärke von TCC besteht darin, dass es eine direkte Kopplung von Modellinformation und Sourcecode bzw. Implementierungscode gibt. In den meisten Fällen speichert TCC Modelle und Diagramme nicht in eigenen Repository Dateien, sondern direkt als Source Files. Und so waren wir guter Dinge, zumal ein spezieller Application Server als Zielplattform eingestellt werden konnte. Da es sich inzwischen um ein Borland Produkt handelt, verwundert es kaum, dass auch der Borland Enterprise Server (BES) in der Version 5.1 angeboten wurde (neben Web-Sphere, WebLogic und einem generischen Application Server).

Als dann das Datenmodell anwuchs, häuften sich ab einer gewissen Größe und Komplexität die Probleme, die sich darin äußerten, dass sich der generierte Code nicht übersetzen ließ. Oder, noch schlimmer, zu Laufzeitfehlern führte. Nach vielen Krisensitzungen und Unterstützungsanfragen Richtung Borland haben wir – zugegebenermaßen schweren Herzens – die Reißleine gezogen und TCC aus dem Werkzeugkasten verbannt.

Neuauflage der Datenmodellierung mit JBuilder

Wir hatten "schöne" und inzwischen auch vollständige Diagramme und Modelle und so setzten wir uns hin und erstellten die gesamte Datenschicht im JBuilder neu. Auch JBuilder bietet eine Unterstützung an, den so genannten EJB-Designer, der zwar nicht ganz so komfortabel wie TCC ist, dafür aber korrekte Implementierungen erzeugt. Abbildung 1 zeigt einen Ausschnitt aus seiner Diagrammdarstellung (aus Datenschutzgründen sind die Einträge unkenntlich gemacht).

Selektiert man eine Entity Bean im EJB-Designer "klappt sie auf" und die Attribute und Methoden erscheinen. Es gibt einige vorgefertigte Methoden (ejbCreate, findAll, ...) und natürlich eigens definierte (auch diese sind hier unkenntlich gemacht). Über das Kontextmenü kann man Einstellungen vornehmen, wie den Typ eines Attributes oder die Art einer Beziehung ( 1:1, 1:n, n:m), die sich dann auf die Implementierung und die Deployment Deskriptoren (DD) auswirken.

Diese Neudefinition hat das Projekt ca. 4 Wochen Mehraufwand gekostet, aber mit solchen unliebsamen Überraschungen muss immer derjenige rechnen, der technologisches Neuland betritt.

Entity Beans und Deployment Deskriptoren

Entity Beans aus der EJB-Spezifikation waren, wie schon berichtet, auserkoren, die Rolle der datenhaltenden Objekte im Application Server zu spielen. Entity Beans sind spezielle Komponenten, die sich jeweils aus einer Reihe von Java Interfaces (zwei bis vier) und einer Java Implementierungsklasse zusammensetzen. Zusätzlich gibt es bei Entity Beans, genauso wie bei Session und Message Driven Beans, so genannte Deployment Deskriptoren.

DD sind XML Strukturen, in denen Eigenschaften der Komponenten beschrieben sind, die sich somit deklarativ einstellen lassen. So gilt z. B. bei einer Entity Bean, dass eine Instanz einer solchen Bean im Allgemeinen einem Datensatz einer Datenbanktabelle entspricht. In einem DD einer Entity Bean ist nun festgelegt, mit welcher Tabelle sie verbunden ist oder auch wie und welche Datenbankfelder auf welche Instanzattribute der Entity Bean „gemappt“, d. h. abgebildet sind.

Dass da natürlich Datenformate und -typen einzuhalten sind, kann sich jeder vorstellen. Oder was soll dabei herauskommen, wenn ein CLOB Feld einer Oracle Tabelle auf ein int Attribut von Java trifft? Es kracht, und zwar gewaltig. Auch das ist im Projekt hin und wieder versehentlich vorgekommen. Aber das sind die Sorte von Fehlern, die man gern hat, denn sie treten sofort zu Tage und sind schnell behoben. :-)

Daraus wird deutlich, dass den Deployment Deskriptoren eine sehr große Bedeutung zukommt und dass bei deren Gestaltung und Konfiguration äußerste Sorgfalt geboten ist.

In Abbildung 2 ist zur Veranschaulichung ein Teil der XML-Struktur eines DD einer sehr schlichten Entity Bean mit zwei Attributen zu sehen. Wir wollen uns nicht alle Einträge ansehen, aber einige sind doch recht interessant. Sehr wichtig im gesamten J2EE-Kontext ist der Name einer Entity Bean.

<entity>
 <ejb-name>UserSessionBean</ejb-name>
 <local-home>de.telekom.inca.ejb.entities.benutzer.UserSessionHome</local-home>
 <local>de.telekom.inca.ejb.entities.benutzer.UserSession</local>
 <ejb-class>de.telekom.inca.ejb.entities.benutzer.UserSessionBean</ejb-class>
 <persistence-type>Container</persistence-type>
 <prim-key-class>java.lang.String</prim-key-class>
 <reentrant>False</reentrant>
 <cmp-version>2.x</cmp-version>
 <abstract-schema-name>UserSessionSchema</abstract-schema-name>
 <cmp-.eld> <.eld-name>sessionid<
 <cmp-.eld> <.eld-name>anmeldezeitpunkt</.eld-name>
 <primkey-.eld>sessionid<
 <query>
       <query-method>
                   <method-name>.ndByBenutzer</method-name>
                   <method-params> <method-param>java.lang.String</method-param>
                   </method-params>
       </query-method>
       <ejb-ql>SELECT OBJECT(o) FROM
                   UserSessionSchema AS o, IN (o.benutzerBean) l WHERE l.benutzerid = ?1
       </ejb-ql>
 </query>
</entity>

Der Name stellt den Verweis dar, auf den an vielen Stellen des DD Bezug genommen wird. So z. B. bei den table-properties (sind nicht dargestellt) oder den relationships.

Vorgehensweisen, Rollenzuteilung und Erfahrungen

Sehr wichtig für das Gelingen mit Entity Beans war für uns, dass wir schon auf die Spezifikation EJB 2.0 bzw. 2.1 setzen konnten, sozusagen die „Gnade des späten Beginns“ hatten. Denn erst ab diesen Versionen ist die Technologie wirklich nutzbar. Die Einführung von Local Interfaces und damit von gesicherten CMR (Container Managed Relationships) gehören zu den entscheidenden Vorteilen, die man sich einhandelt.

In früheren Jahren (vor dem Jahr 2003), als EJB 1.1 aktuell war, waren Entity Beans doch eher von akademischem Interesse und weit von der Alltagstauglichkeit entfernt.

Weiterhin kann man sagen, dass die Umsetzung der Entity Bean Spezifikation im Borland Enterprise Server als gelungen zu bezeichnen ist und die „Persistence Engine“ im Hause Borland schon zahlreiche Optimierungsrunden gedreht hat, nicht zuletzt durch das Feedback aus dem Hause ORDIX sowie aus diesem Projekt.

Ein Vorteil von Entity Beans, der nicht so offensichtlich zu Tage tritt, soll hier etwas genauer beschrieben werden. In Projekten, in denen die Datenzugriffsschicht mit herkömmlichen Methoden (z. B. direkt per JDBC) erfolgt, besteht die Gefahr, dass sich alle Entwickler daran beteiligen und jeder sich gerade das zusammenbaut, was er braucht. Das führt bestenfalls zu nicht einheitlichem Sourcecode und auf jeden Fall zu einer Verteilung der einzelnen Datenzugriffe über den gesamten Sourcecode. Diese frühen Fehler führen später dann zu undurchschaubaren, äußerst komplexen Codefragmenten, die jeweils nur noch vom eigenen Autor verstanden werden.

Fazit

Die J2EE-Anwendung geht in den kommenden beiden Quartalen in den Wirkbetrieb. Bereits heute zeichnet sich eine ordentliche Stabilität der gewählten Persistenzlösung „Entity Beans mit CMP“ ab.

Explizite Lasttestszenarien und -durchläufe lassen auch im Hinblick auf Performance erste, gute Ergebnisse erwarten. ORDIX hat während des gesamten Projektverlaufs in allen wichtigen Phasen tatkräftige Unterstützung geleistet und insbesondere beim Thema Persistenz geballtes Know-how und Erfahrung eingebracht.

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

P.S.: Wir möchten an dieser Stelle auf das sehr verwandte und nicht minder spannende Thema „Hibernate“ verweisen, das unter Java/XML - Hibernate behandelt wird.

Seitenanfang

Seite drucken

Seite weiterempfehlen