OpenID Connect und OAuth2 sind vielleicht etwas moderner und hipper als das bereits etwas in die Jahre gekommene SAML 2 Protokoll. Soll jedoch im Enterpriseumfeld eine Anwendung in bestehende Landschaften integriert werden, führt selten ein Weg an SAML 2 vorbei. Das gilt um so stärker, wenn es sich um eine Branche mit hohem Sicherheitsbedarf wie Luftfahrt, Banken oder Versicherungen handelt.

Keycloak hat sich als zuverlässige und gleichzeitig sehr leicht zugängliche Plattform zur Umsetzung von OpenID Connect oder SAML erwiesen. Dabei kann Keycloak sowohl produktiv eingesetzt werden, als auch sehr komfortabel als lokale Testumgebung für Entwicklung und Test verwendet werden. Zur Integration von Keycloak in Spring Boot existieren neben einem Keycloak Modul auch Spring-Security-SAML bzw. OAuth2 Client und Resourceserver.

Gerade wenn es um das Thema Security geht, bringen automatisierte Tests ein wichtiges Sicherheitsnetz für die Software. Wir wollen Keycloak als SAML 2 IdP verwenden und mit einer Spring Boot Anwendung Authentifizierung mit SAML 2 als Beispielanwendung für automatisierte Integrationstests verwenden. Ein - relativ einfacher - Weg wäre, Keycloak als Docker Container im Rahmen der CI-Pipeline mit Jenkins, Bamboo oder GitLab-CI bereitzustellen, so dass die zu testende Software darauf zugreifen kann. Allerding verliert man damit die Möglichkeit, die Tests lokal genauso zu entwickeln und zu validieren, wie sie nachher in der Buildserver Umgebung laufen.

Eine Alternative stellen Testcontainers dar. Die allgemeine Verwendung von Testcontainers wurde bereits in Testcontainers mit JUnit 5 erläutert. Nun schauen wir uns an, wie Keycloak, Testcontainers und Spring Boot SAML 2 zusammen eingesetzt werden kann.

Regelmäßig kommt in unseren Docker Schulungen Verwunderung auf, wenn wir Beispiele zum Einsatz von Containern im Entwicklungsprozess aufzeigen. Denn Container bzw. Docker bringt gerade da auch immense Vorteile: Neben einer möglichen Parität zwischen Produktionsumgebung und Entwicklersystem ist es gerade die sehr einfache Möglichkeit, Umsysteme als Container bereitzustellen.

Das kann für einen Frontendentwickler das Backend sein, für einen Backendentwickler kann es die richtige Datenbank, Message-Queue oder ein anderer (Micro-)Service sein.
Verfügen aktuelle IDEs in der Regel über Docker-Integration oder wird docker-compose eingesetzt, stellt sich die Frage, wie in CI-Umgebungen Container für Integrationstests am besten eingesetzt werden können. Hier hat das Projekt Testcontainers eine Lösung ins Rennen geschickt: Durch eine gelungene Abstraktion lassen sich Container sehr leicht in Tests verwalten und zusammen mit den Tests orchestrieren. Container-Typen und Versionen werden gemeinsam mit dem Testcode versioniert, was die Wartung und Refactoring erleichtert. Auch ein häufiges Problem, nämlich auf den erfolgreichen Start eines Containers bzw. des damit bereitgestellten Dienstes zu warten, wird gut gelöst.

Testcontainers gibt es für verschiedene Programmiersprachen bzw. Plattformen. Wir schauen uns im folgenden einmal die Umsetzung für Java speziell im Kontext von JUnit 5 genauer an.

Bei der PHP Usergroup Münster stellte Thomas Kruse vor, welche Optionen gRPC für die Entwicklung und Integration von Microservices bietet.

Wie können moderne APIs unter Berücksichtigung von Web Anwendungen definiert und implementiert werden?
Diese Frage stellt sich vor allem bei Microservice Architekturen, wenn viele unterschiedliche Dienste miteinander integriert werden.

Als eine Option stellte Thomas Kruse bei dem Meetup "Frontend Freunde" vor, wie dies auf Basis von gRPC umgesetzt werden kann und welche Implikationen sich ergeben.

Im Backend hat sich der Architekturstil "Microservices" für viele Anwendungsbereiche durchgesetzt. Dabei stellt sich relativ schnell die Frage: Wie geht man mit dem Thema Frontend um?

In dem Vortrag "Frontend Architektur für Microservices" gab Thomas Kruse auf der W-JAX 2019 in München einen Überblick zu verschiedenen Herangehensweisen.
Der Vortrag zeigt die speziellen Herausforderungen, die sich aus einer guten Benutzbarkeit von Frontends für Microservices ergeben.

Durch aktuelle Entwicklungen im Bereich von WebComponents und modularer SPA Frameworks ergeben sich zusätzliche Architekturoptionen, die in dem Vortrag bewertet wurden.

