Java Application Server

Ein Softwaresystem zum Ausführen von Anwendungssoftware. Schwerpunkt dieses Artikels sind dabei die Java Application Server. Dabei werden wir auf einzelne Bestandteile des Java EE Standards eingehen.

Gliederung

1. Das Konzept Application Server
2. Java EE
   1. Web Services
   2. EJB
   3. JDBC
   4. JPA
3. Beispiel: Wildfly Application Server
4. Aktualität
5. Quellen

1. Konzept Application Server

Application Server (auch Anwendungsserver) stellen Dienste zur Verfügung. Dabei handelt es sich zum Beispiel um Transaktionsdienste, Authentifizierung, Persistenz, verschiedene Webservices und auch Load Balancing. Die Liste der vorhandenen Services hängt vom konkreten Application Server ab und wird teilweise in Standards definiert (Java EE/ .NET …). Bekannte Gruppen von Application Servern sind die .NET Systeme, der SAP NetWeaver, verschiedene PHP Server und die Gruppe der Java EE Server. Wählt man einen Properitären Application Server ist man an die zur Verfügung gestellten Anwendungen und an die Instandhaltung der Software durch den entsprechenden Anbieter gebunden. Die Java EE Platform beitet einen offenen Industriestandard für Application Server, der es Entwicklern ermöglicht Anwendungen für mehrere Systeme zu erstellen. Dementsprechend basieren sehr viele der open-source Anwendungen für Application Server auf Java EE.
Dieser Artikel wird sich auf die Vorstellung einiger Grundkonzepte und Dienste der Java EE Application Server beschränken. Wird in folgenden Absätzen von Application Servern  geschrieben werden damit Java Application Server gemeint.

 

2. Java EE

Die Java Enterprise Edition (Java EE) ist im Gegensatz zur Java Standard Edition (Java SE) nur für die Entwicklung von Software für Server gedacht. Java EE Anwendungen können meist in folgende vier Schichten unterteilt werden:

1. Client-Schicht
2. Web-Schicht (auch Kommunikationsschicht)
3. Verarbeitungschicht (Business-Logik)
4. Persistenzschicht

 

2.1. Web Services

Für Webservices bietet die Java EE Plattform verschiedene Modelle. Diese unterscheiden sich in ihrer Flexibilität und Programmierung. Die erste und simpelste Möglichkeit einen Webservice zu erstellen ist das Servlet. Ein Servlet ist eine sich von HttpServlet ableitende Klasse mit Methoden für verschiedene HTTP-Requests. So können natürlich HTML-Webseiten als String zurückgesendet werden, allerdings auch alle anderen auf HTTP oder HTTPS basierenden Protokolle.

Neben dem einfachen Servlet bietet Java EE auch  Java Server Pages, kurz JSP an. Im Gegensatz zur Entwicklung einer Website als Java String Objekt kann hier Java in ein HTML-

Dokument eingebettet werden. Diese Einrichtung macht die Entwicklung für größere Webseiten einfacher, schließlich ist die HTML Struktur so viel besser erkennbar. Unter der Haube wird eine solche JSP Datei (meist xhtml) in ein Java-Servlet umgewandelt. Das passiert während des Kompilierens,  wodurch aus jeder JSP Seite genauso Bytecode wird wie bei einem normalen Servlet.

Die dritte Variante zur Auslieferung von Webseiten mit Java EE Werkzeugen sind die Java Server Faces, kurz JSF. Die JSF beruhen auf den vorhergenannten Servlets und JSP Dateien. JSF Webseiten können auch in annotiertem Java geschrieben werden. Die Implementierung folgt dem Model-View-Controller Pattern. Mit JSF wird auch der Lifecycle der einzelnen Komponenten und etwaige Navigationen zwischen den Seiten beschrieben.

 

2.2 EJB

Enterprise Java Beans sind standardisierte Komponenten, mit denen die Geschäftslogik auf dem Application Server umgesetzt werden kann.
EJBs werden in 3 Kategorien Eingeteilt:

Entity Beans werden Eingesetzt um den Datenbestand des Systems zu modellieren(vgl. Einträge in einer Datenbank).
Die Persitenz der Entity Beans wird im Normalfall über einen EJB-Container realisiert, kann bei Bedarf aber auch vom Entwickler selbst umgesetzt werden.

Session Beans setzen die Beziehungen und Vorgänge zwischen den Entity Beans um. Man unterscheidet zwischen Stateless und Statefull Session Beans.
Statefull Beans speichern Informationen über ihren eigenen Zustand, und können so bei einem Wiederholten Aufruf andere Ausgaben haben.
Eine Stateless Bean dagegen wird bei jedem Aufruf mit den selben Parametern exakt das selbe Ergebnis liefern. Stateless Beans sind also statisch.

