In der letzten Zeit findet man diverse Veröffentlichungen oder auch Vorträge auf Usergroups und Konferenzen, die scheinbar das eine Ziel haben, Enterprise JavaBeans aus der Anwendungsarchitektur zu verbannen. Da werden zunächst EJBs durch entsprechende CDI-Beans ersetzt, weil die ja leichtgewichtiger seien. Aus Entwicklersicht kann ich dem nicht zustimmen: Aus einer einfachen Klasse wird durch eine einzelne Annotation eine EJB. Wenn das schwergewichtig ist … Natürlich ist auch der Laufzeitaspekt zu berücksichtigen. Und da sind EJBs tatsächlich etwas langsamer als CDI-Beans, aber der Unterschied ist relativ gering – vgl. dazu auch Adam Biens Weblog. Nach der Ersetzung der EJBs stelt man dann fest, dass einige Aspekte fehlen, die EJBs mitbringen, CDI-Beans aber nicht. So z. B. die deklarative Transaktionssteuerung. Die Verfechter des EJB-Abschusses programmieren sich dann mal eben (*) einen CDI-Interceptor mit dem Binding über eine Annotation namens @Transactional o. ä. Analog könnte man für Security, asynchrone Methoden, Timer etc. vorgehen. Ich frage mich nur “warum?”. Warum um alles in der Welt sollte ich eine vorhandene, funktionierende Lösung durch eine selbstprogrammierte ersetzen? Als Argument wird gelegentlich angeführt, dass eine Lösung ohne EJBs bspw. in einem Tomcat mit CDI-Container (Weld oder OpenWebbeans) lauffähig wäre. Ja, schon – aber die Lösung mit EJBs ist eben auch in einem Tomcat lauffähig, wenn ich einen entsprechenden Container hinzunehme. Es gibt doch genau diese Plattformen – SIwpas, TomEE, Resin etc., die das nötige Java-EE-6-Webprofil implementieren. Warum sollte ich mich denn selbst kasteien und nur ein Subset davon nutzen? Es muss wohl doch daran liegen, dass EJBs böse sind … (*) “mal eben” ist in der IT ein Signalwort. Es bedeutet, dass hier höchste Aufmerksamkeit hinsichtlich des zu veranschlagenden Aufwands geboten ist. PS.: Eine Vereinheitlichung der in grossen Teilen konkurrierenden Komponentenkonzepte EJB und CDI ist sicher sinnvoll. Das sollte aber IMHO im Standard (Java EE 7) passieren und nicht mit “Mach ich mal eben selbst”-Schnellschüssen.
Softwarearchitektur
