Agile Coding mit Java, Kotlin, Spring und Microservices

Java 25: Die wichtigsten Features seit Version 21

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sun, 28 Sep 2025 06:02:00 +0000

Seit September 2025 gibt es das neue Java 25 LTS-Release. Neben den typischen Performance-Verbesserungen und Ressourcen-Optimierungen fallen vor allem die Vereinfachungen für Java-Neulinge auf. Mehr dazu in diesem Artikel.

Java 25 Features

Als neues LTS-Release bringt Java 25 einige Neuerungen im Vergleich zu Java 21 mit. Unter der Haube wurde viel optimiert, das Web-EntwicklerInnen bei der täglichen Arbeit eventuell gar nicht bemerken. Das sind zum Beispiel Optimierungen bei den Garbage-Kollektoren, der Support-Stop für 32 Bit Rechner oder mehr Unterstützung für die AOT-Kompilierung. In diesem Artikel fokussiere ich mich auf Änderungen, die auffallen. Alles Weitere findet ihr im Detail hier: https://openjdk.org/projects/jdk/25/

Rückblick Java 21 Features

Performance Tuning durch Versionsupdate

Java 25 ist performanter als Java 21. Ich teste es mit einer kleinen, produktiven Spring Boot Webanwendung. Dazu starte ich die Anwendung 10 Mal mit Java 21 und 10 Mal mit Java 25. Dabei protokolliere ich die Startzeiten, wie Spring Boot sie loggt.

Java 21

Schnellste Zeit: 2,976 Sekunden
Langsamste Zeit: 3,376 Sekunden
Durchschnitt: 3,087 Sekunden

Java 25

Schnellste Zeit: 2,537 Sekunden
Langsamste Zeit: 2,760 Sekunden
Durchschnitt: 2,653 Sekunden

In diesem einfachen Performancetest ist Java 25 circa 14% schneller als Java 21. Im Vergleich zu älteren Versionen, wie Java 17 oder 11 wäre die Performance-Steigerung noch deutlicher.

Module Import

In Java 25 wurde der Modul-Import eingeführt. Vorher konnte man einzelne Klassen, Konstanten oder Pakete importieren, mit JEP 511 können ganze Module importiert werden:

import module java.base;

public class Java25 {

    static void jep511_ModuleImport() {
        for (var item : List.of("1", 0))
            jep456_UnnamedVariable(item);
    }
    ...
}

Der vorherige Code-Ausschnitt benutzt die Klasse List innerhalb der Klasse Java25. Statt einem Einzelklassen-Import (import java.util.List;) wird sie zusammen mit den anderen Klassen des java.base-Moduls importiert.

Keine Klasse und vereinfachte main-Methode

Java 25 lernt sich leichter für Neulinge, weil:

die main-Methode kein "public static" und kein "String[] args" mehr benötigt.
keine Klasse mehr für die main-Methode braucht.
die Klassen des java.base-Moduls (hier ArrayList und IO) automatisch importiert sind. Wäre die main-Methode in einer Klasse, so müssten wir die Klasse ArrayList importieren.

Hier der Inhalt einer kompletten Java-Datei, welche die neue Klasse IO verwendet, um mit der Konsole zu interagieren:

void main() {
    var list = new ArrayList<String>();
    while (list.size() < 2) {
        IO.print("Enter max 2 items in Console: ");
        list.add(IO.readln());
    }
    IO.println("Java 25 items are " + list);
}

(Mehr dazu in JEP 512.)

Unbenannte Variablen

JEP 456 führt unbenannte Variablen in Java 22 ein. Bisher brauchte jede Variable einen Namen, auch wenn wir sie nicht benutzt haben. Nun können wir ungenutzte Variablen einfach mit Unterstrich _ benennen. Im folgenden Beispiel verwende ich unbenannte Variablen für eine Exception und einen String, die im Code ignoriert werden:

static void jep456_UnnamedVariable(Object obj) {
    try {
        switch (obj) {
            case String _ -> IO.println("Any Text.");
            case Integer number -> IO.println(10 / number);
            default -> IO.println("Unknown type");
        }
    } catch (Exception _) {
        IO.println("Exception caught without caring about details.");
    }
}

Kommentare in Markdown

Seit Java 23 wird Markdown als Format für Kommentare unterstützt. Dazu muss jede Kommentarzeile mit /// starten. Das sieht dann so aus:

/// # JEP 467
/// Java supports comments in Markdown format.
/// Other Java 25 JEPs in this class are:
/// * JEP 511
/// * JEP 456
public class Java25 {
    ...

Flexible Konstruktor-Bodies

JEP 513 lockert die Regel für Code im Konstruktor. Vor Java 25 durfte vor einem this(...) oder super(...) Konstruktoraufruf kein anderer Code stehen. Durch den flexiblen Konstruktor-Body ist dies nun erlaubt:

public class Java25 {

    Java25() {
        IO.println("Code before super() is allowed with JEP 513.");
        super();
        IO.println("Code after super() was allowed before.");
    }
    ...

Stream Gatherers

Gatherers (JEP 485) bereichern die Stream-Verarbeitung seit Java 24. Dazu hat die Stream API eine neue Methode gather, die Elemente im Stream sammelt. gather ist eine intermediate Operation, so dass der Stream nach gather weiter verarbeitet werden kann. Die Grundlagen zu Streams findet ihr hier.

Gatherer ist ein neues Interface, durch dessen Implementierung wir mit der gather Methode one-to-one, one-to-many, many-to-one und many-to-many Mappings im Stream durchführen können. Im folgenden zeige ich 5 Implementierungen, die Teil von Java 25 sind.

fold

Ein many-to-one Mapping im Stream.

List<Integer> numbers = List.of(1, 2, 3, 4, 5);

// Prints 15 (Stream has only 1 element after gather)
numbers.stream()
        .gather(Gatherers.fold(() -> 0, Integer::sum))
        .forEach(IO::println);

scan

scan nimmt den aktuellen und den vorherigen Wert und wendet eine BiFunction an, um den aktuellen Wert zu ändern.

// Result: [1, 3, 6, 10, 15]
numbers.stream()
        .gather(Gatherers.scan(() -> 0, (previous, current) -> previous + current))
        .toList();

windowFixed

Sammelt jedes Element in gleichgroßen Unterlisten.

// Result: [[1, 2], [3, 4], [5]]
List<List<Integer>> windows = numbers.stream()
        .gather(Gatherers.windowFixed(2))
        .toList();

slidingWindow

Ähnlich wie windowFixed nur mit Überlagerungen der Elemente in den gesammelten Unterlisten.

// Result: [[1, 2], [2, 3], [3, 4], [4, 5]]
List<List<Integer>> slidingWindows = numbers.stream()
        .gather(Gatherers. windowSliding(2))
        .toList();

mapConcurrent

Parallele Ausführung des Mappings im Gatherer, dabei wird die Ordnung des Streams erhalten.

// Result: true - proves that order was kept, 
// because each sliding window has a difference of 1.
IntStream.range(0, 10000)
        .boxed()
        .gather(Gatherers.mapConcurrent(100, x -> x + 1))
        .gather(Gatherers.windowSliding(2))
        .allMatch(pair -> pair.getLast() - pair.getFirst() == 1);

Scoped Values

Scoped Values JEP 506 sind eine Modernisierung von ThreadLocal. Mit ScopedValue definieren wir Objekte, die nur im Rahmen definierter Threads sichtbar sind. Im folgenden Beispiel startet die main-Methode einen Thread. Im Thread wird nur die Methode printScopedValue ausgeführt. Diese Methode greift per get() auf das Integer-Objekt innerhalb des Scopes zu, welches mit ScopedValue.where für die Ausführung des Threads gesetzt wurde.

private static final ScopedValue<Integer> X = ScopedValue.newInstance();

private static void printScopedValue() {
    IO.println("Instead of method-parameter a scoped value is used: " + X.get());
}

void main() {
    ScopedValue.where(X, 666).run(() -> printScopedValue());
    IO.println("Is scoped value bound in main thread: " + X.isBound());
    ...
}

Das Beispiel zeigt 2 Vorteile von ScopedValues:

Werte im Scope des Threads müssen nicht per Methoden-Parameter übergeben werden. Bei einem Wert ist das sicherlich kein Problem, ab 3 Parametern ist es aus Clean Code Sicht problematisch. Mit ScopedValue machen wir beliebig viele Objekte durch mehrfache where-Aufrufe in einem Thread verfügbar.
Außerhalb des Scopes sind die Werte nicht mehr verfügbar und werden so auch nicht unnötig lang im Speicher gehalten. Deshalb liefert X.isBound() im obigen Beispiel den Wert false. Ein Aufruf von X.get() liefert nur innerhalb des Thread den Wert 666. Außerhalb des Scopes (z.B. in der main-Methode) wirft es eine NoSuchElementException.

Hier ein weiteres Beispiel zur Veranschaulichung der NoSuchElementException. Im 2. Aufruf von thread.run() wird diese Exception geworfen, weil Y nur beim ersten Thread-Aufruf (.run(thread)) einen Wert im Scope hat.

private void scopedValueExample2() {
    ScopedValue<String> Y = ScopedValue.newInstance();

    Runnable thread = () -> {
        try {
            IO.println("Print scoped value: " + Y.get());
        } catch (NoSuchElementException _) {
            IO.println("Scoped value was not bound to this thread.");
        }
    };

    ScopedValue.where(Y, "12345").run(thread);
    thread.run();
    IO.println("Is scoped value bound in main thread: " + Y.isBound());
}

Fazit

Meine Java 25 Highlights sind Unbenannte Variablen, Gatherers und die Performance-Tunings, weil ich von diesen 3 Features im Berufsalltag am meisten profitieren werde.

Die Vereinfachungen um die main-Methode kommen Java-Neulingen mit Sicherheit zugute. Einsteiger in die Programmierung können sich so besser auf das Wesentliche konzentrieren. Sie lernen zuerst Schleifen, Variablen und if-Statements lernen, bevor sie mit Klassen und statischem Code "kämpfen" müssen.

Das Update unserer Spring Boot Anwendung von Java 21 auf Java 25 verlief problemlos. Wir mussten nur die Java-Version in der Maven-Konfiguration anpassen.

Den kompletten Code zu diesem Artikel gibt es hier:
https://github.com/elmar-brauch/java25

Lessons Learned – von der Idee bis zum Go-Live unseres KI-Chatbots

noreply@blogger.com (Elmar Brauch - Microservice Master) — Wed, 28 May 2025 05:55:00 +0000

Erfahrungen aus der Entwicklung bei Magenta Business

Die Entwicklung eines KI-Chatbots mit modernen Sprachmodellen (LLMs) war für unser Team nicht nur spannend, sondern auch lehrreich. Der Weg war gespickt mit Erfolgen, Rückschlägen und vielen Lessons Learned. Heute wird unser Chatbot aktiv von Kund:innen genutzt, aber der Weg dorthin war nicht geradlinig.

In diesem Beitrag teilen wir unsere Erkenntnisse – damit andere Teams schneller und mit weniger Stolpersteinen zum Ziel kommen.

KI in Java? Geht – und zwar ziemlich gut

Wer KI-Anwendungen entwickeln möchte, muss nicht zwingend in Python unterwegs sein. Für Java-Teams gibt es mittlerweile sehr gute Frameworks wie Spring AI und LangChain4J, die die Anbindung von Sprachmodellen wie GPT, Claude oder Mistral deutlich vereinfachen. Selbst das Integrieren von Backend-Funktionalität oder anderer Firmen-APIs per Tool in die KI ist mit diesen Frameworks einfach. So könnt Ihr relativ leicht einfache KI Agenten bauen.

Unser Tipp: Baut frühzeitig einen kleinen Prototypen – zum Beispiel eine REST-API, die ein paar typische Kundenfragen beantwortet. So schafft ihr Vertrauen im Team, gewinnt durch Demos Unterstützung aus der Fachseite und könnt Aufwände realistischer abschätzen.

Video LangChain4J

MVP statt Feature-Wildwuchs

Ein häufiger Fehler bei neuen Technologien: Man will gleich alles auf einmal. Unser erster KI-Chatbot war technisch aufwendig und in seinem Kontext sehr mächtig – aber leider nicht relevant genug für unsere Kund:innen. Der Use Case war zu spitz, das Interesse zu gering. Die Folge: kaum Nutzung, viel Aufwand, wenig Impact.

Lektion gelernt: Startet mit einem MVP (Minimal Viable Product).
Ein schlanker Chatbot, der ein echtes Problem löst, bringt mehr als ein hochgerüsteter Alleskönner mit viel zu kleiner Zielgruppe. Im laufenden Betrieb lässt sich immer noch optimieren und ausbauen – basierend auf echten Nutzungsdaten.

Beim zweiten Anlauf waren wir strategischer: Zuerst haben wir analysiert, wie stark der klassische Hilfe-Chat überhaupt genutzt wird. Daraufhin platzierten wir den KI-Chatbot an einer prominenten, deutlich frequentierten Stelle im Portal – und wurden mit deutlich höherer Nutzung belohnt.

Trotzdem empfehlen wir, erste KI-Bots an weniger kritischen Stellen zu testen. Denn KI-Systeme sind nicht immer vorhersehbar – und Fehler können schnell teuer werden. Beispiele wie der versehentliche Verkauf von Neuwagen für 1 Dollar zeigen, wie wichtig kontrollierte Einführungen sind.

Wir empfehlen auch den Chatbot am Anfang nur in einem kleinen Kontext einzusetzen. Das bedeutet beispielsweise, dass ihr den Chatbot auf einer einzelnen Webseite einsetzt und ihn auch nur für den UseCase auf dieser Webseite trainiert. Per SystemPrompt erklärt ihr dem Chatbot, dass er Fragen außerhalb des kleinen Kontextes freundlich Ablehnen soll oder an andere Kanäle (z. B. Hotline oder Hilfe-Seiten) verweisen soll.

Klare Kennzeichnung: UX beginnt beim Icon

Ein weiteres Learning aus der Praxis: Nur weil ein neuer Chatbot live ist, heißt das noch lange nicht, dass er auch genutzt wird. Anfangs wurde unser KI-Chat von vielen Kund:innen schlicht übersehen – wir hatten nämlich dasselbe Icon wie beim klassischen Live-Chat verwendet.

Den 2. KI-Chatbot haben wir mit einem neuen Icon und Beschriftung "KI-Chat" direkt am Chat-Starten-Button versehen. Ob das direkt zur gestiegenen Nutzung geführt hat, lässt sich nicht sicher sagen – aber: Die Nutzung ist da, und der klarere Hinweis hat wahrscheinlich geholfen, den Chatbot besser einzuordnen.

Guter Chatbot ≠ komplexer Chatbot

Nicht jeder Bot muss agentisch sein und eine prall gefüllte Wissensdatenbank haben. In unserem Fall reichte für viele Anliegen ein einfacher FAQ-Chatbot. Zusammen mit dem Service-Team haben wir analysiert:

Welche Probleme melden Kund:innen am häufigsten?
Welche Antworten gibt der Service immer wieder?

Mit diesem Wissen haben wir einen Bot gebaut, der ohne aufwendige Logik zuverlässig funktioniert – ganz einfach mit einem LLM, einem SystemPrompt und einer gepflegten FAQ-Liste.

Ein zusätzlicher Pluspunkt: Die Zusammenarbeit mit der Fachseite lief auch ohne KI-Vorerfahrung reibungslos. Die Kolleg:innen mussten nur ihr Wissen in eine strukturierte Liste bringen – ein KI-Experte übernahm das Feintuning. Umgekehrt musste der KI-Experte das Fachthema gar nicht im Detail verstehen.

Sicherheit, Kostenkontrolle und Guardrails

Sobald ein Chatbot live geht, wird er getestet – auch von weniger wohlmeinenden Nutzer:innen. Die ersten Angriffe auf unseren Bot waren klassische Injection-Versuche über die REST-API zwischen Frontend und Backend. Gut, dass wir bereits auf bekannte Security-Mechanismen gesetzt hatten:

Validierung aller Eingabenparameter - also auch der Chatnachricht
Detailliertes Logging zur Analyse von Angriffen

Dazu kamen KI-spezifische Maßnahmen:
Weil LLM-Anfragen pro Call abgerechnet werden, haben wir Kostenlimits und DoS-Schutzmechanismen implementiert. Außerdem empfehlen wir, sogenannte Guardrails zu aktivieren – also Filter für sensible Inhalte (Hass, Gewalt, Sexualität, Jailbreak etc.), die vom Cloud-Provider zusammen mit dem LLM als Service angeboten werden.

Lernen durch echte Chats

Egal wie viel man testet – im Live-Betrieb zeigt sich die Realität. Und die sieht oft anders aus als gedacht. Kund:innen schreiben nicht immer vollständige Fragen, sondern oft nur Stichworte wie „Rechnung“, „Störung“ oder „EVN“ (Einzelverbindungsnachweis). Trotzdem erwarten sie eine sinnvolle Antwort.

Aktuelle Sprachmodelle kommen damit erstaunlich gut zurecht – aber sie brauchen Kontext. Deshalb analysieren wir regelmäßig die echten Chatverläufe, um fehlendes Wissen nachzupflegen und den SystemPrompt zu verbessern.

Ein Beispiel: LLMs kennen in der Regel nicht das aktuelle Datum. Wird nach „Rechnung im Mai 2025“ gefragt, kann das Modell falsche Schlüsse ziehen, weil seine Trainingsdaten aus 2024 sind. Wir lösen das inzwischen, indem wir das aktuelle Datum automatisch im SystemPrompt mitgeben.

Chatbots mit KI Hilfe testen

Klassische Tests wie Unit- oder Integrationstests reichen bei KI-Systemen nicht aus, da die Antworten nicht immer eindeutig oder fest definiert sind. Entscheidend ist vielmehr, ob die Antworten hilfreich, konsistent oder missverständlich sind.

Deshalb setzen wir zusätzlich ein zweites KI-Modell ein, das die Antworten unseres Chatbots bewertet. In folgendem Video führe ich das vor.

Vektor-Datenbanken: Einfach reicht oft

Für viele Anwendungen braucht es keine dedizierte Vektor-Datenbank wie Milvus oder chroma. Wir haben sehr gute Erfahrungen mit der Vektor-Erweiterung für MongoDB und PostgreSQL gemacht – ideal für einfache RAG-Szenarien. Der große Vorteil: keine zusätzliche Infrastruktur, falls ihr diese stark verbreiteten Datenbanken schon im Einsatz habt.

Fazit

KI-Chatbots/-Anwendungen sind keine Raketenwissenschaft – besonders nicht in Java. Wer Webanwendungen bauen kann, bringt die besten Voraussetzungen mit, um auch KI-gestützte Chatbots schnell und effektiv umzusetzen. Moderne Frameworks wie Spring AI oder LangChain4J machen den Einstieg leicht – ganz ohne Python.

Der schnellste Weg zum Erfolg führt über erste Prototypen statt langer PowerPoint-Präsentationen. Schon ein einfacher Prototyp, der grundlegende Fragen beantwortet, überzeugt Kollegen und schafft interne Unterstützung. Ein aufwendiges Frontend ist dafür nicht nötig – der Nutzen steht im Vordergrund.

Am wichtigsten: Nutzt echte Kundendialoge und lernt daraus. Kunden sind kreativer als jedes Testskript und zeigen durch ihre Fragen, wo die KI glänzt und wo noch nachgebessert werden muss. Die enge Zusammenarbeit mit dem Service-Team hilft, echte Probleme zu verstehen und den Chatbot gezielt zu verbessern.

GIT Einführung und Best Practices

noreply@blogger.com (Elmar Brauch - Microservice Master) — Thu, 17 Apr 2025 13:55:00 +0000

Ob Entwicklung, Test, Betrieb oder Projektmanagement – Git ist nicht nur ein Thema für Developer. Es ist ein zentrales Werkzeug, das die Zusammenarbeit im gesamten IT-Team unterstützt und absichert. Doch was macht Git eigentlich so wertvoll?

Zentraler Zugriff auf den Code

Mit Git arbeitet das ganze Team an einer gemeinsamen Codebasis. Egal ob Backend, Frontend, Testautomatisierung oder Infrastruktur-as-Code – alle Dateien liegen im selben Repository. Das sorgt für Transparenz und verhindert, dass einzelne Teammitglieder mit unterschiedlichen Versionen arbeiten. Jeder kann nachvollziehen, wie sich der Code entwickelt und welche Änderungen aktuell sind.

Nachvollziehbarkeit von Änderungen

Git protokolliert jede Änderung. Wer hat wann was geändert – und warum? Diese Informationen sind Gold wert, wenn man verstehen möchte, warum ein Fehler entstanden ist oder wie ein Feature genau implementiert wurde. Gute Commit-Nachrichten und sauber strukturierte Branches machen es möglich, die Entwicklung lückenlos nachzuvollziehen.

Sicherheit durch Versionierung

Mit Git ist jede Änderung gesichert. Man kann jederzeit auf einen früheren Stand zurückspringen – etwa wenn nach einem Deployment plötzlich ein Fehler auftritt. Git fungiert damit wie ein intelligentes Backup-System für die gesamte Codebasis. Es schützt nicht nur vor Datenverlust, sondern gibt auch Sicherheit bei Experimenten und schnellen Hotfixes.

Git Basics – Die wichtigsten Konzepte

Repository

Ein Repository ist der Speicherort für den Projektcode und dessen gesamte Versionsgeschichte. Man unterscheidet zwischen zwei Arten:

Das lokale Repository liegt auf dem eigenen Rechner. Hier arbeitet man direkt am Code, führt Änderungen durch und sichert diese in Form von Commits.
Das Remote Repository liegt auf einem Server, zum Beispiel bei GitHub oder GitLab. Es dient als zentrale Anlaufstelle für das gesamte Team. Von hier wird der Code verteilt, synchronisiert und zusammengeführt.

Ein typischer Arbeitsablauf beginnt damit, dass man ein Remote Repository einmalig klont und anschließend lokal daran arbeitet.

Commit und Push

Änderungen am Code werden in sogenannten Commits gesichert. Jeder Commit enthält eine Momentaufnahme der geänderten Dateien sowie eine Nachricht, die beschreibt, was geändert wurde. So entsteht eine nachvollziehbare Änderungshistorie.

Sobald ein oder mehrere Commits lokal erstellt wurden, kann man sie durch einen Push an das Remote Repository übertragen. Erst dann werden die Änderungen für andere sichtbar.

Pull

Während man selbst Änderungen vornimmt, arbeitet auch das Team weiter. Damit die eigene lokale Version aktuell bleibt, werden die Änderungen anderer Teammitglieder regelmäßig aus dem Remote Repository abgerufen. Dieser Vorgang heißt Pull.

Branch

Ein Branch ist ein Entwicklungszweig, in dem Änderungen isoliert vorgenommen werden können. Auf diese Weise lassen sich neue Features, Bugfixes oder Experimente entwickeln, ohne den Hauptzweig des Projekts zu beeinflussen.

Ein Projekt hat in der Regel einen Hauptbranch (z. B. main oder master), von dem aus neue Branches erstellt und später wieder integriert werden.

Merge

Wenn ein Branch fertig entwickelt wurde, sollen die Änderungen wieder in den Hauptzweig einfließen. Mit einem Merge werden die beiden Zweige zusammengeführt, wobei die komplette Entwicklungshistorie erhalten bleibt. Git erstellt dabei einen zusätzlichen Merge-Commit, der die Zusammenführung dokumentiert und die Nachvollziehbarkeit sicherstellt.

Log und History

Git speichert jede Änderung mit Zeitstempel, Autor und Nachricht. Über die Historie lässt sich jederzeit nachvollziehen, wer wann welche Änderung vorgenommen hat. Das ist besonders hilfreich, wenn man verstehen möchte, warum ein bestimmter Fehler auftritt oder wie sich ein Feature entwickelt hat.

Video mit Demo zu diesem Abschnitt.

GIT im täglichen Einsatz & Best Practices

Git Kommandozeile oder Tools

Git kann auf unterschiedliche Weise genutzt werden – je nach persönlicher Vorliebe und eingesetztem Werkzeug. Viele moderne Entwicklungsumgebungen wie IntelliJ IDEA oder Visual Studio Code haben Git bereits integriert. So lassen sich typische Aktionen wie Commit, Pull oder das Anlegen von Branches direkt aus der IDE heraus durchführen – ohne zwischen Programmen wechseln zu müssen.

Alternativ kann man Git auch direkt über die Kommandozeile bedienen. Das bietet maximale Kontrolle und hilft dabei, die Abläufe im Hintergrund besser zu verstehen. Besonders für wiederkehrende Aufgaben oder automatisierte Prozesse ist die Kommandozeile oft die bevorzugte Wahl.

Ein weiterer beliebter Weg ist die Nutzung von TortoiseGit. Dieses Tool integriert sich direkt in den Windows Explorer und macht viele Git-Funktionen über das Kontextmenü mit der rechten Maustaste zugänglich. Gerade wer häufig mit Dateien und Ordnern arbeitet, profitiert von dieser nahtlosen Einbettung in die gewohnte Arbeitsumgebung.

Bei kleinen Änderung

Pull first

Bevor man Änderungen an einem Projekt vornimmt, sollte man sich angewöhnen, zunächst einen Pull durchzuführen. Damit stellt man sicher, dass man auf dem aktuellen Stand des Remote-Repositories arbeitet und alle Änderungen der Teammitglieder berücksichtigt.

Gerade bei kleineren Anpassungen – etwa an Konfigurationsdateien, Texten oder Dokumentation – ist die Gefahr groß, dass mehrere Personen gleichzeitig dieselbe Datei bearbeiten. Ein vorheriger Pull reduziert das Risiko von Merge-Konflikten erheblich und sorgt dafür, dass die eigenen Änderungen reibungslos integriert werden können.

Diese einfache Gewohnheit spart im Alltag viel Zeit und vermeidet unnötige Unterbrechungen im Arbeitsfluss.

Review vor Commit & Push

Bevor Änderungen committet und gepusht werden, sollte man sie kurz überprüfen. Ein Blick auf die geänderten Dateien und Inhalte hilft, versehentliche Änderungen oder temporäre Code-Anpassungen zu erkennen. Dieser Schritt verbessert die Qualität und verhindert unnötige Korrekturen im Nachhinein.

Gute Commit-Message mit Ticket-Referenz

In der Teamarbeit ist eine eindeutige Ticket-Referenz in der Commit-Message besonders wichtig. Sie ermöglicht es, jede Änderung direkt einer Aufgabe oder einem Fehlerbericht zuzuordnen. Idealerweise folgt die Nachricht einem einheitlichen Format im Team – zum Beispiel:

JIRA-123: Validation for email field added

Ein kurzer, präziser Satz reicht meist aus, wenn er zusammen mit der Ticket-ID den Kontext klar macht.

Ein Commit – eine Änderung

Ein Commit sollte sich immer auf genau eine inhaltliche Änderung konzentrieren. Wenn man beispielsweise gleichzeitig die Texte in der Benutzeroberfläche ändert und ein neues Logging einführt, gehören diese Änderungen in getrennte Commits. So bleibt die Historie nachvollziehbar, und einzelne Änderungen lassen sich bei Bedarf gezielt zurückverfolgen oder rückgängig machen.

Revert statt Löschen

Ein Revert nimmt eine Änderung zurück, indem ein neuer Commit erzeugt wird, der genau das Gegenteil der ursprünglichen Änderung macht. Der ursprüngliche Commit bleibt in der Historie erhalten, sodass der Verlauf vollständig nachvollziehbar bleibt – es gibt also keine Löschung, sondern eine bewusste Korrektur.

Ein Revert muss nicht unbedingt einen Fehler beheben. Manchmal hat man bewusst etwas ausprobiert, das später nicht mehr benötigt wird, und möchte es daher zurücknehmen. Dabei entstehen nach einem Revert zwei Commits im Branch: der ursprüngliche Commit und der Revert-Commit.

Obwohl es grundsätzlich möglich ist, Commits zu löschen, ist dies in der Praxis eher umständlich.

Große Änderung mit feature-Branches

Bei größeren Änderungen, die umfangreiche Anpassungen oder die Entwicklung neuer Funktionen betreffen, ist es ratsam, einen Feature-Branch zu verwenden. Ein Feature-Branch ist ein separater Entwicklungszweig, der vom Hauptzweig (z. B. main oder master) abzweigt und speziell für die Entwicklung eines bestimmten Features oder einer größeren Änderung gedacht ist.

Der Vorteil von Feature-Branches liegt darin, dass man isoliert an neuen Funktionen arbeiten kann, ohne die Stabilität des Hauptzweigs zu gefährden. Änderungen im Feature-Branch werden lokal entwickelt, getestet und überprüft, bevor sie durch einen Merge oder Pull-Request in den Hauptzweig integriert werden.

Mit dieser Methode bleibt der Hauptzweig stets stabil und funktionsfähig, während das Team parallel an neuen Features oder Verbesserungen arbeitet. Feature-Branches bieten außerdem den Vorteil, dass mehrere Teammitglieder gleichzeitig an verschiedenen Features arbeiten können, ohne dass sich ihre Änderungen gegenseitig beeinflussen.

Rebase

Ein Rebase wird häufig eingesetzt, bevor ein Feature-Branch in den master- oder main-Branch gemerged wird. Ziel ist es, den Feature-Branch auf den aktuellen Stand des Hauptzweigs zu bringen, um spätere Merge-Konflikte zu vermeiden. Dabei werden die eigenen Commits so umgehängt, als wären sie auf dem aktuellen Stand von master entstanden.

Technisch gesehen verschiebt Git dabei die Commits aus dem Feature-Branch auf die aktuelle Spitze des Hauptzweigs. So entsteht eine lineare Historie, in der alle Änderungen sauber aufeinander folgen – ganz ohne zusätzlichen Merge-Commit.

Empfehlung: Merge mit Squash

Bevor ein Feature-Branch in den master- oder main-Branch gemerged wird, empfiehlt es sich, alle Commits aus dem Feature-Branch zu einem einzigen Commit zusammenzufassen – dieser Vorgang wird „Squash“ genannt. Gerade bei der Entwicklung eines Features entstehen oft viele kleine Commits, die aus Sicht der Projekt-Historie nicht einzeln relevant sind.

Ein Merge mit Squash sorgt dafür, dass im Hauptzweig nur ein klar benannter Commit auftaucht, der das gesamte Feature beschreibt. Das hält die Historie übersichtlich und hilft, die Entwicklungsschritte später leichter nachzuvollziehen.

Diese Methode ist besonders nützlich bei der Arbeit im Team, da sie Wildwuchs in der Historie vermeidet und den Überblick über eingeführte Features erleichtert.

Git Blame - wer war es?

Mit dem Git-Befehl blame kann man herausfinden, wer eine bestimmte Zeile in einer Datei zuletzt geändert hat – und in welchem Commit das passiert ist. Das ist besonders hilfreich, wenn man verstehen möchte, warum ein bestimmter Code geschrieben wurde oder wer bei Rückfragen der richtige Ansprechpartner ist.

Git Diff - was hat sich genau geändert?

Mit git diff kann man sich Unterschiede zwischen zwei Versionen von Dateien anzeigen lassen – etwa zwischen dem aktuellen Stand im Arbeitsverzeichnis und dem letzten Commit oder zwischen zwei Branches. So sieht man genau, welche Zeilen hinzugefügt, geändert oder entfernt wurden.

Fazit

Git ist weit mehr als nur ein Versionierungstool – es ist ein unverzichtbares Fundament moderner Softwareentwicklung und ein Schlüsselbestandteil effektiver Teamzusammenarbeit. Git ermöglicht nicht nur die Verwaltung von Code, sondern spielt auch eine zentrale Rolle in modernen Release- und Deployment-Prozessen. Durch die enge Integration in Build- und Deployment-Pipelines können Änderungen im Git-Repository automatisch ganze Prozesse anstoßen, von der Erstellung von Builds bis hin zum Deployment in die Produktion. Dies fördert eine nahtlose und automatisierte Entwicklung und sorgt für eine effiziente, fehlerresistente Bereitstellung von Software.

Testgetriebene Entwicklung (TDD) Schritt für Schritt

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sat, 05 Apr 2025 06:02:00 +0000

Testgetriebene Entwicklung besteht aus 3 Schritten:

Rot: Schreib ausreichend viele fehlschlagende Unit Tests.
Grün: Implementiere nur so viel Code, dass alle Unit Tests erfolgreich durchlaufen.
Blau: Falls nötig, refaktorisiere den Code und Deine Unit Tests.

Dieser Blog-Artikel demonstriert TDD anhand des Clean Code Bowling Game Katas in Kotlin mit JUnit Tests. Außerdem betrachten wir wie KI unsere Arbeitsweise bei TDD verändert. Passen die Idee von TDD und aktuelle KI-Tools wie GitHub Copilot oder ChatGPT überhaupt noch zusammen?

Testgetriebene Entwicklung (TDD)

Ich kenne testgetriebene Entwicklung aus Extreme Programming (von Kent Beck) und Clean Code (von Robert C. Martin). Beide beschreiben den TDD-Zyklus als Entwicklungsprozess in 3 sich wiederholenden Schritten. Im folgenden Bild seht Ihr den Zyklus mit entsprechenden Farben, abgeleitet aus dem Status der Testergebnisse.

Rot - Test schlägt fehl

In der ersten Phase ROT wird mindestens ein neuer Testfall geschrieben oder ein bestehender erweitert. Wichtig ist dabei, dass dieser Testfall dann fehlschlägt. Daher die Status Farbe Rot. Es ist erlaubt mehrere Testfälle zu schreiben. Wichtig ist vor allem, dass die Tests vor dem eigentlich Code geschrieben werden. Meistens schlägt der angepasste Test aufgrund einer Assertion (Überprüfung einer Testbedingung) fehl. Am Anfang kann der Test auch aufgrund eines Compile-Fehlers fehlschlagen, wenn z. B. eine nicht existierende Klasse getestet werden soll. Weiter unten demonstriere ich das.

Grün - Implementierung des Testfalls

In der zweiten Phase GRÜN wird die Implementierung des Testfalls bzw. der produktive Code geschrieben. Dabei ist es wichtig möglichst minimalistisch vorzugehen. Schreibt nur den notwendigen Code, so dass der Testfall grün wird. Mehr produktiven Code schreibt ihr erst wieder einen nächsten TDD-Zyklus. Ein neuer Testfall zur Überprüfung einer Boolean-Methode erwartet z. B. true als Rückgabe. Die notwendige bzw. minimale Implementierung dieser Methode ist "return true" - mehr nicht!

Manche EntwicklerInnen fangen im ersten Zyklus mit Skeleton Implementierungen an, damit sie fehlschlagende Testfälle aufgrund von Compile-Fehler und die trivialen Methoden Implementierungen überspringen. Passt dabei aber auf, dass ihr wirklich bei einer Skeleton Implementierung bleibt, da ihr ansonsten keine testgetriebene Entwicklung mehr macht.

Blau - Refactoring

Die dritte Phase ist optional. Aus Clean Code Büchern wisst ihr, wie wichtig sauberer Code ist. Nehmt euch immer die Zeit zu refaktorisieren bzw. aufzuräumen, wenn alle Test grün sind. Dann seht ihr durch die Tests direkt, ob eure Änderungen etwas kaputt gemacht haben oder ob das Refactoring erfolgreich war und alles funktioniert. Das Refaktorisieren betrifft sowohl den produktiven Code als auch die Unit Tests. Sauberer Code wird überall benötigt, schaut euch dazu diesen Blog-Artikel an: JUnit5andSpringBootTest.html

TDD Schritt für Schritt Demo

In einem vorherigen Blog-Artikel stellte ich das Bowling Game Kata vor, siehe clean-code-dojo.html. Mittlerweile implementierte ich dieses Kata mittles testgetriebener Entwicklung. Die Implementierung habe ich in der Programmiersprache Kotlin mit JUnit 5 gemacht. Ich zeige euch hier die einzelnen Schritte aus den ersten TDD-Zyklen. Den fertigen Code mit einem Commit nach jedem Zyklus findet ihr in GitHub: https://github.com/elmar-brauch/cleanCodeDojo/.../GameTest.kt

1. Zyklus: ROT

class GameTest {
    @Test
    fun bowlingGame() {
        val game = Game()
    }
}

Vorab habe ich nur ein leeres Projekt erstellt. Der Test bowlingGame schlägt tatsächlich fehl, weil die Klasse Game zu diesem Zeitpunkt noch nicht existiert - also rot wegen Compile-Fehler.

1. Zyklus: GRÜN

class Game {}

Das ist die minimale Implementierung, um den Test aus dem ersten Zyklus grün zu bekommen...
Den optionalen Refactoring Schritt können wir überspringen.

2. Zyklus: ROT

@Test
fun bowlingGame() {
    val game = Game()
    game.role(0)
}

Wieder Fehlschlag wegen Compile-Fehler, da Methode role nicht existiert.

2. Zyklus: GRÜN

class Game {
    fun role(pins: Int) {}
}

Erneut nur eine minimale Implementierung, um den Compile-Fehler zu beheben.
Ihr könnt diese Zyklen auch zusammenfassen, indem ihr in ROT direkt den Test aus Zyklus 2 schreibt oder mit der Skeleton Implementierung startet.

3. Zyklus: ROT

@Test
fun roleOnly0() {
    val game = Game()
    game.role(0)
    assertEquals(0, game.score())
}

@Test
fun roleOnly1() {
    val game = Game()
    game.role(1)
    assertEquals(1, game.score())
}

Hier hätte man auch 2 Zyklen machen können: Compile-Fehler für Methode score und Test für role(0) und role(1).

3. Zyklus: GRÜN

class Game {
    private val pinsRolled = IntArray(21)

    fun role(pins: Int) {
        pinsRolled[0] = pins
    }

    fun score(): Int {
        return pinsRolled.sum()
    }
}

Nachträgliche Anmerkung: Für pinsRolled ein Array der Größe 21 zu verwenden, ist zu diesem Zeitpunkt zu früh und ein Verstoß gegen das Prinzip den minimales Code zu schreiben. Ein einfacher Int reicht in diesem Zyklus.

3. Zyklus: BLAU

Die Test-Klasse kann nun refaktorisiert werden, indem wir game als Klassenattribut verwenden:

class GameTest {
    val game = Game()

    @Test
    fun roleOnly0() {
        game.role(0)
        assertEquals(0, game.score())
    }

    @Test
    fun roleOnly1() {
        game.role(1)
        assertEquals(1, game.score())
    }
}

4. Zyklus: ROT

class GameTest {
    private val game = Game()

    @Test
    fun roleOnly0() {
        roleMany(0, 20)
        assertEquals(0, game.score())
    }

    @Test
    fun roleOnly1() {
        roleMany(1, 20)
        assertEquals(20, game.score())
    }

    private fun roleMany(pins: Int, roles: Int) {
        for (i in 1..roles)
            game.role(pins)
    }
}

Statt einem Wurf machen wir nun viele bzw. 20, so dass die Assertion im roleOnly1 Test fehlschlägt.

4. Zyklus: GRÜN

class Game {
    private val pinsRolled = IntArray(21)
    private var role = 0

    fun role(pins: Int) {
        pinsRolled[role++] = pins
    }
    ...
}

Zum Fixen des fehlgeschlagenen Tests, mache ich nur Anpassungen in der Methode role.

4. Zyklus: BLAU

@ParameterizedTest
@CsvSource("0,0,20,", "20,1,20")
fun roleTest(expectedScore: Int, pins: Int, roles: Int) {
    roleMany(pins, roles)
    assertEquals(expectedScore, game.score())
}

Mittels parametrisierten Tests können wir die JUnit Tests roleOnly0 und roleOnly1 zusammenfassen. Die Testfälle für das perfekte Spiel (nur Strikes) "300,10,12" und nur Spares "150,5,21" können wir dann später einfach in der @CsvSource aufnehmen.
Weitere Details zu parametrisierten Tests mit JUnit 5 findet ihr hier: JUnit5andSpringBootTest.html

5. Zyklus: ROT

@ParameterizedTest
@CsvSource("0,0,20,", "20,1,20", "150,5,21")
fun roleTest(expectedScore: Int, pins: Int, roles: Int)...

In diesem Zyklus füge ich den neuen Testfall "Spare in jeder Runde" bzw. "150,5,21" hinzu. In diesem Testfall wirft der Bowling Spieler mit jedem Wurf 5 Pins um.

5. Zyklus: GRÜN

class Game {

    private val pinsRolled = IntArray(21)
    private var currentRole = 0

    fun role(pins: Int) {
        pinsRolled[currentRole] = pins
        currentRole++
    }

    fun score(): Int {
        var sum = pinsRolled[18] + pinsRolled[19] + pinsRolled[20]
        for (role in 0..17) {
            sum += pinsRolled[role]
            if (spare(role))
                sum += pinsRolled[role + 2]
        }
        return sum
    }

    private fun spare(role: Int) = role % 2 == 0 &&
            pinsRolled[role] + pinsRolled[role + 1] == 10
}

Hier habe ich ein Refaktoring schon während der Implementierung gemacht, ich habe das Klassen Attribut role in currentRole umbenannt, da es ein Pointer zum aktuellen Wurf ist.
Ansonsten wurde die Berechnung der Punkte in der Methode score so angepasst, dass die Punkte des nächsten Wurfs nach einem Spare doppelt zählen.
Außerdem habe ich eine Hilfsmethode spare zum Erkennen von Spares geschrieben. Um unseren Test grün zu bekommen, muss ich in diesem Fall noch nicht zwischen Spare und Strike unterscheiden. Daher akzeptiert die spare Methode in diesem Zyklus auch Strikes.
Strikes werden zu diesem Zeitpunkt nicht richtig berechnet, da es dafür auch noch keinen Testfall gibt.

Die restlichen Zyklen...

Mittlerweile sollte das Vorgehen beim testgetriebenen Entwickeln klar geworden sein. In den folgenden Zyklen schreibe ich noch Tests für Spiele mit Strikes und Fehlerbehandlungen, wenn z.B. ein weiterer Wurf gemacht wird, obwohl das Spiel vorbei ist oder eine negative Zahl an die Methode role übergeben wird. Das zeige ich hier aber nicht mehr.

Wenn euch der komplette Code interessiert, schaut ihn euch hier in GitHub an: https://github.com/elmar-brauch/cleanCodeDojo/.../GameTest.kt
Meine Commits entsprechen nicht den Zyklen, sondern den Wechseln beim Bowling Game Kata, wenn es im Wasa von 2 Entwickler implementiert wird 😉

Falls ihr mit den Kampfsport-Begriffen nichts anfangen könnt: clean-code-dojo.html

Auswirkungen von KI auf testgetriebene Entwicklung

Künstliche Intelligenz verändert zunehmend unsere tägliche Arbeit als EntwicklerInnen – auch beim testgetriebenen Entwickeln. Tools wie GitHub Copilot, ChatGPT oder Windsurf schreiben nicht nur Code, sondern auch Testfälle. Doch was bedeutet das für TDD?

KI als Testgenerator

KI kann beim Schreiben von Unit Tests unterstützen, indem sie Vorschläge basierend auf bestehenden Code-Strukturen generiert. Dennoch bleibt es essenziell, Testfälle vor dem produktiven Code zu formulieren – wie es TDD verlangt. Die Überlegung "Was soll mein Code eigentlich tun?" lässt sich nicht an eine KI delegieren. Die Qualität der Tests hängt weiterhin davon ab, wie gut wir das gewünschte Verhalten verstehen und formulieren.

Unterstützung in Phase GRÜN

Wenn es darum geht, die minimale Implementierung zu schreiben, kann eine KI durchaus passende Code-Vorschläge machen. Gerade bei einfachen Funktionen spart das Zeit. Aber Achtung: Wer testgetrieben entwickelt, möchte ganz bewusst nicht sofort die komplette Lösung sehen. Die Herausforderung liegt im disziplinierten Vorgehen – und hier kann ein KI-Codevorschlag vom TDD-Weg ablenken.

Hilfe beim Refactoring

In der optionalen BLAU-Phase kann KI nützlich sein: Sie erkennt doppelte Logik, schlägt sauberere Strukturen vor und hilft beim Umbau von Code. Auch hier gilt: Nutze KI als Assistent, nicht als Architekt. Letztlich entscheidet der Mensch, was „clean“ ist – und was nicht.

KI-Driven Development als Anti-Pattern?

Ein wachsender Trend ist es, zuerst Code durch KI generieren zu lassen und anschließend Tests hinzuzufügen – also genau umgekehrt wie bei TDD. Das führt oft zu Tests, die nur bestätigen, was ohnehin schon programmiert wurde. Die Gefahr: Man verliert den prüfenden, hinterfragenden Blick, der TDD so wertvoll macht.

Fazit

Wenn ihr bisher TDD nicht verwendet habt, hoffe ich, dass euch dieser Artikel zeigt, wie man testgetriebene Entwicklung ganz konkret umsetzen kann – mit kleinen Schritten, klaren Zyklen und einem bewussten Fokus auf das Warum hinter dem Code. Ob mit oder ohne KI: TDD hilft uns, strukturiert zu denken, Fehlverhalten früh zu erkennen und robuste Software zu schreiben.

Künstliche Intelligenz kann dabei eine wertvolle Unterstützung sein – beim Schreiben von Tests, bei der minimalen Implementierung oder beim Refactoring. Aber sie ersetzt keine saubere Denkarbeit. TDD bleibt ein Werkzeug für uns Menschen, um Kontrolle über unsere Software zu behalten – gerade weil KI unsere Entwicklung beschleunigt und automatisiert. Erst testen, dann coden – das ist und bleibt der Kern.

Probiert es doch einfach mal aus – am besten mit einem Kata wie dem Bowling Game. Denn genau dafür wurden sie gemacht: Um gute Entwicklungspraktiken zu trainieren. Schritt für Schritt. Test für Test.

Spring Boot vs. Security Vulnerabilities

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sun, 16 Feb 2025 10:35:00 +0000

Der Security-Scanner in eurer CI/CD-Pipeline hat eine kritische Security Vulnerability gefunden. In einer 3rd-Party-Bibliothek gibt es eine Schwachstelle.
Der Scanner kennt bereits die Lösung: ein Upgrade der Bibliothek.
Doch ist das wirklich immer die beste Idee?
Oder gibt es Aspekte wie Wartbarkeit und Stabilität zu beachten?

Security Scanner und Vulnerabilities

CI/CD-Pipelines mit Code-Scannern sind essenzielle Werkzeuge in der professionellen Softwareentwicklung. In meinem Projekt nutzen wir eine GitLab CI/CD-Pipeline mit diversen Scannern. Einer davon analysiert unsere Third-Party-Bibliotheken auf Sicherheitslücken, also veraltete Abhängigkeiten mit bekannten Schwachstellen. Diese werden in einem Report aufgelistet. Für jede Schwachstelle sind detaillierte Informationen abrufbar.

Hier ein Beispiel aus einem Java-Projekt mit Spring Boot 3.4.2.

Titel und Beschreibung der Vulerability bzw. des Security Problems.
Severity: Kategorisiert die Kritikalität in fünf Stufen von "Info" bis "Kritisch" (im Beispiel "Hoch").
Location: Zeigt die betroffene Stelle, hier das Dependency-Management in der pom.xml.
Evidence & Solution: Nennen die betroffene Bibliothek und die gefixte Version.

Video about this article in English

Security Vulnerability gefunden - was nun?

Ist eine Sicherheitslücke gefunden, scheint die Lösung klar:
Upgrade der betroffenen Bibliothek auf die gefixte Version.
Doch ist das immer der beste Weg?

Wann ein direktes Upgrade notwendig ist

Ja - bei extrem kritischen Sicherheitslücken! Diese sollten so schnell wie möglich gefixt werden, da eine unmittelbare Bedrohung besteht (z. B. Remote Code Execution oder bekannte Exploits in der Wildnis).

Wann ein direktes Upgrade problematisch sein kann

In allen anderen Fällen müssen wir die Konsequenzen solcher Upgrades abwägen:

1. Auswirkungen auf die Stabilität

Unsere Software wurde mit den bestehenden 3rd-Party-Bibliotheken getestet. Wird eine Version geändert, können unerwartete Probleme auftreten. Deshalb sind nach einem Upgrade erneute, idealerweise automatisierte Tests notwendig, um Stabilitätsrisiken und neue Bugs auszuschließen.

2. Herausforderungen für die Wartbarkeit

Die meisten professionellen Software-Systeme setzen auf ein Framework wie Spring Boot, weil es das Dependeny- und Versions-Management übernimmt. Wird eine Dependency manuell aktualisiert, kann das zu Inkonsistenzen führen. Konkret stellt sich die Fragen:

Kann der Security-Fix später entfernt werden, wenn Spring Boot das Problem selbst löst?
Ist die neue Spring-Boot-Version kompatibel mit der gefixten Bibliothek?

Jede manuelle Änderung erhöht den Wartungsaufwand.

Konkretes Beispiel: Fix einer betroffenen Bibliothek

Zurück zur konkreten Security Vulnerability aus dem vorherigen Screenshot. Die Bibliothek json-smart ist betroffen und benötigt ein Upgrade. Mit IntelliJ analysiere ich die Maven-Konfiguration, um herauszufinden, dass json-smart von spring-boot-startet-test benutzt wird.

Der Fix der Dependency erfolgt in 2 Schritten:

Die betroffene Bibliothek json-smart wird per "exclusion" aus der Bibliothek spring-boot-starter-test entfernt.
Die Upgrade-Version der Bibliothek wird mit Versionsangabe "2.5.2" extra in die Liste der Dependencies aufgenommen.

Konkret sieht es so in der pom.xml aus:

<dependencies>
    <!-- other dependencies -->
    <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-test</artifactId>
       <scope>test</scope>
       <exclusions>
          <exclusion>
             <artifactId>json-smart</artifactId>
             <groupId>net.minidev</groupId>
          </exclusion>
       </exclusions>
    </dependency>
    <dependency>
       <groupId>net.minidev</groupId>
       <artifactId>json-smart</artifactId>
       <version>2.5.2</version>
       <scope>test</scope>
    </dependency>
</dependencies>
Ohne Security-Fix würden wir uns das Management von json-smart sparen, dann macht Spring Boot das.
<dependencies>
    <!-- other dependencies -->
    <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-test</artifactId>
       <scope>test</scope>
    </dependency>
</dependencies>

Praktischer Umgang mit Dependency-Vulnerabilities

Es gibt drei mögliche Strategien im Umgang mit Sicherheitslücken in Abhängigkeiten:

Direkter Fix (Upgrade der betroffenen Bibliothek)

Vorteile: Schnell umsetzbar
Nachteile: Erhöhter Wartungsaufwand, mögliche Stabilitätsprobleme

Indirekter Fix (Upgrade des Frameworks, z. B. Spring Boot)

Vorteile: Nachhaltiger, besser für Wartbarkeit
Nachteile: Weitere indirekte Updates, die getestet werden müssen,
nicht immer sofort verfügbar

Ignorieren (wenn nicht relevant)

Vorteile: Kein zusätzlicher Aufwand
Nachteil: Risiko, wenn Schwachstelle doch kritisch ist

Wann ignorieren eine sinnvolle Option ist

Nicht jede gemeldete Schwachstelle ist relevant. Security Scanner haben oft False Positives. Ein typisches Beispiel ist eine Sicherheitslücke in einer Test-Dependency.

Im obigen Beispiel betrifft json-smart nur spring-boot-starter-test, das ausschließlich in automatisierten Tests verwendet wird (siehe scope="test"). Da es nicht produktiv genutzt wird, kann man den Fix ignorieren, insbesondere wenn die aktuellste Version von Spring Boot genutzt wird und kein indirektes Update verfügbar ist.

Indirekter Fix durch Upgrade des Frameworks

Ein indirekter Fix bedeutet, dass wir die Version unseres Frameworks (z. B. Spring Boot) aktualisieren. Dadurch erhalten wir nicht nur den Security-Fix, sondern modernisieren gleichzeitig unser System. Dabei werden auch weitere Bibliotheken aktualisiert, was zusätzliche Änderungen im System mit sich bringt. Dies kann zu unerwarteten Nebenwirkungen führen, weshalb Regressionstests notwendig sind. Dennoch ist dies die beste langfristige Lösung für die Wartbarkeit, da sie das System aktuell hält und zukünftige Sicherheitsrisiken reduziert.

Gerade in großen Projekten mit vielen Schwachstellen führen direkte Fixes zu einer Verschlechterung der Wartbarkeit. Daher sollte bevorzugt geprüft werden, ob eine Aktualisierung des Frameworks möglich ist.

Fazit

Security-Schwachstellen sollten ernst genommen werden, aber nicht blind gefixt werden.
Die richtige Strategie hängt vom konkreten Fall ab:

✅ Extrem kritische Lücke? → Direktes Upgrade notwendig
✅ Weniger kritische Lücke? → Indirektes Upgrade oder warten auf indirektes Upgrade
✅ Nicht produktiver Code betroffen? → Ignorieren oder indirektes Upgrade

Im Idealfall fixt ihr Sicherheitslücken, indem ihr euer Framework aktualisiert.
Das sorgt nicht nur für Sicherheit, sondern hält euer Software-System langfristig wartbar und stabil.

RAG Chatbot mit Spring AI, AWS Bedrock und Vektor Datenbank

noreply@blogger.com (Elmar Brauch - Microservice Master) — Mon, 26 Aug 2024 05:27:00 +0000

Wie bringt man einem KI Chatbot Unternehmens-Knowhow bei? Retrieval Augmented Generation (RAG) ist eine Lösung, die ich in diesem Artikel mit Amazon Bedrock, der Vektor Datenbank pgvector und Spring AI umsetze.

RAG Architektur-Überblick

Der Benutzer chattet mit dem Chatbot unserer Anwendung (hier "RAG Chat Service"). Diesen Teil implementieren wir selbst mit Java und Spring AI. Als LLM bzw. Chat-Service verwendet unsere Spring AI Anwendung den AWS Dienst Bedrock mit dem Sprachmodell Titan (eine Alternative zu GPT von OpenAI). Ohne eigene Dokumente in einer Vektor Datenbank, hätten wir so einen Chatbot ohne Unternehmens-spezifisches Wissen - vergleichbar mit ChatGPT. So etwas habe ich schon mit GPT gebaut, siehe dazu gpt-3 in deiner Java Webanwendung.

Unsere Anwendung sucht in der Vektor Datenbank nach zur Chat-Anfrage des Benutzers passenden Dokumenten. Mit diesen Unternehmens-spezifische Texten reichert unsere Anwendung die Interaktion mit dem Bedrock Titan Chat Service an. Dadurch bekommt der Benutzer eine Chat-Antwort passend zum Kontext des Unternehmens.

Um die Datenbank mit vektorisierten Dokumenten zu füllen, verwendet der "Document Importer" unserer Anwendung den AWS Bedrock Embedding Service des Sprachmodells Titan. Die Dokumente bzw. Texte werden aus Quellen des Unternehmens eingelesen, mit Hilfe des AWS Embedding Services vektorisiert und dann in der Vektor-DB gespeichert.

Video about Spring AI and Azure

Dokumente in pgvector importieren

Als Vektor-Datenbank verwende ich PostgreSQL mit der Erweiterung pgvector. Diese Datenbank wird von Spring AI unterstützt und lässt sich im Docker Container starten:

docker run -d --name vector_db --restart always -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=vector_store -e PGPASSWORD=postgres --log-opt max-size=10m --log-opt max-file=3 -p 5433:5432 ankane/pgvector:v0.5.1

Die Maven Konfiguration für den Document Importer und den Chatbot im nächsten Abschnitt sieht so aus:

<dependencies>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-bedrock-ai-spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-pgvector-store-spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
        <scope>runtime</scope>
    </dependency>

    ...
</dependencies>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>0.8.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
<repositories>
    <repository>
        <id>spring-milestones</id>
        <name>Spring Milestones</name>
        <url>https://repo.spring.io/milestone</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

Da Spring AI noch keine 1.0 Version hat, finden wir es noch nicht im zentralen Maven-Repository sondern im Spring Milestones Repository.
Für den Chatbot und die Vektorisierung benötigen wir die "spring-ai-bedrock-ai-spring-boot-starter" Bibliothek.
Für die Vektor-Datenbank die andere Spring AI und PostgreSQL Dependencies.

Damit bauen wir einen einfachen Importer:

@Component
public class DocumentImport {
    private final VectorStore vectorStore;
    private final TokenTextSplitter textSplitter = new TokenTextSplitter();

    private static final String EXAMPLE_DOCUMENT = "Long text with company specific content.";

...

    public void importDocuments() {
        var vectorizedDocumentChunks = textSplitter.split(EXAMPLE_DOCUMENT, 800)
                .stream()
                .map(chunk -> new Document(chunk, Map.of("Add", "meta", "data", "here")))
                .toList();
        vectorStore.accept(vectorizedDocumentChunks);
    }
}

Die VectorStore Bean stellt Spring AI automatisch zur Verfügung.
TokenTextSplitter ist eine Klasse aus den Spring AI Bibliotheken zum Aufsplitten langer Texte. 800 definiert die Größe der aufgeteilten Textblöcke. Den Wert 800 habe ich in einer Spring-Klasse als dortigen default abgeschaut.
Die aufgeteilten Textblöcke wandle ich in Spring AI Document Objekte um. Die Document Objekte könnt ihr mit Metadaten in Form einer Map anreichern.
Der letzte Schritt vectorStore.accept schreibt eine Liste aus allen Document Objekten des ursprünglichen, Firmen-spezifischen Beispiel-Dokuments in die Vektor-DB. Im VectorStore ist eine Spring AI Bean EmbeddingClient injiziert, welche die Vektorisierung der Document Objekte vornimmt.

Damit Spring AI automatisch alle benötigten Beans bereitstellt, konfiguriert ihr in application.porperties:

spring.ai.bedrock.aws.region=eu-central-1
spring.ai.bedrock.aws.access-key=TODO_set_me
spring.ai.bedrock.aws.secret-key=TODO_set_me

spring.ai.bedrock.titan.chat.enabled=true

spring.ai.bedrock.titan.embedding.enabled=true
spring.ai.bedrock.titan.embedding.input-type=text
spring.ai.bedrock.titan.embedding.model=amazon.titan-embed-text-v1

spring.datasource.password=postgres
spring.datasource.username=postgres
spring.datasource.url=jdbc:postgresql://localhost:5433/vector_store

spring.ai.bedrock.aws definiert die Verbindung zum AWS Bedrock Service sowohl für den Embedding Service zur Dokumenten-Vektorisierung als auch für den Chat Service.
spring.ai.bedrock.titan aktiviert und konfiguriert die beiden AWS Bedrock Dienste. Hier sind noch weitere Feineinstellungen der KI möglich (maxtoken, temprature etc.).
spring.datasource beschreibt die Verbindung zur Datenbank.

RAG Chatbot mit Vektor-DB

Einen Chat mit Spring AI und AWS Bedrock implementieren wir so:

private final BedrockTitanChatClient chatClient;

public void chat(String message) {
    var userMessage = new UserMessage(message);
    // TODO Integrate VectorStore
    var prompt = new Prompt(List.of(userMessage));
    var aiResponse = chatClient.call(prompt);
    log.info("AI response: {}", aiResponse.getResult().getOutput().getContent());
}

Die Chat message des Benutzers wandeln wir in ein Objekt der Spring AI Klasse UserMessage um.
Das UserMessage Objekt überführen wir in ein Spring AI Prompt Objekt. (In das Prompt Objekt integrieren wir in einem späteren Schritt noch die Daten aus der Vektor-DB.)
Das Prompt Objekt schicken wir an den AWS Bedrock Chat Service. Dazu verwenden wir eine Bean, die von Spring AI automatisch erzeugt wurde: BedrockTitanChatClient. Die Antwort der KI logge ich in die Konsole - es ist eine kleine Demo-Anwendung.

Um aus diesem einfachen Chat-Service ein RAG zu machen, binden wir noch die Vektor-Datenbank mit unserem Unternehmens Know-How ein. Dazu ergänzen wir den zuvor gezeigten Code:

private final VectorStore vectorStore;

private static final SystemPromptTemplate template = new SystemPromptTemplate("""
        Du assistierst bei Fragen zum UseCase X.
        
        Verwende die Informationen aus dem Abschnitt DOKUMENTE, um genaue Antworten zu geben,
        aber tu so, als ob du diese Informationen von Natur aus wüsstest.
        Wenn du dir nicht sicher bist, gib einfach an, dass du es nicht weißt.
        
        DOKUMENTE:
        {documents}
        """);

public void chat(String message) {
    ...
    var similarDocuments = vectorStore.similaritySearch(message)
            .stream()
            .map(Document::getContent)
            .collect(Collectors.joining(System.lineSeparator()));
    var contextMessage = template.createMessage(Map.of("documents", similarDocuments));

    var prompt = new Prompt(List.of(contextMessage, userMessage));
    ...
}

Mit der VectorStore Bean suchen wir nach ähnlichen Dokumenten in der Vektor-Datenbank: vectorStore.similaritySearch
Die so gefundenen Document Objekte wandeln wir in einen langen String um. Das passiert in den Stream-Operationen direkt nach der Ähnlichkeits-Suche. Mehr zu Streams gibt es hier.
Neben der UserMessage stecken wir dieses mal ein 2. Message Objekt (contextMessage) als Kontext in die Prompt Instanz. Diese 2. Message bauen wir mit dem Spring AI SystemPromptTemplate. Das Template beschreibt das Verhalten unserer KI und auf welche Dokumente mit Firmen-spezifischen Wissen die KI zugreift. Auf diese Weise ist im AWS Bedrock Chat Service kein Firmen-spezifisches Wissen dauerhaft persistiert. Den Unternehmenskontext übertragen wir mit jeder Chat Anfrage passend zur Nachricht des Benutzers.

Fazit

Durch AWS Bedrock habe ich einfachen Zugriff auf KI Sprachmodelle. Eine einfache Vektor Datenbank lässt sich schnell mit Docker starten. Mit Spring AI benutzen wir diese Dienste leicht und verbinden sie so zu einem RAG.

Wenn euch die Qualität des Amazon Titan Sprachmodells nicht überzeugt, testet andere Sprachmodelle wie Mistral AI oder Llama in AWS Bedrock. Dank Spring AI braucht ihr nur die Maven-Dependencies und die application.properties anzupassen.

Den von mir gezeigten Code, findet ihr bei GitHub: https://github.com/elmar-brauch/aws-bedrock-rag

OpenAI Chatbot

AI Assistent mit LangChain4j und Spring Boot

noreply@blogger.com (Elmar Brauch - Microservice Master) — Thu, 25 Jul 2024 06:00:00 +0000

LangChain4j ist ein neues und populäres Framework, um LLMs, Vektor-Datenbanken und weitere KI-Funktionen in Java Systemen zu nutzen. In diesem Artikel integrieren wir LangChain4j in eine Spring Boot Anwendung.

Spring Boot mit LangChain4j

Maven Dependencies

Stand 22.07.2024 hat LangChain4j noch eine Nuller-Version im Maven Repository. LangChain4j integrieren wir als 3rd-Party Bibliothek in unser Spring Boot Projekt:

<dependencies>
    <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
       <groupId>dev.langchain4j</groupId>
       <artifactId>langchain4j-spring-boot-starter</artifactId>
       <version>0.32.0</version>
    </dependency>
    <dependency>
       <groupId>dev.langchain4j</groupId>
       <artifactId>langchain4j-azure-open-ai-spring-boot-starter</artifactId>
       <version>0.32.0</version>
    </dependency>

langchain4j-spring-boot-starter ist keine von Spring gewartete Spring Boot Starter Dependency. Die Spring Boot Starter Konfiguration wird vom LangChain4j Opensource Projekt entwickelt. Deshalb muss die Versionsnummer angegeben werden, hier 0.32.0.
Ich verwende ein OpenAI LLM in Azure. Daher benötige ich neben der Basis Bibliothek langchain4j-spring-boot-starter noch diese Azure-LLM Integrations-Bibliothek langchain4j-azure-open-ai-spring-boot-starter.

Konfiguration in application.properties

Die beiden Spring Boot Starter Dependencies bringen eine Auto-Konfiguration mit. Diese passen wir für den Zugriff auf unseren OpenAI LLM Azure-Service in den appliation.properties wie folgt an:

langchain4j.azure-open-ai.chat-model.api-key=geheim
langchain4j.azure-open-ai.chat-model.endpoint=https://azure.url
langchain4j.azure-open-ai.chat-model.deployment-name=gpt-4-turbo-preview
langchain4j.azure-open-ai.chat-model.log-requests-and-responses=true

logging.level.dev.langchain4j=DEBUG
logging.level.dev.ai4j.openai4j=DEBUG

...endpoint und ...deployment-name definieren wo unser LLM Service gefunden wird. Anhand des vollen Property-keys "langchain4j.azure-open-ai" steht fest, dass es die Azure Cloud ist.
Der API-Key in ...api-key authentifiziert und autorisiert meine Spring Boot Anwendung für den Zugriff auf den Azure LLM Service.
Alle weiteren Properties sind optional. Hier sehen wir noch Einstellung für das Debug-Logging zur Interaktion mit dem LLM.
Chatbot Bean mit @AiService und @SystemMessage

Einfache Chatbots definieren wir mit LangChain4j per Interface und Annotation.
Der Spring Boot Starter in der LangChain4j Bibliothek erzeugt daraus eine Chatbot Bean
- die Implementierung des Interfaces stellt LangChain4j bereit.

import dev.langchain4j.service.SystemMessage;
import dev.langchain4j.service.spring.AiService;

@AiService
interface Assistant {
    @SystemMessage("Du bist ein freundlicher Assistent und antwortest in Deutsch.")
    String chat(String userMessage);    
}

@AiService stellt die Implementierung des Interfaces und eine Assistant Bean bereit.
@SystemMessage definiert den 1. System-Prompt des Chatbots.
Die Assistant Bean nutzen wir in unserer Spring Anwendung analog zu beliebigen, anderen Beans. Für einfache Tests bzw. Demos exponieren wir den Chatbot per RestController:
@RestController
class AssistantController {
    @Autowired
    private Assistant assistant;

