Enterprise Tales: Welcome to the Jungle

Lars Röwekamp und Matthias Weßendorf

Was waren das noch für Zeiten, als aus Mangel an Alternativen die Wahl des richtigen Enterprise Java Frameworks zur reinen Formsache verkam. Um 2000 herum hieß die einzig akzeptable Lösung, dank „einfach“ zu nutzender APIs und standardisierter Server, J2EE. Wenige Jahre später war das Spring Framework das Maß aller Dinge. Heute dagegen sieht die Enterprise-Java-Welt schon anders aus – Welcome to the Jungle!

Aus Raider wird Twix

Manch ein FacesTales-Fan wundert sich an dieser Stelle sicherlich, dass die beiden Autoren der Kolumne die Fronten gewechselt zu haben scheinen. Was steckt dahinter? Ist ihnen die JSF-Welt zu klein geworden? Dem ist natürlich nicht so. Vielmehr ist unserer Meinung nach das Thema JSF kaum noch losgelöst von der umliegenden Infrastruktur zu sehen, weswegen wir uns dazu entschlossen haben, zukünftig vermehrt auch über den JSF-Tellerrand hinauszuschauen. Entsprechend haben wir unsere Kolumne kurzerhand in EnterpriseTales (kurz: ET) umgetauft. Den Anfang der neuen Kolumne macht eine Bestandsaufnahme des aktuellen Status Quo im Enterprise-Java-Dschungel – ganz ohne JSF.

Alles ist gleich

„Was ist denn nun besser? Java EE oder Spring? Oder gibt es vielleicht sogar eine ganz andere Alternative?“. Diese Frage, in verschiedensten Variationen, bekommen wir fast täglich gestellt. Manch ein Fragender zeigt sich dann ganz überrascht, wenn wir mit „Es kommt ganz darauf an!“ antworten.

Auf den ersten Blick sind die Kernbereiche von Java EE und Spring kaum noch zu unterscheiden. Das ist auch kein Wunder, sind doch ein Großteil der Java-EE-Innovationen 1:1 von Spring – und anderen, in der Praxis etablierten Frameworks – übernommen worden. Dependency Injection und POJO-basierte Komponenten sind nur zwei Beispiele dafür, dass der Enterprise-Java-Standard seine Hausaufgaben gemacht und von den Open-Source-Vorbildern gelernt hat. Hinzu kommt, dass sowohl Java EE als auch Spring gleich eine ganze Reihe identischer JSRs aus dem Java Community Process unterstützen. So wundert es kaum, dass die Sourcen in beiden Welten oft nahezu identisch aussehen. Listing 1 zeigt exemplarisch einen CDI-basierten Service, der sowohl in Java EE als auch in Spring realisierbar ist.

Listing 1: CDI-basierter Service als Spring und Java-EE-Implementierung
@Named("service")
public class MyService {

  @Inject
  private AnotherService dependentService;

  @PersistenceContext
  private EntityManager entityManager;

  public void myServiceMethod() {
    ...
  }
}
Alles ist anders

So ähnlich einige Ansätze in beiden Welten auch zu sein scheinen, so unterschiedlich sind wiederum die dahinterliegenden Konzepte. Während Java EE automatisch einen, aus Sicht der Spezifikation, sinnvollen Satz von Standardkonfigurationen mit jedem Komponententyp verbindet, verlangt Spring in der Regel eine explizite Konfiguration. So bringen zum Beispiel die EJBs aus Java-EE-Transaction- und Security-Management von Haus aus mit. Für Spring Managed Beans vom Sterotyp Service dagegen müssen diese Eigenschaften explizit angegeben werden (Listing 2). Beide Ansätze haben ihre Vor- und Nachteile, über die mittlerweile mehr als ausreichend diskutiert wurde [1], [2].

Listing 2: Businesskomponente als Spring und Java-EE-Implementierung
@Stateless
public class MyTransactionalEjbService {

  // transactional by default
  public void myTransactionalServiceMethod() {
    ...
  }

  // non-transactional by configuration
  @TransactionAttribute(NEVER)
  public void myNonTransactionalServiceMethod() {
     ...
  }
}


@Service
public class MyTransactionalSpringService {

  // transactional by configuration
  @Transactional
  public void myTransactionalServiceMethod() {
    ...
  }

  // non-transactional by default
  public void myNonTransactionalServiceMethod() {
    ...
  }
}

Wesentlich größer werden die Unterschiede, wenn man die Kernbereiche beider Frameworks verlässt. Mittlerweile bietet Spring für nahezu jeden Anwendungsfall eine eigene – und somit proprietäre – Lösung an. Spring Web Flow für die Entwicklung von Webanwendungen, Spring Batch für die Umsetzung von Batch-Verarbeitung oder Spring Integration für die Anbindung von 3rd-Party- und Legacy-Systemen, um hier nur einige der fast 20 aktiven Spring-Projekte zu nennen.

