Sind EJBs böse?

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.

Advertisements

Über Dirk Weil
Dirk Weil ist seit 1998 als Berater im Bereich Java tätig. Als Geschäftsführer der GEDOPLAN GmbH in Bielefeld ist er für die Konzeption und Realisierung von Informationssystemen auf Basis von Java EE verantwortlich. Seine langjährige Erfahrung in der Entwicklung anspruchsvoller Unternehmenslösungen machen ihn zu einem kompetenten Ansprechpartner und anerkannten Experten auf dem Gebiet Java EE. Er ist Autor in Fachmagazinen, hält Vorträge und leitet Seminare und Workshops aus einem eigenen Java-Curriculum.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: