Architecture & Microservices on JAVAPRO Germany

Url-Shortener - Redirect-Statistiken - Teil 2

Thu, 09 Apr 2026 07:05:03 +0000

Die Vaadin-UI-Komponenten im Detail

In diesem Teil geht es nun weiter mit der Implementierung von den Redirect-Statistiken in dem Open Source Tool URL-Shortener. Den ersten Teil findest Du hier: https://3g3.eu/Hfzsf3

Die Quelltexte findest Du auf GitHub unter https://3g3.eu/url

Die Komponentenarchitektur

Die Vaadin-UI für die Statistik-Funktionalität besteht aus mehreren eng verzahnten, aber bewusst entkoppelten Komponenten. Im Zentrum stehen zwei Views: die StatisticsView als Übersichtsseite und die StatisticsDetailView für die Analyse einzelner ShortCodes. Beide nutzen die wiederverwendbare StatisticsToolbar für Datumsauswahl und Granularitätssteuerung. Diese Trennung folgt dem Prinzip der Komposition über Vererbung – ein Muster, das sich in Vaadin-Anwendungen bewährt hat.

Großes Kino für Java-Entwickler & Architekten

Wed, 08 Apr 2026 12:00:36 +0000

JCON EUROPE 2026 | 20. bis 23. April 2026 | Cinedom in Köln

Wer heute über moderne Softwareentwicklung spricht, spricht zwangsläufig über Java. Kaum eine Technologie prägt die Enterprise-Welt so nachhaltig – und kaum eine Community ist gleichzeitig so lebendig, vielfältig und innovationsgetrieben. Genau hier setzt die JCON an: als Treffpunkt, als Plattform und als Erlebnisraum für Entwicklerinnen und Entwickler aus der ganzen Welt. Mit Teilnehmern aus über 70 Ländern hat sich die JCON längst zu einem internationalen Treffpunkt entwickelt. Dabei bleiben Offenheit, Wissensaustausch und Community-Gedanke zentrale Elemente.

DevOps-Patterns und Java 26 für On-Premises LLM-Plattformen in sicherheitskritischen Umgebungen

Mon, 06 Apr 2026 07:00:00 +0000

Während die erste Welle der KI-Adoption in vielen Organisationen auf Cloud-APIs setzte, ist dieser Ansatz in sicherheitskritischen und regulierten Umgebungen häufig nicht nutzbar. Vertraulichkeitsanforderungen, Datenschutzvorgaben und der Bedarf an technisch durchsetzbaren Betriebsgrenzen stehen dem entgegen. In On-Premises-Setups erweitert sich die Architektur um zusätzliche Laufzeitkomponenten, etwa LLM-Serving, Retrieval und Wissensartefakte wie Indizes und Prompts. Der Fokus verschiebt sich damit von der reinen Modellnutzung zur Plattformfrage: Wie lassen sich Datenzugriffe und Berechtigungen entlang der Pipeline kontrollieren? Wie bleiben Änderungen an Modellen, Prompts und Indizes nachvollziehbar? Und wie lassen sich Fehlerfälle reproduzierbar eingrenzen und zurückrollen?

Von Spaghetti zu Hexagonen: Ein praktischer Leitfaden zur sauberen Java-Architektur

Mon, 16 Feb 2026 07:02:42 +0000

Eine kulinarische Warnung und die dunkle Seite des Codes

Willkommen, Mitarchitekt und geschätzter Entwickler, in unserem hexagonalen Stadtstaat – einem Reich, in dem Pragmatismus suprema regiert und Flexibilität unsere größte Stärke ist. Dieser Leitfaden ist keine Elfenbeinturm-Doktrin voller theoretischer Perfektion, sondern vielmehr ein vielseitiges Werkzeugarsenal, das in der Schmiede realer Herausforderungen und unzähliger Produktionsschlachten geschmiedet wurde.

Bevor wir die Zitadelle der sauberen Architektur errichten können, müssen wir zunächst die Realität unserer Branche anerkennen. Wir müssen die „Dunkle Seite des Codes“ navigieren. Die Softwarewelt ist voll von kulinarischen Katastrophen, die einen Koch zum Weinen bringen würden. Wir alle kennen Spaghetti-Code^(1), ein verworrenes Durcheinander, in dem der Programmfluss sich wie Pasta windet und dreht, sodass die Wartung zu einem Albtraum wird, bei dem Referenzen und Abhängigkeiten überall hin springen. Doch das Menü der Katastrophen ist umfangreich.

Beyond UML: Saubere Software-Architektur im Zeitalter von KI‑generiertem Code

Mon, 02 Feb 2026 07:01:37 +0000

Abstract

Wir schreiben heute mehr Code in kürzerer Zeit als jemals zuvor. KI‑Systeme agieren dabei wie ständig verfügbare Juniorprogrammierer: Sie produzieren in Minuten tausende Zeilen Code – aber wer übernimmt dabei die Verantwortung für die Software-Architektur?

