Enterprise Integration Patterns:

Im Folgenden werden die Aspekte der Messaging Channels im Detail betrachtet.

• Point-to-Point Channel – Wie kann ein Sender sicher stellen, dass genau ein Empfänger durch eine Nachricht eine Aktion auslöst?
• Publish-Subscribe Channel – Wie kann ein Sender eine Nachricht an alle interessierten Empfänger verteilen?
• Datatype Channel – Wie legt eine Sender-Applikation fest, dass der Empfänger eine Nachricht korrekt verarbeiten kann?
• Invalid Message Channel – Wie kann eine nicht sinnvolle Nachricht vom Empfänger sanft beantwortet werden?
• Dead Letter Channel – Wie behandelt ein Messaging System Nachrichten welche nicht zustellbar sind?
• Guaranteed Delivery – Wie kann eine Applikation sicherstellen, dass eine Nachricht auch beim Ausfall des Messaging System ausgeliefert wird.
• Channel Adapter – Wie wird eine beliebige Applikation an ein Messaging System zum Nachrichtenaustausch angebunden?
• Messaging Bridge – Wie können unterschiedliche Nachrichtensysteme verbunden werden, so dass Nachrichten über die Systemgrenzen fließen können?
• Message Bus – Wie können ohne die Gefahr von Seiteneffekten unterschiedliche Applikationen so kooperieren, dass die Architektur durch eine lose Kopplung beliebige Zu- und Abgänge von Applikationen in der Umgebung ermöglicht.

Im Kapitel Message Construction werden unterschiedliche Möglichkeiten betrachtet, wie über einen Nachrichtenaustausch konkrete Interoperationen realisiert werden können.

• Command Message – Wie wird über einen Nachrichtenaustausch in einem entfernten System eine Prozedur aufgerufen?
• Document Message – Wie werden Daten über einen Nachrichtenaustausch zwischen entfernten Systemen ausgetauscht?
• Event Message – Wie wird über einen Nachrichtenaustausch in einem entfernten System ein Event ausgelöst?
• Request-Reply – Wie kann nach einem Nachrichtenaustausch der Sender eine Antwort von einem Empfänger erhalten?
• Return Address – Wie kann nach einem Nachrichtenaustausch der Empfänger eine Antwort an den Sender übermitteln?
  Correlation Identifier – Wie kann nach einem asynchronen Nachrichtenaustausch der Sender eine Antwort eines Empfängers einer seiner Anfragen zuordnen?
• Message Sequence – Wie können beliebig große Datenmengen mittels Messaging verarbeitet werden?
• Message Expiration – Wie wird einer Nachricht ein Verfallsdatum mitgegeben?
• Format Indicator – Wie kann das Format einer Nachricht für zukünftige Änderungen gestaltet werden?

Nach einem Exkurs zu einfachen JMS und .NET Beispielen im Abschnitt Simple Messaging Examples wird im Kapitel Message Routing einer der beiden wesentlichsten Aspekte eines Nachrichtensystem beschrieben – das Routing!

• Content-Based Router – Wie kann ein fachlicher Dienst, dessen IT Repräsentation über verschiedene Anwendungssysteme verteilt ist, in einem Messaging System abgebildet werden?
• Message Filter – Wie kann ein Teilnehmer am Nachrichtensystem sich vor unerheblichen Nachrichten schützen?
• Dynamic Router – Wie kann das Routing effizient gestaltet werden, bei Vermeidung von Abhängigkeiten hinsichtlich aller möglichen Empfänger?
• Recipient List – Wie wird eine Nachricht einer dynamischen Menge von Empfängern zugestellt?
• Splitter – Wie kann eine Nachricht verarbeitet werden, in der Teile jeweils unterschiedlich behandelt werden müssen?
• Aggregator – Wie lassen sich Ergebnisse als eine kombinierte Nachricht weiterverarbeiten, die zwar aus unterschiedlichen jedoch zusammenhängenden Bereichen stammen?
• Resequencer – Wie werden in Beziehung stehende Nachrichten in die richtige Reihenfolge gebracht, wenn sie nicht in dieser eintreffen?
• Composed Message Processor – Wie kann der gesamte Message Flow aufrecht gehalten werden, falls die Bestandteile der Nachricht jeweils unterschiedlich behandelt werden müssen und asynchron in Unterprozessen zu verarbeiteten sind?
• Scatter-Gather – Wie kann der gesamte Message Flow aufrecht gehalten werden, falls eine Nachricht unterschiedlichen Empfängern zugestellt werden muss und diese sie jeweils spezifisch beantworten?
• Routing Slip – Wie ist eine Nachricht fortlaufend durch verschiedene Schritte in einem Fluss zu steuern, wenn die Reihenfolge zur Design Zeit nicht bekannt ist und jeweils unterschiedlich je Nachricht sein kann?
• Process Manager – Wie ist eine Nachricht durch verschiedene Schritte in einem Fluss zu steuern, wenn die benötigten (und nicht zwingend sequentiellen) Schritte zur Design Zeit nicht bekannt sind?
• Message Broker – Wie kann die gesamte Steuerung der Nachrichtenflüsse aufrecht gehalten werden, wobei der Sender und das Ziel einer Nachricht zu entkoppeln sind?

