IBM WebSphere Application Server – Ein Überblick bzw. Einführung

Der folgende Beitrag soll einen kleinen Überblick über den WebSphere Application Server geben.

Was ist der IBM WebSphere Application Server (Full Profile)?

Als vor circa 20 Jahren die Anwendungen nach und nach Internet fähig gemacht werden mussten, entstand die Notwendigkeit neben statischen Seiten, die ist im World Wide Web sowieso schon gab, nun eine Möglichkeit zu bieten auch Anwendungen übers Internet auf einem Server auszuführen. Eine der Techniken zu der Zeit war CGI (Common Gateway Interface). CGI war eine Erweiterung der Web Server, um über das HTTP Protokoll Anwendungen, die auf dem Server lagen, aufzurufen. Die Java Gilde überlegte sich, dass es sinnvoll wäre auch ein Java Technik in diesem Bereich zur Verfügung zu stellen. Somit entstand die Idee einer serverseitigen Java Anwendung, die auch vom Client aus aufrufbar sein sollte. So entstand das Servlets. (Übrigens wäre der Name Applet der sinnvollere gewesen, da es sich um einen Applikation handelte. Dieser Name war aber schon belegt. Dann hätte das Applet besser Clientlet geheissen)

Dieses Servlet sollte also im Server laufen. Da Java nun mal eine JVM braucht, wurde auch hier das Konzept verwendet.

Die JVM, die auf der Serverseite eingebaut wurde, beinhaltete einen Teil, der spezieller war, als die Standard JVM. Das resultierte daher, das man erwartete, dass es ganz viele Instanzen eines Servlets auf dem Server geben würde. Somit erzeugt man einen eigenen, so genannten Container, der damals noch Servlet Engine hieß, in dem die Servlets in einem bestimmten Lebenszyklus existieren. Dies geschah vor allem Dingen aus Skalierbarkeit und Ressourcen Gründen.

Somit entstand ein so genannter Web Applikation Server, der sich vom Web Server dadurch unterschied, dass es eine JVM gab und so Servlets, die darin liefen. Das war die Idee und erste Umsetzung. Im weiteren wurde die erste Spezifikation stark erweitert. Hier spielte vor allen Dingen der Model View Controller eine Rolle, der eine Trennung der Präsentationslogik,  der Business Logik  und des Kontrollers forderte. Hieraus entstand ein Standard der sich heute Java Enterprise Edition (J EE) nennt, früher  Java 2 Enterprise Edition (J2EE).

Der WebSphere Application Server ist somit ein Web Application Server (auch schon Mal nur Application Server genannt), der nach dem Java EE Standard implementiert worden ist.

Wie ist der IBM WebSphere Application Server aufgebaut?

In seiner Grundstruktur ist der WebSphere Application Server ist ein Java EE compliant  Server, der alle notwendigen Spezifikationen erfüllt. Im Kern besteht der Server aus einem internen Web Server, der die HTTP Requests entgegen nimmt und intern an den Web Container weiterleitet. In dem Container Leben die Servlets und JSPs, die die Control Logik und die User Interface Logik beinhalten. Von der Kontrolllogik aus wir nach Standard normalerweise der EJB Container angesprochen, nn dem sich die Business Logik befindet. Von der Business Logik aus wird auf ein Backend zugegriffen. Diese Backends können verschiedener Natur sein. Eine Möglichkeit ist ein Zugriff über JDBC auf eine Standard relationale Datenbank. Eine andere Möglichkeit ist der Zugriff auf beliebig andere Systeme. Der Zugriff erfolgt wie im J2C bzw. JCA Standard beschrieben. Ein weiterer wichtiger  Aspekt sind die verschiedenen Möglichkeiten, die Server basierte Anwendung anzusprechen. Dies kann wie bereits erwähnt über das Web Interface geschehen aber auch Webservice Zugriffe sowie Zugriffe über ein Messaging System wie JMS ist möglich. Auch besteht die  Möglichkeit eine Java Anwendung direkt mit der Business Logik reden zulassen (Java Client). Soweit ist der Aufbau des Servers ein ganz normaler Aufbau, wie er auch im Standard beschrieben wird. Interessant ist, dass die IBM viele Erweiterung zum Standard Server hinzugefügt hat, die vor allen Dingen Skalierbarkeit, Sicherheit und Zuverlässigkeit beinhalten. Dies wird vor allen Dingen im nächsten Abschnitt „Welche Konfiguration gibt es“  erklärt.

