Lobster Experten Fragen

Message Services

Message Service ist ein sehr allgemeiner Begriff. So ein Message Service dient schlicht dazu, Nachrichten zwischen diversen Systemen auszutauschen, die voneinander im Prinzip gar nichts wissen müssen. Jedes angeschlossene System schickt einfach Nachrichten an diesen Service, die von anderen Systemen empfangen werden. Und jedes System, das solche Nachrichten empfangen will, registriert sich für bestimmte Kanäle oder Themen. Das Interessante dabei ist, dass der Sender gar nicht genau wissen muss, wer seine Nachricht empfängt, ja oft nicht einmal mitbekommt, ob sie überhaupt empfangen wurde. Und wie die Nachricht letztlich verarbeitet wurde, interessiert ihn eigentlich auch nicht. Das entkoppelt die verschiedenen Systeme voneinander, logisch und auch zeitlich. Die Nachricht wird dem Message Service übergeben, und gut.

Grundlegende Varianten der Nachrichtenverteilung

„Kanäle oder Themen“ war jetzt etwas kurz gehalten. Genauer gesagt gibt es bei Message Services verschiedene Wege, Nachrichten zu verteilen. Im Großen und Ganzen kann man folgende Ansätze unterscheiden:

  • Queues: Nachrichten werden in Warteschlangen gestellt und der Reihe nach (FIFO-Prinzip) an interessierte Empfänger verteilt. Dabei kann es mehrere mögliche Empfänger pro Nachricht geben, aber nur einer davon erhält eine bestimmte Nachricht auch wirklich.
  • Publish/Subscribe: Nachrichten werden in einem bestimmten Pool versenkt, und jeder Empfänger, der sich für diesen Pool interessiert, erhält die zugehörigen Nachrichten. Man kann auch Broadcasting dazu sagen.
  • Routing: Ähnlich dem Publish/Subscribe-Verfahren, aber hier bekommen die Nachrichten noch eine zusätzliche Eigenschaft mit, den sogenannten Routing Key. Die möglichen Empfänger interessieren sich nur für Nachrichten mit bestimmten Keys. Sie filtern sozusagen für sie interessante Nachrichten heraus. Diese Keys sind völlig frei wählbar. Und ein Empfänger kann sich durchaus für mehrere Keys interessieren.
  • Topics: Ein bisschen ähnlich wie Routing. Nur, dass Topics nicht nur einen einzelnen Wert beinhalten, sondern aus mehreren Teilen bestehen. Beispielsweise „Erde.Europa.Deutschland“ (Trennzeichen ist hier der Punkt) oder „Politik.Wirtschaft.Deutschland“. Empfänger können sich nun für das exakte Topic registrieren oder für einen Teil davon, etwa „Erde.Europa.*“ (alles, was zu Erde.Europa gehört, der * ersetzt ein Wort), „Politik.#“ (alles Politische, das # ersetzt beliebig viele Worte) oder auch „#.Deutschland“ (egal, ob es um die geografische oder die politische Einteilung handelt).
  • RPC: Remote Procedure Call. Eine Message fordert die Ausführung einer bestimmte Prozedur auf einem anderen Server an und teilt dabei auch gleichzeitig mit, an wen anschließend das Ergebnis geschickt werden soll. Empfänger registrieren sich sinnigerweise auf Nachrichten, für die sie auch die entsprechenden Prozeduren bereitstellen.

Mehr wollen wir nicht über die Arbeitsweise von Message Services sagen. Wer mehr wissen will, kann sich das Tutorial von Rabbit MQ anschauen, das ist ein Message Service Provider. Interessanter ist eigentlich, was es für Message Services gibt. Kurze Antwort: Viele.
Da ist zum Beispiel der Java Message Service JMS. Das ist eine API, also eine Programmierschnittstelle, die alle wichtigen Funktionen für den Aufbau eines Message Service bereitstellt. Eine verbreitete Implementierung hiervon ist Apache ActiveMQ, es gibt aber einige Dutzend weitere.
Aber nicht nur mit Java kann man Message Services bereitstellen bzw. implementieren, auch viele andere Programmiersprachen sind dafür geeignet. Dementsprechend gibt es Message Services wie Sand am Meer. Womit sich ein Problem auftut: Eigentlich sollte so ein Message Service ja gerade so flexibel wie möglich sein, um beliebige Systeme als Sender und/oder Empfänger von Nachrichten anbinden zu können. Deshalb bietet zum Beispiel das bereits genannte Rabbit MQ Schnittstellen zu mehr als einem halben Dutzend Sprachen. Neben der Anbindung diverser Programmiersprachen gibt es noch etwas, das einen Message Service flexibel machen kann, nämlich eine Schnittstelle, die nicht per Programmierung, sondern einfach über das Netz angesprochen wird. Ein Vertreter dieser Art Protokolle ist STOMP (Simple Text Oriented Protocol), ein anderer AMQP, das Advanced Message Queuing Protocol. Letzteres ist kein Text-, sondern ein binäres Protokoll und kann dementsprechend auch mehr als STOMP. Sehen wir es uns noch etwas genauer an:

AMQP

Die reale, serverseitige Implementierung eines Message Services nennt man auch „Broker“. Mit welcher Technologie dieser Broker unter der Haube arbeitet, sollte nach außen hin verborgen bleiben. Stattdessen soll er eine Schnittstelle bieten, über die Nachrichten von Clients angeliefert bzw. an diese ausgeliefert werden. AMQP ist eine solche Schnittstelle. Sie wurde von einem ziemlich großen Firmenkonsortium entwickelt und ist inzwischen auch ein OASIS-Standard. Einer der Vorzüge von AMQP: Es kostet nichts. Jeder darf in seinem Broker oder seinem Client das Protokoll implementieren und nutzen. Ein anderer Vorteil: Immer mehr Broker (wie z.B. Rabbit MQ oder auch Apache ActiveMQ) nutzen diese Schnittstelle. Sollten Sie bereits einen Message Service in Ihrem Hause betreiben, stehen die Chancen sehr gut, dass es auch eine AMQP-Anbindung dafür gibt. (Hier übrigens noch der Wikipedia-Artikel zu AMQP)
Clients und Server (alias Broker) kommunizieren bei AMQP über TCP. Wer am jeweils anderen Ende sitzt und wie (z.B. in welcher Sprache) derjenige implementiert ist, spielt keine Rolle. Das ist im Prinzip genau so wie bei Webservern und Browsern. Also eine ideale Voraussetzung für die Vernetzung unterschiedlicher Systeme: was uns zum eigentlich wichtigen Punkt bringt:

Message Services und EDI/EAI

Was genau hat denn nun das Thema Message Services auf diesen Seiten zu suchen?
Nun ja, an sich ist ein Message Service die ideale Möglichkeit für Systeme innerhalb eines Firmennetzes miteinander zu kommunizieren. Okay, SAP bietet sein ALE als direkte Kommunikationsform an, das ist aber eben sehr SAP-spezifisch. Andere Produkte stützen sich auf HTTP oder gar auf einfache Dateisystem-Schnittstellen, aber diese Formen der Kommunikation sind eigentlich nur Notbehelfe. Während HTTP oder auch FTP für die Kommunikation zwischen verschiedenen Firmen im Internet geeignet sind und AS2 z.B. geradezu dafür entworfen, ist das Dateisystem in erster Linie zur Datenhaltung, aber nicht zur Kommunikation gemacht. Für den Datenaustausch im selben lokalen Netz dagegen sind alle diese Wege nur zweckentfremdet worden.
Message Services sind hingegen exakt dafür entworfen. Ob EAI- oder EDI-System (oder eines, das beides beherrscht), es muss immer mit anderen Produkten im Haus (bzw. im LAN) kommuniziert werden. Dazu gibt es ein Konzept wie den ESB, aber wie dort schon gesagt, das ist ziemlich schwammig. Die reale Implementierung dieser Kommunikation dagegen kann sehr gut ein Message Service sein. Vorausgesetzt natürlich, die bereits im Hause vorhandene Software ist fähig, mit einem solchen Message Service zu arbeiten. Eine gute Möglichkeit dazu ist wiederum die Nutzung von AMQP.
Wenn Sie vor der Entscheidung stehen, eine EDI- oder EAI-Software anzuschaffen, klopfen Sie doch mal die schon existierenden (oder noch anzuschaffenden) Systeme daraufhin ab, ob sie diese Fähigkeit besitzen. Und sollte das in Frage kommen, achten Sie auch bei Ihrer EDI/EAI-Wahl darauf.