THESE: EJBs sind Tod/JEE ist Tod…​

EJBs werden seit 1997 spezifiziert und spätestens durch die Adoption von SUN 1999 auch genutzt [Wikipedia EJBs]. Mit den Versionen 1.0/1.1 und 2.0 wurde eine sehr strikte und Code-Intensive Umsetzung der Spezifikation angeboten. So war es z.B. zwingend erforderlich, das man Interfaces implementiert. Insbesondere in den Versionen 1.0/1.1 mussten auch lokale Beans immer über Corba aufgerufen werden, auch wenn man ein Distributed Computing nicht verwendete. Dies führte zu einem hohen Performance impact [Wikipedia EJBs History]. Dies änderte sich dann mit Version 2.0.

In der Version 3.0 der EJB-Spezifikation (2004) wandte man sich in Teilen von den bisherigen Konzepten ab, und übernahm Konzepte aus dem bereits damals schon aufkommenden und als leichtgewichtiger empfundenen Spring Framework. So wurde hier verstärkt auf Annotationen und nicht mehr auf die Implementierung von Interfaces gesetzt.[Wikipedia EJBs History].

Eine Versions-Historie bis zur Version 3.2 (2013) kann man unter [Wikipedia EJBs Versions Historie] einsehen.

Bereits mit der EJB Spezfikation 3.1 und dem JEE Stack 6 (2009) wurde CDI [Wikipedia CDI] eingeführt. Dieses Konzept entstammt in weiten Teilen dem Spring Framework und beruht auf dessen und Google Guice‘ Konzepten.

Im folgenden möchte ich auf einige Punkte in der JEE Spezifikation eingehen, die meist mit EJBs umgesetzt werden.

Im Bereich des Remoting (sprich, die Method Invocation innerhalb einer anderen VM bzw. sogar über Hardware-Genzen hinweg ist ein Einsatzbereich der EJBs (@Remote). Dieses Paradigma wird in einigen Applikationen für die Kommunikation zwischen verschiedenen Applikatiionen genutzt. Dieses Programmier-Paradigma ist längst durch andere Paradigmen mit loser Kopplung (zB. REST [Adam Bien - Local and Remote EJB]) abgelöst worden.

Für die Asynchrone Kommunikation werden vielfach die Message Driven Beans (MDB) und JMS eingesetzt. Dies wird voraussichtlich mit der JEE 9.0 Spezifikation auch in CDI abgebildet, so dass eine Verwendung von MDBs in Zukunft nicht mehr notwendig erscheint [Eclipse JEE8 - Absatz CDI 2]. Derzeit erscheinen diese jedoch immer noch eine einfache Möglichkeit um asynchron Messages zwischen Systemen auszutauschen.

Im Bereich der Security haben EJBs auch eine Stärke, die mit CDI1.1/1.2 leider noch nicht komplett aufgehoben wurde. Dennoch ist es bereits in dieser Version möglich, die von EJB bekannten Sicherheitskonzepte einfach "nachzubauen"[Wofür braucht man JEE eigentlich noch - Absatz Security].

Mit CDI1.1 wurde das Transaktionshandling mit dem Handling von EJBs weitgehend angeglichen. Bei der Behandlung von Exceptions ist CDI sogar besser als das bisherige EJB Konzept. Eine Ausnahme bildet der Einsatz von sogenannten Extended Transactions, die die Objekte nach dem Ende einer Transaktion nicht von der DB detachen und so einen einfacheren Flow der Daten ermöglichen [Wofür braucht man JEE eigentlich noch - Absatz Transaktionsbehandlung und JPA].

Hier hat sich bereits jetzt in Projekten "eingebürgert", das Objekte gemerged werden, was eine Extended Transaction nicht mehr notwendig macht. Dies geschieht häufig in einer zentralen DAO Klasse.

Mit JEE8 wurde leider nicht, wie ursprünglich geplant, die @Schedule-Annotation in CDI implementiert. Dies ist auch weiterhin nur über ein Singleton-EJB möglich. Bei Bedarf kann diese Zeitsteuerung aber über entsprechende Zusatzbibliotheken auch in CDI nachgerüstet werden [Schedule Jobs in CDI].

Häufig sollen beim Startup eines Containers einige Funktionen ausgeführt werden, zB. um spezifische Konfigurationsdaten zu lesen. Auch dies wurde mit CDI 2.0 noch nicht umgesetzt. Auch dies kann bereits in CDI 1.1 recht einfach nachgebildet werden [CDI and Startup].

Da immer noch ein paar (wenige) Features in der EJB Spec nicht in CDI abgebildet sind, ist es derzeit nicht möglich, die EJBs bereits aus den Projekten zu entfernen. Dies ist auch nicht notwendig, da die beiden Spezifikationen sehr gut miteinander kooperieren. Dennoch empfiehlt es sich, bei einer Implementierung eines Projektes darauf zu achten, das die EJBs in Zukunft durch CDI abgelöst werden (könnten). Um dann zusätzliche Aufwand zu vermeiden (wie zB. bei den in JEE8 deprecateden @ManagedBean und den daran hängenden Scopes) sollte somit vorwiegend CDI eingesetzt werden.

Die Fokussierung auf Microservices und schnell startende bzw. Self-Contained Container [Thorntail] und die damit zusammenhängenden Mirco-Profiles [Microprofile] ergibt sich, zumindest aus meiner Perspektive, ein klarer Trend in Richtung einer EJB-losen Welt.

Für die Zukunft gerüstet sein, heißt hier also ganz klar, auf EJBs möglichst verzichten ["birdseye JEE8 - Absatz CDI 2, letzter Abschnitt"].