Gründe gegen den Einsatz von EJBs

Die Häufigsten Gründe gegen einen Einsatz von EJBs, die ich von Entwicklern aus dem Java Servlet Entwickler Umfeld höre:

EJBs sind langsam

Ein Aufruf einer EJB über ein lokales Interface ist ersteinmal nicht mehr als ein Methodenaufruf mit ein paar Hooks für Interceptoren. Das kostet gemein hin nicht so wahnsinnig viel Zeit. Bei der Servlet Programmierung übliche Verfahren zum Aufruf von Business Logik ohne EJBs sind:

  • Alle benötigten Objekte werden im Servlet jedesmal neu Instanziert. Da man sich in einem Servlet in einem Multithreaded Kontext befindet, ist das die einfachste Variante, Synchronisationsprobleme zu vermeiden. Allerdings kann das Instanzieren der Objekte durchaus teuer sein.
  • Business Objekte werden als „Singleton“ einmalig instanziert und aufgerufen. Damit sind die Objekte ebenfalls in einem Mulithreaded Kontext und müssen ggf. Synchronisiert werden. Ausgiebige Synchronisation verhindert die parallele Abarbeitung und wirkt wie eine Bremse – mangelnde Synchronisation verhindert üblicherweise die Lauffähigkeit des Programms. Letzteres sehe ich häufiger.

Stateless EJBs werden in einem Pool gehalten und wiederverwendet. Dabei werden die EJBs Threads zugeordnet, während der Ausführung einer EJB ist man also der einzige Thread mit Zugriff auf diese Instanz. Man programmiert also im Prinzip Single Threaded. Thread Synchronisation ist deshalb per EJB Spec verboten.

EJBs sind kompliziert

Da habe ich jüngst während eines Coachings eine recht interessante Beobachtung gemacht: Entwickler, für die Java relativ neu war, hatten wenig Probleme mit dem Einsatz von EJBs. Veteranen der Java Entwicklung sind hingegen mit Schwung gegen jede Mauer gelaufen, die sie finden konnten. Es scheint aus irgendwelchen Gründen in der Natur des geübten Java Entwicklers zu liegen, dass er Frameworks ersteinmal zu umgehen versucht. Ich habe schon die coolsten Sachen gesehen: Selbst geschriebene Frameworks mit schier unglaublicher Komplexität, die zum einen versuchen die Funktionalität des Frameworks, in dem sie sich gerade befinden, nachzubauen und zum anderen dann die ganzen Probleme zu Umgehen, die sich durch die komplette Ignoration der Funktionsweise der ursprünglichen Frameworks ergeben haben. Ich habe Ansätze gesehen, die auf so fantasievolle Art initialisiert werden, dass pro Appliaktionserver genau eine Anwendung installiert sein kann. Ich habe Kunstvolle Konstrukte gesehen, die alle Aufrufe über JMX ausführen und die eigentlichen EJB Interfaces nur zum Übertragen der JMX Serveradressen verwenden.

Nach meiner persönlichen Erfahrung liegt der Großteil der Probleme mit dem Framework in der eigenwilligen Benutzung des Frameworks. Allerdings werde ich auch eher selten gerufen, wenn alles funktioniert. 🙂

RMI ist langsam, Serialisierung hat zu viel Overhead

Das ist ersteinmal gut beobachtet und ausgesprochen richtig. Die Frage ist, wozu brauche ich es? Wenn ich es zur physikalischen Trennung von Applikationsteilen brauche z.B. zur besseren Skalierung, sind die ausgelagerten Applikationsteile meist so rechenintensiv, dass der Overhead für den Remote Call in Kauf genommen werden kann. Wenn ich rasend schnelle Sessionreplikation brauche, weil ich ein hochverfügbares Ebay bauen will, was recht ungewöhnlich ist, kann ich auf Implementierungen des EJB Standrads zurückgreifen, die so etwas eben nicht auf Basis von Java Serialisierung implementieren sondern eine andere Strategie benutzen. Wenn ich ein externes Programm anbinden will, dass ein anderes Protokoll unterstützt, kann ich das auch ohne Umweg über JMS oder RMI direkt als Ressourceadapter integrieren und somit wieder lokal darauf zugreifen.

Die noch interessantere Frage ist: Was ist die Alternative? Ich habe nicht wenige Applikationen gesehen, aus Performancegründen auf EJBs verzichten und dann Applikationsteile über SOAP verbinden – was jetzt auch nicht unbedingt in dem Ruf steht, besonders performant zu sein.

EJBs lösen nicht meine Art von Problem nicht

Java EE ist eine Möglichkeit, möglichst einfach Unternehmensanwendungen zu schreiben. Es gibt sicherlich unzählige Applikationen, die damit zumindest schwer zu entwickeln sind. So würde nicht einmal Sun auf die Idee kommen, eine massiv parallele, eventgetriebene Architektur, wie sie zu Entwicklung von Online Spielen gebraucht wird, in einen Java EE Container zu stecken (s. Project Darkstar). Java EE ist gut für viele Anwendungen – aber nicht für alle. Man sollte eine grobe Idee haben, was man Entwickeln möchte und kann dann einfach gucken, welche Anforderungen nimmt mir das Framework ab, welche lassen sich elegant lösen, bei welchen steht es mir im Weg. There is no silver bullet…

Nachtrag: Es gibt offensichtlich doch Menschen, die Project Darkstar in die Java EE Umgebung pressen wollen: Underworld

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


8 − drei =