Was ist WebSphere eigentlich? Traditionelles WAS vs. Liberty

Status: dokumentiert, nicht live verifizierbar für den traditionellen Teil (keine WAS-ND-Lizenz/-Installation in dieser Umgebung verfügbar) — reiner Orientierungstext, analog zu ../40-bindeglied-dev-ops-db2-netzwerk/00-was-ist-zos.md. Der Liberty-Teil ist in 01-liberty-installation-und-featuremanager.md real verifiziert.

"WebSphere" ist eine Marke, kein einzelnes Produkt

IBM nutzt "WebSphere" seit den späten 1990ern als Dach-Marke für eine ganze Reihe von Middleware-Produkten (u. a. WebSphere MQ, WebSphere DataPower). Für diese Anzeige und dieses Projekt ist ausschließlich WebSphere Application Server (WAS) relevant — und selbst das ist kein einzelnes Produkt, sondern zwei parallel existierende, technisch grundverschiedene Produktlinien, die man klar auseinanderhalten muss.

Zwei Lininen: "traditionelles WAS" vs. Liberty

	WebSphere Application Server traditional (Full Profile)	WebSphere Liberty
Seit	Ende der 1990er (J2EE-Ära)	~2012, als bewusste Kehrtwende
Architekturprinzip	Monolithischer, immer voll geladener Server-Stack	Modularer Feature-Manager — nur explizit angeforderte Features werden geladen (siehe `01-liberty-installation-und-featuremanager.md`)
Konfiguration	Verteilte XML-Deskriptoren, gepflegt über Admin Console/`wsadmin`	Eine Datei, `server.xml`, direkt editierbar
Startzeit	Typischerweise 1–2+ Minuten, viele mitgeladene Subsysteme	Sekunden bis wenige zehn Sekunden (feature-abhängig)
Administrationsmodell	Zentralisiert: Deployment Manager verwaltet mehrere Knoten (siehe unten)	Jeder Server administriert sich im Wesentlichen selbst über seine eigene `server.xml`
Java-Versionsstrategie	Sehr konservativ (siehe `docs/00-ueberblick/systemlandschaft.md`)	Deutlich agiler, kontinuierliche Releases
Typischer Neueinsatz heute	Eher Bestandssysteme, die (noch) nicht migriert wurden	IBMs empfohlener Weg für alles Neue

Für die Anzeige ist das doppelt relevant: sie nennt explizit Liberty (die Zukunftsrichtung), aber ein WAS-Spezialist in einer gewachsenen Bank-IT trifft in der Praxis oft auf beides gleichzeitig — Alt-Anwendungen auf traditionellem WAS, Neuentwicklungen auf Liberty, und gelegentlich Migrationsprojekte dazwischen.

Architektur von traditionellem WAS (zum Wiedererkennen)

Auch wenn dieses Projekt nur Liberty real betreibt, sollte man diese Begriffe im Gespräch einordnen können:

Cell: die größte Verwaltungseinheit — eine Cell kann mehrere Nodes umfassen.
Node: eine logische Gruppe von Application-Server-Instanzen auf (meist) einem physischen/ virtuellen Host, überwacht von einem Node Agent.
Deployment Manager (Dmgr): der zentrale Administrationsprozess einer Cell — verteilt Konfigurationsänderungen an alle Nodes, einziger Ort für zentrale Verwaltung in einer Network-Deployment-Topologie (siehe Editionen unten).
Profile: eine per manageprofiles-Tool erzeugte Laufzeitinstanz-Konfiguration — es gibt eigene Profiltypen für Dmgr und für Application-Server-Knoten.
Cluster: mehrere Application-Server-Instanzen (Cluster-Mitglieder), die dieselbe Anwendung bereitstellen — die traditionelle WAS-Antwort auf dieselbe HA-Grundfrage wie die Liberty-Zwei-Knoten-Demo in docs/70-high-availability/, nur zentral vom Dmgr verwaltet statt als unabhängige Prozesse.
IHS (IBM HTTP Server) + plugin-cfg.xml: der klassische Web-Tier davor — ein Apache- basierter HTTP-Server mit einem WebSphere-eigenen Plugin, das Anfragen anhand von plugin-cfg.xml auf die passende Cluster-Mitglieder-Instanz verteilt. Die traditionelle Antwort auf dieselbe Frage, die der (in diesem Projekt an einer Netzwerk-Einschränkung gescheiterte) Traefik-Versuch für Liberty demonstrieren sollte, siehe docs/70-high-availability/03-traefik-load-balancing-versuch.md.
Admin Console vs. wsadmin: zwei Wege, eine Cell zu administrieren — die browserbasierte Admin Console für interaktive Änderungen, wsadmin (Jython- oder historisch Jacl-Skripting) für automatisierbare, wiederholbare Änderungen — das traditionelle WAS-Gegenstück zu "server.xml von Hand editieren" bei Liberty.

Editionen und Lizenzmodell (grober Überblick)

Edition	Charakteristik
WAS Base	Einzelner Server, keine zentrale Cell-Verwaltung, kein Clustering
WAS Network Deployment (ND)	Volle Cell/Node/Dmgr-Architektur, Clustering — die "Enterprise"-Stufe von traditionellem WAS
Liberty Core	Kleinster Liberty-Funktionsumfang (im Wesentlichen Web-/EJB-Lite)
Liberty Base / ND-Äquivalent	Erweiterter Funktionsumfang, entspricht in etwa dem, was traditionelles WAS Base/ND abdeckt
Open Liberty	Der komplette, quelloffene Kern ohne IBM-Lizenz/-Support/-Semeru-Bundling — was dieses Projekt tatsächlich verwendet, siehe `01-liberty-installation-und-featuremanager.md`

Der Lizenz-/Editionsunterschied ist in echten Kundenumgebungen keine akademische Frage — welche Features genutzt werden dürfen (z. B. bestimmte Cluster-/Failover-Funktionen) hängt direkt an der lizenzierten Edition, und das ist typischerweise etwas, das der WAS-Admin im Blick behalten muss, nicht nur die Einkaufsabteilung.

Warum dieses Projekt trotzdem (fast) nur Liberty zeigt

Die Anzeige nennt explizit Liberty, und IBMs eigene strategische Richtung geht seit Jahren eindeutig in Richtung Liberty (siehe Java-Versionsstrategie oben). Die traditionelle WAS-Architektur hier zu betreiben würde eine kommerzielle Lizenz und einen deutlich schwereren Infrastruktur-Aufbau (Dmgr + mehrere Node-Profile) erfordern, ohne zusätzlichen Erkenntnisgewinn für die eigentlichen Anzeigen-Punkte. Dieses Dokument existiert trotzdem, damit die Begriffe (Cell, Node, Dmgr, Cluster, IHS/plugin-cfg.xml, wsadmin) im Gespräch nicht fremd klingen, falls die reale Zielumgebung (teilweise) noch traditionelles WAS einsetzt.

⌂ Cockpit