Nachrichtenbasierte Middleware-Ein Vergleich: Protokolle, Fähigkeiten

Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik

Hauptseminar

Nachrichtenbasierte Middleware - ein Vergleich: Protokolle, Fähigkeiten, Implementierungen und Anwendungsgebiete

vorgelegt von: Mihaela Todorova Tomova

eingereicht am: 10. 01. 2014

geboren am:

Studiengang: Ingenieurinformatik

Studienrichtung: Multimediale Informations- und

Kommunikationssysteme

Anfertigung im Fachgebiet: Kommunikationsnetze

Fakultät für Elektrotechnik und Informationstechnik

Verantwortlicher Professor: Prof. Dr. rer. nat. Jochen Seitz

Wissenschaftlicher Betreuer: Dipl.-Ing. Karsten Renhak Kurzfassung

In dieser Arbeit geht es um die Beschreibung der Fähigkeiten einer nachrichtenbasierten Middleware (MOM : Message Oriented Middleware), die mit einer MOM verwendeten Protokolle und einige der den MOM nutzende open-source Projekte (wie RabbitMQ, ActiveMQ, Qpid, OpenMQ). In dem ersten Kapitel werden die Problemstellung dieser Arbeit und die Anwendungsgebiete einer nachrichtenbasierten Middleware vorgestellt. Das zweite Kapitel beschreibt die Eigenschaften von MOM und gibt eine Antwort auf die Frage, warum MOM benötigt wird. Im nächsten Kapitel werden typische Protokolle und Standards von MOM vorgestellt. Das letzte Kapitel gibt einen Überblick über eine Auswahl der bekanntesten Implementierungen nachrichtenbasierter Middlewares. Abstract

This work concentrates on the capabilities and characteristics of a message oriented middleware (MOM), the protocols used with MOM-based middleware and typical MOM implementations such as RabbitMQ, ActiveMQ, Apache Qpid. The ﬁrst chapter tells us more about where MOM can be found. The second chapter explains the need of a message oriented middleware and gives a description of its capabilities. Typical protocols and standards are discussed in the next chapter. The last chapter compares some of the most used open-source MOM projects. Inhaltsverzeichnis i

Inhaltsverzeichnis

1 Einleitung 1

2 Fähigkeiten und Funktionen einer MOM 2

3 Protokolle und Standards 5 3.1 XMPP ...... 5 3.1.1 Was ist XMPP? ...... 5 3.1.2 Aufbau von XMPP-Streams ...... 5 3.1.3 Vor- und Nachteile ...... 5 3.2 JMS ...... 6 3.2.1 Was ist JMS ? ...... 6 3.2.2 Eigenschaften ...... 7 3.2.3 JMS Message Model ...... 7 3.2.4 Aufbau von JMS-Nachrichten ...... 8 3.3 AMQP ...... 10 3.3.1 Was ist AMQP? ...... 10 3.3.2 Message Model AMQP ...... 10 3.3.3 Wie ist AMQP aufgebaut? ...... 12 3.3.4 Aufbau von AMQP-Nachrichten ...... 13 3.3.5 Vor- und Nachteile ...... 14 3.4 Was ist STOMP? ...... 14 3.5 Was ist HTTP/HTTPS? ...... 15 3.6 Vergleich zwischen AMQP und JMS ...... 15

4 Implementierungen 18 4.1 Beschreibung und Vergleich von typischen open-source Projekten . . . . 18 4.1.1 RabbitMQ ...... 21 4.1.2 Apache ActiveMQ ...... 22 4.1.3 Apache Qpid ...... 22

Hauptseminar Mihaela Tomova Inhaltsverzeichnis ii

4.1.4 OpenMQ ...... 23 4.2 Zusammenfassung ...... 23

Literaturverzeichnis 26

Abbildungsverzeichnis 29

Tabellenverzeichnis 30

Abkürzungsverzeichnis 31

Erklärung 33

Hauptseminar Mihaela Tomova 1 Einleitung 1

1 Einleitung

Die Entwicklung des Internets und seine sich ausweitende Nutzung hat zu vielen und vielfältigen Möglichkeiten geführt. So sind wir es beispielsweise heutzutage gewohnt online Sachen zu kaufen oder zu verkaufen, uns einfach, schnell und zu jederzeit über die Wettervorhersage oder den Verkehrszustand zu informieren oder die Route eines Briefes zu verfolgen. Für alle diese Möglichkeiten stehen Anwendungen zur Verfügung. Um die Kommunikation zwischen den verschiedenen Anwendungen innerhalb einer Organisation oder zwischen mehreren zu schaﬀen ist, muss eine Zwischenschnittstelle hinzugefügt werden. Diese Schnittstelle wird durch eine Message Oriented Middleware, kurz MOM genannt, repräsentiert.

Durch MOM kann die Kommunikation zwischen verschiedene Anwendungen erleichtert werden. Middleware dieser Art ﬁndet man unter anderem auch bei Onlinespiele oder beispielsweise im Finanzsektor. Immer mehr wird MOM auch im Alltag der Men- schen eingesetzt, z.B. in technischen Assistenzsystemen, die älteren, allein wohnenden Menschen helfen. Weitere Vorteile der Middleware werden in den folgenden Kapiteln dargestellt.

Ziel dieser Arbeit ist die Fähigkeiten und Funktionen einer nachrichtenbasierten Middleware zu recherchieren und die dazugehörenden Protokolle und Standards zu beschreiben und zu vergleichen.

Hauptseminar Mihaela Tomova 2 Fähigkeiten und Funktionen einer MOM 2

2 Fähigkeiten und Funktionen einer MOM

Vor der Entwicklung einer nachrichtenbasierten Middleware wurde RPC (Remote Pro- cedure Call) verwendet, um die Kommunikation zwischen Prozessen (Systemen) zu ermöglichen. RPC ist mit einem Telefongespräch vergleichbar. Bei dem Remote Pro- cedure Call sprechen die beiden Systeme miteinander.

Mit fortschreitender technischer Entwicklung und steigender Komplexität entstand auch der Wunsch nach besserer Quality of Service ( QoS), besserer Performanz und höherer Geschwindigkeit. RPC konnte diese Anforderungen nicht mehr erfüllen, we- shalb nach einer Alternative geforscht wurde.

