Livré sous les auspices du groupe de travail MicroProfile et cinq mois après la diffusion de MicroProfile 4.1, la diffusion anticipée de MicroProfile 5.0 a été mise à la disposition de la communauté Java. Cette nouvelle version propose un alignement avec Jakarta EE 9.1 et des mises à jour des huit principales API développées par la communauté plus une API autonome :
Les API CDI, JAX-RS, JSON-P et JSON-B, initialement basées sur leurs JSR équivalentes, sont désormais basées sur les spécifications équivalentes Jakarta EE 9.1, à savoir Jakarta Contexts and Dependency Injection 3.0 (CDI), Jakarta RESTful Web Services 3.0 (JAX-RS), Jakarta JSON Processing 2.0 (JSON-P) et Jakarta JSON Binding 2.0 (JSON-B). Dans les coulisses, MicroProfile 5.0 utilise Jakarta Annotations 2.0, une spécification qui "définit une collection d'annotations représentant des concepts sémantiques communs qui permettent un style de programmation déclaratif qui s'applique à une variété de technologies Java."
Les huit API développées par la communauté ont été mises à jour pour utiliser les dépendances Jakarta EE 9. En tant que tel, il y a des changements de rupture pour chacun d'eux. Nous examinons ici quelques-unes des API mises à jour.
MicroProfile Config 3.0
L'API MicroProfile Config fournit une configuration d'exécution à partir de sources externes pour minimiser le reconditionnement d'une application. Basées sur un système ordinal basé sur la priorité, ces sources incluent : les propriétés du système (ordinal = 400
) ; les variables d'environnement (ordinal = 300
) ; et un fichier .properties
(ordinal = 100
). La priorité est donnée à la valeur ordinale définie la plus élevée. Des sources personnalisées peuvent également être définies en implémentant l'interface ConfigSource
.
Le seul changement majeur pour Config 3.0 est qu'il ne peut pas être utilisé avec les versions antérieures de Jakarta EE ou Java EE en raison de la migration de l'espace de noms javax
vers l'espace de noms jakarta
. D'autres mises à jour incluent : une clarification dans la JavaDoc pour l'annotation @ConfigProperties
; un correctif pour une incohérence entre la spécification et la JavaDoc liée à l'interface Converter
; et un correctif pour un bug du TCK dans le ConfigProviderTest
.
MicroProfile Metrics 4.0
L'API MicroProfile Metrics fournit des données de télémétrie chronologiques pour les applications MicroProfile. Un endpoint /metrics
intégré envoie des données au format Prometheus. Les métriques personnalisées peuvent être définies via des annotations intégrées telles que @Counted
, @Gauge
, @Histogram
et @Timed
.
Les modifications majeures apportées à Metrics 4.0 incluent : une classe Timer
mise à jour dans laquelle Timer.update(long duration, java.util.concurrent.TimeUnit)
a été remplacée par Timer.update(java.time.Duration duration)
; un MetricRegistry
qui est passé d'une classe abstraite à une interface ; les méthodes Metadata.getDescription()
et Metadata.getUnit()
renvoient désormais le type String
au lieu de Optional<String>
; et de nouvelles méthodes, Metadata.description()
et Metadata.unit()
, qui renvoient le type Optional<String>
.
MicroProfile Fault Tolerance 4.0
L'API MicroProfile Fault Tolerance fournit un nombre de stratégies (timeouts, retries, circuit breakers, etc.) pour gérer les défaillances au sein d'une application. Chacune de ces stratégies a une annotation correspondante qui, lorsqu'elle est appliquée, redirigera l'application avec un plan d'action nécessaire pour minimiser les effets néfastes d'une défaillance.
Les changements majeurs dans Fault Tolerance 4.0 sont principalement liés à son interaction avec l'API Metrics. Cette spécification prend désormais en charge les balises de métrique qui ont été introduites dans Metrics 2.0. Et pour des raisons de cohérence avec les autres API MicroProfile, la portée application:
a été remplacée par la portée base:
. Cela signifie que les métriques de tolérance aux pannes sont exportées via le endpoint /metrics/base
remplaçant le endpoint /metrics/application
précédemment utilisé.
Présenté lors de la conférence DevNation de Red Hat le 27 juin 2016, l'initiative MicroProfile a été créée en tant que collaboration de fournisseurs pour fournir des microservices pour Java Entreprise. La sortie de MicroProfile 1.0, annoncée à JavaOne 2016, se composait de trois API basées sur des JSR considérées comme minimales pour la création de microservices : JSR-346 - Contexts and Dependency Injection (CDI); JSR-353 - Java API for JSON Processing (JSON-P) ; et JSR-339 - Java API for RESTful Web Services (JAX-RS).
MicroProfile 4.0, sorti en décembre 2020, était la première version livrée dans le cadre du groupe de travail MicroProfile alors nouvellement formé, établi en octobre 2020. Les membres actuels du groupe de travail incluent Oracle, IBM,Red Hat, Tomitribe, Fujitsu, Atlanta Java User Group, Garden State Java User Group et iJUG.
Le groupe de travail MicroProfile évalue actuellement OpenTelemetry, un projet formé par la fusion de OpenTracing et OpenCensus et le projet Micrometer, une façade de métriques d'application indépendante du fournisseur, comme candidats potentiels pour remplacer les API OpenTracing et Metrics, respectivement.
Note du rédacteur
Michael Redlich est co-directeur du Garden State Java User Group, un membre contributeur du MicroProfile Working Group.