Markus Kett on JAVAPRO Germany

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.

Helidon

Wed, 20 Jan 2021 15:15:16 +0000

Helidon ist ein Framework für die Entwicklung von Microservices. Helidon ist schnell, leichtgewichtig und einfach zu bedienen. Es kombiniert die Portabilität von Microprofile mit der Leistungsfähigkeit reaktiver APIs und möchte dabei völlig neue Maßstäbe bei der Erstellung von Microservices setzen.

Helidon stammt aus dem Griechischen und bedeutet Schwalbe. Sie ist ein Vogel aus der Gattung der Sperlingsvögel mit langen, scharfen Flügeln und dem charakteristischen Doppelschwanz. Der Flug und die Anmut dieser Vögel ist bewundernswert. Die Art und Weise, wie sie in Schwärmen leben, erinnert ein wenig an die Welt der Microservices.

JSR-385 hätte Mars Orbiter retten können

Tue, 22 Dec 2020 14:18:40 +0000

1999 verlor die NASA den Mars-Climate-Orbiter im Wert von 125 Millionen US-Dollar, als er in die Umlaufbahn eintrat. Aufgrund einer Diskrepanz zwischen US-Customary und SI-Maßeinheiten in unterschiedlichen Teilsystemen kam das Raumschiff dem Planeten zu nahe, passierte die obere Atmosphäre und zerfiel. Dies war nicht der einzige Fall, in dem eine fehlerhafte Umrechnung zwischen Maßeinheiten katastrophale Folgen hatte, aber es war sicherlich einer der spektakulärsten und kostspieligsten.

Immer wieder Unglücksfälle wegen Rechenfehler

Patriot Missile: Hier war die Ursache eine ungenaue Berechnung der Zeit, die seit dem Start verstrichen ist, auf Grund von Arithmetik-Fehler im Computersystem.
Ariane 5 Explosion: Es wurde eine Fließkommazahl umgewandelt, welche danach einen größeren Wert hatte, als durch den verfügbaren 16-Bit-signed Integer-Wert speicherbar gewesen ist.
Beinahe Absturz einer US-Verkehrsmaschine auf dem Flug zwischen den USA und Kanada, in der Gegend der Großen Seen und Großraum Chicago. Hier wurden beim Betanken der Maschine die Volumeneinheiten US-Gallone und Britischer Gallone für Flüssigkeit und Treibstoffe verwechselt, was die tatsächlich verfügbare Menge an Kerosin erheblich reduzierte und dazu führte, dass die Maschine in der Warteschleife beim Landeanflug ohne ausreichend Treibstoff endete.
Zahlreiche manchmal auch tödliche Fehldosierungen von Medikamenten.

Das Maß einer körperlichen Quantität ist der Prozess des Schätzens des Verhältnisses seiner Größe zu einer anderen Quantität der gleichen Art, die wir als Einheit gegeben annehmen. Zum Beispiel 5 Meter ist eine Schätzung der Länge eines Gegenstandes im Verhältnis zu einer anderen Länge - das Messinstrument, das wir in diesem Beispielfall als die Standardmaßeinheit der Länge annehmen. Eine ähnliche Annäherung kann für finanzielle Quantitäten angenommen werden und voraussetzen, dass eine Währungseinheit richtig und allgemein gültig definiert wird.

Kafka-Connect - Drittsysteme an Kafka anbinden

Tue, 22 Dec 2020 11:18:21 +0000

**Kafka ist eine verteilte Streaming-Plattform die verschiedene Nutzungsszenarien unterstützt. Sie kann als Messaging- oder Speichersystem eingesetzt werden und Datenströme transformieren. Dieser Artikel beschreibt, wie Sie mit Kafka-Connect Drittsysteme wie Redis an Kafka anbinden können. **

