novaris-billing-soap

Das Abrechnungs-/Billing-Partnersystem der Novaris-Landschaft - ein klassischer JAX-WS- SOAP-Service, den novaris-policy-core als Client anspricht (siehe BillingIntegrationBean dort und docs/20-soap/).

Warum hier kein wsimport-Codegen laeuft

Der ueblicherweise "richtige" Contract-First-Weg ist: WSDL schreiben, per wsimport (z.B. ueber das jaxws-maven-plugin) daraus automatisch das Service Endpoint Interface (SEI), die JAXB-Bindungsklassen und die Fault-Klassen generieren lassen.

Bei der Umsetzung dieses Moduls wurde genau das ausprobiert - und ist auf der hier verwendeten Toolchain (aktuelles JDK, org.jvnet.jax-ws-commons:jaxws-maven-plugin) mit einem internen Plugin-Fehler gescheitert (das Plugin ist seit ca. 2016 nicht mehr gepflegt und mit modernen JDKs erkennbar nicht mehr zuverlaessig kompatibel). Das ist selbst ein authentisches Legacy-Erlebnis: veraltete Build-Tooling-Ketten, die irgendwann nicht mehr mit aktuellen JDKs harmonieren, sind ein sehr reales Problem in gewachsenen Java-EE-Projekten - nicht nur der Anwendungscode selbst altert, auch die Werkzeuge, mit denen er gebaut wird.

Deshalb der pragmatische Ausweg, der auch in echten Projekten oft gewaehlt wird:

• Die WSDL (src/main/resources/wsdl/BillingService.wsdl) bleibt die dokumentierte Quelle der Wahrheit fuer den Vertrag.
• SEI, Fault-Klasse und Fault-Detail-Bean sind von Hand geschrieben, aber inhaltlich exakt passend zur WSDL - sie liegen in novaris-common-legacy (com.novaris.legacy.common.billing.contract), damit Server (dieses Modul) und Client (novaris-policy-core) garantiert dieselbe Klasse verwenden.
• Diese Entscheidung ist bewusst nicht versteckt: jede betroffene Klasse verweist in ihrem Javadoc auf diese Begruendung. Aendert sich der Vertrag, muessen WSDL und Java-Klassen manuell synchron gehalten werden - genau die Doppelpflege, die eine funktionierende Codegen-Toolchain eigentlich vermeiden wuerde.

Wie der Endpoint getestet wird

BillingServiceEndpointTest publiziert den echten Endpoint lokal ueber javax.xml.ws.Endpoint.publish(...) (die eingebaute Mini-HTTP-Laufzeit der JAX-WS-RI) und spricht ihn ueber einen dynamisch aufgebauten Client (Service.create(...).getPort(...)) an - ein vollstaendiger SOAP-Roundtrip inklusive Fault-Handling, ganz ohne Docker/Application Server. Die dafuer noetige JAX-WS-Laufzeit (jaxws-rt, jaxb-impl, javax.activation-api) ist bewusst nur test-scoped - in einer echten WebSphere-/ Liberty-Umgebung stellt der Server diese Implementierung selbst bereit (Feature jaxws-2.2/jaxws-2.3).