MicroProfile® and its Ecosystem
The MicroProfile® 4.1 version is getting released and is soon available for use. One might what does it exactly entail and what is MicroProfile® about exactly? What are the cons of having a joined effort in providing uniform and coherent API specifications across several vendors? In this guide I will demonstrate a few examples about how it can look in practice with Quarkus as a chosen vendor implementation.
Looking a the newest release we find the following outline.
MicroProfile® 4.1
Release Date: Wednesday, July 7, 2021
Note that MicroProfile Health 3.1 is the only updated specification to be included in this release. The eco system itself consists of several specifications which cover different topics in different areas. In the newest release we can see these changes.
- Config 2.0
- Fault Tolerance 3.0
- Health 3.1*
- JWT RBAC 1.2
- Metrics 3.0
- Open API 2.0
- Open Tracing 2.0
- Rest Client 2.0
What is MicroProfile®?
So what is it and what does it really solve?
When you use MicroProfile you are free to choose any compliant runtime and the slogan “Write once, run anywhere” becomes great again. Being able to move your applications to different runtimes gives you the freedom to choose the best vendor for your needs, and when you are no longer satisfied, or if a better one comes up, you can just switch it, since using MicroProfile helps you avoid the vendor lock-in.
How did it call come together?
The MicroProfile® Community Creation
Seeing the slow movement of Java EE, a few industry leaders got together to discuss the path forward for the influence of Java in the Enterprise and Microservice domin. On 14th June 2016, IBM, Red Hat, Payara, LJC, Tomitribe and other independents proudly established the MicroProfile community and the domain https://microprofile.io was secured. On 27th June 2016, at DevNation keynote in San Francisco, California, MicroProfile was formally announced.
Many innovative “microservice” Enterprise Java environments and frameworks already exist in the Java ecosystem. These projects are creating new features and capabilities to address microservice architectures — leveraging both Jakarta EE/Java EE and non-Jakarta EE technologies.
The goal of the MicroProfile® project is to iterate and innovate in short cycles to propose new common APIs and functionality, get community approval, release, and repeat.
The MicroProfile® basically provides a coherent API specification which whatever project can decide to follow, implement and market themselves with.
This can give some insights in choosing the appropriate technology that will leverage the Java Enterprise based microservice with best practices when it comes to building resilient and coherent applications.
Vendor Implementations
Currently we can find the following supported vendor implementations.
- KumuluzEE https://ee.kumuluz.com/
- Open Liberty https://openliberty.io/
- Wildfly https://www.wildfly.org/
- Payara Micro https://www.payara.fish/
- Helidon https://helidon.io/
- Quarkus https://quarkus.io/
One might wonder why micronaut for instance is not visible in the list of vendors. Micronaut also supports the Retry, Fallback, and Circuit Breaker patterns but it relies more on Aspect Oriented Programming implementations and therefor avoids using reflection for its cross cutting concerns. Micronaut uses its own definitions inspired by other frameworks like Spring.
Eclipse MicroProfile Starter
Each MicroProfile version offers a suite of specifications and is implemented by a set of application servers. The different specs can be generated using the following microprofile starter.
The MicroProfile Starter helps developers kickstart their microservices development journey, choosing the runtime they’re most comfortable with from the list of available implementations for the MicroProfile version selected.
This means you can use whatever Runtime platform version and see which MicroProfile® compliant version is available along with with specifications you want to use for your application. I have selected a few to demonstrate what will be provided when using the kick starter for the different specifications. All of these are chosen with Quarkus as the actual vendor implementation.
Microprofile Fault Tolerance
To enable resiliency, the vendor implementations contains an implementatioMicroProfile®n of the MicroProfile Fault Tolerance specification to provide @Retry, @Timeout, @Fallback, and @CircuitBreakercapabilities (as demonstrated in the following class). There are numerous resources describing the behavior of circuit breakers and how they can be applied to the application, and what type of strategy can be provided in case of a connection surge.
Microprofile Metrics
A specification aims at providing a unified way for Microprofile servers to unified Java API, that all (application) programmers can use to expose their telemetry data. MicroProfile Metrics provides a way to register Application-specific metrics to allow applications to expose metrics in the application scope and that can be later exposed through for example a Promethus compliant endpoint.
Microprofile Open API
This MicroProfile specification aims at providing a unified Java API for the OpenAPI v3 specification, that all application developers can use to expose their API documentation.
When looking at our kick start project we get the following provided for us.
Microprofile Health
This specification provides different kinds of health check procedures. Difference between them is only semantic. The nature of the procedure is defined by annotating the HealthCheck procedure with a specific annotation.
- Readiness checks defined with
@Readinessannotation - Liveness checks defined with
@Livenessannotation
Health check procedures are CDI beans, therefore, they can also be defined with CDI producers. So the above example can look something like this.
Finally, for just the simplest of health checks. All checks fall under same semantic health check.
@ApplicationScoped
@Liveness
@Readiness
public class MyCheck implements HealthCheck {
public HealthCheckResponse call() {
[...]
}
}Microprofile Rest Client
The MicroProfile Rest Client provides a type-safe approach to invoke RESTful services over HTTP. As much as possible the MP Rest Client attempts to use Jakarta RESTful Web Services 2.1 APIs for consistency and easier re-use.
package com.dvddhln.demo.microprofile.with.quarkus.client;import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;import javax.enterprise.context.ApplicationScoped;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;@RegisterRestClient
@ApplicationScoped
public interface Service {@GET
@Path("/{parameter}")
String doSomething(@PathParam("parameter") String parameter);}
Microprofile Config
MicroProfile Config uses Contexts and Dependency Injection (CDI) to inject configuration property values directly into an application without requiring user code to retrieve them. The injected values are defined as static because they are set only at application startup.
The API combines configuration values from multiple sources, each known as a ConfigSource. Each ConfigSource has a specified priority, defined by its ordinal value. A higher ordinal means that the values taken from this ConfigSource will override values from ConfigSources with a lower ordinal value.
With this in mind, one can in theory replace their vendor stack towards another vendor, if requirements should change, however it all depends on the context. There should not be any major changes for the shift in case there are no known compatibility issues between versions.
I have omitted these below in case one wants to delve into the details and usage for security and tracing of a Microprofile compliant application.
Good luck!
