Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

MicroProfile Status in Version 1.3

DZone's Guide to

MicroProfile Status in Version 1.3

Get an overview of Eclipse MicroProfile 1.3 and helps you to get started with the specification to optimize Enterprise Java for microservices architecture.

Free Resource

Learn why microservices are breaking traditional APM tools that were built for monoliths.

MicroProfile Status in Version 1.3

Launched nearly two years ago, the Eclipse MicroProfile project is moving fast with four releases and eight subspecs having at least two implementations each. Because it's a fast-moving target, this post tries to give an overview of MicroProfile 1.3, which was released on September 30th, and helps you to get started with the specification.

What Is MicroProfile?

Before you started reading this post, you probably had an idea of what MicroProfile is. But to make things clearer, I'll quote the microprofile.io website definition below:

"The MicroProfile is a baseline platform definition that optimizes Enterprise Java for a microservices architecture and delivers application portability across multiple MicroProfile runtimes. The initially planned baseline is JAX-RS CDI JSON-P, with the intent of community having an active role in the MicroProfile definition and roadmap."

In other words, MicroProfile is a platform that leverages JAX-RS, CDI, and JSON-P (and possibly other specifications in the future) to easily produce microservices.

On top of these three well-known Java EE (or Jakarta EE) specifications, MicroProfile adds its own layer to provide value-added features for microservices (but also for any Java EE application).

MicroProfile is an Eclipse Foundation project, making it totally vendor-neutral.

Vendors and Projects Supporting MicroProfile

MicroProfile has tremendous momentum and wide adoption by vendors. The main products and projects that implement it are:

  • WildFly Swarm by Red Hat
  • Open Liberty by IBM
  • Apache TomEE
  • Payara Micro
  • Apache Hammock
  • KumuluzEE

The list is not exhaustive and is growing with each MicroProfile version.

What's Included?

In 1.3 version, the MicroProfile specifications include the following:

  • Config 1.2 (updated from the previous version)
  • Fault Tolerance 1.0
  • Health Check 1.0
  • Metrics 1.1 (updated from the previous version)
  • JWT Auth 1.0
  • MicroProfile OpenAPI 1.0 (new specification)
  • MicroProfile OpenTracing 1.0 (new specification)
  • MicroProfile Rest Client 1.0 (new specification)

Let's take a quick look at each of those.

Umbrella Specification

The MicroProfile umbrella spec defines minimum version for JDK, CDI, JAX-RS, and JSON-P for MicroProfile. Right now, these versions are aligned on Java EE 7, but implementers can choose to use a later version if they wish.

This specification could be wrongly assumed to be a bill of material in a Maven POM file. In fact, it goes beyond that. Community members agreed on three important points that make the spec shine even more:

  1. Consistency for doc tools: While the spec is not forcing subspecs to do so, every MicroProfile contributor agreed on using the Asciidoc format and the Asciidoctor toolchain to produce documentation.
  2. Consistency for tools in TCKs: A Technology Compatibility Kit is a very important part of a specification; it helps implementers to validate their code against a test collection designing a "living" contract to respect the spec. As was done for documentation, an agreement was reached to use TestNG and Arquillian to produce TCKs for all MicroProfile specs.
  3. CDI-centric approach: Again, this is not a written rule but an implicit guideline to make sure that the CDI programming model is present in all MicroProfile subspecs to provide a consistent user experience for MicroProfile users.

Points 1 and 2 are important to make contributors' lives easier for and implementers. As a contributor, when switching from one spec to another, I won't have to learn another way to write docs and tests. This consistency is a way to empower contribution coming from the community.

Point 3 is a way to make adoption easier. Having a consistent way to consume features and develop makes the learning curve smaller and allows teams to focus on their business part instead of on technical stuff. Besides, as CDI spec lead, I can approve only CDI programming model adoption for MicroProfile.

The MicroProfile umbrella spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>1.3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>

