Livré dans le cadre du MicroProfile Working Group nouvellement formé, la très attendue release de MicroProfile 4.0 a été mise à la disposition de la communauté Java. Les fonctionnalités incluent l'alignement avec Jakarta EE 8 et les mises à jour des 12 API principales. Les API autonomes, cependant, restent inchangées pour le moment.
Les API CDI, JAX-RS, JSON-P et JSON-B, basées à l'origine sur leurs JSR équivalentes, sont désormais basé sur leurs spécifications équivalentes de Jakarta EE 8, à savoir Jakarta Contexts and Dependency Injection 2.0, Jakarta RESTful Web Services 2.1, Jakarta JSON Processing 1.1 et Jakarta JSON Reliure 1.0. Dans les coulisses, MicroProfile 4.0 utilise Jakarta Annotations 1.3, une spécification qui "définit un ensemble d'annotations représentant des concepts sémantiques courants qui permettre un style de programmation déclaratif qui s'applique à une variété de technologies Java."
Initialement prévu pour une version en juin 2020, MicroProfile 4.0 a été retardé afin que le MicroProfile Working Group puisse être créé comme mandaté par la Fondation Eclipse. Le groupe de travail définit le MicroProfile Specification Process et un comité de pilotage officiel composé d'organisations et de groupes d'utilisateurs Java (JUG), à savoir Atlanta JUG, IBM, Jelastic, Red Hat et Tomitribe.
Emily Jiang, Liberty microservice architect and advocate chez IBM, offrant une rétrospective sur les défis de l'année dernière, a déclaré à InfoQ :
MicroProfile 4.0 a été une version livrée en retard. Les spécifications individuelles de l'API étaient prêtes à être publiées il y a quelque temps. Cependant, la condition préalable à la publication était de créer le groupe de travail MicroProfile, ce qui nous a pris environ 10 mois. Une fois le groupe de travail établi, nous avons immédiatement lancé le processus de publication de MicroProfile 4.0.
MicroProfile Config 2.0 a été utilisé comme cobaye pour établir le processus de publication, y compris les exigences de licence pour les spécifications, les javadocs, etc., ainsi que pour voter sur les spécifications. Avec cette expérience, nous avons créé les modèles et le processus pour les versions d'API. J'ai créé un plan de publication pour diviser les versions d'API en trois vagues en fonction des dépendances. Nous avons ensuite lancé les versions de l'API, organisé les versions, lancé le processus de vote, etc.
Nous nous sommes efforcés de publier MicroProfile 4.0 en 2020. Avec l'aide et l'assistance précieuses d'Eclipse Foundation, nous avons réussi à publier MicroProfile 4.0 le 23 décembre. Une mention spéciale va à Jelastic pour avoir annoncé MicroProfile 4.0 à la dernière minute.
Aligné avec les dépendances de Jakarta EE 8, MicroProfile 4.0 est livré avec des modifications incompatibles pour cinq des API, à savoir Config, Fault Tolerance, Health, Metrics et OpenAPI. Nous examinons ici quelques-unes des API.
MicroProfile Config 2.0
L'API MicroProfile Config fournit une configuration d'exécution à partir de sources externes pour minimiser repackaging d'une application. Basées sur un système ordinal basé sur les priorités, ces sources comprennent : 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. Les sources personnalisées peuvent également être définies en implémentant l'interface ConfigSource.
Config 2.0 introduit l'annotation @ConfigProperties qui permet l'extraction en masse de propriétés dans une classe de propriétés. Cela élimine la répétition de l'annotation @ConfigProperty sur un certain nombre de propriétés associées lues à partir d'une source de configuration. Par exemple, considérez la configuration suivante :
server.host=localhost
server.port=8080
server.endpoint=movie
Il serait désormais possible d'extraire toutes les propriétés dans une seule classe :
@ConfigProperties(prefix="server")
@Dependent
public class ServerDetails {
public String host; // the value of server.host
public int port; // the value of server.port
private String endpoint; //the value of server.endpoint
public String getEndpoint() {
return endpoint;
}
}
Vous trouverez plus de détails sur les nouvelles fonctionnalités et les modifications incompatibles dans la release notes et le référentiel GitHub.
MicroProfile Fault Tolerance 3.0
L'API MicroProfile Fault Tolerance fournit des stratégies (timeouts, retentatives, disjoncteurs, etc.) pour gérer les pannes 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.
Fault Tolerance 3.0 spécifie désormais le cycle de vie des circuit breakers et bulkheads de telle sorte qu'ils conservent leur état entre les appels pour garantir un fonctionnement correct. Par exemple, si un bean @RequestScoped a une méthode @CircuitBreaker, toutes les invocations de cette méthode partageront le même état du circuit breaker, même si chaque requête a une instance différente du bean.
Les métriques de tolérance aux pannes ont été mises à jour pour prendre en charge les balises metric, une fonctionnalité ajoutée dans Metrics 2.0. Par conséquent, les informations précédemment contenues dans le nom de la métrique sont à la place incluses dans les balises.
Par souci de cohérence avec les autres API MicroProfile, les métriques de tolérance aux pannes ont été déplacées de la portée application: vers la portée base:. Par conséquent, ces métriques sont désormais exportées sous les endpoints /metrics et /metrics/base en remplaçant les endpoints /metrics et /metrics/application.
Vous trouverez plus de détails sur les nouvelles fonctionnalités et les modifications incompatibles dans la release notes et le référentiel GitHub.
MicroProfile Health 3.0
L'API MicroProfile Health détermine si un nœud de calcul est sur le point de s'arrêter ou s'arrête et remplacera ce nœud par une nouvelle instance saine. Semblable à l'API Metrics, un endpoint /health est automatiquement fourni pour afficher les informations de santé d'une application au format JSON.
Health 3.0 permet aux développeurs de définir l'état de disponibilité par défaut au démarrage de l'application. Comme la disponibilité détermine si un conteneur peut accepter des demandes, le conteneur doit renvoyer un état global négatif jusqu'à ce que la disponibilité de l'application puisse être confirmée. Par conséquent, la valeur MicroProfile Config, mp.health.default.readiness.empty.response, peut être définie sur UP pour informer le conteneur qu'une application est prête.
Pour plus de détails sur les nouvelles fonctionnalités et les modifications incompatibles, consultez la release notes et le référentiel GitHub.
MicroProfile Metrics 3.0
L'API MicroProfile Metrics fournit des données de télémétrie chronologique pour les applications MicroProfile. Un endpoint /metrics intégré envoie les 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.
Metrics 3.0 apporte un certain nombre de changements en particulier à MetricRegistry qui a été converti d'une classe abstraite en une interface. Un certain nombre de nouvelles méthodes (getType(), gauge(), histogramme(), meter(), etc.) ont été ajoutés à l'interface MetricRegistry. L'enregistrement de métrique n'est plus déclenché avec l'annotation @Metric. Si les métriques d'application nécessitent un enregistrement, cela doit être fait à l'aide des nouvelles méthodes de MetricRegistry .
Pour plus de détails sur les nouvelles fonctionnalités et les incompatibles, consultez la release notes et référentiel GitHub.
Premiers pas avec MicroProfile
Similaire aux outils de démarrage Web, tels que Spring Initialzr, Quarkus et Micronaut Launch, le MicroProfile Starter est un outil relativement nouveau permettant aux développeurs de commencer à écrire des applications microservices basées sur le cloud. Sorti en janvier 2019, MicroProfile Starter générera un projet Maven complet basé sur des options sélectionnées telles que les versions MicroProfile et Java SE, un runtime pris en charge basé sur la version MicroProfile sélectionnée et une série de cases à cocher pour sélectionner les API MicroProfile souhaitées.
Le groupe de travail MicroProfile évalue actuellement OpenTelemetry, un nouveau projet formé par la fusion récente des projets OpenTracing et OpenCensus et le projet Micrometer, une façade pour application de métriques indépendante du fournisseur, en tant que candidats potentiels pour remplacer respectivement les API OpenTracing et Metrics.
Note du rédacteur
Cette news a été mise à jour pour inclure la rétrospective d'Emily Jiang et pour remplacer le diagramme MicroProfile 4.0 d'origine qui contenait une erreur typographique.