Developer

Aktuelle Themen

13.12.2019, 14:52

Application Insights für App Services

Was ist Application Insights?

Application Insights ist ein Dienst der Microsoft-Azure Cloud mit dem sich eine Anwendung überwachen lässt. Die benötigte Leistung dieses Dienstes ist laut Microsoft sehr gering.Mehr

Mehr...

10.12.2019, 11:04

Stefan Waldmann

How to deploy a (native) Quarkus Application on Heroku

Quarkus is a „container first“ framework for microservice development in Java (or alternatively Kotlin or Scala). With help of GraalVM Native Image, Quarkus applications can be compiled to native executables that run directly on the target OS, without JVM, with low memory footprint and blazing fast startup time.

Heroku is a Cloud Application Platform for building and hosting applications, while various languages can be used for development. It also allows to deploy and run self-built docker images.

Following the instructions from this blog post, we’ll create a native Quarkus application and deploy it in a docker container to the Heroku Runtime.

Mehr

Mehr...

09.12.2019, 11:54

Lars Kalkuhl

Vergleich Spring Boot vs Micronaut vs Quarkus

In diesem Blog Beitrag geht es um den Vergleich der beiden Frameworks Micronaut und Quarkus mit Spring Boot.

Micronaut

Micronaut ist „ein modernes, JVM-basiertes Full-Stack-Framework für den Aufbau modularer, leicht testbarer Microservice- und Serverless-Anwendungen.“ [1]

Dabei unterstützt Micronaut Sprachen wie

Java
Kotlin
Groovy

Vorteile

Micronaut zielt auf folgende Aspekte von Anwendungen für die JVM ab und versucht, sie zu optimieren:

schneller Applikationsstart
reduzierter Laufzeit-Speicherbedarf
minimaler Einsatz von Java Reflection
minimaler Einsatz von Java Proxies
einfache, schnelle Applikationstests

Die schnelle Startzeit fällt sowohl bei der Entwicklung und der Ausführung von Integrationstests als auch bei einem Kaltstart als AWS-Lambda-Funktion positiv auf. Aufgrund des geringen Speicherbedarfs zur Laufzeit eignet sich Micronaut besonders für die Entwicklung von „Serverless“-Anwendungen. Damit verbunden wirbt das Entwicklungsteam vor allem mit dem inhärenten Cloud-Support, der keine zusätzlichen externen Abhängigkeiten benötigt, sondern Teil des Ökosystems ist. [2]

Eine Beispielmessung der Seite w-jax zeigt den genauen Vergleich:
Die Abbildung zeigt die Verbesserungen von Micronaut gegenüber Spring. Während die Compile-Zeit nun signifikant länger ist, kann das Framework bei anderen Metriken punkten. Dabei ist zu beachten, dass die Startzeit je nach Größe der Anwendung bei Spring immer länger wird, während die Startzeit der MicronautAnwendung relativ konstant bleibt. [3]

Quarkus

Quarkus ist „ein Kubernetes Native Java-Stack, der auf OpenJDK HotSpot und GraalVM zugeschnitten ist und aus den besten Java-Bibliotheken und -Standards entwickelt wurde.“ [4]

Bei der Optimierung von Quarkus steht besonders der Einsatz in Cloud- und Container-Umgebungen im Fokus. Hierbei sind besonders geringe Speichernutzung und schnelle Startzeiten wichtig. Quarkus erreicht diese Eigenschaften durch verschiedene Optimierungen:  Sehr gute Unterstützung von Graal/SubstrateVM  Verarbeitung der Metadaten zur Build-Zeit  Reduzierte Nutzung von Reflection  Vorverarbeitung des Boot-Prozesses
Quarkus ist ein Fullstack-Framework, das eine ganze Reihe von Bibliotheken integriert. Hierbei wird stark auf bewährte Bibliotheken, wie z.B. Hibernate, RESTEasy oder Apache Kafka, gesetzt. Das Ziel hierbei ist, dass Entwickler nicht viel Zeit investieren müssen, um neue Technologien zu lernen, sondern mit bewährten Bibliotheken und Standards arbeiten können. Quarkus sieht sich hierbei nicht nur als einfacher Konsument, sondern möchte auch daran teilhaben die verwendeten Bibliotheken zu verbessern.Viele der Bibliotheken, die in Quarkus verwendet werden, müssen vorher für das Framework optimiert werden. Quarkus verzichtet so gut es geht auf Reflection, und da viele Frameworks stark darauf ausgelegt sind, müssen diese angepasst werden. Es stehen hierzu eine Reihe von Erweiterungen bereit, welche für Quarkus genutzt werden können. Diese liefern direkt die optimierten Versionen der Bibliotheken. [5]