Kafka bietet eine flexible Grundlage, um darauf komplexe Datenverarbeitungsarchitekturen zu bauen. Eine wichtige Frage bei diesen Architekturen ist, wie die Daten in die Plattform gelangen und wie sie diese wieder verlassen. Hier kommt Kafka-Connect ins Spiel, ebenfalls eine quelloffene Komponente von Kafka. Kafka-Connect ist ein Framework mit dem man externe Systeme, wie zum Beispiel Datenbanken, Key-Value-Speicher, Suchindizes oder Dateisysteme an Kafka anschließen kann. Für Kafka-Connect gibt es bereits zahlreiche vorgefertigte Konnektoren, wie zum Beispiel für Splunk oder Elasticsearch¹. Diese Konnektoren teilen sich in zwei Gruppen auf: Sources und Sinks -also Quellen und Senken. Quellkonnektoren können zum Beispiel ganze Datenbanken auslesen und Änderungen in der Datenbank dann in Kafka-Topics veröffentlichen. Ein anderer Anwendungsfall ist das Sammeln von Metriken von Microservices, um sie dann dem Stream-Processing mit geringer Latenz zur Verfügung zu stellen und sie dann auswerten zu können. Sinks bringen die Daten aus den Kafka-Topics dann zum Beispiel in Suchindizes wie Elasticsearch oder in Batch-Systeme wie Hadoop, zur späteren Offline-Verarbeitung.

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.

Die Magie der Lambdas

Fri, 18 Dec 2020 14:17:32 +0000

Mit der JDK-Version 8 wurde der Versuch gestartet, die objektorientierte Welt mit den Vorteilen der funktionalen Programmierung zu verbinden. Dazu wurden die Lambda-Ausdrücke eingeführt, ein mächtiges aber leider oft unterschätztes Werkzeug. Da Lambda-Ausdrücke jedoch ein integraler Bestandteil des JDK und vieler Frameworks sind, kommt man in der Java-Welt nur noch schwer um sie herum.

Code = Daten

Die mit Java 8 eingeführten Lambda-Ausdrücke sollen die objektorientierte Programmiersprache Java mit den Vorteilen bekannter Konzepte aus der funktionalen Programmierung bereichern. Dazu muss erst einmal geklärt werden, dass Daten nicht notwendigerweise nur aus Zahlen, Bytes oder Zeichenketten bestehen, die in einem Programm herumgereicht werden, sondern dass auch der Code unseres Programms nichts anderes ist als Daten. Daten können an Methoden übergeben werden. Es ist also bekanntermaßen kein Problem Daten zum Beispiel in Form eines Integers oder eines komplexen Objekts an eine Methode weiterzugeben. Doch auch Code kann an eine Methode übergeben werden. Vor Java 8 verwendete man dazu eine Referenz auf ein Objekt. Innerhalb der Methode können dann die Methoden des Objekts aufgerufen werden und somit ist ein Zugriff auf dessen Code möglich. Oftmals macht man es sich zunutze, dass die Klasse des Objekts eine bestimmte Methode implementiert, die beispielsweise durch ein Interface oder eine abstrakte Klasse vorgegeben ist. Bekannt sind das Interface Runnable, in deren Methode run der Code für einen Thread verpackt wird, und das Interface ActionListener zur Definition einer Aktion, die z.B. beim Klick auf eine Schaltfläche ausgeführt werden soll. Diese Aktion wird in der vom Interface vorgegebenen Methode actionPerformed definiert.

MicroStream 4 – High-Performance Java-Native Persistence

Fri, 18 Dec 2020 10:17:15 +0000

Native Anwendungen mit Java. Java-Services so schnell wie C. Startzeiten in Millisekunden und minimaler Memory-Footprint. Auf Basis von GraalVM entsteht ein neuer Java-Stack für moderne Cloud-Native-Applikationen, der Java auf ein völlig neues Level bringt. Mit MicroStream kommt jetzt eine hoch performante und gleichzeitig leichtgewichtige Persistence dazu die mit bis zu 1000 Mal schnelleren Datenbankzugriffen eine extrem hohe Performance bietet.