    @GetMapping("/assistant")
    public String assistant(@RequestParam String message) {
        return assistant.chat(message);
    }
}
Chatverlauf merken
Testen wir den Chatbot mit diesen beiden GET-Requests (im Browser):
http://localhost:8080/assistant?message="Hallo, ich bin Elmar"
http://localhost:8080/assistant?message="Wie ist mein Name"
Dann stellen wir fest, dass der Chatbot kein Gedächtnis hat und im zweiten Request den Namen nicht mehr kennt. Das ändern wir mit einer ChatMemory Bean:
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import dev.langchain4j.memory.ChatMemory;
import dev.langchain4j.memory.chat.MessageWindowChatMemory;

@Configuration
class AssistantConfiguration {
    @Bean
    ChatMemory chatMemory() {
        return MessageWindowChatMemory.withMaxMessages(10);
    }  
}
Durch die ChatMemory Bean kennt der Assistant in diesem Code-Beispiel die letzten 10 Chat-Nachrichten. In diesem Beispiel teilen sich alle Benutzer dasselbe Gedächtnis im Chatbot - bei mehr als einen Benutzer benötigen wir eine andere Lösung.

Fazit
LangChain4j bietet noch viele weitere interessante Features, siehe dazu https://docs.langchain4j.dev/. Es ist vergleichbar zu Spring AI. Beide Frameworks vereinfachen die Nutzung von LLMs erheblich und bieten praktische Features für die Entwicklung und Integration von AI in bestehende Java-Anwendungen.

IT Stability Health Radar

noreply@blogger.com (Elmar Brauch - Microservice Master) — Mon, 22 Apr 2024 13:36:00 +0000

How to run IT applications stable in production? Instead of providing one more operations readiness checklist, I created an IT Stability health radar. This helps in agile projects to choose the next stability improvement depending on current situation. All non-functional requirements in this health radar are prioritized by levels, so that you and your Product Owner can plan them properly.

IT Stability Health Radar

Companies have often operations readiness checklists, which describe what to do before customers can use an IT system in production. These long lists with non-functional requirements are not easy to use and fulfill in agile working environments. Product owners and business stakeholders have a hard time to accept these requirements, if they come all at the same time and might block a big part of the team for several weeks.

In this article I focus on non-functional requirements related to IT stability. I group and order them, so that you learn where to start and which stability requirements should be planned next. I decided to not go for an operations or production readiness health radar, because that would include many more requirement domains like security, legal, etc. Security has obviously an impact on IT stability, but since this is such a big field, I decided to keep this out of scope (for now).

The non-functional requirements of my IT Stability Health Radar are grouped in 4 categories:

High Availability with focus on redundancy and elimination of single point of failures.
Performance is about how your application handles many parallel usage, so that it does not fail during load peaks.
Resilient Code is about how developers should implement the application to be resilient in case of unexpected events.
Operations with focus on change process and monitoring with alerting.

Each category has 5 levels. Level 1 contains the critical foundation of a stable IT system. Level 5 is very advanced and contains the last requirements, which should be tackled for new systems. Depending on the maturity of your application and the expected stability at some point you should address all requirements including level 5.

Requirements in each category might depend on each other. E.g. you can not fully address level 2 requirement (horizontal) scalability, if your application can not run redundant on more than 1 server (level 1 high availability requirement). Requirements in different categories do not depend on each other. But I advise to develop non-functional requirements level by level, because the selected level is based on effort and stability impact estimations.

Category: High Availability

Level 1

Redundancy
In case your application is productive, it should be running on more than one server to ensure high availability.

Level 2

Scalability
In case of occasionally high load, your application must scale automatically to handle successful load peaks.

Level 3

Empty level in this category.

Level 4

Multi Availability Zones
In case your application is high available (redundant servers), it should be deployed in multiple availability zones.

Level 5

Chaos monkey
Test the resilience of your application with chaos engineering: At least in your test environment, you could activate "chaos monkeys" to test your applications resilience.

Single point of failure
In case your application is high available, you should reduce the single points of failure. E.g., you have 2 servers behind 1 load balancer, that means the load balancer is your single point of failure.

Category: Performance

Level 1

Empty level in this category.

Level 2

Performance tests
Test if your application can handle the expected load. You must know the limits of your application - which load peeks can be handled by your application.

Throttling (incoming)
Your application can not scale "infinitely", so you should set a rate limit for incoming request / calls.

Level 3

Caching
In case of expectable high load, caching should be added to your application. Think about proper caching strategies for your application and Use-Cases. Find more about caching with Spring here.

Resource limits
In case your application can scale vertical, set resource limits. Limit CPU and RAM consumption of Containers (vertical scaling) to ensure that horizontal scaling is also possible.

Level 4

Performant database design
In case your system uses a database, verify that database design does not cause bad performances.

Level 5

Automatic Performance tests
Performance tests should be regularly executed by your CICD pipeline. Focus first on the critical UseCases of your application. When your automated performance tests become stable and do not produce false alerts, you can start adding other UseCases.

Throttling (outgoing)
In case your application sends request to other systems, you could protect those systems with throttling for outgoing requests.

If you work on requirements in performance category, you should know about good practices for performance tuning.

Category: Resilient Code

Level 1

Reconnect
In case your application loses the connection to another system, database, API etc., it must not crash and is able to reconnect. This event should be logged.

Error handling
In case of errors, your application must catch and handle them in proper way. This could be logging, retry or converting to own error message depending on error type (business, technical) and context.

Tests
Your application must be tested. You should automate your tests from scratch, but the key message here is: Untested software can not be considered as stable. If you do not test, your users test and consider found bugs as instabilities.

Level 2

Automatic regression test
Regression tests should be automated and executed by your CICD pipeline. For E2E-regression tests focus first on the critical Use-Cases of your application.

Level 3

Empty level in this category.

Level 4

Retry
In case of unexpected error while calling a 3rd party, your system should do a retry. Retry logic must not flood other systems, so proper backoff settings must be in place. A retry should only be added, if it makes sense in the context of this Use-Case.

Stable IO design

In case your application has access to files or other data stream, proper handling must be implemented.

Level 5

Empty level in this category.

Category: Operations

Level 1

Deployment process
In case your application is productive, and your team is operating it (DevOps-team), you must have a ticket-based and well-defined deployment-/change-process.

Deployment verification
In case your team changes productive systems, you must be able to test or verify the success of your change.

More about stable deployments

Level 2

Alerting: Logs
Monitoring must cover critical log entries. Trigger an alert, if unknown errors or well-known critical entries are logged, which require operations involvement.

Alerting: Application health
Monitoring must cover the health status endpoint of your application. Trigger an alert, if the health status is negative. Your application requires an API endpoint, which returns its health status. The health status shows, that you application is up and running. The health status might also report insights of your application like connection status against database or 3rd party APIs.

Level 3

Alerting: Resources
Monitoring must cover CPU-, memory- and storage-consumption. Trigger an alert, if consumption is on a critical level.

Alerting: Certificates
Monitoring must cover expiry date of (SSL) certificates. Trigger an alert before the certificate expires and renew it in time.

Canary Deployment
You should use canary deployments as a progressive rollout of your application. The canary deployment splits traffic between an already-deployed version and a new version. The new version is rolled out to a subset of users before it is fully rolled out to all users. This way problems in new version have limited impact due to traffic split and rollback to already-deployed version is quick and easy.

Operations manual
In case your application is in production and your team is operating it (DevOps-team), you must have an operations manual. This manual describes operation processes (like changes, deployments, database update & backup, etc.) and the incident handling process. It lists also the stakeholders to be contacted in case of incidents or other issues.

Level 4

Alerting: Timeouts
Monitoring must cover number of timeouts. Trigger an alert, if too many timeouts happened in a defined time range.

Alerting: Latency (incoming)
Monitoring should cover latency for incoming requests to your application. Trigger an alert, if your application takes too much time to handle incoming requests.

Alerting: Latency (outgoing)
Monitoring should cover latency for outgoing requests from your application. An alert could be triggered, if outgoing requests take too much time to be answered by other systems - in that case the problem-solving might not be in your team.

Level 5

Alerting: Load
Monitoring must cover current load. Trigger an alert, if current load is higher than expected load in a defined time range.

How to use the IT Stability Health Radar?

If you work on an existing IT system and you want to improve its stability, you should check first at which level you are currently. Start with level 1 non-functional requirements in each category and check, if your systems fulfils these requirements. If not I recommend to start with these requirements. If you fulfil all requirements in one level, check the next level.

In case you start to develop a new system, you should check which stability level is required. For a prototype or a small MVP, you might not need much. But it is always a good idea to do things in the right way from the beginning, so keep the requirements and level in mind, when you start development.

Software-Entwicklung mit KI-Hilfe von ChatGPT

noreply@blogger.com (Elmar Brauch - Microservice Master) — Wed, 10 Jan 2024 21:44:00 +0000

Wie hilft uns KI beim Programmieren? Als erfahrener Software Entwickler zeige ich euch, in welchen Situationen mir ChatGPT beim Entwickeln besonders hilft.

Die Trainingsdaten der KI enthalten viele Programmiersprachen und Technologien. Außerdem kennt sie viele Algorithmen, Tutorials, Opensource Codes, Probleme und deren Lösungen. Dein Arbeits-Kontext, der komplette Sourcecode dazu und euer Problem bzw. dessen echte Root-Cause sind der KI allerdings unbekannt. Die KI bzw. ChatGPT hilft euch also nur so gut, wie ihr euer Problem bzw. die Anforderung mit passendem Kontext klar beschreibt.

Mein generelles Vorgehen dazu ist Teile und Herrsche. Ich zerlege meine User Story bzw. meine Aufgabe in kleinere Teile. Kleinere Teilprobleme oder Teilanforderungen lassen sich leichter und genauer beschreiben, so dass die KI bzw. ChatGPT mich besser unterstützen kann.

Um euch das zu verdeutlichen, zeige ich im Folgenden Beispiele aus meinem Entwickler-Alltag. In diesen Beispielen habe ich Teil-Probleme oder einzelne Anforderungen an ChatGPT geschickt. Die Lösungen oder mindestens die Lösungsideen von ChatGPT arbeite ich dann in meinen Code ein. Das Generieren ganzer Programme mit ChatGPT ist bei meinen typischen Enterprise-Anforderungen nicht praktikabel.

Den Artikel-Inhalt und mehr zu Programmieren mit KI gibt es von mir bei Udemy als Online-Training.

Java Probleme

Programmieraufgaben

Wie schon in meinen Video ChatGPT vs. Codewars gezeigt, kann die KI Programmieraufgaben lösen. Das können wir ausnutzen, indem wir Logiken von ihr programmieren lassen, deren Lösung uns nicht direkt einfällt.

Dieses Probleme können alle EntwicklerInnen selbst lösen, aber evtl. nicht ganz so schnell wie ChatGPT. Junior EntwicklerInnen könnten hier vom Kennenlernen der substring-Methode zusätzlich profitieren.

Typ-Konvertierung

Typ-Konvertierungen sind ein weiteres konkretes Problem, welches eine KI leicht lösen kann. Hier benötigte ich innerhalb eines Mappers eine Konvertierung von LocalDate nach OffsetDateTime. Da diese Konvertierungen häufig eleganter als per Konstruktor-Aufruf funktionieren, habe ich ChatGPT um eine Lösung gebeten:

Unbekannte Technologie verwenden

Am meisten profitiere ich von KI, wenn ich eine mir unbekannte Technologie einsetze. Meine Aufgabe war eine CSV-Datei als Datenquelle einzulesen und eine REST-API zum Abfragen dieser Daten zu bauen. Da ich mich mit REST-APIs sehr gut auskenne, benötige ich für diesen Teil keine KI-Hilfe. Allerdings hatte ich zuvor noch nicht eine CSV-Datei mit der Bibliothek jackson-dataformat-csv eingelesen. Früher hätte ich nach passenden Beispielen mit Google gesucht, heute stelle ich die Frage ChatGPT:

Das erste Ergebnis fügte sich nicht gut in meinen eigenen Code ein, daher eine 2. Anfrage zum direkten Schreiben in eine Map. Generell könnt ihr ChatGPT sagen, dass es keine Kommentare in den Code schreiben soll oder wie die Methoden-Signatur aussehen muss. Das vereinfacht das Kopieren des Codes.

Debugging

Wenn der von ChatGPT produzierte Code Compile-Fehler oder Laufzeit-Fehler verursacht, schickt diese Information im selben Chat als Antwort zurück. ChatGPT schafft es manchmal diese Probleme zu lösen. Das nächste Beispiel ist allerdings eine Bad Practice:

Hier ist meine Fehlerbeschreibung zu ungenau. Ich hatte keinen richtigen Kontext an die KI übergeben. Dadurch nimmt die KI an, dass es einen API Change gab. Tatsächlich hatte ich nur die Version des API Generators erhöht. Die unveränderte API Spezifikation war allerdings nicht mehr kompatibel zur neuen Version 6.4.0 des OpenAPI Code Generators. Dieses Beispiel zeigt, dass die Antwort nur so gut bzw. schlecht ist, wie das Problem beschrieben ist.

Spring Probleme

Neben der Programmiersprache Java kennt ChatGPT auch verbreitete Frameworks wie Spring. Probleme mit Spring könnt ihr also an die KI übergeben.

Spring Properties

Spring EntwicklerInnen kennen die application.properties oder application.yml Datei. Wir speichern dort einfache Konfiguration im Key-Value Format. Gelegentlich besteht unsere Konfiguration aber auch aus einer Liste von Werten. Das zugehörige Format ist uns eventuell unbekannt, aber nicht der KI:

Die erste Antwort passte nicht zum Stil des Projektes. Daher die 2. Frage nach einer Lösung mit der @Value Annotation. Das Aufsplitten des konfigurierten Wertes per split in der Annotation ist ein gutes Beispiel für seltene Notationsstile, die wir meistens nicht auswendig kennen.

JSON Serialisierung

Im nächsten Beispiel geht es um die Serialisierung von Objekten in JSON. Konkret sollen Attribute mit dem Wert null nicht in die JSON-Struktur geschrieben werden. Dazu muss der von Jackson verwendet ObjectMapper entsprechend konfiguriert werden - ein kompliziertes Spezial-Wissen, genau richtig für eine KI:

Problem bei neusten Technologien oder Versionen

Neue Technologien oder neuste Versionen können der KI unbekannt sein. Weil die Trainingsdaten älter als die Technologie sind, kann die KI uns hier nicht helfen. Im folgenden Beispiel eine Frage zur Konfiguration eines Plugins, um es mit der neuen Spring Boot Version zu verwenden. Spring Boot 3 vom November 2022 ist in den Trainingsdaten von September 2021 unbekannt. Das Angeben der Version in meiner Frage sorgte dafür, dass mich ChatGPT nicht mit alten Informationen in eine falsche Richtung schickt.

Test & Maven Probleme

Die Trainingsdaten der KI umfassen sehr viele Technologien. So hilft ChatGPT auch bei Fragen zum Mockito Test-Framework und zum Maven-Build.

Mockito Mock

Einen Mock, der einfach einen Eingabeparameter zurück gibt, benötige ich gelegentlich in meinen Tests. Leider kann ich mir die konkrete Lösung nie merken - ich weiß aber, dass die Google-Suche nach diesem Problem aufwändig ist...

Maven paralleler Build

Habt ihr ein großes Projekt mit vielen Maven-Modulen? Dann beschleunigt den Build durch paralleles Bauen. ChatGPT empfiehlt diese Tuning Maßnahme, wenn ihr nach einem schnelleren Maven-Build fragt. Im folgenden Frage ich, wie es konkret funktioniert und bekomme eine hilfreiche Antwort.

Linux Probleme

Datei-Suche mit grep

Die Linux Shell ist ein mächtiges Werkzeug, dessen Bedienung schwierig zu lernen ist. Müsst ihr beispielsweise eine große Menge von Dateien nach bestimmten Inhalten durchsuchen, hilft die Shell, wenn Ihr das richtige Kommando kennt. Ist euch das Kommando unbekannt, löst die KI das Linux Problem, da sie scheinbar alle Kommandos kennt und ihr das Problem konkret beschreiben könnt.

Netzwerk-Tests mit curl

Zum Analysieren von Netzwerkverbindungen verwende ich die Linux Shell. Kennt Ihr dazu den Befehl curl? Mit welchem Parameter sendet Ihr ein http PATCH statt dem standardmäßigen GET? Und wie setzt man den Proxy für das Firmennetzwerk? Auch für dieses Problem, findet die KI schnell eine Antwort.

Fazit

Programmieren mit KI-Unterstützung macht die Entwicklung schneller. Ich selbst habe in letzter Zeit weniger mit Google beim Programmieren gesucht. Stattdessen setze ich mehr auf KI bzw. ChatGPT. Die Antwortzeiten und Stabilität von ChatGPT sind leider nicht immer gut. Das kostenpflichtige ChtatGPT Plus sollte zuverlässiger sein. Die Alternativen GitHub Copilot oder Bing Chat muss ich noch evaluieren.

Ich schließe mit einem Zitat von Albert Einstein. Dieses passt zu meiner Feststellung, dass die KI nur dann helfen kann, wenn wir Problem und Kontext gut beschrieben haben:

„Wenn ich eine Stunde habe, um ein Problem zu lösen, dann beschäftige ich mich 55 Minuten mit dem Problem und 5 Minuten mit der Lösung.“

Java 21: Die wichtigsten Features seit Version 17

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sat, 02 Dec 2023 22:26:00 +0000

Java 21, die neue Version mit verlängertem Support, ist da! Hier stelle ich die wichtigsten Features vor:

Interface SequencedCollection,
Record Patterns,
Neuerungen bei switch und
das Highlight virtuelle Threads

Falls Ihr noch Java 11 verwendet, schaut euch hier die Features von Java 17 an: java-17-features.html

🎓 Auf Udemy findet ihr meinen kostenloses Online-Kurs zu Java 21.

Java 21 at YouTube in English

Interface SequencedCollection

Die neuen Sequenced-Interfaces erweitern Listen-Implementierungen um den Direktzugriff auf das erste und letzte Element. Am Beispiel einer ArrayList zeige ich hier die neuen, selbsterklärenden Methoden:

// Mutable list created.
List<String> list = new ArrayList<>(List.of("1st", "2nd", "3rd"));

log.info("Read first & last element in list: %s & %s"
        .formatted(list.getFirst(), list.getLast()));

var reversedList = list.reversed();
reversedList.addFirst("4th");
log.info("Reversed order with new first element: " + reversedList);
log.info("Changed list: " + list);

list.removeFirst();
list.removeLast();
list.addFirst("begin");
list.addLast("end");
log.info("Changed list: " + list);

Log-Ausgabe zum Code:

INFO: Read first & last element in list: 1st & 3rd
INFO: Reversed order with new first element: [4th, 3rd, 2nd, 1st]
INFO: Changed list: [1st, 2nd, 3rd, 4th]
INFO: Changed list: [begin, 2nd, 3rd, end]

Die eingesetzten Methoden kommen mit dem Interface SequencedCollection. Seit Java 21 gibt es analoge Interfaces als Spezialisierung von Map und Set, schaut euch dazu den JEP 431 an.

Trotz der komfortablen Methoden der SequencedCollection kann es in folgenden Fällen zu RuntimeExceptions kommen:

NoSuchElementException - wenn die Liste leer ist und ihr das erste oder letzte Element lesen oder entfernen wollt.
UnsupportedOperationException - wenn die Liste unveränderlich ist und ihr das erste oder letzte Element entfernen oder hinzufügen wollt. Eine unveränderliche Liste wird z. B. so erzeugt List.of("test"). Im Code-Beispiel erzeuge ich daher eine veränderliche ArrayList.
NullPointerException - wenn die Listenimplementierung das Hinzufügen von null nicht erlaubt.

Auch aus Clean Code Sicht ein tolle Erweiterung, da die neuen teils Parameter-losen Methoden leicht verständlich sind. Sie vermeiden auch Bugs bzgl. falscher Indexierung beim Zugriff auf das letzte Element einer Liste: list.size() vs. (list.size() - 1).

Pattern Matching bei switch

Mit Java 21 ist das Pattern Matching in switch Blöcken fester Bestandteil der Sprache, siehe dazu JEP 441. Pattern Matching in switch funktioniert analog zum Pattern Matching nach instanceof. Das case Label definiert mehr als eine einfache Konstante. Es kann sowohl Casten als auch Boolean-Ausdrücke auswerten. Die Auswertung eines Boolean-Ausdrucks im case benötigt zusätzlich das neue Keyword when . null als case Label ist jetzt möglich und macht null-Checks vor dem switch überflüssig. Hier ist ein Beispiel mit allen genannten Features:

BaseStream stream = DoubleStream.of(1.1);
switch (stream) {
    case null -> log.info("null is now a possible case.");
    case IntStream is when is.isParallel() ->
            log.info("Expression in case.");
    case DoubleStream ds -> log.info("Casted in case.");
    default -> throw new IllegalStateException();
}

Record Patterns

Pattern Matching ist auch mit Records möglich. Das wurde mit JEP 440 in Java 21 eingeführt. Mehr zu Records findet ihr hier. Das Besondere am Record Patterns ist der direkte Zugriff auf die Record-Attribute beim Casten (siehe instanceof und case unten). Im folgenden Code Beispiel gibt es 2 verschiedene Records. Beim Pair-Record caste ich im if und switch Statement jeweils auf die beiden Attribute und verkürze ihren Namen dabei auf k und v.

record Pair(String key, Integer value){}
record Single(Double element){}

private static void recordPatterns() {
    var mixedList = List.of(
            new Single(1.1), 
            new Pair("2nd", 2));

    for (Object entry : mixedList) {
        if (entry instanceof Pair(String k, Integer v))
            log.info("Record has: %s %d".formatted(k, v));
        switch (entry) {
            case Single s -> log.info("Record: " + s);
            case Pair(String k, Integer v) -> log.finest("...");
            default -> throw new IllegalStateException();
        }
    }
}

Log-Ausgabe zum Code:

INFO: Record: Single[element=1.1]

INFO: Record has: 2nd 2

Virtuelle Threads

Endlich - virtuelle Threads sind fester Bestandteil von Java! JEP 444 integriert die leichtgewichtigen Threads in die Java Plattform. Praktischer Weise unterscheidet sich das Erstellen virtueller Threads kaum vom Erstellen klassischer Threads:

try (var executorService = Executors.newVirtualThreadPerTaskExecutor()) {
    executorService.submit(() -> {
        var virtualThread = Thread.currentThread();
        log.info(virtualThread.threadId() + " : "
                + virtualThread.isVirtual());
    });
} catch (ExecutionException | InterruptedException e) {
    throw new RuntimeException(e);
}

Die Log-Ausgabe zum Code sieht so aus:
INFO: 22 : true
Mit der neuen Methode isVirtual überprüfen wir, ob wirklich ein virtueller Thread erzeugt wurde. Der hier gezeigt Thread loggt nur seine eigene ID und ob er virtuell ist.
Zum Erzeugen neuer Threads wird ein ExecutorService mit Executors.newVirtualThreadPerTaskExecutor instanziiert. Dieser Service erzeugt neue virtuelle Threads mit der Methode submit. Somit können virtuelle Threads analog zu klassischen Thread erzeugt werden - am ExecutorService Interface hat sich nichts geändert.
Das hier verwendete try-with bedient das AutoCloseable Interface, um den ExecuterService automatisch zu schließen.

Virtual Threads at YouTube in English

Server Anwendungen profitieren von dem nun möglichen Thread-pro-Request Stil. So kann beispielsweise eine mit dem Spring Framework gebaute API, für jeden Request einen eigenen virtuellen Thread erzeugen. Das ermöglicht eine nahezu optimale Hardware-Ausnutzung, wie wir es bisher nur von reaktiven Anwendungen kannten.

Fazit

2 Jahre nach Java 17 gibt es ein neues LTS (Long Term Support) Release. Dieses erweitert die Sprache Java um wenige, aber gute Sprach-Features. Virtuelle Threads sind für mich das Highlight. Sie helfen unter der Last vieler, parallel eingehender Requests eine bessere Hardware-Nutzung zu erreichen - das spart Geld und Strom!

CronJobs mit Spring

noreply@blogger.com (Elmar Brauch - Microservice Master) — Fri, 03 Nov 2023 16:44:00 +0000

Mit Spring können zeitgesteuerte Aufgaben in Java Code integriert werden. CronJobs wie wir sie in Linux kennen, definieren wir mit Spring einfach per Annotation. In diesem Artikel zeige ich wie das geht und wie Spring die CronJobs entsprechend unserer Definition ausführt.

Was ist ein CronJob?

Unter CronJob verstehen wir die zeitlich gesteuerte Ausführung eines Kommandos zur Erledigung einer Aufgabe bzw. eines Jobs. Das Kommando wird durch einen bestimmten Zeitpunkt oder eine zeitliche Bedingung angestoßen.

Typische Beispiele für durch CronJobs gestartete Aufgaben sind:

Regelmäßiges Aufräumen der Datenbank - z. B. um veraltete Daten zu löschen oder DSGVO konform persönliche Daten nach einer definierten Zeit zu löschen.
Wöchentlicher Versand von Newslettern oder Werbung per Email
Nächtliche Datenbank-Backups
Monatliches Erstellen von Rechnungen (z.B. Telefon-Rechnung)

Das Betriebssystem Linux bietet crontab zum Erstellen von CronJobs an. Mit crontab könnten wir eine Spring Anwendung starten, die täglich neue Angebots-Daten veröffentlicht. Spring bietet uns Spring die Möglichkeit, das ganze ohne Linux und crontab zu tun. Eine ausführliche Erklärung zu CronJobs und ihre Verwendung mit Linux findet ihr hier:

https://www.ionos.de/digitalguide/hosting/hosting-technik/cronjob/

Englisches Video zum Artikel

CronJobs mit Spring

Das Spring Framework bietet Entwickler eine Scheduling-Funktionalität zum Erstellen von CronJobs. Scheduling ist Teil der Spring Kern-Funktionalitäten, daher werden keine weiteren Build-Dependencies bzw. Bibliotheken benötigt. Einen einzelnen CronJob legen wir einfach in einer einzigen Klasse an und konfigurieren per Annotation:

@EnableScheduling
@Configuration
public class ScheduledJobs {
   Logger log = Logger.getLogger("ScheduledJobs");