Das eigentliche Problem ist daher oft nicht „schlechter KI‑Code“, sondern die wachsende Schwierigkeit für Menschen, den Überblick zu behalten und fundierte Architekturentscheidungen zu treffen.

Dieser Artikel diskutiert eine Idee, um schnell ein mentales Modell von vorhandenem Code aufzubauen, Architekturprobleme früh zu erkennen und Änderungen gezielt vorzunehmen – ohne parallel eine statische Dokumentation pflegen zu müssen.

Java 26 übernimmt HTTP/3 mit der Weiterentwicklung des HttpClient

Mon, 19 Jan 2026 07:00:49 +0000

die Zukunft der Kommunikation zwischen Microservices

Moderne verteilte Architekturen, wie etwa Microservices, sind eng mit der Weiterentwicklung von Netzwerkprotokollen verknüpft. Da sich Microservice-Architekturen als der vorherrschende Ansatz für den Aufbau skalierbarer und resilienter Anwendungen etabliert haben, ist die Effizienz der Service-zu-Service-Kommunikation zu einem zentralen Anliegen geworden.

Obwohl HTTP/1.1 und HTTP/2 bedeutende Verbesserungen brachten, wie etwa persistente Verbindungen und Request-Multiplexing, waren sie weiterhin grundsätzlich durch ihre Abhängigkeit von TCP eingeschränkt. In Netzwerken mit hoher Latenz oder Instabilität können diese Einschränkungen nach wie vor zu Leistungseinbußen, erhöhter Tail-Latenz und geringerer Resilienz unter Last führen. Mit JEP 517 führt Java 26 Unterstützung für HTTP/3 im HttpClient ein und ermöglicht damit QUIC-basierte Kommunikation. Sehen wir uns an, was sich mit HTTP/3 ändert.

Adventskalender – 2025 –Persistence – Teil 02

Fri, 05 Dec 2025 07:05:13 +0000

Heute werden wir den StoreIndicator final in die UI integrieren.

Der Quelltext für diese Version befindet sich auf GitHub unter https://github.com/svenruppert/url-shortener/tree/feature/advent-2025-day-02

Hier ist der Screenshot der Version, die wir nun implementieren.

Vaadin-Integration: Live-Status des Stores

Nachdem die Kommunikation zwischen Client und Server über den AdminClient etabliert wurde, rückt nun die Integration in die Vaadin-Oberfläche in den Mittelpunkt. Das Ziel ist, den aktuellen Systemzustand für den Benutzer sichtbar zu machen, ohne dass eine manuelle Aktualisierung erforderlich ist. Der Mechanismus basiert auf zyklischer Abfrage, Ereignissteuerung und einem reaktiven UI-Konzept, die vollständig in Vaadin implementiert wurden.

Adventskalender - 2025 - Filter & Search – Teil 01

Tue, 02 Dec 2025 07:05:12 +0000

Mit der in [Teil III] beschriebenen Vaadin-Oberfläche steht unserem URL-Shortener erstmals eine voll funktionsfähige Administrationskonsole zur Verfügung. Sie ermöglicht, bestehende Kurzlinks tabellarisch einzusehen und manuell zu verwalten. Doch bereits nach wenigen Dutzenden Einträgen zeigt sich eine klare Grenze: Die vollständige Anzeige aller gespeicherten Mappings ist weder performant noch benutzerfreundlich. Ein effizienter Shortener muss skalieren können – nicht nur beim Erzeugen, sondern auch beim Durchsuchen seiner Daten.

Der Quelltext zu diesem Stand ist auf GitHub unter https://github.com/svenruppert/url-shortener/tree/feature/advent-2025-day-00 zu finden. Der nachfolgende Screenshot zeigt den Stand, mit dem wir beginnen.

Code. Collaboration. Community.

Mon, 01 Dec 2025 07:01:12 +0000

JCON USA @ IBM TechXchange 2025 – wo der Java-Spirit in Orlando ein neues Zuhause fand

Als das JCON-Team ankündigte, seine etablierte Java-Konferenzreihe über den Atlantik zu bringen, waren die Erwartungen hoch. JCON Europe gilt seit Jahren als Pflichttermin für Java-Entwickler – lebendig, technisch anspruchsvoll und stark community-getrieben. Die erste US-Ausgabe, JCON USA @ IBM TechXchange 2025, erfüllte diese Erwartungen nicht nur, sondern übertraf sie. Entwickler aus aller Welt kamen nach Orlando zusammen, um drei Tage lang Java in all seinen Facetten zu feiern.

Java trifft Zukunft: Wie Quarkus Architektur, Performance und Cloud-Native nahtlos verbindet

Mon, 24 Nov 2025 07:00:53 +0000

Angesichts der zunehmenden Allgegenwärtigkeit digitaler Technologien, die fortlaufend und immer natürlicher in unsere Umgebung eingebettet werden, stellt sich die essenzielle Frage, welche Rolle Java in dieser zukünftigen Entwicklung von IT-Systemen spielen wird. Mark Weiser, Pionier des ubiquitären Computings, formulierte diesen technologischen Paradigmenwechsel folgendermaßen: “Die beste Technologie ist die, die wir gar nicht bemerken, weil sie auf natürliche Weise unseren Alltag bereichert.” (sinngemäß nach [LMU19]).

