This document discusses gradually migrating Java EE applications to use MicroProfile features. It presents two options for the migration: 1) Adding MicroProfile implementations to an existing Java EE server or 2) Using a Java EE server that integrates MicroProfile implementations. The document demonstrates migrating a sample mortgage application first using Thorntail and then Payara Micro. It highlights some issues that may occur and advantages of each approach.

1. Gradual migration Java EE
to MicroProfile

2. What You’ll Learn Today
• Relation between Java EE, MicroProfile,…
• MicroProfile implementations overview
• Using MicroProfile
• Some examples in how migration can be done

3. Rudy De Busscher
• Payara
• Service team
• JSR-375
• Java EE Security API Expert group member
• Committer in Eclipse EE4J groups
• Java EE Believer
@rdebusscher
https://blog.payara.fish/
https://www.atbash.be

4. AGENDA
Today’s Challenges
Migration options
Plain Java EE Servers
Pimped Java EE Servers

5. Code
Java EE
• Backwards compatible enterprise apps
• Long term projects
• Also popular under start-ups
• Focus on business logic
• Slowly moving
• Not your silver bullet

6. Java EE 8 contents
From Oracle Blog

7. Arch
MicroServices
• Vaguely defined
• Not about size
• Service per domain
• Independently deployable
• Architectural style
• Not your silver bullet

8. MicroServices topology

9. Ops
• Fat Jar
• Application + Server code in 1 file
• Web Artifact (WAR, …)
• Application deployable on multiple implementations
• Hollow jar
• Server code in 1 file; runs your WAR
• Containerized
• Run your Server + App easy on multiple OS with lightweight VM.
Deployment style

10. Best Pract
1. Codebase: One codebase tracked in revision control, many deploys
2. Dependencies: Explicitly declare and isolate dependencies
3. Config: Store config in the environment
4. Backing services: Treat backing services as attached resources
5. Build, release, run: Strictly separate build and run stages
6. Processes: Execute the app as one or more stateless processes
7. Port binding: Export services via port binding
8. Concurrency: Scale out via the process model
9. Disposability: Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity: Keep development, staging, and production as similar as
possible
11. Logs: Treat logs as event streams
12. Admin processes: Run admin/management tasks as one-off processes
12 factor app

11. Arch
Best Pract
• Asynchronous data streams
• Events
• Hot/Cold (active/Inactive)
• Asynchronous IO (non blocking)
Reactive

12. Reactive concepts
From Reactive Manifesto

13. Today’s challenges

14. Code
MicroProfile
• Adds a few missing things to Java EE
• Makes Java EE more MicroService-ish
• Config, Rest invocation, Security, Tracing, Metrics, Non-
blocking

15. • MicroProfile can make your Java EE application
more MicroService-ish and compliant with the 12
Factor and reactive approach.
MP Goal

16. AGENDA
Today’s Challenges
Migration options
Plain Java EE Servers
Pimped Java EE Servers

17. Migration ?
• Gradual
• Large (monolith) app
• MicroServices

18. MicroProfile implementations
• Dedicated ‘Server’ implementations
• KumuluzEE, Hammock, Launcher
• Recently Thorntail v4, Helidon

19. MicroProfile implementations
• Individual frameworks
• Like SmallRye, Apache (Geronimo) umbrella
• Added to classic Java EE servers.
• Payara, OpenLiberty, (TomEE, WildFly)

20. Migration Options
1. Using classic servers
2. Use MP containing Java EE servers

21. Demo app
Mortgage

22. Start from
• Java EE
• Monolith
• JSF Front
• CDI services

23. Demo

24. AGENDA
Today’s Challenges
Migration options
Plain Java EE Servers
Pimped Java EE Servers

25. Option 1
• Java EE server
• No MicroProfile implementations available
• Ex WebLogic
• Add MP spec implementation(s) to server
• Adding to WAR not option
• Most use CDI extensions
• Result in class loading issues in impl code in JAR.

26. MP Impl in demo = KumuluzEE
Option 1 Overview

27. Demo

28. Option 1 issues
• Issues
• CDI injection not always work properly
• Use programmatic lookup
• Goals met
• Easier config of external services

29. • Call Rest endpoints easier
• Add automatically some filters
• Metrics
• Tracing
• Authentication
• Standalone implementations
• Apache CXF
• SmallRye Rest client
MP Rest Client

30. • Standalone implementation vs Java EE servers
• Bring their own Rest client
• Clashes with server defined one
• Atbash Rest Client uses the available client
• Not certified / fully compatible
• Workaround
MP Rest client issues

31. Demo

32. • All ‘services’ separated
• Front end can be rewritten
• Use of uber jars
• Example
• Thorntail v2 (nee WildFly Swarm)
Decomposed

33. MP lmpl in demo = Thorntail v2
Option 1 decomposed

34. AGENDA
Today’s Challenges
Migration options
Plain Java EE Servers
Pimped Java EE Servers

35. Option 2
• Use Java EE server
• Which has MP implementations on board
• Example
• OpenLiberty
• Payara Server

36. Advantage
• Less different servers used
• MP Perfectly integrated
• Use any mixture of traditional Java EE and MicroServices
(MP)

37. demo = Payara Micro
Option 2 decomposed

38. Demo

39. Take aways
• MicroProfile brings current best practices and modern
architectural styles into Java EE/Jakarta EE
• Can be used on any Java EE server (with limitations)
• Allows gradual adaptation of your app (no big bang)
• More and more Java EE servers incorporate it.

40. Code
• Demo applications
• https://github.com/rdebusscher/gradual-migration-mp
• Atbash Rest Client
• https://github.com/atbashEE/atbash-rest-client

41. Q & A

42. Thank You
Not using the Payara Platform yet? Download the open
source software: Payara Server or Payara Micro
https://payara.fish/downloads
Need support for the Payara Platform?
https://payara.fish/support