Sollte ich EJB3 oder Spring für meine Business-Schicht verwenden?

Mein Team entwickelt ein neues serviceorientiertes Produkt mit einem Web-Frontend. In Diskussionen darüber, welche Technologien wir verwenden werden, haben wir uns darauf geeinigt, einen JBoss-Anwendungsserver und ein Flex-Frontend (mit möglicher Desktop-Bereitstellung mit Adobe AIR) sowie Webdienste als Schnittstelle zwischen Client und Server auszuführen.

Wir sind in eine Sackgasse geraten, wenn es darum geht, welche Servertechnologie wir für unsere Geschäftslogik verwenden sollen. Der große Streit liegt zwischen EJB3 und Spring, wobei unsere größten Bedenken die Skalierbarkeit und Leistung sowie die Wartbarkeit der Codebasis sind.

Hier sind meine Fragen:

1. Was sind die Argumente für oder gegen EJB3 vs. Spring?
   • Welche Fallstricke kann ich jeweils erwarten?
   • Wo finde ich gute Benchmark-Informationen?

Es wird keinen großen Unterschied zwischen EJB3 und Spring geben, basierend auf der Leistung. Wir haben uns aus folgenden Gründen für Spring entschieden (in der Frage nicht erwähnt):

• Spring treibt die Architektur in eine Richtung, die Komponententests besser unterstützt. Fügen Sie beispielsweise ein Mock-DAO-Objekt ein, um Ihre Geschäftsschicht zu testen, oder verwenden Sie das MockHttpRequest-Objekt von Spring, um ein Servlet zu testen. Wir pflegen eine separate Spring-Konfiguration für Komponententests, die es uns ermöglicht, Tests auf die spezifischen Schichten zu isolieren.
• Ein vorrangiger Treiber war die Kompatibilität. Wenn Sie mehr als einen App-Server unterstützen müssen (oder eventuell die Möglichkeit haben möchten, von JBoss zu Glassfish usw. zu wechseln), tragen Sie im Wesentlichen Ihren Container (Spring) mit sich, anstatt sich auf die Kompatibilität zwischen verschiedenen Implementierungen des zu verlassen EJB3-Spezifikation.
• Spring ermöglicht Technologieoptionen für Persistenz, Objekt-Remoting usw. Beispielsweise verwenden wir auch ein Flex-Frontend und verwenden das Hessian-Protokoll für die Kommunikation zwischen Flex und Spring.

Die Lücke zwischen EJB3 und Spring ist deutlich kleiner als zuvor. Allerdings ist einer der Nachteile von EJB3 jetzt, dass Sie nur in eine Bean injizieren können, sodass Sie am Ende Komponenten in Beans verwandeln können, die es nicht sein müssen.

Das Argument über Unit-Tests ist jetzt ziemlich irrelevant – EJB3 ist eindeutig so konzipiert, dass es leichter Unit-testbar ist.

Das obige Kompatibilitätsargument ist auch irgendwie irrelevant: Egal, ob Sie EJB3 oder Spring verwenden, Sie sind immer noch auf von Drittanbietern bereitgestellte Implementierungen von Transaktionsmanagern, JMS usw. angewiesen.

Was es für mich jedoch schwingen würde, ist die Unterstützung durch die Community. Als ich letztes Jahr an einem EJB3-Projekt arbeitete, gab es einfach nicht viele Leute da draußen, die es benutzten und über ihre Probleme sprachen. Der Frühling ist zu Recht oder zu Unrecht extrem allgegenwärtig, insbesondere in Unternehmen, und das macht es einfacher, jemanden zu finden, der das gleiche Problem hat, das Sie zu lösen versuchen.

Was sind die Argumente für oder gegen EJB3 vs. Spring?
Spring ist immer innovativ und erkennt reale Einschränkungen. Spring bot Einfachheit und Eleganz für die Java 1.4-Anwendungsserver und erforderte keine Version der J2EE-Spezifikation, auf die in den Jahren 2004 bis 2006 niemand Zugriff hatte. An diesem Punkt ist es fast eine religiöse Debatte, in die Sie hineingezogen werden können – Spring + Abstraktion + Open Source versus Java Enterprise Edition (Java EE) 5.0 Spezifikationen.

Ich denke Frühling ergänzt mehr als konkurriert mit den Java-EE-Spezifikationen. Da die Funktionen, die einst Spring einzigartig waren, weiterhin in die Spezifikation aufgenommen werden, werden viele argumentieren, dass EJB 3 für die meisten internen Geschäftsanwendungen einen „gut genug“-Funktionsumfang bietet.

