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

Transkript

1 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: geboren am: Studiengang: Studienrichtung: in Shumen Ingenieurinformatik Multimediale Informations- und Kommunikationssysteme Anfertigung im Fachgebiet: Kommunikationsnetze Fakultät für Elektrotechnik und Informationstechnik Verantwortlicher Professor: Wissenschaftlicher Betreuer: Prof. Dr. rer. nat. Jochen Seitz Dipl.-Ing. Karsten Renhak

2 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.

3 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 first 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.

4 Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einleitung 1 2 Fähigkeiten und Funktionen einer MOM 2 3 Protokolle und Standards XMPP Was ist XMPP? Aufbau von XMPP-Streams Vor- und Nachteile JMS Was ist JMS? Eigenschaften JMS Message Model Aufbau von JMS-Nachrichten AMQP Was ist AMQP? Message Model AMQP Wie ist AMQP aufgebaut? Aufbau von AMQP-Nachrichten Vor- und Nachteile Was ist STOMP? Was ist HTTP/HTTPS? Vergleich zwischen AMQP und JMS Implementierungen Beschreibung und Vergleich von typischen open-source Projekten RabbitMQ Apache ActiveMQ Apache Qpid

5 Inhaltsverzeichnis ii OpenMQ Zusammenfassung Literaturverzeichnis 26 Abbildungsverzeichnis 29 Tabellenverzeichnis 30 Abkürzungsverzeichnis 31 Erklärung 33

6 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 schaffen 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 findet man unter anderem auch bei Onlinespiele oder beispielsweise im Finanzsektor. Immer mehr wird MOM auch im Alltag der Menschen 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.

7 2 Fähigkeiten und Funktionen einer MOM 2 2 Fähigkeiten und Funktionen einer MOM Vor der Entwicklung einer nachrichtenbasierten Middleware wurde RPC (Remote Procedure Call) verwendet, um die Kommunikation zwischen Prozessen (Systemen) zu ermöglichen. RPC ist mit einem Telefongespräch vergleichbar. Bei dem Remote Procedure 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, weshalb nach einer Alternative geforscht wurde. Das Ziel von MOM war es daher, die Nachteile von RPC zu beseitigen und wachsende 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, flexibler 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).

8 2 Fähigkeiten und Funktionen einer MOM 3 Vorteile Nachteile RPC einfacher Mechanismus; direkte Nachrichtenübertragung durch synchrones Modell; garantierte sequenzielle Verarbeitung; langsam, aber widerspruchsfrei unflexible; enge Kopplung; alle Komponenten des Systems müssen funktionieren, ansonsten arbeitet das System nicht mehr; Skalierungsprobleme; mehr Bandbreite; unterstützt nur einen Client MOM weniger Bandbreite; keine großen Änderungen von Anwendungen; integrierte Infrastruktur, die Änderungen stören die Funktionalität des Systems nicht; unterstützt mehrere Clients keine Garantie für sequenzielle Verarbeitung, daraus folgen kurzfristige Ungenauigkeiten der Daten in der Datenbank Tabelle 2.1: Vergleich RPC und MOM,[Mah04]

9 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 entnehmen. Die dritte wichtige Kompetente ist der message Broker (message Provider). Die Hauptaufgabe eines message Brokers ist es, Nachrichten von einem Produzenten zu einem Konsumenten weiterzuleiten. Durch diese vermittelnde Instanz 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 und ausführlich beschrieben. Weitere Aufgaben sind in [ASR + 05] aufgelistet: Verbindung heterogener Systemen Übersetzung des Nachrichtenformates des Senders in ein oder in meherere Nachrichtenformaten des oder der Empfänger MOM sorgt für effiziente Nachrichtenvermittlung (priorisierbare Nachrichtenvermittlung) [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önnen 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.

10 3 Protokolle und Standards 5 3 Protokolle und Standards 3.1 XMPP Was ist XMPP? XMPP steht für Extensible Messaging and Presence Protocol und ist ein Kommunikationsprotokoll von MOM. XMPP wurde zunächst unter dem Namen Jabber bekannt 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] 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 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

11 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 Intranetservern 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 unmodifizierte binäre Daten zu übertragen. Anstatt XML kann man AMQP benutzen.[hal12] 3.2 JMS 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

12 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 wurde die erste Version (JMS 1.0.2b) entwickelt, gefolgt von Version 1.1 im Jahr Die aktuellste Version (2.0) wurde 2013 etabliert 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 Kommunikation 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] 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.

13 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 entsprechenden 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 Nachrichten an mehreren Konsumenten weiterleitet werden. Konsumenten und Produzenten brauchen nichts voneinander zu wissen. Der Produzent sendet die Nachrichten themenspezifisch 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] Aufbau von JMS-Nachrichten JMS Anwendungen kommunizieren mittels Nachrichten. Nachrichten sind einfach strukturiert, flexibel und können durch verschiedene Anwendungen verwendet werden. JMS

14 3 Protokolle und Standards 9 Abbildung 3.4: P2P-Kommunikation, [SH05] Abbildung 3.5: Sub/Pub-Kommunikation, [SH05] definiert das Superinterface Message. Davon werden die folgenden Subinterfaces abgeleitet (Bild 3.6):[SH05] BytesMessage MapMessage ObjectMessage StreamMessage

15 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 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 Organisationen ermöglicht wurden die ersten beiden AMQP-Versionen (0-8, 0-9) veröffentlicht, gefolgt von den Versionen 0-10 und im Jahr wurde die neuste Version (1.0) auf dem Markt gebracht Message Model AMQP Nachrichtenaustausch im AMQP erfolgt mittels exchanges und Warteschlangen. Die exchange-komponente dient nur als Verteiler und speichert keine Nachrichten.

