Enterprise Java Beans: Wann lohnt der Einsatz?

Standardisierte Komponenten vereinfachen die Entwicklung mehrschichtiger Softwaresysteme. Doch diese Komponenten und der Umgang mit ihnen müssen erlernt werden. Oft stellt sich die Frage, ob der Aufwand gerechtfertigt ist. Der folgende Artikel wendet sich an Entwickler, die noch unentschlossen sind, ob sie Zeit und Energie in das Erlernen und in die Anwendung der Enterprise-Java-Beans-Technologie bei ihren Projekten investieren möchten.

Zunächst werden hier die Vor- und Nachteile von Enterprise Java Beans (EJB) besprochen. Dann wird darauf eingegangen, wofür sich EJB gut eignet und wofür nicht. Abschließend wird mit einigen verbreiteten EJB-Mythen aufgeräumt.

Vorteile

• Spezifizierung: EJB basiert auf standardisierten Komponenten. (Dies ist sowohl der größte Vorzug als auch der größte Nachteil von EJB.) Die EJB-Spezifikation beschreibt fast alle Aspekte des Einsatzes, einschließlich Datentypen, Lebenszyklen der Komponenten, Rollenverteilung und anderes mehr.
• Enge Integration in J2EE: Um J2EE herum sind zahlreiche Server-Technologien entstanden, darunter EJB und so wertvolle Technologien wie Servlets, Java Server Pages, Java Message Service, J2EE Connector Architecture, Java Database Connectivity, Java Authentication and Authorization Service, Java Transaction API und Javamail. Dies macht J2EE und EJB zu einer sehr attraktiven Lösung.
• Skalierbarkeit: So lange die meisten Funktionen in Sachen Ressourcenmanagement an die Anwendungsserver delegiert werden, können Anbieter komplexe Skalierungs-Algorithmen einsetzen.
• Zugriff auf Ressourcenverwaltungssysteme: Zusammen mit dem EJB-Container erhält der Programmierer Tausende von Codezeilen für den Zugriff auf die Verwaltung von Ressourcen, darunter Transaction-Management-Systeme, Security-Management-Systeme und Verzeichnisdienste.

Nachteile

• Umfangreiche und komplexe Spezifikation: Ein respektabler Umfang ist normal für eine Spezifikation, die ein derart komplexes, verteiltes System beschreibt. Es werden jedoch nicht alle Informationen wirklich benötigt, um mit dem Schreiben von Code zu beginnen, was die Spezifikation zu einem wenig komfortablen Werkzeug macht.
• Voluminöse Dokumentation: Bevor man mit der Entwicklung eines Projekts beginnt, muss man gewöhnlich über 1000 Seiten Dokumentation lesen. Dieser Umstand schreckt viele davon ab, EJB einzusetzen.
• Der Zeitaufwand für die Entwicklung erhöht sich: Eine EJB-Lösung benötigt mehr Zeit als einfacher Java-Code. Auch das Debugging von EJB-Code nimmt längere Zeit in Anspruch, als dies bei einfachem Java-Code der Fall ist. Dies liegt hauptsächlich daran, dass man nie sicher sein kann, ob der Fehler sich im Code oder im Container befindet.
• EJB-Code ist komplexer: Es müssen zum Beispiel drei Klassen geschrieben werden, wenn eine Session-Bean eingesetzt werden soll. Für eine Entity-Bean sind es vier Klassen. Wenn dann noch ein paar Deployment-Deskriptoren hinzukommen, kann ein einfaches „Hello World“-Programm schnell statt einer gleich zehn Dateien umfassen.
• Gefahr zu komplizierten Designs: Dies liegt daran, dass die Spezifikation so komplex ist. Werden die der EJB zugrunde liegenden Konzepte nicht vollständig erfasst, kann diese Technologie nicht effizient eingesetzt werden. Dies wiederum macht ein Projekt womöglich komplizierter als eigentlich notwendig.
• Spezifikationsänderungen: EJB ist eine junge Technologie, und das, was man heute programmiert, kann morgen schon überholt sein. Damit wird ein zusätzlicher Aufwand an Zeit und Geld erforderlich, um den Code mit neuen EJB-Containern kompatibel zu machen.