Ein Großteil der Java EE-Entwickler weltweit arbeitet wahrscheinlich gegenwärtig mit EJB 3.0. Die Nachfolgeversion ist noch nicht „business proved“, und die Vorgängerversion ist in der Entwicklung zu schwergewichtig. Auch wir bei Holisticon arbeiten mit der EJB 3.0-Technologie. Dankbar für jede Datei und Code-Zeile, die man nicht mehr schreiben muss, setzen wir schon seit geraumer Zeit nicht mehr auf den alten Standard EJB 2.1.
In meinem jüngsten Projekt musste ich allerdings eine Reise in die Vergangenheit machen, um eine Enterprise Java-Applikation zu migrieren. Nachfolgend sind Strategien und Techniken beschrieben, mit denen man schnell und effizient zu dem Ziel kommt, die Persistenzschicht auf JPA 1 anzuheben.
Projektspezifisches
Um einmal den Rahmen abzustecken, seien hier alle relevanten technischen Details des Projekts genannt.
Die Entity Beans waren vom Typ CMP (Container Managed Persistence) mit XDoclet. Home, Component Interfaces, die konkrete Entity Bean-Klasse, Value Objects und der Assembly Descriptor wurden generiert. Es existierte eine abstrakte Superklasse für jede Entity Bean, die die Attribute deklarierte und die XDoclet-Quelltextkommentare beinhaltete. Sie diente als Eingabe für XDoclet. Sehr vorbildlich. Aus viel (drei Klassen/Interfaces und eine XML-Datei) mache wenig (eine XDoclet-annotierte Klasse) mache viel (alles Notwendige, allerdings generiert).
Die Entity Beans müssen weg
…und das stimmt auch so. Mit dem JSR-220 wurden Entity Beans durch Persistent Entities abgelöst. Nun ist es so, dass ein guter Entwickler meist faul ist. Er scheut Fleißarbeit so sehr wie der Teufel das Weihwasser. Auch ich bevorzuge Automatisierungen. Im Projekt haben wir darauf verzichtet, Klasse für Klasse zu analysieren und neu zu schreiben, um dann Property für Property zu kopieren. Wir verwendeten Hibernate Tools, um aus der bestehenden Datenbank mittels Reverse Engineering die Persistent Entities zu erzeugen. Relationen werden korrekt erkannt und der Objektgraph entsprechend erzeugt.
Mit dem Entfernen der Entity Beans entfallen auch die Component Interfaces. Zu beachten ist hierbei, dass die Zugriffe auf die Persistenzschicht ausschließlich mit diesen arbeiteten, jetzt aber mit Persistent Entities umgehen müssen, die nicht auf „Local“ oder „Remote“ enden. Ein kleiner Trick hilft hier: Die Persistent Entities werden kurzfristig umbenannt und ggf. in das richtige Package der Component Interfaces verschoben, sodass Kompilierungsfehler behoben werden. Jetzt kann man sehr einfach mit seiner Lieblings-IDE refaktorisieren und mit einem kleinen Handgriff viel Arbeit erledigen.
Eine sehr zielführende Vorgehensweise zur Anbindung der Persistent Entities an darüber liegende Schichten ist die Wiederverwendung der Entity Bean–Home Interfaces. Das führt dazu, dass Zugriffe unverändert bleiben können. Aber was genau bedeutet Wiederverwendung in diesem Kontext? Im Projekt haben wir die Interfaces nur marginal überarbeitet und zu Data Access Object-Beans umfunktioniert. Eine Implementierung der deklarierten Finder-Methoden hätte zwar generiert werden können, das haben wir aber in unserem Projekt nicht getan, da die Erstellung einer solchen Logik als unverhältnismäßig eingestuft wurde. Trotzdem mussten die Finder geschrieben werden. Die Abfragen dazu existierten bereits in Form von EJB QL in den XDoclet-Tags in den abstrakten Entity Beans. Aufgrund der Tatsache, dass die Abfragen als NamedQueries in den Persistent Entities hinterlegt werden sollten, haben wir ein Tool geschrieben, das Abfragen extrahiert und direkt als NamedQueries ausgibt, die dann nur noch in die Persistent Entity-Klassen eingefügt werden mussten. Eine Transformation von EJB-QL– in JPA QL-Abfragen war nicht notwendig, da JPA-QL auf EJB-QL basiert und diese erweitert.
Damit war alles Nötige geschafft, um die Entity Beans abzulösen.
Und die Session Beans?
Diesen Teil werden wir Ihnen demnächst an dieser Stelle verraten – seien Sie gespannt.
Fazit
Ich werde auch in weiteren Projekten so verfahren, da der betriebene Aufwand relativ gering ausfiel. Zudem hat sich für die Business-Schicht kaum etwas geändert. Der Quelltext blieb sehr sauber und strukturiert.