16 3 Protokolle und Standards 11 Elements Description Required Nachrichtenkopf (Header) Enthält Information über Identifikation und Pfad von Nachrichten. Abb. 3.6 zeigt eine Auflistung von Header-Feldern und deren Werte. Ja Nachrichtenrumpf (Body) speichert Nutzdaten, die zum Nachrichtenaustausch benutzt werden. Mit Hilfe der Messaghe Typen (Subinterfaces) aus Abb. 3.8 kann man eine Übertragung verschiedener Nutzdaten ermöglicht werden. Nein Nachrichteneigenschaften (Properties) Verschiedene Datentypen (boolean, byte, int, short, u.a) stehen dem Entwickler zur Verfügung. Drei Eigenschaftskategorien können hier unterscheiden werden (anwendungsspezifische, JMS-definierte und providerspezifische) Nein 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 Exchange ä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

17 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. Typischerweise werden die Nachrichten an eine Warteschlange weitergeleitet.[ric11] Wie ist AMQP aufgebaut? AMQP kann in zwei Bereiche unterteilt werden: Nezwerkprotokoll-Teil und das Protokollmodell-Teil. Im ersten Teil wird entschieden, welche Informationen die Clientund 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 definiert neun verschiedene Frame-Bodies:[Hal12] open: neue Verbindung herstellen begin: neue Session erstellen attach: neuen Link erstellen transfer: Nachricht verschicken

18 3 Protokolle und Standards 13 Abbildung 3.8: JMS Message Types,[JMS13] flow: Nachrichtenaustauschkontrollschema disposition: Zuverlässigkeitseinstellung(at-most-once, at-least-once, exactly-once) detach: Link trennen end: Session beenden close: Verbindung schließen Aufbau von AMQP-Nachrichten Der Aufbau von AMQP Nachrichten ähnelt den Aufbau von JMS-Nachrichten. Wie in Punkt erwähnt, bestehen JMS-Nachrichten aus drei Teilen (header, properties section, message body). AMQP dagegen besteht aus mehreren Teilen (header, proporties, body and optional footer). Der header-teil im Vergleich zu JMS-header enthält unveränderliche anwendungsspezifische Eigenschaften. Der Property-Teil stellt die unveränderlichen Routing- und Metadaten Eigenschaften dar. Im AMQP existiert nur

19 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] 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 1 wird 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.

20 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 Message Broker erleichtert.[wik14b] 3.6 Vergleich zwischen AMQP und JMS Im Vergleich zu AMQP spezifiziert JMS eine API. D.h., JMS entscheidet, wie Senderund Empfängerseite implementiert sind. AMQP dagegen ist eine Lösung für Interoperabilitä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).

21 3 Protokolle und Standards 16 Damit Produzent (Sender) und Konsument (Receiver) Nachrichten austauschen können, müssen sie zunächst mit einer Warteschlange verbunden sein. Entweder sind beide mit einer Warteschlange des gleichen Namens verbunden oder der Produzent sendet themenspezifische Nachrichten, während der Konsument Themen abonniert. [Ric11] Weitere Unterschiede sind die Nachrichtenstruktur und Nachrichtenmodelle. Sie werden in Kapiteln 3.2.4, und in Kapiteln 3.2.3, beschrieben. In [Wik14a] wird erwähnt, wofür JMS nicht geeignet ist. JMS definiert einen Standard 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, OpenWire 2 ), 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. 2 Openwire ist ein wire-protokoll und wird von ActiveMQ benutzt.

22 3 Protokolle und Standards 17 Abbildung 3.10: JMS-Message Routing, [Ric11] Abbildung 3.11: AMQP-Message Routing, [Ric11]

23 4 Implementierungen 18 4 Implementierungen 4.1 Beschreibung und Vergleich von typischen open-source Projekten Heutzutage gibt es viele kommerzielle und offene 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äufig 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ässigkeit, 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 Nachrichtenü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 Broker ausfällt, wird die Kommunikation mittels eines anderen Brokers wiederhergestellt.

24 4 Implementierungen 19 Diese Art von Broker cluster haben den Nachteil, dass Nachrichten und Zustandsinformationen 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 Informationen 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 definiert als die Fähigkeit, Daten (oder Objekte) oder logische Verbindungen über lange Zeit (insbesondere ü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.

25 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 Zugriff datenbankneutral ist. Man unterscheidet auch dateibasierte Persistenz. Durch das Anlegen von individuellen 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 Robustheit 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üsselungsprotokoll SSL/TLS vorgestellt. SSL/TLS steht für Secure Socket Layer/Transport Layer

26 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 Authorization Service). JAAS ist eine Java-API und dient zur Authentifizierung von Diensten und Bereitstellung von Zugriffsrechte RabbitMQ RabbitMQ ist eine häufig verwendete Implementierunge des AMQP Protokolls. RabbitMQ ist ein Open Source Message Broker Software, die von der Firma Rabbit Technologies 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 effiziente Mitteilung von Nachrichten 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 unterstützt wird, aber gerade daran gearbeitet wird. In [Wik10] sind ein paar Testergebnisse für RabbitMQ zu finden. Die durchgeführten Tests zeigen, dass Clustering angeboten wird. Bei high-availability Clustern entstehen Probleme in den Fällen, wenn

27 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 ineffizienten Nutzung von Speicherplatz führt. Abbildung 4.3: Verbreitung von message Brokers,[Int14] 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 Service(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 Konfiguration geschaffen werden. Wie im Punkt 4.1 erwähnt ist, bietet high-availability Clustering einen schnellen Ersetzen von einem ausgefallenen Cluster. Bei der Master/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 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