Ubiquitäres Computing zeigt bereits heute, wie Technologie allgegenwärtig wird und als unsichtbarer Begleiter nahtlos in unsere Umgebung integriert ist. Ein zentraler Faktor dabei ist der nahezu universelle Zugang zu Netzwerken (wie z.B. WLAN), der international immer mehr zur Standardinfrastruktur gehört. Dieser Zugang ermöglicht die Echtzeitvernetzung smarter Geräte, von Smart Homes bis hin zu Wearables, und bildet die Basis für Technologien, die intuitiv im Hintergrund arbeiten und barrierefrei ohne störende Eingriffe miteinander kommunizieren. Zudem fördert das ubiquitäre Computing eine immer engere Symbiose zwischen Mensch und Maschine, in der neue Technologien heranwachsen, die klassische Interfaces zur digitalen Welt wie Smartphones oder Tablets zunehmend ablösen. Geräte wie beispielsweise Mixed-Reality-Brillen (z.B. die Meta Quest oder Apple Vision Pro) eröffnen eine neue Form der Interaktion, bei der digitale Informationen direkt und kontextbewusst ins Sichtfeld projiziert werden. Ziel ist nicht mehr nur allgemeine Interaktion, sondern eine präzise Anpassung digitaler Inhalte an die individuellen Bedürfnisse des Nutzers. Diese Entwicklung mündet in das Konzept der Hyperpersonalisierung: Systeme reagieren in Echtzeit auf Standort, Vorlieben und Ziele und liefern so maßgeschneiderte Informationen, Unterhaltung oder Unterstützung im Alltag. Damit zeichnet sich eine Zukunft ab, in der digitale Erlebnisse nahtlos in das persönliche Leben integriert sind.

Signal per SSE, Daten per REST – eine Vaadin-Demonstration in Core Java

Wed, 03 Sep 2025 13:10:48 +0000

1. Einleitung

1.1 Motivation: Ereignisgetriebene Aktualisierung ohne Polling

In klassischen Webanwendungen dominiert nach wie vor das Pull-Prinzip: Clients stellen wiederholt Anfragen an den Server, um Veränderungen zu erkennen. Dieses Polling ist einfach, führt aber zu unnötiger Last auf Server- und Netzwerkseite, insbesondere wenn sich der Datenbestand nur sporadisch ändert. Mit Server-Sent Events (SSE) steht ein standardisiertes Verfahren zur Verfügung, mit dem der Server Änderungen aktiv an verbundene Clients signalisieren kann. Dadurch lassen sich unnötige Anfragen vermeiden, während Aktualisierungen zeitnah an die Oberfläche gelangen.

Die Blockchain in deiner Java Anwendung

Mon, 01 Sep 2025 07:01:53 +0000

kurzes Vorwort

Dieser Artikel befasst mit der Integration von Blockchain Mechanismen in Java Anwendungen. Hierbei befassen wir uns nicht mit Preisen oder insgesamt einzelnen Kryptowährungen, dies ist mir wichtig zu Beginn zu erwähnen. Im Verlaufe des Artikels nenne ich Blockchain Netzwerke, sodass ich klarstellen möchte, es handelt sich hierbei ausdrücklich nicht um Anlageberatung oder Werbung für diese Netzwerke und deren Kryptowährungen. Es handelt sich um eine technische Erklärung der Integration von Blockchain in Java mit Web3j.

Was macht Vaadin-Komponenten besonders?

Wed, 20 Aug 2025 13:26:00 +0000

Aus meiner Erfahrung heraus hebt sich Vaadin seit jeher von anderen Java-Frameworks ab. Natürlich erlaubt es die Umsetzung moderner Web-UIs, doch der eigentliche Unterschied liegt in seiner Komponentenarchitektur. Diese ist nicht als kurzfristiges Hilfsmittel gedacht, sondern konsequent auf Wartbarkeit und Flexibilität ausgelegt. Damit entsteht die Möglichkeit, Anwendungen über viele Jahre hinweg stabil zu betreiben und dennoch schrittweise zu erweitern.

Ganz gleich, ob ich eine Komponente aus der offiziellen Bibliothek nutze, eine eigene entwickle oder ein npm-Paket einbinde – Vaadin stellt sicher, dass alle Bausteine einem klaren Muster folgen. Die Verbindung zwischen Server und Client bleibt konsistent und verlässlich. Dadurch konnte ich Anwendungen im Laufe der Zeit Stück für Stück weiterentwickeln, ohne jemals gezwungen zu sein, sie vollständig neu aufzusetzen.

Microfrontends mit Module Federation für bestehende Anwendungen - Ein Erfahrungsbericht

Mon, 11 Aug 2025 07:00:34 +0000

