Jakarta-EE-Architektur

alte Buecher und Computer

Was versteht man unter Jakarta EE

Jakarta EE, früher Java EE, ist die Enterprise Edition von Java, die seit der Übergabe von Oracle zur Eclipse Foundation im Jahr 2017 nicht mehr das Wort „Java“ enthalten durfte. Die Community entschied sich dann im Frühjahr 2018 für den Namen „Jakarta“.

Sie kommt häufig zum Einsatz, wenn eine webbasierte bzw. vielschichtige Anwendung entwickelt werden soll. Jakarta EE basiert auf Java SE und bietet darüber hinaus noch einen weiteren großen Funktionsumfang für die serverseitige Programmierung, der im folgenden Text erklärt wird.

ÜBLICHE KOMPONENTEN EINER JAKARTA-EE-ANWENDUNG

JAVASERVER FACES – JSF

Um eine Anwendung im Webbrowser aufzurufen, benötigt der Anwender nichts anderes als den Webbrowser selbst. Die Anwendung hingegen ist dafür zuständig, die Kommunikation per HTTP-Requests zwischen Server und Client zu regeln und eine Benutzeroberfläche zu präsentieren. Dafür gibt es das standardisierte Framework JavaServer Faces. Es ermöglicht Entwicklern, relativ einfach eine Seite mit schon existierenden UI-Komponenten zu erstellen und diese auch mit Java-Objekten zu verknüpfen. Die Syntax ähnelt der von HTML.

Eine übliche Vorgehensweise ist, dass man für die nach außen zu repräsentierenden Java-Objekte DTOs (Data Transfer Objects) nutzt, um seine eigentliche Domäne zu verbergen. Dies hat den Hintergrund, dass in der Domäne die ganze Fachlogik enthalten ist und man diese nicht an jeden Benutzer preisgeben möchte.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/
     xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html">
    <h:head>
        <h1 class="ueberschrift">Dies ist eine Beispielseite</h1>
    </h:head>
    <h:body>
        <h2>Dein Konto!</h2>
        Name: <h:outputText value="#{user.name}"></h:outputText>
        E-Mail: <h:outputText value="#{user.email}"></h:outputText>
    </h:body>
</html>

Wie man sehen kann, wird hier mit objekt.attribut das Java-Objekt eingebunden. Für die genutzten Attribute müssen Getter vorhanden sein.

CONTEXTS AND DEPENDENCY INJECTION – CDI

Um die Komponenten in einer EE-Anwendung zu verknüpfen, kann man auf klassischem Wege ein neues Objekt der Klasse mit dem Schlüsselwort new instanziieren. Der Nachteil bei dieser Methode ist, dass man dadurch eine sehr starke Kopplung schafft und spätere Änderungen erschwert. Um das zu verhindern, kann man Dependency Injection nutzen. Damit übergibt man die Steuerung der Komponenten, sprich das Erzeugen und Zerstören oder Überwachen, an den Container bzw. den Application Server. Durch das Auslagern hat die Komponente, die die Instanzen injiziert bekommt, keinen direkten Bezug mehr und somit wurde die Kopplung verringert. Um einer Komponente eine andere injizieren zu lassen, reicht schon die Annotation @Inject an der Instanzvariable (Field Injection) oder am Konstruktor (Constructor Injection).

Bean Validation

Um keine fehlerhaften Eingaben eines Benutzers zu persistieren, sollten die mit den Informationen gefüllten DTOs rechtzeitig validiert werden. Die Bean Validation bietet hier eine standardisierte schichtübergreifende Validierung per Annotation. Diese Annotationen bilden dann Einschränkungen, sog. „Property Constraints“, die für dieses Objekt und ggf. seine Attribute gelten. Frameworks wie JSF, CDI oder JPA können die Objekte und deren Attribute dann anhand dieser Annotationen validieren und bei einer Verletzung der Einschränkungen reagieren. So kann in der Präsentationsschicht durch JSF sichergestellt werden, dass keine fehlerhaften Daten eingegeben werden können oder in der Persistenzschicht durch JPA, dass keine falschen Daten gespeichert werden.

@Email
private String email;

Auch wichtig zu nennen ist, dass es durch die Annotationen ganz leicht ist, eine Fehlermeldung mit zur Oberfläche zu geben. Durch ein Einfaches message = Ihre Fehlermeldung hinter der Constraint-Annotation, wird die Fehlermeldung gesetzt und genutzt, wenn die Einschränkung verletzt wird.

