#Master-Checklisten, Praxisplan und nächste Schritte
Abschlusskapitel mit Checklisten, persönlichem Lernplan, Praxisplan und Übergang zum echten Projekt.
#Master-Abschluss, Gesamt-Checklisten, persönlicher Lernplan, Praxisplan und Übergang zum echten Projekt
Dieser Abschlussblock beendet den Master-Lernpfad. Bis hierhin wurde ein alter Java-Enterprise-Monolith mit EJB, JTA, JMS, SOAP, JSP, JPA, JNDI, Application Server, Transaktionen, Security, Deployment, Observability, Datenbankmigration und Plattformmigration systematisch betrachtet.
Das Ziel ab jetzt ist nicht mehr, noch mehr Theorie zu sammeln. Das Ziel ist, das Gelernte auf ein echtes Projekt anzuwenden.
#Gesamtbild des Lernpfads
Der Lernpfad hatte bewusst drei große Bewegungen:
1. Verstehen
- Inventar
- Entry Points
- EJBs
- JTA
- JMS
- SOAP
- JSP
- DB
- Security
- Deployment
2. Stabilisieren
- Characterization Tests
- Smoke Tests
- Contract Tests
- Logging
- Metrics
- Tracing
- Runtime Checks
- Risiko-Backlog
3. Modernisieren
- Use Cases extrahieren
- Ports und Adapter einführen
- Legacy-Fassaden dünner machen
- Outbox und Idempotenz einführen
- Zielplattform wählen
- Cutover planen
Der wichtigste Zusammenhang:
Ohne Verstehen keine sichere Stabilisierung.
Ohne Stabilisierung keine sichere Modernisierung.
Ohne Modernisierung kein nachhaltiger Plattformwechsel.
#Master-Checkliste — Legacy-Projekt verstehen
Diese Checkliste verwendest du beim Start mit einem echten Projekt.
#Runtime
| Frage | Antwort |
|---|---|
| Java-Version | |
| Application Server | |
| Java EE / Jakarta EE Version | |
| Build Tool | |
| Deployment-Art | EAR / WAR / EJB-JAR |
| Datenbank | |
| JMS Provider | |
| SOAP Stack | JAX-WS / CXF / Axis / Metro |
| Authentifizierung | JAAS / LDAP / SSO / Custom |
#Module
| Modul | Typ | Zweck | Risiko |
|---|---|---|---|
| legacy-web | WAR | JSP/Servlet UI | |
| legacy-ejb | EJB-JAR | Business Services | |
| legacy-soap | WAR | SOAP Endpoints | |
| legacy-ear | EAR | Deployment | |
#Entry Points
| Entry Point | Technologie | Klasse/Datei | Zweck | Risiko |
|---|---|---|---|---|
| /order/create.jsp | JSP | create-order.jsp | Bestellung anlegen | hoch |
| CustomerEndpoint | SOAP | CustomerEndpoint.java | Kunden aktualisieren | mittel |
| InvoiceMDB | JMS | InvoiceMessageBean.java | Rechnung erzeugen | hoch |
| BillingTimer | Timer | BillingTimerBean.java | Nachtlauf | hoch |
#Container-Magie
Suche und dokumentiere:
@Stateless
@Stateful
@Singleton
@MessageDriven
@TransactionAttribute
@ApplicationException
@RolesAllowed
@PermitAll
@DenyAll
@Resource
@EJB
@PersistenceContext
@WebService
@WebServiceRef
@Schedule
InitialContext
UserTransaction
SessionContext
#Master-Checkliste — Transaktionen und Side Effects
Für jeden wichtigen Use Case brauchst du eine Transaction Map.
# Transaction Map: <Use Case>
## Main Transaction
- Startklasse:
- Startmethode:
- TransactionAttribute:
- Startet neue Transaktion? ja/nein
## Beteiligte Ressourcen
| Ressource | Typ | Innerhalb TX? | Bemerkung |
|---|---|---|---|
| ORDERS | DB | ja | Insert/Update |
| AUDIT_LOG | DB | REQUIRES_NEW | bleibt bei Rollback |
| PaymentProvider | SOAP | ja/nein | kritisch |
| OrderQueue | JMS | ja/nein | XA prüfen |
## Rollback
| Fehler | Checked? | Rollback? | Gewollt? |
|---|---|---|---|
| PaymentFailedException | ja/nein | | |
| ValidationException | ja/nein | | |
| RuntimeException | nein | ja | |
## Kritische Stellen
- REQUIRES_NEW:
- NOT_SUPPORTED:
- UserTransaction:
- setRollbackOnly:
- SOAP innerhalb TX:
- JMS innerhalb TX:
- lange DB-Locks:
Merksatz:
Bei Legacy Enterprise Java ist die Transaktion oft wichtiger als die Methode selbst.
#Master-Checkliste — Modernisierungskandidaten bewerten
Jede Komponente bekommt eine Strategie.
| Komponente | Typ | Risiko | Änderungshäufigkeit | Strategie |
|---|---|---|---|---|
| OrderServiceBean | EJB | hoch | hoch | EXTRACT |
| PaymentSoapClient | SOAP Client | hoch | mittel | WRAP |
| InvoiceMDB | MDB | hoch | mittel | EXTRACT |
| createOrder.jsp | JSP | mittel | niedrig | WRAP/EXTRACT |
| AuditServiceBean | EJB | hoch | niedrig | KEEP |
Strategien:
KEEP = vorerst behalten
WRAP = hinter Interface kapseln
EXTRACT = Fachlogik in Plain Java ziehen
REPLACE = Technologie ersetzen
DELETE = nach Nachweis entfernen
SPLIT = fachlich trennen
Ein guter erster Kandidat ist:
- fachlich relevant
- technisch überschaubar
- gut testbar
- keine extremen Security-/XA-/Batch-Abhängigkeiten
- keine kritische Zahlungs- oder Abrechnungslogik als erster Versuch
#Master-Checkliste — Tests und Schutznetz
Modernisierung ohne Tests ist kontrolliertes Raten.
Du brauchst mindestens diese Testebenen:
| Testtyp | Zweck | Priorität |
|---|---|---|
| Smoke Test | App startet, Login, Hauptflow | P1 |
| Characterization Test | aktuelles Verhalten dokumentieren | P1 |
| Plain Java Unit Test | neuer Kern ohne Container | P1 |
| Integration Test | DB/JMS/SOAP Adapter prüfen | P2 |
| Contract Test | SOAP/XML/REST-Verträge schützen | P2 |
| Transaction Test | Rollback/Commit prüfen | P1 bei kritischen Flows |
| Idempotenztest | doppelte Messages verhindern | P1 bei JMS/Outbox |
Minimaler Einstieg:
1. Ein Smoke Test
2. Ein Characterization Test für einen kritischen Use Case
3. Ein Plain-Java-Test für den extrahierten Use Case
4. Ein Idempotenztest für einen Consumer
Beispiel für eine gute Testaussage:
Wenn Payment fehlschlägt,
wird kein OrderPaid Event erzeugt.
Beispiel für eine schlechte Testaussage:
Die Methode gibt nicht null zurück.
#Persönlicher Lernplan für dich als Senior Java Entwickler
Du musst nicht Java von vorne lernen. Du brauchst Enterprise-Runtime-Kompetenz plus Modernisierungspraxis.
#Woche 1: Legacy-Projekt lesen
- EAR/WAR/EJB-JAR-Struktur verstehen
- App-Server-Konfiguration lesen
- JNDI-Ressourcen dokumentieren
- EJB-Liste erstellen
- Entry-Point-Katalog erstellen
Ergebnis:
Du weißt, wie das System deployed wird und wo die wichtigsten Einstiegspunkte sind.
#Woche 2: Transaktionen und Side Effects
- @TransactionAttribute analysieren
- REQUIRES_NEW finden
- UserTransaction finden
- DB Writes dokumentieren
- SOAP/JMS innerhalb Transaktionen markieren
Ergebnis:
Du weißt, wo Commit, Rollback und Inkonsistenzen entstehen können.
#Woche 3: JMS, SOAP, JSP
- MDBs analysieren
- Queues/Topics dokumentieren
- Redelivery/DLQ prüfen
- WSDL/XSD/SOAP Clients erfassen
- JSPs nach Businesslogik scannen
Ergebnis:
Du verstehst die synchronen und asynchronen Integrationspunkte.
#Woche 4: Tests und Observability
- Smoke Test bauen
- Characterization Test schreiben
- Correlation ID einführen
- strukturierte Logs ergänzen
- Fehlerfälle clustern
Ergebnis:
Du kannst Änderungen besser beobachten und absichern.
#Woche 5–6: Erster Modernisierungs-Slice
- eine zentrale EJB auswählen
- Use Case extrahieren
- Ports definieren
- Adapter bauen
- EJB als Fassade behalten
- Tests ergänzen
Ergebnis:
Ein echter Teil des Systems ist modernisierungsfähig, ohne Big Bang.
#Woche 7–8: Outbox, Idempotenz, Risikoabbau
- direkte JMS Sends prüfen
- Outbox-Kandidaten identifizieren
- Consumer idempotent machen
- Payment/externen SOAP Call aus langer TX lösen
- Monitoring für Outbox und Messages ergänzen
Ergebnis:
Die gefährlichsten Integrationsrisiken sind sichtbar und teilweise reduziert.
#Praxisplan — die ersten 10 Arbeitstage im echten Projekt
#Tag 1: Repository und Build
- Projekt lokal auschecken
- Build starten
- Buildfehler dokumentieren
- Module und Artefakte auflisten
- docs/legacy-inventory.md anlegen
#Tag 2: Runtime und Deployment
- Application Server identifizieren
- Deployment-Struktur dokumentieren
- EAR/WAR/EJB-JAR prüfen
- Datasources und JMS-Ressourcen erfassen
#Tag 3: EJB und Entry Points
- alle @Stateless/@Stateful/@MessageDriven finden
- SOAP Endpoints finden
- JSP/Servlet Entry Points erfassen
- Timer/Scheduler finden
#Tag 4: Transaktionen
- @TransactionAttribute suchen
- REQUIRES_NEW markieren
- UserTransaction markieren
- Exception/Rollback-Regeln dokumentieren
#Tag 5: Ersten Use Case auswählen
- mittleres Risiko wählen
- nicht Payment/Billing/Login als erstes
- Call Chain starten
- docs/use-cases/use-case-001.md anlegen
#Tag 6: Call Chain vervollständigen
- Entry Point
- EJBs
- DAOs
- SOAP Calls
- JMS Sends
- DB Writes
- Security Checks
#Tag 7: Transaction Map und Risikoanalyse
- Haupttransaktion markieren
- Nebentransaktionen markieren
- externe Calls markieren
- Risiko-Backlog aktualisieren
#Tag 8: Smoke oder Characterization Test
- Hauptverhalten dokumentieren
- Test oder manueller Testablauf festhalten
- Testdaten definieren
#Tag 9: Erster kleiner Refactoring-Schnitt
- Command einführen
- Port definieren
- Adapter vorbereiten
- keine Transaktion ändern
- keinen Vertrag ändern
#Tag 10: Review und nächster Slice
- Verhalten vergleichen
- Risiken aktualisieren
- offenen Punkt entscheiden
- nächsten Slice auswählen
#Abschluss-Checkliste vor jeder Modernisierung
Bevor du eine Legacy-Komponente veränderst, prüfe:
| Frage | Ja/Nein |
|---|---|
| Ist der fachliche Zweck verstanden? | |
| Ist der Entry Point bekannt? | |
| Ist die Call Chain dokumentiert? | |
| Sind Transaktionsgrenzen dokumentiert? | |
| Sind DB Writes bekannt? | |
| Sind JMS/SOAP Side Effects bekannt? | |
| Sind Rollback-Regeln bekannt? | |
| Gibt es REQUIRES_NEW? | |
| Gibt es Security-Prüfungen? | |
| Gibt es Tests oder Smoke-Test? | |
| Ist der erste Schritt strukturell statt verhaltensändernd? | |
| Gibt es Rollback-Plan? | |
Wenn mehrere Antworten unbekannt sind, modernisierst du noch nicht. Dann analysierst du zuerst.
#Die wichtigsten Merksätze des gesamten Lernpfads
1. Code lesen reicht nicht. Du musst Container-Verhalten lesen.
2. EJB ist nicht nur eine Klasse. EJB bedeutet Transaktion, Security, Pooling, Lifecycle, Remoting und Container-Kontext.
3. @Transactional ist nicht automatisch dasselbe wie @TransactionAttribute.
4. SOAP ist oft ein Vertrag, nicht nur eine alte API.
5. JMS bedeutet at-least-once denken. Idempotenz ist Pflicht.
6. JSP zuerst von Businesslogik befreien, danach UI ersetzen.
7. Outbox reduziert Kopplung, bringt aber Betriebsverantwortung.
8. Nicht Technologie zuerst modernisieren, sondern Grenzen.
9. Der erste sichere Schritt ist meistens WRAP oder EXTRACT, nicht REPLACE.
10. Eine gute Migration ist langweilig, beobachtbar und rollbackfähig.
#Übergang zum echten Projekt
Der Master-Lernpfad ist jetzt abgeschlossen.
Ab jetzt sollte die Arbeit nicht mehr abstrakt weitergehen. Der nächste sinnvolle Schritt ist, ein echtes Projekt-Slice zu analysieren.
#Was du mir als Nächstes geben kannst
Am besten eines davon:
1. Projektstruktur / tree
2. pom.xml oder build.gradle
3. eine zentrale @Stateless EJB
4. eine @MessageDriven Bean
5. einen SOAP Endpoint
6. eine JSP mit Businesslogik
7. persistence.xml
8. web.xml / ejb-jar.xml / application.xml
#Beste nächste Eingabe
Führe im Projektroot aus:
tree -L 4 -I "target|build|.git|.idea|.gradle|node_modules"
Falls tree nicht installiert ist:
find . -maxdepth 4 \
-not -path "*/target/*" \
-not -path "*/build/*" \
-not -path "*/.git/*" \
-not -path "*/.idea/*"
Dann kann daraus entstehen:
- echtes Legacy Inventory
- echte Entry-Point-Liste
- erste Transaction Map
- erstes Modernization Candidate Dokument
- erster Refactoring-Plan
- erste Tests
#Finaler Arbeitsmodus ab jetzt
Nicht mehr:
Lernpfad erweitern.
Sondern:
Echten Code analysieren.
Einen Slice auswählen.
Risiko reduzieren.
Kern extrahieren.
Tests schreiben.
Schrittweise modernisieren.
Damit ist der Master-Lernpfad vollständig genug, um mit einem echten alten Java-Enterprise-Projekt sicher und strukturiert zu starten.