Spezifikation / Library-APIXML4.0

Jakarta XML Binding

XML Binding mappt XML-Dokumente auf Java-Klassen und zurück.

Einordnung
Spezifikation / Library-API
Enterprise-Rolle
In SOAP-, Batch- und B2B-Systemen ist XML weiterhin relevant.
Diagramm zu Jakarta XML Binding

Fachliches Verständnis

In SOAP-, Batch- und B2B-Systemen ist XML weiterhin relevant. 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

  • @XmlRootElement.
  • Schema-first vs Code-first.
  • Marshaller/Unmarshaller.
  • Namespaces.

Typische Einsatzfälle

  • SOAP Payloads binden.
  • B2B XML importieren/exportieren.
  • Alte XSD-Verträge weiterführen.

Technisches Beispiel

java
@XmlRootElement(name = "order")
public class OrderXml {
    public String number;
    public List<OrderLineXml> lines;
}

JAXBContext context = JAXBContext.newInstance(OrderXml.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
OrderXml xml = (OrderXml) unmarshaller.unmarshal(new StringReader(payload));
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

  • Namespace-Fehler.
  • XML-Binding-Klassen als Domänenmodell verwenden.
  • Schema-Kompatibilität nicht testen.

Legacy-Modernisierung

JAXB-Legacy wird auf jakarta.xml.bind Pakete und neue Runtime-Abhängigkeiten migriert.

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?
Index