Spätestens an dieser Stelle beginnt nun der Glaubenskrieg bzw. die Frage nach der hausinternen Philosophie in Hinblick auf standardbasierte Softwareentwicklung. Setzt man auf die Lösungen von Spring, bekommt man eine beinahe optimal aufeinander abgestimmte Entwicklungs- und Laufzeitumgebung geliefert, bei der alle APIs nahezu identischer Implementierungs- und Konfigurationsmustern unterliegen. So weit, so gut. Der Preis, den man dafür zahlt, ist ein 100%iges Commitment auf die Welt von Spring und somit genau auf einen Hersteller. Das kann – muss aber nicht – ein Risiko bedeuten. Wer hätte zum Beispiel vor zwei Jahren damit gerechnet, dass SpringSource von VMWare aufgekauft werden würde? Und wie heißt der nächste im Bunde?

Die Alternative zu diesem Szenario ist der Java-EE-Standard, der per Definition weniger innovativ und flexibel, dafür aber herstellerunabhängig ist. In der Praxis bedeutet das, dass bestimmte Themen, die auf dem Markt an Relevanz gewinnen, im Standard noch nicht oder nur unzureichend verankert sind. Ein Beispiel hierfür ist die Anbindung von NoSQL-Datenbanken. Während Spring mit SpringData bereits eine entsprechende Lösung im Gepäck hat, wird es im Java-EE-Umfeld wahrscheinlich noch einige Iterationen dauern, bevor eine Lösung Einzug in den Standard erhält. Interessant sind in diesem Zusammenhang erste Versuche, JPA auch zur Anbindung „alternativer“ Storage-Systeme zu verwenden [3], [4], ob und wann das jedoch in den Standard einfließt, steht aktuell noch in den Sternen.

Alles ist Ansichtssache

Die Entscheidung für oder gegen Java EE bzw. für oder gegen Spring sollte unserer Meinung nach nicht auf Basis der reinen Technologien und deren Features erfolgen. Sowohl Spring als auch der Standard (ergänzt um einige APIs) sind heute in der Lage, nahezu identische Szenarien abzudecken. Generell ist unsere Empfehlung daher, im Umfeld von Greenfield-Projekten so lange auf den Standard zu setzen, bis etwas explizit dagegen spricht. Da dank des CDI-Portable-Extension-Mechanismus [5] mittlerweile relativ einfach 3rd Party Frameworks und Libraries in den Standard eingebunden werden können und dieser so nahezu beliebig erweitert werden kann, spricht zum Beispiel auch nichts gegen eine Java-EE-basierte Spring-Integration. Wie so etwas aussehen kann, finden Sie unter [6].

Abraten möchten wir an dieser Stelle allerdings explizit von der Migration bestehender Spring-Projekte auf Java EE – solange kein triftiger Grund dafür vorliegt. Auch wenn der Aufwand für die Migration sicherlich überschaubar sein dürfte, steht er in der Regel in keiner Relation zum Nutzen.

Fazit

Trotz bestehender Alternativen bestimmen Java EE und Spring den Enterprise-Java-Markt fast vollständig. Und wie so oft gilt: „Wer die Wahl hat, hat die Qual!“. Während sich beide Frameworks im Kern kaum noch unterscheiden, rückt das „Rundherum“ immer stärker in den Fokus. Hier hat Spring mit seinen mittlerweile fast 20 Projekten ganz eindeutig die Nase vorn. Egal ob Enterprise-Integration, NoSQL-Datenbanken oder die Cloud – Spring bietet eine Lösung. Doch alles hat seinen Preis. Und der heißt in diesem Fall 100%ige Abhängigkeit.

Unser Ziel für die kommenden Kolumnen ist, Ihnen einen möglichst neutralen Blick auf das gesamte Enterprise-Java-Umfeld zu vermitteln. Wir werden dabei sowohl einzelne Aspekte von Spring und Java EE als auch völlig andere Alternativen betrachten, um Ihnen so die Qual der Wahl ein wenig zu erleichtern.

Lars Röwekamp ist Geschäftsführer der OpenKnowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing (Twitter: @mobileLarson).Matthias Weßendorf arbeitet für die Firma Kaazing. Dort beschäftigt er sich mit WebSocket, HTML5 und weiteren Themen rund um das „Next Generation Web“. Matthias blogt regelmäßig auf http://matthiaswessendorf.wordpress.com (Twitter: @mwessendorf).

Geschrieben von
Lars Röwekamp und Matthias Weßendorf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.