   @Scheduled(cron = "1 * * * * *")
   private void logEvery1stSecond() {
       log.log(Level.INFO,
           "CronJob executed every 1st second" +
           "of any minute at any day");
   }
}

@EnableScheduling aktiviert die Spring Scheduling Fähigkeit für die komplette Spring Anwendung. Sie sollte zusammen mit der @Configuration Annotation gesetzt werden. Sie muss nicht zusammen mit den CronJob-Methoden in derselben Klasse sein.
@Scheduled markiert eine Methode, so dass sie vom Spring Scheduler entsprechend ihrer Konfiguration ausgeführt wird. Hier verwende ich eine einfache CronJob-Konfiguration, welche die Methode in der ersten Sekunden jeder beliebigen Minute ausführt.
cron = "1 * * * * *" definiert durch die Sterne (*), dass Minute, Stunde, Tag, Monat und Wochentag beliebig sind.

Das cron-Attribut

Das cron-Attribute der Scheduled Annotation ist ähnlich dem Linux crontab aufgebaut. In Spring hat es 6 Leerzeichen-separierte Werte und somit dieses Format:
<Sekunde> <Minute> <Stunde> <Tag des Monats> <Monat> <Tag der Woche>
Weitere Beispiele für das cron-Attribut:

@Scheduled(cron = "1-10 */2 * * * Mon-Fri")

1-10 legt fest, dass die annotierte Methode in den Sekunden 1 bis 10 aufgerufen wird. Das Minuszeichen definiert eine Spanne und legt hier fest, dass die Methode nur an den Werktagen Montag bis Freitag in einer Woche ausgeführt wird.
*/2 legt fest, dass der CronJob nur jede 2. Minute ausgeführt wird. Würde man statt dem Stern eine Zahl festlegen, z.B. 5/2 so würde der Job ab der 5. Minute jede 2 Minute ausgeführt.

@Scheduled(cron = "0 0 0 25 12 ?", zone = "Europe/Berlin")

Dieser CronJob wird einmal im Jahr am ersten Weihnachtstag, dem 25.12. um 0:00 Uhr ausgeführt.
Mit dem zone Attribut kann man noch die Zeitzone festlegen, also hier die deutsche Zeitzone.
Der Wochentag kann durch ein Fragezeichen als irrelevant markiert werden.

@Scheduled(cron = "11,22,33,44,55 * * * * *")

Die Komma-separierte Liste definiert in welchen Sekunden dieser CronJob ausgeführt wird.

@Scheduled(cron = "1-10,15,30,45 * * * * ?")

Kombinationen sind auch möglich.

Relative Abstände zwischen CronJobs

Statt mit genauen Zeitangaben (cron-Attribut) können mit @Schedule annotierte Methoden auch mit relativen Zeitspannen zwischen den einzelnen Ausführungen gestartet werden:

@Autowired IdGenerator idGenerator;

@Scheduled(fixedDelay = 1000, initialDelay = 5000)

private void startJobAfterCompletionOfPreviousSchedule() {

String jobId = idGenerator.generateId();

log.log(Level.INFO, "Job completed: " + jobId));

}

Wenn CronJobs mit Spring definiert und ausgeführt werden, können sie auf den Spring IoC Container und somit alle Beans zugreifen. Hier wurde eine IdGenerator Bean mit @Autowired injiziert. Weitere Infos zu Beans und Dependency Injektion findet ihr hier: kernkonzepte-von-spring.html
initialDelay legt fest wie viele Millisekunden nach Start der Spring Anwendung der CronJob zum ersten Mal startet.
fixedDelay definiert wie viele Millisekunden gewartet wird, bevor der CronJob erneut nach Ende der vorherigen CronJobs-Ausführung startet. Im Code-Beispiel oben ist zwischen den Ausführungen des CronJobs immer 1 Sekunde bzw. 1000 Millisekunden Pause.
fixedRate zeige ich im Zusammenhang mit asynchroner Ausführung von CronJobs. Das Attribut fixedRate legt fest wie viele Millisekunden Abstand zwischen dem Start zweier CronJobs ist.

Asynchrone Ausführung von CronJobs

@Scheduled annotierte Methoden werden grundsätzlich im scheduling-Thread ausgeführt. In meinem Beispiel-Code verwende ich immer eine Logger-Instanz, da diese den Namen des Threads loggt. Das verdeutlicht den Unterschied zu asynchron ausgeführten CronJobs. Startet unsere Anwendung viele zeitlich überlappende CronJobs, kann es besser bzw. performanter sein die CronJobs asynchron auszuführen. Ohne zeitliche Überlappung ist die asynchrone Ausführung der CronJobs nicht notwendig, da jede CronJob-Ausführung im scheduling-Thread unabhängig vom main-Thread und der restlichen Anwendung stattfindet.

@EnableAsync

@EnableScheduling

@Configuration

public class AsyncScheduledJobs {

Logger log = Logger.getLogger("AsyncScheduledJobs");

@Scheduled(cron = "${scheduled.special_seconds}")

@Async

void logAtSpecialSeconds() {

log.log(Level.INFO, "Job async executed");

}

@Scheduled(fixedRateString = "${scheduled.fixed-rate}",
initialDelayString = "${scheduled.initial-delay}")

@Async

void startJobOften() {

log.log(Level.INFO, "Job async executed");

}

Um CronJobs asynchron durch den Spring Scheduler auszuführen, muss zur @EnableScheduling Annotation auch die @EnableAsync in einer Konfiguration-Klasse gesetzt werden.
Jede @Scheduled annotierte Methode, die asynchron zu anderen CronJobs ausgeführt werden soll, benötigt die @Async Annotation. Danach startet sie der Spring Scheduler in einem separaten Thread.
Die String-Attribute (inklusive cron-Attribut) der @Scheduled Annotation, können aus den Spring Properties Dateien gelesen werden. Dazu schreibt man den Properties-Schlüssel in ${...}. Spring geht alle Property Definitionen durch, um den Wert passend zum Schlüssel zu finden. Meine application.properties Datei zu diesem Beispiel sieht so aus:

scheduled.special_seconds=11,22,33,44,55 * * * * ?

scheduled.fixed-rate=2500

scheduled.initial-delay=4000

Anmerkung: Definiert ihr mehrere CronJobs mit zeitlicher Überlappung, starten einige Ausführungen möglicherweise nicht, weil der scheduling-Thread gerade ausgelastet ist. Die asynchrone Ausführung kann dies verhindern. Startet meinen JUnit-Test ScheduledJobsTest um zu sehen, wie einige Ausführungen übersprungen werden. Die Ursache dessen ist, dass der scheduling-Thread durch die Methode startJobAfterCompletionOfPreviousSchedule phasenweise blockiert ist.

Fazit

Die Scheduling Fähigkeit von Spring ist sehr gut ins Spring Framework integriert und einfach zu benutzen. Falls ihr Linux CronJobs kennt, versteht ihr alles schnell.

In der Praxis verwende ich die Scheduling Fähigkeit von Spring, um alte Daten aus der Datenbank zu löschen. Dazu verwende ich einfach die vorhandene Beans, die JPA Entitäten und die Datenbank Connection innerhalb des CronJobs.

Den kompletten Code findet ihr in GitHub:
https://github.com/elmar-brauch/beans/tree/master/src/main/java/de/bsi/bean/schedule

Copilot Evaluierung bei der Telekom

noreply@blogger.com (Elmar Brauch - Microservice Master) — Wed, 13 Sep 2023 20:06:00 +0000

Hebt KI die Software-Entwicklung auf ein neues Level? Sind EntwicklerInnen mit KI Support schneller als ohne? Diesen Fragen stellen wir uns bei der Deutschen Telekom IT GmbH. Dazu führten mein Team und ich eine Evaluierung von GitHub Copilot durch. Ich stelle euch hier die Ergebnisse und Meinungen des Teams vor.

Warum Copilot?

Copilot integriert sich in die Entwicklungsumgebung der Programmierenden. Es analysiert den vorhandenen Sourcecode und macht mittels KI unterstützter Text-Completion Vorschläge für weiteren Code. Diesen können die ProgrammiererInnen per Tastendruck übernehmen. Das beschleunigt insbesondere das Schreiben von sich wiederholendem Code.

Copilot in der Praxis

ChatGPT hilft EntwicklerInnen bei technischen Fragestellungen. Dazu unterbrechen wir das Schreiben von Code in der IDE, öffnen im Browser die Chat-KI und stellen unsere Frage oder Anforderung. Mit der Antwort von ChatGPT wechseln wir in die IDE und probieren sie aus. Im Unterschied zu ChatGPT unterstützt Copilot die Entwickelnden direkt beim Schreiben von Code in der IDE. Ich sehe die beiden KI Tools nicht als Konkurrenten sondern als Werkzeuge für unterschiedliche Zwecke. Mehr zu ChatGPT für EntwicklerInnen findet Ihr hier: chatgpt-coding.html

Ziel und Rahmen der Copilot Evaluierung

Vor der konzernweiten Einführung eines neuen, kostenpflichtigen Tool findet meist eine Evaluierung statt. Konkret war das Ziel im Evaluierungsteam herauszufinden, ob die tägliche Arbeit in der Software-Entwicklung beschleunigt wird und wenn ja, um wie viel.

Ich selbst bin Software Entwickler und Architekt im Scrum-Team Asteroid. Das Asteroid Team baut Microservices und Self-Contained Systems als Teil des Geschäftskunden-Portal der Deutschen Telekom. Im Sinne von DevOps ist unser Team sowohl für die Entwicklung als auch für den Betrieb unserer Systeme verantwortlich. Den Schwerpunkt unser täglichen Arbeit bildet aber die Entwicklung. Unser Technologie-Stack besteht im wesentlichen aus Java, Spring und Vue.js. Als Entwicklungsumgebung verwenden wir größtenteils IntelliJ.

Durchführung der Evaluierung

Als Scrum-Team schätzen wir den Aufwand jeder UserStory bevor wir sie bearbeiten. Vor der Evaluierung hatte unser Team bereits 25 zweiwöchige Sprints abgeschlossen.
Zu jedem Sprint erfassten wir folgende Daten:

Entwicklungskapazität: Wie viele Story Points kann das Team wahrscheinlich im kommenden Sprint abschließen.
Burndown-Charts: Wie viele Story Points hat das Team im vergangenen Sprint tatsächlich abgeschlossen.
Anzahl der Software-EntwicklerInnen im jeweiligen Sprint. Die Größe unseres Teams hatte sich in den 25 Sprints verändert, z. B. durch Fluktuation, Neueinstellungen, Urlaube oder Schulungen.

Zu Beginn des 26. Sprints erhielten alle EntwicklerInnen die Copilot-Lizenz und installierten das Plugin innerhalb eines Tages in ihrer IDE. Da wir eine 30-tägige Evaluierungs-Lizenz hatten, konnten wir Copilot in 2 kompletten Sprints verwenden.

8 von 9 EntwicklerInnen machten in unserem Team bei der Copilot Evaluierung mit. 1 Entwickler entschied sich dagegen, da er Copilot bzw. GitHub hinsichtlich der Daten-Sicherheit misstraute.

Ergebnisse durch Scrum-Metriken

Unser ScrumMaster lieferte die folgenden Mess-Ergebnisse:

Im ersten Sprint mit Copilot erreichten wir 38 Story Points.
Im zweiten Spint mit Copilot erreichten wir 28 Story Points.
Der Durchschnittswert an Story Points in den 25 vorherigen Sprints ist 23.
Beide Copilot Sprints waren also überdurchschnittlich erfolgreich.
Die Top 5 Sprints vor Copilot hatten als Ergebnis 48, 40, 37, 34 und 33 Story Points.
Der erste Copilot Sprint war also unser drittbester Sprint von insgesamt 27 Sprints.

Aus Evaluierungssicht hatten wir Seiteneffekte in beiden Sprints, so dass die zuvor genannten Ergebnisse leider relativiert werden müssen:

Verglichen mit den vorherigen Sprints hatte das Asteroid Team mehr Entwickelnde in der Evaluierungs-Phase als zuvor. Mit den vorhandenen Daten könnten wir die Story Points jedes Sprints ins Verhältnis zur Anzahl der Entwickelnden setzen. Da neue EntwicklerInnen aber Einarbeitungszeit benötigen, lässt sich dieser Seiteneffekt trotzdem nicht ganz eliminieren.
Ein weiteres Rauschen war die Bearbeitung von Bugs und anderen operativen Tasks. Den Aufwand dafür messen wir nicht in Story Points. In den beiden Evaluierungs-Sprints hatten wir relative wenige Bugs, während wir in den vorherigen Sprint durch einen großen Go-Live relativ viel ungeplante Arbeit hatten.

Interviews mit Software-EntwicklerInnen zu Copilot

Um den Wert von Copilot besser einzuschätzen, habe ich neben den Messungen Interviews mit allen Team-KollegInnen durchgeführt. Als erstes haben wir die Interviews vom Hersteller selbst überprüft. GitHub selbst erstellte die Umfrageergebnisse im folgenden Bild links. Auf der rechten Seite beantworten die Entwickelnden im Asteroid Team die selben Fragen:

Vergleich GitHub Copilot "Werbung" mit Erfahrung in meinem Team

Zwischen der Umfrage des Herstellers und der Erfahrung in unserem Team gibt es signifikante Unterschiede. Allerdings bestätigt unsere Umfrage die Ergebnisse zu den wichtigen Fragen nach höherer Produktivität und Geschwindigkeit.

Da bei unserer Evaluierung die Frage nach dem Nutzen in der täglichen Arbeit eines Scrum-Teams im Fokus stand, habe ich noch 4 andere Fragen gestellt:

Using it? - Verwendest Du Copilot wirklich in der täglichen Arbeit?
Is helpful in your Daily Work? - Hilft Copilot Dir bei Deiner täglichen Arbeit in der Software-Entwicklung?
Makes Copilot you faster? - Macht Dich Copilot bei Deiner Arbeit insgesamt schneller? Hintergrund neben dem reinen Entwickeln verwenden wir auch viel Zeit für Tests, Betriebsaufgaben (DevOps-Team), Scrum-Rituale etc. Das eigentliche Programmieren bei dem uns Copilot unterstützt ist nur ein Teil unserer täglichen Arbeit.
What impact do you expect in future? - Welchen Effekt auf Deine Arbeit erwartest Du durch Copilot in der Zukunft?

Interview zu Copilot

Zusammenfassung der Antworten:

Alle TeilnehmerInnen verwendeten Copilot in der täglichen Arbeit während der Evaluierung.
Für fast alle war Copilot hilfreich. Insbesondere bei ähnlichem Code oder sich wiederholendem Code wurde die Nützlichkeit festgestellt.
Einige berichten, dass Copilot bei komplexen Aufgaben scheiterte.
Fast alle waren durch Copilot zumindest ein wenig schneller.
Die meisten erwarten in Zukunft einen noch größeren Effekt auf die tägliche Arbeit durch Copilot.

Fazit und Ausblick

Copilot erzielt ein gutes Evaluierungsergebnis. Wir empfehlen die Verwendung von Copilot.

GitHub Copilot kostet im September 2023 19$ pro Benutzer pro Monat. Basierend auf den Evaluierungsergebnissen nehme ich an, dass die meisten EntwicklerInnen durch Copilot mindestens 1 Stunde pro Monat schneller sind. Die Stundensätze von Developern liegen in den meisten Länder deutlich über 19$, daher sehe ich hier eine positive Kosten-Nutzen-Rechnung.

In naher Zukunft erwarte ich weitere Features in Copilot, welche die Entwicklung beschleunigen und die Qualität verbessern, siehe GitHub Labs. Daher empfehle ich jedem zumindest das Ausprobieren von GitHub Copilot.

Model-View-Controller mit Spring und Thymeleaf

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sat, 09 Sep 2023 11:11:00 +0000

Thymeleaf ist eine moderne Template Engine, um Server-seitig html zu generieren. Hier zeige ich, wie es in einem Spring MVC Projekt eingesetzt wird. Dabei demonstriere ich verschiedene Thymeleaf Ausdrücke (if, loop, usw.), Lesen des Modells und Nutzung von CSS oder JavaScript.

Model-View-Controller mit Spring und Thymeleaf

Betrachten wir das bekannte Design Pattern MVC (siehe auch rest-json-apis-in-java-leicht-gemacht), dann können wir die einzelnen Bestandteile mit dem hier vorgestellten Technologie-Stack implementieren:

Das Modell (Model) wird mit einfachen Java Objekten realisiert (POJO).
Die Ansicht (View) wird mittels Thymeleaf in html, css und JavaScript implementiert.
Der Controller wird als Spring Bean vom Typ @Controller umgesetzt.

Thymeleaf (https://www.thymeleaf.org/) ist eine Template Engine deren Templates in html geschrieben werden. Dynamische Stellen im html werden dann durch Thymeleaf Ausdrücke definiert. Z.B. blenden wir mit folgendem if-Ausdruck eine Nachricht (bzw. das ganze <p>-Tag) ein oder aus:

<p th:if="${#lists.isEmpty(items)}">Die Liste ist leer.</p>

itmes ist eine Liste von Item Objekten im Modell, das vom Controller an die Thymeleaf View übergeben wurde. th: ist der XML Namensraum (Namespace) von Thymeleaf, der weiter oben im selben Dokument definiert sein muss.

Variable Ausdrücke, die Thymeleaf zur html Generierung auswertet, werden unter anderem mit ${...} markiert. #lists ist ein von Thymeleaf bereitgestelltes Hilfs-Objekt für Listen-Operationen, wir nutzen hier die isEmpty Methode, um das <p>-Tag nur dann einzublenden, wenn die Liste items leer ist.

YouTube Video zum Artikel

Thymeleaf ins Java Projekt integrieren

Thymeleaf befindet sich als Java-Bibliothek im Maven Repository und kann somit als Dependency in jedes Maven oder Gradle Projekt geladen werden. Ein bestehendes Spring Boot Projekt (siehe microservices-mit-spring-boot-erstellen) kann durch Hinzufügen der von Spring Boot gemanagten Thymeleaf Dependency ergänzt werden:

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>

</dependency>

Spring Controller

Der Controller für die Thymeleaf View wird in Spring analog zu einem RestController erstellt (siehe auch rest-json-apis-in-java-leicht-gemacht). Der wesentliche Unterschied ist, dass wir in jeder Controller-Methode, die nächste anzuzeigende View festlegen müssen.

Unsere Demo Web-Anwendung soll die folgenden UseCases umsetzen:

Liste mit allen erstellten Dingen (Items) anzeigen.
Neues Ding erstellen und der Liste hinzufügen.

Der Spring MVC Controller für diese Anwendung sieht so aus:

import org.springframework.stereotype.Controller;

import org.springframework.ui.Model;

import org.springframework.web.bind.annotation.GetMapping;

import org.springframework.web.bind.annotation.PostMapping;

import org.springframework.web.bind.annotation.RequestParam;

import org.springframework.web.servlet.ModelAndView;

@Controller

public class ItemController {

private List<Item> items = new ArrayList<>();

private static final String MODEL_KEY_ITEMS = "items";

private static final String VIEW_NAME_LIST = "item-list";

private static final String VIEW_NAME_CREATE = "item-create";

@GetMapping(path = {"/", "/item"})

public ModelAndView showItems(ModelAndView mav) {

mav.setViewName(VIEW_NAME_LIST);

mav.addObject(MODEL_KEY_ITEMS, items);

return mav;

}

@GetMapping("/item-create")

public String showCreateItem() {

return VIEW_NAME_CREATE;

}

@PostMapping("/item")

public String createNewItem(Model model,

@RequestParam String itemname,

@RequestParam String itemid) {

var item = new Item();

item.setName(itemname);

item.setId(itemid);

items.add(item);

model.addAttribute(MODEL_KEY_ITEMS, items);

return VIEW_NAME_LIST;

}

Den klassischen MVC Controller annotieren wir in Spring mit @Controller. Dadurch wird der ItemContoller als Bean im Spring IoC Container bekannt. Eingehende Requests werden vom Dispatcher Servlet entsprechend dem registrierten Handler Mapping an den richtigen Controller geschickt.
@GetMapping und @PostMapping kennen wir schon aus diesem Artikel rest-json-apis-in-java-leicht-gemacht. Das Spring Handler Mapping basiert auf den hier konfigurierten Pfaden, so dass eingehendet Request entsprechend ihres Typs und URL-Pfades an die jeweilige Methode des Controllers geschickt werden.
Die Methode showItems bearbeitet hier eingehende GET Requests für 2 verschiedene Pfade - generell können beliebig viele Pfade bzw. eine Liste von Pfaden auf eine Methode gemappt werden.
@RequestParam mappt die Daten innerhalb des POST Formulars auf den annotierten Parameter in der Methode createNewItem. Das Formular stelle ich in einem zweiten Artikel zu Thymeleaf html Templates vor.
Model : Die Methode createNewItem hat den Parameter model, der automatisch eine Instanz des Model Interface bereitstellt. Diese Model Instanz kann dann mit den Daten des Modells befüllt werden und in der View ausgelesen werden (siehe Kapitel weiter unten). Model ist vergleichbar mit einer Map, daher kann eine Model Instanz auch mit der Methode asMap als Map Instanz verarbeitet werden.
ModelAndView : Die Methode showItems hat den Parameter mav vom Typ ModelAndView. Die ModelAndView Klasse ist ein Kombination aus dem Model und der anzuzeigenden View. Mit mav.addObject werden Objekte dem Modell innerhalb der Klasse ModelAndView hinzugefügt. Mit setView oder setViewName wird die anzuzeigende View definiert. Im Beispiel hier setze ich immer den String viewName, dessen Wert dem Namen der Thymeleaf html-Templates mit oder ohne Dateiendung ".html" entsprechen muss.
Wenn die Methode einfach nur einen String zurückgibt (siehe showCreateItem), versucht Spring eine passende View zu finden und diese anzuzeigen. Findet Spring keine View, kommt es zu einem "Internal Server Error".
Hier unterscheiden sich @RestController vom @Controller. Der RestController interpretiert den Sting als den Inhalt der Response und nicht als die nächste anzuzeigende View. Gibt man im RestController ein View Objekt zurück, so zeigt auch dieser die View an.
Ihr könnt das einfach testen, indem ihr in unserem Demo Projekt einfach mal die ItemController Annotation ändert.

POJO Modell Klasse

Die Modell Klassen sind einfache POJO (Plain Old Java Object) Klasse. Das Besondere daran ist, dass es keine Besonderheiten gibt. 😄

Daher zeige ich euch hier einfach kurz die Item Klasse bestehend aus Attributen, Getter-, Setter-Methoden und sonst nichts.

public class Item {

private String id, name;

public String getId() { return id; }

public void setId(String id) { this.id = id; }

public String getName() { return name; }

public void setName(String name) { this.name = name; }

}

Thymeleaf View

Nachdem wir in den vorherigen Kapiteln über den Controller und das Modell gelesen haben, kommen wir nun zur Ansicht (View), die mit Thymeleaf umgesetzt wird.

Controller und Modell könnten wir auch mit beliebigen anderen View Technologien kombinieren, wie zum Beispiel:

JSP - JavaServer Pages : https://www.oracle.com/java/technologies/jspt.html
Groovy Markup Templates : http://groovy-lang.org/templating.html#_the_markuptemplateengine
JSF - Java Server Faces : https://www.oracle.com/java/technologies/javaserverfaces.html

Es gibt noch viele mehr, hier möchte ich mich aber ausschließlich auf Thymeleaf konzentrieren.

HTML, CSS und JavaScript Dateien richtig ablegen

In unserem Spring Boot Thymeleaf Projekt gibt es Standard-Verzeichnisse für HTML-, CSS- und JavaScript-Dateien. Diese nutzen wir hier auch, um das Tutorial einfach zu halten.

Im src/main/resources Verzeichnis, wo sich auch die Spring application.properties Datei befindet, erstellen wir 2 Unterordner: static und templates.

templates ist der Standard Ordner für alle Thymeleaf Templates, die in Form von html Dateien gespeichert werden.
static wird für statische Dateien, wie JavaScript- und CSS-Dateien verwendet. Es empfiehlt sich mit weiteren Unterverzeichnissen eine Ordnung zu schaffen. Ich habe daher hier die beiden Unterverzeichnisse js für JavaScript-Dateien und css für Cascading Style Sheets angelegt.

Die JavaScript und CSS Dateien sind unabhängig von Thymeleaf und sehen mit anderen View-Technologien genau so aus. Daher gehe ich hier nicht weiter auf diese Dateien ein - ihr könnt sie aber gerne in meinen GitHub Projekt zusammen mit dem anderen Code genauer anschauen:
https://github.com/elmar-brauch/thymeleaf

Verzeichnis-Struktur Thymeleaf

Thymeleaf Templates

Normale html-Dateien könnten auch von Thymeleaf ausgespielt werden, so dass man die html-Dateien auch Schritt für Schritt in Thymeleaf Templates umwandeln kann. In meinem GitHub Projekt findet ihr Thymeleaf Templates, die mehr Funktionen nutzen. Hier im Blog Teil 1 möchte ich es aber auf wenige Elemente beschränken. Im Teil 2, einem künftigen Post, zeige ich dann weitere Thymleaf Funktionen.

Also hier die vereinfachte Template Datei "src/main/resources/templates/item-list.html":

<!DOCTYPE HTML>

<head>

<title>Spring Boot Thymeleaf Demonstration</title>

</head>

<body>

<h1>Ding Sammlung</h1>

Ding Sammlung ist leer...

</p>

</ol>

<h2><a th:href="@{/item-create}">Erstelle Ding</a></h2>
</div>

</main>

</body>

</html>

Für Infos zu html verweise ich auf https://wiki.selfhtml.org/wiki/HTML.
Die Thymeleaf Ausdrücke erkennt man hier am Prefix "th:":

xmlns:th="http://www.thymeleaf.org" ist die Definition des XML Namespaces für Thymeleaf. Das wird benötigt, damit die folgenden Thymeleaf Ausdrücke als solche erkannt werden.
Mit th:href="@{/css/main.css}" wird hier eine Hyper-Referenz (href) auf die verwendete CSS Datei main.css gemacht. Der Pfad /css/main.css muss sich im Spring resource Folder befinden. Links zu URLs oder Dateien werden immer mit @{...} definiert.
th:src="@{/js/main.js}" referenziert hier die JavaScript Quellen-Datei (src) "/js/main.js". Es funktioniert analog zur th:href Hyper-Referenz.
<a th:href="@{/item-create}"> : th:href kann auch für Links (in a-Tags) zu anderen Views genutzt werden, die dann wieder über den Spring Controller ausgespielt werden, siehe ItemController Klasse showCreateItem Methode.
th:if="${#lists.isEmpty(items)} ist ein Thymeleaf if-Ausdruck zum Ein- oder Ausblenden des zugehörigen Tags. Die Erklärung dieses Ausdrucks findet ihr bereits im ersten Abschnitt dieses Blog-Posts.
Hier möchte ich noch mal darauf eingehen, wo die items Liste her kommt. Schauen wir uns noch mal unseren Controller an. Dort sehen wir, dass eine Liste mit Item Objekten zum Modell per Methode addAttribute hinzugefügt wurde. addAttribute verwendet als Schlüssel den Wert "items", daher können wir in Thymeleaf mit items auf den Wert im Modell, also die List<Item> Instanz zugreifen.
th:unless="${#lists.isEmpty(items)} bzw. th:unless ist die negierte Form vom vorherigen th:if. Es entspricht also exakt diesen Ausdruck:
th:if="${not #lists.isEmpty(items)}.
th:each="item : ${items}" ist eine for-each Schleife, wie wir sie auch aus Java kennen. ${items} greift auf die List<Item> Instanz in unserem Modell zu. Mit th:each iteriert Thymeleaf über alle Element in der Liste. Innerhalb der Tags (im Beispiel <li>) im Schleifen Tag (im Beispiel <ol>) können wir mit ${item} auf die einzelnen Listenelemente zugreifen.
th:text="${item.name}" wird verwendet um einen Text in einem Tag auszuspielen. Der Text wird aus der Variablen item bzw. deren Attribute name ausgelesen.

Im Browser sieht die Seite dann so aus, wenn man http://localhost:8080 aufruft und ja, das css für die Seite gewinnt keinen Schönheitswettbewerb 🙈

Fazit & Ausblick

In diesem Blog-Post haben wir gesehen, wie man mit Spring MVC Web-Applikationen bauen kann. Die html Seiten haben wir mit Thymeleaf Templates erstellt. Variable Elemente wurden vom Controller ins Modell geschrieben und im html-Template mit Thymeleaf Ausdrücken ausgelesen.

Im 2. Teil zu Thymeleaf stelle ich folgende Aspekte vor:

Schreiben ins Modell bzw. html Formulare
JavaScript in Thymeleaf Templates
Iternationalisierung (i18n) bzw. mehrere Sprachen mit Spring
Wiederverwendung von Thymeleaf Templates - z.B. dasselbe html head-Tag in mehreren Seiten anzeigen

Den kompletten Code inklusive dem Code für Teil 2 findet ihr hier in GitHub:
https://github.com/elmar-brauch/thymeleaf

Weiterführende Informationen zu Thymeleaf findet ihr hier:
https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html

Performanz Tuning: Strategien und Tipps aus der Praxis

noreply@blogger.com (Elmar Brauch - Microservice Master) — Fri, 11 Aug 2023 15:54:00 +0000

Performanz-Problemen sind meist schwierig zu lösen. Hier zeige ich euch, wie wir unser letzten Problem analysiert, gemessen und gelöst haben. Unter dem Zeitdruck des bevorstehenden Go-Lives wählten wir Strategien, um Risiken durch Seiteneffekte zu vermeiden.

Analyse von Performanz-Problemen

Aus Kundensicht ist unser System eine Browser-Anwendung. Wenn die Seiten im Browser langsam laden, haben wir ein Performanz-Problem. Die Diskussion, was langsam bedeutet und ob langsame Ladezeiten in manchen UseCases akzeptabel sind, ignoriere ich hier. Unsere Situation war eindeutig, statt Ladezeiten von 1-2 Sekunden dauerte es in einigen Fällen mehr als 10 Sekunden.

Logs sind ein guter Startpunkt für die Analyse. Eventuell habt Ihr einen Log-Eintrag am Anfang und Ende der Anfrage. Mit den Zeitstempeln dieser beiden Log-Einträge könnt Ihr die Bearbeitungsdauer der Anfrage überprüfen. Das bestätigt objektiv euer Preformanz-Problem.

Wo treten Performanz-Probleme auf?

In unserem Fall betraf das Performanz-Probleme nur UseCases die mit der ShoppingCart API zu tun hatten. Damit war klar, wo die genaue Analyse beginnt. Sollten die Probleme überall im Gesamtsystem auftreten, würde ich am ersten System in der Kette mit der Ursachenforschung beginnen.

Wann treten die Performanz-Probleme auf?

Die Performanz-Probleme traten nicht immer auf. Wir haben dann herausgefunden, dass es einen Zusammenhang zwischen Performanz und Menge der Produkte im ShoppingCart gibt. Damit konnten wir das Problem reproduzieren und zur Lösungsfindung übergehen.

Die Reproduzierbarkeit ist beim Beheben von Performanz-Problemen sehr wichtig. Das fachliche Verhalten der Anwendung darf sich nicht ändern, muss aber schneller werden. Also testen wir vorher und messen dabei die Performanz. Nach dem Tuning testen wir erneut und messen die Performanz. Blieb das getestete Verhalten gleicht, zeigt der Vergleich der Performanz-Messungen, ob unsere Tuning Maßnahmen erfolgreich sind. Ohne Reproduzierbarkeit können wir nicht beurteilen, ob wir überhaupt an der richtigen Stelle getunt haben.

Arbeit strukturieren & priorisieren

Performanz-Probleme eskalieren schnell, wenn wichtige UseCases zu langsam oder im schlimmsten Fall nicht benutzbar sind. Geratet auf keinen Fall in Panik und tunt mit allen EntwicklerInnen überall. Die Gefahr von Seiteneffekten oder neuen Bugs, darf beim Tunen nicht unterschätzt werden. Daher müssen Performanz-Tunings genau so strukturiert wie andere Arbeiten ablaufen.

Überlegt bei Bedarf mit dem ganzen Team, was Ursachen und Lösungen sein könnten. Erstellt Tickets bzw. Arbeitspakete für die einzelnen Ideen. Diese priorisiert ihr anschließend, so dass ihr sie nach einander abarbeiten könnt. Damit könnt ihr für jede Maßnahme einzelnen prüfen, ob der gewünschte Tuning-Erfolg eingetreten ist.

Grundlage für unsere Maßnahmen-Priorisierung war der geschätzte Aufwand, das Risiko von Seiteneffekten bzw. Bugs und das Tuning-Potential. Mit hoher Priorität bearbeitet ihr Tickets mit geringem Aufwand und Risiko bei möglichst großem Potential zur Beschleunigung eurer Anwendung. Mehr CPU in euren Server könnte beispielsweise so eine Maßnahme sein (wenn ihr die laufenden Kosten nicht betrachtet). Tickets mit hohem Aufwand und Risiko bei schwer abschätzbarem Tuning Potential sollten am Ende eurer priorisierten Liste stehen. Komplette Technologie-Wechsel wären Beispiele dafür, also beispielsweise Python durch Java ersetzen oder die vorhandene relationale Datenbank durch ein bisher ungenutzte NoSQL Datenbank austauschen.

Schnell genug? Dann beende das Tuning.

Wenn das System schnell genug ist, stellt die Tuning-Maßnahmen ein oder bewertet sie neu. Prüft dazu nach jedem erfolgreichen Performanz-Tuning Change im Master Branch, ob euer System schnell genug ist. Ist das der Fall, beendet das Performanz-Tuning, um die Risiken von ungewollten Seiteneffekten zu minimieren. Tunings sind meist komplexe Änderungen. Je mehr Tuning-Maßnahmen ihr bündelt und abliefert, desto größer ist das Risiko versehentlich neue Fehler einzubauen.

EntwicklerInnen sind beim Tuning in ihrem Element und haben meist weitere Verbesserungs-Ideen, die sie gerne ausprobieren wollen. Widersteht diesem Drang. Plant die Arbeit stattdessen im Rahmen eurer normalen Prozesse. Auf diese Weise vermeidet ihr unnötige Risiken zum Erreichen einer Performanz, die im Moment keiner erwartet. Liefert weitere Tunings im Rahmen eurer kontinuierlichen Release-Strategie einzeln aus, so könnt ihr im Fehlerfall leicht zurückrollen.

Performanz-Tunings implementieren

Im folgenden erkläre ich unsere Performanz-Tuning Strategien bzw. Regeln, die wir in der Praxis angewendet haben. Es geht dabei um das Allgemeine Vorgehen, welches unabhängig von Programmiersprachen oder Technologie-Stacks ist.

Erst messen, dann tunen!

Stellt euch folgendes vor:

Beim Lesen des Codes findet Ihr eine Methode, die eine Liste von Objekten durchsucht. Ihr erkennt direkt, dass die Suche einen linearen Aufwand hat. Deshalb baut ihr die Suche so um, dass der Aufwand konstant ist, indem ihr mit Indexen sucht. Danach liefert ihr die beschleunigte Software aus. Für den Kunden bzw. Benutzer ist aber alles genau so langsam wie vorher. Warum?

In diesem Beispiel wurde die Regel "Erst messen, dann tunen" ignoriert. Beim Messen hättet ihr feststellen können, dass die Methode bei der Gesamtverarbeitungsdauer nicht ins Gewicht fällt, da die meiste Zeit z. B. beim Interagieren mit der Datenbank verbraucht wird.

Zum Messen könnt Ihr nach Performanz-Plugins für eurer IDE suchen. Eine einfache Alternative sind zusätzliche Log-Zeilen in eurem Code, z. B. so:

public List<Price> findPrices(List<String> ids) {

var result = new ArrayList<Price>();

doOtherCrazyStuff();

for (var id : ids) {

var before = System.currentTimeMillis();

result.add(requestPriceAtPcm(id));

log.debug("requestPriceAtPcm in ms: "

+ (System.currentTimeMillis() - before));

}

doMoreCrazyStuff();

return result;

}

Hier hatte ich die Vermutung, dass die Methode requestPriceAtPcm zu häufig aufgerufen wird und zu lange dauert. Daher messe ich die Zeit und logge sie für jeden Aufruf. Um das konkrete Tuning "Beschleunigen der Methode" oder "Parallelisieren der for-Schleife" geht es hier noch nicht. Mit der Messung finde ich zuerst heraus, ob Tunings an dieser Stelle überhaupt lohnen. Lohnen sie nicht, wie beim Anfangsbeispiel mit dem linearen Aufwand einer Suche, so stelle ich dieses Tuning zurück und schaue mir andere Stellen mit Tuning-Potential an.

Nach dem Tunen erneut messen

Euer Performanz-Tuning ist nur dann erfolgreich, wenn die Logik anschließend messbar schneller ist. Wie zuvor erwähnt sind Tunings häufig riskante Anpassungen am Code. Unter Zeitdruck sollten sie nur dann ausgeliefert werden, wenn sich die Anpassung wirklich lohnt. Dazu müsst Ihr nach dem Tuning erneut messen, ob die Anwendung wirklich schneller geworden ist.

Ist die Anwendung nicht schneller, solltet ihr eure Code-Änderungen zurückstellen bzw. nicht im Master-Branch committen. Denn an je mehr Tuning-Schrauben ihr gleichzeitig dreht, desto schwieriger erkennt ihr was wirklich hilft. Außerdem steigt mit jeder Änderung die Wahrscheinlichkeit für neue Seiteneffekte bzw. Bugs.

Tune immer nur eine Stelle

Diese Überschrift bzw. Regel passt zur vorherigen Beschreibung. Hier ein anderes Beispiel:

Euer System besteht aus mehreren Microservices und es ist zu langsam. Jetzt könntet ihr gleichzeitig an Tunings an allen Microservices arbeiten. Das kann funktionieren, es kann aber auch schief gehen. Gegebenenfalls wird euer System schneller, ihr wisst aber nicht an welchem Microservice, die Tunings erfolgreich waren, da an allen optimiert wurde. Mit gutem Logging erkennt ihr es vermutlich doch, aber die Arbeitsweise war nicht effizient.

Im Idealfall loggt jeder Microservice die Verarbeitungsdauer eingehender Requests. Diese Logs zeigen dann, in welchem Microservice das Gesamt-System die meiste Zeit benötigt. Auf diese Microservices fokussiert ihr euch zuerst - hier gibt es das größte Tuning-Potential.

Keine Anfrage ist die schnellste Anfrage

Beispiel: Euer Server hat eine häufig benutzte Methode, ihr tunt sie von zwei Sekunden auf eine Sekunde. Gute Arbeit - hilft aber nichts, weil der Benutzer immer noch lange warten muss. Woran kann es liegen?

Zum Server gibt es immer einen Client. Wenn der Client 10 unnötige Anfragen stellt, kann Server-seitiges Tuning das Problem nicht lösen. Schaut euch auch den Client kritisch an:

Ist die Anfrage an dieser Stelle wirklich nötig?
Können mehrere Anfragen zu einer zusammengefasst werden?
Könnte ein Client-seitiger Cache eingebaut werden?

Die schnellste Antwort bekommt die Anfrage, die nicht abgeschickt wurde.

Dazu ein Beispiel aus meiner Praxis: Für jede Darstellung des Einkaufwagen im Online-Shopping-Portal, wurden die Preise aller Produkte im Einkaufwagen neu abgefragt. Diese Logik wurde gebaut, um dem Kunden stets die aktuellen Preise zu zeigen. Je mehr Produkte im Einkaufswagen waren, desto länger musste der Kunde warten bis alle Preise abgefragt waren.

Funfact: Die Preise ändern sich nur einmal am Tag und zwar jeden Morgen um 8 Uhr. Unsere performantere Lösung für dieses Problem war ein Preis-Cache einzubauen (Mehr Infos zu Caches, siehe cache.html). Dieser Cache wird jeden morgen um 8 Uhr geleert und neu befüllt. So muss kein Kunde mehr auf das Laden der aktuellen Preise warten - außer dem Kunden der genau um 8 Uhr morgens kommt...

Durch den Cache schicken nur noch zur einmaligen täglichen Befüllung des Caches Anfragen an die Preis API. Für die meisten Kunden ist damit das Abfragen der Preise nicht mehr nötig, da die Preis-Daten schon im Cache sind. Wir sparen also nicht nur die Preis-Anfragen ein, sondern eliminieren damit auch für den Kunden die Wartezeit auf die Preise und haben ein messbares Performanz-Tuning implementiert.

Verwende realistische Testdaten während der Entwicklung.

Ein- und Ausgabedaten beeinflussen die Performanz. Iterieren wir beispielsweise über eine kleine Datenmenge, fällt die Verarbeitungsdauer der einzelnen Datenelemente kaum ins Gewicht. Ein inperformanter Algorithmus innerhalb der Schleife, kann hinsichtlich der Gesamtdauer für kleine Datenmengen akzeptabel sein. Bei großen Datenmengen beeinflusst der inperformante Algorithmus in der Schleife die Gesamtdauer aber erheblich.

Unrealistisch kleine Testdatenmengen waren in meinem Fall die Ursache des spät entdeckten Performanz-Problems. Realistische Testdaten der Clients unserer ShoppingCart API erhielten wir leider sehr spät, so dass wir kurz vor dem Go-Live des Gesamtsystems tunen mussten. Mit realistischen, großen Datenmengen zu Beginn der Entwicklung erkennen wir Performanz-Probleme direkt (Eventuell entstehen sie gar nicht, da direkt passende Lösungen implementiert werden). Bearbeiten wir Performanz-Probleme in frühen Entwicklungsphasen mit weniger Zeitdruck, lösen wir auch die Auswirkungen von Seiteneffekten entspannter. Dennoch empfehle ich die hier gezeigten Regeln zum disziplinierten Performanz-Tuning - es ist auch ohne Zeitdruck schwierig genug.

Fazit

Mit den hier gezeigten Performanz-Tuning Strategien schafften wir einen erfolgreichen Go-Live unseres neuen Shopping-Portals. Dazu lieferte mein Team eine performante ShoppingCart API.

Als Zusammenfassung meine Tuning-Regeln:

Erst messen, dann tunen!
Nach dem Tunen erneut messen
Tune immer nur eine Stelle
Keine Anfrage ist die schnellste Anfrage
Verwende realistische Testdaten während der Entwicklung
Schnell genug? Dann beende das Tuning.

Reaktive REST-Webservices mit Spring WebFlux

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sat, 01 Jul 2023 13:15:00 +0000

Mit Spring WebFlux entwickeln wir deutlich performanterer Web-Anwendungen und REST-Services. WebFlux ist Teil vom Spring Reactor Projekt. Es ist die moderne, reaktive Alternative zu Spring MVC. In diesem Artikel baue ich mit Mono und Flux eine reaktive API.

Unterschied zwischen WebFlux und Spring MVC

Das Reactor Projekt bildet die Grundlage des reaktiven Stacks in Spring. Es bietet eine Event-basierte, nicht blockierende Architektur, so dass darauf aufbauende Anwendungen mehr Leistung aus ihren CPU-Ressourcen herausholen.

Spring WebFlux ist Teil des reaktiven Stacks. Es ist das reaktive Gegenstück zu Spring MVC im klassischen Servlet Stack.
Weitere Infos zu Spring MVC findet ihr in meinem Blog: spring-mvc-thymeleaf.html
Weitere Details zum Spring Reactor Projekt findet ihr hier: https://spring.io/reactive
Von dort stammt die folgende Gegenüberstellung zur besseren Einordnung der einzelnen Komponenten aus dem Servlet und reaktivem Stack.

Gegenüberstellung Reactive und Servlet Stack

Im ersten Blog-Artikel zur reaktiven Programmierung stellte ich den Spring WebClient vor und zeigte, dass dieser deutlich performanter ist als der klassische HTTP Client: reactive-webclient.html

Hier zeige ich die Vorteile der reaktiven Programmierung anhand einer mit Spring WebFlux geschriebene Serverseite. Konkret entwickle ich eine REST-API und schicke Mono und Flux als Antwort an einen aufrufenden Spring WebClient.

Video zur Umstellung von Spring MVC auf WebFlux

Design Pattern: Publisher-Subscriber

Die Kommunikation zwischen Client und Server funktioniert in Spring WebFlux nach dem Publisher und Subscriber Entwurfsmuster. Serverseitig agiert Spring WebFlux als Publisher und publiziert Daten als Mono oder Flux, sobald diese verfügbar sind. Clientseitig meldet sich der Spring WebClient beim Publisher an (subscribe) und wartet dann in einem separaten Thread auf die Daten der Server-Antwort. Der Haupt-Thread auf Client-Seite kann ist nicht blockiert und läuft weiter, weil das Warten in einem anderen Clientseitigen Thread geschieht. Dadurch haben wir eine Nachrichten-basierte, nicht blockierende Kommunikation, so wie in der reaktiven Programmierung benötigt. Weitere Details zum Design Pattern findet ihr hier: Wikipedia_Publish_Subscribe

Was ist ein Mono?

Wenn die Serverseite mit Spring WebFlux einen oder keinen Datensatz als Ergebnis liefert, dann verwenden wir als Antworttyp Mono. Dazu ein Beispiel aus der analogen Welt:

Im Restaurant bestellt der Gast (Clientseite) ein Hauptgericht (Mono). Die Küche (Serverseite) fängt nun an das Gericht zu kochen. Sie bringt es dem Gast auf einem Teller (Mono), wenn es fertig ist. In der Zwischenzeit kann der Gast noch andere Dinge tun: Trinken, Reden, Handy spielen usw. - der Gast ist also nicht blockiert (reaktiv), während er auf die Nachricht Hauptgang ist fertig wartet.

Was ist ein Flux?

Liefert die Serverseite eine beliebig große Menge an Datensätzen als Ergebnis, so ist der Antworttyp ein Flux. Ein Flux ist ein Datenstrom der vom Server zum Client fließt. Die Flussgeschwindigkeit kann sich dabei beliebig ändern. Dazu wieder ein Beispiel aus der analogen Gastronomie:

Im Sterne-Restaurant kocht die Küche (Serverseite) ein 9 Gänge Menu (Flux) für die Gäste (Clientseite). Dabei kommen die einzelnen Gänge getrennt von einander beim Gast an, manche Gänge kommen schneller hintereinander andere brauchen etwas länger (Datenstrom). Wie schon beim Mono-Beispiel ist der Gast im Restaurant nicht blockiert bzw. reaktiv, da er sich in der Zwischenzeit beliebig beschäftigen kann.

Mono als Antwort einer REST-API

Eine reaktive REST-API schickt den Datensatz nach dem Publisher-Subscriber Prinzip an den Client. Wenn es höchstens ein Datensatz ist, verwenden wir serverseitig einen Mono. Im folgenden wird ein Spring RestController gezeigt, der ein Mapping für eine GET Methode hat:

@RestController

public class ReactiveEmployeeController {

@ResponseStatus(HttpStatus.OK)

@GetMapping("/employee/mono")

public Mono<Employee> receiveMono() {

Mono<Employee> result = Mono.fromSupplier(
() -> generateEmployee())

.doOnSuccess(

employee -> log.info("Mono published: " + employee));

log.info("Returning Mono.");

return result;

}

...

}

@RestController und @GetMapping erkläre ich hier: rest-apis-in-java.html
Die Methode generateEmployee ist ausgeblendet, da sie lediglich eine Employee Instanz erstellt. In meiner Demo wartet die Methode einige Sekunden bevor sie als Ergebnis eine Employee Instanz liefert. Das Warten simuliert eine lang dauernde Suche nach einem Employee in einer großen Datenbank. Je länger die Such- oder Rechenoperationen zum Beschaffen des Ergebnisses dauern und je mehr Anfragen ankommen, desto mehr profitieren wir hinsichtlich Performance von der reaktiven Programmierung.
Mono<Employee> ist der Rückgabetyp unserer GET Methode.
Den HTTP Response-Code definiere ich mit der Annotation @ResponseStatus(HttpStatus.OK).
return Mono.fromSupplier antwortet dem Client direkt, schickt aber noch nicht den eigentlichen Datensatz. Der Parameter der Methode fromSupplier ist ein Lambda Ausdruck bzw. ein Supplier. Der Supplier berechnet den eigentlichen Datensatz (Employee) und publiziert ihn dann durch den Mono an den Client.
doOnSuccess hat als Parameter einen Consumer, den ich hier nur zum Loggen verwende. doOnSuccess wird ausgeführt, wenn der Mono erfolgreich seinen Datensatz publiziert hat.
Supplier und Consumer sind funktionale Interfaces, die in Java 8 eingeführt wurden.

Wie man clientseitig mit dem reaktiven Spring WebClient einen Mono abfragt und einen Lambda Ausdruck als Consumer zur Verarbeitung des Datensatzes registriert (subscribe), zeige ich in reactive-webclient.html. Daher hier ohne weitere Erklärungen der Code der Clientseite:

WebClient reactiveClient = WebClient.builder()

.baseUrl("http://localhost:8080").build();

reactiveClient.get().uri("/employee/mono")

.retrieve().bodyToMono(Employee.class)

.subscribe(employee -> {

log.info("Response received: " + employee);

});

log.info("Request send. " +

"Data published in Mono will be handled in another thread.");

Folgende 4 Log-Einträge werden vom Client und Server durch den Logger (log.info) in dieser Reihenfolge geschrieben:

2023-02-21 21:46:12.255 INFO [ main] Client : Request send. Data published in Mono will be handled in another thread.

2023-02-21 21:46:12.492 INFO [ctor-http-nio-4] ReactiveEmployeeController : Returning Mono.

2023-02-21 21:46:14.515 INFO [ctor-http-nio-4] ReactiveEmployeeController : Mono published: Employee(id=-772...)

2023-02-21 21:46:14.654 INFO [ctor-http-nio-3] Client : Response received: Employee(id=-772...)

Beachtet die verschiedenen clientseitig eingesetzten Threads: main und ctor-http-nio-3. Aufgrund der geringen Last wurde serverseitig nur ein Thread ctor-http-nio-4 verwendet, das können bei höherer Last mehr sein. Die Reihenfolge der Logeinträge zeigt, dass die Threads weder client- noch serverseitig blockiert wurde. Bei einer synchronen, blockierenden Kommunikation wären, die ersten beiden Log-Einträge am Ende:

Clientseitig, weil der Log-Eintrag "Request send..." erst nach erhaltener Antwort vom Server geschrieben wird - vorher ist der main Thread blockiert.
Serverseitig, weil zuerst das Ergebnis (Employee Instanz) berechnet wird und erst danach "Returning..." geloggt werden würde. (Inhaltlich machen die geloggten Texte bei einer synchronen Kommunikation natürlich keinen Sinn.)

Flux als Antwort einer REST-API

Wie zuvor erwähnt ist der Unterschied zwischen Mono und Flux die Anzahl der Datensätze, welche der reaktive Server publiziert. Beim Flux können es beliebig viele sein, es ist also eine Art Stream. Im folgenden Beispiel werde ich serverseitig die Datensätze im Flux aus einem Stream beziehen. Das Stream Interface wurde in Java 8 eingeführt und wird zum Beispiel hier vorgestellt: https://ertan-toker.de/java-streams-tutorial-and-examples/

@ResponseStatus(HttpStatus.OK)

@GetMapping(path = "/employee/flux",

produces = MediaType.APPLICATION_NDJSON_VALUE)

public Flux<Employee> receiveFlux() {

Supplier<Employee> supplier = () -> generateEmployee();

return Flux.fromStream(Stream.generate(supplier))

.doOnNext(employee -> log.info("Flux emits: " + employee));

}

Flux<Employee> ist der Rückgabetyp unserer Methode. Damit der Client erkennt, dass die Antwort ein reaktiver Datenstrom (Flux) ist, muss der Content Type für unsere HTTP Response entsprechend als "application/x-ndjson" definiert werden. Das mache ich in der Annotation @GetMapping mit: produces = MediaType.APPLICATION_NDJSON_VALUE
Ansonsten habe ich @GetMapping und @ResponseStatus bereits im Mono Beispiel weiter oben erklärt.
Die Supplier<Employee> Instanz ist ein Lambda Ausdruck, der die Methode generateEmployee aufruft. Diese Methode wird auch im Mono Beispiel verwendet und erklärt.
Stream.generate erstellt mit Hilfe der Supplier<Employee> Instanz einen Datenstrom vom Typ Stream<Employee>. Die Supplier Instanz befüllt also kontinuierlich den Stream mit neu generierten Employee Objekten bzw. Daten. Dieses Beispiel ist ein endloser Datenstrom. In der Praxis könnte ein Stream aus einer endlichen Liste erstellt werden oder eine reaktive Datenbank-Abfrage, die mit längerer Rechenzeit immer mehr Ergebnisse liefert. Die reaktive Datenbank-Abfrage stelle ich hier vor: spring-data-reactive.html
Flux.fromStream ist eine von vielen Möglichkeit eine Flux Instanz zu erstellen. Schaut euch einfach die abstrakte Klasse Flux im Quellcode an, um weitere Möglichkeiten zu sehen.
Analog zu Mono (.doOnSuccess) gibt es auch beim Flux diverse Methode, um in den reaktiven Datenstrom einzugreifen. Mit .doOnNext greift Ihr jedes im Flux publizierte Objekt zu - ich logge hier einfach nur das publizierte Objekt.

Die Clientseite sieht beim Flux vergleichbar zum Mono aus:

Flux<Employee> employees = reactiveClient.get().uri("/employee/flux")

        .retrieve().bodyToFlux(Employee.class);

employees.subscribe(employee -> {

    log.info("Part of response received: " + employee);

});

reactiveClient ist dieselbe Instanz von WebClient, die zuvor im Mono Beispiel verwendet wurde.
bodyToFlux wird anstatt bodyToMono verwendet und legt fest, dass die Antwort des Servers ein Datenstrom ist.
Jedes vom Server durch den Flux publizierte Employee Objekt wird in einem Consumer verarbeitet. Der Consumer bindet sich mit der subscribe Methode als Lambda Funktion an den Flux<Employee>.

Hier ein kleiner Ausschnitt aus den client- und serverseitigen Logs:

2023-02-23 21:08:31.258 INFO [ctor-http-nio-4] ReactiveEmployeeController: Flux emits: Employee(id=-835...)

2023-02-23 21:08:31.447 INFO [ctor-http-nio-3] Client:
Parts of response received: Employee(id=-835...)

2023-02-23 21:08:33.353 INFO [ctor-http-nio-4] ReactiveEmployeeController: Flux emits: Employee(id=-526...)

2023-02-23 21:08:33.358 INFO [ctor-http-nio-3] Client:
Parts of response received: Employee(id=-526...)

2023-02-23 21:08:35.363 INFO [ctor-http-nio-4] ReactiveEmployeeController: Flux emits: Employee(id=494...)

2023-02-23 21:08:35.367 INFO [ctor-http-nio-3] Client:
Parts of response received: Employee(id=494...)

Der Client bzw. ein Thread auf der Clientseite verarbeitet immer dann einen Datensatz, wenn der Datensatz vom Server publiziert wurde. Damit haben wir mit einem HTTP Request einen Datenstrom zwischen Client und Server aufgebaut, der effizient und Nachrichten-basiert in Threads verarbeitet wird. Diese Konstellation ist für mich ein Highlight der reaktiven Programmierung! 🎆

Die langsameren Alternativen in der klassischen Programmierung bzw. bei der Verwendung von synchronen Requests sind:

langes Warten auf eine riesige Antwort mit allen Datensätzen
oder viele kleine Abfragen (Pagination), um die Datensätze in kleineren Teilmengen abzufragen.

Fazit

Ich habe gezeigt, wie man mit reaktiver Programmierung und Spring WebFlux eine Client-Server-Kommunikation nach dem Publisher und Subscriber Entwurfsmuster aufbauen kann. Sowohl die Client- als auch die Serverseite sind nicht blockierend und damit besonders performant auf aktuellen Rechnern mit mehreren Kernen.

Die Unterschiede zwischen Mono (höchstens ein Datensatz als Antwort) und Flux (beliebig viele Datensätze als Antwort) habe ich anhand von Beispielen erklärt. Wie immer findet ihr den kompletten Code mit JUnit-Tests, die als Clientseite fungieren, in GitHub:

https://github.com/elmar-brauch/webflux

Weiterführendes zum Einsatz von Datenbank in Spring Reactive findet ihr hier: spring-data-reactive.html

Spring WebClient der reaktive HTTP Client im Performance-Vergleich zum RestTemplate

noreply@blogger.com (Elmar Brauch - Microservice Master) — Thu, 18 May 2023 13:38:00 +0000

Spring Reactive ist der moderne, reaktive Technologie Stack von Spring. Es ist die skalierbare, resiliente, responsive und Event-basierte Alternative zum klassischen Servlet Stack - dem bisherigen Standard in jedem Spring Web Projekt. Teil des reaktiven Stacks ist Spring WebFlux und dessen WebClient zum Verschicken von HTTP Requests. In diesem Artikel zeige ich, dass der WebClient unter Last deutlich schneller als der klassische Spring RestTemplate ist.

Spring WebFlux

Spring WebFlux ist Teil des reaktiven Stacks und damit das reaktive Gegenstück zu Spring MVC im klassischen Servlet Stack.
Weitere Infos zu Spring MVC findet ihr in meinem Blog: spring-mvc-thymeleaf.html
Weitere Details zum Spring Reactor Projekt findet ihr hier: https://spring.io/reactive
Von dort stammt auch die Gegenüberstellung von Servlet und reaktivem Stack. Diese hilft die einzelnen Komponenten besser einzuordnen.

Gegenüberstellung Reactive und Servlet Stack

Hier konzentriere ich mich auf den Vergleich der HTTP Clients aus beiden Stacks:

WebClient: Aus dem reaktiven Stack als Teil der Spring WebFlux Bibliothek
RestTemplate: Aus dem Servlet Stack als Teil der Spring Web Bibliothek

Beim reaktiven Programmieren geht es nicht nur um die Verwendung einer anderen Art von HTTP-Kommunikation. Sondern geht es auch darum, dass wir wann immer möglich auf CPU blockierende Operationen verzichten und eine alternative, nicht blockierende Operation verwenden. Daher gibt es auch reaktive Repositories für den nicht blockierenden Zugriff auf Datenbank als Teil von Spring Data. Spring Data in der klassischen Form, habe ich in diesem Blog-Artikel vorgestellt:
mongodb-und-spring-data.html

HTTP Requests mit WebClient und RestTemplate

RestTemplate

HTTP Requests mit dem RestTemplate kennt Ihr vermutlich schon. Das RestTemplate ist eine elegante und einfache Form um HTTP REST Requests zu verschicken. Im Code sieht das z.B. so aus:

String responseBody = new RestTemplate().getForEntity(

"http://someurl.de/something",

String.class)

.getBody();

In diesem Code Beispiel erzeuge ich eine neue Instanz des RestTemplate, um dann einen HTTP GET Request abzuschicken (getForEntity). In der Methode getForEntity definiere ich die URL und den Klassen-Typ (String.class) in den ich den Body der Response (.getBody()) automatisch geparst haben möchte. Statt String würde man hier besser fachliche Klassen verwenden, die passend zur Response sind (z.B. Employee, Customer, Car, Item etc.).
Das RestTemplate kann noch viel mehr, z.B. Header mitschicken, in komplexere Typen als String parsen und unterstützt natürlich auch alle anderen HTTP Methoden (POST, PUT etc.). Weitere Infos zum RestTemplate findet ihr z.B. hier:

https://www.baeldung.com/rest-template

RestTemplate verschickt 3 synchrone Requests - Haupt-Thread blockiert bis Response ankommt.

WebClient

Um den WebClient verwenden zu können, müssen wir die Spring WebFlux Bibliothek zu unserem Projekt hinzufügen. Bei Spring Boot Projekten funktioniert das mit Gradle so:

implementation 'org.springframework.boot:spring-boot-starter-webflux'

Mit Maven funktioniert es analog:

    <dependency>

        <groupId>org.springframework.boot</groupId>

	<artifactId>spring-boot-starter-webflux</artifactId>

    </dependency>

Ansonsten müssen wir nichts weiter tun, um den WebClient zu nutzen. Mit dem WebClient sieht der zuvor mit RestTemplate gezeigte GET Request so aus:

WebClient client = WebClient.create("http://someurl.de/something");

String responseBody = client.get().retrieve().toEntity(String.class)

.block().getBody();

Der WebClient wird mittels Builder instanziiert (WebClient.create). Dann wird der abzuschickende Request spezifiziert - hier im Beispiel minimal mit der get() Methode. Ab retrieve() wird festgelegt, wie die erwartete Response aussieht. Mit toEntity(String.class) wird festgelegt, dass der Body der Response in einen String geparst werden soll. Der eigentliche HTTP Request wird hier im Beispiel mit der Methode block() blockierend verschickt. Sobald die HTTP Response angekommen ist, wird der Response-Body als String Instanz mit getBody() ausgelesen.

Wenn wir den WebClient so verwenden, haben wir keinen Vorteil gegenüber dem RestTemplate, da der HTTP Request synchron verarbeitet wird. Das Besondere am WebClient ist die nicht blockierende, Event-gesteuerte (und damit asynchrone) HTTP Request und Response Verarbeitung. Diese sieht dann so aus:

Mono<String> responseMono = client.get().retrieve()

.bodyToMono(String.class);

responseMono.subscribe(responseBodyAsString -> {

// Bei erfolgreichen Requests, enthält responseBodyAsString
// den HTTP Response Body als String und

// kann hier im Lambda z.B. so verarbeitet werden:

System.out.println(responseString);

});

client ist hier dieselbe WebClient Instanz wie im vorherigen Code-Beispiel.
Mit der Methode bodyToMono legen wir fest, dass als Antwort auf diesen Request ein Mono erwartet wird. Ein Mono ist ein Datenstrom, der höchstens eine Instanz vom definierten Datentyp (hier String.class) übertragen wird. Die Alternative zum Mono ist der Flux für Datenströme, die beliebig viele Instanzen des definierten Datentyps enthalten. Würden wir statt String, einen Datentyp wie Customer, Employee, Item, Car etc. verwenden, wird klar, dass man besser Flux bei Antworten in Listen-Form verwendet.
In diesem Blog-Artikel werde ich Flux und Mono nicht weiter betrachten, obwohl diese Typen sehr wichtig für die Performance in der reaktiven Programmierung sind!
Statt der Methode block verwenden wir beim reaktiven Programmieren die Methode subscribe. subscribe schickt den Request ab und meldet einen Lambda-Ausdruck an, der die Antwort verarbeitet, wenn diese ankommt. Damit ist subscribe eine nicht blockierende Methode und der Thread, der mit der WebClient Instanz den Request abgeschickt hat, läuft einfach weiter. Im Lambda Ausdruck findet eine asynchrone Verarbeitung der Response statt. Hier im Beispiel wird der Response Body einfach mit System.out in die Konsole geschrieben. Die Response könnte aber auch in einer Datenbank gespeichert werden oder auf andere sinnvolle Weise verarbeitet werden.

WebClient verschickt 3 asynchrone Requests - Haupt-Thread wartet nicht auf die Responses.

Web-Client mit Proxy

In Firmennetzwerken müssen meist Proxies für Internet-Verbindungen eingerichtet werden. Das könnt Ihr zum Beispiel so machen:

reactor.netty.http.client.HttpClient httpClient = HttpClient.create()

.proxy(proxy -> proxy.host("localhost").port(3128)
.type(Proxy.HTTP).nonProxyHosts("*.intranet.de"))

.responseTimeout(Duration.ofSeconds(30));

WebClient proxiedClient = WebClient.builder()

.clientConnector(new ReactorClientHttpConnector(httpClient))

.baseUrl("http://someurl.needs/proxy")

.build();

Statt des WebClient Default ClientConnector erzeugt ihr einen eigenen basierend auf dem Netty HttpClient.
Im Netty HttpClient wird der Proxy mit type, host, port und optional nonProxyHosts definiert. Im HttpClient können noch weitere Einstellungen, wie z. B. Timeouts konfiguriert werden.
Ansonsten wurde hier nur der WebClient-Builder anstelle der zuvor gezeigten create Methode verwendet.

Performance-Vergleich WebClient und RestTemplate

Mich haben die Performance-Unterschiede zwischen WebClient und RestTemplate interessiert. Dazu habe ich den WebClient einfach ausprobiert und die Zeiten gestoppt. Da beim einfachen Ausprobieren die zu erwartenden Ergebnisse schnell sichtbar wurden, habe ich keine wissenschaftlichen Benchmark-Tests durchgeführt.

Der WebClient setzt auf eine asynchrone, Event-gesteuerte Kommunikation, die eingehende Nachrichten (Responses) erst dann aktiv in Threads verarbeitet, wenn diese wirklich angekommen sind - in der Zwischenzeit wird die CPU dabei nicht blockiert bzw. nicht aufgehalten. RestTemplate kommuniziert im selben Thread synchron und blockiert damit den Thread. Da man heute fast immer mehrere CPUs und Kerne zur Verfügung hat und bei der Kommunikation mit Systemen aufgrund der Übertragungsdauer Wartezeiten entstehen, habe ich vorher schon erwartet, dass der WebClient in den meisten Tests schneller ist.
Das zeigt dann auch der Test-Code, den ich zu diesem Artikel geschrieben habe.
Ihr findet den Code hier und könnt damit eigene Performance-Tests machen:

https://github.com/elmar-brauch/webflux

Requests gegen normale REST Webservices

In meinem ersten Performance-Vergleich habe ich drei Spring Beans erstellt, die jeweils den gleichen HTTP Request gegen einen REST-Service irgendwo im Internet schicken - wie gesagt ich mache keinen wissenschaftlichen Benchmark-Test. Die drei Beans sind so aufgebaut:

ClassicBackendApiClient Bean schickt einen GET Request mittels einer RestTemplate Instanz an einen REST-Service im Internet. Das funktioniert genau so wie im vorherigen Abschnitt RestTemplate gezeigt. Die Response wird dann zusammen mit einer Request-Id geloggt. Der Test-Ablauf ist im ersten Sequenz-Diagramm zum RestTemplate gezeigt.
ThreadedClassicBackendApiClient Bean erstellt zum Verschicken jedes einzelnen REST-Requests einen eigenen Thread mittels CompletableFuture.runAsync. Im Thread wird die ClassicBackendApiClient Bean zum Verschicken und Loggen des Requests wiederverwendet. Im Code sieht das so aus:

@Component
public class ThreadedClassicBackendApiClient {
@Autowired ClassicBackendApiClient client;

public void callApi(final int requestId) {
CompletableFuture.runAsync(() -> client.callApi(requestId));
}
}
Weitere Infos zum CompletableFuture aus Java 8, findet ihr zum Beispiel in diesem Buch:
Buch: Java ist auch eine Insel (zu Java 14)
ReactiveBackendApiClient Bean verschickt den gleichen REST-Request wie die anderen 2 Beans nur diesmal mit einer WebClient Instanz. Der Code dazu sieht aus wie im vorherigen Abschnitt WebClient gezeigt - dort zeigt auch das zweite Sequenz-Diagramm den Test-Ablauf.

Der Performance-Vergleich ist in der JUnit 5 Testklasse ReactiveVsClassicClientTest gemacht. Das ist kein richtiger Unit-Test, da ich aber den Anwendungs-Code vom Performance-Test Code trennen wollte, habe ich mich für die Implementierung des Testablaufs und die Zeitmessung in dieser Datei entschieden: https://github.com/...

(Zum Thema JUnit 5 Tests habe ich diesen Artikel geschrieben: JUnit5andSpringBootTest.html)

In der Testklasse kann man das Attribut NUMBER_OF_CALLS anpassen, um Anzahl der Requests festzulegen, die jede Bean abschicken soll. Das Ergebnis der Zeitmessung wird dann einfach geloggt. Für die beiden Beans ThreadedClassicBackendApiClient und ReactiveBackendApiClient verwende ich Awaitility, um solange zu warten bis alle Threads eine Antwort bekommen haben. Awaitility zum Testen von Threads hatte ich in diesem Blog-Artikel erklärt: junit-testing-von-threads.html
Hier noch der Code des JUnit Tests zum Messen der Performance:

@SpringBootTest

@Slf4j

class ReactiveVsClassicClientTest {

private static final int NUMBER_OF_CALLS = 50;

@Test

void useRestTemplate(@Autowired ClassicBackendApiClient client) {

log.info("RestTemplate API calls took {} ms",
measureCalls(client));

}

@Test

void useRestTemplateInThreads(
@Autowired ThreadedClassicBackendApiClient client) {

log.info("RestTemplate in Thread API calls took {} ms",
measureCalls(client));

}

@Test

void useWebClient(@Autowired ReactiveBackendApiClient client) {

log.info("WebClient API calls took {} ms",
measureCalls(clientBean));

}

private long measureCalls(BackendApiClient clientBean) {

long before = System.currentTimeMillis();

for (int i = 1; i < NUMBER_OF_CALLS + 1; i++)

clientBean.callApi(i);

Awaitility.await().until(clientBean::isQueueEmpty);

return System.currentTimeMillis() - before;

}

Alle Beans implementieren das Interface BackendApiClient mit der Methode callApi. Daher konnte ich die Logik zum Messen der Zeit und das Abschicken aller Requests in einer for-Schleife in die Hilfs-Methode measureCalls auslagern.
@Slf4j ist eine Annotation von Lombok, die den Logger im Attribut log bereitstellt. Schaut euch für weitere Details die Webseite von Lombok an: https://projectlombok.org/
Wie @Autowired funktioniert habe ich hier erklärt: kernkonzepte-von-spring.html

Testergebnisse

So kommen wir nun endlich zu den Testergebnissen 😉

NUMBER_OF_CALLS = 2

Auf meinem Rechner schwanken die Zeiten zwischen 0,8 und 3 Sekunden für alle Beans.
Meist waren asynchron arbeitenden Beans minimal schneller. Wenn man allerdings mit so wenigen Requests arbeitet, kann man keine ernsthaften Aussagen zu Performance-Unterschieden machen.

NUMBER_OF_CALLS = 15

ClassicBackendApiClient Bean Zeiten zwischen 4 und 5,2 Sekunden
ThreadedClassicBackendApiClient Bean Zeiten zwischen 1,2 und 2,4 Sekunden
ReactiveBackendApiClient Bean Zeiten zwischen 2 und 3 Sekunden
Es fällt also schon bei 15 Requests auf, dass die asynchrone Verarbeitung durch ThreadedClassicBackendApiClient oder ReactiveBackendApiClient Bean schneller ist als die synchrone Verarbeitung durch die ClassicBackendApiClient Bean.

NUMBER_OF_CALLS = 150

ClassicBackendApiClient Bean braucht nun circa 30 Sekunden. Wenn man das mit den vorherigen Zeiten vergleicht, erkennt man einen linearen Zusammenhang. Jeder weitere Request verlängert die Gesamtdauer, da alle Request nacheinander ausgeführt werden.
ThreadedClassicBackendApiClient Bean Zeiten zwischen 7 und 10 Sekunden
ReactiveBackendApiClient Bean Zeiten zwischen 3 und 5,5 Sekunden
Die asynchrone Verarbeitung wird nun im Vergleich zur synchronen erheblich schneller.
Außerdem fällt auf, das sich bei dieser Request-Anzahl auch messbare Unterschiede zwischen der nicht blockierenden, reaktiven Programmierung (ReactiveBackendApiClient ) und der im jeweiligen Thread blockierenden, klassischen Programmierung (ThreadedClassicBackendApiClient) zeigen.

NUMBER_OF_CALLS = 500

Weitere Messungen mit noch größeren Request-Anzahlen zeigen, dass die Unterschiede immer größer werden. Das RestTemplate ist auch beim Einsatz in Threads durch die Anzahl der verfügbaren Threads und Kerne limitiert, während die reaktive Programmierung durch das nicht blockierende Warten auf eingehende Nachrichten (subscribe) seine Vorteile voll ausspielen kann. Bei Tests mit 500 Requests war der WebClient um circa Faktor 5 schneller als das RestTemplate in Threads.

Performance-Testergebnisse als Liniendiagramm

Fazit

Die reaktive Programmierung ist ein neues Entwicklungs-Paradigma, welches seine Vorteile insbesondere bei hoher Last durch viele Anfragen oder großen Datenabfragen ausspielt. Mit meinem WebClient Performance Test habe ich gezeigt, dass der reaktive WebClient klassischen HTTP Clients bei vielen parallelen Anfragen überlegen ist.

Auch beim Abfragen großer Datenmengen kann der WebClient seine Überlegenheit zeigen, wenn die Server-Seite mit einen Flux antwortet. Für weiterführende Infos zur reaktiven Programmierung mit Spring schaut euch gerne meinen Udemy Kurs an.

Authentifizierung in Web-Anwendungen mit Spring Security 6

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sat, 01 Apr 2023 19:42:00 +0000

Spring Security hilft uns beim Authentifizieren und Autorisieren von Benutzern in Java Web-Anwendungen. Da Spring Security ein mächtiges und komplexes Framework ist, zeige ich in diesem Einstiegsartikel, wie wir die von Spring Boot vorkonfigurierte Spring Security Authentifizierung nutzen und anpassen können.

In diesem Artikel demonstriere ich Spring Security 6 passend zum aktuellen Spring Framework in Version 6. Das Demo Projekt wurde mit der neuen Spring Boot Version 3 erstellt.

Spring Security

Spring Security ist eins mächtiges und flexibel anpassbares Authentifizierungs- und Zugangskontroll-Framework. In der Praxis ist es der Standard zum Absichern von Spring basierten Web-Anwendungen.
Weitere Infos zum Spring Security Projekt findet man hier: https://spring.io/projects/spring-security.

Video zum Blog-Artikel

Spring Security Dependency für das Build-Tool

Mit Spring Boot kann man Spring Security einfach beim Aufsetzen eines neuen Projektes hinzufügen. Das funktioniert so, wie ich es schon in diesem Artikel gezeigt habe:
microservices-mit-spring-boot-erstellen.html
Allerdings kann man Spring Security auch einfach als Maven Dependency zu existierenden Spring oder Spring Boot Projekten hinzufügen, bei Spring Boot Projekten sieht das so aus:

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-security</artifactId>

</dependency>

Da ich zum Bauen der Demo zu diesem Artikel Gradle (https://gradle.org/) verwendet habe, zeige ich hier auch das Gradle Format:

dependencies {

implementation 'org.springframework.boot:
spring-boot-starter-security'...

}

Den kompletten Code zur Spring Security Demo findet ihr in GitHub:

https://github.com/elmar-brauch/spring-security-webapp

Authentifizierung mit dem Spring Security Standard Benutzer

Nach dem Hinzufügen der Spring Security Dependency ist die Spring Boot Web-Anwendung standardmäßig mit Benutzername und Passwort abgesichert. Das sieht man dann in den Log-Einträgen beim Starten der Anwendung:

...Starting Servlet engine: [Apache Tomcat/10.1.1]...

...Initializing Spring embedded WebApplicationContext

...Root WebApplicationContext: initialization completed in 909 ms

.s.s.UserDetailsServiceAutoConfiguration :

Using generated security password: 0139...

...Adding welcome page template: index

o.s.s.web.DefaultSecurityFilterChain : Will secure any request with
[org.spring...security...WebAsyncManagerIntegrationFilter@e6cffb4,
org.spring...security...DefaultLoginPageGeneratingFilter@6507a4d2,
...

In den Logs steht das automatisch, generierte Passwort für den Standard Benutzer mit dem Benutzernamen "user": "Using generated security password: 0139...". Bei jedem Start der Anwendung wird ein neues Passwort generiert.
Außerdem sehen wir noch die Log-Meldung das jeder beliebige Request mit einer Liste von diversen Spring Security Filtern abgesichert wird: "DefaultSecurityFilterChain: Will secure any request with...".

Rufen wir nun im Browser die Web-Application auf (http://localhost:8080), werden wir von den Spring Security Filtern automatisch zur Spring Security Login-Seite weitergeleitet. Der Login-Dialog wird im folgenden Screenshot gezeigt.

Nach erfolgreichem Login als Benutzer "user" wird der Request wie gewohnt von unseren Spring Controllern verarbeitet, wie das funktioniert ist z.B. hier gezeigt: spring-mvc-thymeleaf.html

Spring Security Filter Chain

Vereinfacht gesagt, ist Spring Security eine zusätzlich Schicht zwischen dem Client und der Spring Anwendung. Die Spring Security Schicht prüft, ob die Requests des Clients den Security Regeln der Anwendung entsprichen. Security Regeln definieren wir in Form von Filtern. Die Filter bilden eine Kette (Filter Chain). Jeder eingehende Request durchläuft die Filter der Kette entsprechend ihrer Reihenfolge. Dabei prüft jeder Filter, ob dem Request Zugriff auf die Anwendung gewährt wird oder nicht.

Die Logausgabe listet z.B. den Filter DefaultLoginPageGeneratingFilter auf. Wenn wir diese Klasse in unserer IDE öffnen, sehen wir, dass die Superklasse das Filter Interface implementiert. In DefaultLoginPageGeneratingFilter gibt es daher auch die Implementierung der Methode doFilter. In doFilter wird entschieden, ob die Login Seite angezeigt wird oder nicht. Wenn ihr einen Breakpoint in doFilter setzt und die Anwendung im Debug-Modus startet, seht ihr, dass dieser Filter bei jedem Request benutzt wird.

Standard Benutzer konfigurieren

Wenn unsere Web-Anwendungen mit einem Benutzer auskommt, können wir den Standard Benutzer auch per Konfiguration anpassen. Dazu können wir in der application.properties Datei den Benutzernamen und das Passwort selbst definieren:

# Replace Spring Security default username "user" with:

spring.security.user.name=admin-user

# Replace Spring Securtiy randomly generated password with:

spring.security.user.password=geheim123

Nach einem Neustart können wir uns nun als Benutzer "admin-user" mit dem Passwort "geheim123" einloggen.
Spring Boot bietet neben der application.properties Datei noch einige andere Möglichkeiten, um Konfigurationen vorzunehmen. So können wir das Passwort auch an einer anderen Stelle definieren - weitere Infos dazu findet ihr hier: https://docs.spring.io/spring-boot/docs/1.0.1.RELEASE/reference/html/boot-features-external-config.html

Mehrere Benutzer und Rollen definieren

Spring Security unterstützt beliebig viele, verschiedene Benutzer. Diese können sich in einer Datenbank, in einem LDAP-Server oder anderen Identity Provider befinden - es werden alle gängigen Lösungen unterstützt. Alternativ kann man Spring Security auch wie benötigt anpassen. Um diesen Einstiegsartikel möglichst einfach zu halten, stelle ich hier nur eine einfache Benutzer-Verwaltung im Speicher vor. Alles was wir dazu brauchen ist eine einfache Spring Bean, die das Interface UserDetailsService implementiert.

@Configuration

public class SecurityConfiguration {

@Bean

public UserDetailsService users(@Autowired PasswordEncoder pwEnc) {

UserDetails user = User.builder()

.username("user")

.password(pwEnc.encode("top"))

.roles("USER")

.build();

UserDetails admin = User.builder()

.username("admin")

.password(pwEnc.encode("secret"))

.roles("USER", "ADMIN")

.build();

return new InMemoryUserDetailsManager(user, admin);

}

@Bean

public PasswordEncoder passwordEncoder() {

return new BCryptPasswordEncoder();

}

Die UserDetailsService Bean habe ich per @Bean Annotation in einer Spring Konfigurationsklasse (@Configuration) erstellt. Dieses Vorgehen ist Standard in Spring, siehe dazu auch kernkonzepte-von-spring.html
Konkret wird die UserDetailsService Bean in Form einer Instanz von InMemoryUserDetailsManager bereitgestellt. Dem Konstruktor-Aufruf kann man dabei beliebig viele Benutzer Objekte übergeben (hier im Beispiel sind es nur 2). Alternativen zur Benutzerverwaltung im Speicher mittels InMemoryUserDetailsManager sind zum Beispiel JdbcUserDetailsManager oder CachingUserDetailsService.
Die beiden Benutzer wurden hier einfach im Java-Code erstellt. Benutzername und Password sind hier im Beispiel hardcoded - in der Praxis sollte man Credentials auch beim Verwalten der Benutzer im Speicher aus der Spring Konfiguration lesen.
Die Benutzer (Instanz von UserDetails) werden mittels UserBuilder (User.builder()) erstellt. Das Setzen von username, password und roles (bzw. der Aufruf der gleichnamigen Builder-Methoden) ist dabei Pflicht - alle anderen UserDetails Attribute sind optional. Rollen (roles) werde ich in einem künftigen Blog-Artikel vorstellen, den Demo-Code dazu findet ihr aber jetzt schon im GitHub-Repository zu diesem Artikel.
Das Passwort muss encodiert im UserBuilder gesetzt werden. Das mache ich mit der Bean PasswordEncoder, die eine einfache Instanz der BCryptPasswordEncoder Implementierungsklasse ist.

Nach einem Neustart der Spring Boot Applikation könnt ihr den Login mit beiden Benutzern testen, indem ihr die URL http://localhost:8080 jeweils in einem neuen Incognito Browser-Fenster öffnet. Da wir hier noch keine Logout-Funktion implementiert haben, empfehle ich zum Testen den Incognito Modus des Browsers.

Fazit & nächste Schritte

In diesem Blog-Artikel habe ich gezeigt, wie man Spring Security zu einem Spring Boot Projekt hinzufügen kann und was die Standard-Konfiguration von Spring Security mitbringt. In einem kleinen nächsten Schritt haben wir weitere Benutzer für unsere Spring Security abgesicherte Web-Anwendung erstellt.

Möchtet ihr tiefer in das Thema einsteigen? Dann schaut euch noch diese Artikel an:

Hinterlasst mir gerne einen Kommentar mit Fragen, Feedback oder Themen-Wünsche zu Spring Security.

Den kompletten hier vorgestellten Code mit einer Demo-Webanwendung findet ihr hier:

https://github.com/elmar-brauch/spring-security-webapp

Erfahrungsbericht Spring Boot 3 Update

noreply@blogger.com (Elmar Brauch - Microservice Master) — Thu, 16 Mar 2023 20:37:00 +0000

Unser Java-System ist jetzt mit Spring Boot Version 3 im produktiven Einsatz! Hier teile ich meinen Erfahrungsbericht, da sich Systeme in der echten Welt häufig von Demos oder Tutorials unterscheiden.

Highlights Spring Boot 3

Warum auf Spring Boot 3 und damit auf die Version 6 des Spring Frameworks updaten?

Spring 6 ist auf die aktuelle Java LTS Version 17 aktualisiert. Damit modernisiert Spring sich in erster Linie selbst, wovon wir indirekt profitieren.
Native Images mit GraalVM werden offiziell supported. Das ermöglicht unserer Spring Anwendung den blitzschnellen Start als Docker Container, siehe graalvm.html.
Viele direkt oder indirekt verwendete 3rd Party Bibliotheken sind auf neue Versionen aktualisiert. Wir bekommen damit diverse Fixes für Sicherheitslücken.

Planung des Spring Boot 3 Updates

Der Spring Boot 3.0 Migration Guide enthält im Wesentlichen diese Schritte:

Update auf Spring Boot 2.7
Update auf Java 17
Update auf Spring Boot 3
Dependencies anpassen
Code anpassen

Unsere Ausgangssituation war eine Spring Boot Anwendung in Version 2.7.X mit Java 17. Alle wesentlichen Dependency-Versionen managt Spring Boot für uns. Außerdem haben wir automatisierte Ende zu Ende Tests, die nach dem Update und der Beseitigung aller Compile-Fehler die Funktionalität unseres Systems schnell testen. Durch frühes Ausprobieren von Spring Boot 3 an einfachen Demo-Projekten wussten wir, dass die API Code Generatoren und die Spring Security Konfiguration Code-Anpassungen benötigen. Daher planten wir unser Spring Boot 3 Update so:

Umstellung des Maven Swagger Code Generator Plugins auf OpenAPI Code Generator.
Aktivierung des Spring Boot 3 Supports im OpenAPI Code Generator.
Zum Zeitpunkt unserer frühen Migration hatte der Swagger Code Generator Spring Boot 3 bzw. die jakarta Package imports nicht generiert. Hier hätten wir auch warten können.
Spring Boot Version 3.0.X in Maven Parent POM konfigurieren.
Code Anpassung jakarta statt javax Imports
Code Anpassung in Spring Security Konfiguration

Akzeptanz-Kriterium: Das Spring Boot 3 Update ist erst erfolgreich, wenn:

es keine Compile-Fehler gibt
alle JUnit-Tests erfolgreich durchlaufen
die CICD Pipeline alle Ende zu Ende Tests erfolgreich ausgeführt hat

Praktische Umsetzung des Spring Boot 3 Updates

Unser System wird seit über zwei Jahre von 6 EntwicklerInnen gebaut und befindet sich über ein Jahr im produktiven Einsatz. Daher bescherte uns die Umsetzung einige ungeplante Überraschungen. Diese Mehraufwände stelle ich im Folgenden thematisch gruppiert vor.

REST API Code Generator

Den Code für REST-APIs generieren wir mittlerweile mit dem OpenAPI Maven Plugin. Das grundsätzliche Vorgehen um den OpenAPI Code Generator mit Spring Boot 3 zu verwenden, stelle ich in diesem Artikel vor: openapi-codegen.html

Das Problem in der Praxis war, dass wir vom Swagger Code Generator auf den OpenAPI Code Generator wechseln mussten. Also nicht einfach nur eine neuere Version verwenden, sondern auch die Technologie austauschen. Für APIs in guter Qualität hat das problemlos funktioniert. Da unser System über 10 verschiedene REST-APIs benutzt, haben wir leider auch APIs in schlechter Qualität für die der OpenAPI Code Generator nur mit Spezial-Konfigurationen oder Workarounds funktioniert.

<groupId>org.openapitools</groupId>

<artifactId>openapi-generator-maven-plugin</artifactId>

<id>x-service</id>

<goals>

<goal>generate</goal>

</goals>

<generatorName>spring</generatorName>

...

<useSpringBoot3>true</useSpringBoot3>

</configOptions>

<skipValidateSpec>true</skipValidateSpec>

...

</configuration>

</execution>

...

Für Code Generierung mit Spring Boot 3 setzen wir <useSpringBoot3>
Schlechte API Qualität zwingt uns die Validierung der API Spezifikation im Maven Plugin zu überspringen: <skipValidateSpec>

SOAP API Code Generator

Unser System verwendet die SOAP API eines Legacy Systems. In unserer Planung hatten wir diese Schnittstelle vergessen. In der Praxis gab es das gleiche Problem wie beim Generieren der REST APIs unser Plugin unterstützt Spring Boot 3 noch nicht.

Die Lösung fanden wir im GitHub Projekt unseres maven-jaxb2-plugin. Dort wurde ein Plugin aus einem anderen Branch empfohlen. Ohne auf weitere Details der SOAP Code Generierung einzugehen, es sieht jetzt so aus:

<groupId>com.helger.maven</groupId>

<artifactId>jaxb40-maven-plugin</artifactId>

<goals>

<goal>generate</goal>

</goals>

</execution>

</executions>

<include>y-service.wsdl</include>

</schemaIncludes>

</configuration>

</plugin>

Code Anpassungen

Nach dem Spring Boot 3 Dependency Update zeigte der Compiler viele Fehler an. Erwartungsgemäß ersetzen wir dazu javax durch jakarta Imports - mit der Text suchen und ersetzen Funktion der IDE geht das recht schnell. Hier ein paar Beispiele:

~~import javax.servlet.http.HttpServletRequest;~~
import jakarta.servlet.http.HttpServletRequest;
~~import javax.annotation.PostConstruct;~~
import jakarta.annotation.PostConstruct;
~~import javax.validation.Valid;~~
import jakarta.validation.Valid;

Spring 6 führt das Interface HttpStatusCode neu ein. Dieses wird nun von diversen Klassen und Methoden im Spring Framework anstelle des enum HttpStatus verwendet. Das ist eine überschaubare Umstellung, weil HttpStatus das Interface HttpStatusCode implementiert. Trotzdem müsst ihr die Stellen im Code anpassen, welche jetzt nur noch das Interface zur Verfügung haben:

WebClient.create("url").get().retrieve()
~~.onStatus(HttpStatus::isError, ...)...~~
.onStatus(HttpStatusCode::isError, ...)...

Spring Security Code Anpassungen

Spring Security 6 entfernte Methoden und ersetzte sie durch neue. Dadurch entstehen beim Spring Boot 3 Update Compile Fehler. In meinem Einsteiger Artikel zu Spring Security 6 zeige und erkläre ich aktuellen Code, daher hier nur die Vorher-Nachher Gegenüberstellung:

@EnableWebSecurity

// Before @EnableWebSecurity included @Configuration

@Configuration

public class SecurityConfiguration {

@Bean

SecurityFilterChain securityFilterChain(HttpSecurity http) {

http.~~authorizeRequests()~~

http.authorizeHttpRequests()
.~~antMatchers~~("/secured").authenticated()

.requestMatchers("/secured").authenticated()

.anyRequest().permitAll()
...

Wir verwenden für manche API Tests Spring MockMvc. Diese Tests haben nach dem Spring Boot 3 Update das Problem, dass die Spring Security Filter automatisch angewendet werden und Requests wegen fehlender Authentifizierung ablehnen. Hier ein Vorher-Beispiel:

@SpringBootTest

@AutoConfigureMockMvc

class MockMvcTest {

@Autowired private MockMvc mvc;

@Test

void redirectTest() throws Exception {

mvc.perform(get("/secured"))

.andExpect(status().is3xxRedirection());

}

Anstelle des erwarteten Http Status 3XX lehnt die Spring SecurityFilterChain Bean den Request ab. Ein einfacher Weg die Security Filter zu entfernen, bietet das Attribut addFilters der Annotation @AutoConfigureMockMvc:

@SpringBootTest

@AutoConfigureMockMvc(addFilters = false)

class MockMvcTest { ...

Spring Web-Flow Workaround

Aus historischen Gründen verwendet unsere Anwendung Spring Web-Flow. Ich empfehle Spring Web-Flow nicht, weil es nach der Version 2.5.1 über 4 Jahre kein Update erhielt. Nach dem Update auf Spring Boot 3 kam es im Web-Flow Code zu Compile Fehlern. Zum Zeitpunkt dieses Artikels war Spring Web-Flow 3.0.0 passend zu Spring Boot 3 noch nicht im zentralen Maven Repository verfügbar. Um das Spring Boot 3 Update trotzdem durchführen zu können, entschieden wir uns Spring Web-Flow als Milestone Release 3.0.0-M1 zu verwenden. Dazu hinterlegen wir das Spring Milestone Repository als weiteres Maven Repository in der pom.xml:

<groupId>org.springframework.webflow</groupId>

<artifactId>spring-webflow</artifactId>

</dependency>

...

<id>spring-milestones</id>

<name>Spring Milestones</name>

<url>https://repo.spring.io/milestone</url>

<enabled>false</enabled>

</snapshots>

</repository>

</repositories>

Ein weiteres Problem lag im Zusammenspiel von Spring Security 6 und Spring Web-Flow 3. Mit Spring Security 5 gab es ein Default Attribute "ROLE_USER" im OpenID Connect Token. Dessen Existenz überprüften wir in der Spring Web-Flow 2.5.1 XML-Konfiguration so:

Nachdem Spring Security 6 Update gibt es andere Default Attribute. Eines hat den Namen "OIDC_USER". Trotz folgender Anpassung funktionierte die Token Überprüfung per XML-Konfiguration im Web-Flow nicht:

Der Grund dafür ist, dass Spring Web-Flow den Prefix "ROLE_" erwartet. Diesen Prefix gibt es aber in den Default Attributen des Tokens nicht mehr. Daher habe ich die Methode getRolePrefix() im RoleVoter überschrieben, um den Prefix "ROLE_" durch den leeren String "" zu ersetzen. Den RoleVoter setze ich im AccessDecisionManager des SecurityFlowExecutionListener, diesen hatten wir schon mit Spring Web-Flow 2.5.1 in einer Bean instanziiert.

@Bean

public FlowExecutor flowExecutor() {

var listener = new SecurityFlowExecutionListener();

listener.setAccessDecisionManager(new ConsensusBased(

List.of(

new RoleVoter() {

@Override

public String getRolePrefix() {

return "";

}

)

));

return getFlowExecutorBuilder(flowRegistry())

.addFlowExecutionListener(listener)

.build();

}

Fazit

Die Komplexität des Spring Boot 3 Updates hängt von der Größe eurer Anwendung und der Anzahl nicht durch Spring Boot gemanagter Bibliotheken ab. Insbesondere wenn die Bibliotheken dem aktuellen Stand der Technik hinterherhinken, wie in meinem Fall z. B. Spring Web-Flow, wird es kompliziert und dreckig.

Die Workarounds, frühe Beta-Versionen oder alternative Bibliotheken (hier OpenAPI statt Swagger Code Generator) zu verwenden, sind riskant. Dank vielen Unit-Tests und guten, automatisierten Ende zu Ende entschieden wir uns für das Update trotz der genannten Risiken. Heute profitieren wir von den Vorteilen der neusten Spring Version.

Vue.js Frontend mit Spring Boot Backend

noreply@blogger.com (Elmar Brauch - Microservice Master) — Mon, 06 Mar 2023 05:00:00 +0000

Vue.js ist eine schnelle und flexible JavaScript-basierte Frontend-Entwicklungsplattform. Durch intuitive Syntax und umfangreiche Bibliotheken ist es eine der besten Optionen für moderne Frontend-Entwicklung. Hier kombinieren wir es mit einem Spring Boot Backend!

Frontend und Backend im Zusammenspiel

Was bauen wir genau?

Wir programmieren ein modernes Frontend mit Vue.js.
Mit npm bauen wir das Frontend als produktionsbereites, kompaktes Artefakt.
Danach Kopieren wir es in unsere Spring Boot Anwendung, so dass es vom integrierten Application Server (z. B. Tomcat oder Netty) ausgeliefert wird.
Mit Spring Boot implementieren wir das Backend mit REST-API für das Vue.js Frontend.

Das folgende Bild zeigt die Struktur unseres Spring Boot Servers mit integriertem Vue.js Frontend. Zuerst lädt der Benutzer die komplette Frontend Anwendung im Browser. Sofern diese mit Vue.js als Single Page Application gebaut wurde, finden anschließend nur noch REST-Requests statt.

Frontend und Backend Entwicklung

Dieser Artikel konzentriert sich auf die Integration des Vue.js Frontend in das Spring Boot Backend.
Zum Entwickeln eines Frontend mit Vue.js schaut euch https://vuejs.org/ an.
Zum Programmieren vom Spring Backend findet ihr viele Artikel hier hier im Blog oder bei Udemy.

Frontend bauen und in Spring Boot integrieren

Nachdem ihr das Frontend in einem beliebigen Verzeichnis entwickelt und getestet habt, könnt ihr es für den produktiven Einsatz bauen. Öffnet dazu eine Shell im Frontend-Verzeichnis und führt den folgenden, fett markierten Befehl aus:

PS C:\<path to Vue.js project>\frontend> npm run build

> frontend@0.0.0 build

...
vite v4.1.2 building for production...

✓ 54 modules transformed.

dist/index.html 0.39 kB

dist/assets/index-638fb41c.js 85.25 kB │ gzip: 33.71 kB

Das Ergebnis des Bauen befindet sich im automatisch erstellten \dist Verzeichnis. Es ist eine transformierte und komprimierte Version des Frontend für den produktiven Einsatz.

Die Integration ins Spring Boot Projekt probieren wir einmalig von Hand aus. Dazu kopieren wir alle Dateien und Verzeichnisse im \dist Verzeichnis in das src\main\resources\public Verzeichnis des Spring Boot Projektes. Das public Verzeichnis erstellen wir vorab, das Verzeichnis resources sollte im neu generierten Spring Boot Projekt vorhanden sein.

Danach startet wir die Spring Boot Anwendung und öffnet sie im Browser. http://localhost:8080/index.html zeigt dann das Frontend.

Frontend und Backend mit Maven bauen

Maven Frontend Konfiguration

Meistens bauen wir aus unserer Spring Boot Anwendung eine ausführbare jar Datei. Dazu verwenden wir das Build Tool Maven. Zuerst muss das Frontend gebaut werden, die Maven Konfiguration pom.xml sieht so:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns=...>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>frontend</artifactId>

    <parent>
        <groupId>de.bsi</groupId>
        <artifactId>vue</artifactId>
        <version>0.2</version>
    </parent>

    <build>
        <plugins>
            <plugin>
                <groupId>com.github.eirslett</groupId>
                <artifactId>frontend-maven-plugin</artifactId>
                <version>1.12.1</version>
                <executions>
                    <execution>
                        <id>install node and npm</id>
                        <goals>
                            <goal>install-node-and-npm</goal>
                        </goals>
                        <configuration>
                            <nodeVersion>v16.17.0</nodeVersion>
                        </configuration>
                    </execution>
                    <execution>
                        <id>npm install</id>
                        <goals>
                            <goal>npm</goal>
                        </goals>
                        <phase>generate-resources</phase>
                        <configuration>
                            <arguments>install</arguments>
                        </configuration>
                    </execution>
                    <execution>
                        <id>npm run build</id>
                        <goals>
                            <goal>npm</goal>
                        </goals>
                        <configuration>
                            <arguments>run build</arguments>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Maven verwendet das Plugin frontend-maven-plugin zum Bauen der Vue.js Anwendung. Ausführliche Infos dazu gibt es hier: https://github.com/eirslett/frontend-maven-plugin
Die hier gezeigt Plugin Konfiguration lädt und installiert zuerst npm und nodejs.
Danach wird npm install ausgeführt, um die Packages für das Vue.js Frontend zu laden.
Im letzten Schritt wird das Frontend mit npm gebaut, so wie wir es im vorherigen Abschnitt von Hand gemacht haben. Das Plugin führt dazu den Befehl npm run build aus.
Die hier gezeigte Maven Konfiguration ist Teil eines Maven Multi-Module Projektes. Deshalb gibt es ein parent Tag.

Maven Parent Konfiguration

Das Parent Projekt bildet die Klammer, um das Frontend und Backend Maven Modul. Ohne Maven Parent Projekt, müsstet ihr Frontend und Backend getrennt bauen - also Maven 2 mal starten. Mit Parent Projekt startet ihr nur dessenn Maven Build. Der Build des Parent Projektes steuert die Maven Builds vom frontend und backend Modul.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns=...>
   <modelVersion>4.0.0</modelVersion>
   <parent>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>3.0.2</version>
      <relativePath/>
   </parent>
   <groupId>de.bsi</groupId>
   <artifactId>vue</artifactId>
   <version>0.2</version>
   <name>vue</name>
   <description>Demo project for Spring Boot with Vue.js</description>
   <packaging>pom</packaging>

   <modules>
      <module>frontend</module>
      <module>backend</module>
   </modules>
</project>

Das Parent Projekt ist ein Spring Boot Projekt (siehe parent Tag), so dass auch die beiden Module Spring Boot Projekte sind. Für das frontend Modul wäre das nicht nötig.
Der Maven Build baut entsprechend der Reihenfolge im XML erst das frontend und dann das backend Modul. Hinweis: Ein paralleler Build mit mehreren Threads würde hier Fehler produzieren.

Zur Verdeutlichung die Verzeichnisstruktur sieht in meinem Beispiel so aus:

vue (pom.xml für Maven parent Projekt)

backend (pom.xml für Maven Modul Spring Boot Backend)
frontend (pom.xml für Maven Modul Vue.js Frontend)

Maven Backend Konfiguration

Die Maven Konfiguration des Backend Moduls sieht so aus:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns=...>
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>de.bsi</groupId>
        <artifactId>vue</artifactId>
        <version>0.2</version>
    </parent>
    <artifactId>backend</artifactId>
    <version>0.2</version>
    <name>backend</name>
    <description>Backend implemented with Spring Boot Java stack.</description>
    <properties>
        <java.version>17</java.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>

            <plugin>
                <artifactId>maven-resources-plugin</artifactId>
                <executions>
                    <execution>
                        <id>copy Vue.js frontend content</id>
                        <phase>generate-resources</phase>
                        <goals>
                            <goal>copy-resources</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>src/main/resources/public</outputDirectory>
                            <overwrite>true</overwrite>
                            <resources>
                                <resource>
                                    <directory>${project.parent.basedir}/frontend/dist</directory>
                                </resource>
                            </resources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

backend und frontend Modul haben dasselbe Parent Projekt.
Es gibt ein besonderes Plugin, das maven-resources-plugin. Dieses kopiert das /dist Verzeichnis aus dem frontend Modul in das src/main/resources/public Verzeichnis des backend Moduls. Der eingebettete Application Server von Spring Boot liefert dann die statischen Frontend-Dateien aus diesem Verzeichnis aus, wie anfangs gezeigt.
Die restliche Maven Konfiguration des Backends entspricht herkömmlichen Spring Boot Projekten.

Abschluss

Mit mvn clean package bauen wir im Verzeichnis mit der parent POM das komplette Projekt. Die jar Datei im backend/target Verzeichnis enthält danach das Spring Boot Backend und das Frontend.

Das jar File könnten wir dann in einen Docker Container packen. Dann würde ein Docker Container Frontend und Backend ausliefern, so wie wir es von klassischen Web-Anwendungen kennen.

Den kompletten Code findet ihr in GitHub:

https://github.com/elmar-brauch/vue

OpenID Connect mit Spring Boot 3

noreply@blogger.com (Elmar Brauch - Microservice Master) — Fri, 24 Feb 2023 20:05:00 +0000

Authentifizierung mit OpenID Connect geht einfach dank Spring Boot. Wir bauen den Login Deiner Web-Anwendung mit dem Autorisierungsserver Deiner Firma. Wie wir dazu OpenID Connect mit Spring Boot 3 konfigurieren, zeige ich in diesem Blog-Artikel.

OpenID Connect - Authorization Code Prozess

OpenID Connect ist ein Single Sign-On Login-Verfahren. Zur Umsetzung komplexer Anwendungsfälle verwenden größere Firmen meist verteilte Systeme. Damit der Benutzer z. B. beim Online-Shopping den Systemwechsel von Produktseiten zum Einkaufswagen und zur Kasse nicht wahrnimmt, loggt er sich mittels Single Sign-On nur einmal ein. Die beteiligten Systeme authentifizieren den eingeloggten Benutzer anhand seiner Single Sign-On Session.

Detaillierte Informationen über OpenID Connect und Single Sign-On findet ihr hier. In diesem Artikel fokussiere ich mich auf das Anwendungs-System, welches zur Benutzer-Authentifizierung den firmeneigenen OpenID Identity Provider verwendet. Bevor wir uns die Implementierung mit Spring Boot und Spring Security anschauen, betrachten wir im folgenden Schaubild den vereinfachen OpenID Connect Ablauf.

Der Benutzer ruft eine URL unseres Spring Systems auf, die nur von eingeloggten Benutzern verwendet werden darf.
Der anonyme Benutzer wird von unserem System zum Single Sign-On an den OpenID Provider unserer Firma weitergeleitet.
Nach erfolgreichem Login z. B. mittels Benutzername und Passwort leitet der OpenID Provider den Benutzer an unserem System zurück. Als Beweis für den erfolgreichen Login enthält der Weiterleitungs-Request einen Authorization Code.
Unser System ruft nun den OAuth2 Token Endpunkt des OpenID Providers auf, um den Authorization Code gegen ein OpenID Token einzutauschen. Das OpenID Token ist im JWT Format und enthält Benutzer-Informationen und eine Signatur.
Nach erfolgreicher Validierung des OpenID Tokens gilt der Benutzer als authentifiziert und ist für die ursprünglich aufgerufene URL berechtigt.

Achtung Spoiler: Zur Umsetzung dieses Prozesses konfigurieren wir dank Spring Boot nur URLs und Credentials.

Englisches Video zum Artikel: Single Sign-On bei der Deutschen Telekom

Gradle Dependencies für OpenID Connect

Die Build-Dependencies managt Spring Boot für uns. Wir fügen nur die richtige Spring Boot Starter Dependency hinzu, um in unserem Projekt OpenID Connect zu nutzen. Mein Demo-Projekt ist eine Thymeleaf Web-Anwendung. Die Authentifizierung mit OpenID Connect benötigt nur die fett markierte Dependency - der Rest ist nur für meine Demo.

dependencies {

implementation 'org.springframework.boot:
spring-boot-starter-oauth2-client'

implementation 'org.springframework.boot:
spring-boot-starter-web'

implementation 'org.springframework.boot:
spring-boot-starter-thymeleaf'

...

Die benötigte Spring Security Dependency kommt automatisch mit der spring-boot-starter-oauth2-client Dependency.

Single Sign-On beim firmeneigenen OpenID Provider

Den Single Sign-On mit OpenID konfigurieren wir mit Spring Boot:

in der application.properties oder application.yml Datei in Form von Key-Value-Properties
und im Java Code durch die Definition einer SecurityFilterChain Bean.

Konfiguration in Spring Properties

Meine Firma, die Deutsche Telekom AG, hat ein eigenes Identity & Access Management System. (Fast) alle Systeme verwenden dieses IAM-System für Login bzw. Single Sign-On. Dazu agiert dieses IAM-System als OpenID Provider, den ich in der application.yml Datei als OpenID Connect Schnittstelle konfiguriere.

spring.security.oauth2.client:

provider:

sam:

issuer-uri: 'https://id.provider.de'

registration:

sam:

authorization-grant-type: authorization_code

client-id: id

client-secret: password

redirect-uri: 'http://localhost:8080/process-login'

scope: openid

sam ist der Name des Deutsche Telekom IAM-Systems. Ihr könnt einen beliebige andere Namen verwenden. Wenn ihr github, google oder facebook als IAM-System verwendet, braucht ihr nur client-id und client-secret zu setzen, da alles andere für diese wohlbekannten Identity-Provider in Spring Boot vorkonfiguriert ist.
client-id & client-secret sind die Credentials meines Systems beim OpenID Provider.
issuer-uri zeigt auf den OpenID Connect Discovery Endpunkt des OpenID Providers. Der Discovery Endpunkt zeigt dann z. B. alle weiteren URLs die beim OpenID Connect Verfahren verwendet werden. Diese müssen wir aufgrund der Öffentlichkeit des Discovery Endpunkts aber nicht extra in der Spring Konfiguration hinterlegen. Bei Google als OpenID Provider ist das der Discovery Endpunkt https://accounts.google.com/.well-known/openid-configuration - im JSON dieses Endpunktes steht die für Google zu verwendende issuer-uri "https://accounts.google.com".
scope und authorization-grant-type setze ich auf die oben gezeigte Werte, um OpenID Connect mit dem Authorization Code Prozess als Single Sign-On Verfahren festzulegen.
Nach erfolgreichem Login am OpenID Provider wird der Benutzer auf die in redirect-uri konfigurierte URL weitergeleitet. Diese URL muss auf unser System zeigen und mit der Login-Processing-URL übereinstimmen, die wir im nächsten Abschnitt in der SecurityFilterChain Bean setzen.

Authentifizierung mit SecurityFilterChain Bean

Die gesicherten URL-Pfade und den Login definieren wir im Java Code der SecurityFilterChain Bean.

@EnableWebSecurity

@Configuration

public class SecurityConfiguration {

@Bean

SecurityFilterChain securityFilterChain(

HttpSecurity http) throws Exception {

http.authorizeHttpRequests()

.requestMatchers("/secured").authenticated()

.anyRequest().permitAll();

http.oauth2Login(c -> {

c.loginProcessingUrl("/process-login");

c.loginPage("/oauth2/authorization/sam");

});

return http.build();

}

@EnableWebSecurity, SecurityFilterChain, HttpSecurity, authorizeHttpRequests, requestMatchers, authenticated, anyRequest und permitAll sind in meinem Artikel zu Spring Security erklärt. Zusammengefasst definiert der nicht fett markierte Java Code, dass die URL http://localhost:8080/secured einen eingeloggten Benutzer verlangt. Alle andern URLs können auch von anonymen Benutzern aufgerufen werden.
Mit Spring Boot 3 muss @Configuration gesetzt werden, damit die SecurityFilterChain Bean erzeugt wird.
Das OpenID Token zur Benutzer-Authentifikation wird mittels OAuth2 vom OpenID Provider geholt. Daher definieren wir mit der Methode oauth2Login einen OAuth2 basierten Login. Der Lambda Ausdruck als Parameter von oauth2Login legt weitere Details zum Login fest.
Die Login Seite befindet sich beim OpenID Provider. Sie wird von Spring über den OpenID Connect Discover Endpunkt ermittelt. loginPage legt die URL fest von der unser Spring Web-Application an den OpenID Provider Login weiterleitet, wenn sie den Prefix "/oauth2/authorization/" und den Postfix passend zum Key in der application.yml Datei hat - also hier "sam".
loginProcessingUrl ist die URL, welche den Redirect des OpenID Providers nach erfolgreichem Login verarbeitet. Diese URL muss aus Sicherheitsgründen auch am OpenID Provider konfiguriert sein.

Benutzerdaten im ID Token lesen

Nach erfolgreichem Login holt Spring Boot automatisch das OpenID Token vom Token-Endpunkt des OpenID Providers. Dazu ist nichts weiter nötig als die zuvor gezeigte Konfiguration. Um die Daten im OpenID Token zu lesen, lassen wir es uns per Annotation von Spring injizieren:

@GetMapping

public ModelAndView defaultPage(

@AuthenticationPrincipal OidcUser principal) {

String email = principal.getEmail();

Map<String, Object> attributes = principal.getAttributes();
...

Die defaultPage Methode befindet sich in einem Spring Controller und verarbeitet HTTP-Requests. Weitere Details zu Spring Controllern findet ihr hier: spring-mvc-thymeleaf.html
@AuthenticationPrincipal injiziert den eingeloggte Benutzer automatisch als OidcUser Objekt in unsere Methode.
Die OidcUser Klasse repräsentiert die Inhalte des OpenID Tokens. OidcUser bietet diverse Methode zum Auslesen der Daten im ID Token an.

Z. B. liefert getEmail die Email-Adresse des eingeloggten Benutzers.
getAttributes liefert alle Attribute im ID Token als Map.

Front-Channel Logout

In den vorherigen Abschnitten haben wir nur den Single Sign-On Login implementiert. Der Standard Logout von Spring melden den Benutzer nur in der Session der Spring Web-Application ab. Nach dem Standard Logout besteht immer noch eine Single Sign-On Session am OpenID Provider. Deshalb kann der "abgemeldete" Benutzer gesicherte URLs ohne erneuten Login direkt wieder verwenden. Um den Benutzer richtig abzumelden, machen wir im Zuge des Logouts zusätzlich einen Front-Channel Logout am OpenID Provider. Dazu ergänzen wir die SecurityFilterChain Bean wie folgt:

var rs = new DefaultRedirectStrategy();

http.logout()

.logoutRequestMatcher(new AntPathRequestMatcher("/logout"))

.logoutSuccessHandler(

(request, response, auth) -> rs.sendRedirect(
request, response, "https://id.provider.de/logout"));

Die Methode logout liefert uns den LogoutConfigurer. Mit diesem konfigurieren wir das Logout-Verhalten unser Spring Anwendung.
Für eine einfachere Demo lege ich fest, dass der Logout mit der URL /logout gestartet wird. Damit können auch HTTP GET Requests den Logout starten. Ohne die hier verwendete Methode logoutRequestMatcher wäre der Logout nur mit HTTP POST Requests möglich.
Front-Channel Logout bedeutet, dass wir den Logout auch am OpenID Provider machen. Das könnte wie hier mit einem einfachen Redirect zur Logout-URL des OpenID Providers passieren. Durch logoutSuccessHandler lege ich fest, dass dieser Redirect nach erfolgreichem Logout an unserer Spring Anwendung gestartet wird.

Fazit

Schaut euch noch mal das Schaubild zum OpenID Connect Prozess an. Trotz der Komplexität dieses Prozesses benötigen wir in unser Spring Boot Anwendung fast keinen eigenen Code. Das ist für mich die große Stärke von Spring Boot - Autokonfiguration und Starter Dependencies schenken uns eine einfache Lösung. Entsprechend eurer Security-Anforderungen könnt ihr diese Standard-Lösung für eure Firma anpassen. Achtet aber darauf, dass der Standard erkennbar bleibt, so dass der Single Sign-On Prozess eurer Anwendung wartbar bleibt.

Den Code zum Artikel findet ihr bei GitHub:

https://github.com/elmar-brauch/spring-security-webapp/tree/openid

Streams vs. Loops in Java

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sun, 19 Feb 2023 12:46:00 +0000

Java's Stream API ist eine mächtige Alternative zu Schleifen. Modernere, reaktive Programmierung setzt voll auf Streams. Hier stelle ich Streams und Loops gegenüber, indem ich die gleiche Aufgabe mittels Stream und Schleife löse.

Java Streams API

Ein Stream ist ein Datenstrom. Mit der Java Stream API können Objekte in Datenströmen analysiert, bearbeitet, gefiltert und umgewandelt werden. Ich stelle mir Stream gerne als Fließband vor. Die Objekte werden von einer Quelle (z.B. List) auf das Fließband gepackt und durchlaufen verschiedene Stationen, an denen sie bearbeitet werden. Zum Abschluss werden sie in ein Ergebnis gepackt (z.B. neue List), welches dann im weiteren Programmcode benutzt werden kann.

Fließband: Stream der analogen Welt

Intermediate Operations

Zum Bearbeiten der Objekte im Stream gibt es sogenannte "intermediate Operations", die im Stream Interface definiert sind:

filter - entfernt Objekte aus dem Stream
map - wandelt Objekte um
peek - erlaubt Bearbeitung des Objekts und lässt es im Stream
distinct - entfernt gleiche Objekte aus dem Stream
flatMap - löst Collections innerhalb des Streams auf
sorted - sortiert die Objekte im Stream
skip - überspring Objekte
limit - begrenzt die Anzahl der bearbeitenden Objekte im Stream

Die intermediate Operationen können in beliebiger Menge und Reihenfolge auf die Objekte im Stream angewendet werden - dazu zeige ich weiter unten Beispiele.

Terminal Operations

Terminal Operations beenden die Verarbeitung der Daten im Stream und produzieren ein Ergebnis:

forEach - bearbeitet jedes Objekt ein letztes Mal
collect - sammelt die Objekte am Ende des Streams z.B. in einer Liste
toArray - sammelt die Objekte am Ende des Streams in einem Array
min / max - findet das Minimum / Maximum Objekt im Stream.
count - zählt die Elemente am Ende des Streams.
reduce - reduziert alle Elemente am Ende des Streams zu einem einzelnen Ergebnis
anyMatch / allMatch / noneMatch - liefert ein Boolean Ergebnis bezüglich der Daten im Stream
findFirst / findAny - liefert als Ergebnis des Streams ein Optional mit dem gefunden Element

Streams erlauben nur eine Terminal Operation, die den Stream beendet. Danach liefert der Stream keine Daten mehr und kann auch nicht mehr benutzt werden.

Video zum Artikel

Streams vs. Loops Code Beispiele

Im folgenden zeige ich einige doppelt implementierte Methoden. Eine Version verwendet Schleifen und die andere Streams mit Lambda-Ausdrücken - weitere Infos zu Lambdas findet ihr hier: lambda.html

Beispiel 1: map & collect

Zuerst wird die Liste itemNames mit der Methode stream() in einen Stream<String> umgewandelt - in allen folgenden Beispielen ist dies immer der erste Schritt. Danach wandelt die Methode map jeden String im Stream mit der funktionalen Methode generateItem in ein Objekt vom Typ Item um. Die abschließende Terminal Operation collect wandelt den Stream in eine neue Item-Liste um und speichert diese im Attribut items, welches in den folgenden Beispielen verwenden wird.

final List<String> itemNames = List.of("Ardbeg", "Lagavulin",
        "Jim Beam", "Teeling", "Jameson", "Johnny Walker");
List<Item> items;

void prepareDemoData() {
    Function<String, Item> generateItem = 
            name -> new Item(name, name.length());
    items = itemNames.stream()
            .map(generateItem).collect(Collectors.toList());
}

Im Beispiel mit Schleife muss das Attribut items zu Beginn instanziiert werden.

void prepareDemoData() {
    items = new ArrayList<>();
    for (var name : itemNames)
        items.add(new Item(name, name.length()));
}

Beispiel 2: sorted & forEach

Zum Sortieren der zuvor generierten items-Liste muss die Item Klasse in dieser Schleifen-Variante das Interface Comparable implementieren.

List<Item> sortAndPrintItems() {
    Collections.sort(items);
    for (var item : items)
        System.out.println(item);
    return items;
}

Die Stream-Variante verwendet sorted zum Sortieren der Elemente im Stream. Die Klasse Item müsste hier nicht das Interface Comparable implementieren, weil wir den Lambda-Ausdruck compareByName an sorted übergeben. Comparator ist ein funktionales Interface zum Festlegen der Sortierreihenfolge. Die Terminal Operation forEach funktioniert analog zur for-each-Schleife und wird auf jedes Element im Stream angewendet. In beiden Beispielen werden die Item Objekte in der gleichen Reihenfolge in die Konsole geschrieben. Die ursprüngliche Liste items bleibt allerdings in der Stream-Variante unverändert, da die Sortierung hier nur im Stream passiert und nicht in der Quelle.

List<Item> sortAndPrintItems() {
    Comparator<Item> compareByName = (a, b) -> a.name().compareTo(b.name());
    items.stream().sorted(compareByName).forEach(System.out::println);
    return items;
}

Beispiel 3: filter & count

Bestimmt habt ihr schon Elemente in einer Liste gezählt, welche spezielle Bedingungen erfüllen. Die klassische Schleifen-Variante sieht dazu so aus:

long countItemsById(int id) {
    long counter = 0;
    for (var item : items)
        if (item.id() == id)
            counter++;
    return counter;
}

Mit der Stream API schreiben wir solche Operationen deutlich kompakter. Die filter Methode ersetzt das if-Statement und die Terminal Operation count übernimmt das Zählen.

long countItemsById(int id) {
    return items.stream().filter(it -> it.id() == id).count();
}

Beispiel 4: filter, peek & findFirst

Im nächsten Beispiel sind 2 Operationen in einer Methode vermischt:

Wir suchen das Item in der Liste, dessen name Attribut den übergebenen Substring enthält.
Außerdem loggen wir die Position des gefunden Item in der Liste. Daher verwende ich hier auch die klassische for-Schleife.
Um NullPointerExceptions zu vermeiden, geben wir einen Optional zurück, siehe dazu auch https://dzone.com/articles/optional-in-java.

Optional<Item> findBySubstringAndCountPosition(String substring) {
    for (int i = 0; i < items.size(); i++) {
        var item = items.get(i);
        if (item.name().contains(substring)) {
            System.out.println("Loop: Item found at position: " + i);
            return Optional.of(item);
        }
    }
    return Optional.empty();
}

Zum Ausführen mehrerer Operationen auf einem Stream-Element verwenden wir die peek Methode. Das if-Statement wird erneut mittels filter Methode umgesetzt.

Optional<Item> findBySubstringAndCountPosition1(String substring) {
    final var counter = new ThreadLocal<Integer>();
    counter.set(0);

    return items.stream()
            .peek(i -> counter.set(counter.get() + 1))
            .filter(it -> it.name().contains(substring))
            .peek(i -> System.out.println(
                    "Stream: Item found at position: " + counter.get()))
            .findFirst();
}

Da peek einen Lambda-Ausdruck als Eingabe benötigt und Lambda-Ausdrücke nur auf (effektiv) finalen Variablen arbeiten können, packe ich den Integer zum Zählen der Position in ein ThreadLocal Objekt.
In diesem Fall gefällt mir die Schleifen-Variante besser. Generell ist es im Stream nicht möglich auf Elemente an bestimmten Positionen zuzugreifen. Bei Schleifen mit Index i ist der Zugriff auf bestimmte Elemente aus der Liste (oder einem Array) kein Problem.
Die Terminal Operation findFirst vereinfacht die Rückgabe, da sie entweder einen leeren oder einen Optional mit dem gefunden Element zurückgibt. Darum müssen wir uns in der Stream-Variante nicht kümmern.

Beispiel 5: noneMatch, allMatch & anyMatch

In den letzten Beispielen stelle ich nur die Stream-Variante vor, da es Code-Ausschnitte meines Unit-Test sind.

assertTrue(items.stream().noneMatch(it -> it.id() < 0));
assertFalse(items.stream().allMatch(it -> it.id() < 0));
assertTrue(items.stream().anyMatch(it -> it.id() > 0));

Die erste Assertion prüft mit dem noneMatch, dass kein einziges Element im Stream eine Id kleiner 0 hat.
Der allMatch in der zweiten Assertion ist das Gegenteil, daher verwende ich hier assertFalse statt assertTrue.
Mit anyMatch prüfe ich, dass mindestens ein Element eine Id größer 0 hat - in unserer items Liste wäre hier auch allMatch möglich, da alle Ids größer 0 sind, siehe Beispiel 1.

Beispiel 6: collect mit groupingBy

Im letzten Beispiel verwende ich die groupingBy Methode der Klasse Collectors innerhalb der Terminal Operation collect. groupingBy entsprich von der Funktionalität dem GROUP BY Statement aus SQL, siehe https://www.w3schools.com/sql/sql_groupby.asp.

items.stream().collect(Collectors.groupingBy(Item::id)).forEach(
        (group, elements) -> System.out.println(group + " : " + elements));

Die Item Objekte innerhalb des Stream sortiert die collect Methode mit Hilfe des Collectors in eine Map<Integer, List<Item>> ein. Die Konsolen Ausgabe sieht dann so aus:

6 : [Item[name=Ardbeg, id=6]]
7 : [Item[name=Teeling, id=7], Item[name=Jameson, id=7]]
8 : [Item[name=Jim Beam, id=8]]
9 : [Item[name=Lagavulin, id=9]]
13 : [Item[name=Johnny Walker, id=13]]

Da 2 Item-Objekte die gleiche Id 7 haben, befinden sie sich in der selben Gruppe. Alle anderen Gruppen haben nur ein Item.

Parallele Bearbeitung von Streams

Die parallele Verarbeitung der Daten im Stream kann mit einer einzigen Methode der Stream API gestartet werden:

items.stream().parallel().forEach(System.out::println);

Die Methode parallel wandelt den Stream in einen parallelen Stream um, der von mehreren Threads bearbeitet wird. Das Schöne ist: Wir müssen uns nicht um die Threads kümmern - das macht Java für uns! Alternativ können wir direkt einen parallelen Stream erzeugen:

items.parallelStream().forEach(System.out::println);

Fazit

Streams und Schleifen sind gleich mächtig, verwenden aber unterschiedliche Stile:

Schleifen basieren auf dem imperativen Programmierstil, bei dem jeder Schritt festgelegt wird.
Streams basieren auf der funktionalen Programmierung. Daher bietet die Stream API Methoden an, deren Implementierung wir nicht kennen müssen. Wir beschreiben mit Lambda-Ausdrücken nur das Ergebnis.

Vermutlich sind mehr EntwicklerInnen mit dem imperativen Programmieren vertraut als mit dem funktionalen. Da die Stream API sich immer mehr verbreitet (siehe z.B. reaktive Programmierung webflux.html) und sehr wichtig ist, solltet Ihr beides beherrschen.

Den hier gezeigten Code findet ihr in GitHub:

https://github.com/elmar-brauch/java16/tree/master/src/main/java/de/bsi/stream

ChatGPT Chatbot in Java Web-Anwendung integrieren

noreply@blogger.com (Elmar Brauch - Microservice Master) — Fri, 27 Jan 2023 07:00:00 +0000

Wie integrierst Du eine künstliche Intelligenz als Chatbot in Deine Web-Anwendung? Am einfachsten indem Du die GPT-3 API benutzt. Hier zeige ich, wie es mit Java funktioniert.

OpenAI Account und API Key

OpenAI bietet die GPT-3 API an, die auch ChatGPT verwendet. Willst Du sie nutzen? Dann geht es vor dem eigentlichen Programmieren in Java so los:

Eigenen Account auf https://openai.com/ erstellen.
Einloggen und eigenen API Key erstellen:
https://beta.openai.com/account/api-keys
Der API Key berechtigt Deine Anwendung die GPT-3 API zu nutzen.

Bei YouTube findet ihr ein englisches und deutsches Video passend zu diesem Blog-Artikel.

How-To use GPT-3 API video in English

GPT-3 API mit Java HttpClient aufrufen

Die GPT-3 API kann mit jeder Programmiersprache bzw. jedem HTTP Client verwendet werden. Ich zeige euch hier, wie es mit dem HttpClient von Java funktioniert.

String postBody =

"""

{

"prompt": "Code in Java to print first 20 Fibonacci numbers",

"max_tokens": 300,

"model": "text-davinci-003",

"temperature": 0.7

}

""";

var request = HttpRequest.newBuilder()

.uri(URI.create("https://api.openai.com/v1/completions"))

.header("Content-Type", "application/json")

.header("Authorization", "Bearer " + OPENAI_API_KEY)

.POST(BodyPublishers.ofString(postBody))

.build();

var client = HttpClient.newHttpClient();

var resp = client.send(request,HttpResponse.BodyHandlers.ofString());

System.out.println(resp.body());

Wir definieren einen String postBody im JSON Format entsprechend der OpenAI API Dokumentation. Dieser String enthält im prompt die Nachricht bzw. hier die Programmieraufgabe die wir an die Chatbot API schicken. Die anderen JSON Attribute sind ausführlich in der API Dokumentation beschrieben: https://beta.openai.com/docs/api-reference/completions
HttpClient.newHttpClient() erzeugt die Instanz des Java HTTP Clients zum Verschicken eines HTTP Requests.
Den eigentlichen HttpRequest bauen wir mit einem Builder. Hier verwende ich nur die nötigsten Attribute des HttpRequests:

Die Internet-Addresse mit uri
Der Content-Type Header legt fest, dass wir einen JSON Text übertragen.
Der Authorization Header überträgt unseren API Key als Bearer Token.
Der POST Request Body bestehend aus unseren JSON String.

Mit der send Methode schicken wir den POST Request ab und legen fest, dass der Response Body als String eingelesen wird. Die Antwort ist dann ein JSON, welches wir in die Console schreiben:

{

"id": "cmpl-6aVIuAySr6W83S0xvbCgq2RUNc3hQ",

"object": "text_completion",

"created": 1674158160,

"model": "text-davinci-003",

"choices": [

{

"text": "public class Fibonacci {...",

"index": 0,

"logprobs": null,

"finish_reason": "stop"

}

"usage": {

"prompt_tokens": 11,

"completion_tokens": 131,

"total_tokens": 142

}

Die Antwort der künstlichen Intelligenz befindet sich im Attribut text innerhalb der Liste choices. Den Java Code für die Fibonacci Folge habe ich hier gekürzt - probiert es selbst aus, um ihn komplett zu sehen.

Wenn ihr die GPT-3 API in einer Spring Web-Anwendungen sehen wollt, schaut euch einfach mein Projekt bei GitHub https://github.com/elmar-brauch/openai-api an. Dort nutze ich zusätzlich das Spring Framework, um eine Thymeleaf Web-Anwendung mit Chatbot zu bauen.

Fazit

ChatGPT bzw. die GPT-3 API ist eine beeindruckende künstliche Intelligenz. Es macht wirklich Spaß sie zu benutzen. Leider kostet jeder API Aufruf - daher werden auch die Token-Attribute im Request und der Response gesetzt, um die genauen Kosten transparent zu machen. Zum Ausprobieren gibt es aber ein kostenloses Startkapital.

Asynchroner, gepufferter Nachrichten-Austausch mit RabbitMQ und Spring

noreply@blogger.com (Elmar Brauch - Microservice Master) — Mon, 16 Jan 2023 06:52:00 +0000

RabbitMQ ist ein Nachrichten-Broker mit integrierter Queue zur asynchronen Kommunikation zwischen Services. Der Produzenten-Service übergibt Nachrichten an RabbitMQ ohne auf den Konsumenten-Service zu warten. Der Konsument holt sich Nachrichten aus der RabbitMQ Queue nach Bedarf und kann so nicht vom Produzent mit Nachrichten überflutet werden. Hier zeige ich die Spring AMQP Implementierung zur RabbitMQ Integration.

Vorteile des asynchronen, gepufferten Nachrichten-Austauschs

Nachrichten Produzent und Konsument müssen nicht aufeinander warten. Wenn der Produzent z. B. für den Benutzer einen Auftrag erstellt, muss der Benutzer nicht warten bis der Konsument den Auftrag erfolgreich verarbeitet hat. Der Produzent übergibt die Nachricht an die RabbitMQ Queue und kann dem Benutzer danach eine Erfolgsmeldung anzeigen. Das ist insbesondere bei lang andauernden Auftragsverarbeitungen im Backend (Konsument) angenehm für den Benutzer, da er nicht warten muss. Der Konsument könnte den Benutzer später per Email über die erfolgreiche Verarbeitung des Auftrags informieren.
Die RabbitMQ Queue dient auch als Puffer zwischen Produzent und Konsument. Wenn innerhalb kurzer Zeit viele Nachrichten produziert werden, können diese in der Queue gesammelt werden. Der Konsument holt sich dann die Nachrichten in seinem Tempo aus der Queue und bricht so auf keinen Fall unter Überlast zusammen.
Wenn Produzent und Konsument als Dienste in der Cloud betrieben werden, könnte die Skalierung dieser Dienste anhand des Füllstandes in der RabbitMQ Queue gemanagt werden. Bei einer vollen Queue könnten Konsumenten Dienste hoch skaliert werden, während sie bei einer sich leerenden Queue herunter skaliert werden. Wir können also Ressourcen effizient nutzen.

RabbitMQ im Docker Container starten

Zum schnellen Ausprobieren bietet sich RabbitMQ im Docker Container an. Wir starten RabbitMQ mit Management UI, damit wir die Queues im Browser prüfen können:

docker run -d -p 15672:15672 -p 5672:5672 rabbitmq:3-management

15672 ist der Management UI Port, den wir mittels Port Weiterleitung erreichbar machen. Mit dieser URL können wir das Management UI im Browser öffenen:
http://localhost:15672/
Benutzername und Password zum Login ist: guest / guest
5672 ist der RabbitMQ Port, den unsere Spring Anwendung verwenden wird.
Weitere Details zu Docker findet ihr hier.

RabbitMQ Management UI

Nachrichten-Produzenten Implementierung

Maven & Spring Property Konfiguration

Bevor die Implementierung des Produzenten startet, benötigen wir die Spring Starter Dependency von Spring AMQP. Hier der entsprechende Ausschnitt aus der Maven Konfiguration:

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-amqp</artifactId>

</dependency>

Außerdem konfigurieren wir in der Spring Properties-Datei application.yml die Verbindung zum RabbitMQ Server:

spring.rabbitmq:

host: localhost

port: 5672

password: guest

username: guest

Produzenten Implementierung

Die Implementierung des Produzenten ist eine Spring Bean, welche Comment Objekte an RabbitMQ schickt:

@Service

public class CommentProducerService {

@Autowired private RabbitTemplate rabbitTemplate;

public void createComment() {

var comment = Comment.builder()

.message("New comment message created")

.author("Elmar")

.createdAt(LocalDateTime.now())

.build();

rabbitTemplate.convertAndSend(

"comments",

comment);

}

...

RabbitTemplate wird automatisch durch die Spring Boot Starter Dependency erzeugt.
convertAndSend schickt die Instanz der Klasse Comment zum RabbitMQ Server in die Queue mit dem Namen "comments". Diese Queue erzeugt ihr vorher im Management UI oder verwendet den Administrationscode weiter unten.
Die Klasse Comment ist ein Java POJO mit 2 String und einem LocalDateTime Attribute. Für die Instanziierung verwende ich einen Builder anstelle von Konstruktor und Setter-Methoden.

Nachrichten Serialisierung

Wenn wir die Nachrichten im gängigen JSON Format zur RabbitMQ Queue schicken wollen, müssen wir einen entsprechenden Konverter konfigurieren. Dazu erzeugen wir eine Spring Bean vom Typ Jackson2JsonMessageConverter:

@Configuration

public class RabbitmqConfig {

@Bean

SmartMessageConverter messageConverter() {

return new Jackson2JsonMessageConverter(objectMapper());

}

@Bean

ObjectMapper objectMapper() {

var mapper = new ObjectMapper();

mapper.registerModule(new JavaTimeModule());

return mapper;

}

Die Jackson2JsonMessageConverter Bean benötigt eine ObjectMapper Instanz zum Schreiben von Nachrichten-Objekten als AMQP JSON Nachrichten.
Beim ObjectMapper musste das JavaTimeModule registriert werden, weil unsere Nachrichten Klasse Comment den Java 8 Datumstyp LocalDateTime verwendet.

Konsument an Queue registrieren

Der Konsument benötigt zur Deserialisierung der Comment Nachrichten die gleichen Konverter Beans wie der Produzent. Das Konsumieren von RabbitMQ Nachrichten aus einer Queue ist mit noch weniger Code als das Produzieren zu implementieren:

@RabbitListener(queues = "comments")

@Component

@Slf4j

public class CommentConsumerService {

@RabbitHandler

public void readComments(Comment comment) {

log.info(comment.toString());

}

...

Die Annotation @RabbitListener definiert die Bean CommentConsumerService als Konsument der Queue mit dem Namen "comments".
Die Annotation @RabbitHandler legt fest, dass die Methode readComments Nachrichten des Typs Comment verarbeitet. Würde die Queue "comment" zusätzlich einfache String Objekte als Nachrichten enthalten, könnten diese von einer 2. Methode mit @RabbitHandler Annotation und String Parameter verarbeitet werden.
Die readComments Methode loggt hier lediglich die konsumierte Comment Nachricht.

RabbitMQ administrieren mit Spring

Spring bietet uns die Möglichkeit den RabbitMQ Nachrichten-Broker per Code zu administrieren. Hier zeige ich euch, wie ihr ohne Management UI eine neue Nachrichten Queue erstellt:

@Configuration

public class RabbitmqConfig {

@Bean

RabbitAdmin createRabbitAdminAndInitQueue(

RabbitTemplate rabbitTemplate) {

var admin = new RabbitAdmin(rabbitTemplate);

if (admin.getQueueInfo("comments") != null)

admin.purgeQueue("comments");

else

admin.declareQueue(

QueueBuilder.durable("comments").build());

return admin;

}

...

RabbitAdmin ist die Bean zur Administration von RabbitMQ. Die Verbindung wird durch den Parameter RabbitTemplate festgelegt - wie auch schon zuvor beim Nachrichten Produzent.
getQueueInfo verwende ich hier nur zum Prüfen, ob die Queue "comments" schon existiert.
purgeQueue löscht alle Nachrichten in einer Queue.
declareQueue erzeugt eine neue Queue basierend auf dem übergebenen Parameter. Die neue Queue wurde hier als dauerhafte Queue mit dem Namen "comments" definiert. Der QueueBuilder bietet natürlich noch weitere Optionen an, schaut euch dazu die public Methoden an.

Fazit

Die Vorteile von RabbitMQ bzw. eines Nachrichten-Brokers mit Queue habe ich am Anfang des Artikels bereits aufgelistet. In den Code Beispielen habe ich gezeigt, wie viel Programmierarbeit uns Spring abnimmt, da wir vieles per Konfiguration und Annotation einrichten können.

Weitere Details zu Spring Integration findet ihr hier:
https://spring.io/projects/spring-integration

Den kompletten Code zum Artikel findet ihr in GitHub:
https://github.com/elmar-brauch/rabbitmq

REST-API mit OpenAPI Spezifikation und Swagger generieren

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sat, 07 Jan 2023 09:54:00 +0000

REST-APIs können als OpenAPI Spezifikation menschen- und maschinenlesbar beschrieben werden. Die maschinenlesbare OpenAPI Spezifikation (vormals bekannt als Swagger Spezifikation) dient Code-Generatoren als Vorlage zum Generieren von Client- oder Server-Code in viele verschiedenen Programmiersprachen. Neben den Basics zeige ich euch hier, wie man den Code-Generator mit Maven verwendet, um API Implementierung und Spezifikation immer synchron zu halten.

API first & Code Generatoren

Beim API first Konzept geht es darum, dass man von Anfang an, die API im Scope der Entwicklung hat. Die API wird vor der Implementierung definiert und kann auch schon mit anderen Teams ausgetauscht werden, welche den Service über die API nutzen. Wird die API als OpenAPI Spezifikation im json oder yaml Format definiert, können mehrere Teams den Client-Code zeitgleich mit der Service-Implementierung entwickeln.

Als Unterstützung für den API first Ansatz gibt es Code Generatoren, die für euch ein Client SDK zum Benutzen einer API in diversen Programmiersprachen oder Server Stubs im gewünschten Technologie Stack generieren.

Das generierte Client SDK ist sicherlich eine gute Starthilfe, wenn ihr mit einer für euch neuen Programmiersprache arbeitet oder generell noch nicht so erfahren im Programmieren von REST-Aufrufen seid. Wie es ohne Code Generator mit OAuth2-Absicherung funktioniert, zeige ich z.B. hier: spring-oauth.html.

Beim generierten Server Stub solltet ihr beachten, dass vom Generator der erste Technologie-Stack eures Services festgelegt wird. Dabei sollte man aus meiner Sicht vorsichtig sein, da der generierte Technologie-Stack häufig leicht veraltet ist und man z.B. mit Spring Boot, die Dependencies deutlich aufgeräumter pflegen kann. Daher bevorzuge ich bei einfachen APIs die Projekt Generatoren des gewählten Frameworks, z.B. https://start.spring.io/ für Spring.

Der generierte Code an sich ist je nach Programmiersprache gut lesbar (siehe z.B. Modell Klassen in Kotlin) oder voll von Boilerplate Code (siehe z.B. Modell Klassen in Java). Es ist sehr wichtig, dass ihr den generierten Code getrennt von eurem restlichen Code behandelt. Generierter Code sollte immer nur vom Generator geschrieben und nicht vom Entwickler angepasst werden. Daher hat dieser Artikel 2 Teile:

Code Generatoren für Einsteiger: Swagger Editor, OpenApi & Swagger CodeGen. Probiert die Generatoren aus, schaut euch genau an was ihr bekommt und überlegt euch, ob das eurer Startpunkt für die Entwicklung sein soll oder nicht. Ein Versuch kann auch nicht schaden.
Code Generatoren als Maven Plugin (in die CICD Pipeline integriert): In dieser Variante begeistern mich die Code Generatoren, da API Spezifikation und API Code immer synchron bleiben! Überspring ruhig die nächsten beiden Abschnitte, wenn es euch in erster Linie, um diese Variante geht.

Swagger Editor: Online Code Generator

Wenn ihr eine OpenAPI Spezifikation habt, könnt ihr euch den Client-Code bzw. ein Client SDK automatisch generieren lassen. Der schnellste Weg dazu ist der Swagger Editor, eine Webseite zum Bearbeiten von API Spezifikationen und zur Online Code Generation.

https://editor.swagger.io/

Einfach json oder yaml Datei links im Editor laden, dann sollten (im kompatiblen Browser) die beiden beiden Menu-Punkte "Generate Server" und "Generate Client" erscheinen mit denen ihr den Code in der Programmiersprache bzw. dem Framework (z.B. Spring oder Micronaut) eurer Wahl generieren könnt.

Swagger & OpenAPI Code Generator

Beim Swagger Editor hat man leider keine Möglichkeiten die Generation des Codes zu konfigurieren. Man kann nur die Programmiersprache oder das Framework auswählen, aber z.B. nicht in welchem Package sich die generierten Java-Klassen befinden sollen. Mit Swagger Codegen kann man das tun, siehe dazu https://github.com/swagger-api/swagger-codegen#readme.

Der OpenAPI Code Generator ist ein alternatives Projekt zum Generieren von Code anhand einer OpenAPI Spezifikation, das auf eine frühere Version des Swagger Code Generators aufsetzt. Weitere Details dazu findet ihr hier: https://github.com/OpenAPITools/openapi-generator/blob/master/README.md

In beiden Links findet ihr einen Link, um ein ausführbares jar-File herunterzuladen, mit dem ihr dann ein Client SDK oder einen Server Stub generieren könnt. Mit folgendem Befehl könnt ihr z.B. einen Kotlin Server Stub erstellen:

   java -jar openapi-generator-cli-6.2.1.jar generate \
       -i ./openapi.yaml \
       -g kotlin-server \
       -o petstore

java -jar führt eine ausführbare jar-Datei aus. Die openapi-generator-cli-6.2.1.jar ist in der zuvor verlinkten README.md verlinkt. (In Zukunft gibt es hier bestimmt neuere Versionen als 6.2.1, den Befehl dann entsprechen anpassen.)
generate ist der Befehl zum Generieren von Code. help wäre eine Alternative zum Anzeigen des Hilfetextes.
-i ./openapi.yaml zeigt an, wo die OpenAPI Spezifikation ist. Ich habe die Datei openapi.yaml einfach aus dem https://editor.swagger.io/ geladen, um dann die API des Demo Projektes Petstore zum Testen zu haben.
Mit -g kann man festlegen, was man generieren möchte. kotlin-server generiert einen Kotlin Server Stub. Alternativen und viele weitere Details findet ihr hier:
https://github.com/OpenAPITools/openapi-generator/wiki/Server-stub-generator-HOWTO
-o legt den Speicherort des generierten Codes fest.

Hier noch ein 2. Beispiel bei dem ich einen Spring Server Stub in Java generiere und zusätzlich eine Konfigurationsdatei config.json übergebe. In der Konfigurationsdatei habe ich exemplarisch das Package für die generierten Java-Klassen selbst definiert.

java -jar openapi-generator-cli-6.2.1.jar generate \
       -i ./openapi.yaml \
       -g spring \
       -o ./petstore2 \
      -c ./config.json

cat ./config.json
{"basePackage":"de.bsi.petstore"}

Weitere Konfigurationsparameter findet ihr in den zuvor verlinkten How-To Artikel oder im nächsten Abschnitt beim Einsatz als Maven Plugin.
Die jar-Datei des Swagger Code Generators wird übrigens analog bedient.

Code Generatoren als Maven Plugin

Der Swagger und der OpenAPI Code Generator können auch als Maven Plugin in den Build Prozess und in die CICD Pipeline integriert werden. Entscheidend dafür ist die Maven Konfiguration in der pom.xml Datei. In meinem Demo-Projekt zu diesem Artikel lasse ich die Modell Klassen anhand der Petstore OpenAPI Spezifikation generieren. Das funktioniert mit dieser Plugin-Konfiguration innerhalb der pom.xml:

<plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>6.2.1</version>
    <executions>
        <execution>
	    <goals>
		<goal>generate</goal>
	    </goals>
	    <configuration>
		<inputSpec>${project.basedir}/src/main/resources/petstore-openapi.yaml</inputSpec>
		<generatorName>spring</generatorName>
		<configOptions>
		    <sourceFolder>petstore</sourceFolder>
		    <dateLibrary>java8</dateLibrary>
		    <useSpringBoot3>true</useSpringBoot3>
		</configOptions>
		<modelPackage>de.bsi.openapi.petstore.model</modelPackage>
		<generateModels>true</generateModels>
		<generateApis>false</generateApis>
		<generateSupportingFiles>false</generateSupportingFiles>
	    </configuration>
	</execution>
    </executions>
</plugin>

Wie bei Maven Dependencies legen groupId, atifactId und version das zu verwendende Plugin fest. Hier könnten wir auch als alternatives Plugin den Swagger Code Generator verwenden:
<groupId>io.swagger.codegen.v3</groupId>
<artifactId>swagger-codegen-maven-plugin</artifactId><version>3.0.36</version>
Das würde wenige, zusätzliche Anpassungen an den verwendeten Konfigurations-Parametern erfordern. Da der Swagger Code-Generator im Januar 2023 Spring Boot in der Version 3 nicht unterstützt, habe ich mich hier für den OpenAPI Code-Generator entschieden.
Mit useSpringBoot3 wird die Code Generierung kompatible zu Spring Boot Version 3 aktiviert.
Durch das Goal generate wird das Plugin in der generate-sources Phase des Maven Lifecycles ausgeführt, siehe auch https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html.
inputSpec verweist auf die OpenAPI Spezifikation und entspricht dem -i Parameter aus dem vorherigen Abschnitt.
generatorName legt fest was generiert werden soll und entspricht dem -g Parameter.
Innerhalb des target/generated-sources/openapi Verzeichnisses werden die generierten Klassen gespeichert. Mit dem Parameter sourceFolder wird noch ein weiterer Teil des Pfades spezifiziert, indem sich dann die package Verzeichnisse befinden.
modelPackage legt den package Namen der generierten Modell Klassen fest. Da ich nur Modell Klassen generiere, benutze ich hier nur diesen Parameter zum Festlegen von package Namen.
generateModels, generateApis und generateSupportingFiles definieren was generiert werden soll. In meinem Beispiel nur die Modell Klassen der OpenAPI Spezifikation, daher sind die beiden anderen Parameter auf false gesetzt.
Java 17 wird Stand Januar 2023 von beiden Code Generatoren unterstützt.

Die anderen Parameter und weiter führende Erklärungen zu den Maven Plugins findet ihr hier:

Für Eclipse habe ich den Maven Build mit diesen Goals durchgeführt:
mvn clean package eclipse:eclipse.

Die beiden Goals clean und package löschen zuerst die alten Builds und Bauen dann neu, dabei wird auch das Swagger Codegen Plugin ausgeführt.
Mit eclipse:eclipse fügt ihr die generierten Sourcen innerhalb des target Verzeichnisses der Projekt Source Konfiguration hinzu, so dass die generierten Klassen in der IDE auch direkt genutzt werden können (das könnte man auch in den Projekt Properties im Java Build Path von Hand konfigurieren).
In IntelliJ funktioniert das automatisch.

Weitere Dependencies und Controller

Die restlichen Dependencies in der Maven Konfiguration ergeben sich aus den generierten Klassen und dem von euch gewünschten Technologie-Stack. Mein Demo-Projekt zu diesem Artikel findet ihr hier: https://github.com/elmar-brauch/openapi-codegen

Mir war es wichtig, dass ich auf die Spring reactive Bibliotheken aufsetze, siehe dazu webflux.html. Damit die generierten Modell Klassen kompilieren, musste ich noch eine weitere Dependency aufnehmen:

<groupId>org.springdoc</groupId>

<artifactId>springdoc-openapi-starter-webflux-ui</artifactId>

</dependency>

<groupId>org.openapitools</groupId>

<artifactId>jackson-databind-nullable</artifactId>

</dependency>

Die Java-Klassen und JUnit Tests zum Demo-Projekt zeigen, dass selbst geschriebener Code und generierter Code nicht im Konflikt zueinander stehen. Wiederholtes Generieren der Modell Klassen macht keine Controller Klassen kaputt. Controller Klassen generiere ich nicht mit meiner Maven Plugin Konfiguration, da ich die Vorteile der reaktiven Programmierung nutzen möchte.

Fazit

Wenn ich Code Generatoren verwende sind mir folgende Punkte wichtig:

Moderner Technologie Stack, der zu den Bedürfnissen des Teams passt (und nicht zu 100% aus dem Code Generator abgeleitet ist).
Integration in die CICD Pipeline.
API Spezifikation und generierter Code müssen automatisiert synchron gehalten werden.
Keine händisches Anpassen des generierten Codes, um z.B. Compile-Fehler zu beseitigen.

Im hier gezeigten Demo-Projekt sind diese Punkte erfüllt, so dass ich mit dem Code Generator zufrieden bin. Allerdings gefallen mir auch einige Punkte nicht so gut:

Die hier generierten Java Modell Klassen haben unnötig viel Boilerplate Code. Ich fände es besser, wenn der Code Generator diese z.B. mit Lombok Annotationen oder Java 14 Records vermieden hätte.

Lohnt sich die Verwendung des Code Generators?
Ja, wenn ihr die OpenAPI Spezifikation zuerst erstellt (API first) und wenn eure Modell relativ viele Klassen hat. Die API Modelle der Microservices in meinem Team sind deutlich umfangreicher als beim hier gezeigte Petstore. Daher setzen wir die Code Generatoren auch in der Praxis ein.

Spring Security 6: Login, Logout & Rollen

noreply@blogger.com (Elmar Brauch - Microservice Master) — Sun, 01 Jan 2023 06:55:00 +0000

Spring Security ermöglicht Login und Logout für Web-Anwendungen in wenigen Konfigurationsschritten. Mit Spring Security sichern wir einzelne Webseiten oder API-Endpunkte so ab, dass nur authentifizierte Benutzer mit festgelegten Rollen zugreifen können. Wie funktioniert das? Lest weiter!

Hinweis: Für einen ersten Einblick zu Spring Security, schaut euch gerne meinen Einsteiger-Artikel an. Dort seht ihr wie Spring Security zum Spring Boot hinzugefügt wird und wie Benutzer mit Rollen definiert werden.

Abgesicherte und frei zugängliche Seiten

Die Spring Security Starter Dependency ist ohne weitere Konfiguration produktionsbereit, da sie alles absichert. Nur eingeloggte Benutzer haben Zugang. Um anonymen Benutzern bestimmte Seiten zugänglich zu machen, müssen wir die Authentifizierung und den Default Login anpassen.

@Configuration

@EnableWebSecurity

public class SecurityConfiguration {

@Bean

SecurityFilterChain authenticatedAndFreePagesWithLogin(

HttpSecurity http) throws Exception {

return http.authorizeHttpRequests()

.requestMatchers("/admin").authenticated()

.anyRequest().permitAll()

.and().formLogin()

.and().build();

}

...

Eine eigene SecurityFilterChain Bean ermöglicht uns in die Security Filter-Kette von Spring einzugreifen und Default Einstellungen zu ändern. Diese Änderungen konfigurieren wir am HttpSecurity Objekt für Web-Anwendungen. Die build Methode des HttpSecurity Objektes erzeugt eine neue DefaultSecurityFilterChain Instanz. Die Bean Definition findet in einer mit @EnableWebSecurity und @Configuration annotierten Klasse statt.
http.authorizeHttpRequests().requestMatchers("/admin").authenticated() legt fest, dass der Pfad /admin nur für authentifizierte Benutzer zugänglich ist.
Seit dem Update auf Spring Security 6 müssen die Methoden authorizeHttpRequests anstatt authorizeRequests und requestMatchers anstatt antMatchers verwendet werden.
.anyRequest().permitAll() gibt anonymen und eingeloggten Benutzer Zugang auf allen anderen URL-Pfaden. Ohne .requestMatchers("/admin").authenticated() wäre unsere komplette Web-Anwendung offen bzw. ohne Absicherung nutzbar.
.and() gibt uns immer wieder das HttpSecurity Objekt zurück, so dass wir weitere Konfigurationen vornehmen können. Alternativ könnten wir statt .and() zu verwenden auch ein neues Statement mit dem HttpSecurity Objekt beginnen.
.formLogin() aktiviert den Default Login von Spring Security. Wenn ein anonymer Benutzer eine mit .authenticated() abgesicherte URL (hier /admin) aufruft, findet ein Redirect zur Default Login Seite statt. Die Default URL der Login-Seite ist /login - Anpassungen sind natürlich möglich.

Logout anpassen - aber wie?

Mit dem Login bekommen wir automatisch einen Logout, den wir über den Pfad /logout erreichen. Im Browser sieht es wie folgt aus:

Bei Bedarf konfigurieren wir den Logout ebenfalls in der SecurityFilterChain Bean.
Beispielsweise legen wir fest, welche URL nach erfolgreichem Logout aufgerufen wird:

...

.and().formLogin()

.and().logout().logoutSuccessUrl("/index")

Zugriff nur mit autorisierter Rolle

Bis jetzt hat jeder eingeloggte Benutzer Zugriff auf die /admin Seite. Das ändern wir im nächsten Schritt, so dass nur noch Administratoren auf diese Seite zugreifen. Dazu definieren wir, dass nur die Rolle ADMIN für die /admin Seite berechtigt ist. Normale Benutzer haben hier nur die Rolle USER - ihnen ist der Zugriff verboten. Schauen wir uns zuerst die Benutzer und deren Rollen an.

@Bean

UserDetailsService users(@Autowired PasswordEncoder pwEnc) {

UserDetails user = User.builder()

.username("user")

.password(pwEnc.encode("top"))

.roles("USER")

.build();

UserDetails admin = User.builder()

.username("admin")

.password(pwEnc.encode("secret"))

.roles("USER", "ADMIN")

.build();

return new InMemoryUserDetailsManager(user, admin);

}

Die UserDetailsService Bean und ihre Alternativen erkläre ich im ersten Spring Security Artikel.
Wichtig: In UserDetails Objekten legen wir sowohl Credentials als auch Rollen der Benutzer fest. Dabei kann ein Benutzer mehrere Rollen bekommen. Das sind dann die einzelnen String Parameter der Methode roles.

Jetzt sichern wir die /admin Seite durch die Rollenüberprüfung ab. Dazu konfigurieren wir in unserer SecurityFilterChain Bean die folgende fett markierte Stelle:

@Bean

SecurityFilterChain authenticatedAndFreePagesWithLogin(

HttpSecurity http) throws Exception {

return http.authorizeHttpRequests()

.requestMatchers("/admin").hasRole("ADMIN")

.anyRequest().permitAll()

.and().formLogin()

.and().build();

}

Der Methodenaufruf von .authenticated() wurde durch .hasRole("ADMIN") ersetzt. Dabei wird die Rolle ADMIN wird als String Parameter übergeben. Der Methodenaufruf .requestMatchers("/admin") legt fest, an welchen URL-Pfaden die Rolle ADMIN überprüft wird.
Logt ihr euch als Benutzer "user" ein und öffnet im Browser die Seite http://localhost:8080/admin, bekommt ihr den HTTP Status-Code 403 mit "Forbidden" Nachricht. Denn nur mit USER Rolle und ohne ADMIN Rolle habt ihr in diesem Testfall keine Zugriffsrechte.
Hinweis: Der HTTP Status Code 403 befindet sich auf einer Whitelabel Error Page, da ich hier keine eigenen Fehlerseiten verwende.

Fazit

So leicht steigen wir mit Spring Security in die Themen Login, Logout und Rollenmanagement ein. Spring Security ist ein anpassbares Framework. Ihr könnt beispielsweise eigene Login und Logout Seiten hinterlegen oder andere Verfahren wie OpenId Connect einsetzen, siehe dazu auch OpenID Connect mit Spring Boot.

Spring Security hat eine sichere Default-Konfiguration. Damit kommen wir nach kurzer Adaption schnell zu einen sicheren Produktivsystem.

Das Update auf Spring Security 6 habe ich mit dem Spring Boot Update auf Version 3.0.0 gemacht. Da in Spring Security 6 deprecated Methoden (z. B. antMatchers) entfernt wurden, musste ich Code Anpassungen vornehmen. Den kompletten Code und die Spring Security 6 Code Anpassungen findet ihr in GitHub bzw. in der Git-Historie: https://github.com/elmar-brauch/spring-security-webapp.git

Agile Coding mit Java, Kotlin, Spring und Microservices

Java 25: Die wichtigsten Features seit Version 21

Java 25 Features

Performance Tuning durch Versionsupdate

Module Import

Keine Klasse und vereinfachte main-Methode

Unbenannte Variablen

Kommentare in Markdown

Flexible Konstruktor-Bodies

Stream Gatherers

fold

scan

mapConcurrent

Scoped Values

Fazit

Lessons Learned – von der Idee bis zum Go-Live unseres KI-Chatbots

KI in Java? Geht – und zwar ziemlich gut

MVP statt Feature-Wildwuchs

Klare Kennzeichnung: UX beginnt beim Icon

Guter Chatbot ≠ komplexer Chatbot

Sicherheit, Kostenkontrolle und Guardrails

Lernen durch echte Chats

Chatbots mit KI Hilfe testen

Vektor-Datenbanken: Einfach reicht oft

Fazit

GIT Einführung und Best Practices

Zentraler Zugriff auf den Code

Nachvollziehbarkeit von Änderungen

Sicherheit durch Versionierung

Git Basics – Die wichtigsten Konzepte

Repository

Commit und Push

Pull

Branch

Merge

Log und History

GIT im täglichen Einsatz & Best Practices

Git Kommandozeile oder Tools

Bei kleinen Änderung

Pull first

Review vor Commit & Push

Gute Commit-Message mit Ticket-Referenz

Ein Commit – eine Änderung

Revert statt Löschen

Große Änderung mit feature-Branches

Rebase

Empfehlung: Merge mit Squash

Git Blame - wer war es?

Git Diff - was hat sich genau geändert?

Tags

Fazit

Testgetriebene Entwicklung (TDD) Schritt für Schritt

Testgetriebene Entwicklung (TDD)

Rot - Test schlägt fehl

Grün - Implementierung des Testfalls

Blau - Refactoring

TDD Schritt für Schritt Demo

1. Zyklus: ROT

Vorab habe ich nur ein leeres Projekt erstellt. Der Test bowlingGame schlägt tatsächlich fehl, weil die Klasse Game zu diesem Zeitpunkt noch nicht existiert - also rot wegen Compile-Fehler.

1. Zyklus: GRÜN

Das ist die minimale Implementierung, um den Test aus dem ersten Zyklus grün zu bekommen...Den optionalen Refactoring Schritt können wir überspringen.

2. Zyklus: ROT

2. Zyklus: GRÜN

3. Zyklus: ROT

3. Zyklus: GRÜN

Nachträgliche Anmerkung: Für pinsRolled ein Array der Größe 21 zu verwenden, ist zu diesem Zeitpunkt zu früh und ein Verstoß gegen das Prinzip den minimales Code zu schreiben. Ein einfacher Int reicht in diesem Zyklus.

3. Zyklus: BLAU

4. Zyklus: ROT

4. Zyklus: GRÜN

4. Zyklus: BLAU

5. Zyklus: ROT

5. Zyklus: GRÜN

Die restlichen Zyklen...

Auswirkungen von KI auf testgetriebene Entwicklung

KI als Testgenerator

Unterstützung in Phase GRÜN

Hilfe beim Refactoring

KI-Driven Development als Anti-Pattern?

Fazit

Spring Boot vs. Security Vulnerabilities

Das ist die minimale Implementierung, um den Test aus dem ersten Zyklus grün zu bekommen...
Den optionalen Refactoring Schritt können wir überspringen.