Enterprise JavaBeans - Die 3. Generation

4 Entities
4.1 Das Problem mit der Persistenz (S.73-74)

Den Entities ist das umfangreichste Kapitel dieses Buches gewidmet, weil es sich hier um einen „Standard im Standard" handelt. Entities dienen einem völlig anderen Zweck als die zuvor beschriebenen Session Beans, nämlich der dauerhaften Ablage von Daten in Datenbanken, der so genannten Persistenz. Dieser thematisch deutlich andere Schwerpunkt sorgt für ein ebenso deutlich anderes Anwendungsmodell, wie sich noch zeigen wird. Die persistente Verwaltung von Entities erfolgt in SQL-Datenbanken nach detailliert festgelegten Abbildungsverfahren, deren Definition logischerweise vergleichbar umfangreich ist wie SQL selbst. In sehr einfachen Applikationen können Entities zwar auch mit einem höchst oberflächlichen Verständnis der Abbildung genutzt werden, so dass einem schnellen Einstieg nichts im Wege steht. Trotzdem sind Datenbankzugriffe häufig ein neuralgischer Punkt von Enterprise-Applikationen in Bezug auf das Antwortverhalten des Systems, daher wirken sich Verständnislücken und konzeptionelle Fehler in diesem Bereich oft besonders deutlich aus. Leser, die sich zunächst nur ein Grundverständnis aneignen wollen, können nach Kapitel 4.3 einen Schnitt setzen und sich mit den Themen O/R-Mapping, Entity- Beziehungen und der Abfragesprache später auseinandersetzen.

Bis zur Version 2.1 des EJB-Standards wurde die Persistenz über so genannte EntityBeans geregelt. Wie der Name vermuten lässt, bestand in diesem Konzept eine stärkere Verwandtschaft zu den übrigen Bean-Typen, als dies bei den mit EJB 3.0 neu geschaffenen Entities der Fall ist. Enge Verwandtschaft liest sich auf den ersten Blick gut, hat sich aber in der Praxis überhaupt nicht bewährt. Führt man sich die unterschiedlichen Verantwortlichkeiten der Bean-Typen vor Augen, wundert einen das nicht. Vereinfacht gesagt, repräsentieren Entities die Geschäftsobjekte, auf denen die in SessionBeans implementierten Geschäftsprozesse operieren. Die aus dieser Aufteilung resultierenden Anforderungen an die Bean-Typen bergen mehr Unterschiede als Gemeinsamkeiten, daher wurde mit den Entities erstmals ein valides Konzept für Persistenz-Management in den Standard eingeführt.

Pate stand hier übrigens nicht der konkurrierende Persistenzstandard Java Data Objects (JDO), sondern vor allem das OpenSource-Toolkit Hibernate. So ist es auch kein Wunder, dass die Persistenz-Implementierung des JBoss-Servers auf eben diesem Toolkit aufbaut, wie ein Blick in die Bibliotheken der Installation schnell verrät. JDO bleibt weiterhin parallel bestehen, sieht allerdings einer ungewissen Zukunft entgegen, weil die Spezifikation der EJB-Persistenz eine wichtige Forderung mit strategisch hoher Reichweite aufstellt:

Das Persistenz-Management muss vollständig auch außerhalb eines Application- Servers funktionieren!

Für den EJB-Entwickler ist dies vor allem ein Vorteil in Bezug auf Testbarkeit, aber für Leute ohne Bedarf an Client-Server-Architekturen entsteht dadurch schlicht ein neuer, leistungsstarker Standard für Persistenz – in welcher Umgebung auch immer. Dieser separate Standard heißt Java Persistence API (kurz: JPA) und ist tatsächlich so konzipiert, dass er auch ohne JEE-Umgebung leben kann. Schon in den Namen der Packages wird dies deutlich, denn hier taucht nirgends das sonst übliche javax.ejb auf, sondern die allgemeinere Bezeichnung javax.persistence. Das bereits erwähnte Toolkit Hibernate ist ein Beispiel für einen Anbieter, der auch außerhalb eines Application-Servers das JPA für die Java- Standardumgebung anbietet. Innerhalb eines Application-Servers angewendet, ist JPA gleichbedeutend mit dem Begriff „EJB-Persistenz", wobei die Mithilfe des Containers sich für den Entwickler durch verschiedene Automatismen sehr positiv bemerkbar macht. Wem die weiter oben erwähnte Verantwortlichkeitstrennung für Entities und Session Beans etwas quer im Magen liegt, der fühlt sich damit ganz zu Recht unwohl. Prozesse hier und Daten dort? Funktionen, die auf Daten operieren, statt interagierende Objekte mit Eigenschaften? Ist das denn überhaupt noch objektorientiert?

Nein, ist es nicht, jedenfalls nicht besonders, was durchaus in der Natur der Sache liegt. Der EJB-Standard wurde entwickelt, um Server-Komponenten einer Client-Server-Architektur zu definieren, die von einem potenziell ganz anders programmierten Client aufgerufen werden. De facto lassen sich EJBs zwar so richtig gut nur von EJB-Clients ansprechen, doch das grundsätzliche Konzept lässt auch andere Clients zu, die vielleicht ganz und gar nicht objektorientiert arbeiten. Aber auch bei Verwendung von EJB-Clients ist der Objektorientierung eine harte Grenze gesetzt, wenn über Rechnergrenzen hinweg kommuniziert wird. Hier können z.B. nur serialisierbare Objekte übertragen werden, was zu relativ „dummen" Objekten als Parameter jeglicher Remote-Operationen führt.