Ein Test der Seite itemis zeigt den Vergleich mit Spring Boot [6]:

Vergleich der „HelloWorld“-Anwendungen

Nachdem ich die „HelloWorld“-Anwendung des jeweiligen Frameworks testen konnte, kam es zu folgendem Ergebnis:

Framework	Durchschnittliche Zeit bis zum kompletten Startup	Arbeitsspeicher Auslastung
Micronaut	1,83 Sekunden	98 MB
Quarkus	1,12 Sekunden	70 MB
Spring Boot	2,55 Sekunden	215 MB

Es wird deutlich, dass die beiden Frameworks im Vergleich mit Spring Boot etwas schneller sind und weniger Arbeitsspeicher Auslastung haben, wobei Quarkus das beste Ergebnis erzielt hat.

Migration von Spring Boot zu Micronaut/Quarkus

An einem bestehenden Maven Projekt, das Spring Boot nutzt soll nun Micronaut/Quarkus zum Einsatz kommen.

Micronaut for Spring

Micronaut for Spring ermöglicht es, traditionelle Spring Annotationen zu verwenden, die zur Kompilierungszeit auf Micronaut Annotationen abgebildet werden. Auf diese
Weise kann eine Anwendung geschrieben werden, die ohne Änderung in eine andere Spring- oder Mikronaut-Anwendung importiert werden kann.
Im Gegensatz zu herkömmlichen, auf Laufzeitreflexion basierenden Frameworks verwendet Micronaut die Ahead of Time (AOT)-Kompilierung, sodass es keinen Laufzeit-Overhead für die Unterstützung eines zusätzlichen Satzes von Annotationen gibt (in diesem Fall Spring’s Annotation Programming Model).
Vorteile sind:

Es kann die kompilierte Anwendung genommen und ohne Änderungen in eine andere Spring oder Micronaut Anwendung eingebunden werden.
Ein bestehendes Team von Spring-Entwicklern kann mit Micronaut arbeiten, ohne eine neue Annotation DSL zu lernen.

Man sollte dabei beachten, dass Spring riesig ist und nur einige Teile unterstützt werden. [7]

Bemerkung: Bei Micronaut for Spring wurde die Startup Zeit bei jedem Neustart geringer. So startete es beim ersten Start mit 5,8 Sekunden und brauchte nach einigen weiteren Starts nur noch 3,8 Sekunden.

Quarkus

Quarkus nutzt Jersey für seine Annotationen.
Die Controller Klassen heißen hier Resource Klassen und müssen mit der Annotation @Path() eingeleitet werden.

@Path("/")
public class HelloWorldResource{
     @GET
     @Path("/hello")
     public String helloWorld(){
          return "hello";
          }
}

@Path("/")

public class HelloWorldResource{

@GET

@Path("/hello")

public String helloWorld(){

return "hello";

}

Vergleich

