Gesamtlandschaft und Denkmodell
Wie fachliche Prozesse, technische Plattformen, Integrationswege, Datenbesitz, Betriebsmodell und Modernisierung zusammenhaengen.
Ein deutsches Verständnis-Lehrbuch für Senior-Java-/Enterprise-Modernisierung: Mainframe, Java EE, SOAP/ESB, MQ, Oracle, Batch, Legacy UI, ETL, Security und Reporting. Jede Systemseite enthält fachliche Erklärung, technische Darstellung, Code-/Konfigurationsbeispiele, Risiken, Modernisierungsmuster und Übungsaufgaben.
Wie fachliche Prozesse, technische Plattformen, Integrationswege, Datenbesitz, Betriebsmodell und Modernisierung zusammenhaengen.
Zentrale Transaktionslogik, Buchungen, Vertragsfuehrung, Policenverwaltung oder Kundenstammdaten mit sehr hoher Stabilitaet.
Klassische EAR/WAR/EJB-Anwendung mit Session Beans, JTA, JDBC/JPA, SOAP, JSP/JSF und serverseitigem Deployment.
WSDL-basierte Services, XML-Schemas, Routing, Transformation, Orchestrierung, Fehlerkanal und Vertragsstabilitaet.
Entkopplung ueber Queues, garantierte Zustellung, Dead Letter Queues, Retry, Reihenfolge und idempotente Verarbeitung.
Tabellen, Views, Packages, Trigger, Stored Procedures und Reporting-Abfragen als versteckte Fachlogik.
Periodische Verarbeitung mit Jobketten, Abhaengigkeiten, Zeitfenstern, Wiederanlauf, Kontrolltabellen und Abschlussberichten.
Serverseitige Masken, Session State, Validierung, Berechtigungen und fachliche Workflows fuer Sachbearbeitung.
CSV/XML/Fixed-Width-Dateien, SFTP, ETL-Strecken, Staging-Tabellen, Datenqualitaet und Reporting-Lieferketten.
Authentifizierung, Autorisierung, Rollen, technische Benutzer, Zertifikate, SSO, Audit und Berechtigungsmigration.
Berichte, regulatorische Nachweise, Archivdaten, Revisionsspuren, Datenaufbewahrung und historische Nachvollziehbarkeit.
Jede Systemseite enthaelt nun laengere Erklaerungen, typische Artefakte, Ablaufmodelle, Risiken, Modernisierungspfad und Uebung.
COBOL Copybook, EJB/JTA, WSDL/XSD/XSLT, MDB/JMS, PL/SQL, Batch, Struts/JSP, ETL, LDAP und Audit-Beispiele.
Jedes System hat eine fachliche und eine technische SVG-Darstellung.
Strangler Fig, Anti-Corruption Layer, Facade, Adapter, Golden Master Test, Outbox und Idempotent Consumer werden systembezogen eingeordnet.
Arbeite nicht von Technologie zu Technologie, sondern von fachlicher Fähigkeit zu technischer Kopplung: Datenhoheit, Transaktion, Schnittstelle, Fehlerkanal, Betrieb und Nachweis. Erst danach sollte entschieden werden, ob ein Teil refactored, gekapselt, ersetzt, stranguliert oder unverändert stabilisiert wird.
| Pattern | Zweck |
|---|---|
| Strangler Fig Pattern | Altsystem schrittweise ueber neue Routen, APIs oder Prozessanteile ersetzen. |
| Anti-Corruption Layer | Legacy-Begriffe und technische Formate vom neuen Domänenmodell isolieren. |
| Facade | Komplexe Host-, EJB-, SOAP-, MQ- oder DB-Aufrufe hinter einem fachlichen Use Case kapseln. |
| Adapter | Technische Protokolle und Altformate in moderne Ports uebersetzen. |
| Outbox Pattern | Datenbankcommit und Event-Publikation konsistent koppeln. |
| Idempotent Consumer | Doppelte Nachrichten ohne doppelten Fachschaden behandeln. |
| Golden Master Test | Ist-Verhalten mit Referenzdaten sichern, bevor modernisiert wird. |
| Saga / Process Manager | Verteilte Prozesse ohne globale Transaktion koordinieren. |
Eine zentrale Stateless Session Bean mischt Validierung, JPA, JDBC, SOAP, JMS, Audit, Rabatte, Fehlerbehandlung und Transaktionssteuerung in einer Methode.
Ein PL/SQL-Package entscheidet Mahnstufe, Gebühren, Sperren und Historie in einem datenbanknahen Block. Das Refactoring extrahiert Regeln kontrolliert in einen Domain Service.
Ein Message Driven Bean verarbeitet Rechnungsereignisse nicht idempotent. Nach dem Refactoring gibt es Idempotency-Key, Retry-Klassifikation und Outbox/Inbox-Nachweis.
Eine Action-Klasse enthält Session-State, Validierung, Berechtigungen, EJB-Aufruf und JSP-Modellaufbereitung. Das Refactoring trennt Controller, Form Validator, Presenter und Use Case.
Ein Shell/JCL-ähnlicher Nachtjob verarbeitet Dateien, Datenbankupdates und Reports in einem Lauf. Nach dem Refactoring gibt es Steps, Kontrolltabelle, Checkpoints und klare Wiederanlaufpunkte.
Vor der Migration werden EAR, WAR, EJB-JAR, Libraries, Deployment Deskriptoren, Datenquellen, JMS-Ressourcen, Security-Rollen und Betriebsabhängigkeiten sichtbar gemacht.
Aus serverzentriertem Deployment wird ein reproduzierbares Image mit klarer Konfiguration, Health Checks, Ressourcenlimits und OpenShift Deployment.
EJB-, JNDI- und WebSphere-spezifische Kopplung wird über Use Cases, Ports, Adapter und klare Transaktionsgrenzen geschnitten.
JNDI, web.xml, serverseitige DataSources und Admin-Console-Einstellungen werden in versionierbare und sichere OpenShift-Konfiguration überführt.
Globale Containertransaktionen werden analysiert, abgesichert und schrittweise durch klare lokale Transaktionen, Outbox und idempotente Consumer ersetzt.
Aus der Anwendung wird ein betreibbares OpenShift-Artefakt mit Deployment, Service, Route, Ressourcen, Probes, Volumes und Betriebsregeln.
Build, Test, Image-Erzeugung und Deployment werden getrennt und reproduzierbar. Der Clusterzustand wird deklarativ aus Git gesteuert.
Migration endet nicht beim Starten des Pods. Wichtig sind Health Checks, Logs, Metriken, Tracing, Alarme und klare Betriebsanweisungen.
Der Wechsel erfolgt kontrolliert: Shadow Mode, Pilotnutzer, Traffic Split, fachliche Vergleichsmessung, Rückfallplan und schrittweise Abschaltung.
maven-websphere-openshift-demo.docs/design-patterns.md erweitert.