Spezifikation / Framework-APIBusiness Components4.0

Jakarta Enterprise Beans

Enterprise Beans definieren containerverwaltete Business-Komponenten, Transaktionen, Timer und asynchrone Methoden.

Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
EJB ist in Legacy-Systemen zentral. Für neue Systeme wird oft CDI plus gezielte Services bevorzugt, aber EJB-Verständnis bleibt wichtig.
Diagramm zu Jakarta Enterprise Beans

Fachliches Verständnis

EJB ist in Legacy-Systemen zentral. Für neue Systeme wird oft CDI plus gezielte Services bevorzugt, aber EJB-Verständnis bleibt wichtig. 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

  • Stateless/Stateful Beans.
  • Singleton Beans.
  • Message Driven Beans.
  • Timer Service.
  • Container Managed Transactions.

Typische Einsatzfälle

  • Legacy-Services verstehen.
  • Timer und transaktionale Komponenten migrieren.

Technisches Beispiel

java
@Stateless
public class LegacyBillingBean {
    @PersistenceContext EntityManager em;

    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public InvoiceId bill(OrderId orderId) {
        OrderEntity order = em.find(OrderEntity.class, orderId.value());
        InvoiceEntity invoice = InvoiceEntity.from(order);
        em.persist(invoice);
        return new InvoiceId(invoice.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

  • Remote EJB als verteiltes Objektmodell.
  • Fachlogik eng an Container binden.
  • Stateful Beans ohne Clusterstrategie.

Legacy-Modernisierung

Stateless EJBs werden oft zu CDI Application Services; MDBs zu Messaging Consumern; Timer zu Batch/Scheduler-Konzepten.

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?