	Durchschnittliche Zeit bis zum kompletten Startup	Arbeitsspeicher Auslastung
Nur Spring Boot	6,8 Sekunden	800 MB
Micronaut for Spring	3,9 Sekunden	210 MB
Micronaut ohne Spring	2,2 Sekunden	130 MB
Quarkus	1,2 Sekunden	87 MB

Fazit

Zusammenfassend lässt sich sagen, dass jedes Framework seine Vor-und Nachteile hat.
Am einfachsten war es, ein bestehendes Projekt mit Micronaut for Spring umzuformen, da man mit kleinen Änderungen in der pom das Projekt schneller und arbeitsspeichersparender machen kann.
Allerdings ist Micronaut for Spring natürlich nicht so schnell und arbeitsspeichersparend wie Micronaut oder Quarkus alleine.
Es fiel mir allerdings leichter, den bestehenden Spring Boot Code in Quarkus umzuschreiben, da Quarkus mit Jersey arbeitet und sich die bestehenden Annotationen einfacher ersetzen lassen.
Von Quarkus in Micronaut umzuformen ist dann genau so leicht, da sich die Micronaut Annotationen stark an Jersey orientieren.
An sich hat mir Quarkus am besten gefallen. Auch hat Quarkus die besten Ergebnisse im Test erzielt, wie man in der obigen Tabelle sieht. Die Zeit zum kompletten Startup ist um einiges geringer und arbeitsspeichersparender als bei den anderen Frameworks.
Wobei Micronaut nicht viel schlechter abschneidet.
Beide Frameworks sind unter der Apache License v2 lizenziert. [8]

[1] https://micronaut.io/

[2] https://www.heise.de/developer/artikel/Micronaut-fuer-Cloud-native-JVM-Microservices-4198374.html?seite=all

[3] https://jax.de/blog/cloud-native-java-mit-micronaut/

[4] https://quarkus.io/

[5] https://blog.codecentric.de/2019/04/quarkus-macht-java-fit-fuer-die-cloud/

[6] https://blogs.itemis.com/de/4-microservice-frameworks-im-vergleich

[7] https://micronaut-projects.github.io/micronaut-spring/latest/guide/index.html

[8] http://www.apache.org/licenses/LICENSE-2.0

Micronaut Quarkus Spring Boot Vergleich

Mehr...

22.11.2019, 11:22

Nico Mutter

It’s #FrontendFriday – Klassen / Modul-Diagramme in Frontend-Projekten

Hallo #FrontendFriday-Leser/in,

heute geht es um Tools, die Klassendiagramme aus Frontend-Projekten (speziell TypeScript, Angular) generieren.

Zu Beginn eines Projekt wird eine Architektur der Anwendung erstellt (die sich im Laufe des Projekts weiterentwickelt). Während des Projekts stellt sich die Frage, ob die geplante Soll-Architektur mit der tatsächlich umgesetzten Architektur übereinstimmt. Hierzu können unter anderem Klassendiagramme helfen, die automatisch aus dem entwickelten Code generiert werden.

Tools

Liste der getesteten Tools. Die Tools, sind verlinkt. Dort finden sich auch Beispiel-Diagramme.

IntelliJ nur in Ultimate verfügbar. Testklassen (.spec.ts) können nicht exkludiert werden.
NGD Generiert sehr breite Bilder. Das Dokumentationstool compodoc verwendet diese Library zur Darstellung einzelner Module.
ngrev Eigenständige Applikation mit UI. Wird von einem Entwickler vom Angular Team entwickelt.
tplant Generiert PlantUML Diagramme, aber ohne direkten Angular-Projekt Support.
tsviz Generiert sehr breite, unübersichtliche Bilder.
vscode-ts-uml Plugin für VS-Code, analysiert nur einzelne Dateien, kann keine Übersicht über ein Projekt erstellen.
TsUML Sendet den Quellcode an einen Onlinedienst, der Klassendiagramme generiert.

Die Tools sind nach Empfehlung geordnet.

Fazit

Mehrere, auch kostenpflichtige Tools, wurden getestet. Ein ganz zufriedenstellendes Ergebnis konnte bisher keines liefern. Für einen schnellen Überlick kann dies aber reichen.
Für andere Programmiersprachen (z.B. Java) sind ausgereiftere Tools verfügbar. Sind euch bessere Möglichkeiten bekannt?

Angular FrontendFriday

Mehr...

22.11.2019, 09:53

Manuel Sauter

Softwarearchitektur Qualitätssicherung

Einführung

Die Softwarearchitektur ist eine wichtige Voraussetzung für die Verständlichkeit und Veränderlichkeit von Code, sowie für die Einhaltung von Software Qualitätszielen. Drei Ziele der Softwarearchitektur sind Wartbarkeit, Austauschbarkeit und Erweiterbarkeit. Durch die Einführung von Mustern und Konventionen können die Ziele erreicht werden. Diese werden vom gesamten Entwicklungsteam definiert.

Doch wie kann jetzt sichergestellt werden, dass die Muster und Konventionen eingehalten werden?

Oft werden dafür in regelmäßigen Abständen aufwändige Code Reviews durchgeführt. Im Zeitraum zwischen den Reviews können sich jedoch viele technische Schulden ansammeln. Die Behebung dieser Verstöße kann dann viel Zeit in Anspruch nehmen.

Tools wie ArchUnit und jQAssistant helfen solche Konventionsverstöße schon bei der Entwicklung zu vermeiden. Im nachfolgenden werden diese Tools miteinander verglichen und eine Empfehlung ausgesprochen.

jQAssistant

jQAssistant analysiert den Code und speichert Daten darüber in einer Neo4j-Graphdatenbank. Als Knoten werden dabei unter anderem Dateien, Klassen, Interfaces, Packages, Felder, Methoden und Annotationen angelegt. Verbindungen werden durch Schlüsselwörter wie CONTAINS, DEPENDS_ON, INVOKES, DECLARES, IMPLEMENTS und RETURNS abgebildet. Durch Plugins kann der Graph nochmals erweitert werden. Zum Beispiel um Code-Coverage, Informationen aus der Git-Historie, JUnit-Testergebnisse und vieles mehr. Außerdem kann jQAssistant durch eigene Plugins oder Regeln erweitert werden.

Beispiel Regeln:

Namenskonventionen prüfen z.B. EJBs, JPA Entities, Test Klassen, Packages etc.
Abhängigkeiten zwischen Modulen überprüfen
API und Implementation Packages trennen
Probleme identifizieren z.B. zyklische Abhängigkeiten, Tests ohne Assertions etc.
Vererbungshierarchien anzeigen
Kennzahlen analysieren: Anzahl-Methoden in einer Klasse

Um einen Eindruck vom zu analysierenden bzw. zu validierenden System zu verschaffen, kann ein Neo4j-Server samt GUI gestartet werden. Dann können über den Browser, Abfragen gegen die Datenbank ausgeführt werden:

Einrichtung

Kommandozeile

jQAssistant herunterladen und entpacken
Es können verschiedene Tasks ausgeführt werden (Details: hier )

Beispiel:
Ordner oder Dateien scannen:

Windows: .\jqassistant.cmd scan -f folderpath/file
Linux: ./jqassistant.sh scan -f folderpath/file

Maven

jQAssistant-Plugin zur pom.xml hinzufügen (https://jqassistant.org/get-started/)
Innerhalb des Moduls ein neues Verzeichnis „jqassistant“ mit einem rules.xml anlegen (dort können Regeln definieren werden).
Ein Maven Build führt die jQAssistant Prüfung aus.
Wenn gegen eine Regel verstoßen wird, bricht der Build

Definition der Regeln

Regeln werden als Queries in Cypher definiert (in XML oder AsciiDoc Files). Es können aber auch Skriptsprachen wie JavaScript, Ruby oder Groovy verwendet werden.

Beispiel mit XML und Cypher:

&lt;jqa:jqassistant-rules xmlns:jqa="http://www.buschmais.com/jqassistant/core/analysis/rules/schema/v1.0"&gt;
   &lt;constraint id="my-rules:TestClassName"&gt;
        &lt;requiresConcept refId="junit4:TestClass" /&gt;
        &lt;description&gt;All JUnit test classes must have a name with suffix "Test".&lt;/description&gt;
        &lt;cypher&gt;&lt;![CDATA[
            MATCH
                (t:Junit4:Test:Class)
            WHERE NOT
                t.name =~ ".*Test"
            RETURN
                t AS InvalidTestClass
        ]]&gt;&lt;/cypher&gt;
    &lt;/constraint&gt;

    &lt;group id="default"&gt;
        &lt;includeConstraint refId="my-rules:TestClassName" /&gt;
    &lt;/group&gt;
&lt;/jqa:jqassistant-rules&gt;

<jqa:jqassistant-rules xmlns:jqa="http://www.buschmais.com/jqassistant/core/analysis/rules/schema/v1.0">

<description>All JUnit test classes must have a name with suffix "Test".</description>

<cypher><![CDATA[

MATCH

(t:Junit4:Test:Class)

WHERE NOT

t.name =~ ".*Test"

RETURN

t AS InvalidTestClass

]]></cypher>

</constraint>

</group>

</jqa:jqassistant-rules>

ArchUnit

ArchUnit ermöglicht es den Java Code und seine Strukturen mit jedem Java-Unit-Testframework zu testen. Mit ArchUnit können Regeln für die statischen Eigenschaften der Architektur wie den folgenden implementieren:

Prüfungen der Package Abhängigkeit
Überprüfung der Abhängigkeiten von Klassen
Vererbungprüfungen
Annotationsprüfungen
Layerprüfungen
Zyklusprüfungen

Einrichtung

Die ArchUnit Dependency zur Parent pom.xml hinzufügen (https://www.archunit.org/userguide/html/000_Index.html)

Definition der Regeln

Die „Regeln“ werden in Form von UnitTests erstellt:

@Test
public void Services_should_only_be_accessed_by_Controllers() {
    JavaClasses importedClasses = new ClassFileImporter().importPackages("com.mycompany.myapp");

    ArchRule myRule = classes()
        .that().resideInAPackage("..service..")
        .should().onlyBeAccessed().byAnyPackage("..controller..", "..service..");

    myRule.check(importedClasses);
}

@Test

public void Services_should_only_be_accessed_by_Controllers() {

JavaClasses importedClasses = new ClassFileImporter().importPackages("com.mycompany.myapp");

ArchRule myRule = classes()

.that().resideInAPackage("..service..")

.should().onlyBeAccessed().byAnyPackage("..controller..", "..service..");

myRule.check(importedClasses);

}

Annotationen reduziert den Code noch auf die Regeldefinition:

@AnalyzeClasses(packages = "com.mycompany.myapp")
public class MyArchitectureTest {

    @ArchTest
    public static final ArchRule myRule = classes()
        .that().resideInAPackage("..service..")
        .should().onlyBeAccessed().byAnyPackage("..controller..", "..service..");

}

@AnalyzeClasses(packages = "com.mycompany.myapp")

public class MyArchitectureTest {

@ArchTest

public static final ArchRule myRule = classes()

.that().resideInAPackage("..service..")

.should().onlyBeAccessed().byAnyPackage("..controller..", "..service..");

}

Fazit

Sowohl jQAssistant als auch ArchUnit sind OpenSource. ArchUnit ist mit Apache License V2 und jQAssistant GPLv3 lizenziert.

Mit ArchUnit lässt sich die statische Architektur von Java-Projekten auf entwicklerfreundliche Art und Weise automatisiert testen. Es benötigt hierzu keine weitere Infrastruktur und kann als Library in jedes beliebige Java-Projekt eingebunden werden. Zudem bietet ArchUnit eine mächtige API, um eigene Regeln zu definieren.

jQAssistant ist etwas schwergewichtiger und man muss sich zuerst die Skriptsprache Cypher aneignen. Jedoch bietet die Neo4j Datenbank mit den Informationen zur Systemarchitektur viele weitere Möglichkeiten. Zum Beispiel nach verschiedenen Abhängigkeiten zu suchen und diese dann gezielt aufbrechen. Außerdem ist ein automatisiertes Reporting von Strukturen in sicherheitsrelevanten Umfeldern möglich.

Ich würde ArchUnit für jedes professionelle Java Projekt empfehlen. Die Integration ist sehr schnell durchgeführt und die wichtigsten Regeln sind schnell definiert. Bei größeren Projekten und Monolithen würde ich eher auf jQAssistant setzen. Hier ist auch eine manuelle Analyse mittels der Neo4j Datenbank möglich.

Quellen:

https://blogs.oracle.com/javamagazine/unit-test-your-architecture-with-archunit

https://www.archunit.org

https://jqassistant.org

https://blog.seibert-media.net/blog/2018/01/12/werkzeuge-zur-architektur-und-code-validierung-jqassistant

https://blog.jdriven.com/2018/10/testing-the-architecture-archunit-in-practice/

ArchUnit jQAssistant Softwarearchitektur

Mehr...