Spring Boot & Apache CXF – Von 0 auf SOAP mit dem cxf-spring-boot-starter

Keine Kommentare

Sie haben bisher keinen einzigen Artikel dieser Blogserie gelesen? Gut so! Denn das Beste kommt erst jetzt. Wir verheiraten Spring Boot und Apache CXF in einem eigenen spring-boot-starter. So haben wir unsere SOAP-Endpoints noch schneller am Start und nutzen trotzdem alle bisher vorgestellten Features voll aus!

Spring Boot & Apache CXF – Tutorial

Part 1: Spring Boot & Apache CXF – SOAP ohne XML?
Part 2: Spring Boot & Apache CXF – SOAP Webservices testen
Part 3: Spring Boot & Apache CXF – XML-Validierung und Custom SOAP Faults
Part 4: Spring Boot & Apache CXF – Logging & Monitoring mit logback, Elasticsearch, Logstash & Kibana
Part 5: Spring Boot & Apache CXF – Von 0 auf SOAP mit dem cxf-spring-boot-starter

Wir haben in den vorangegangenen Blogartikeln eine Menge über die Arbeit mit Spring Boot und Apache CXF gelernt. Es bleibt eigentlich nur ein Problem: Wir fangen bei jedem unserer SOAP Endpoints von Neuem an, alle Schritte jedes einzelnen Blogartikels aufs Neue nachzuvollziehen. Bei aller Aktualität der Technologien geht uns das aber irgendwann gegen den Strich: Wir machen Dinge doppelt und dreifach. Doch glücklicherweise haben sich die Spring-Boot-Entwickler auch für diesen Fall etwas einfallen lassen: Es ist möglich, sich eigene Spring Boot Starter zu bauen, die alles Nötige für unseren speziellen Use Case mitbringen.

Der offizielle Apache CXF spring-boot-starter reicht uns nicht…

Das haben mittlerweile auch die Apache-CXF-Entwickler erkannt und bieten einen spring boot starter an (danke nochmal für den Hinweis Stéphane Nicoll 🙂 ). Schaut man sich diesen spring-boot-starter genauer an, so wird schnell klar, dass er sich natürlich ausschließlich auf Apache CXF konzentriert. Er nimmt uns dabei insgesamt die folgende Arbeit ab: Er initialisiert CXF. Das ist alles. Wie im ersten Artikel dieser Serie beschrieben, ist das letztlich folgender Code, den wir uns sparen können, wenn wir den Starter einsetzen:

@Bean
public ServletRegistrationBean dispatcherServlet() {
    return new ServletRegistrationBean(new CXFServlet(), "/soap-api/*");
}
@Bean(name=Bus.DEFAULT_BUS_ID)
public SpringBus springBus() {      
    return new SpringBus();
}

Im Kontext der CXF-Entwickler ist diese Fokussierung auch völlig ok! Aber es hilft uns in unseren Enterprise-Umfeldern wenig. Denn mit allen anderen Punkten stehen wir wieder allein da.

Also ein eigener spring-boot-starter?!!

Genau deshalb haben wir uns entschieden, einen eigenen spring-boot-starter für Apache CXF sowie notwendige Technologien „drumherum“ zu entwickeln und auf GitHub verfügbar zu machen…

Aber halt! Dürfen spring-boot-starter nicht nur durch die Spring-Entwickler bereitgestellt werden? Sind sie nicht deren exklusiver Weg, Funktionalität mit Spring Boot verfügbar zu machen? Zum Glück nicht! Neben der riesigen Anzahl von Startern, die Spring Boot von Haus aus mitbringt, kann jeder Entwickler seinen eigenen Starter bauen. Einige davon haben es sogar in die Community-Auswahl der Spring-Boot-Entwickler geschafft.

Wie man einen eigenen spring-boot-starter baut, beschreiben die Spring-Boot-Entwickler auf docs.spring.io und einer meiner Kollegen hat alle notwendigen Schritte zusammengetragen. Der Aufbau eines eigenen spring-boot-starters birgt die Möglichkeit, richtig in die Tiefen von Spring Boot abzutauchen und ein tieferes Verständnis für das Framework zu entwickeln. Gleichzeitig werden technische Frameworks nicht mehrfach entwickelt und können in allen Projekten mit den gleichen Anforderungen benutzt werden. Damit widerspricht ein spring-boot-starter auch nicht den Gedanken hinter der Microservices-Bewegung, sondern fördert diese sogar: Der Austausch von technischen Bibliotheken, am besten sogar über github.com, wird ausdrücklich empfohlen.

cxf-spring-boot-starter

Doch nun zum Eigentlichen: Ähnlich dem schon länger verfügbaren spring-boot-starter-batch-web haben wir den cxf-spring-boot-starter auf GitHub verfügbar gemacht. Er nimmt uns viele Dinge ab, die wir ohne ihn zu Fuß machen müssten. Hier ein paar davon:

  • Hochziehen aller notwendigen Apache-CXF-Komponenten (natürlich mit 100% Java-Konfiguration 😉 )
  • Extremes Vereinfachen der Logging-Konfiguration
  • Extraktion der ein- und ausgehenden SOAP-XML-Nachrichten für einen Elastic-Stack – inkl. eigener Custom Fields & Korrelation aller Log-Events eines Requests
  • Anbieten eines Builders für eigene Custom SOAP Faults, die bei XML-Schemavalidierung auf Basis eigener XSDs zurückgeliefert werden sollen
  • Umfangreiche Unterstützung bei der Erstellung von Unit-, Integrations- und Systemstests sowie beim Testen von invaliden XML-Anfragen
Jonas Hecht

Die Überzeugung, dass Softwarearchitektur und Hands-on Entwicklung zusammengehören, führte Jonas zu codecentric. Tiefgreifende Erfahrungen in allen Bereichen der Softwareentwicklung großer Unternehmen treffen auf Leidenschaft für neue Technologien. Im Fokus stand dabei immer die Integration verschiedenster Systeme (und Menschen).

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.