Java EE 6 und Enterprise-Anwendungen — warum wir auf Standards setzen

Als unser Unternehmen vor drei Jahren gegründet wurde, standen wir vor einer grundlegenden Entscheidung: auf welcher Technologieplattform wir aufbauen sollten. Wir haben .NET, PHP-Frameworks und das damals populäre Ruby on Rails in Betracht gezogen. Letztlich haben wir uns für Java EE entschieden — und heute, nach Dutzenden erfolgreicher Projekte, wissen wir, dass es die richtige Entscheidung war. Hier ist der Grund.

Warum Java EE und nicht Spring?¶

Das ist wohl die Frage, die wir am häufigsten von Branchenkollegen bekommen. Spring Framework ist ein ausgezeichnetes Werkzeug und hat sicher seinen Platz. Aber für unsere Kunden — meist große Unternehmen mit Anforderungen an Langzeitwartung und Zertifizierungen — ist eine standardisierte Plattform einfach die sicherere Wahl.

Java EE 6 brachte einen grundlegenden Wandel im Vergleich zu früheren Versionen. Erinnern Sie sich an die riesigen XML-Deskriptoren in J2EE 1.4? Entity Beans, die niemand nutzen wollte? Das ist vorbei. Das heutige Java EE ist überraschend einfach — Annotationen statt XML, CDI für Dependency Injection, JPA 2.0 für Persistenz.

EJB 3.1 — endlich brauchbar¶

Enterprise JavaBeans hatten lange einen schlechten Ruf. Zu Recht — in der J2EE-Ära war es ein überentwickeltes Desaster. Aber EJB 3.1 ist eine völlig andere Geschichte. Ein einfaches POJO mit ein paar Annotationen, automatisches Transaktionsmanagement, Timer Service, asynchrone Verarbeitung. Und vor allem — No-Interface View, sodass man nicht einmal ein Interface schreiben muss, wenn man keines braucht.

Bei unserem letzten Projekt für eine tschechische Bank (die ich nicht nennen kann, NDA) haben wir ein komplettes Transaktionssystem auf EJB 3.1 aufgebaut. Es verarbeitet Tausende von Transaktionen pro Minute, läuft auf einem Cluster aus zwei GlassFish-Servern und im vergangenen Jahr hatten wir keinen einzigen Ausfall. Versuchen Sie das mal mit PHP.

JPA 2.0 und Oracle Database¶

Unser typischer Stack ist JPA 2.0 (EclipseLink-Implementierung) über Oracle Database 11g. Ich weiß, was Sie jetzt denken — Oracle ist teuer. Und Sie haben Recht. Aber wenn Ihr Kunde eine Oracle-Lizenz und ein DBA-Team hat, das sie seit zwanzig Jahren verwaltet, hat es keinen Sinn, ihnen PostgreSQL aufzudrängen, nur weil es kostenlos ist.

JPA 2.0 gibt uns eine schöne Abstraktionsschicht über die Datenbank. Die Criteria API ist zwar wortreicher als JPQL, aber typsichere Abfragen sind den zusätzlichen Code wert. Und mit Oracle-spezifischen Optimierungen (Partitioning, Materialized Views) erreichen wir eine Performance, die uns mit einem ORM-Framework über MySQL deutlich mehr Aufwand kosten würde.

Application Server — GlassFish vs. JBoss¶

Derzeit verwenden wir hauptsächlich GlassFish 3.1, die Referenzimplementierung von Java EE 6. Es ist die logische Wahl — Oracle steht dahinter, die Dokumentation ist ausgezeichnet, und wenn man auf einen Bug stößt, kann man sicher sein, dass es ein Spezifikationsproblem ist, kein Implementierungsproblem.

JBoss AS 7 ist allerdings eine interessante Alternative. Wir haben ihn in einem internen Projekt getestet und er startet um Größenordnungen schneller als GlassFish. Für Kunden, die den Red Hat Stack bevorzugen (und ein RHEL-Abonnement haben), ist es die klare Wahl. Die Migration zwischen Servern ist dank der Standards relativ schmerzlos — meist muss man nur die Datasource-Konfiguration und ein paar herstellerspezifische Dinge anpassen.

SOA — Buzzword oder Realität?¶

Service-Oriented Architecture ist ein Begriff, der seit zehn Jahren im Enterprise-IT-Umfeld kursiert. Und ehrlich gesagt — viele Projekte berufen sich nur auf SOA, haben aber in Wirklichkeit eine monolithische Architektur mit ein paar SOAP Web Services obendrauf.

Wir versuchen, SOA richtig zu machen. Das bedeutet klar definierte Services mit einem WSDL-Vertrag, einen ESB (wir verwenden Oracle Service Bus) als Vermittlungsschicht und einen Governance-Prozess für das Service-Management. Das ist anfangs mehr Arbeit, aber ein Kunde mit über 50 Systemen braucht Ordnung in seinen Integrationen.

SOAP Web Services sind in der Enterprise-Welt nach wie vor Standard. Ich weiß, dass in der Startup-Community über RESTful APIs und JSON gesprochen wird — und ja, für einfache Szenarien ist REST einfacher. Aber versuchen Sie mal, in REST einen transaktionalen Vertrag mit WS-Security und WS-ReliableMessaging zu definieren. SOAP hat im Enterprise-Bereich nach wie vor seinen Platz.

Deployment und Betrieb¶

Unser Stack hier ist unkompliziert: RHEL auf den Servern, Oracle DB, GlassFish (oder JBoss), Apache HTTP als Reverse Proxy. Monitoring über Nagios, Deployment per Skript über SSH. Keine Magie, bewährte Praxis.

Continuous Integration lösen wir derzeit über Hudson (ja, ich weiß, das heißt jetzt Jenkins). Jeder Commit löst einen Build, Unit-Tests und ein Deployment auf den Testserver aus. Es ist nichts Avantgardistisches, aber es funktioniert zuverlässig und unsere Kunden — die typischerweise monatliche Release-Zyklen haben — brauchen nicht mehr.

Was uns erwartet¶

Java EE 7 ist in Vorbereitung und sieht vielversprechend aus. WebSocket-Unterstützung, JSON Processing API, Batch API — das sind Dinge, die uns derzeit fehlen und die wir mit proprietären Bibliotheken lösen. Wir freuen uns besonders auf JPA 2.1 mit Stored-Procedure-Unterstützung und Verbesserungen der Criteria API.

Cloud Computing ist ein Thema, das wir beobachten, aber wir sehen es noch nicht als realistische Option für unsere Kunden. Regulierung im Bankensektor, Data-Residency-Anforderungen und Sicherheitsaudits — all das spricht derzeit noch für On-Premise-Lösungen. Aber die Situation wird sich sicher weiterentwickeln.

Fazit¶

Java EE 6 ist eine ausgereifte, standardisierte Plattform für Enterprise-Entwicklung. Es ist nicht die aufregendste Technologie — man bekommt dafür keine Upvotes auf Hacker News. Aber wenn man ein System baut, das fünf Jahre in einer Bank oder Versicherungsgesellschaft laufen soll, ist es die Plattform, auf die man sich verlassen kann. Und genau das brauchen unsere Kunden.