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, LocalDateAttributeConverter - siehe deren Javadoc). Dieses Dokument ergaenzt die fehlende Haelfte: wie diese Datenquellen tatsaechlich auf dem Server konfiguriert werden.

Der Datenfluss vom Code zur physischen Datenbank

@PersistenceContext(unitName="novarisPolicyPU")   <- Code (PolicyRepository)
        |
persistence.xml: <jta-data-source>jdbc/novaris/policyDS</jta-data-source>
        |
server.xml: <dataSource jndiName="jdbc/novaris/policyDS">   <- JNDI-Bindung
        |
J2C Authentication Alias   <- WER darf sich verbinden (siehe unten)
        |
JDBC-Treiber + Connection-Pool   <- WIE die physische Verbindung entsteht
        |
Oracle-Instanz

Jede Ebene loest ein anderes Problem; siehe docs/10-ejb-konzepte/08-jndi-vertieft.md fuer die JNDI-Bindung selbst. Dieses Dokument fokussiert auf die beiden untersten Ebenen.

J2C Authentication Alias: WebSphere-Sprache fuer "gespeicherte Zugangsdaten"

Ein J2C Authentication Alias ist WebSphere-Terminologie fuer einen benannten, zentral verwalteten Satz Zugangsdaten (Benutzername/Passwort oder Zertifikat), auf den sich eine Ressourcendefinition (Datenquelle, JMS-Connection-Factory) per Namen bezieht, statt die Zugangsdaten direkt einzutragen:

<!-- novaris-policy-core/src/main/liberty/config/server.xml -->
<dataSource jndiName="jdbc/novaris/policyDS" id="policyDS">
    <jdbcDriver libraryRef="oracleJdbcLib"/>
    <properties.oracle
            URL="${env.NOVARIS_ORACLE_JDBC_URL}"
            user="${env.NOVARIS_ORACLE_USER}"
            password="${env.NOVARIS_ORACLE_PASSWORD}"/>
</dataSource>

Die user/password-Attribute direkt auf properties.oracle sind Libertys vereinfachte Form eines eingebetteten Authentication-Alias - fachlich dasselbe Prinzip (Zugangsdaten sind an einer Stelle benannt, nicht im Anwendungscode verstreut), nur ohne das eigenstaendige, wiederverwendbare Alias-Objekt, das WebSphere traditional als separate Admin-Console-Entitaet fuehrt (siehe naechster Absatz).

Auf WebSphere traditional ist das ein eigenstaendiges Admin-Console-Objekt ("J2C Authentication Data Entries"), das von mehreren Ressourcen wiederverwendet werden kann - z.B. dieselbe Alias-Definition fuer eine Datenquelle UND einen JMS-Connection-Factory, wenn beide gegen dasselbe Backend-System authentifizieren. Der entscheidende Vorteil: Passwort- Rotation passiert an einer Stelle (dem Alias), nicht in jeder einzelnen Ressourcendefinition, die dieses Passwort braucht.

In diesem Projekt sind die Zugangsdaten in server.xml bewusst als Umgebungsvariablen- Platzhalter (${env.NOVARIS_ORACLE_USER}) gehalten - genau das Prinzip eines Alias, nur ohne die WebSphere-spezifische Admin-Console-Indirektion, weil Liberty Umgebungsvariablen-Substitution direkt eingebaut hat.

Zwei Datenquellen, zwei Connection-Pools

novaris-policy-core/src/main/liberty/config/server.xml definiert zwei unabhaengige <dataSource>-Eintraege - policyDS (Oracle) und legacyContractDS (DB2), jede mit eigenem JDBC-Treiber (oracleJdbcLib/db2JdbcLib) und eigenem Connection-Pool. Das ist keine Formalitaet: die beiden Datenbanken haben unterschiedliche Lastprofile (Oracle: hohe Schreiblast durch aktives Neugeschaeft; DB2: fast nur noch Lesezugriffe auf einen schrumpfenden Altbestand) und sollten deshalb unabhaengig dimensionierte Pools (maxPoolSize, minPoolSize) haben - ein gemeinsamer Pool waere ein Kapazitaetsproblem zwischen zwei fachlich vollkommen unabhaengigen Systemen.

Warum das ueberhaupt in einer eigenen Doku steht

JNDI-Namen und Datenquellen-Konfiguration werden in Tutorials oft als Randnotiz behandelt - in echten Produktionsvorfaellen sind sie aber eine der haeufigsten Fehlerursachen ("Connection pool exhausted", "falscher J2C-Alias nach einem Umgebungswechsel", "Datenquelle zeigt nach einem Refactoring noch auf die alte JNDI-Name"). Das Verstaendnis dieser Konfigurationsebene ist deshalb genauso wichtig wie das Verstaendnis von JPA/JDBC selbst - nur seltener explizit gelehrt.

⌂ Cockpit