Im Anschluss wird auf den zweiten wichtigen Aspekt im Messaging eingegangen – die Message Transformation!

• Envelope Wrapper – Wie können Bestandsysteme in einen vorhandenen Nachrichtenfluss eingebunden werden, der bereits spezielle Anforderungen an die Nachrichtenformate stellt – wie z.B. Header oder Verschlüsselung?
• Content Enricher – Wie wird mit einer Applikation kommuniziert, welche mehr Attributdaten benötigt als primär in einer Nachricht vorhanden?
• Content Filter – Wie kann eine sehr große Nachricht vereinfacht verarbeitet werden, wenn nur wenige Anteile der Nachricht interessieren?
• Claim Check – Wie kann ohne Verlust der Informationsinhalte einer Nachricht diese im Volumen reduziert werden?
• Normalizer – Wie werden semantisch analoge Nachrichten verarbeitet, die in unterschiedlichen Formaten transferiert werden?
• Canonical Data Model – Wie können Abhängigkeiten bei der Applikationsintegration minimiert werden, wenn von den Anwendungen unterschiedliche Datenformate verwendet werden.

Nachdem nun auf diese beiden Aspekte Routing und Transformation eingegangen wurde, kann im Anschluss der natürlich ebenfalls wichtigen Punkt Messaging Endpoints behandelt werden.

• Messaging Gateway – Wie wird der Zugriff aus das Messaging System von den übrigen Teilen der Applikation gekapselt.
• Messaging Mapper – Wie können Daten zwischen unterschiedlichen Domänen und dem Messaging System ausgetauscht werden, wobei diese voneinander unabhängig bleiben.
• Transactional Client – Wie steuert ein Client seine Transaktionen mit dem Messaging System?
• Polling Consumer – Wie kann eine Applikation den Nachrichtenabruf eigenständig steuern, ohne dies direkt an die Nachrichtenverfügbarkeit zu koppeln?
• Event-Driven Consumer – Wie kann eine Applikation den Nachrichtenabruf automatisiert nach Verfügbarkeit der Nachrichten steuern?
• Competing Consumers – Wie steuert ein Client die zeitgleiche Verarbeitung von mehreren Nachrichten?
• Message Dispatcher – Wie steuern mehrere Teilnehmer an einem Channel deren Transaktionen?
• Selective Consumer – Wie kann ein Client (Message Consumer) auswählen welche Nachrichten er erhalten möchte?
• Durable Subscriber – Wie kann ein Subscriber in einem Publish-Subribe-Channel den Verlust von Nachrichten verhindern, wenn er inaktiv ist?
• Idempotent Receiver – Auch wenn eine Applikation eine Nachricht nur einmal sendet, kann diese vom Empfänger mehrfach empfangen werden – wie kann oder besser sollte dieser mit diesen doppelten Nachrichten umgehen?
• Service Activator – Wie kann ein Serviceaufruf entworfen werden, der sowohl mittels verschiedenen Messaging Techniken wie auch ohne message-orientierte Middleware verwendbar ist.

Als Abschluss werden wichtige Ansätze für das System Management im Bereich einer message-orientierten Middleware beschrieben.

• Control Bus – Wie kann ein räumlich und physisch verteiltest Messaging System effektiv verwaltet werden?
• Detour – Wie kann zur Validierung, zum Testen und Debugging eine Nachricht in Zwischenschritten „geroutet“ werden?
• Wire Tap – Wie können Nachrichten auf in einem Point-to-Point Channel untersucht werden?
• Message History – Wie können in einem lose gekoppelten System für Message Flows durchgreifend Analyse und Debuging vorgenommen werden?
• Message Store – Wie kann unter Berücksichtigung der losen Kopplung und der Flüchtigkeit der Nachrichten trotzdem ein Reporting auf diese Kommunikationsinformationen erfolgen?
• Smart Proxy – Wie können Nachrichten verfolgt werden, wenn Ihre erzeugenden Servicekomponenten nicht mit einem festen Channel verknüpft sind, sondern diese dynamisch je Caller auswählen?
• Test Message – Wie können Flows welche Nachrichten korrekt verarbeiten dahingehend getestet werden, dass sie Nachrichten nicht aufgrund eines internen Fehlers verlieren?
• Channel Purger – Wie können von Tests oder Ähnlichem übrig gebliebene Nachrichten auf einem Channel gelöscht werden, ohne echte Bestandsnachrichten zu verlieren?