Die Anwendung ist seit mehreren Jahren produktiv – und dann auf einen Hype wie Microfrontends aufspringen, geht das überhaupt? Wir haben das Experiment gewagt und unser bestehendes Frontend umgebaut und Microfrontends mit Module Federation eingeführt. Was uns dazu bewogen hat und was wir dabei gelernt haben, lernt ihr in diesem Artikel.

Wir hatten folgende Situation: zwei Projektteams, welche voneinander unabhängige Webportale in derselben Firma entwickeln, sollen möglichst viele Komponenten wiederverwenden. Die Wiederverwendung wurde beiden Projekten als Ziel vom Management vorgegeben.

Ist Java Cloud-nativ?

Mon, 14 Jul 2025 07:00:00 +0000

2025 feiert Java sein 30-jähriges Bestehen und erfreut sich nach wie vor großer Beliebtheit. Dank der hervorragenden Abwärtskompatibilität, der engagierten Community sowie der Vielzahl an Tools und Lösungen zur Erleichterung der Entwicklung mit Java bleibt die Plattform die bevorzugte Wahl für Unternehmensanwendungen.

Wenn es allerdings um Cloud-native Programmiersprachen geht, zeichnen sich Go, JavaScript, Ruby, Kotlin oder Rust durch ihre besonders hohe Geschwindigkeit und Effizienz sowie Benutzerfreundlichkeit aus – Eigenschaften, die sie zur bevorzugten Wahl für neue Projekte machen. Auch WebAssembly (Wasm) wird bei der Webentwicklung immer beliebter. Die Fähigkeit von Java zur Erstellung Cloud-nativer Programme wird allerdings oft mit Vorsicht genossen.

Mit Vaadin Flow Rest Endpoints in Core Java konsumieren

Mon, 23 Jun 2025 22:15:03 +0000

Warum REST-Integration in Vaadin-Anwendungen kein Nachgedanke sein sollte

In modernen Webanwendungen ist die Kommunikation mit externen Services längst keine Sonderfunktion mehr, sondern ein integraler Bestandteil einer dienstorientierten Architektur. Selbst wenn Vaadin Flow als UI-Framework auf serverseitige Java-Logik setzt und dadurch eine hohe Kohärenz zwischen View- und Datenmodell erreicht, entsteht schnell der Bedarf, mit Systemen außerhalb der eigenen Anwendung zu kommunizieren. Das können einfache öffentliche APIs sein – etwa zur Anzeige von Wetterdaten oder Währungsumrechnungen – ebenso wie interne Unternehmensdienste, beispielsweise zur Lizenzprüfung, Benutzerverwaltung oder der Anbindung an ein zentrales ERP-System.

Kino, Code, Community: Die JCON EUROPE 2025 setzt neue Maßstäbe für Java-Events

Fri, 30 May 2025 08:40:10 +0000

Von praxisnahen Workshops über Live-Coding im Kinosaal bis zur Mentoring-Revolution – die JCON EUROPE 2025 in Köln war ein Fest für Java-Fans aus aller Welt.

Ein globales Treffen der Java Community

Vom 12. bis 15. Mai 2025 wurde Köln zum Epizentrum der internationalen Java-Community. Zur zehnten Ausgabe der JCON EUROPE pilgerten Entwickler aus über 60 Ländern und fünf Kontinenten in den Cinedom, um gemeinsam 30 Jahre Java zu feiern. Die Stimmung? Euphorisch, gemeinschaftlich – und immer mit einer Prise Humor.

Java im Ernstfall: Wie Eigenentwicklung Kontrolle schafft und kritische Systeme sichert

Wed, 28 May 2025 13:55:34 +0000

Wenn IT versagt, merkt es keiner – bis es alle betrifft.
Ob im Krankenhaus, bei der Energieversorgung oder am Flughafen: In sicherheitskritischen Umgebungen ist der stabile Betrieb digitaler Systeme keine Option, sondern Pflicht. Genau hier zeigt sich, ob Infrastruktur resilient, skalierbar und unabhängig genug gebaut ist, um im Ernstfall standzuhalten.

Ein prägnantes Beispiel ist die Fraport AG, Betreiberin eines der größten Luftfahrtdrehkreuze Europas. Wenn dort Gepäck nicht ankommt oder sicherheitsrelevante Informationen verzögert eintreffen, steht nicht nur der Urlaub einzelner Passagiere auf dem Spiel – sondern die operative Stabilität des gesamten Betriebs. Hinter den Kulissen eines solchen Drehkreuzes läuft eine hochkomplexe digitale Infrastruktur, die rund um die Uhr funktionieren muss – trotz wachsender Anforderungen, alternder Legacy-Systeme und zunehmender Sicherheitsauflagen.

30 Jahre Java - Wie sich die Sprache entwickelt hat

Mon, 19 May 2025 07:00:31 +0000