@Email(message = "Die angegebene E-Mail scheint nicht korrekt zu sein")
private String email;

Um diese auch in der Oberfläche sichtbar zu machen, muss hinter dem UI-Komponent dann ein message-tag gesetzt werden.

<h:inputText id="emailInput" value="#{dto.email}"> </h:inputText>
<h:message for="emailInput" style = "color:red"/>

Jakarta Persistence API – JPA

Die Jakarta Persistence API ist eine standardisierte Schnittstelle für Java-Anwendungen und ist, wie oben schon genannt, für das Persistieren der POJOs (Plain Old Java Objects) zuständig und hilft erheblich bei der Kommunikation mit der Datenbank. Wird ein Java-Objekt mit der Annotation @Entity versehen, kümmert sich JPA um die objektrelationale Abbildung, kurz ORM. Das heißt, dass ein Objekt in einer relationalen Datenstruktur abgebildet wird, indem eine Tabelle/Relation mit dem Namen der Klasse und für jedes Attribut eine Spalte erstellt wird. Ein Objekt dieser Klasse kann dann mit samt seinen Eigenschaften in der Datenbank als Entität persistiert werden. Wichtig zu erwähnen ist auch, dass ein Primärschlüssel mit der Annotation @Id gesetzt werden kann.

@Entity
public class User
{
    @Id
    private String id;
    private String name;
    private String email;
}

Application Server

Um die fertige EE-Anwendung auch aus dem Webbrowser heraus erreichen zu können, fehlt nur noch ein sogenannter Application Server. Dieser führt die fertige Anwendung aus und stellt sie in einem Netzwerk unter einem vorher festgelegten Port bereit. Wie bereits im Abschnitt CDI erwähnt, kümmert sich der Application Server auch um die Instanziierung, Steuerung und Zerstörung der Objekte. Außerdem bringt er noch Funktionen wie „ein Transaktionsmanagement, Authentifizierungsmöglichkeiten und vor allem [einen] stark abstrahierte[n] Zugriff auf Datenbanksysteme und Lastverteilung“ (https://www.it-talents.de/blog/it-talents/dein-start-in-java-ee, Jan-Dirk, 15.02.2016) mit.

ARCHITEKTUR

Da EE-Anwendungen häufig sehr große und webbasierte Anwendungen sind, ist es sehr wichtig, dass man hier auf eine saubere Struktur achtet. Deshalb teilt man seine Anwendung standardmäßig in vier Schichten auf.

Präsentationsschicht

Sie ist auch als View bekannt und bildet die Schnittstelle von der Anwendung zum Anwender. Um die Seite anschaulich zu gestalten wird hier auf HTML, CSS und JavaScript gesetzt. Durch JSF wird die Oberfläche auch mitgestaltet. JSF stellt hier einige vorgefertigte UI-Komponenten, wie bspw. Schleifen zur Verfügung und ermöglicht UI-Komponenten bedingt anzuzeigen.

Steuerungsschicht

Hier werden die Anfragen des Clients in Form von HTTP-Requests angenommen und mithilfe von POJOs und Controllern verarbeitet und an die nächste Schicht geleitet. Die Verarbeitung der HTTP-Requests übernimmt JSF, d.h., dass eine eigene Implementierung nicht mehr notwendig ist.

Serviceschicht

In dieser Schicht verbirgt sich unsere Domäne. Sie enthält die komplette Logik unserer Anwendung. Falls DTOs in der Oberfläche genutzt werden, um die Domäne nicht nach außen zu präsentieren, werden diese hier genutzt, um die Domänenobjekte zu instanziieren. Diese Objekte können dann an die Persistenzschicht gegeben werden.

Persistenzschicht

Hier findet die Kommunikation zwischen der Anwendung und der Datenbank mithilfe von der JPA statt. Sie sorgt dafür, dass die Domänenobjekte, auch JPA-Entities, in einer relationalen Datenbank sicher persistiert werden.

Quellen

  • https://jaxenter.de/java-ee-insights-jakarta-75228 https://javaee.github.io/javaserverfaces-spec/
  • https://entwickler.de/online/jsf-ueberblick-und-einsatzzweck-115542.html
  • https://entwickler.de/online/cdi-116046.html
  • https://jaxenter.de/alles-valide-bean-validation-in-pojos-mittels-aspektorientierter-programmierung-19882
  • https://zkmablog.com/2016/11/30/was-ist-jpa/
  • https://leon-brachwitz.de/?p=507

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.