The goal of MicroProfile is to optimise Java EE for a micro-service architecture. It is based on some of the Java EE specifications and standardise a few technologies from the micro-services space. However, some of the MicroProfile implementations are completely different 'servers', like the KumuluzEE server. So how can you migrate easily from your favorite Java EE server to a MicroProfile implementation? This session shows you an overview of what MicroProfile.IO is and how it relates to Java EE. It then demonstrates with a few examples how you can adjust your Java EE application to incorporate some of the MicroProfile.IO specifications and how you can transform your Java EE application to a MicroProfile.IO one using Thorntail, Payara Micro, and KumuluzEE.

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