Wir feiern 30 Jahre Java. Zeit für einen Rückblick wie sich Java als Programmiersprache entwickelt hat. Wir werden sehen, wie Java verschiedene Paradigmen der Softwareentwicklung integriert hat, ohne seine klare Struktur zu verlieren. Es ist faszinierend, dass man trotz all dieser Veränderungen in Java immer noch genauso programmieren kann wie vor 30 Jahren.

Als Java Mitte der 90er Jahre aufkam, war die objektorientierte Programmierung das dominierende Paradigma. Dies spiegelt sich in Java wider, das von Anfang an eine „rein“ objektorientierte Sprache war. „Alles ist ein Objekt“ kann wörtlich genommen werden. Mit Ausnahme der Primitiven ist alles von der Basisklasse „Objekt“ abgeleitet. Anfangs hielt sich die Sprache strikt an dieses Paradigma. Dies änderte sich im Laufe der Zeit, als die Sprache immer mehr Elemente des funktionalen Programmierparadigmas übernahm. Diese Entwicklung lässt sich auch in anderen Programmiersprachen beobachten.

Modularer Monolith mit SpringBoot & Maven

Tue, 18 Feb 2025 11:17:17 +0000

Monolithen sind ein bekanntes Architekturmuster, bei dem die gesamte Software als ein Deployable bereitgestellt wird. Sie sind dafür bekannt, dass ihre Wartbarkeit und Erweiterbarkeit im Laufe der Zeit zu einer Herausforderung werden können. Microservices sollen genau diesen technischen Schulden entgegenwirken. Dabei handelt es sich um einen Architekturansatz, bei dem die Fachlogik in einzelne Services aufgeteilt und separat bereitgestellt wird, was zu einer hohen Flexibilität führt. Diese Flexibilität hat jedoch auch ihren Preis: erhöhte Infrastukturkomplexität, zusätzlicher Netzwerktraffic, erschwertes Debugging von Fehlern und Bugs sowie kompliziertere Lösungen für Transaktionsprozesse, beispielsweise beim Schreiben in Datenbanken.

Kostenminimierung durch Nutzung von Cloud-Speicher mit Spring-Data-Eclipse-Store

Wed, 21 Feb 2024 14:59:47 +0000

Mit Hilfe von Spring Data und EclipseStore können massive Kosten für Datenspeicherung in der Cloud eingespart werden. Wie das funktioniert, zeigt folgender Artikel durch die Spring-Data-Eclipse-Store-Bibliothek.

Bewährte Praktiken für CI/CD Pipelines

Wed, 30 Nov 2022 17:51:53 +0000

Diese Praktiken sollen eine Vorstellung davon vermitteln, wie einige Probleme in modernen CI/CD-Pipelines gelöst und was vermieden werden sollte. Verwenden Sie diese Muster als Richtlinie beim Implementieren Ihrer eigenen Pipelines.

Die Zukunft von Containern - Was kommt als Nächstes?

Wed, 15 Jun 2022 17:29:13 +0000

Vielleicht haben Sie schon die Schlagworte gehört, die in aller Munde sind, wenn es um die Zukunft von Containern geht. Seltsame Namen wie “Micro-VMs”… “Unikernel”… “Sandboxes”… Haben Sie sich gefragt, was diese Dinge sind und wie Sie sie nutzen können? Oder sollten Sie diese überhaupt verwenden?

MicroStream High-Speed Persistence jetzt Open Source

Fri, 13 Aug 2021 16:14:42 +0000

MicroStream ist im Kern eine von Grund auf neu entwickelte, hoch performante und ebenso hoch sichere Serialisierung für Java, mit einem darauf aufsetzendem Persistence-Framework für die persistente Speicherung beliebiger Java Objektgraphen (POJOs), die im schnellen Hauptspeicher gehalten werden. Das Ergebnis ist eine hoch performante In-Memory Datenbankanwendung oder ein Microservice mit eigener Persistence.

Das 2013 gestartete Projekt ist nun in Version 5 als Open Source unter der Eclipse Public License auf GitHub verfügbar. Mit MicroStream lassen sich beliebige Java Objekte (Plain-Old-Java-Objects), in der Praxis meist komplexe Objektgraphen bestehend aus Millionen von Objekten oder auch nur einzelne Subgraphen davon, persistent speichern und zu einem beliebigen Zeitpunkt ganz oder auch nur teilweise im Hauptspeicher wiederherstellen, z.B. nach einem Systemneustart. Anders als bei traditionellen Java Persistenz-Frameworks wie Hibernate in Verbindung mit relationalen Datenbanken oder bei NoSQL Systemen, werden Java Objekte mit MicroStream nicht mehr auf eine datenbankspezifische Datenstruktur abgebildet (Mapping), sondern serialisiert und direkt in Form von Bytecode persistent gespeichert. Umständliche Mappings, daraus resultierende technische Probleme, rechenzeitintensive Datenkonvertierungen und damit verbundene Latenzen zur Laufzeit fallen vollständig weg.

Architektur-Hotspots aufspüren

Mon, 21 Dec 2020 13:18:06 +0000

