#Orientierung, Zielbild und Lernstrategie

Dieses Kapitel erklärt, wie du den Lernpfad liest, welches Zielbild hinter der Modernisierung steht und wie du als Senior Java Entwickler priorisieren solltest.

#Leitgedanke

Bei Legacy Java Enterprise reicht es nicht, Klassen zu lesen. Du musst Container-Verhalten lesen:

  • Welche Transaktion läuft?
  • Welcher Proxy ruft die Methode auf?
  • Ist der Call lokal, remote, synchron oder asynchron?
  • Welche Ressourcen werden per JNDI injected?
  • Welche DB-, JMS-, SOAP- und File-Side-Effects passieren?
  • Was passiert bei Exception, Timeout, Retry, Rollback oder Redelivery?

Die wichtigste Reihenfolge lautet:

text
Dokumentieren
    ↓
Absichern
    ↓
Kapseln
    ↓
Extrahieren
    ↓
Ersetzen

Nicht umgekehrt.

#Gesamtziel des Lernpfads

Am Ende sollst du:

  1. Ein altes Java-Enterprise-System strukturiert inventarisieren können.
  2. EJB-, JTA-, JMS-, SOAP-, JSP- und JPA-Laufzeitverhalten erklären können.
  3. Kritische Use Cases vom Entry Point bis zur Datenbank verfolgen können.
  4. Transaktionsgrenzen, Side Effects, Rollback-Regeln und Retry-Verhalten dokumentieren können.
  5. Charakterisierungstests und Smoke Tests für Legacy-Verhalten bauen können.
  6. Komponenten hinter Ports/Adapter kapseln können.
  7. EJBs zu dünnen Fassaden umbauen können.
  8. SOAP/JMS/JPA/JNDI-Abhängigkeiten vom fachlichen Kern trennen können.
  9. Eine realistische Modernisierungsstrategie Richtung Jakarta EE, Spring Boot oder Quarkus entwickeln können.
  10. Einen schrittweisen Migrationsplan ohne Big Bang erstellen können.

#Zielarchitektur als Orientierung

Nicht sofort Framework wechseln. Erst eine saubere innere Struktur schaffen.

text
Inbound Adapter
JSP / Servlet / SOAP / JMS / Scheduler / REST
        ↓
Application Services / Use Cases
Transaktionsgrenzen, Orchestrierung, Commands
        ↓
Domain
Fachregeln, Statusübergänge, Invarianten
        ↓
Ports
Repository, EventPublisher, PaymentGateway, AuditPort
        ↓
Outbound Adapter
JPA, JDBC, SOAP Client, JMS, File, Mail, JNDI

Kurzform:

text
Außen darf alt bleiben.
Innen soll sauber werden.

#Zielplattformen: Jakarta EE, Spring Boot, Quarkus

#Jakarta EE modernisieren

Geeignet, wenn:

  • viele EJBs, JTA, JMS, JPA und Application-Server-Features vorhanden sind
  • XA-Transaktionen wichtig sind
  • Container Security genutzt wird
  • Remote EJBs, MDBs oder Timer stark genutzt werden
  • das Team Java EE/Jakarta EE kennt
  • möglichst wenig Architekturbruch gewünscht ist

Typische Richtung:

text
Java EE 6/7/8
    ↓
Build stabilisieren
    ↓
Java 11/17 vorbereiten
    ↓
Java EE 8 kompatibel machen
    ↓
javax.* → jakarta.* prüfen
    ↓
Jakarta EE 10/11 Runtime
    ↓
EJB-Fachlogik reduzieren, CDI/Application Services stärken

#Spring Boot

Geeignet, wenn:

  • Application Server abgelöst werden soll
  • eigenständige Deployables gewünscht sind
  • Team Spring kennt
  • REST/APIs, einfache Container Deployments oder modulare Services geplant sind
  • EJBs hauptsächlich normale Services sind

Typisches Mapping:

text
@Stateless              → @Service
@TransactionAttribute   → @Transactional
@PersistenceContext     → EntityManager / Spring Data / Repository
@MessageDriven          → @JmsListener
@WebService             → SOAP Adapter oder REST Controller
@Resource               → Spring Bean / ConfigurationProperties
JNDI Datasource         → konfigurierte DataSource

Achtung: EJB-Transaktionen und Spring-Transaktionen sind ähnlich, aber nicht identisch. Prüfe besonders:

  • checked Exceptions
  • Rollback-Regeln
  • REQUIRES_NEW
  • NOT_SUPPORTED
  • Self-invocation
  • Proxy-Verhalten
  • Security Context
  • Remote Calls
  • Interceptors

#Quarkus

Geeignet, wenn:

  • Kubernetes/Container wichtig sind
  • schnelle Startzeit und niedriger Speicherverbrauch wichtig sind
  • Jakarta/MicroProfile-nahe Entwicklung gewünscht ist
  • Services kleiner geschnitten werden sollen
  • Native Image oder Cloud-native Java relevant ist

Typische Richtung:

text
Legacy Monolith
    ↓
Use Cases und Ports extrahieren
    ↓
einzelne fachliche Slices als Quarkus Services neu anbinden
    ↓
Legacy per Adapter/Events/Schnittstellen integrieren

#Master-Roadmap

#Phase A: Sichtbarkeit schaffen

Ziel: Wissen, was existiert.

Dauer: 1–2 Wochen

Ergebnisse:

  • docs/legacy-inventory.md
  • docs/entry-points.md
  • docs/runtime-resources.md
  • docs/deployment-structure.md
  • erste Liste kritischer Use Cases

#Phase B: Laufzeitverhalten verstehen

Ziel: Wissen, was wirklich passiert.

Dauer: 2–4 Wochen

Ergebnisse:

  • Call Chains
  • Transaction Maps
  • Queue Maps
  • SOAP Contract Maps
  • Security Map
  • Exception/Rollback Matrix

#Phase C: Schutznetz bauen

Ziel: Änderungen absichern.

Dauer: 2–4 Wochen

Ergebnisse:

  • Smoke Tests
  • Charakterisierungstests
  • SOAP Golden Master Tests
  • JMS Handler Tests
  • DB Integration Tests
  • Logging/Correlation IDs

#Phase D: Kapseln und entkoppeln

Ziel: Fachlogik aus Container-/Framework-Code lösen.

Dauer: 4–12 Wochen, iterativ

Ergebnisse:

  • Ports/Adapter
  • dünne EJB-Fassaden
  • extrahierte Use Cases
  • Plain-Java-Fachlogik
  • SOAP/JMS/JPA/JNDI hinter Interfaces

#Phase E: Modernisieren

Ziel: Technologie gezielt ersetzen.

Dauer: projektabhängig

Mögliche Ergebnisse:

  • Java-Version modernisiert
  • Build modernisiert
  • Application Server aktualisiert oder ersetzt
  • Jakarta EE Migration
  • Spring Boot/Quarkus Slices
  • JSP reduziert oder abgelöst
  • Outbox Pattern statt XA/JMS-Kopplung
  • Legacy-Module entfernt

#30-Tage-Lern- und Arbeitsplan

#Woche 1: System sichtbar machen

Ziele:

  • Build reproduzierbar machen
  • Deployment verstehen
  • EJB/MDB/SOAP/JSP Inventar erstellen
  • Runtime Resources dokumentieren
  • 1 kritischen Use Case auswählen

Deliverables:

text
docs/legacy-inventory.md
docs/entry-points.md
docs/runtime-resources.md
docs/deployment-structure.md

#Woche 2: Verhalten verstehen

Ziele:

  • Call Chain eines Use Cases dokumentieren
  • Transaktionsgrenzen markieren
  • DB-Schreibzugriffe markieren
  • JMS/SOAP Side Effects markieren
  • Fehlerfälle prüfen

Deliverables:

text
docs/use-case-001.md
docs/transaction-map-001.md
docs/queue-map.md
docs/soap-map.md

#Woche 3: Schutznetz bauen

Ziele:

  • Smoke Test
  • Charakterisierungstest
  • SOAP Golden Master
  • JMS Handler Test
  • DB Integration Test
  • erste Observability-Verbesserung

Deliverables:

text
src/test/...
docs/test-strategy.md
docs/manual-test-script.md

#Woche 4: Erste Kapselung

Ziele:

  • eine SOAP-Abhängigkeit hinter Interface ziehen
  • einen JMS Publisher hinter Interface ziehen
  • eine EJB-Fachlogik in Plain Java Use Case ziehen
  • eine JSP von direkter Businesslogik befreien
  • Risiko-Backlog aktualisieren

Deliverables:

text
application/<UseCase>.java
ports/*.java
adapters/*.java
docs/modernization-candidate-001.md
docs/risk-backlog.md

#60-Tage-Plan

#Tage 31–45

  • 3–5 zentrale Use Cases analysieren
  • Transaktionsmatrix vervollständigen
  • Queue- und SOAP-Katalog vervollständigen
  • Security Map erstellen
  • JNDI zentralisieren
  • erste EJB-Fassaden dünner machen

#Tage 46–60

  • automatisierte Regression für Haupt-Use-Cases
  • Outbox-Kandidaten identifizieren
  • nicht-idempotente MDBs absichern
  • erste technische Spike-Migration:
    • Jakarta EE Runtime
    • Spring Boot Slice
    • Quarkus Slice
  • Entscheidungsvorlage für Zielplattform erstellen

#90-Tage-Plan

#Tage 61–75

  • Java-Version-Upgrade prüfen
  • Dependencies auditieren
  • Build modernisieren
  • Deployment pipeline stabilisieren
  • Observability ausbauen
  • zentrale Adapter fertigstellen

#Tage 76–90

  • erstes produktionsnahes Modernisierungs-Slice
  • Legacy-Fassade + neuer Kern
  • Rollback-Plan
  • Performance-Vergleich
  • Betriebsdokumentation
  • Roadmap für weitere Slices

#Prioritätenliste für dich als Senior Java Entwickler

  1. JTA und EJB Transaction Semantics
  2. EJB Lifecycle, Proxies und Interceptors
  3. JMS, MDB, Redelivery und Idempotenz
  4. SOAP/WSDL/XSD/JAXB und Contract Tests
  5. JPA im Container
  6. JNDI, Datasources und Classloading
  7. JSP/Servlet/Session/Security
  8. Build, EAR/WAR/EJB-JAR, App Server
  9. Charakterisierungstests und Golden Master
  10. Ports/Adapter und Use-Case-Extraktion
  11. Jakarta/Spring/Quarkus Zielplattform
  12. Outbox, Events und schrittweise Entkopplung

#Was du nicht zuerst tun solltest

Nicht zuerst:

  • alle EJBs löschen
  • sofort Spring Boot draus machen
  • javax.* blind nach jakarta.* ersetzen
  • JSP durch React ersetzen
  • DB-Schema groß umbauen
  • SOAP-Verträge ändern
  • Queue-Namen ändern
  • Transaktionsattribute ändern
  • REQUIRES_NEW entfernen
  • XA abschalten
  • Microservices schneiden

Erst verstehen, testen und kapseln.

#Lernressourcen und Referenzen

Offizielle / primäre Referenzpunkte:

  • Jakarta EE 11 Platform: https://jakarta.ee/specifications/platform/11/
  • Jakarta EE 11 Release: https://jakarta.ee/release/11/
  • Spring Boot Reference Documentation: https://docs.spring.io/spring-boot/
  • Spring Boot System Requirements: https://docs.spring.io/spring-boot/system-requirements.html
  • Quarkus: https://quarkus.io/
  • Quarkus Guides: https://quarkus.io/guides/
  • OpenRewrite Java Migration Recipes: https://docs.openrewrite.org/recipes/java/migrate
  • OpenRewrite Upgrade to Java 17: https://docs.openrewrite.org/recipes/java/migrate/upgradetojava17
  • OpenRewrite Upgrade to Java 21: https://docs.openrewrite.org/recipes/java/migrate/upgradetojava21
  • Eclipse Transformer: https://projects.eclipse.org/projects/technology.transformer
  • Tomcat Jakarta EE Migration Tool: https://github.com/apache/tomcat-jakartaee-migration

#Merksätze

text
Modernisierung ist kein Rewrite.
Modernisierung ist kontrollierte Risikoreduktion.
text
EJB ist nicht nur eine alte Service-Klasse.
EJB ist oft Transaktion, Security, Pooling, Remoting und Lifecycle.
text
SOAP ist nicht nur altes XML.
SOAP ist oft ein Vertrag.
text
JMS ist nicht nur Queue-Technik.
JMS ist oft ein versteckter Workflow.
text
JSP ist nicht nur View.
JSP enthält in Legacy-Systemen oft Businesslogik.
text
Transaktionen sind fachliche Grenzen.
Nicht nur technische Annotationen.
text
Der erste gute Schritt ist fast immer:
Interface einführen, Adapter bauen, Verhalten testen.

#Abschlussziel

Nach diesem Lernpfad solltest du für jeden wichtigen Use Case sagen können:

text
Dieser Use Case startet hier.
Diese Klassen sind beteiligt.
Diese Transaktion läuft.
Diese Tabellen werden geschrieben.
Diese Messages werden gesendet.
Diese externen Calls passieren.
Diese Fehler führen zu Rollback.
Diese Fehler führen zu Retry.
Diese Komponente kann ich kapseln.
Diese Komponente darf ich noch nicht anfassen.
Das ist der sichere nächste Modernisierungsschritt.

Wenn du das kannst, bist du bereit, das Legacy-System nicht nur zu verstehen, sondern strategisch zu modernisieren.

← Legacy Java Enterprise Modernisierung — thematische Navigation
Projektinventur, Reverse Engineering und Entry Points →
Offline-fähige HTML-Version aus dem thematisch strukturierten Markdown-Lernpfad.
⌂ Cockpit