With the transition of Java EE to Jakarta EE, you can now adopt both Jakarta EE standards and MicroProfile stack for your projects. In this tutorial we will show a step-by-step guide to bootstrap a MicroProfile application and how to deploy it on most common Runtimes.
MicroProfile in a nutshell
The era of monolithic application appears obsolete as many enterprises in the industries are looking for frameworks and APIs that would enable them to move efficiently into the cloud and microservies world.
Therefore, in parallel to the evolution of Jakarta EE, that will remain the main reference for complex scenarios (such as XA Transactions or communication with communication a Common Object Request Broker Architecture) a new architecture called MicroProfile emerged.
MicroProfile API components are built upon the model of Java EE making natural the transition to microservices development. Therefore, you will be able to reuse the valuable knowledge of java EE you have accumulated in these years, while having the flexibility to use multiple vendor specs to define application requirements. At this point we should briefly define what MicroServices are.
The best fitting definition for MicroServices is:
“You can think of microservices as modular, decoupled applications that can be independently deployed, modified, scaled and integrated with other systems and services.
Microservices are agile components that can be easily updated therefore you won’t need to stop the entire platform for days, until changes are propagated.”
Microservices vs SOA
You can think of Microservices as an evolution of the Service Oriented Architecture (SOA), with some similarities and notable differences though.
Let’s start from the similarities: both SOA and microservices architectures, unlike monolithic apps, deliver components which are solely responsible for a particular task. It follows that each component can also be developed using a different technology stack.
The first difference is that when developing microservices, each team can develop and deploy applications independently of other services. On the other hand, when using SOA, each team developing a service needs to know about the common communication mechanism to be used to achieve the SOA.
The second main difference between SOA and microservices is that in a SOA the Service Bus, used as communication layer between services, can potentially become a bottleneck or single point of failure. This does not happen in a microservices architecture where each service works independently from others so you can can fine tune its fault tolerance and resiliency.
In terms of storage, a SOA architecture normally used traditional shared data storage solution like a RDBMS. A microservice architecture, on the other hand, has a more flexible approach which is often declined as container native storage. That is, you define your storage as a container itself, just like your applications. Every approach as pros and cons: using a shared data solution makes easier to re-use data between applications. On the other hand, for applications that run independently from each other, an independent storage solution (like container storage) can be easier to bootstrap and to maintain.
Finally, the last difference, as you can imagine, is the size. A Microservice is a significantly smaller artifact and can be deployed indendently from other services. On the other hand, a SOA can be either deployed as a monolith or it can be as well comprised of multiple smaller services.
Developing with MicroProfile
Having clear what a MicroService is, how do we develop them using the MicroProfile architecture ? The main standard that is emerging is Eclipse MicroProfile which is a collection of community-driven open source specifications that define an enterprise Java microservices platform.
Here is an overview of the technology stack that is available using the MicroProfile 5.0 stack:
As you can see, the technology stack mostly focuses on REST and CDI Services for the interaction between the microservices. JSON-P and JSON-B is also included out of the box as common transport language. (In blue you can see recently updated API in the Microprofile 2.0 spec)
There are several Runtimes where you can run MicroProfile API. Here we will mention just the most popular options:
- WildFly Application Server / JBoss EAP (with Expansion Pack)
- Quarkus
- Payara Application Server
- IBM OpenLiberty
- Tomtribe TomEE
Coding a MicroProfile application
In order to kickstart a MicroProfile application, you can use the online MicroProfile Starter available at: https://start.microprofile.io/
Select the MicroProfile Version, Maven GAV, Java version and Examples from the specification. Once done, download the example project and import it into your Development environment:
Using the REST API to bootstrap Microprofile applications
On the other hand, if you want to automate the process or adding some cool bash aliases to your environment, then you should check out the MicroProfile CLI. The Microprofile CLI enables you to generate applications with curl or PowerShell, without the distraction of opening a web browser
How to list the available Microprofile Versions in the starter:
curl https://start.microprofile.io/api/mpVersion ["MP50","MP41","MP40","MP33","MP32","MP30","MP22","MP21","MP20","MP14","MP13","MP12"]
How to list all available API Starters for all Runtime Environments in a specific Microprofile version:
curl https://start.microprofile.io/api/mpVersion/MP30
{"supportedServers":["LIBERTY","THORNTAIL_V2","HELIDON"],"specs":["CONFIG","FAULT_TOLERANCE","JWT_AUTH","METRICS","HEALTH_CHECKS","OPEN_API","OPEN_TRACING","REST_CLIENT"]}]
How to create a MicroProfile project for a specified Runtime environment (include all available API)
curl -O -J 'https://start.microprofile.io/api/project?supportedServer=THORNTAIL_V2'
How to create a MicroProfile project for a specified Runtime environment (include only a subset of API)
curl -O -J 'https://start.microprofile.io/api/project?supportedServer=THORNTAIL_V2&selectedSpecs=METRICS'
How to create a MicroProfile project setting all available options
$ curl -O -J -L 'https://start.microprofile.io/api/1/project?supportedServer=LIBERTY&groupId=com.example&artifactId=myapp&mpVersion=MP22&javaSEVersion=SE8&selectedSpecs=CONFIG&selectedSpecs=FAULT_TOLERANCE&selectedSpecs=JWT_AUTH&selectedSpecs=METRICS&selectedSpecs=HEALTH_CHECKS&selectedSpecs=OPEN_API&selectedSpecs=OPEN_TRACING&selectedSpecs=REST_CLIENT'
Adapting the Microprofile Starter for your Runtime
The default example project contains a Maven profile for Liberty application server and the dependencies to build it. If you want to adapt it for your specific Runtime you can edit the pom.xml including the appropriate dependencies or plugins. For example, if using WildFly runtime, check this article: How to build and deploy Microprofile applications on Wildfly On the other hand, if you want to see an example of Microprofile applications on different Runtimes (Quarkus, Tom EE) check this article: http://Getting started with MicroProfile FaultTolerance API
Conclusion
In conclusion, Start.MicroProfile.io proves to be an invaluable resource for bootstrapping MicroProfile applications. By leveraging its user-friendly interface and customizable options, developers can quickly generate a solid foundation for their projects. Throughout this article, we have explored the step-by-step process of using Start.MicroProfile.io, empowering you to effortlessly initialize MicroProfile applications tailored to your specific requirements.