Welche Konfigurationen gibt es?

Wie bereits erwähnt ist in seiner Grundstruktur der WebSphere Application Server ein ganz normaler Server, der nach dem J EE Standard implementiert worden ist. Diese Version lässt sich standardmäßig installieren und ist eine so genannte Single Server Version (bei IBM auch schon mal Base genannt). Der Single Server hat aber diverse Nachteile. Fällt dieser eine Server aus kann man auf die Anwendung nicht mehr zugreifen. Ferner hat ein Soingel Server begrenzte Kapazitäten, die durch Speicher und Prozessor der Maschine begrenzt sind. Für die Themen Skalierbarkeit, Ausfallsicherheit und Load Balancing hat die IBM eine weitere Installationsmöglichkeit geschaffen, die mit dem Produkt Version Network Deployment ein hergeht. Die Network Deployment Version bietet die Möglichkeit nicht nur einen Server aufzubauen, sondern ein komplettes Cluster von Servern, die horizontal oder vertikal angeordnet werden können, um somit Prozess fail over oder Machine fail over zu kompensieren. In dieser Konfiguration gibt es eine zentrale Administrationsmöglichkeit den  Network Deployment Manager.

Welche Plattformen werden unterstützt?

Unabhängig von den verschiedenen Konfigurationen ist beim Application Server maßgeblich die Java EE Version. D.h. immer dann, wenn der Standard erweitert beziehungsweise eine neue Version des Standards herauskommt, muss der WebSphere Application Server um ein Java EE Compliant Server zu bleiben, auch angepasst beziehungsweise weiter implementiert werden. Darüber hinaus kann man den Server auf fast allen gängigen Plattformen installieren. eine Unterscheidung ist hierbei allerdings, ob der Server mit einer eigenen von IBM implementierten JVM ausgeliefert wird oder ob man eine JVM von Oracle installieren muss. Der Server ist generell auf Z/OS genau so verfügbar, wie auf allen Linux, Unix und Windows Plattform. Interessant ist hier das war eine Clusterkonfiguration nicht Mal gleiche Betriebssysteme noch Version des Servers gefordert sind.

Was sind die Vorteile vom WebSphere Application Server?

Von außen betrachtet und wenn man die reine Funktionalität sieht, hat der WebSphere Application Server in der Base Version keine Vorteile gegenüber den anderen angebotenen J EE complaint Servern.

  1. Support von IBM: Jeder Kommerzielle Server Anbieter unterstützt seine Kunden mit umfangreichem Support. Bei IBM gibt es alklerdings noch diverses mehr. Angefangen von den Redbooks über Developerworks bis hin zu diversen Spezialisten und 20 Jahren Erfahrung, vor allen Dingen auch mit großen Installationen, ist da alles dabei.

