Spezifikation / Framework-ÖkosystemCloud Native6.x/7.x Orientierung
MicroProfile als Ergänzung zu Jakarta EE
MicroProfile ergänzt Enterprise Java um cloud-native APIs wie Config, Health, Metrics, Fault Tolerance, JWT, OpenAPI und REST Client.
Einordnung
Spezifikation / Framework-Ökosystem
Enterprise-Rolle
Jakarta EE standardisiert Kern-Enterprise-Java; MicroProfile ergänzt typische Microservice-Betriebsthemen.
Fachliches Verständnis
Jakarta EE standardisiert Kern-Enterprise-Java; MicroProfile ergänzt typische Microservice-Betriebsthemen. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.
Kernkonzepte
- Config für externe Konfiguration.
- Health und Metrics für Betrieb.
- Fault Tolerance für Resilienz.
- OpenAPI und REST Client für Schnittstellen.
- JWT für Security-Kontext.
Typische Einsatzfälle
- Cloud-native Jakarta Services bauen.
- Kubernetes Readiness/Liveness integrieren.
- REST-Clients standardisieren.
Technisches Beispiel
java
@Path("/health/business")
@ApplicationScoped
public class BusinessHealthCheck implements HealthCheck {
@Override
public HealthCheckResponse call() {
return HealthCheckResponse.named("billing-cutoff")
.status(true)
.withData("cutoffHour", 22)
.build();
}
}
@RegisterRestClient(configKey = "partner-api")
public interface PartnerClient {
@GET @Path("/partners/{id}") PartnerDto find(@PathParam("id") String id);
}
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.
Enterprise-Fallen
- MicroProfile als Ersatz für saubere Architektur.
- Resilience ohne fachliche Idempotenz.
- Health Checks ohne Aussagekraft.
Legacy-Modernisierung
Für Modernisierung alter WAR/EAR-Services ist MicroProfile oft die Brücke zu Cloud-Betrieb.
Vertiefung: Review-Fragen für Senior-Entwickler
- Welche Spezifikation ist hier wirklich nötig?
- Welche Runtime-Funktion wird genutzt und ist sie portabel?
- Wo liegt die Transaktionsgrenze?
- Sind API-Verträge, DTOs und Domain-Modelle getrennt?
- Ist der Code ohne Application Server testbar?