Das Ziel von MOM war es daher, die Nachteile von RPC zu beseitigen und wach- sende Ansprüche zu bedienen. Einen Vergleich zwischen RPC und MOM zeigt Tabelle 2.1. MOM arbeitet nach dem Store and Forward Prinzip. Man ermöglicht es eine Nachricht zu erhalten, auch wenn Sender und Empfänger nicht gleichzeitig aktiv sind. Dies wird durch die Verwendung von Message Queues realisiert. Daher kann MOM auch mit Post-Diensten verglichen werden.

Im Vergleich zu RPC, MOM ist zuverlässiger, ﬂexibler und besser skalierbar. MOM bietet eine asynchrone, verbindungslose und anwendungsunabhängige Technologie. Die Verwendung von MOM ermöglicht die Zustellung von Nachrichten, die nicht sofort gesendet werden können. z.B. in Fällen, in denen es keinen Internetzugang oder nur schlechte Verbindung gibt.

Grundsätzlich kann MOM drei wichtige Komponenten unterscheiden: Konsumenten, Produzenten und message Brokers (message Provider).

Hauptseminar Mihaela Tomova 2 Fähigkeiten und Funktionen einer MOM 3

RPC MOM Vorteile • einfacher Mechanismus; • weniger Bandbreite;

• direkte • keine großen Änderungen Nachrichtenübertragung von Anwendungen; durch synchrones Modell; • integrierte Infrastruktur, die • garantierte sequenzielle Änderungen stören die Verarbeitung; Funktionalität des Systems nicht; • langsam, aber widerspruchsfrei • unterstützt mehrere Clients

Nachteile • unﬂexible; • keine Garantie für sequenzielle Verarbeitung, • enge Kopplung; daraus folgen kurzfristige • alle Komponenten des Ungenauigkeiten der Daten Systems müssen in der Datenbank funktionieren, ansonsten arbeitet das System nicht mehr;

• Skalierungsprobleme;

• mehr Bandbreite;

• unterstützt nur einen Client

Tabelle 2.1: Vergleich RPC und MOM,[Mah04]

Hauptseminar Mihaela Tomova 2 Fähigkeiten und Funktionen einer MOM 4

• Die Produzenten (Sender) haben die Aufgabe Nachrichten zu erzeugen und sie zu einer Zwischeninstanz (message broker) zu senden.

• Die Konsumenten (Receiver) können Nachrichten aus einem message Broker ent- nehmen.

• Die dritte wichtige Kompetente ist der message Broker (message Provider). Die Hauptaufgabe eines message Brokers ist es, Nachrichten von einem Pro- duzenten zu einem Konsumenten weiterzuleiten. Durch diese vermittelnde In- stanz gibt es keine direkte Verbindung zwischen Sender und Empfänger. Aus der Verwendung von Warteschlangen folgt asynchrones Verhalten. Typische MOM- Kommunikationsmodelle, die Warteschlangen benutzen, werden in Kapiteln 3.2.3 und 3.3.2 ausführlich beschrieben. Weitere Aufgaben sind in [ASR+05] aufgelis- tet: – Verbindung heterogener Systemen – Übersetzung des Nachrichtenformates des Senders in ein oder in meherere Nachrichtenformaten des oder der Empfänger – MOM sorgt für eﬃziente Nachrichtenvermittlung (priorisierbare Nachricht- envermittlung) [Ric11]

Nach [Mah04] bietet MOM lose Kopplung, welche durch das Hinzufügen von einer Schicht zwischen Sender und Empfänger realisiert wird. Dieser Kopplungsart erleichtert die Durchführung von Änderungen einzelner Komponenten in einem System. So kön- nen Anwendungen von verschiedenen Systemen leichter miteinander kommunizieren, ohne Anpassungen der Ziel- und Quellsysteme. Diese Funktion bietet RPC nicht.

Wie in der Einleitung kurz erwähnt, kann MOM in Assistenzsystemen oder in verteilen Systemen benutzt werden. Das MOM basierte Protokoll AMQP wird auch von vielen Finanzorganisationen eingesetzt. Beispiele für MOM-Implementierungen sind u.a. WebsphereMQ, Apache ActiveMQ, RabbitMQ.

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 5

3 Protokolle und Standards

3.1 XMPP

3.1.1 Was ist XMPP?

XMPP steht für Extensible Messaging and Presence Protocol und ist ein Kommunika- tionsprotokoll von MOM. XMPP wurde zunächst unter dem Namen Jabber bekannt. 1999 wurde dieses auf XML basierendes Protokoll von der Jabber open-source Gruppe entwickelt. Im Jahr 2008 wurde Jabber ein Teil der Cisco Firmengruppe. Die Idee für die Entwicklung dieses Protokolls war es, den echtzeitfähigen Nachrichtenaustausch zu ermöglichen. Mit den Jahren hat sich das Protokoll verbreitet und wurde von Firmen wie Google, AOL und Facebook benutzt.[Wik14c]

3.1.2 Aufbau von XMPP-Streams

Das XMPP-Protokoll verwendet zur Kommunikation Streams. Abbildung 3.1 zeigt den grundlegenden Aufbau eines Streams. Man kann sehen, dass der XMPP-Stream in einen Initial Stream und in einen Response Stream aufgeteilt ist. Man kann auch drei wichtige Teile erkennen:[Hal12]

• presence

• message

• iq

3.1.3 Vor- und Nachteile

XMPP gibt den Benutzern die Möglichkeit einen eigenen Server zu betreiben. Somit kann ein zentraler Server durch einzelne Server ersetzt werden. So können eine eventuelle Überlastung und der daraus folgende single point of failure vermieden werden. Noch ein

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 6

Abbildung 3.1: Vereinfachte Sicht auf zwei Streams, [Hal12]

Vorteil von XMPP ist die Sicherheit, die durch das Benutzen von isolierten Intranet- servern und durch die Verschlüsselung via SASL und TLS realisiert werden kann.

