Tutorial: A step-by-step guide from traditional Java EE to reactive microservice design

Have you wondered how you can improve the design of your applications to improve its performance? You probably heard that reactive design can lead to better response times and more flexible apps. But you’re asking: Do I need to rewrite my apps from scratch? Do I need to learn a new framework for all that? The answer is no, especially if your application is built on top of Java EE and Java 8.

Together, we will explore how we can migrate parts of an existing Java EE application step-by-step, in order to increase its response time, throughput, and make it more flexible and robust. We will go through examples how to apply reactive design to a traditional codebase, using standard API from Java SE, Java EE and MicroProfile, split a monolith into several microservices and deploy them to cloud.

4th February at JFokus
https://www.jfokus.se/jfokus19/talks/2693

Source code and instructions: https://github.com/OndrejM-demonstrations/ReactiveWay-cargotracker-ext

Transcript

1. A step-by-step guide from traditional Java EE to reactive microservice design Ondrej Mihályi @OndroMih https://ondro.inginea.eu
2.  Engineer at Payara  Java EE developer, lecturer  MicroProfile member  Czech JUG leader Ondro Mihályi Web: ondro.inginea.eu www.payara.fish Twitter: @OMihalyi
3.  Reactive improvements  Separation to micro-svc  Deploy with Docker https://github.com/OndrejM-demonstrations/ ReactiveWay-cargotracker-ext Agenda
4. @ONDROMIH Majority of the enterprise code Request started → resource required (DB, WS, files) → request the resource → the resource is slow WHAT DO WE DO? (hint: it’s quite natural)
5. @ONDROMIH We simply...
6. @ONDROMIH We simply... ...WAIT No shame, we all do it  Simple  Thread-safe  Enough in most cases
7. @ONDROMIH But what if...
8. @ONDROMIH If waiting is too long...  Thread resources are wasted  Processing may slow down or halt if all threads waiting  Users don’t receive a timely feedback  Failures lead to more failures
9. @ONDROMIH If waiting is too long...  Thread resources are wasted  Processing may slow down or halt if all threads waiting  Users don’t receive a timely feedback  Failures lead to more failures
10. @ONDROMIH Reactive manifesto http://www.reactivemanifesto.org/
11. @ONDROMIH Reactive idea in a nutshell Single-threaded Reactive - not bound to a thread
12. @ONDROMIH Threads reused between calls
13. @ONDROMIH Example traditional application We’re going to improve it reactively Original project: https://github.com/javaee/cargotracker Reactive improvements: https://github.com/OndrejM-demonstrations/Rea ctiveWay-cargotracker-ext
14. @ONDROMIH Traditional design
15. @ONDROMIH More reactive design
16. @ONDROMIH Chaining callbacks CompletableFuture in Java 8  complete, completeExceptionally  thenAccept, thenApply, thenCompose  exceptionally Alternatively use third-party libraries  RxJava observables
17. @ONDROMIH 3. Messages WebSocket, Server-Sent Events CDI events  Light-weight but extensible API  Events don’t cross JVM boundaries  Can we turn them into messages?
18. @ONDROMIH Even more reactive design
19. @ONDROMIH Simple messaging and caching Payara CDI Event Bus  Async events on all nodes  On top of CDI events  Uses Hazelcast JCache API  Scalable distributed memory  Replication and failover @Inject @Outbound Event<MyMsg> ev; /* handle in the same or a different JVM: */ void handle(@Observes @Inbound MyMsg ev) { … }
20. @ONDROMIH Multiple threads, need to track origin and arrival of responses, errors may be unnoticed, new design patterns Don’t over-engineer, but leave space for future improvements Java EE and MicroProfile allow for gradual improvements Reactive programming isn’t easy
21. @ONDROMIH Thank you!