Nimmt man die Network Deployment Version mit hinzu, ergeben sich weitere Vorteile:

  1. Einfache Administration: Der WebSphere Application Server kann, egal in welchem Umfang über eine zentrale Administrationskonsole bedient beziehungsweise konfiguriert werden. Dies hat den entscheidenden Vorteil, dass auch bei komplexen Installationen, keine Notwendigkeit besteht einzelne Server zu administrieren. Ferner bietet die Zentrale Konsole diverse Konfigurationsmöglichkeiten, die von einem dynamischen Cluster angefangen bis hin zum Health Management konfigurierbar sind. Damit lassen sich einfacher aber auch sehr komplexe Installation einfach handhaben. Sollte das Konzept der Zelle (Cell) nicht ausreichen, gibt es darüber hinaus noch eine weitere Möglichkeit verschiedene Zellen auch zentral zu managen. Dies geschieht über den so genannten Job Manager, der einzeln installiert werden kann, oder Bestandteil des Deployment Managers ist. Sollte Administration über die Konsole zu aufwändig werden, bietet der WebSphere Application Server die Möglichkeit der Kommandozeilen Administration über wasadmin. Mit diesem Scriptinmg Client hat man die gleichen Möglichkeiten, wie in der Administrationskonsole, allerdings lassen sich nun diverse Aufgaben automatisieren und sogar zeitlich steuern.
  2. Zuverlässigkeit: Nimmt man den Server für sich, kann man natürlich auch von einer gewissen Zuverlässigkeit reden. Spannend wenn es allerdings erst, wenn man das Konstrukt der Cluster mit einbezieht. Durch ein Cluster, dass auch verschiedene Maschinen verteilt ist, kann man erreichen, dass immer ein Server zur Verfügung steht.
  3. Skalierbarkeit: Es besteht die Möglichkeit auf einer physikalischen Maschine oder logische Partition mehrere WebSphere Application Server zu installieren. Jeder dieser Server hat seinen eigenen Prozess und JVM. Dadurch lassen sich die Ressourcen der Maschine deutlich besser nutzen. Ferner bietet diese Installation schon einen ersten Fail Over Support, da bei Prozessfehler (Server Fehler) die anderen Server Prozesse weiterlaufen. Ferner besteht die Möglichkeit weitere Server auf anderen physikalisch getrennten Maschinen zu installieren. Dies hat den Vorteil, dass man beliebig viele Maschinen zu einem so genannten Cluster zusammensetzen kann. Dies ergibt die Möglichkeit eine Anwendung auf dem Cluster zu installieren und egal, ob 10 oder 100.000 Nutzer gleichzeitig auf den Server zugreifen wollen, hat man immer genügend Kapazität.
  4. Hoch Verfügbarkeit: Durch die Installation der Anwendung auf einem Cluster, welches aus verschiedenen Servern besteht, erhält man die Möglichkeit über einen vorgeschalteten Load Balancer (das kann das Plugin des WebServers und/oder ein externer Load Balancer) die verschiedenen Server zu nutzen. Die Anwendung ist bei sauberer Konfiguration nicht an einen Server gebunden (Session affinity), sondern kann auch verschiedenen Servern betrieben werden. Der Nutzer merkt den Unterschied nicht. Alle Daten (Session) bleiben erhalten.

Abgrenzung zu IBM WebSphere Application Server Liberty Profile

Der WebSphere Application Server Liberty Profile ist eine Server Version, die vor allen Dingen für einfache Anwendungen im kleineren Umfeld Verwendung finden sollte. Durch OSGI und die Möglichkeit nur Features einzubinden, die tatsächlich benötigt werden, entsteht eine Server-Struktur, deren Konfiguration des früheren JBoss sehr ähnelt.

Bei einfachen Installationen oder bei einfachen Anwendungen, die kein großes Cluster und keine große flexible Konfiguration brauchen, ist der Liberty Profile Server sicherlich die erste Wahl. Generell sind das allerdings zwei Unterschiedliche Produkte, die auch unterschiedliche Ziele und Aufgaben haben.

Eine genaue Gegenüberstellung kann man hier bei der IBM einsehen:

http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/documentation/ChoosingTraditionalWASorLiberty-16.0.0.4.pdf

Hieraus ergibt sich auch folgende Zusammenfassung:

„As stated in the introduction, if you are using traditional WAS and it does what you need, you should not feel compelled to move to Liberty. Many companies have large investments in traditional WAS infrastructure and automation, and IBM will continue to serve and support those customers. It is expected that there will be some applications that remain on WAS indefinitely, because it is impractical or cost-prohibitive to adapt them to run on Liberty.“

