Spezifikation / Framework-APISOAP4.0 / 3.0

Jakarta XML Web Services und SOAP with Attachments

Jakarta XML Web Services standardisiert SOAP-Webservices; SAAJ unterstützt SOAP-Nachrichten und Attachments.

Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
Viele Enterprise-Landschaften nutzen SOAP für stabile, vertragliche Systemintegration.
Diagramm zu Jakarta XML Web Services und SOAP with Attachments

Fachliches Verständnis

Viele Enterprise-Landschaften nutzen SOAP für stabile, vertragliche Systemintegration. 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

  • WSDL und Service Endpoint Interface.
  • @WebService.
  • SOAP Envelope und Faults.
  • MTOM/Attachments.

Typische Einsatzfälle

  • Bestehende SOAP-Schnittstellen weiter betreiben.
  • Contract-first Integration mit Partnern.

Technisches Beispiel

java
@WebService(serviceName = "BillingService")
public class BillingEndpoint {
    @Inject BillingUseCase billing;

    @WebMethod
    public BillingResponse bill(BillingRequest request) {
        return billing.bill(request);
    }
}
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

  • Code-first ohne Vertragspflege.
  • SOAP Faults uneinheitlich.
  • Transport- und Fachfehler vermischen.

Legacy-Modernisierung

SOAP kann hinter REST-Fassaden verborgen werden, während Verträge zu Partnern stabil bleiben.

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?
Jakarta Web Services MetadataIndex