Bei dem Meetup Digital Innovation Ruhr behandelte Thomas Kruse in seinem Vortrag "Frontend Architektur für Microservices" verschiedene Architektur Optionen, um mit den Herausforderungen des Frontends bei einer Microservice Architektur umzugehen.

Für den Vortrag wurden die Erfahrungen aus verschiedenen Projekten in einem zeitlichen und technologischen Kontext eingeordnet und liefern damit Entscheidungshilfen für Architekten, die sich mit dem Thema Frontend im Microservice Kontext befassen.

Ein besonderes Augenmerk wurde dabei auf den Systemschnitt aus der Perspektive des Frontends und des Nutzers gelegt, der in der Regel eine integrierte Oberfläche ohne Brüche im Prozess erwartet.

Dank aktueller Entwicklungen eignen sich inzwischen Webcomponents für bestimmte Aufgabenstellungen und wurden mit einem Beispiel auf Basis von Angular Elements praktisch demonstriert.

Karsten Sitterberg stellte auf der Jax 2019 in Mainz in seinem Vortrag "Effektives Testen von Browseranwendungen" Technologien und Frameworks vor. Der Überblick wurde dabei durch Tipps und Best-Practices für die Erstellung von wartbaren Tests ergänzt.

Frontend Architektur im Kontext von Microservices behandelt Thomas Kruse in seinem Vortrag auf der Jax 2019. Der Vortrag zeigt die speziellen Herausforderungen, die sich aus einer guten Benutzbarkeit von Frontends für Microservices, ergeben.

Für den Vortrag wurden die Erfahrungen aus verschiedenen Projekten in einem zeitlichen und technologischen Kontext eingeordnet und liefern damit Entscheidungshilfen für Architekten, die sich mit dem Thema Frontend im Microservice Kontext befassen. Dank aktueller Entwicklungen eignen sich inzwischen Webcomponents für bestimmte Aufgabenstellungen und wurden mit einem Beispiel auf Basis von Angular Elements praktisch demonstriert.

Bei der Java User Group Münster stellte Karsten Sitterberg Technologien und Frameworks zum Testen von Browser-Anwendungen vor. Der Überblick wurde dabei durch Tipps und Best-Practices für die Erstellung von wartbaren Tests ergänzt.

Auf der "JavaLand" Konferenz in Brühl präsentierte Thomas Kruse Architekturvarianten für Microservices. Für den Vortrag wurden die Erfahrungen aus verschiedenen Projekten in einem zeitlichen und technologischen Kontext eingeordnet und liefern damit Entscheidungshilfen für Architekten, die sich mit dem Thema Frontend im Microservice Kontext befassen.

Dank aktueller Entwicklungen eignen sich inzwischen Webcomponents für bestimmte Aufgabenstellungen und wurden mit einem Beispiel auf Basis von Angular Elements praktisch demonstriert.

gRPC hat bisher vor allem im Backend oder bei der direkten Kommunikation zwischen Anwendungen auf dem Endgrät und dem Backend eine Rolle gespielt. Aufgrund der zunehmenden Rolle von Browseranwendungen sollte gRPC auch in clientseitigen Webanwendungen genutzt werden können.
Das zugehörige Projekt ist gRPC-Web: https://github.com/grpc/grpc-web

In diesem Beitrag wurde die Erstellung eines Spring Boot gRPC Backends demonstriert. Nun get es darum, das Backend in einer Angular Webanwendung mit gRPC-Web anzubinden.

In verteilten Systemen, zu denen etwa solche mit Microservice- und Cloud-Architekturen zählen, müssen in der Regel über Anwendungsgrenzen hinweg Funktionsaufrufe erfolgen. Typischerweise kommt dabei für synchrone Aufrufe HTTP als Transportschicht zum Einsatz, das Format der ausgetauschten Daten kann XML, JSON oder eine andere spezifische Datenstruktur sein. Welche HTTP-Verben und welche Adressen (URLs) wie zu verwenden sind, ist dabei eine fast schon in philosophische Bereiche ausufernde Debatte zwischen den verschiedenen Ansätzen. Am häufigsten finden sich REST und Abwandlungen davon als Schnittstellenkonzept.

Im Gegensatz zu der reichhaltigen API-Oberfläche von REST findet sich SOAP als XML-basiertes RPC- (Remote-Procedure-Call-) Verfahren, bei dem lediglich HTTP POST-Requests zum Einsatz kommen. Neben dem oft als schwerfällig bezeichneten Vorgehen von Design und Implementierung von SOAP-Schnittstellen hat XML als Transportformat auch deutliche Auswirkungen auf möglichen Durchsatz und erforderliche CPU- und Speicherresourcen bei der Verarbeitung.

Als Alternative zu diesen Ansätzen hat Google gRPC entwickelt: gRPC setzt ebenfalls auf HTTP auf, verwendet jedoch Google Protocol Buffers als optimiertes Datenformat. Wie der Einsatz im Kontext einer Java-Spring-Boot-Anwendung aussehen kann, wird im Folgenden dargestellt.