Jakarta EE Umsetzung im Praxisprojekt

Jakarta EE zeigt Enterprise-Standardisierung mit CDI, JTA, JAX-RS, Persistence, Security und Batch.

Jakarta EE 11CDIJTAJAX-RS
Jakarta EE Transaktionsgrenze im Projekt
Jakarta EE Transaktionsgrenze im Projekt

Rolle von Jakarta EE

Jakarta EE ist besonders stark, wenn ein Unternehmen Standards, zertifizierte Runtime, Portabilität und klassische Enterprise-Fähigkeiten wie CDI, JTA, JAX-RS, Jakarta Persistence, Messaging und Batch bündeln möchte.

JAX-RS Resource

JAX-RS Resource als Adapter
@Path("/orders")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class OrderResource { // Pattern: Inbound Adapter
    @Inject PlaceOrderUseCase placeOrder;

    @POST
    public Response place(PlaceOrderRequest request, @Context UriInfo uriInfo) {
        OrderId id = placeOrder.handle(request.toCommand());
        URI location = uriInfo.getAbsolutePathBuilder().path(id.value()).build();
        return Response.created(location).entity(new OrderResponse(id.value(), "ACCEPTED")).build();
    }
}

CDI

CDI übernimmt Dependency Injection und Scopes. Auch hier sollte die Domain keine CDI-Annotationen benötigen.

JTA

JTA als technische Umsetzung der Unit-of-Work-Grenze
@ApplicationScoped
public class JakartaTransactionRunner implements TransactionRunner { // Pattern: Unit of Work
    @Transactional
    public <T> T required(Supplier<T> work) {
        return work.get();
    }
}

Batch

Jakarta Batch eignet sich für kontrollierte, wiederanlaufbare Verarbeitung großer Datenmengen. Das Praxisprojekt nutzt Batch für nächtliche Rechnungsabgleiche.

Vergleich

AspektJakarta EESpring Boot
StandardisierungSehr stark über SpezifikationenStark über Ökosystem und Konventionen
RuntimeApplication Server oder kompatible RuntimeEmbedded Runtime
TransaktionenJTA standardisiertSpring Transaction Abstraction
Cloud Nativeüber moderne Runtimes möglichsehr verbreitet
⌂ Cockpit