Chapter 2. Understand MicroProfile

2.1. MicroProfile Config

2.1.1. MicroProfile Config in JBoss EAP

Configuration data can change dynamically and applications need to be able to access the latest configuration information without restarting the server.

MicroProfile Config provides portable externalization of configuration data. This means, you can configure applications and microservices to run in multiple environments without modification or repackaging.

MicroProfile Config functionality is implemented in JBoss EAP using the SmallRye Config component and is provided by the microprofile-config-smallrye subsystem.

Note

MicroProfile Config is only supported in JBoss EAP XP. It is not supported in JBoss EAP.

Important

If you are adding your own Config implementations, you need to use the methods in the latest version of the Config interface.

Additional Resources

2.1.2. MicroProfile Config sources supported in MicroProfile Config

MicroProfile Config configuration properties can come from different locations and can be in different formats. These properties are provided by ConfigSources. ConfigSources are implementations of the org.eclipse.microprofile.config.spi.ConfigSource interface.

The MicroProfile Config specification provides the following default ConfigSource implementations for retrieving configuration values:

  • System.getProperties().
  • System.getenv().
  • All META-INF/microprofile-config.properties files on the class path.

The microprofile-config-smallrye subsystem supports additional types of ConfigSource resources for retrieving configuration values. You can also retrieve the configuration values from the following resources:

  • Properties in a microprofile-config-smallrye/config-source management resource
  • Files in a directory
  • ConfigSource class
  • ConfigSourceProvider class

Additional Resources

2.2. MicroProfile Fault Tolerance

2.2.1. About MicroProfile Fault Tolerance specification

The MicroProfile Fault Tolerance specification defines strategies to deal with errors inherent in distributed microservices.

The MicroProfile Fault Tolerance specification defines the following strategies to handle errors:

Timeout
Define the amount of time within which an execution must finish. Defining a timeout prevents waiting for an execution indefinitely.
Retry
Define the criteria for retrying a failed execution.
Fallback
Provide an alternative in the case of a failed execution.
CircuitBreaker
Define the number of failed execution attempts before temporarily stopping. You can define the length of the delay before resuming execution.
Bulkhead
Isolate failures in part of the system so that the rest of the system can still function.
Asynchronous
Execute client request in a separate thread.

Additional Resources

2.2.2. MicroProfile Fault Tolerance in JBoss EAP

The microprofile-fault-tolerance-smallrye subsystem provides support for MicroProfile Fault Tolerance in JBoss EAP. The subsystem is available only in the JBoss EAP XP stream.

The microprofile-fault-tolerance-smallrye subsystem provides the following annotations for interceptor bindings:

  • @Timeout
  • @Retry
  • @Fallback
  • @CircuitBreaker
  • @Bulkhead
  • @Asynchronous

You can bind these annotations at the class level or at the method level. An annotation bound to a class applies to all of the business methods of that class.

The following rules apply to binding interceptors:

  • If a component class declares or inherits a class-level interceptor binding, the following restrictions apply:

    • The class must not be declared final.
    • The class must not contain any static, private, or final methods.
  • If a non-static, non-private method of a component class declares a method level interceptor binding, neither the method nor the component class may be declared final.

Fault tolerance operations have the following restrictions:

  • Fault tolerance interceptor bindings must be applied to a bean class or bean class method.
  • When invoked, the invocation must be the business method invocation as defined in the Jakarta Contexts and Dependency Injection specification.

  • An operation is not considered fault tolerant if both of the following conditions are true:

    • The method itself is not bound to any fault tolerance interceptor.
    • The class containing the method is not bound to any fault tolerance interceptor.

The microprofile-fault-tolerance-smallrye subsystem provides the following configuration options, in addition to the configuration options provided by MicroProfile Fault Tolerance:

  • io.smallrye.faulttolerance.mainThreadPoolSize
  • io.smallrye.faulttolerance.mainThreadPoolQueueSize

Additional Resources

2.3. MicroProfile Health