Mit GraalVM, Quarkus und leichtgewichtigen Microservice-Frameworks wie Micronaut und Helidon dringt Java in neue Dimensionen vor. Java-Anwendungen so schnell wie C-Programme, Startzeiten in Millisekunden, mit all den Stärken von Java – das klingt beeindruckend. Das ist der neue Java-Cloud-Native-Stack mit GraalVM im Kern. Er wird von Oracle stark vorangetrieben,, das von Oracle stark vorangetrieben wird um Java fit zu machen für die Entwicklung moderner, hoch performanter und resourcensparender Applikationen und Services für die Cloud. Das einzige was diesem Stack noch fehlt, ist eine ebenso leistungsfähige wie leichtgewichtige Persistence. Genau dafür wurde MicroStream entwickelt – seit kurzem in Version 4 mit bedeutenden Neuerungen verfügbar. Genau dafür wurde MicroStream entwickelt, das seit kurzem in Version 4 verfügbar ist und bedeutende Neuerungen mit sich bringt.

H2 für JUnit-Tests

Thu, 17 Dec 2020 15:16:56 +0000

H2 ist eine komplett in Java implementierte, relationale Open-Source-Datenbank, die man embedded, als Server- oder In-Memory-Datenbank verwenden kann. H2 eignet sich unter anderem in Prototypen, kleinen Services und für automatisierte Unit-Tests.

Moderne Ansätze zum Systemdesign wie Microservices oder Self-Contained-Systems bieten die Möglichkeit, einzelne Aspekte eines Gesamtsystems isoliert betrachten und bearbeiten zu können. Implementierung, Erweiterung und Deployment der einzelnen Komponenten sind durch automatisierte Tests schnell und trotz zahlreicher Build- und Deployment-Pipelines sicher. Die Vorteile der Isolation kommen vor allem in der Entwicklung zum Tragen, wenn es gelingt Services ohne weitere Umgebungskonfiguration auf der Entwicklermaschine aufzusetzen und testgetrieben entwickeln zu können. Für Services und Systeme, die eine relationale Datenbank als Datenquelle nutzen, gibt es für lokal und in Pipelines ausgeführte Unit-Tests unterschiedliche Ansätze zur Einbindung einer Datenquelle. In diesem Zusammenhang wird im Folgenden das relationale Datenbankmanagementsystem H2 vorgestellt, das insbesondere für Tests auch als In-Memory Lösung konfigurierbar ist.

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)

Native Anwendungen mit Java

Wed, 16 Dec 2020 12:08:27 +0000

**Quarkus verspricht sagenhafte Performancegewinne. Der Einstieg ist einfach, da Quarkus wie eine Sammlung bereits bekannter Frameworks erscheint. Doch Quarkus wurde speziell für den Einsatz im Container und in der Cloud entwickelt. Hohe Performance und geringer Ressourcenverbrauch stehen im Focus. **

Quarkus bietet einen ähnlichen Funktionsumfang wie die Platzhirsche Spring-Boot und Java-EE (jetzt Jakarta-EE). Es ist jedoch nicht das Ziel von Quarkus, die etablierten Frameworks verdrängen. Es gibt keinen vorgezeichneten Migrationspfad von Java-EE oder Spring nach Quarkus. In den meisten Fällen dürfte eine Migration so teuer sein, dass sie den Nutzen bei weitem überschreitet. Quarkus ist vielmehr angetreten, um neue Nischen zu besetzen.

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.

OpenJDK Amazon-Corretto

Fri, 11 Dec 2020 14:22:15 +0000

Anfang 2019 wurde Amazon-Corretto 8, eine kostenlose, plattformübergreifende Distribution von OpenJDK für Java 8 veröffentlicht. Kurz darauf kam Amazon-Corretto 11 für Java 11 hinzu. Amazon setzt intern Corretto bei Tausenden von produktiven Workloads ein und hat auf Basis dieser Erfahrung Verbesserungen hinsichtlich Sicherheit, Stabilität oder Leistung im OpenJDK-Projekt beigesteuert. In diesem Artikel betrachten wir genauer, welche spezifischen Vorteile Amazon-Corretto bietet.

Die Installation von Amazon-Corretto

Amazon-Corretto 11 ist als Headless-Variante verfügbar. Diese Variante enthält keine Laufzeitabhängigkeiten, die in der Regel mit GUI-Anwendungen wie X11 und ASLA verbunden sind, und ist für serverseitige Workloads sinnvoll. Im folgenden werden die Installationsanweisungen für Amazon-Linux 2 gezeigt. Amazon-Linux 2 ist die nächste Generation von Amazon-Linux, einem Linux-Server-Betriebssystem von Amazon-Web-Services (AWS). Es bietet eine sichere, stabile und hochleistungsfähige Ausführungsumgebung zur Entwicklung und Ausführung von Cloud- und Unternehmensanwendungen.

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.