Welche Fallstricke kann ich jeweils erwarten?
Wenn Sie dies als Persistenzproblem (Spring + JPA) im Vergleich zu EJB3 behandeln, treffen Sie wirklich keine so große Wahl.

Wo finde ich gute Benchmark-Informationen?
Ich bin dem nicht gefolgt specj Benchmark-Ergebnisse für einige Zeit, aber sie waren für eine Weile beliebt. Es scheint, dass alle Anbieter (IBM, JBOSS, Oracle und Sun) immer weniger daran interessiert sind, einen konformen Server zu haben. Die Listen mit zertifizierten Anbietern werden von 1.3, 1.4 immer kürzer. 1.5 Java-Enterprise-Edition. Ich denke, die Zeiten eines riesigen Servers, der alle Spezifikationen vollständig erfüllt, sind vorbei.

Ich würde EJB3 definitiv über das Frühjahr empfehlen. Wir finden, dass es schlanker ist, besser zu programmieren und besser unterstützt wird. Ich habe in der Vergangenheit Spring verwendet und fand es sehr verwirrend und nicht so gut dokumentiert wie EJB3 (oder JPA, denke ich am Ende des Tages).

1. Ab EJB3 müssen Sie sich nicht mehr mit externen Konfigurationsdateien herumschlagen, und es gibt nur ein POJO, das Sie pro Datenbanktabelle annotieren. Dieses POJO kann problemlos an Ihre Webebene weitergegeben werden. IDEs wie Netbeans können diese POJOs sogar automatisch für Sie generieren. Wir haben EJB3 jetzt als Backend für einige große Anwendungen verwendet und keine Leistungsprobleme festgestellt. Ihre Session Beans können einfach als Webdienste verfügbar gemacht werden, die Sie Ihrem Flex-Frontend zur Verfügung stellen könnten. Session Beans lassen sich einfach auf Methoden- oder Klassenebene sperren, um Rollen und ähnliches zuzuweisen, wenn dies erforderlich ist.

Über den Frühling kann ich nicht viel sagen, da ich ihn erst seit ein paar Wochen ausprobiert habe. Aber mein Gesamteindruck war sehr schlecht. Das bedeutet nicht, dass es ein schlechtes Framework ist, aber unser Team hier hat festgestellt, dass EJB3 das Beste für die Persistenz-/Business-Schicht ist.

Ich tendiere dazu, Spring gegenüber EJB3 zu bevorzugen, aber meine Empfehlung wäre, welchen Ansatz Sie auch immer wählen, versuchen Sie, beim Schreiben von POJOs zu bleiben und nach Möglichkeit die Standardannotationen zu verwenden, wie die JSR-Annotationen wie @PostConstruct, @PreDestroy und @Resource, die mit beiden EJB3 funktionieren oder Spring, damit Sie das von Ihnen bevorzugte Framework auswählen können.

Beispielsweise könnten Sie sich für ein Projekt entscheiden, stattdessen Guice für IoC zu verwenden.

Wenn Sie die Pre-Request-Injection verwenden möchten, z. B. in einer Webanwendung, werden Sie möglicherweise feststellen, dass Guice für die Abhängigkeitsinjektion um einiges schneller ist als Spring.

Session Beans laufen meistens auf Dependency Injection und Transaktionen hinaus; EJB3 und Spring sind sich also wirklich ähnlich. Wo Spring den Vorteil hat, liegt in der besseren Abhängigkeitsinjektion und schöneren Abstraktionen für Dinge wie JMS

Ich habe in der Vergangenheit eine sehr ähnliche Architektur verwendet. Spring + Java 1.5 + Actionscript 2/3 in Kombination mit Flex Data Services machten das Programmieren sehr einfach (und macht Spaß!). Ein Flex-Front-End bedeutet jedoch, dass Sie ausreichend leistungsstarke Client-Computer benötigen.

Was Ihre Frage betrifft:

Was sind die Argumente für oder gegen EJB3 vs. Spring?

Ich schlage vor, die Antwort der Experten zu lesen: EINE ANTWORT AUF: EJB 3 UND SPRING COMPARATIVE ANALYSIS von Mark Fisher. Lesen Sie die Kommentare, um die Bemerkungen von Reza Rahman zu finden (EJB 3.0).