Strukturelle Abhängigkeitsanalysen sind von begrenzter Aussagekraft. Teilweise erfassen sie die wesentlichen Architektur-Hotspots nicht, wie anhand eines Code-Beispiels exemplarisch gezeigt wird. Die vorgestellten Konzepte zur Feature-Modularität sind eine neue Art die System-Komplexität zu erfassen. Sie zielen darauf ab, Architektur-Hotspots zu identifizieren, die den (Wartungs-)Aufwand für neue Features ansteigen lassen.

Ein weit verbreiteter Ansatz zur Bewertung von Softwaresystemen und deren Architekturen besteht in der Analyse ihrer Abhängigkeitsstruktur. Ziel ist es Abhängigkeitsstrukturen zu identifizieren, die allgemein als schwer wartbar bekannt sind, zum Beispiel zyklische Abhängigkeiten und bestimmte systemspezifische Verletzungen wie schichtübergreifende Abhängigkeiten. Es besteht kein Zweifel, dass die Abhängigkeitsanalyse wertvolle Einblicke in die Struktur eines Softwaresystems liefert und tatsächlich echte Wartungsprobleme aufdecken kann. Trotz ihrer Nützlichkeit hat die klassische Abhängigkeitsanalyse aber große Schwächen.

Vernetzte Systeme mit FEPCOS-J

Mon, 21 Dec 2020 09:17:49 +0000

FEPCOS-J ist ein Programmiergerüst für Java, das die Entwicklung von zusammengesetzten, vernetzten Systemen, wie zum Beispiel Roboterschwärme, beschleunigt, indem es die benötigte Netzwerkprogrammierung automatisiert und die Spezifikation von Nebenläufigkeit vereinfacht. In diesem Artikel werden die Grundlagen und, mit einem einfachen Beispiel, die Anwendung von FEPCOS-J vorgestellt.

„Das Ganze ist mehr als die Summe seiner Teile.“ Aristoteles (384 v.Chr. - 322 v.Chr.). Dieses Prinzip ist auf ein vernetztes, technisches System, das aus Teilsystemen zusammengesetzt ist, übertragbar. Zum Beispiel ist bei einem Roboterschwarm der Schwarm das Ganze und die Roboter sind die Teile. Jeder Roboter kann für sich fahren. Der Schwarm kann mehr. Er kann zum Beispiel ausschwärmen, indem die einzelnen Roboter in verschiedene Richtungen fahren. Dies ist ein möglicher Mehrwert. Allerdings bekommt man diesen nicht geschenkt. Bei der Entwicklung eines vernetzten, technischen Systems, das ein aus Teilen zusammengesetztes Ganzes ist, ist mehr zu beachten als bei einem einzelnen System. Die Programmierung derartiger Systeme umfasst Netzwerkkommunikation und systemübergreifende Nebenläufigkeit, da die Teile kommunizieren und hochgradig parallel arbeiten. Dies ist ein Mehraufwand.

Von Nixdorf nach Kubernetien - Digitalisierung im Wandel der Zeit

Thu, 17 Dec 2020 10:16:28 +0000

Die Politik entdeckt die Digitalisierung als Zukunftsthema und gibt den Rat: „Die Digitalisierung ist auch für Mittelständler eine Pflichtaufgabe“. Dabei ist die Digitalisierung im Mittelstand schon lange angekommen, wie ein Ausflug in das Optica Abrechnungszentrum, einem Unternehmen der Dr. Güldner Firmengruppe, zeigt – lange bevor das Internet zum Neuland in der Politik deklariert wurde.

Digitalisierung 1.0

Mit der mittleren Datentechnik, die in den 70er Jahren des vorherigen Jahrhunderts vor allem durch Nixdorf in Deutschland und Europa geprägt wurde, wurden Computer auch für mittelständische Unternehmen erschwinglich. So hat das Optica Abrechnungszentrum bereits früh auf Unterstützung durch die elektronische Datenverarbeitung (EDV), wie IT früher hieß, gesetzt. Damit sich die teure Investition rechnete, waren die Prozesse auf den Computer ausgerichtet, um Leerlauf zu vermeiden. In mehreren großen Schreibbüros mit 40 bis 50 vorwiegend weiblichen Mitarbeitern wurden Abrechnungsdaten an Datensammelsystemen erfasst und gespeichert, anfangs auf Lochkarten, später auf Magnetbändern. Zum Abrechnungslauf wurden die Bänder auf ein Nixdorf 8850 eingespielt und anschließend archiviert. Benutzerschnittstellen waren in der EDV-Bronzezeit kein Thema – der Benutzer hatte sich nach dem Rechner zu richten. Vorherrschend waren Batch-Betrieb und das EVA-Prinzip: Eingabe – Verarbeitung – Ausgabe (Abb. 1). Hierbei gab es einfache, meist grüne Masken, die über die Tastatur und Enter-Taste bedient wurden. Und gute Datentypisten/-innen konnten die Masken blind und in hoher Geschwindigkeit bedienen.