Loggen mit Struktur

Fri, 04 Dec 2020 11:36:38 +0000

Log-Server bieten weit mehr als eine Volltextsuche über textuelle Log-Meldungen an. Sie sind komplette Datenbanksysteme mit komplexen Auswertemöglichkeiten. Wenn Log-Meldungen passend zu den Datenbankfähigkeiten erstellt werden, ergeben sich neue Möglichkeiten im Umgang mit Log-Daten.

Java-Log-Bibliotheken zum effizienten Schreiben von Log-Meldungen gibt es seit über 20 Jahren. Ursprünglich dienten sie als Hilfe beim Debuggen während der Entwicklung und zur Diagnose von Produktionsproblemen. Im produktiven Unternehmenseinsatz hatten Entwickler meistens keinen Zugriff auf die produktiven Log-Dateien. Die Dateien mussten erst von einem Administrator angefordert werden, der einem dann die hoffentlich richtigen Log-Dateien bereitstellte. Unter solchen Umständen dauerte es oft Stunden, bis ein Problem diagnostiziert werden konnte. Mit dem Aufkommen von Microservice-Architekturen und verteilten Anwendungen in der Cloud steigt die Anzahl der relevanten Log-Dateien rasant an. In der Vergangenheit gab es Projekte mit einer Microservice-Architektur, bei denen allein von den Java-Anwendungen über 40 Log-Dateien auf vier verschiedenen Maschinen gleichzeitig geschrieben wurden. Die Problemdiagnose nur mit Texteditoren und UNIX-Kommandozeilen-Tools ist bei einer solchen Anzahl von Dateien keine erfreuliche Aufgabe. Ein Log-Server, der über eine grafische Oberfläche eine Volltextsuche über alle Log-Dateien ermöglicht, ist unter diesen Umständen eine große Arbeitserleichterung. Da der Zugriff auf den Log-Server nicht den direkten Zugriff auf das Produktionssystem erfordert, ist es – abgesehen vom Datenschutz – auch unkritisch, dem Entwickler Zugriff auf die Produktions-Logs zu geben. Es dauert dann nicht mehr Stunden, bis ein Entwickler die richtigen Log-Meldungen sehen kann, sondern er kann ohne fremde Hilfe tätig werden und hat praktisch Live-Zugriff.

Boilerplate-Code minimieren mit Lombok

Wed, 02 Dec 2020 14:04:34 +0000

Projekt Lombok versteckt auf elegante Weise sogenannten Boilerplate-Code. Getter, Setter und all das, was Entwickler im Leben ungefähr 2 Millionen Mal per IDE generieren – all das soll mit Lombok wegfallen. Ist die Einstiegshürde erst einmal überwunden, funktioniert das wirklich.

Wer erinnert sich eigentlich noch an die vielen Java-Enterprise-Beans der Version 1 oder 2, die unsäglichen Schmerzen, die einem damals bei professioneller Entwicklung widerfahren sind und die große Erleichterung die schließlich mit POJOs kam. Plain-Old-Java-Objects: Endlich testbarer Code! Code, den man auch verstehen konnte. Es gab nur zwei Regeln die man akzeptieren musste:

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.

Keycloak individuell erweitern

Thu, 19 Nov 2020 15:01:45 +0000

Die Identity- und Access-Management-Lösung Keycloak erfreut sich in den letzten Jahren weiter Verbreitung. Trotz vieler Funktionen sind in der Praxis häufig individuelle Anpassungen erforderlich. Wie kann man solche Erweiterung vornehmen - von der Bereitstellung eines eigenen Moduls, über die Registrierung eines Providers bis hin zu Aspekten wie Logging und Konfiguration?

