Begriffe aus diesem Projekt, die im zentralen
shared/enterprise-glossary(Stand dieser Session geprüft) noch fehlen oder dort nicht WAS-/Liberty-/z-OS-spezifisch genug erklärt sind. Connection Pool, Thread Pool und LDAP selbst stehen bereits im Shared-Glossary und werden hier nicht dupliziert.
| Begriff | Erklärung |
|---|---|
| WebSphere Liberty | Leichtgewichtiges, modulares WebSphere-Profil mit Feature-Manager-Modell (nur explizit angeforderte Features werden geladen) — Gegenstück zum "traditionellen" WebSphere Application Server (Full Profile/ND). Siehe docs/10-installation-konfiguration/00-was-ist-websphere.md. |
| WAS traditional (Full Profile) | Die ältere, monolithische WAS-Produktlinie — zentral über eine Cell/einen Deployment Manager verwaltet, Gegenstück zu Liberty. |
| Cell / Node / Node Agent | Verwaltungshierarchie von traditionellem WAS: eine Cell umfasst mehrere Nodes, jeder Node wird von einem Node Agent überwacht. |
| Deployment Manager (Dmgr) | Zentraler Administrationsprozess einer WAS-Cell — verteilt Konfiguration an alle Nodes. |
| Cluster (traditionelles WAS) | Mehrere Application-Server-Instanzen, die dieselbe Anwendung bereitstellen, zentral vom Dmgr verwaltet — die traditionelle Antwort auf dieselbe HA-Frage wie die Liberty-Zwei-Knoten-Demo in docs/70-high-availability/. |
IHS (IBM HTTP Server) / plugin-cfg.xml |
Klassischer Web-Tier vor traditionellem WAS — Apache-basiert, verteilt Anfragen per Plugin-Konfigurationsdatei auf Cluster-Mitglieder. |
wsadmin |
Skriptbasierte Administration von traditionellem WAS (Jython/Jacl) — das Gegenstück zu "server.xml von Hand editieren" bei Liberty. |
| WAS Base / Network Deployment (ND) | Lizenz-/Funktionsstufen von traditionellem WAS — Base ohne, ND mit Cell/Cluster-Fähigkeit. |
| Open Liberty | Der Open-Source-Kern von WebSphere Liberty (identische Codebasis) — von IBM kostenlos bereitgestellt, ohne kommerziellen Support/IBM-Semeru-Bundling. In diesem Projekt verwendet, siehe docs/10-installation-konfiguration/. |
| Feature-Manager | Liberty-Kernkonzept: server.xml listet explizit die benötigten Features (servlet-6.0, ldapRegistry-3.0, …) — kein "alles ist immer installiert" wie bei traditionellem WAS. |
server.xml |
Die einzige Konfigurationsdatei, die ein Liberty-Admin normalerweise von Hand pflegt (Features, Endpoints, DataSources, Security, Rollen). |
application-bnd (Authorization Table) |
Der Teil von server.xml, der Anwendungsrollen (security-role) auf LDAP-Gruppen/-Nutzer abbildet, siehe docs/60-security-lifecycle/01-rollen-und-rechte.md. |
liberty-maven-plugin |
Maven-Plugin, das eine Open-Liberty-Runtime als Artefakt lädt, einen Server erzeugt und die Anwendung deployt — hier für Build/Verifikation genutzt, siehe docs/10-installation-konfiguration/. |
securityUtility |
Liberty-Bordmittel zur kontrollierten Erstellung von SSL-Zertifikaten/Keystores, siehe docs/60-security-lifecycle/03-zertifikate-ssl.md. |
| Begriff | Erklärung |
|---|---|
| z/OS | IBM-Mainframe-Betriebssystem, auf dem in diesem Szenario das Core-Banking-System (DB2 for z/OS) läuft ("zentral"), im Gegensatz zu den Liberty-Servern auf Linux ("dezentral"). Grundlagen: docs/40-bindeglied-dev-ops-db2-netzwerk/00-was-ist-zos.md. |
| Address Space | z/OS-Äquivalent zu einem Prozess — jede Subsystem-Instanz (z. B. ein DB2-Subsystem) läuft in eigenen, benannten Adressräumen. |
| Dataset | z/OS-Äquivalent zu einer Datei, aber mit fester Organisationsform (sequenziell/PS, partitioniert/PDS(E), VSAM) und eigener Namenskonvention — kein Pfad-basiertes Dateisystem wie bei Linux/Windows. |
| EBCDIC | Zeichenkodierung, die z/OS-Anwendungen traditionell intern nutzen — anders als das in der Java-/Web-Welt übliche ASCII/UTF-8, potenzielle Fehlerquelle bei Datei-/Batch-basiertem Datenaustausch mit dezentralen Systemen. |
| JCL (Job Control Language) / JES2/JES3 | Sprache zur Definition von Batch-Jobs bzw. das Subsystem, das sie einplant/ausführt — viel Kernbank-Logik läuft als Batch-Job, nicht als dauerhaft laufender Server-Prozess. |
| CICS / IMS | Eigenständige z/OS-Transaktionsmonitore für gewachsene Kernbank-Programme — nicht jede Geschäftslogik steckt in DB2-Tabellen, für Transaktionsauslösung oft der richtigere Integrationsweg als reines JDBC. |
| z/OS Connect EE | Moderner, REST/JSON-basierter API-Zugang zu z/OS-Programmen (CICS/IMS/Batch) — Alternative zu klassischem JDBC/DDF, wenn eine Transaktion statt nur ein Datenzugriff nötig ist. |
| TSO/ISPF | Interaktiver, menübasierter Terminal-Zugang, mit dem Mainframe-Personal typischerweise arbeitet. |
| USS (Unix System Services) | POSIX-kompatible Schicht innerhalb z/OS, erlaubt u. a. Shell-Skripte auf dem Mainframe. |
| Parallel Sysplex / Coupling Facility | Mehrere gekoppelte z/OS-Systeme, die sich Workload/Daten/Verfügbarkeit teilen, verbunden über die Coupling Facility — die Mainframe-Antwort auf dieselbe HA-Grundfrage wie die Liberty-HA-Demo in docs/70-high-availability/. |
| DB2 for z/OS | Die auf z/OS laufende DB2-Variante — organisatorisch und technisch deutlich anders betrieben als DB2 LUW (Linux/Unix/Windows), siehe docs/40-bindeglied-dev-ops-db2-netzwerk/01-db2-fuer-zos-und-mainframe-grundlagen.md. |
| DDF (Distributed Data Facility) | Die Komponente von DB2 for z/OS, die TCP/IP-JDBC-/ODBC-Verbindungen von verteilten Systemen entgegennimmt (Ports 446/447). |
| RACF | Mainframe-eigenes Sicherheitssystem (Resource Access Control Facility) — getrennt vom LDAP-Verzeichnis, das für Liberty-/Web-Logins genutzt wird. |
| WLM (Workload Manager) | Klassifiziert eingehende Verbindungen/Workloads auf z/OS in Service-Klassen mit unterschiedlicher Priorität. |
| MSU (Million Service Units) | Maßeinheit für z/OS-CPU-Verbrauch, oft direkt mit Lizenzkosten verknüpft — Grund, warum Connection-Pool-Größen gegen DB2 for z/OS abgestimmt statt frei gewählt werden. |
| DVIPA / Sysplex Distributor | Mechanismus, der mehrere physische DB2-Mitglieder eines Sysplex hinter einer einzigen, stabilen IP-Adresse verbirgt. |
| Sysplex | Verbund gekoppelter Mainframe-Systeme für Hochverfügbarkeit/Lastverteilung. |
| Begriff | Erklärung |
|---|---|
| IBM Semeru Runtime | IBM's auf OpenJ9 basierende JVM — in kommerziellen WebSphere-Liberty-Umgebungen der übliche Unterbau, mit eigenen GC-Policies (gencon, optthruput, …), siehe docs/20-monitoring-tuning/01-jvm-heap-und-gc.md. |
| OpenJ9 | Die JVM-Implementierung, auf der IBM Semeru basiert — Gegenstück zu HotSpot. |
gencon |
Default-GC-Policy von OpenJ9 (generationell, ähnliches Grundprinzip wie HotSpots G1, andere interne Umsetzung). |
| PMI (Performance Monitoring Infrastructure) | Traditionelles WebSphere-Monitoring-Framework — bei Liberty durch das monitor-1.0-Feature (JMX-MBeans) bzw. MicroProfile Metrics abgelöst. |
server javadump |
Liberty-Bordmittel für einen Thread-Dump, funktioniert JVM-unabhängig (HotSpot wie Semeru), siehe docs/20-monitoring-tuning/02-heap-und-thread-dumps.md. |
| Begriff | Erklärung |
|---|---|
ldapRegistry |
Liberty-Feature/Konfigurationselement zur Anbindung eines LDAP-Verzeichnisses als User-Registry, siehe docs/60-security-lifecycle/02-ldap-registry.md. |
| BASIC-Auth | Einfaches HTTP-Authentifizierungsverfahren (Nutzername/Passwort im Authorization-Header) — hier für /secure/* verwendet, siehe docs/60-security-lifecycle/01-rollen-und-rechte.md. |
{xor}-Passwort-Obfuskierung |
Libertys Standard-Verschleierung für Passwörter in server.xml — trivial umkehrbar, kein Verschlüsselungsersatz, siehe docs/60-security-lifecycle/03-zertifikate-ssl.md. |