Systemlandschaft: Concordia Bank AG

Warum eine fiktive Firma?

Dieses Projekt bereitet auf ein Bewerbungsgespräch für die Rolle "Websphere Application Server Spezialist (WAS)" vor. Die Anzeige beschreibt fast ausschließlich Middleware-Betrieb, kein Java-Coding. Damit jeder einzelne Anzeigen-Punkt an einem konkreten, nachvollziehbaren Szenario demonstriert werden kann (und nicht nur als abstrakte Doku existiert), spielt das Projekt in einer fiktiven Bank mit einer für den WAS-Alltag typischen Systemlandschaft.

Die Firma

Concordia Bank AG — mittelgroße Retail- und Firmenkundenbank. Charakteristisch (und Grund, warum die Rolle aus der Anzeige hier überhaupt gebraucht wird):

Core-Banking auf dem Mainframe ("zentral"): Kontoführung, Buchungen, Zahlungsverkehr laufen auf z/OS gegen DB2 for z/OS. Dieser Teil ändert sich selten, ist hoch reguliert, und wird von einem eigenen Mainframe-Team betrieben.
Kunden-/Mitarbeiterportale und Fachanwendungen auf WebSphere Liberty ("dezentral"): alles, was eine moderne Web-Oberfläche braucht (Kundenportal, Sachbearbeiter-Anwendungen, interne Tools) — läuft auf Linux-Servern, Java-Web-Anwendungen unter Liberty.
Zentrales LDAP-Verzeichnis für Authentifizierung und Rollen — eine Quelle der Wahrheit für "wer darf was", von Liberty über ldapRegistry angebunden statt eigener Nutzerverwaltung pro Anwendung.
Getrennte Netzzonen ("dezentral" vs. "zentral"): die Liberty-Server sprechen nicht direkt mit dem Mainframe-Netz, sondern über klar definierte, von einem Netzwerk-Team verwaltete Verbindungspunkte (Firewall-Freischaltungen, feste Ports) — siehe docs/40-bindeglied-dev-ops-db2-netzwerk/.

Genau in diesem Dreieck — Java-Entwicklung ↔ WAS-Administration ↔ Mainframe-/DB2-/Netzwerk-Team — steht laut Anzeige die gesuchte Rolle als Bindeglied.

Die Beispielanwendung: Concordia Portal

concordia-portal/ ist bewusst eine fachlich triviale Jakarta-EE-Webanwendung (Health-Check, ein JDBC-Test-Endpoint, ein LDAP-gesicherter Endpoint) — sie existiert nur als Vehikel, um echte Liberty-Administrationsarbeit daran zu demonstrieren. Kein Anspruch auf fachliche Tiefe, siehe concordia-portal/pom.xml.

Ausbaustufen (Roadmap)

Jede Ausbaustufe deckt einen zusammenhängenden Block der Anzeige ab und ist einzeln als "verifiziert" oder "dokumentiert/vorbereitet" gekennzeichnet (siehe Ehrlichkeits-Konvention unten).

Ausbaustufe	Anzeigen-Bezug	Doku
1. Installation & Konfiguration	"Installation, Instandhaltung und Konfiguration von Websphere Liberty"	`10-installation-konfiguration/`
2. Security-Lifecycle	"Rollen und Rechte, Zertifikate, SSL"	`60-security-lifecycle/`
3. Monitoring/Tuning	"Monitoring, Troubleshooting und Tuning/Skalierung ... Java Heap, Garbage Collection, Threads, Pools"	`20-monitoring-tuning/`, `30-troubleshooting-runbooks/`
4. Bindeglied Dev/Ops/DB2/Netzwerk	"Bindeglied zwischen Java-Entwicklung und Administration ... sowie DB2 für z/OS, Netzwerk"	`40-bindeglied-dev-ops-db2-netzwerk/`
5. Automatisierung & Deployment	"Implementierung, Durchführung und Automation von Betriebsprozessen sowie Deployment- und Testprozessen", "Bereitstellung ... inkl. Übergabe an den Betrieb und Support"	`50-automatisierung-deployment/`
6. High Availability	"High Availability (24x7 Anwendung) AppServer", "High Availability Messaging"	`70-high-availability/`

Eine vollständige Punkt-für-Punkt-Nachweistabelle (jede Zeile der Anzeige → konkrete Projektstelle) steht am Ende der Umsetzung im Haupt-README.md.

Verifikations-Umgebung dieses Projekts

Liberty: Open Liberty (aktuell installierte Runtime-Version, siehe concordia-portal/pom.xml) über den liberty-maven-plugin, gestartet mit Eclipse Temurin OpenJDK 21 (die auf dieser Maschine installierte JDK) — kein Docker-Image, siehe 10-installation-konfiguration/ für die Begründung.
LDAP: echter osixia/openldap-Container (Podman), Bootstrap-Daten in infra/openldap/bootstrap/.
DB2: ab Ausbaustufe 4 ein DB2-Community-Edition-Container als Stand-in — echtes DB2 for z/OS ist in dieser Umgebung nicht erreichbar, siehe 40-bindeglied-dev-ops-db2-netzwerk/.

Wichtiger Hinweis zur Java-/JVM-Wahl: kommerzielles WebSphere Liberty läuft in echten IBM-Shops meist auf IBM Semeru Runtime (IBM's OpenJ9-JVM) statt auf HotSpot/Temurin wie hier - das hat spürbare Auswirkungen auf GC-Tuning (siehe 20-monitoring-tuning/). Außerdem ist traditionelles WebSphere (Full Profile/ND, nicht Liberty) bei Java deutlich konservativer: WAS 9.0.x startete mit Java 8, bekam Java 11 erst über spätere Fixpacks nachgerüstet, und niemals offizielle Java-17+-Unterstützung - IBM hat neue Java-Versionen bewusst nur noch für Liberty freigegeben. Die Anzeige nennt explizit Liberty, das passt also.

⌂ Cockpit