Dies bedeutet, dass man je nach Einsatzbereich den richtigen Server auswählen sollte.

Schulungen zum Thema WebSphere Application Server

Das IBM Schulungsportfolio bietet unterschiedliche Kurse zu den jeweiligen Themen an. Die erste Unterscheidung muss man treffen, ob man etwas über den WebSphere Application Server Full Profile oder Liberty Profile lernen möchte. Will man Liberty Profile, kann man den Kurs WA190 – Administering WebSphere Application Server Liberty Profile V9 besuchen. Die Firma Obtec bietet diesen Kurs unter der Kursnummer OB2202 an:

https://obtec.net/trainings/ibm-wa190g-administering-websphere-application-server-liberty-profile-v9/

Dieser Kurs ist zwei Tage lang. Allerdings sollte man hier Kenntnisse des WebSphere Application Server Traditional mitbringen, sonst ist die Zeit sehr knapp.

Für den „Standard“ WebSphere Application Server bietet die IBM verschiedene Kurse an. Will man die Administration der Version 8.5.5 lernen, so kann man den Kurs WA855 – WebSphere Application Server V8.5.5 Administration besuchen. Obtec bietet den Kurs unter OB2203 an. Der nächste Termin ist:

21.06.-25.06.2021 | WA855G – WebSphere Application Server V8.5.5 Administration

 

Dieser 5 tägige Kurs deckt alle relevanten und wichtigen Themen der Administration ab.

Für die Version 9 des Servers hat die IBM 2 Kurse im Angebot. Der WA590 ist der erste Teil. Hier werden alle Funktionalitäten des „Base“ Servers abgedeckt. Im zweiten Kurs WA599 werden die Network Deployment Konfigurationen erklärt. Die Firma Obtec Sofware bietet das Ganze in Kombination in 5 Tagen an:

OB 2201 – WebSphere Application Server V9 Administration

Der nächste Termin ist:

21.06.-25.06.2021 | WA590G / WA599G – WebSphere Application Server V9 Administration

Beide Kurse werden sowohl Remote (ILO) und als Klassenraumkurse angeboten. Der V9 Admin Kurs wurde um einen Tag gegebenüber den IBM Vorgaben verlängert. Die Erfahrung hat gezeigt, dass man den Kurs in 5 Tagen besser halten kann. Dies hat zwei Gründe. Zum einen waren die 4 Tage sowieso etwas knapp bemessen, zum Anderen kann man so ein paar Themen ergänzen, die leider im Standard Kurs nicht mehr enthalten sind.

 

IBM erweitert das Schulungsprogramm zum WebSphere Application Server Full profile

IBM hat drei erfolgreiche Kurse zurück ins Portfolio gebracht. Diese Kurse sind ab sofort bei IBM re-retired. Sie werden auf dem Stand des WAS 8.5.5 angeboten, passen aber auch für die Nutzer/Administratoren der Version 9. Auf die geringen Unterschiede zwischen den Versionen 8.5.5 und 9 wird eingegangen.

 

WA680 – WebSphere Application Server V8.5 Scripting and Automation

06.09.-10.09.2021 | WA680G – WebSphere Application Server V8.5 Scripting and Automation

In diesem Kurs wird vermittelt, wie der WAS ohne die ICS Console administiert werden kann.

 

WA815 – WebSphere Application Server V8.5.5 Performance Tuning

12.07.-15.07.2021 | WA815G – WebSphere Application Server V8.5.5 Performance Tuning

Lernen Sie kennen, wie man den WAS unter Last testet und optimiert.

Beide Kurse werden sowohl online als auch Präsenzkurs angeboten.

Generell sind alle Kurse auch gerne als Inhouse bei Ihnen vor Ort möglich. Equipment kann dafür gestellt werden. Eigene Lizenzen des Produkts sind nicht erforderlich, sondern werden mit den Labs bei IBM eingekauft.