Microservices bouwen met Eclipse
De enthousiaste community werkt hard om van MicroProfile een modern framework te creëren voor het bouwen van oplossingen voor cloud-based Java. Toegegeven, er is nog veel werk aan de winkel om te kunnen concurreren met het immens populaire Spring Boot. Afijn, je kunt dus microservices bouwen met MicroProfile. Maar hoe doe je dat en waarom zou je het willen? Hopelijk zijn die vragen voor jullie beantwoord na het lezen van dit artikel.
Auteur: Edwin Derks is Solutions Architect en CodeSmith bij Ordina JTech en heeft naast Java een passie voor cloud-driven development en serverless architecture.
Het is alweer ruim een jaar geleden dat ik besloot om mezelf weer te gaan verdiepen in de Java EE community. De trigger hiervoor was ik dat ik over dit onderwerp weer colleges en workshops ging geven. Ik stuitte op een paar interessante bewegingen in de Java EE community. Om te beginnen deed Oracle de Java EE specificatie de deur uit en werd het geheel gedoneerd aan de Eclipse community. Zij hebben als doel om Java EE door te ontwikkelen onder de naam Jakarta EE. Daarnaast kwam ik tot de ontdekking dat het Eclipse MicroProfile (kortweg: MicroProfile) project daadwerkelijk een productierijp framework was geworden. Je kunt tegenwoordig daadwerkelijk microservices bouwen voor het Java EE ecosysteem. Kan dat echt? Jazeker! Als ik dit vertel aan mede-developers krijg ik vaak die reactie.
Vanwege mijn enthousiasme voor Java EE heb ik besloten consequent bij te blijven met de ontwikkelingen en deze te gaan delen in mijn omgeving. Het verbaast me dat het bestaan van MicroProfile bij weinig mede-developers bekend is. Een mooie missie voor mij om daar verandering in te brengen, zoals bijvoorbeeld dit artikel schrijven.
MicroProfile is ontstaan als oplossing voor beperkingen in Java EE 7 voor het bouwen van microservices. De specificaties van Java EE 7 zijn niet toereikend om aan de eisen voor o.a. schaalbaarheid, failover en monitoring te kunnen voldoen. Sowieso ontbreekt de mogelijkheid om zogeheten “Uber JAR’s” te bouwen.
Wachten op een Java EE versie waarin specificaties met oplossingen van deze beperkingen beschikbaar zouden komen, was vanwege de astronomische doorlooptijd daarvan voor de community gewoonweg niet acceptabel. Dit had als oorzaak dat de evolutie van Java EE onder het bewind van Oracle trager verliep dan de ontwikkelingen op de softwaremarkt daaromheen. Dit was een doorn in het oog van bepaalde Java EE minnende partijen, zowel de vendors van de applicatieservers als de community. Het was tijd om actie te ondernemen.
En zo geschiedde het dat de Eclipse community destijds de MicroProfile projectgroep oprichtte. Deze had als taak om de beperkingen voor het bouwen van microservices op te lossen door het uitwerken van specificaties hiervoor, als aanvulling op de officiële Java EE 7 specificaties.
De MicroProfile projectgroep heeft eind zomer 2016 een eerste versie gereleased. MicroProfile 1.0 was daarmee geboren, maar bevatte nog helemaal geen MicroProfile specifieke specificaties. Deze versie was gebaseerd op drie Java EE 7 specificaties die de MicroProfile projectgroep kandidaat zag om te (her)gebruiken als basis voor MicroProfile: CDI, JSON-P en JAX-RS.
Kort daarna verscheen de eerste MicroProfile specificatie: Config 1.0, wat ook meteen leidde tot de release van MicroProfile 1.1. Met deze specificatie werd het mogelijk om property injection toe te passen op de members van je enterprise beans. Dat kon nog niet als zodanig met Java EE 7 en daarmee was meteen het nut van MicroProfile bewezen.
Dat had weer als gevolg dat je op applicatieservers die zowel Java EE 7 als MicroProfile ondersteunden, vanaf dat moment enterprise software kon bouwen, zoals je gewend was met Java EE 7. Met natuurlijk als aanvulling dat je vanaf dat moment ook Config 1.0 tot je beschikking had. Tevens kun je met bepaalde implementaties ook je MicroProfile applicaties verpakken als een Uber JAR, maar daarover later meer. Dit alles werd dus mogelijk zonder dat je hoefde te wachten op Java EE 8. Of nog later…
Daarna ging de MicroProfile community los met het uitwerken van nieuwe specificaties. Na versie 1.2 verscheen eind 2017 MicroProfile 1.3, waarin als geheel al een hele lijst nieuwe specificaties aangeboden werd. Denk hierbij aan foutafhandeling, health checks, tracing, een HTTP client en JWT authenticatie. Al deze specificaties vullen ieder voor zich een wens van de community in om microservices mee te bouwen.
Tijdens het schrijven van dit artikel in de zomer van 2018 is de MicroProfile community de laatste hand aan het leggen aan MicroProfile 1.4 en 2.0. MicroProfile 1.4 bevat updates van specificaties zoals evolutie op versie 1.3. Hieronder is de complete set weergegeven.
De stap naar MicroProfile 2.0 zal de Java EE 7 basis van het project upgraden naar Java EE 8. Daarmee worden dus CDI, JSON-P en JAX-RS naar hun Java EE 8 versie geüpgrade. Tevens wordt een splinternieuwe JSON-B 1.0 specificatie toegevoegd. Hiermee heb je een directe object mapping tot je beschikking om (de)serialisatie te doen van Java objecten en JSON data, wat ontbreekt in JSON-P.
De bekende Java EE vendors, zoals RedHat en IBM, leveren intussen implementaties van MicroProfile, zoals respectievelijk Wildfly Swarm en OpenLiberty. Een van de Java EE 8 applicatieservers die tevens MicroProfile ondersteunt, is het op GlassFish gebaseerde Payara 5. Zie de link in de referenties naar Payara om deze applicatieserver te kunnen downloaden.
Je hebt twee mogelijkheden om applicaties te ontwikkelen en runnen met MicroProfile:
Voor beide oplossingen heb je voor ontwikkeling op zijn minst de volgende Maven dependency nodig wanneer je met versie 1.3 aan de slag wilt:
<dependency>
<groupId>org.eclipse.microprofile</groupId>
<artifactId>microprofile</artifactId>
<version>1.3</version>
<type>pom</type>
</dependency>
Ontwikkel je vanilla MicroProfile voor een Java EE applicatieserver die MicroProfile ondersteunt zoals Payara, dan ben je hiermee al geholpen. Wil je de applicatie als JAR verpakken met ingebakken server, dan moet je daarvoor nog vendor-specifieke Maven configuratie toevoegen. Een voorbeeld van hoe je dit doet met Wildfly Swarm, dat volgt later.
De kracht en filosofie van Java EE blijven bestaan in MicroProfile, omdat je nog steeds tegen een specificatie kunt ontwikkelen en een applicatieserver de implementatie laat regelen. Een MicroProfile HealthCheck kun je eenvoudig bouwen en runnen op Payara op de volgende manier.
Creëer een Maven project met de volgende eigenschappen:
Maak een Java klasse met de volgende code. Deze definieert een HealthCheck die met CDI gevonden en beschikbaar gesteld wordt op je applicatieserver.
import org.eclipse.microprofile.health.Health;
import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import javax.enterprise.context.ApplicationScoped;
@Health
@ApplicationScoped
public class JavaMagazineHealthCheck implements HealthCheck {
@Override
public HealthCheckResponse call() {
return HealthCheckResponse
.named(“java-magazine-health-check”)
.withData(“article-name”, “Microservices bouwen met Eclipse MicroProfile”)
.withData(“author-name”, “Edwin Derks”)
.up()
.build();
}
}
Merk op dat .up() de waarde “true” retourneert die aangeeft dat je draaiende applicatie healthy is. Zijn tegenhanger down() doet het omgekeerde. Je hebt tevens state (boolean) tot je beschikking waar je een method call in kwijt kunt die bepaalt of je service healthy is. Denk aan het checken van beschikbaarheid van een database, JVM metrics of beschikbaarheid van een externe service.
Dit is alles wat nodig is om een HealthCheck beschikbaar te stellen bij het starten van Payara. Door het aanroepen van de volgende URL kun je de HealthCheck aanroepen:
http://localhost:8080/health
Verwacht dan deze output:
{
outcome: “UP”,
checks:
[
{
name: “java-magazine-health-check”,
state: “UP”,
data:
{
author-name: “Edwin Derks”,
article-name: “Microservices bouwen met Eclipse MicroProfile”,
},
}
],
}
Merk op dat de HealthCheck beschikbaar komt onder het root pad van de applicatieserver en niet onder het context pad van de applicatie zelf.
Mocht je eerdergenoemde MicroProfile applicatie willen bouwen als Uber JAR, dan kun je daar onder andere Red Hat’s Wildfly Swarm voor gebruiken. Een aanvulling op de eerder genoemde Maven configuratie is dan de nodige vendor-specifieke Wildfly Swarm Maven Plugin die de JAR bouwt.
Packaging ‘jar’
<plugins>
<plugin>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<version>2018.5.0</version>
<executions>
<execution>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Voer nu de volgende Maven commando’s uit:
mvn clean package
java -jar <<het pad naar de gebouwde jar>>
Wederom moet je applicatie beschikbaar zijn onder:
http://localhost:8080/health
Het gegeven voorbeeld is natuurlijk maar het puntje van het topje van de ijsberg van de mogelijkheden die de MicroProfile specificaties bieden, zeker als je de verschillende vendor implementaties in acht neemt. Een leuk detail is dat je zelfs minder code nodig hebt om een MicroProfile applicatie mee te bootstrappen, dan dat je nodig hebt om datzelfde te doen met Spring Boot. En dat is een mooie prestatie.
Waarom je zou overwegen om MicroProfile te gaan gebruiken voor je microservice projecten in plaats van bijvoorbeeld Spring Boot? Uiteraard is Spring Boot een bewezen, generieke optie waarmee je soortgelijke software kunt bouwen, maar dat geldt ook voor MicroProfile. Ik ben van mening dat andere variabelen dan alleen simpelweg de beschikbare functionaliteit van MicroProfile en Spring Boot een rol spelen bij het kiezen. In het geval van MicroProfile zal het meer een persoonlijke voorkeur zijn wanneer je al bekend en uiteraard tevreden bent met het toepassen van Java EE. Daarnaast heb je op je project of bedrijf misschien al productie support lopen bij een van de vendors die Java EE en MicroProfile implementeren.
Verschillende vendors hebben al implementaties voor MicroProfile vanaf versie 1.2 beschikbaar waarmee je aan de slag kunt:
Nu versie 1.4 en 2.0 inmiddels beschikbaar zijn, vermoed ik dat implementaties en support hierop ook snel gaan volgen.
Zoals eerder vermeld, is MicroProfile ontstaan voor het bouwen van microservices in het Java EE ecosysteem. Omdat de basis bij Java EE ligt, blijft het een feit dat MicroProfile een verlengde is van die basis.
Dus wat gaat er gebeuren als die basis gaat veranderen? MicroProfile 2.0, gebaseerd op Java EE 8, is onderhevig aan de doorontwikkeling van Jakarta EE voor de evolutie van hun Java EE gebaseerde componenten. Hoeveel beweging er nou daadwerkelijk in de ontwikkeling van Jakarta EE zit, dat is momenteel nog onduidelijk.
Nu het eigenaarschap van zowel Java EE als MicroProfile bij Eclipse ligt én beide projecten open source zijn, is het misschien mogelijk beide projecten weer te laten samensmelten. Eén van de projecten zou daarmee leidend kunnen worden en de andere kanaliseren. Ik heb over dit idee gespard met enkele leden van MicroProfile. De ideeën zijn er wel, maar een dergelijke samensmelting gaat er op de korte termijn echt niet komen. Waarschijnlijk zal dit ook hoger in de boom van Eclipse besloten moeten worden.
De MicroProfile projectgroep is druk bezig om specificaties toe te voegen voor bijvoorbeeld CQRS, Event Sourcing, Reactive en Data Access. Daarnaast zijn ze aan het kijken of de filosofie van MicroProfile nog wel spoort met wat het framework op dit moment voorstelt. Men begint zich te realiseren dat je veel meer typen software kunt bouwen met MicroProfile dan louter software die aan het microservices gedachtengoed voldoet. Zeker als je een volwaardige applicatieserver, zoals Payara, in acht neemt die zowel Java EE (wellicht later Jakarta EE) als MicroProfile ondersteunt. In hoeverre MicroProfile dan micro blijft, is ook een mooi onderwerp voor discussie.
Meningen verschillen hierover, maar je kunt niet ontkennen dat er potentie zit in de visie waar de Jakarta EE en MicroProfile community naar toe willen. Eclipse wil uiteraard hun Jakarta EE en MicroProfile projecten weer een belangrijke speler laten worden bij het bouwen van enterprise software, met het oog op cloud-gebaseerde oplossingen. Hoe dit gaat uitpakken gaan we de komende jaren meemaken. Waar het ook heen gaat, ik ga mijn best doen jullie over de ontwikkelingen op de hoogte te stellen.
https://projects.eclipse.org/projects/technology.microprofile
https://microprofile.io/blog/2018/06/eclipse-microprofile-1.4-2.0-available