Keycloak ist eine Open-Source Identity- und Accessmanagement-Lösung. Für individuelle Erweiterungen stehen in Keycloak eine Reihe von Erweiterungspunkten, sogenannte Service-Provider-Interfaces (SPI) zur Verfügung, um vorhandene Funktionalität auszutauschen oder an die eigenen Bedürfnisse anzupassen.

Quarkus - die Zukunft von Java?

Fri, 13 Nov 2020 11:13:57 +0000

Wenn es um Entwicklungszykluszeiten, Startzeiten von Anwendungen, Größe der Deployments und Kompatibilität in oder mit Containerumgebungen geht, scheinen andere Sprachen wie JavaScript, Python oder Go gerade Java den Rang abzulaufen. Mit Quarkus soll sich das jetzt ändern: Native Anwendungen mit Java, Performance vergleichbar mit C, Startzeiten unter einer Sekunde und dazu alle bereits bekannten Vorteilen von Java. Damit dringt Java in eine neue Dimension vor uns setzt völlig neue Maßstäbe.

Quarkus ist ein für die GraalVMs optimiertes Java-Framework. Bei GraalVM handelt es sich im Grunde um zwei eigenständige virtuelle Maschinen:

JCON-ONLINE 2020 Rückblick

Tue, 03 Nov 2020 15:08:30 +0000

Danke an alle Teilnehmer, Speaker, Sponsoren und Partner für die beste JCON aller Zeiten! Bedingt durch COVID-19 haben wir uns dieses Jahr dafür entschieden, die mittlerweile 4. JCON nicht wie gewohnt in der UCI Kinowelt in Düsseldorf zu veranstalten, sondern erstmals als reine Online-Konferenz. Von Anfang an haben wir das als großen Vorteil betrachtet: Teilnehmer und Speaker sparen sich die Anreise und Hotelkosten, man kann bequem vom Office oder von zu Hause aus teilnehmen, was sich auch lohnt, wenn man sich nur für einige wenige Vorträge interessiert und auch internationale Teilnehmer und Speaker können problemlos an einer Online-Konferenz teilnehmen. Bereits nach dem überragenden Call-for-Papers und der finalen Zusammenstellung des diesjährigen Sessionplans stand für uns fest: Das ist ein Hammer-Sessionplan, gespickt mit über 110 internationalen Top-Speakern, über 150 Sessions, jede Stunde 5 Vorträge zeitgleich von früh morgens 9:00 Uhr bis abends 21:00 Uhr, 3 Tage lang. Wem das zu viel ist, kann sich später die aufgezeichneten Sessions ansehen. Bis zum letzten Konferenztag haben sich schließlich über 2.000 Teilnehmer angemeldet. Das ist absoluter Rekord! Am ersten Konferenztag waren über 1.000 Teilnehmer online live dabei. Über 530 Teilnehmer haben die erste technische Keynote mit Adam Bien “What Should Happen in 2021 with Java Backends and Web Frameworks?” mitvervolgt. In der Spitze waren 483 Teilnehmer bei der Keynote gleichzeitig online. Am 2. Konferenztag stand das Thema Java-Cloud-Native rund um GraalVM und Quarkus im Fokus. Bei der Keynote “High-Performance Java-Cloud-Native Apps & Microservices” mit Markus Kett, waren knapp 400 Teilnehmer online und auch die zweite Keynote des Tages über “Open Source at Amazon” mit Sascha Möllering von Amazon Web Services, waren über 300 Teilnehmer live dabei. Highlight des 3. Konferenztages war die Keynote mit Gaël Blondelle, Vice President, Ecosystem Develpment at Eclipse Foundation. Im Hintergrund hat das dreißigköpfige JCON-Orga-Team dafür gesorgt, dass dass die JCON auch als Online-Konferenz reibungslos abläuft. Dazu wurde das JAVAPRO Office noch rechtzeitig in ein modernes Studio umgewandelt. Alle Sessions wurden aufgezeichnet und die ersten Videos sind bereits über den JCON-Sessionplan abrufbar. Täglich werden jetzt sukzessiv weitere Aufzeichnungen hinzu kommen, sodass in Kürze alle aufgezeichneten Vorträge sowie die dazugehörigen Slides online sein werden. Die Zugangsdaten zum Sessionplan sind auch weiterhin gülitg. Als erste Verbesserung wurde die Einführung einer neuen Sessionplan-Software beschlossen, nachdem unser bisheriges Tool etwas in die Jahre gekommen ist und sich für eine reine Online-Konferenz nicht so gut eignet. Schwierig ist die aktuelle Situation jedoch für Sponsoren und Aussteller und das nicht nur auf der JCON. Werbeformate, die in den Pausen zwischen den Sessions abgespielt werden können, sind bei den meisten Sponsoren noch nicht vorhanden. Deshalb wird unser JCON-Marketing an neuen smarten Werbeformaten arbeiten, mit denen Sponsoren und Aussteller wieder einen echten Mehrwert erhalten und damit wieder Spaß an Konferenzen haben werden. Für nächstes Jahr gehen wir davon aus, dass die JCON 2021 erneut als Online-Konferenz stattfinden und weiter kräftig wachsen wird.