Das EVA-Prinzip (Abb. 1)

Self-Contained-Systems

Mon, 14 Dec 2020 15:10:36 +0000

Self-Contained-Systems ist sowohl ein Architektur-, als auch Organisationsansatz, der im Kern auf dem Domain-Driven-Design-Ansatz aufsetzt und erweitert. SCS soll nicht nur die Trennung und Betrieb von Systemen, sondern auch die organisatorische Strukturierung und Trennung größerer Entwicklungsteams erleichtern. Der Fokus von SCS liegt klar auf Anforderungen und nicht auf technische Implementierungsdetails. Self-Contained-Systems (SCS) ist zunächst einmal ein Architekturansatz. Die Idee ist, Anforderungen durch einzelne, fachlich unabhängige Systeme abzubilden. Diese Systeme beinhalten alles, was für die Abbildung der Anforderungen notwendig ist - die Datenhaltung, die eigentliche Geschäftslogik und die komplette Benutzerschnittstelle. Diese Systeme werden dadurch self-contained. Jedes SCS soll von einem eigenen Entwicklungsteam betreut werden. Dieser Architekturansatz soll neben der technischen Trennung der Systeme auch die organisatorische Trennung erleichtern. Durch die Vermeidung von Abhängigkeiten werden auch die Teams unabhängiger und damit flexibler. Soweit die Theorie. Nachfolgend werden Vorteile und auch mögliche Probleme bei der Implementierung des SCS-Ansatzes beleuchtet.

Business-Impact-Analyse mit nur 5 Slides

Tue, 08 Dec 2020 10:51:41 +0000

**Um zukünftige Schadensszenarien begegnen zu können, müssen Unternehmen im Kontext eines Notfall- bzw. Risikomanagements eine Erhebung ihrer kritischen IT-Systeme durchführen, insbesondere im Rahmen von IT-Architektur-Reviews, Assessments, Audits oder weil die Compliance dies erfordert. In der Praxis ist eine solche Betrachtung viel zu umfänglich. Eine Business-Impact-Analyse kann jedoch mit vereinfachtem Umgang auf fünf Schaubilder reduziert werden. ** Eine gängige und anerkannte Methode für die Erhebung kritischer IT-Systeme ist das Notfallmanagement nach BSI 100-4. Der Umfang dieses Vorgehens betrachtet jedoch nicht nur die IT-Infrastruktur, sondern eben ein unternehmensweites Notfallmanagement inklusive Organisation und Prozesse. Nicht selten ist ein Analyseprojekt in diesem Kontext bis zu mehrere Hundert PT groß. In der Praxis ist diese Betrachtung viel zu umfänglich, da man im ersten Schritt nur den Technologie-Stack betrachten möchte. Sofern Prozesse und Organisation nicht im Fokus stehen, kann eine Business-Impact-Analyse (BIA) mit vereinfachtem Umfang auf fünf Schaubilder reduziert werden.

Java-EE vs. Spring für Microservices

Fri, 27 Nov 2020 13:14:10 +0000

Hat Jakarta-EE (ehem. Java-EE) immer noch den Ruf schwergewichtig zu sein und hat damit geringe Chancen für eine Microservice-Architektur in Betracht gezogen zu werden? Ist das Spring-Framework die bessere Antwort auf die Frage mit welcher Java-Technologie wir unsere Services bauen? Einmal mehr stehen sich die ewigen Duellanten Jakarta-EE und Spring gegenüber, dieses Mal jedoch mit dem Fokus auf Microservices.

Jakarta-EE vs. Spring - schon wieder?

Microservices mit Spring-Boot sind für viele Java-Entwickler zur Norm geworden und werfen einen erheblichen Schatten auf Jakarta-EE, wie Java-EE jetzt heißt. Durch seine beständige Evolution schafft es Spring immer wieder neue Entwicklungsansätze in die Welt zu tragen. Somit passt es sich den neuen Gegebenheiten und unseren sich ständig ändernden Anforderungen an. Spring-Boot hat sicherlich erheblich dazu beigetragen, dessen Grundlagen in der Blütezeit der Microservices entstanden sind. Gerade mit diesem Framework lassen sich schlanke Anwendungen schreiben, die in Self-Contained-JARs ausgeliefert werden. Diese und noch weitere Komponenten aus dem Spring-Ökosystem eignen sich nahezu perfekt, um den Kriterien eines Microservice gerecht zu werden.

Durchdachtes Log-Management für Industrie 4.0

Fri, 10 Jul 2020 12:51:25 +0000

Log- und Protokollmanagement ist eine oft wenig beachtete, aber dennoch eine der dringlichsten Herausforderungen zur Absicherung von IT-Strukturen. Dieser Artikel zeigt ein Best Case in Form eines Sicherheitskonzeptes über zehn Etappen und bedient sich dabei zur Veranschaulichung aus der Industrie 4.0-Themenwelt.