2.3.1. MicroProfile Health in JBoss EAP

JBoss EAP includes the SmallRye Health component, which you can use to determine whether the JBoss EAP instance is responding as expected. This capability is enabled by default.

MicroProfile Health is only available when running JBoss EAP as a standalone server.

The MicroProfile Health specification defines the following health checks:

Readiness
Determines whether an application is ready to process requests. The annotation @Readiness provides this health check.
Liveness
Determines whether an application is running. The annotation @Liveness provides this health check.
Startup
Determines whether an application has already started. The annotation @Startup provides this health check.

The @Health annotation was removed in MicroProfile Health 3.0.

MicroProfile Health 3.1 includes a new Startup health check probe.

For more information about the changes in MicroProfile Health 3.1, see Release Notes for MicroProfile Health 3.1.

Important

The :empty-readiness-checks-status, :empty-liveness-checks-status, and :empty-startup-checks-status management attributes specify the global status when no readiness, liveness, or startup probes are defined.

Additional Resources

2.4. MicroProfile JWT

2.4.1. MicroProfile JWT integration in JBoss EAP

The subsystem microprofile-jwt-smallrye provides MicroProfile JWT integration in JBoss EAP.

The following functionalities are provided by the microprofile-jwt-smallrye subsystem:

  • Detecting deployments that use MicroProfile JWT security.
  • Activating support for MicroProfile JWT.

The subsystem contains no configurable attributes or resources.

In addition to the microprofile-jwt-smallrye subsystem, the org.eclipse.microprofile.jwt.auth.api module provides MicroProfile JWT integration in JBoss EAP.

Additional Resources

2.4.2. Differences between a traditional deployment and an MicroProfile JWT deployment

MicroProfile JWT deployments do not depend on managed SecurityDomain resources like traditional JBoss EAP deployments. Instead, a virtual SecurityDomain is created and used across the MicroProfile JWT deployment.

As the MicroProfile JWT deployment is configured entirely within the MicroProfile Config properties and the microprofile-jwt-smallrye subsystem, the virtual SecurityDomain does not need any other managed configuration for the deployment.

2.4.3. MicroProfile JWT activation in JBoss EAP

MicroProfile JWT is activated for applications based on the presence of an auth-method in the application.

The MicroProfile JWT integration is activated for an application in the following way:

  • As part of the deployment process, JBoss EAP scans the application archive for the presence of an auth-method.
  • If an auth-method is present and defined as MP-JWT, the MicroProfile JWT integration is activated.

The auth-method can be specified in either or both of the following files:

  • the file containing the class that extends javax.ws.rs.core.Application, annotated with the @LoginConfig
  • the web.xml configuration file

If auth-method is defined both in a class, using annotation, and in the web.xml configuration file, the definition in web.xml configuration file is used.

2.4.4. Limitations of MicroProfile JWT in JBoss EAP

The MicroProfile JWT implementation in JBoss EAP has certain limitations.

The following limitations of MicroProfile JWT implementation exist in JBoss EAP:

  • The MicroProfile JWT implementation parses only the first key from the JSON Web Key Set (JWKS) supplied in the mp.jwt.verify.publickey property. Therefore, if a token claims to be signed by the second key or any key after the second key, the token fails verification and the request containing the token is not authorized.
  • Base64 encoding of JWKS is not supported.

In both cases, a clear text JWKS can be referenced instead of using the mp.jwt.verify.publickey.location config property.

2.5. MicroProfile Metrics

2.5.1. MicroProfile Metrics in JBoss EAP

JBoss EAP includes the SmallRye Metrics component. The SmallRye Metrics component provides the MicroProfile Metrics functionality using the microprofile-metrics-smallrye subsystem.

The microprofile-metrics-smallrye subsystem provides monitoring data for the JBoss EAP instance. The subsystem is enabled by default.

Important

The microprofile-metrics-smallrye subsystem is only enabled in standalone configurations.

Additional Resources

2.6. MicroProfile OpenAPI

