Eclipse MicroProfile or in other words, "Optimized Enterprise Java for a Microservices Architecture" is a way to eliminates the risk of vendor lock-in and maintains the developers’ freedom of choice when implementing Microservices. Microservices is the most popular architecture when creating cloud-native applications.
I have written another article which introduces microservices.
https://www.harshajayamanna.com/2019/01/introduction-to-microservices_30.html
Eclipse MicroProfile is an open-source community specification for Enterprise Java microservices.
It is a project under Eclipse foundation and backed by individuals, organizations, vendors.
 |
| Microprofile Community |
I have highlighted the word "specification" in the previous paragraph. That means Microprofile is a specification which can be implemented by anybody and that eliminates the risk of vendor lock-in. Some of the specifications which developers are already familiar with are Java EE 8 Specification and Java Persistence 2.1 Specification.
Current MicroProfile implementations
There are several Microprofile implementations available.
 |
| Microprofile Implementations |
Microprofile has TCKs (test compatibility kits) and these runtime providers have to implement the APIs and pass the TCKs.
More about implementations here.
More about implementations here.
What is inside Microprofile?
Microprofile has extended some of the Java EE specifications to address microservices patterns.
MicroProfile specifications include:
- MicroProfile Config: Modify configuration data from outside an application so that the application itself does not need to be repackaged.
- MicroProfile Fault Tolerance: Leveraging different strategies to guide the execution and result of some logic to build fault-tolerant microservices.
- MicroProfile Health Check: Determine if a computing node needs to be discarded (terminated, shutdown) and eventually replaced by another (healthy) instance.
- MicroProfile Metrics: A unified way for Microprofile servers to export Monitoring data.
- MicroProfile Open API: Providing a unified Java API for the OpenAPI v3 specification.
- MicroProfile Rest Client: Provides a type-safe approach to invoke RESTful services over HTTP.
- MicroProfile JWT Authentication: Using OpenID Connect(OIDC) based JSON Web Tokens(JWT) for role-based access control(RBAC) of microservice endpoints
- MicroProfile Open Tracing API: Defines behaviors and an API for accessing an OpenTracing compliant Tracer object within your JAX-RS application.
MicroProfile 3.0 was released on 11th of June 2019, this release had,
- Java EE 8 continued alignment
- A richer feature set for Rest Client, Metrics, and Health Check
- Metrics and Health Check have introduced breaking API changes
- CDI-based and programmatic interfaces
- Test Compatibility Kit (TCK), Javadoc, PDF doc for download
Why not Java EE/Jakarta EE for Microservices?
Microservices has its benefits and comes with complexities. Java EE is not sufficient for building cloud-native applications such as microservices.
Requirements such as resiliency, monitoring, or distributed tracing are critical. These are currently not covered by standard Java EE. Also, plain Java EE doesn’t easily support injectable configuration.
Even though these aspects are not entirely new, they have become more critical than ever due to these distributed and cloud-native applications.
On the other hand, MicroProfile alone is not sufficient for developing complex enterprise applications because it lacks features such as support for JPA and Concurrency API. I hope these features will be available in the future. Because of these reasons, we have to use application-containers that supports both Java EE and MicroProfile to build applications using MicroProfile and Java EE. MicroProfile can be integrated with Java EE since MicroProfile is based on the Java EE standards.
Spring Boot vs MicroProfile
According to Spring website, the Spring programming model does not embrace the Java EE platform specification; rather, it integrates with carefully selected individual specifications from the EE umbrella such as Servlet API (JSR 340) and WebSocket API (JSR 356). On the other hand, MicroProfile is based on the Java EE standards.
Spring framework was released 16 years ago and MicroProfile is only a few years old. Both frameworks are based on Java. We can do almost everything in MicroProfile that we can do in Spring.
MicroProfile is an open-source community-driven project while Spring is an open-source project managed by Pivotal Software Company. Using Spring means you are locked, but with Microprofile will be free of vendor lock-in.
Spring framework was released 16 years ago and MicroProfile is only a few years old. Both frameworks are based on Java. We can do almost everything in MicroProfile that we can do in Spring.
MicroProfile is an open-source community-driven project while Spring is an open-source project managed by Pivotal Software Company. Using Spring means you are locked, but with Microprofile will be free of vendor lock-in.
When it comes to feature, to implement REST service, Spring uses Spring MVC while Microprofile uses JAX-RS.
For Dependency injection, Spring uses it's core functionality while Microprofile uses CDI.
For Configuration, Spring uses @Value annotation while Microprofile uses @Inject and @ConfigProperty.
Spring Framework has a huge community with compared Microprofile and since Microprofile is based on Java EE, it also has the potential to gain more community involvement easily.
I think is later post, we should discuss more "Spring Boot vs MicroProfile"
For Dependency injection, Spring uses it's core functionality while Microprofile uses CDI.
For Configuration, Spring uses @Value annotation while Microprofile uses @Inject and @ConfigProperty.
Spring Framework has a huge community with compared Microprofile and since Microprofile is based on Java EE, it also has the potential to gain more community involvement easily.
I think is later post, we should discuss more "Spring Boot vs MicroProfile"
Future of MicroProfile
Microprofile has a sandbox for incubating ideas and code. These can be turned into new
specifications in the future according to a defined process. Few of those projects are,
- Long-Running Actions: API for loosely coupled services to coordinate long-running activities.
- Reactive: Objective is to make MicroProfile applications more event-driven, asynchronous and efficient.
- GraphQL: Making GraphQL available for microservice development.
- Concurrency: Introduces APIs - fully compatible with the EE Concurrency specification.
References
- https://microprofile.io
- https://docs.google.com/presentation/d/1BYfVqnBIffh-QDIrPyromwc9YSwIbsawGUECSsrSQB0/edit#slide=id.g5b6a45cdac_0_34
- https://mikecroft.io/2017/07/11/microprofile-1-year-on.html
- https://wiki.eclipse.org/MicroProfile/Implementation
- https://developer.ibm.com/articles/java-ee-jakarta-ee-microprofile-or-maybe-all-of-them/
- https://wiki.eclipse.org/MicroProfile/Implementation#MP_Config_implementations
- https://www.ibm.com/cloud/blog/migrate-java-microservices-from-spring-to-microprofile-p2
- https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html#overview-spring
- https://developers.redhat.com/blog/2018/11/21/eclipse-microprofile-for-spring-boot-developers/
- https://www.ibm.com/cloud/blog/migrate-java-microservices-from-spring-to-microprofile-p2
Comments
Post a Comment