Migration: EJB/WebSphere-Legacy -> Spring Boot/Jakarta EE -> OpenShift

Warum diese Migration

novaris-legacy-parent wurde bewusst zuerst vollstaendig als "Vorher"-Zustand gebaut - ein authentisches WebSphere/EJB-Altsystem mit allen typischen Eigenschaften (Container-verwaltete Beans, JNDI, IBM MQ, DB2/Oracle-Dualitaet, EAR-Deployment). Migration war von Anfang an explizit auf "spaeter" verschoben. Dieses "spaeter" ist jetzt: novaris-modern-parent baut dieselbe Fachlogik neu auf Spring Boot auf, mit dem Endziel OpenShift.

Strategie: Strangler Fig statt In-Place-Umbau

novaris-legacy-parent bleibt unveraendert stehen - als lauffaehige, dokumentierte "Vorher"-Referenz, nicht als Ausgangspunkt fuer schrittweise Refactorings. Ein Vergleich beider Reactors Seite an Seite ist genau der Lerneffekt dieses zweiten Projektteils.
novaris-modern-parent ist ein neuer, eigenstaendiger Reactor im selben Repository, gleiche fiktive Firma (Novaris Versicherung AG), neue groupId com.novaris.modern.
Modulgrenzen sind bewusst an die Legacy-Module gespiegelt (Policy-Core zuerst, dann Billing-Integration, Messaging, Web/Security, Deployment), damit jede EJB-Klasse ihr direktes Spring-Gegenstueck hat - siehe 02-component-mapping.md. Die gemeinsame lokale Infrastruktur wird nicht in diesem Repository dupliziert, sondern ueber ../../shared/enterprise-infrastructure angeschlossen; Details stehen in 15-enterprise-infrastructure.md.

Was unveraendert bleibt

Oracle und DB2 bleiben zunaechst technologisch unveraendert. Diese Migration ist primaer eine Applikations-, keine Infrastruktur-Migration; eine Datenmigration/-konsolidierung waere ein eigenes, deutlich groesseres Vorhaben.
Der Billing-SOAP-Partner (novaris-billing-soap) bleibt unveraendert bestehen - er repraesentiert ein fremdes System, das man in einer echten Migration nicht einfach mit umschreibt. Der neue Policy-Core ruft ihn weiterhin per SOAP-Client auf (Migrationsphase M2).

Was bewusst NICHT unveraendert bleibt: Messaging

Auf ausdruecklichen Wunsch wird IBM MQ nicht mitgenommen. Mit dem Schritt nach OpenShift wird das gesamte Messaging auf AMQ Streams (Kafka) umgestellt - siehe 03-messaging-jms-zu-kafka.md fuer die Begruendung und den konzeptionellen Umbau (Request/Reply und Publish/Subscribe funktionieren in Kafka strukturell anders als in JMS).

Zwei Versionsetappen

Java 11 + Spring Boot + jakarta.*-Namespace lassen sich nicht gleichzeitig erreichen (siehe 01-versionsstrategie.md) - die Migration laeuft deshalb in zwei bewusst getrennten Etappen, Etappe A (jetzt) und Etappe B (Java 17/Spring Boot 3/Jakarta, spaeter).

Phasenroadmap

Details in 04-phasenroadmap.md. Kurzfassung:

Phase	Inhalt	Status
M0	Reactor-Skeleton, Migrationsdoku, Git-Workflow-Doku	fertig
M1	`novaris-common-modern` + `novaris-policy-core-modern`	fertig
M2	SOAP-Client-Anbindung an `novaris-billing-soap` + Antragswizard-Ersatz	fertig
M3	Messaging-Redesign auf Kafka (`novaris-claims-modern`, `novaris-notification-modern`)	fertig
M4	Sprung auf Java 17/Spring Boot 3/Jakarta, Spring Security, Container-Image	fertig
M5	OpenShift-Manifeste (inkl. Strimzi-Kafka), eigenes Jenkinsfile	fertig
M6	Fuenf Erweiterungen: Draft-Cleanup, Kafka-DLT, echte DB2-Anbindung, Observability, OIDC/Keycloak	fertig
M7	React-SPA-Frontend + zwei real gefundene Blocking-Bugs behoben	fertig