Spring Framework für Java Enterprise

Als wir 2008 mit dem Aufbau eines neuen Kernsystems für eine Versicherungsgesellschaft begannen, standen wir vor dem klassischen Dilemma: reines Java EE (EJB 3.0, JPA, JSF) oder Spring Framework? Wir entschieden uns für Spring. Vier Jahre und 200.000 Codezeilen später wissen wir, dass es die richtige Entscheidung war.

Spring vs. Java EE — die ewige Debatte¶

Java EE 6 (genehmigt im Dezember 2009) machte einen enormen Sprung nach vorne. EJB 3.1 ist endlich ohne XML-Hölle nutzbar, CDI bringt Dependency Injection direkt in die Spezifikation, und JPA 2.0 ist ein solider ORM-Standard. Auf dem Papier gibt es kaum noch einen Grund für Spring.

In der Praxis sieht es anders aus. Spring hat einen Vorsprung bei Ökosystem, Dokumentation und Community. Spring Security ist der De-facto-Standard für Authentifizierung und Autorisierung in der Java-Welt. Spring Batch hat kein Äquivalent in Java EE. Und vor allem — Spring lässt Ihnen die Wahl des Applikationsservers. Sie können auf Tomcat laufen, das einfach und leichtgewichtig ist, statt auf einem vollwertigen Java-EE-Server wie WebSphere oder JBoss.

Dependency Injection in der Praxis¶

DI ist das Herz von Spring und der Grund, warum Code damit testbar ist. Ohne DI erstellt Ihr Service seine eigenen Abhängigkeiten — und Sie können sie im Test nicht durch Mocks ersetzen. Mit Spring deklarieren Sie Abhängigkeiten und der Container liefert sie.

@Service

public class ClaimService {

private final ClaimRepository repository;

private final NotificationService notifications;



@Autowired

public ClaimService(ClaimRepository repository,

    NotificationService notifications) {

    this.repository = repository;

    this.notifications = notifications;

}

}

Constructor Injection (statt Field Injection) ist unser Standard. Abhängigkeiten sind explizit, unveränderlich, und die Klasse ist auch ohne Spring Container nutzbar — einfach mit new instanziieren und Mocks übergeben.

Spring MVC für die Web-Schicht¶

JSF (JavaServer Faces) ist das offizielle Java-EE-Web-Framework, aber ehrlich gesagt — niemand mag es. Das komponentenbasierte Modell ist schwerfällig, der Request-Lebenszyklus ist komplex, und Debugging ist ein Albtraum.

Spring MVC verfolgt den request-basierten Ansatz (ähnlich wie Struts, aber sauberer). Ein Controller ist ein POJO mit Annotationen, URL-Mapping ist übersichtlich, und Testen ist trivial — MockMvc ermöglicht das Testen von Controllern ohne einen Server zu starten.

Für die View-Schicht verwenden wir Thymeleaf statt JSP. Templates sind gültiges HTML, das ein Designer ohne Server im Browser öffnen kann. Und anders als JSP braucht man keinen Servlet Container zum Rendern.

Transaktionsmanagement¶

In Enterprise-Systemen sind Transaktionen allgegenwärtig. Spring bietet deklarative Transaktionen über die @Transactional-Annotation — die Einfachheit von EJB CMT (Container-Managed Transactions), aber ohne die Notwendigkeit eines EJB-Containers.

Unter der Haube erstellt Spring einen AOP-Proxy, der vor der Methode eine Transaktion öffnet und sie danach committet (oder bei einer Exception ein Rollback durchführt). Das Verständnis der Propagation ist wichtig — REQUIRED, REQUIRES_NEW, NESTED. Falsch konfigurierte Propagation ist eine häufige Fehlerquelle, die sich erst unter Last zeigt.

Unser Tipp: Setzen Sie immer readOnly = true für Leseoperationen. Hibernate muss dann kein Dirty Checking durchführen und die Performance verbessert sich spürbar. In unserem System bedeutete das eine 20%ige Reduzierung der Leseoperationszeit.

Spring Security¶

Sicherheit in Enterprise-Java-Anwendungen ist ein komplexes Thema. Authentifizierung gegen LDAP/Active Directory, Autorisierung auf URL- und Methodenebene, CSRF-Schutz, Session Management, Remember-me… Spring Security deckt all das ab.

Die Konfiguration war früher notorisch komplex (XML-Namespace mit Dutzenden von Elementen), aber seit Version 3.1 hat sie sich deutlich verbessert. Java Config ist besser lesbar und die IDE hilft mit Autocomplete.

In unserer Versicherungsanwendung haben wir rollenbasierte Zugriffskontrolle mit einer Rollenhierarchie (AGENT → SUPERVISOR → ADMIN) und Sicherheit auf Methodenebene über @PreAuthorize-Annotationen. Jeder Endpunkt ist abgesichert und ein Audit-Log zeichnet auf, wer wann was getan hat.

Testing — der Hauptgewinn¶

Der größte Vorteil von Spring ist kein bestimmtes Feature, sondern die Testbarkeit. Im Projekt haben wir über 3.000 Unit Tests und 400 Integrationstests. Sie laufen bei jedem Build in Jenkins CI.

Unit Tests sind reines JUnit + Mockito — kein Spring Context, kein Server, sie laufen in Sekunden. Integrationstests verwenden SpringJUnit4ClassRunner mit einer In-Memory-H2-Datenbank. Die gesamte Test-Suite ist in 8 Minuten fertig.

Ohne DI und ohne Spring hätten wir einen Bruchteil dieser Abdeckung. Und dieser Bruchteil wäre unzuverlässig, weil er von externen Systemen abhängen würde.

Was wir anders machen würden¶

• Weniger XML: Wir starteten mit XML-Konfiguration (2008, Spring 2.5). Heute würden wir direkt Java Config und Component Scanning nutzen.
• Spring Profiles früher: Profile für Dev/Test/Prod-Umgebungen sparen Nerven. Wir führten sie erst nach einem Jahr ein.
• REST von Anfang an: Wir starteten mit SOAP Web Services (WS-*-Stack). Heute würden wir direkt REST + JSON nehmen.
• Maven statt Ant: Wir migrierten das Build-System erst 2010 auf Maven. Verlorene Zeit.

Zusammenfassung¶

Spring Framework ist 2012 eine ausgereifte, robuste Plattform für die Java-Enterprise-Entwicklung. Die Hauptvorteile — Testbarkeit, Flexibilität und ein reichhaltiges Ökosystem — überwiegen den einzigen Nachteil (es ist kein Standard). Für ein neues Projekt würden wir Spring erneut wählen, ohne zu zögern.