Als Nachteil kann man die Verwendung vom XML-Format erwähnen. XMPP ist als ein einzelner XML-Dokument kodiert und es ist nicht möglich unmodiﬁzierte binäre Daten zu übertragen. Anstatt XML kann man AMQP benutzen.[Hal12]

3.2 JMS

3.2.1 Was ist JMS ?

JMS steht für Java Message Service und ist in [Wik13a] erläutert. JMS ist ein Teil aus dem Java Platform, Enterprise Edition und wurde durch den Java Community Process

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 7 im Rahmen des JMR 914 genormt. JMS repräsentiert eine Programmierschnittstelle (API ). Diese Schnittstelle steurt den Nachrichtenaustausch zwischen ein oder mehreren Clients. Wie das Akronym zeigt, wird Java als Programmiersprache verwendet. 2001 wurde die erste Version (JMS 1.0.2b) entwickelt, gefolgt von Version 1.1 im Jahr 2002. Die aktuellste Version (2.0) wurde 2013 etabliert.

3.2.2 Eigenschaften

Einer der Hauptgründe für die Entwicklung von nachrichtenbasierter Middleware war der Ersatz von enger Kopplung (RPC) durch lose Kopplung. Allerdings stellte sich mit der Einführung loser Kopplung auch die Frage nach der Portabilität. [Mah04]

JMS hat das Ziel, eine lose gekoppelte, verlässliche und asynchrone Kommunikation zwischen den Komponenten einer verteilten Anwendung zu ermöglichen. Bild 3.2 zeigt die Kommunikation zwischen einem Client und einem Server. Um die Kommunika- tion wie in dieser Abbildung zu ermöglichen, müssen Client und Server die API des Middleware-Herstellers verwenden. Obwohl effektiv, ist diese Variante nicht portierbar. Um Portabilität zu erreichen, braucht man eine standardisierte Schnittstelle. Mittels dieser Schnittstelle kann man auf die nachrichtenbasierte Middleware zugegriffen werden. Bild 3.3 zeigt, dass JMS die herstellerspezifische API ergänzt.[SH05]

Abbildung 3.2: MOM ohne JMS, [SH05]

3.2.3 JMS Message Model

JMS unterstützt zwei Arten von Nachrichtenübertragung:

• Punkt-zu-Punkt (Point-to-Point)

• Publish/Subscribe (Pub/Sub)

Beide Modelle basieren sich auf dem Nachrichtenaustausch über einen Kanal (auch als Warteschlange bezeichnet) und werden in Abbildungen 3.4 und 3.5 dargestellt.

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 8

Abbildung 3.3: MOM mitJMS, [SH05]

• Point-to-Point

Dieses Modell ermöglicht einen asynchronen Austausch von Nachrichten. Bild 3.4 zeigt wie Produzenten Nachrichten an Konsumenten über eine Warteschlange schicken. Die Anzahl von den Produzenten kann variieren, wobei die Anzahl von Konsumenten bis auf einen begrenzt ist. Bei diesem Modell werden die Nachrichten nur einmal weitergeleitet. Sie werden in einer Warteschlange gespeichert bis sie von dem entsprechen- den Konsumenten empfangt werden. Die Nachrichten werden über das FIFO-Prinzip in der Warteschlange gespeichert und aus der Warteschlange entnommen. [Mah04]

• Publish/Subscribe

Bild 3.5 zeigt das zweite Modell. Im Gegensatz zu dem P2P-Modell können Nachricht- en an mehreren Konsumenten weiterleitet werden. Konsumenten und Produzenten brauchen nichts voneinander zu wissen. Der Produzent sendet die Nachrichten the- menspeziﬁsch an den message Broker. Der Empfänger bekommt nur die Nachrichten, deren Themen er abonniert hat. Im Fall, dass einzelne Konsumenten nicht aktiv sind, gibt es zwei Möglichkeiten. Bei einem normalen Abonnement erreichen die Nachrichten die inaktiven Ziele nicht. Wenn ein dauerhaftes Abonnement gewählt ist, werden die Nachrichten in einer Warteschlange zwischengespeichert und später von den jeweiligen Abonnenten gelesen.[Mah04]

3.2.4 Aufbau von JMS-Nachrichten

JMS Anwendungen kommunizieren mittels Nachrichten. Nachrichten sind einfach struk- turiert, ﬂexibel und können durch verschiedene Anwendungen verwendet werden. JMS

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 9

Abbildung 3.4: P2P-Kommunikation, [SH05]

Abbildung 3.5: Sub/Pub-Kommunikation, [SH05] deﬁniert das Superinterface Message. Davon werden die folgenden Subinterfaces abgeleit- et (Bild 3.6):[SH05]

• BytesMessage

• MapMessage

• ObjectMessage

• StreamMessage

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 10

• TextMessage

Abbildung 3.6: Message Interfaces, [SH05]

Mit deren Hilfe können Daten verschiedener Art versendet werden. Eine JMS – Nachricht besteht aus drei Teilen. In der folgenden Tabelle (3.1) werden die drei Teile dargestellt und kurz beschrieben.

3.3 AMQP

3.3.1 Was ist AMQP?

AMQP steht für Advanced Message Queuing Protocol. AMQP Version 1.0 ist ein OASIS Standard, der den Nachrichtenaustausch zwischen Anwendungen oder Organi- sationen ermöglicht. 2006 wurden die ersten beiden AMQP-Versionen (0-8, 0-9) veröf- fentlicht, gefolgt von den Versionen 0-10 und 0-9-1 im Jahr 2008. 2011 wurde die neuste Version (1.0) auf dem Markt gebracht.

3.3.2 Message Model AMQP

Nachrichtenaustausch im AMQP erfolgt mittels „exchanges“ und „Warteschlangen“. Die exchange-Komponente dient nur als Verteiler und speichert keine Nachrichten.

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 11

Elements Description Required

Nachrichtenkopf (Header) Enthält Information über Ja Identiﬁkation und Pfad von Nachrichten. Abb. 3.6 zeigt eine Auﬂistung von Header-Feldern und deren Werte.