Die dritte Kategorie sind die Message Driven Beans.
Über diese Komponente wird die Asynchrone Kommunikation des System realisiert.
Message Driven Beans implementieren den Java Message Service (JMS) und ermöglichen es somit auch asynchrone Befehlsabarbeitung umzusetzen.

2.3 JDBC

Die Java Database Connectivity (JDBC) – API ist eine standardisierte Schnittstelle für Java Programme und Datenbanksysteme.
Durch ihre Implementierung ist es Anwendungen möglich Verbindungen zu Datenbanken aufzubauen, Anfragen an Datenbanken zu senden und neue Einträge in Datenbanken zu erstellen.
Jeder Datenbank-typ, der einen JDBC-Treiber implementiert kann angesprochen werden.

JDBC verfügt auf der Anwendungsseite außerdem über einen erweiterten Verbindungsmanager, der es ermöglicht mehrere Datenbank-Verbindungen gleichzeitig zu speichern und zu organisieren. Dies ermöglicht das erstellen von Connection-Pools, welche die Verbindungen zu Datenbanken offenhalten, anstatt sie nach jeder Anfrage wieder zu schließen. Methoden, die eine Anfrage senden öffnen keine neue Verbindung zur Datenbank, sondern senden ihre Anfrage an den Pool, damit er sie weiterleiten kann. Außerdem verfügt die JDBC über einen Statement-Pool, in dem vorgefertigte SQL-Anfragen abgelegt werden können, um die Anfragezeit weiter zu verringern.

Der Konkrete Aufruf der JDBC läuft in 5 Phasen ab:
Zuerst sucht der JDBC-Treibermanager eine Datenbank, die einen passenden JDBC-Treiber implementiert.
Danach wird die Verbindung zur Datenbank über den gefundenen Treiber geöffnet.
Anschließend wird das entsprechende SQL-Statement an die Datenbank gesendet.
Die Antwort der Datenbank wird über die JDBC an das Programm weitergeleitet.
Jetzt ist das Statement abgeschlossen, und die Ressourcen können wieder freigegeben werden.

 

2.4 JPA

Damit die Objektorientierten Entitäten eines Java-Programmes persistent in einem relationalen Datenbanksystem abgespeichert werden können muss eine eindeutige Übersetzung zwischen den beiden Konzepten implementiert werden. Zu diesem Zweck wird die Java Persistance API (JPA) eingesetzt.
Die JPA ermöglicht es Entwicklern die Eigenschaften und Methoden der objektorientierten Java-Entitäten mithilfe von Annotationen als Relationale Eigenschaften und Beziehungen zu markieren. So können Eigenschaften einer Klasse, zum Beispiel mit der Annotation @Id als ein Primärschlüssel des Objektes gekennzeichnet werden.
Soll der Zustand der Entitäten abgespeichert werden generiert die JPA mithilfe der Annotationen eine Folge von Datenbankbefehlen, die die Übersetzung von objektorientiert zu relational konkret umsetzen. Natürlich kann mithilfe der JPA der gespeicherte Zustand der Objekte auch wieder aus der Datenbank ausgelesen werden.
Dank der zur verfügung stehenden Annotationen (u.a. @OneToOne, @OneToMany) ist ein Entwickler in der Lage jede theoretisch mögliche relationale Beziehung  zwischen zwei Entitäten zu simulieren.

 

Wildfly Application Server

Ein Vertreter der Java EE Application Server ist Wildfly. Wildfly ist die Community-Abspaltung vom kommerziellen JBoss von RedHat. JBoss und Wildfly sind sich dadurch und durch den Java EE Standard in der Handhabung recht ähnlich. Für den Wildfly Application Server gibt es ein von den JBoss-Entwicklern gepflegtes Docker-Image namens jb

oss/wildfly. Natürlich ist es nicht unbedingt praktikabel einen Application Server (welcher verschiedene Anwendungen in Container-ähnlichen Strukturen ausführt) in einem Container zu starten – für Demonstrationszwecke ist es aber eine schnelle und saubere Lösung. Eine vollständige Docker-Installation vorausgesetzt, kann das Image mit diesem Kommando gestartet werden:

docker run -p 8080:8080 -p 9990:9990 -it jboss/wildfly /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0

Bevor man die integrierte Weboberfläche zur graphischen  Konfiguration verwenden kann, muss ein Benutzerkonto angelegt werden. Dazu muss der nun laufende Container mittels docker exec konfiguriert werden. Bei CONTAINER handelt es sich um die Referenz auf den gestarteten Container (docker ps zum Anzeigen der laufenden Container), NAME ist der neue Benutzername und PASSWORT das Passwort.

docker exec CONTAINER wildfly/bin/add-user.sh -u NAME -p PASSWORT -e -s