Sichere Identitäten gelten als wesentlicher Ausgangspunkt für Sicherheitsketten, welche die Datenerhebung, Datentransport und Datenverarbeitung auf Hardware-, Software- und Prozess-Ebene absichern. Damit bilden sie die Voraussetzung für viele weitere Schutzmaßnahmen, die Unternehmen in puncto Datensicherheit ergreifen sollten, um sich compliant und wettbewerbsfähig aufzustellen. Denn klar ist: Sobald es einem Angreifer gelingt, sich unberechtigt einer Identität zu bemächtigen, laufen alle darauf aufbauenden Maßnahmen wie zum Beispiel der Zugriffsschutz ins Leere. So bietet die Gewährleistung sicherer Identitäten über automatisierte Kommunikation ein solides Startglied in der Vertrauenskette. Mit der Einführung eines Sicherheitsprozesses leiten IT-Verantwortliche die notwendigen organisatorischen Veränderungen ein, definieren eine Strategie und nutzen Hilfsmittel zur Erreichung der Sicherheitsziele.

Prototyping spart Zeit und Kosten

Thu, 09 Jul 2020 16:51:10 +0000

Heute muss Software zügig entwickelt und produktiv gesetzt werden (Time-to-Market). Dabei kann Prototyping helfen, die Effizienz im Entwicklungsprozess zu verbessern. Allerdings gilt es sorgfältig zu überlegen, welche Prototyping-Methode zum eigenen Projekt passt. Softwareentwicklung ist eine sehr dynamische Disziplin, in der sich die Anforderungen schnell ändern. Häufig entwickelt die Auftraggeberseite eine Reihe von Anforderungen oder User-Stories, obwohl sie das entsprechende Resultat nicht genau einschätzen kann. Das Entwicklerteam macht sich Gedanken und arbeitet an einem repräsentablen Stakeholder. Wenn dieser jedoch hinter den Erwartungen zurückbleibt, weil die Anlage zur Visualisierung anfänglicher Anforderungen fehlt, kann es passieren, dass so ein Projekt komplett neu auf die Spur gesetzt werden muss. Das führt im Ergebnis zu einem erhöhten Budgetbedarf für die Produktentwicklung. Um den Ablauf und dementsprechend das Budget zu optimieren, können verschiedene Ansätze verfolgt werden: Proof-of-Concept, Wireframes, Funktionales Prototyping, MVP (Minimum Viable Product) oder ein Pilotprojekt. Dieser Artikel konzentriert sich auf das Prototyping:

Monolithen und Microservices sind keine Gegensätze

Tue, 12 May 2020 15:19:38 +0000

**Microservices sind in - Monolithen sind out. Diese einfache Formel wird der Programmier-Realität nicht gerecht. Denn nach wie vor kämpfen Microservices mit diversen Schwächen, während monolithische Architekturen immer noch eine ganze Reihe systembedingter Vorzüge besitzen. Clevere Programmierer nutzen deshalb mit modernem Software Engineering die komplementären Stärken beider Ansätze. ** Microservices-Architekturen sind nicht umsonst aktuell so beliebt, denn ihre Vorteile sind evident: Sie sind sauber strukturiert, granular skalierbar, ressourcenschonend, leicht erweiterbar und unterstützen die agile Software-Entwicklung in Teams. Dieser Habenseite stehen allerdings einige gravierende Nachteile gegenüber. Der für IT-Abteilungen vielleicht wichtigste ist die Komplexität von Microservice-Strukturen. Denn das Microservice-Portfolio gerät schnell in einen unübersichtlichen Wildwuchs, der nur mit viel Aufwand hinsichtlich Transparenz, Verwaltung und Kommunikation in den Griff zu bekommen ist. Das bindet zwar produktive Ressourcen, ist aber auch deshalb unumgänglich, weil mit der wachsenden Zahl von Microservices das Sicherheitsrisiko steigt. Denn mit ihren APIs, über die sie mit der Außenwelt kommunizieren, sind sie ein beliebtes Angriffsziel von Cyberattacken. Mit den Nachteilen von Microservices wurden prinzipiell bereits die Vorteile monolithisch aufgebauter Software-Architekturen beschrieben. Das ergibt sich aus der Tatsache, dass beide sich in ihren Eigenschaften und Merkmalen fast komplementär zueinander verhalten. Monolithen sind architektonisch einfacher, leichter auszurollen und häufig performanter als Microservices. Letzteres gilt, wenn eine App mit einer Microservices-Architektur zum Beispiel 20 bis 30 API-Aufrufe an 20 bis 30 unterschiedliche Microservices benötigt, um eine einzelne Eingabemaske zu laden, was zulasten der Performance geht. Demgegenüber kommunizieren die Software-Komponenten eines Monolithen in der Regel wesentlich performanter miteinander. Monolithen haben jedoch auch einige gravierende Nachteile: Sie skalieren nur “an einem Stück”, gelten deshalb als Ressourcenfresser und als schwerfällig, wenn es um die agile Einführung neuer Technologien wie das IoT oder KI geht.