Nachrichtenrumpf (Body) speichert Nutzdaten, die Nein zum Nachrichtenaustausch benutzt werden. Mit Hilfe der Messaghe Typen (Subinterfaces) aus Abb. 3.8 kann man eine Übertragung verschiedener Nutzdaten ermöglicht werden.

Nachrichteneigenschaften Verschiedene Datentypen Nein (Properties) (boolean, byte, int, short, u.a) stehen dem Entwickler zur Verfügung. Drei Eigenschaftskategorien können hier unterscheiden werden (anwendungsspezifische, JMS-definierte und providerspezifische)

Tabelle 3.1: Teile einer JMS-Nachricht und deren Beschreibung,[SH05]

Diese Aufgabe übernehmen die Warteschlangen, sie speichern Nachrichten. Das message Model AMQP bietet fünf exchange-Typen (Direct Exchange, Fanout Exchange, Header Exchange, Topic Exchange, System Exchange). Die ersten beiden müssen von den message Brokers verwendet werden. Die anderen drei sind optional. Direct Ex- change ähnelt dem JMS-P2P Modell. Der Unterschied ist, dass es bei Direct Exchange keine Beschränkung für die Anzahl von Konsumenten gibt. Fanout Exchange, Topic

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 12

Abbildung 3.7: How JMS Message Header Field Values are set, [JMS13]

Exchange und Header Exchange ähneln dem Pub/Sub-Modell. System Exchange kann Nachrichten zu einem Anwendungs- oder einem Systemdienst weiterleiten. Typischer- weise werden die Nachrichten an eine Warteschlange weitergeleitet.[Ric11]

3.3.3 Wie ist AMQP aufgebaut?

AMQP kann in zwei Bereiche unterteilt werden: Nezwerkprotokoll-Teil und das Pro- tokollmodell-Teil. Im ersten Teil wird entschieden, welche Informationen die Client- und Serveranwendungen austauschen sollen,um miteinander zu kommunizieren. AMQP überträgt Daten mittels Rahmen (Frames). Der zweite Teil setzt die Standards an AMQP Anwendungen. Eine Anwendung kann die Form und Kodierungsart der Daten beliebig wählen. AMQP deﬁniert neun verschiedene Frame-Bodies:[Hal12]

• open: neue Verbindung herstellen

• begin: neue Session erstellen

• attach: neuen Link erstellen

• transfer: Nachricht verschicken

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 13

Abbildung 3.8: JMS Message Types,[JMS13]

• ﬂow: Nachrichtenaustauschkontrollschema

• disposition: Zuverlässigkeitseinstellung(at-most-once, at-least-once, exactly-once)

• detach: Link trennen

• end: Session beenden

• close: Verbindung schließen

3.3.4 Aufbau von AMQP-Nachrichten

Der Aufbau von AMQP Nachrichten ähnelt den Aufbau von JMS-Nachrichten. Wie in Punkt 3.2.4 erwähnt, bestehen JMS-Nachrichten aus drei Teilen (header, properties section, message body). AMQP dagegen besteht aus mehreren Teilen (header, propor- ties, body and optional footer). Der header-Teil im Vergleich zu JMS-header enthält unveränderliche anwendungsspeziﬁsche Eigenschaften. Der Property-Teil stellt die un- veränderlichen Routing- und Metadaten Eigenschaften dar. Im AMQP existiert nur

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 14

Abbildung 3.9: Aufbau des AMQP Frames, [Hal12] ein Nachrichten Body-Typ (eine binäre Nachricht). Bei JMS gibt es fünf Nachrichten Body-Typen. [Wik14a]

3.3.5 Vor- und Nachteile

Das Protokoll wurde für den Finanz- und Börsensektor entwickelt. Aus diesem Grund waren hohe Geschwindigkeit, Durchsatz, Skalierbarkeit, Verlässlichkeit, Sicherheit und Interoperabilität gewünscht. Da AMQP ein binäres Netzwerkprotokoll ist, entsteht der Vorteil mehrere Daten in einem Rahmen zu übertragen. Daraus folgt die Erhöhung der Geschwindigkeit. Eine weitere Besonderheit ist die Verschiebung der Routinglogik in den Broker, was wieder zur Erhöhung der Geschwindigkeit führt. Die Verschiebung der Routinglogik kann nicht nur als Vorteil, sondern auch als Nachteil gesehen werden. Die Folge ist, dass man bei der Implementierung von AMQP im Vergleich zu anderen Protokollen (z.B. XMPP) mehr Programmierungsarbeit geleistet werden muss. [Hal12]

3.4 Was ist STOMP?

STOMP steht für „Streaming Text Oriented Messaging Protocol“ und ist ein textbasiertes Protokoll. STOMP ähnelt HTTP und wird von nachrichtenbasierten Middlewares verwendet. Das Protokoll benutzt ein wire-Format.1[Con13] Mittels STOMP können STOMP-Clients mit STOMP unterstützenden Message

1wird benutzt zur Übertragung von Daten von einem Punkt zu einem anderen. Ein wire-Protokoll ist bei der Interoperabilität von einer oder mehreren Anwendungen verwendet.

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 15

Brokers unproblematisch kommunizieren. Wie in [Jü11] erwähnt ist, ermöglicht STOMP eine Kommunikation zwischen Anwendungen verschiedener Herkunft, in Bezug auf die zugrundeliegende Programmiersprachen und Plattform.

3.5 Was ist HTTP/HTTPS?

HTTP steht für HyperText Transfer Protocol und ist ein Anwendungsschichtprotokoll. HTTP dient zur Übertragung von Daten über ein Netzwerk und wird am meisten zum Laden von Webseiten in einem Webbrowser verwendet. HTTPS steht für HyperText Transfer Protocol Secure und hat die selben Eigenschaften wie HTTP. Der Unterschied liegt in der abhörsicheren Übertragung von Daten. Diese wird durch eine SSL/TLS Verschlüsselung erreicht. HTTP bzw. HTTPS wird verwendet, um die Barriere eines clientseitigen Firewalls umgegangen zu werden. So wird eine Nachrichtenvermittlung mittels XML-Messages ermöglicht, was die Kommunikation zwischen Client und Mes- sage Broker erleichtert.[Wik14b]