Nun kann bei Installation auf dem lokalen Rechner unter der Adresse: http://localhost:8080/
Die Webkonsole aufgerufen werden. Nach Anmeldung mit NAME und PASSWORT kann man nun als Admin seine laufenden Anwendungen auf dem Application Server verwalten. Dazu gehört das starten/stoppen, die Konfiguration von Datenbanken und allen möglichen Schnittstellen. Außerdem können Auslastung und Ressourcenverbrauch beobachtet werden.

Deployen einer Anwendung

Java EE Anwendungen können mit einer Vielzahl von IDEs entwickelt werden. Neben den JBoss Tool und einer Intellij-Lösung gibt es auch eine modifizierte Eclipse. Diese kostenfreie Eclipse names „Eclipse IDE for Enterprise Java Developers“ wird hier in unserem kurzen Beispiel verwendet. Online gibt es zahlreiche Beispiel-Anwendungen zum herunterladen. Als besonders gut verständlich und vollständig erwies sich diese Erklärung. Ist die eigene Anwendung bereit zum deployen auf dem Server kann diese in einem von der IDE verwaltetem Application Server gestartet werden. Will man seinen eigenen verwenden, bietet sich er Export als war-Datei an. Diese kann zum Beispiel in der Web-Oberfläche hochgeladen und gestartet werden.

Aktualität

Java Application Server gibt es schon eine ganze Weile, Vertreter wie etwa Tomcat seit 1999. Gerade in den letzten Jahren gibt es neuere Strömungen wie Containervirtualisierung oder SaaS die Lösungen für Probleme bieten welche vorher mit Application Servern gelöst wurden. In diesem Abschnitt werden wir nicht beurteilen inwiefern Application Server durch andere Technologien abgelöst oder ersetzt werden, sondern Vorteile und Nachteile der verschiedenen Konzepte hervorheben.

Sowohl mit SaaS Architekturen, Containervirtualisierung oder Application Servern lassen sich ähnliche Ziele erreichen. Natürlich sind genauso Kombinationen dieser Strukturen möglich. Interessante Alternativen sind etwa: Docker, Kubernetes, Spring Boot

 

Nachteile Application Server

Die  Wahl der Programmiersprache ist eingeschränkt – gerade bei Java EE Application Servern ist kaum etwas anderes als Java anzutreffen. Dazu kommt die mitunter doch noch nötige aufwendige Konfiguration über XML-Dateien. Auch ist das Ökosystem in welchem eine Anwendung läuft mehr oder weniger festgelegt. Natürlich kann man über diverse Schnittstellen andere Services nutzen, eine Integration der Java EE Standard-Dienste ist meist aber der einfachste Weg. Bei Container-virtualisierten Anwendungen hingegen kann der Entwickler jede beliebige Software einsetzen.  Application Server sind auch nicht direkt geeignet um eine Anwendung mit Service-orientierter Architektur umzusetzen. Dafür gab es den Ansatz eines leichtgewichtigen Application Server für SOA – Wildfly Swarm. Diese Projekt wird allerdings nicht mehr gepflegt.

 

Vorteile Application Server

Was einerseits ein Nachteil sein kann, sehen manche vielleicht als einen Vorteil. Das abgeschlossene Ökosystem der Java EE Application Server ist sicher eine dieser Eigenschaften. Abhängigkeiten, Nachrichtenformate und Protokolle sind innerhalb von Java EE einigermaßen übersichtlich. Die vielen im Standard integrierten Services ermöglichen einen Verzicht auf manchen externen Dienst.

 

Vortrag Folien

Vortrag_Application_Server

 

Quellen

Wikipedia, „Application server“: https://en.wikipedia.org/wiki/Application_server, Abruf 17.1.2021

Docker Inc., „WildFly Docker image – Docker hub“: https://hub.docker.com/r/jboss/wildfly, Abruf 20.1.2021

Red Hat Inc., „Java EE moves to Eclipse“: https://www.redhat.com/en/blog/java-ee-moves-eclipse, Abruf 20.1.2021

The Wildfly project, „WildFly 22 Final is now available“: https://www.wildfly.org/, Abruf 20.1.2021

Müller-Hofmann, Frank – Hiller Martin – Wanner Gerhard, „Programmierung von verteilten Systemen und Webanwendungen mit Java EE“, ISBN=“978-3-658-10512-9″

Rafael Benevides, „Why Kubernetes is The New Application Server“,  https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server/, Abruf 26.1.2021

Bauke Scholtz, „JSF 2.3 tutorial with Eclipse, Maven, WildFly and H2“, https://balusc.omnifaces.org/2020/04/jsf-23-tutorial-with-eclipse-maven.html, Abruf 21.1.2021