Kapitel 18 · Messaging

Spring Integration und Enterprise Integration Patterns

Typ: FrameworkVersion 2 ausführlich

Spring Integration implementiert Enterprise Integration Patterns wie Channel, Transformer, Router, Splitter, Aggregator und Service Activator.

‹ Zurück ⌂ Index Weiter ›

Fachliche Einordnung

Viele Enterprise-Probleme sind Integrationsprobleme: Dateien, FTP/SFTP, Mail, JMS, REST, SOAP, Timer, Routing und Transformation. Spring Integration macht diese Flüsse explizit.

Enterprise-Merksatz: Spring Integration implementiert Enterprise Integration Patterns wie Channel, Transformer, Router, Splitter, Aggregator und Service Activator.

Technische Darstellung

Kernkonzepte

Message, Channel und Endpoint.
Transformer, Router, Filter, Splitter, Aggregator.
IntegrationFlow Java DSL.
Poller und Adapter für externe Systeme.
Error Channel und kompensierende Fehlerflüsse.

Wann einsetzen?

Du integrierst heterogene Systeme.
Du migrierst ESB-Flows oder Batch-nahe Dateischnittstellen.
Du willst Integrationslogik sichtbar und testbar machen.

Typische Fehler und Risiken

IntegrationFlow wird zum unlesbaren Monster ohne Unterflüsse.
Fachentscheidungen stecken in technischen Routern.
Fehlerkanal wird nicht modelliert.

Legacy- und Modernisierungssicht

ESB-, IBM Integration Bus- oder cronbasierte Dateiablagen lassen sich in kleinere, testbare IntegrationFlows zerlegen.

Ausführliches Beispiel

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

@Configuration
class InvoiceImportFlowConfiguration {
    @Bean
    IntegrationFlow invoiceFileFlow(InvoiceImportService service) {
        return IntegrationFlow
            .from(Files.inboundAdapter(Path.of("/data/invoices")), e -> e.poller(Pollers.fixedDelay(5000)))
            .filter(file -> file.getName().endsWith(".csv"))
            .transform(new CsvToInvoiceCommandTransformer()) // Transformer Pattern
            .handle(service, "importInvoice")
            .channel("invoiceImportResultChannel")
            .get();
    }
}

Checkliste für Reviews

Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?