3.6 Vergleich zwischen AMQP und JMS

Im Vergleich zu AMQP speziﬁziert JMS eine API. D.h., JMS entscheidet, wie Sender- und Empfängerseite implementiert sind. AMQP dagegen ist eine Lösung für Inter- operabilität zwischen unterschiedlichen Implementierungen. So können beispielsweise Sender und Empfänger in verschiedenen Programmiersprachen geschrieben sein.

Ein weiterer Unterschied liegt im Message Routing:

• Message Routing AMQP

Im Vergleich zu JMS-message Routing (Bild 3.10 ) hat das AMQP-Message Routing (Bild 3.11 ) zusätzlich zu den Komponenten: Produzent, Konsument und Warteschlange auch eine binding- und exchange-Komponente. Die exchange-Komponente hat einen Routing-Schlüssel (routing key). Die binding-Komponente verbindet die exchange- Komponente mit der Warteschlange.[Ric11]

• Message Routing JMS

Bild 3.10 zeigt wie message Routing bei JMS realisiert wird. Aus dem Bild lassen sich die drei wichtigen Teile von JMS erkennen. (Produzent, Konsument, Warteschlange).

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 16

Damit Produzent (Sender) und Konsument (Receiver) Nachrichten austauschen kön- nen, müssen sie zunächst mit einer Warteschlange verbunden sein. Entweder sind beide mit einer Warteschlange des gleichen Namens verbunden oder der Produzent sendet themenspeziﬁsche Nachrichten, während der Konsument Themen abonniert. [Ric11]

Weitere Unterschiede sind die Nachrichtenstruktur und Nachrichtenmodelle. Sie werden in Kapiteln 3.2.4, 3.3.4 und in Kapiteln 3.2.3, 3.3.4 beschrieben.

In [Wik14a] wird erwähnt, wofür JMS nicht geeignet ist. JMS deﬁniert einen Stan- dard für Interoperabilität innerhalb einer Java-Platform, aber nicht außerhalb dieser Platformen. In Fällen, in denen es sich um unterschiedliche Platformen handelt und JMS verwendet wird, können verschiedenen Nachteilen auftreten. Einige dieser Nachteile sind die folgenden:

• Die Protokolle (z.B. STOMP, OpenWire2), die der Message Broker für die verschiedenen Klienten benötigt, können unterschiedliche Nachrichten Body-Typen (message body types) unterstützen.

• Die Protokolle können unterschiedliche Datentypen und unterschiedliche header- Eigenschaften unterstützen.

• Viele Lösungen für cross-platform Interoperabilität sind oft kommerziell und nicht Fokus dieser Arbeit.

AMQP ist deshalb häufig eine bessere Alternative. AMQP bietet eine Spezifikation für ein standardisiertes wire-level Protokoll. Die Aufgabe dieser Spezifikation ist es, die Struktur von Nachrichten und die Art und Weise von Nachrichtenvermittlung zu beschreiben. Man kann jede beliebige AMQP Client-Bibliothek und jeden beliebigen AMQP Broker benutzen. Daher liegt die Schlussfolgerung nahe, dass AMQP flexibler, besser austauschbar ist.

2Openwire ist ein wire-Protokoll und wird von ActiveMQ benutzt.

Hauptseminar Mihaela Tomova 3 Protokolle und Standards 17

Abbildung 3.10: JMS-Message Routing, [Ric11]

Abbildung 3.11: AMQP-Message Routing, [Ric11]

Hauptseminar Mihaela Tomova 4 Implementierungen 18

4 Implementierungen

4.1 Beschreibung und Vergleich von typischen open-source Projekten

Heutzutage gibt es viele kommerzielle und oﬀene Implementierungen, die auf JMS oder AMQP basiert sind. Dieses Kapitel beschreibt und vergleicht eine Auswahl der bekanntesten open-source (ActiveMQ, RabbitMQ, Apache Qpid, OpenMQ) Message Brokers. Abb. 4.3 stellt ein Google Trends Diagramm ein. Die Abbildung zeigt, wie häuﬁg nach den vier in dieser Arbeit gewählten Message Brokers gesucht wurde. Da kommerzielle Software wie WebsphereMQ (auch als MQSeries) zu teuer ist und es viele kostenfreie Projekte gibt, wird diese nicht betrachtet. Tabelle [4.1] zeigt vier open-source Projekte und die Kriterien, nach denen die Brokers miteinander verglichen sind.

Einige der wichtigsten Kriterien für Message Brokers sind Clustering, Zuverläs- sigkeit, Robustheit, Sicherheit, Persistenz. Unter Clustering versteht man eine Gruppe von miteinander arbeitender Geräte (z.B. Rechner, Message Brokers). Broker cluster sind für diese Arbeit besonders relevant, da mit ihrer Hilfe eine zuverlässige Nachricht- enübertragung sicher gestellt werden kann. So kann beispielsweise ein aus irgendwelchen Gründen ausgefallener Broker mit einem anderen Broker aus demselben Cluster ersetzt werden. Der Broker übernimmt die Arbeit des ausgefallenen Brokers, um so die weitere Nachrichtenvermittlung zu garantieren. In [Clu13] werden grundsätzlich zwei Arten von Broker clusters unterschieden:

• conventional broker clusters

• enhanced broker clustering

Conventional broker clusters (Bild 4.1 ) bieten service availability. Wenn ein Bro- ker ausfällt, wird die Kommunikation mittels eines anderen Brokers wiederhergestellt.

Hauptseminar Mihaela Tomova 4 Implementierungen 19

Diese Art von Broker cluster haben den Nachteil, dass Nachrichten und Zustandsin- formationen des ausgefallenen Brokers nicht in dem Neuen erhalten sind.

Abbildung 4.1: Conventional broker clusters, [Clu13]

Enhanced broker clusters (Bild 4.2 ) bieten data availability und service availability. Der Unterschied hier ist, dass der neue Cluster einen Zugang zu allen Informatio- nen und Nachrichten des ausgefallenen Brokers erlaubt. Das wird durch das Benutzen gemeinsamer Datenspeicher realisiert. Dieser Speicher ist durch eine highly-available JDBC Datenbank repräsentiert. Im Gegensatz dazu hat in den conventional broker clusters jeder Cluster einen separaten Datenspeicher. Die enhanced Broker clusters bieten auch recovery at failover, was auch für eine zuverlässige Nachrichtenvermittlung spricht.

Ein weiteres Kriterium ist Persistenz. In [Wik13c] ist Persistenz deﬁniert als „die Fähigkeit, Daten (oder Objekte) oder logische Verbindungen über lange Zeit (ins- besondere über einen Programmabbruch hinaus) bereitzuhalten“ . Dies wird durch die Verwendung von Datenbanken ermöglicht. Zwei Typen von Persistenz werden unterschieden: persistenter Typ und nicht persistenter Typ. Der Unterschied zwischen beiden ist, dass bei dem persistenten Typ die Nachrichten nach der Vermittlung immer noch zur Verfügung stehen. Die nicht-persistenten Nachrichten werden nach der Übertragung aus dem Speicher gelöscht.

Hauptseminar Mihaela Tomova 4 Implementierungen 20

Abbildung 4.2: Enhanced broker clustering, [Clu13]

Persitenz wird auch durch JDBC (Java Database Connectivity) repräsentiert. JDBC ist eine Datenbankschnittstelle. In [Jü11] ist erwähnt, dass Nachrichten über eine standardisierte Schnittstelle auf Datenbanken gespeichert werden können. So können verschiedene Datenbanksystemen unterstützt werden, da der brokerseitige Zugriﬀ daten- bankneutral ist.

Man unterscheidet auch dateibasierte Persistenz. Durch das Anlegen von individu- ellen Dateien können Nachrichten persistent gespeichert werden. Bespiele für dateibasierte Persistenz ist AMQ Message Store, KahaDB MessageStore.

Unter dem Kriterium Robustheit versteht man die Fähigkeit eines Systems auch unter ungünstigen Bedingungen (z.B. Serverausfall) weiter zu funktionieren. Für Ro- bustheit bei den Message Brokers sprechen Kriterien wie Clustering und redelivery policy. In [Mes13] wird erwähnt, dass ActiveMQ im Vergleich zu anderen Brokern weniger robust ist. Bei extrem hohen Last oder bei tausenden von Queues stößt ActiveMQ an seine Grenze. Daraus kann ein temporärer Ausfall folgen.

Eine Möglichkeit für sichere Übertragung wird durch das hybride Verschlüsselungspro- tokoll SSL/TLS vorgestellt. SSL/TLS steht für Secure Socket Layer/Transport Layer

Hauptseminar Mihaela Tomova 4 Implementierungen 21

Security. Heutzutage wird nur TLS benutzt. TLS befindet sich in der Transportschicht in der TCP/IP-Schichtenmodell und ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung. Bekannte Implementierungen des Protokolls sind OpenSSL und GnuTLS. TLS wird in HTTPS, POP3, SMTP, XMPP und andere Protokolle eingesetzt. Eine weitere Möglichkeit ist JAAS (Java Authentication and Authoriza- tion Service). JAAS ist eine Java-API und dient zur Authentifizierung von Diensten und Bereitstellung von Zugriffsrechte.

4.1.1 RabbitMQ

RabbitMQ ist eine häuﬁg verwendete Implementierunge des AMQP Protokolls. Rab- bitMQ ist ein Open Source Message Broker Software, die von der Firma Rabbit Tech- nologies entwickelt wurde.

Wie auch in [Hal12] erwähnt, besteht RabbitMQ aus den folgenden vier Teilen: • RabbitMQ Server, der in der Sprache Erlang geschrieben ist

• Gateways für diversen Protokolle (HTTP, STOMP, u.a.)

• Bibliotheken für AMQP Clients (Java, .NET, Erlang)

• Plug-in Plattform, deren Arbeit sich durch drei Plug-ins weiter charakterisiert:

– „Shovel“ Plug-in (kopiert oder tauscht Nachrichten von einem Broker zu einem anderen), – „Federation“ Plug-in (kümmert sich um eine eﬃziente Mitteilung von Nachricht- en zwischen zwei Brokern), – „Management“ Plug-in (zur Steuerung und Überwachung von Brokern). RabbitMQ ist zuverlässig, robust, schnell und bietet viele Client- Bibliotheken, die Programmiersprachen wie Java, C++, Python und andere unterstützen. Dieser Broker kann mit Hilfe von Plug-ins auch Protokolle wie STOMP benutzen. Weitere Protokolle, die von RabbitMQ verwendet werden können, sind AMQP (Version 0-8, 0-9, 0-9-1) und XMPP (über Gateway). Als Nachteil kann man hier erwähnen, dass kein AMQ Protokoll in der Version 1.0 un- terstützt wird, aber gerade daran gearbeitet wird. In [Wik10] sind ein paar Testergeb- nisse für RabbitMQ zu ﬁnden. Die durchgeführten Tests zeigen, dass Clustering ange- boten wird. Bei high-availability Clustern entstehen Probleme in den Fällen, wenn

Hauptseminar Mihaela Tomova 4 Implementierungen 22

Knoten vorübergehend nicht online sind. Was sich noch von den Ergebnissen erkennen lässt ist, dass keine Skalierung für die Anzahl von Clients/queues existiert, was zu einer ineﬃzienten Nutzung von Speicherplatz führt.

Abbildung 4.3: Verbreitung von message Brokers,[Int14]

4.1.2 Apache ActiveMQ

Apache ActiveMQ ist noch ein sehr verbreiteter und bekannter message broker. In [Mes13] wird dieser Broker als zuverlässig, hoch performant und ressourcenschonend beschrieben. Ein Unterschied zu RabbitMQ ist, dass ActiveMQ die Java Message Ser- vice(JMS) Spezifikation unterstützt. Es gibt eine große Wahl an Möglichkeiten für Clustering. So z.B. kann ein high-availability Cluster durch eine Master/Slave Kon- figuration geschaffen werden. Wie im Punkt 4.1 erwähnt ist, bietet high-availability Clustering einen schnellen Ersetzen von einem ausgefallenen Cluster. Bei der Mas- ter/Slave Konfiguration kann ein Slavebroker den ausgefallenen Master ersetzen. Der Slavebroker enthält eine Kopie aller Daten des Masters. So wird eine eventuelle „single point of failure“ vermieden, da der Master schnell von einem Slavebroker ersetzt wurde. In [Nig09] kann man einen Skalierungstest finden, der zeigt, dass man mehrere Nachrichten zwischen zwei Broker senden kann, wenn man ActiveMQ im Vergleich zu RabbitMQ verwendet.

4.1.3 Apache Qpid

Apache Qpid ist ein open-source message Broker, der auf dem AMQ Protokoll basiert. In [Mes13] wird erwähnt, dass der Qpid Broker in zwei Versionen geboten wird. Die erste Version ist für Java Clients entwickelt und ist unter den Namen Java API für

Hauptseminar Mihaela Tomova 4 Implementierungen 23

Qpid bekannt. Die zweite Version (Qpid Messaging API ) wird von C++, Python und Microsoft .Net-Clients benutzt. Als Vorteil für Apache Qpid kann man die JMS-Client API erwähnen. Mit dieser API können sich Clients über AMQP auch mit anderen Brokern wie z.B. RabbitMQ verbinden.[Mes13]

4.1.4 OpenMQ

OpenMQ ist ein open-source Projekt, das von der Firma Oracle entwickelt wurde. OpenMQ implementiert die JMS-API Version 2.0. Dieser Message Broker bietet auch high availability performance, was für eine zuverlässige Kommunikation zwischen Clients und message Broker spricht. Die Sicherheit in OpenMQ wird durch SSL/TSL und JAAS erreicht.[Wik13b]

4.2 Zusammenfassung

In diesem Kapitel wurden einige Implementierungen durch selbstgewählte Kriterien miteinander verglichen. Diese Vergleiche geben einen Überblick über verschiedene MOM- basierte Softwares, die auf dem Markt existieren. Dennoch kann man nicht mit Sicher- heit sagen, dass eine Software einer anderen überlegen ist. Der Grund dafür ist, dass die zum Vergleich verwendeten Kriterien von weiteren Faktoren wie Programmiersprache und Anwendungsgebiet abhängig sind. So ist beispielsweise ein AMQP Message Broker eine bessere Lösung für Finanzsoftware im Vergleich zu einem JMS-basierten Message Broker.

Hauptseminar Mihaela Tomova 4 Implementierungen 24

Kriterien/Message RabbitMQ Apache Ac- Apache Qpid OpenMQ Brokers tiveMQ JMS/AMQP- AMQP JMS AMQP JMS Unterstützung Zuverlässigkeit Ja Ja Ja Ja Robustheit Ja Ja Ja Ja

Clients C, C++, Java, C, C, C++, Java und C Schnittstellen Erlang, C++, Erlang, Java JMS, Client API .NET, Phython, .NET, Python, .NET, Perl, Python, Ruby, u.A u.A. Ruby, u.A.

Unterstützung AMQP(0-8, AMQP1.0, AMQP1.0 TCP, UDP, für Messaging 0-9, 0-9- MQTT, HTTPS, Protokolle 1),MQTT, OpenWire, RMI STOMP, STOMP, XMPP, XMPP, UDP, HTTP HTTP, TCP

Sicherheit OpenSSL JAAS, LDAP pluggable JAAS repository security using Plugin, SASL SSl/TLS

STOMP- ja ja nein ja Unterstützung Persistenz k.A. Memory Mes- Memory Mes- dateibasierte sage Store, sage Store, Persistenz, AMQ Mes- Derby Mes- JDBC sage Store, sage Store, KahaDB JDBC API Message Store, JDB- SC Clustering/HA ja ja ja ja redelivery policy k.A. dead message k.A. automatic queue acknowl- edgement Dokumentaion sehr gut sehr gut gut gut Verbreitung hoch hoch niedrig niedrig

Tabelle 4.1: Open-source Projekte

Hauptseminar Mihaela Tomova 25

Anhang

Hauptseminar Mihaela Tomova Literaturverzeichnis 26

Literaturverzeichnis

[ASR+05] Arion, Alexandru ; Schöllhorn, Benjamin ; Reese, Ingo ; Gebhard, Jürgen ; Patsch, Stefan ; Frank, Stephan: MessageBroker(MB). http://www.informatik.uni-augsburg.de/lehrstuehle/swt/vs/ lehre/archiv/WS_05_06/VerteilteSysteme_Uebung/downloads/ MessageBroker.pdf. Version: 2005. – Message Broker [Online; zuletzt abgerufen am 30.12.2013]

[Clu13] Oracle: 4 Broker Clusters. http://docs.oracle.com/cd/E26576_01/doc. 312/e24949/broker-clusters.htm. Version: 2013. – Oracle Homepage [Online; zuletzt abgerufen am 30.12.2013]

[Con13] Contributors, Wikipedia: Streaming Text Oriented Messaging Pro- tocol. http://en.wikipedia.org/w/index.php?title=Streaming_Text_ Oriented_Messaging_Protocol&oldid=571515755. Version: 4 September 2013. – [Online; zuletzt abgerufen am 07.01.2014]

[Hal12] Haller, Andreas: Message Queuing System. http://media.itm. uni-luebeck.de/teaching/ws2012/sem-sse/andreas-haller-mqs.pdf. Version: 2012. – Message Queing System [Online; zuletzt abgerufen am 03.01.2014]

[Int14] Interest over Time. http://www.google.de/trends/explore?hl= en-US#q=activemq%2C%20rabbitmq%2C%20qpid%2C%20openmq&cmpt=q. Version: 2014. – [Online; zuletzt abgerufen am 03.01.2014]

[JMS13] Oracle: JMS Messages. http://docs.oracle.com/javaee/6/tutorial/ doc/bncdr.html#bncds. Version: 2013. – The Java EE 6 Tutorial [Online; zuletzt abgerufen am 30.12.2013]

[Jü11] Jürgens, Frank: Open Message Queue, Technische Universität Ilmenau, Fachgebiet AVT, Hauptseminar, 2011

Hauptseminar Mihaela Tomova Literaturverzeichnis 27

[Mah04] Mahmoud, Qusay H.: Middleware for Communications. 1. WILEY, 2004. – 487 Seiten

[Mes13] predic8 GmbH: ActiveMQ, Qpid, HornetQ und RabbitMQ im Vergleich. http://predic8.de/ activemq-hornetq-rabbitmq-apollo-qpid-vergleich.htm. Version: 17.01.2013. – ActiveMQ, Qpid, HornetQ und RabbitMQ im Vergleich, Thomas Bayer [Online; zuletzt abgerufen am 2013]

[Nig09] Nighttale, Dejan: Python messaging: ActiveMQ and RabbitMQ. http:// sensatic.net/activemq/python-messaging-activemq-and-rabbitmq. html. Version: 2009. – [Online; zuletzt abgerufen am 30.12.2013]

[Ric11] Richards, Mark: Understanding the Diﬀerences between AMQP and JMS. http://www.wmrichards.com/amqp.pdf. Version: 2011. – Understand- ing the Diﬀerencs between AMQP and JMS [Online; zuletzt abgerufen am 20.12.2013]

[SH05] Steffen Heinzl, Markus M.: Middleware in Java. 1. VIEWEG, 2005. – 280 Seiten

[Wik10] Wiki, Second L.: Message Queue Evaluation Notes. http: //wiki.secondlife.com/w/index.php?title=Message_Queue_ Evaluation_Notes&oldid=702853. Version: 2010. – [Online; zuletzt abgerufen am 03.01.2014]

[Wik13a] Wikipedia: Java Message Service. http://de.wikipedia.org/w/index. php?title=Java_Message_Service&oldid=124593646. Version: 2013. – [Online; zuletzt abgerufen am 15.11.2013]

[Wik13b] Wikipedia: Open Message Queue — Wikipedia, The Free Encyclo- pedia. http://en.wikipedia.org/w/index.php?title=Open_Message_ Queue&oldid=574334112. Version: 2013. – [Online; zuletzt abgerufen am 03.01.2014]

[Wik13c] Wikipedia: Persistenz (Informatik). http://de.wikipedia.org/ w/index.php?title=Persistenz_(Informatik)&oldid=125248373. Version: 2013. – [Online; zuletzt abgerufen am 18.12.2013]

[Wik14a] Wikipedia: Advance Message Queuing Protocol. http://en.wikipedia. org/w/index.php?title=Advanced_Message_Queuing_Protocol&oldid=

Hauptseminar Mihaela Tomova Literaturverzeichnis 28

588999213. Version: 2014. – Advance Message Queuing Protocol [Online; zuletzt abgerufen am 3.10.2014]

[Wik14b] Wikipedia: Hypertext Transfer Protocol — Wikipedia, Die freie En- zyklopädie. http://de.wikipedia.org/w/index.php?title=Hypertext_ Transfer_Protocol&oldid=12667691. Version: 2014. – [Online; zuletzt abgerufen am 03.01.2014]

[Wik14c] Wikipedia: Message-oriented middleware. http://en.wikipedia.org/ w/index.php?title=Message-oriented_middleware&oldid=591137752. Version: 2014. – [Online; zuletzt abgerufen am 03.01.2014]

Hauptseminar Mihaela Tomova Abbildungsverzeichnis 29

Abbildungsverzeichnis

3.1 Vereinfachte Sicht auf zwei Streams, [Hal12] ...... 6 3.2 MOM ohne JMS, [SH05] ...... 7 3.3 MOM mitJMS, [SH05] ...... 8 3.4 P2P-Kommunikation, [SH05] ...... 9 3.5 Sub/Pub-Kommunikation, [SH05] ...... 9 3.6 Message Interfaces, [SH05] ...... 10 3.7 How JMS Message Header Field Values are set, [JMS13] ...... 12 3.8 JMS Message Types,[JMS13] ...... 13 3.9 Aufbau des AMQP Frames, [Hal12] ...... 14 3.10 JMS-Message Routing, [Ric11] ...... 17 3.11 AMQP-Message Routing, [Ric11] ...... 17

4.1 Conventional broker clusters, [Clu13] ...... 19 4.2 Enhanced broker clustering, [Clu13] ...... 20 4.3 Verbreitung von message Brokers,[Int14] ...... 22

Hauptseminar Mihaela Tomova Tabellenverzeichnis 30

Tabellenverzeichnis

2.1 Vergleich RPC und MOM,[Mah04] ...... 3

3.1 Teile einer JMS-Nachricht und deren Beschreibung,[SH05] ...... 11

4.1 Open-source Projekte ...... 24

Hauptseminar Mihaela Tomova Abkürzungsverzeichnis 31

Abkürzungsverzeichnis

MOM ...... Message Oriented Middleware

RPC ...... Remote Procedure Call

QoS ...... Quality of Service

XML ...... eXtensible Markup Language

API ...... Application Programming Interface

PDF ...... Portable Document Format

AMQP ...... Advanced Message Queuing Protocol

XMPP ...... eXtensible Messaging and Presence Protocol

JMS...... Java Message Service

FIFO...... First In First Out

MQ ...... Message Queue

STOMP...... Streaming Text Oriented Messaging Protocol

P2P ...... Point-to-Point

Pub/Sub ...... Publish/Subscribe

SASL ...... Simple Authetication and Security Layer

TLS...... Transport Layer Security

SSL/TLS...... Secure Sockets Layer/Transport Layer Security

HTTP ...... HyperText Transfer Protocol

HTTPS ...... HyperText Transfer Protocol Secure

Hauptseminar Mihaela Tomova Abkürzungsverzeichnis 32

JDBC ...... Java DataBase Connectivity

JAAS ...... Java Authentication and Authorization Service

TCP/IP...... Transmission Control Protocol/ Internet Protocol

POP3 ...... Post Oﬃce Protocol version 3

Hauptseminar Mihaela Tomova Erklärung 33

Erklärung

Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebe- nen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröﬀentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gle- icher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen noch nicht vorgelegt worden.

Ilmenau, den 05. 01. 2014 Mihaela Tomova

Hauptseminar Mihaela Tomova