MicroProfile Config Specification 1.2

MicroProfile Config is used by all other specs to provide a consistent way to read configuration information from various sources. While it provides CDI support, this spec allows accessing configurations without using CDI. It is inspired by projects such as Apache DeltaSpike and Apache Tamaya.

The MicroProfile Config spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.config</groupId>
    <artifactId>microprofile-config-api</artifactId>
    <version>1.2</version>
</dependency>

MicroProfile Fault Tolerance 1.0

This spec allows developers to add a fault tolerance mechanism to microservices with the Circuit Breaker and Bulkhead patterns, asynchronous operations, and Retry or Fallback policies.
Version 1.0 is fully CDI-oriented by providing interceptor binding to apply these policies to a chosen method or class.

The MicroProfile Fault Tolerance spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.fault-tolerance</groupId>
    <artifactId>microprofile-fault-tolerance-api</artifactId>
    <version>1.0</version>
</dependency>

MicroProfile Health Check 1.0

This spec provides a way to probe the state of a computing node from another machine. This spec is not designed to be used by human operators but by automated systems in a cloud infrastructure to decide if a given computing node should be discarded or replaced by another node.

The MicroProfile Health Check spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.health</groupId>
    <artifactId>microprofile-health-api</artifactId>
    <version>1.0</version>
</dependency>

MicroProfile Metrics 1.1

This specification provides a unified way for microservices developed with MicroProfile to expose monitoring data to management agents. As with the other specifications, it is not limited to MicroProfile and can also be used in any Java development to expose telemetry data.

The MicroProfile Metrics spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.metrics</groupId>
    <artifactId>microprofile-metrics-api</artifactId>
    <version>1.1</version>
</dependency>

MicroProfile JWT Auth 1.0

This MicroProfile subspec adds security to developed microservices. By using JSON Web Token (JWT) propagation, it helps keep security information across different services using a RESTful approach.

The MicroProfile JWT Auth spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.jwt</groupId>
    <artifactId>microprofile-jwt-auth-api</artifactId>
    <version>1.0</version>
</dependency>

MicroProfile OpenAPI 1.0

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.

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs that allows both humans and computers to discover and understand the capabilities of the service without access to source code or documentation or through network traffic inspection.

The MicroProfile OpenAPI spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.openapi</groupId>
    <artifactId>microprofile-openapi-api</artifactId>
    <version>1.0</version>
</dependency>

MicroProfile OpenTracing 1.0

This MicroProfile specification defines behaviors and an API for accessing an OpenTracing-compliant Tracer object within your JAX-RS application. The behaviors specify how incoming and outgoing requests will have OpenTracing Spans automatically created. The API defines how to explicitly access a configured Tracer object.

The MicroProfile OpenTracing spec's links:

The spec's Maven artifact:

<dependency>
    <groupId>org.eclipse.microprofile.opentracing</groupId>
    <artifactId>microprofile-opentracing-api</artifactId>
    <version>1.0</version>
</dependency>

MicroProfile Rest Client 1.0

This MicroProfile spec provides a type-safe approach to invoke RESTful services over HTTP. As much as possible, the MicroProfile Rest Client spec attempts to use JAX-RS 2.0 APIs for consistency and easier re-use.

The MicroProfile Rest Client spec's links:

The spec's Maven artifact:

<dependency>
 <groupId>org.eclipse.microprofile.rest.client</groupId>
 <artifactId>microprofile-rest-client-api</artifactId>
 <version>1.0</version>
</dependency>

Conclusion

If you want to learn more about MicroProfile, keep an eye on the microprofile.io website or on the MicroProfile section of the Eclipse website. You may also want to follow @MicropProfileIO on Twitter.

If you want to contribute to the spec or to one of the implementations, microprofile.io is the best place to find information and get started. Subscribing to the MicroProfile Google group will probably your first step.

Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.

Topics:
microservices ,microprofile ,java ,enterprise java ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}