© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 2: Microservices mit Java EE, Application Server und Docker

Ein Taschenrechner

Mit Standard-Java-8-, Java-EE-7-Bordmitteln, einem Application-Server und Docker bauen wir eine Microservices-Architektur, die schnell und leichtgewichtig ist. Und das Ganze ohne Abhängigkeiten zu Third-Party Libraries. Als Beispiel implementieren wir einen Taschenrechner.

Adam Bien


Video: „Wer testet schon gerne?“ Kugelsicheres Java EE mit möglichst wenig Entwicklerfrustration

ArtikelserieTeil 1: Microservices mit Java EETeil 2: Microservices mit Java EE, Application Server und Docker

Die Effizienz von Java-EE-basierten Microservices lässt sich in der Theorie schwer beschreiben, ein Beispiel soll helfen. Ein Taschenrechner wird mit Java-EE-7-Microservices implementiert und mit Docker in Betrieb genommen. Der Taschenrechner wird dabei in einem Thin WAR mit einer einzigen provided-Abhängigkeit zu javax:javaee-api:7.0 realisiert. Dazu starten wir mit der Implementierung der Addition in einem POJO:

public class OperationService { public int add(int a, int b) { return a + b; }}

Damit hätten wir schon die erste CDI Bean implementiert. Die Veröffentlichung der Logik übernimmt die OperationsResource:

import javax.ejb.Stateless;import javax.inject.Inject;import javax.json.Json;import javax.json.JsonObject;import javax.ws.rs.POST;import javax.ws.rs.Path; @Stateless@Path("operations")public class OperationsResource { @Inject OperationService operations; @POST @Path("addition") public JsonObject addition(JsonObject input) { int a = input.getJsonNumber("a").intValue(); int b = input.getJsonNumber("b").intValue(); int result = operations.add(a, b); return Json.createObjectBuilder(). add("result", result). build(); }}

Die Trennung der beiden Klassen ist zwar technisch nicht nötig, in der Praxis wird allerdings das Testen dadurch erleichtert. Die Resource-Klassen enthalten keine Geschäftslogik und dürfen deswegen nicht getestet werden. Bei dem OperationService handelt es sich dagegen um eine gewöhnliche Java-Klasse, die mit JUnit getestet werden kann.

Zeit sparen

Das Implementieren eines Systemtests dauert nur wenige Minuten:

public class OperationsResourceIT { private Client client; private WebTarget tut; static final String ADDITION_URI = "http://localhost:8080/calculator/resources/operations/addition";  @Before public void init() { this.client = ClientBuilder.newClient(); this.tut = this.client.target(ADDITION_URI); }  @Test public void addition() { JsonObject input = Json.createObjectBuilder(). add("a", 2). add("b", 21). build(); Response response = this.tut. request(MediaType.APPLICATION_JSON). post(json(input)); assertThat(response.getStatus(), is(200)); JsonObject jsonResult = response.readEntity(JsonObject.class); int result = jsonResult.getJsonNumber("r...

Java Magazin
Teil 2: Microservices mit Java EE, Application Server und Docker

Ein Taschenrechner

Mit Standard-Java-8-, Java-EE-7-Bordmitteln, einem Application-Server und Docker bauen wir eine Microservices-Architektur, die schnell und leichtgewichtig ist. Und das Ganze ohne Abhängigkeiten zu Third-Party Libraries. Als Beispiel implementieren wir einen Taschenrechner.

Adam Bien


Video: „Wer testet schon gerne?“ Kugelsicheres Java EE mit möglichst wenig Entwicklerfrustration

ArtikelserieTeil 1: Microservices mit Java EETeil 2: Microservices mit Java EE, Application Server und Docker

Die Effizienz von Java-EE-basierten Microservices lässt sich in der Theorie schwer beschreiben, ein Beispiel soll helfen. Ein Taschenrechner wird mit Java-EE-7-Microservices implementiert und mit Docker in Betrieb genommen. Der Taschenrechner wird dabei in einem Thin WAR mit einer einzigen provided-Abhängigkeit zu javax:javaee-api:7.0 realisiert. Dazu starten wir mit der Implementierung der Addition in einem POJO:

public class OperationService { public int add(int a, int b) { return a + b; }}

Damit hätten wir schon die erste CDI Bean implementiert. Die Veröffentlichung der Logik übernimmt die OperationsResource:

import javax.ejb.Stateless;import javax.inject.Inject;import javax.json.Json;import javax.json.JsonObject;import javax.ws.rs.POST;import javax.ws.rs.Path; @Stateless@Path("operations")public class OperationsResource { @Inject OperationService operations; @POST @Path("addition") public JsonObject addition(JsonObject input) { int a = input.getJsonNumber("a").intValue(); int b = input.getJsonNumber("b").intValue(); int result = operations.add(a, b); return Json.createObjectBuilder(). add("result", result). build(); }}

Die Trennung der beiden Klassen ist zwar technisch nicht nötig, in der Praxis wird allerdings das Testen dadurch erleichtert. Die Resource-Klassen enthalten keine Geschäftslogik und dürfen deswegen nicht getestet werden. Bei dem OperationService handelt es sich dagegen um eine gewöhnliche Java-Klasse, die mit JUnit getestet werden kann.

Zeit sparen

Das Implementieren eines Systemtests dauert nur wenige Minuten:

public class OperationsResourceIT { private Client client; private WebTarget tut; static final String ADDITION_URI = "http://localhost:8080/calculator/resources/operations/addition";  @Before public void init() { this.client = ClientBuilder.newClient(); this.tut = this.client.target(ADDITION_URI); }  @Test public void addition() { JsonObject input = Json.createObjectBuilder(). add("a", 2). add("b", 21). build(); Response response = this.tut. request(MediaType.APPLICATION_JSON). post(json(input)); assertThat(response.getStatus(), is(200)); JsonObject jsonResult = response.readEntity(JsonObject.class); int result = jsonResult.getJsonNumber("r...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang