Novaris Versicherung - Projektdokumentation

EJB/WebSphere-Legacy-Lernprojekt und seine Migration auf Spring Boot/Jakarta EE/OpenShift - komplette Doku als navigierbare HTML-Uebersicht.

Projekt

Novaris Versicherung AG — Legacy- und Modernisierungs-Lernprojekt

Lernprojekt fuer eine umfangreiche, realistische Java-8/WebSphere-Legacy-Enterprise- Landschaft: EJB (Stateless/Stateful/Message-Driven/Singleton-Timer), SOAP (Client +…

Ueberblick

Novaris Versicherung AG — Systemlandschaft

Dieses Dokument gibt den Gesamtueberblick ueber das Lernprojekt: welche fiktive Systemlandschaft wir nachbauen, warum sie so aussieht, wie sie aussieht, und in welchen…

EJB-Konzepte

Java EE: die Plattform, auf der alles hier aufbaut

Bevor es um EJB im Detail geht, lohnt sich der Blick auf die Ebene darueber: Java EE selbst. EJB, JMS, JAX-WS und JPA sind keine unabhaengigen Bibliotheken, die man…

Session Beans: Stateless, Stateful, Singleton

Session Beans sind der Kern der Geschaeftslogik in diesem Projekt. Es gibt drei Spielarten, alle in novaris-policy-core vertreten - jede loest ein anderes Problem.

Message-Driven Beans (MDB)

Beispiel: ClaimIntakeMDB.

Transaktionen: Container-Managed (CMT) vs. Bean-Managed (BMT)

Dieses Projekt zeigt beide Modelle nebeneinander, absichtlich an zwei verschiedenen Beans: PolicyManagementBean (CMT, der EJB-Normalfall) und PremiumCalculationBean…

EJB Timer Service

Beispiel: PolicyRenewalTimerBean.

Interceptors

Beispiel: AuditInterceptor, gebunden an PolicyManagementBean und PremiumCalculationBean.

Exceptions in EJB: Application vs. System Exceptions

Das ist einer der am haeufigsten missverstandenen Teile des EJB-Modells - und einer der Gruende, warum "EJB verstehen" oft schwerer faellt, als es sein muesste. Dieses…

JNDI, Deployment-Deskriptoren und Packaging

JNDI (Java Naming and Directory Interface) ist der Mechanismus, ueber den Java-EE-Komponenten Ressourcen (Datenquellen, JMS-Ziele, andere EJBs) per Namen statt per…

JNDI wirklich verstehen

Dieses Dokument ist bewusst eigenstaendig und langsamer als docs/10-ejb-konzepte/07-jndi-und-packaging.md - dort wird JNDI vorausgesetzt und im Zusammenspiel mit…

SOAP

SOAP: Contract-First und WSDL

Beispiel: novaris-billing-soap/src/main/resources/wsdl/BillingService.wsdl.

SOAP: Service-Implementierung und Client-Aufruf

Beispiel: BillingServiceEndpoint in novaris-billing-soap.

SOAP Faults

Beispiel: BillingRegistrationFault + BillingFaultDetail in novaris-common-legacy, geworfen von BillingServiceEndpoint, behandelt in BillingIntegrationBean.

JMS/MQ

JMS: Queues vs. Topics

Bevor es um die konkreten Muster (Request/Reply, Publish/Subscribe) geht, lohnt sich die Grundunterscheidung, auf der alles andere aufbaut.

JMS Request/Reply

Beispiele: ClaimSubmissionClient (novaris-claims-mq, Sender/Empfaenger der Antwort), ClaimIntakeMDB.sendReply(...) (novaris-policy-core, Empfaenger der Anfrage/Sender…

Topics, durable Subscriptions und Message-Selektoren

Beispiele: PolicyEventPublisherBean (Publisher), PolicyDocumentGenerationMDB + CustomerNotificationMDB (zwei unabhaengige Abonnenten), beide novaris-notification-jms.

Von ActiveMQ zu echtem IBM MQ: was sich wirklich aendert

Beispiel: IbmMqRequestReplyIT (novaris-integration-tests) gegenueber den ActiveMQ- basierten Tests aus Phase 1-3 (ClaimSubmissionRequestReplyTest…

Persistence (Oracle/DB2)

Datasources und J2C-Authentication-Aliases

Die duale Persistenz (Oracle fuer den aktiven Policenbestand, DB2 fuer die Alt-Vertraege) ist bereits in Phase 1 code-seitig erklaert (Policy, LegacyContractDao…

DB2: bewusst nur dokumentiert, nicht in Phase 5 verifiziert

Anders als Oracle (OraclePersistenceIT) und IBM MQ (IbmMqRequestReplyIT) wird DB2 in diesem Projekt nicht gegen einen tatsaechlich laufenden Container verifiziert. Diese…

JPA gegen echtes Oracle verifiziert

Beispiel: OraclePersistenceIT (novaris-integration-tests).

WebSphere-Konfiguration

Legacy-Auth: JAAS Custom Login Module und LTPA

Beispiel: NovarisLegacyLoginModule + LegacyUserDirectory (novaris-policy-web-legacy-jsf).

EAR-Packaging und Deployment

Beispiel: novaris-policy-ear (bundelt novaris-policy-core + novaris-policy-web-legacy-jsf).

Open Liberty: Serverstart verifiziert, automatisches EAR-Deployment (noch) nicht

Modul: novaris-policy-ear, Maven-Profil liberty-verify (siehe dessen pom.xml-Kommentare fuer alle Details), Konfiguration in src/main/liberty/config/server.xml.

CI/CD

Vier Stages: LOCAL, TEST, QS, PROD

Dieses Kapitel beschreibt, wie eine Aenderung an der Novaris-Landschaft von der Entwicklung bis in den (simulierten) Produktivbetrieb wandert - unabhaengig davon…

Das Jenkinsfile im Detail

Wichtiger Hinweis vorab: Fuer dieses Lernprojekt stand kein echter Jenkins-Server zur Verfuegung - das Jenkinsfile selbst konnte deshalb nicht gegen einen echten Jenkins…

LOCAL: Entwicklung in IntelliJ

Siehe 01-vier-stages-ueberblick.md fuer die Begruendung, warum LOCAL bewusst kein Jenkins-Job ist. Dieses Kapitel beschreibt, wie die LOCAL-Stage stattdessen aussieht …

Migration (M0-M7)

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

novaris-legacy-parent wurde bewusst zuerst vollstaendig als "Vorher"-Zustand gebaut - ein authentisches WebSphere/EJB-Altsystem mit allen typischen Eigenschaften…

Versionsstrategie: warum zwei Etappen statt einer

Der urspruengliche Wunsch war "Java 11 und Spring Boot und Jakarta EE weg von Java EE" - alles gleichzeitig. Das geht technisch nicht:

Component-Mapping: EJB/Java-EE-Konzept -> Spring/Cloud-native-Entsprechung

Diese Tabelle ist der Kern der Migrationsdoku - fuer jedes EJB-/Java-EE-Konzept aus docs/10-ejb-konzepte/ steht hier die konkrete Entsprechung im modernen Reactor, mit…

Messaging-Redesign: JMS/IBM MQ -> Kafka (AMQ Streams)

Oracle und DB2 bleiben laut 00-uebersicht.md bewusst unveraendert - reine Infrastruktur, kein Grund fuer einen Applikationsumbau. Bei IBM MQ ist die Entscheidung eine…

Phasenroadmap M0-M7

Spiegelt den bewaehrten Phasenrhythmus des Legacy-Aufbaus (Phase 0-5, je 2-3 thematische Commits pro Phase).

Git/GitHub-Workflow dieses Projekts

Dokumentiert den tatsaechlich verwendeten git/gh-Workflow - vom lokalen Repo bis zum gemergten Pull Request. Nachtraeglich erstellt (offener Punkt aus der…

Refactoring-Taxonomie: drei genau unterschiedene Aenderungsarten

"Migration" wird in diesem Projekt oft als Sammelbegriff verwendet, verdeckt dabei aber drei fachlich sehr unterschiedliche Dinge. Diese Doku legt die drei Kategorien…

OpenShift-Deployment und Jenkins-Pipeline (Migrationsphase M5)

Letzter Schritt der Migration, wie von Anfang an vom Nutzer verlangt ("zuletzt ... migrieren"). Ersetzt WebSphere-Liberty-EAR-Deployment und Liberty-server.xml durch…

Draft-Cleanup-Scheduler (Migrationsphase M6)

Erste von fuenf Erweiterungen aus M6 - Nachruestung eines in M2 bewusst offen gelassenen Punkts: PolicyApplicationDraft (Ersatz fuer den zustandsbehafteten…

Zwei offene Punkte geschlossen: Kafka Dead-Letter-Topic und echte DB2-Anbindung (M6)

Zweite und dritte Erweiterung aus M6 - beide schliessen einen in fruehen M6-Vorgaenger-Phasen bewusst offen gelassenen Punkt, deshalb hier gemeinsam dokumentiert.

Observability: Micrometer Tracing + Zipkin (Migrationsphase M6)

Vierte Erweiterung aus M6. Ein Geschaeftsvorfall (z. B. eine Schadenmeldung) durchlaeuft in der modernen Landschaft mehrere Prozessgrenzen: REST-Aufruf in…

OIDC/Keycloak statt HTTP Basic (Migrationsphase M6)

Fuenfte und letzte Erweiterung aus M6. Loest den in SecurityConfigs eigenem Javadoc (aus M4) bereits benannten "naheliegenden naechsten Ausbauschritt" ein: HTTP Basic +…

Zwei blockierende Bugs behoben: Kafka-Publish und DB2-Benchmark-Lookup

Nachtraeglich behobener, in 10-observability-tracing.md urspruenglich nur als offener Nebenbefund dokumentierter Bug - plus ein zweiter, strukturell identischer Bug, der…

Frontend: novaris-policy-web-modern-spa (Migrationsphase M7)

Loest den seit M0 in 02-component-mapping.md als spaeteres Ziel benannten, aber nie gebauten Punkt ein: ein eigenstaendiges Frontend fuer novaris-policy-core-modern…

Verifikationsstatus nach M7

Nicht live erreichbare Infrastruktur wird bewusst als „vorbereitet“ und nicht als „verifiziert“ bezeichnet.

Gemeinsame Infrastruktur

Das Projekt verwendet für lokale Infrastruktur die projektübergreifende Umgebung unter ../../shared/enterprise-infrastructure/. Dort laufen gemeinsame Dienste nur einmal…

Verbesserungsvorschlaege nach M7

Die sinnvollste naechste Reihenfolge nach M0-M7 ist:

Git-Reparatur: einen zu grossen Commit sinnvoll aufteilen

Beim Arbeiten am Verbesserungsplan kann es passieren, dass mehrere fachliche Themen versehentlich in einem Sammelcommit landen. Das ist kein Grund, die Projektdateien zu…

Exkurs: Podman im Novaris-Projekt

Podman ist die Container-Runtime fuer die lokale Entwicklung und passt gut zur OpenShift-Zielplattform. Die Bedienung ist Docker sehr aehnlich, Podman arbeitet jedoch…

Einfuehrung in Podman

Dieser Text ist eine allgemeine Grundlagen-Einfuehrung in Podman, unabhaengig vom konkreten Projekt. Wer bereits Docker kennt, findet fast alles wieder; wer noch nie mit…

Legacy-Reactor (Module)

novaris-billing-soap

Das Abrechnungs-/Billing-Partnersystem der Novaris-Landschaft - ein klassischer JAX-WS- SOAP-Service, den novaris-policy-core als Client anspricht (siehe…

novaris-claims-mq

Das Schaden-Teilsystem der Novaris-Landschaft - sendet Schadensmeldungen per klassischem JMS-Request/Reply an ClaimIntakeMDB (novaris-policy-core) und wartet synchron…

novaris-common-legacy

Geteilte Bausteine, die von mehreren Novaris-Teilsystemen verwendet werden - bewusst als eigenes, sehr kleines Modul gehalten, damit z.B. novaris-billing-soap (Server)…

novaris-integration-tests

Verifiziert die Novaris-Landschaft gegen echte Infrastruktur statt Ersatz-Implementierungen:

novaris-notification-jms

Zwei unabhaengige Abonnenten des Policy-Events-Topics - zeigt JMS Publish/Subscribe im Kontrast zum Point-to-Point-Request/Reply in novaris-claims-mq. Siehe…

novaris-policy-core

Der EJB-Kern der Policenverwaltung - das zentrale Modul dieses Projekts und der Ort, an dem die meisten EJB-Konzepte konkret zu sehen sind (siehe docs/10-ejb-konzepte/).

novaris-policy-ear

Buendelt novaris-policy-core (EJB-Modul) und novaris-policy-web-legacy-jsf (Web-Modul) zu der einen deploybaren Einheit, die WebSphere tatsaechlich als Anwendung…

novaris-policy-web-legacy-jsf

Das "Novaris-Kundenportal" - JSF/Facelets-Weboberflaeche fuer Policenuebersicht und Antragserfassung, mit klassischem WebSphere-Legacy-Auth. Bewusst mit dem Suffix…

Modern-Reactor (Module)

novaris-modern-parent

Migrationsziel des Novaris-Lernprojekts: dieselbe fachliche Policen-/Schadenlandschaft wie novaris-legacy-parent, neu gebaut auf Spring Boot statt EJB/WebSphere, auf…

Keycloak-Demo-Realm

novaris-realm.json enthält nur Realm-, Client- und Rollenstruktur. Es enthält bewusst keine Passwörter und ist nicht als Produktionskonfiguration gedacht.

novaris-claims-modern

Spring-Boot-Gegenstueck zu novaris-legacy-parent/novaris-claims-mq. Sendet Schadensmeldungen per Kafka-Request/Reply an ClaimIntakeKafkaListener…

novaris-common-modern

Geteilte Bausteine des modernen Reactors - das funktionale Gegenstueck zu novaris-legacy-parent/novaris-common-legacy.

novaris-notification-modern

Spring-Boot-Gegenstueck zu novaris-legacy-parent/novaris-notification-jms. Zwei unabhaengige Abonnenten desselben Kafka-Topics - zeigt Publish/Subscribe im Kontrast zum…

novaris-policy-core-modern

Spring-Boot-Gegenstueck zu novaris-legacy-parent/novaris-policy-core. Baut dieselbe Fachlogik (Policenverwaltung, Praemienberechnung, Audit, Verlaengerungspruefung…

novaris-policy-web-modern-spa

React/TypeScript-SPA fuer novaris-policy-core-modern - Umsetzung der zuvor nur als Ziel benannten novaris-policy-web-modern-spa-Luecke (siehe…

OpenShift-Manifeste (Migrationsphase M5/M7)

Letzter Schritt der Migration - Deployment des modernen Reactors auf OpenShift, wie von Anfang an geplant ("zuletzt ... auf OpenShift migrieren"). Ersetzt das…

Sonstiges

Novaris — Arbeitsregeln für KI-Agenten

Vergleichsreaktor erhalten.

⌂ Cockpit