JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile
X

Jetzt abstimmen im neuen Quickvote: Die Kunst des Logging - wissen Sie wie?

Spring Integration

Bernhard Kraus und Peter Welkenbach

Mit Spring Integration erblickte vor ziemlich genau einem Jahr ein neues Mitglied im Spring-Universum das Licht der Welt. Im Laufe des Jahres wuchs der neue Spross zu einem reifen Produkt heran, das kürzlich den ersten offiziellen Releasestatus erhielt und auch schon in diversen Projekten zum Einsatz kam.

Spring Integration ergänzt das Spring-Basisframework um Funktionalitäten, die vor allem beim Design von Integrationssystemen das Leben des Entwicklers erleichtern. Hierzu stellt Spring Integration eine Implementierung wesentlicher Integrationsmuster zur Verfügung, wie sie in "Enterprise Integration Patterns" von Gregor Hohpe und Bobby Woolf [1] beschrieben sind.

Bei Hohpe und Woolf werden zurzeit 65 Muster unterschieden, die sich in 6 Kategorien unterteilen lassen (Abb.1):



Abb.1: Integrationsmuster nach Hohpe und Woolf

  • Messaging Channel Patterns beschreiben die fundamentalen Attribute eines Messaging-Systems. Diese Muster werden durch die meisten kommerziellen und nichtkommerziellen Messaging-Systeme implementiert.
  • Message Construction Patterns beschreiben Absicht und Nutzen, Form sowie den Inhalt einer Message, die über ein Messaging-System transportiert werden soll.
  • Message Routing Patterns befassen sich mit der Problemstellung der Nachrichtenweiterleitung, die die korrekte Versendung einer Nachricht von einem Sender an einen oder mehrere Empfänger ermöglichen soll. Message-Routing-Muster konsumieren Nachrichten aus einem Message-Channel und publizieren diese, basierend auf bestimmten Regeln, erneut in weitere Message-Channels. Der Inhalt einer Nachricht wird hierbei (nach dem Separation-of-Concerns-Ansatz) nicht verändert.
  • Message Transformation Patterns sind für eine Änderung an der Nachricht, ihrem Format, ihrer Struktur, bzw. dem Nachrichteninhalt selbst verantwortlich.
  • Messaging Endpoint Patterns beschreiben das Verhalten von Client eines Nachrichtensystems. Sie beschreiben die unterschiedliche Art und Weise, wie eine Applikation Nachrichten produzieren und konsumieren, bzw. mit dem eigentlichen Nachrichtensystem interagieren kann.
  • System Management Patterns dienen der Laufzeitüberwachung bzw. dem Betrieb von komplexen Nachrichtensystemen. Hierbei geht es auch um die Einhaltung von SLAs, Fehlerüberwachung und Ausfallsicherheit.

Spring Integration basiert auf einem domänenspezifischen Dialekt für die technische Integrationsdomäne und übernimmt hier weitestgehend die Terminologie der Integrationsmuster von Hohpe und Woolf.

Zentrales Konzept ist dabei der Message Bus, der den Informationsfluss zwischen Message Source (Producer) und Message Targets (Consumer) über Message Channels entkoppelt. Weiterhin werden Komponenten von ihrer Umgebung entkoppelt und die Testbarkeit von Einzelschritten ermöglicht (Abb. 2).



Abb.2: Application Context

Wesentliche Komponenten von Spring Integration

Eine Message beschreibt einen generischen Datencontainer, der über die Message Channels zwischen Consumern und Producern weitergeleitet werden kann. Eine Message in Spring Integration besteht aus einem Header und dem eigentlichen Payload, und entspricht konzeptionell somit den von JMS bekannten Messages.

Ein Message Channel entkoppelt Producer und Consumer und kann die Datentypkonsistenz der Messages gewährleisten (Abb.3).



Abb.3: Message Channel

Spring Integration liefert mehrere unterschiedliche Implementierungen des Message Channels:

  • PublishSubscribeChannel
  • QueueChannel
  • PriorityChannel
  • RendezvousChannel
  • DirectChannel
  • ThreadLocalChannel

Bei einem Message Endpoint handelt es sich um eine Abstraktion für Consumer und Producer, der Input Sourcen und Output Targets anbinden sowie lokale Services aufrufen kann (Abb.4).



Abb.4: Message Endpoint

Channel Adapter sind Spezialisierungen eines Endoints und verbinden externe Sourcen oder Targets mit dem Messaging System von Spring Integration.

Konfigurationsbeispiel für einen Adapter:

Message Router sind ebenfalls spezialisierte Endpoints und haben die Aufgabe die Routing-Logik von der fachlichen Logik zu isolieren.

Der PayloadTypeRouter leitet Nachrichten auf Basis ihres Typs an entsprechende Ziele weiter:

Der RecipientListRouter sendet Nachrichten an eine fix definierte Liste von Zielkanälen weiter:

Um eine komplexere Routing-Logik zu implementieren, können entsprechende Methoden als Router mit den entsprechenden Annotationen versehen werden:

@Router
public MessageChannel route(Message message) {...}

@Router
public List route(Message message) {...}

@Router
public String route(Foo payload) {...}

@Router
public List route(Foo payload) {...}

Anschließend können solche Beans in der Konfiguration als Router angegeben werden.

Zusammenfassung

Viele Applikationen benötigen die eine oder andere Art von Integrationslogik, z. B. Datentransformation zwischen Sender und Empfänger oder Routing zu diversen Endpoints (z. B. JMS, FTP, Dateisystem etc.). Spring Integration erlaubt die Verwendung der bekannten Spring-Features wie Dependency Injection, Templates und Transactions sowie Security in Integrationsapplikationen. Spring Integration kann als Erweiterung des Spring-Programmiermodells für die Integrationsdomäne gesehen werden.

Das Framework bietet Implementierungen für viele der bekannten EAI-Muster, die sich direkt auf eine Komponente mappen lassen, z. B. Service Activator, Transformer, Router, Splitter, Message Channel etc.). Zukünftige Versionen des Frameworks sollen einige Composite Patterns (wie Routing Slip oder Process Manager) als neue Implementierungen anbieten. Des Weiteren sollen auf einer abstrakteren Ebene Composite Patterns konfiguierbar sein, die heute schon möglich sind. So setzt sich ein Composed Message Processor aus einem Splitter, Router und einem Aggregator zusammen, die in den aktuellen Versionen des Frameworks schon als Implementierungen vorliegen. Zukünftig wird es eine konfigurierbare Komponente für dieses Composite Pattern geben, was zu einer übersichtlicheren und einfacheren Konfiguration beträgt.

Bernhard Kraus ist bei der adesso AG beschäftigt. Als Senior Consultant befasst er sich mit Architekturen im JEE- und Spring-Bereich.

Peter Welkenbach ist Principal Consultant und Trainer bei der Trivadis GmbH, wo er sich mit komplexen Integrationsarchitekturen auf Basis von Oracle, JEE und Spring beschäftigt.

 
Verwandte Themen: 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).