2.6.1. MicroProfile OpenAPI in JBoss EAP

MicroProfile OpenAPI is integrated in JBoss EAP using the microprofile-openapi-smallrye subsystem.

The MicroProfile OpenAPI specification defines an HTTP endpoint that serves an OpenAPI 3.0 document. The OpenAPI 3.0 document describes the REST services for the host. The OpenAPI endpoint is registered using the configured path, for example http://localhost:8080/openapi, local to the root of the host associated with a deployment.

Note

Currently, the OpenAPI endpoint for a virtual host can only document a single deployment. To use OpenAPI with multiple deployments registered with different context paths on the same virtual host, each deployment must use a distinct endpoint path.

The OpenAPI endpoint returns a YAML document by default. You can also request a JSON document using an Accept HTTP header, or a format query parameter.

If the Undertow server or host of a given application defines an HTTPS listener then the OpenAPI document is also available using HTTPS. For example, an endpoint for HTTPS is https://localhost:8443/openapi.

2.7. MicroProfile OpenTracing

2.7.1. MicroProfile OpenTracing

The ability to trace requests across service boundaries is important, especially in a microservices environment where a request can flow through multiple services during its life cycle.

The MicroProfile OpenTracing specification defines behaviors and an API for accessing an OpenTracing compliant Tracer interface within a CDI-bean application. The Tracer interface automatically traces JAX-RS applications.

The behaviors specify how OpenTracing Spans are created automatically for incoming and outgoing requests. The API defines how to explicitly disable or enable tracing for given endpoints.

Additional Resources

2.7.2. MicroProfile OpenTracing in JBoss EAP

You can use the microprofile-opentracing-smallrye subsystem to configure the distributed tracing of Jakarta EE applications. This subsystem uses the SmallRye OpenTracing component to provide the MicroProfile OpenTracing functionality for JBoss EAP.

MicroProfile OpenTracing 2.0 supports tracing requests for applications. You can configure the default Jaeger Java Client tracer, plus a set of instrumentation libraries for components commonly used in Jakarta EE, using JBoss EAP management API with the management CLI or the management console.

Note

Each individual WAR deployed to the JBoss EAP server automatically has its own Tracer instance. Each WAR within an EAR is treated as an individual WAR, and each has its own Tracer instance. By default, the service name used with the Jaeger Client is derived from the deployment’s name, which is usually the WAR file name.

Within the microprofile-opentracing-smallrye subsystem, you can configure the Jaeger Java Client by setting system properties or environment variables.

Important

Configuring the Jaeger Client tracer using system properties and environment variables is provided as a Technology Preview. The system properties and environment variables affiliated with the Jaeger Client tracer might change and become incompatible with each other in future releases.

Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Note

By default, the probabilistic sampling strategy of the Jaeger Client for Java is set to 0.001, meaning that only approximately one in one thousand traces are sampled. To sample every request, set the system properties JAEGER_SAMPLER_TYPE to const and JAEGER_SAMPLER_PARAM to 1.

Additional Resources

2.8. MicroProfile REST Client

2.8.1. MicroProfile REST client

JBoss EAP XP 4.0.0 supports the MicroProfile REST client 2.0 that builds on Jakarta RESTful Web Services 2.1.6 client APIs to provide a type-safe approach to invoke RESTful services over HTTP. The MicroProfile Type Safe REST clients are defined as Java interfaces. With the MicroProfile REST clients, you can write client applications with executable code.

Use the MicroProfile REST client to avail the following capabilities:

  • An intuitive syntax
  • Programmatic registration of providers
  • Declarative registration of providers
  • Declarative specification of headers
  • ResponseExceptionMapper
  • Jakarta Contexts and Dependency Injection integration
  • Access to server-sent events (SSE)

Additional resources

2.8.2. The resteasy.original.webapplicationexception.behavior MicroProfile Config property