Be part of the future of JavaFX - JFX Adopters Meeting 2020

Mon, 21 Sep 2020 17:03:37 +0000

“Write once, run anywhere” is not only the slogan but also the key advantage of this multi-platform-development launched by Java. JavaFX - a next-generation client application platform for desktop, mobile and embedded systems built on Java. It enables the development of modern applications with Rich Media content, audio, video and provides an attractive experience when using applications developed with it. JavaFX was originally part of Java SE Development Kit as JDK 8. It is fully open-sourced and detached from the Development Kit since JDK 11. This enables individuals and companies alike to join the community and drive the future of JavaFX. A JFX Adopters Meeting was held 2018 in Munich, to exchange information on current projects and future plans. Representatives of the JavaFX ‘ecosystem’ (e.g. Oracle, Gluon, BestSolution, Karakun, JPro) attended the meeting, to discuss a viable picture of JavaFX with the attendees. Concerns raised at the time regarding the difficulty in contributing code changes and lack of support for 3D-rendering have now been overcome. The move from JavaFX Mercurial Repository to Git and OpenJFX on GitHub has drastically reduced the turnaround time and facilitated developers to integrate their own fixes in official JavaFX code. Lead developers have been freed up to concentrate on future development whilst the community contributes to fixing and stabilizing JavaFX. Contributions and accepted pull requests have shown that the process of fixing bugs, instead of only reporting in a bug database, is now becoming best practice and JavaFX is back to being a highly active initiative. The number of new projects started with JavaFX as user interface technology has increased. Integrated devices, like user interfaces in the car or machines, have come more into focus. Furthermore, due to the separation of JavaFX and the JDK with JDK11, it is now finally possible to compile JavaFX like any other open-source library. Consequently, with the greatly increased development speed, the JavaFX developer is more independent than ever before. Since JavaFX13, its support for 3D-Rendering has greatly improved. With the new NIO-Support for writable images, it is now possible to integrate VLC, WebGL, OpenGL into existing JavaFX applications. Furthermore, Oracle has announced the extension of its commercial support for JavaFX 8 to the year 2025: a total of 11 years, considering Java SE Development Kit 8 was released in 2014. Compared to other UI-Toolkits (I’m pointing to you, Angular), this is a very reliable foundation for Desktop-Development, which can also be used for Mobile Applications (Gluon) and Web Applications (JPro) with a reliable API that will be stable for decades. Nevertheless, for successful further development of JavaFX, a strong ecosystem is needed, particularly from adopter companies contributions. The next JFX Adopters online meeting will be held virtual on Wednesday, the 14th of October 2020. To register for the JFX Adopters Meeting online on Wednesday, the 14th of October 2020 please click on the following URL: http://zeiss.com/jfx-adopters-meeting Further readings: Oracle Java Client Roadmap Updates: https://blogs.oracle.com/java-platform-group/java-client-roadmap-updates OpenJFX: https://openjfx.io/ Gluon: https://gluonhq.com/ JPro: https://www.jpro.one/ Karakun: https://karakun.com/ [accordion-group title=“Autor - Christian Heilmann”] Christian Heilmann is software architect at Carl Zeiss Meditec AG in Munich [/accordion-group]

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.