MicroProfile Config is the name of a specification that developers can use to configure applications and microservices to run in multiple environments without having to modify or repackage those apps. Previously, MicroProfile Config was available for JBoss EAP as a technology preview, but it has since been removed. MicroProfile Config is now available only on JBoss EAP XP.

Defining the resteasy.original.webapplicationexception.behavior MicroProfile Config property

You can set the resteasy.original.webapplicationexception.behavior parameter as either a web.xml servlet property or a system property. Here’s an example of one such servlet property in web.xml: 

<context-param>
    <param-name>resteasy.original.webapplicationexception.behavior</param-name>
    <param-value>true</param-value>
</context-param>

You can also use MicroProfile Config to configure any other RESTEasy property.

Additional resources

2.9. MicroProfile Reactive Messaging

2.9.1. MicroProfile reactive messaging

When you upgrade to JBoss EAP XP 4.0.0, you can enable the newest version of MicroProfile Reactive Messaging, which includes reactive messaging extensions and subsystems.

A "reactive stream" is a succession of event data, along with processing protocols and standards, that is pushed across an asynchronous boundary (like a scheduler) without any buffering. An "event" might be a scheduled and repeating temperature check in a weather app, for example. The primary benefit of reactive streams is the seamless interoperability of your various applications and implementations.

Reactive messaging provides a framework for building event-driven, data-streaming, and event-sourcing applications. Reactive messaging results in the constant and smooth exchange of event data, the reactive stream, from one app to another. You can use MicroProfile Reactive Messaging for asynchronous messaging through reactive streams so that your application can interact with others, like Apache Kafka, for example.

After you upgrade your instance of MicroProfile Reactive Messaging to the latest version, you can do the following:

  • Provision a server with MicroProfile Reactive Messaging for the Apache Kafka data-streaming platform.
  • Interact with reactive messaging in-memory and backed by Apache Kafka topics through the latest reactive messaging APIs.
  • Use MicroProfile Metrics to find out how many messages are streamed on a given channel.

Additional resources

2.9.2. MicroProfile reactive messaging connectors

You can use connectors to integrate MicroProfile Reactive Messaging with a number of external messaging systems. MicroProfile for JBoss EAP comes with the Apache Kafka connector. Use the Eclipse MicroProfile Config specification to configure your connectors.

The Apache Kafka connector and incorporated layers

MicroProfile Reactive Messaging includes the Kafka connector, which you can configure with MicroProfile Config. The Kafka connector incorporates microprofile-reactive-messaging-kafka and microprofile-reactive-messaging Galleon layers. The microprofile-reactive-messaging layer provides the core MicroProfile Reactive Messaging functionality.

Table 2.1. Reactive messaging and Apache Kafka connector Galleon layers

LayerDefinition

microprofile-reactive-streams-operators

  • Provides MicroProfile Reactive Streams Operators APIs and supporting implementing modules.
  • Contains MicroProfile Reactive Streams Operators with SmallRye extension and subsystem.

  • Depends on cdi layer.

    • cdi stands for Jakarta Contexts and Dependency Injection; provides subsystems that add @Inject functionality.

microprofile-reactive-messaging

  • Provides MicroProfile Reactive Messaging APIs and supporting implementing modules.
  • Contains MicroProfile with SmallRye extension and subsystem.
  • Depends on microprofile-config and microprofile-reactive-streams-operators layers.

microprofile-reactive-messaging-kafka

  • Provides Kafka connector modules that enable MicroProfile Reactive Messaging to interact with Kafka.
  • Depends on microprofile-reactive-messaging layer.

2.9.3. The Apache Kafka event streaming platform

Apache Kafka is an open source distributed event (data) streaming platform that can publish, subscribe to, store, and process streams of records in real time. It handles event streams from multiple sources and delivers them to multiple consumers, moving large amounts of data from points A to Z and everywhere else, all at the same time. MicroProfile Reactive Messaging uses Apache Kafka to deliver these event records in as few as two microseconds, store them safely in distributed, fault-tolerant clusters, all while making them available across any team-defined zones or geographic regions.

Additional resources