Institut für Architektur von Anwendungssystemen
Universität Stuttgart Universitätsstraße 38 D–70569 Stuttgart
Fachstudie
Eine Analyse von open-source Message-oriented Middlewares hinsichtlich der Integrationsfähigkeit von Enterprise Integration Patterns
Timo Gutierrez, Marcel Graf
Studiengang: Softwaretechnik
Prüfer/in: Prof. Dr. Dr. h. c. Frank Leymann
Betreuer/in: Michael Falkenthal, M.Sc.
Beginn am: 1. April 2019
Beendet am: 1. Oktober 2019
Abstract
Die Integration von modernen Softwaresystem stellt auf Grund von wachsender Komplexität und großen Datenmengen eine Herausforderung dar. Um diesen Herausforderungen zu begegnen wurden von Hohpe und Woolf Enterprise Integration Patterns (EIPs) vorgeschlagen. In diesem Kontext stellt der Integrationsstil Messaging und somit Message-Oriented Middlewares (MOMs) einen wichtigen Bestandteil dar. Sie dienen dem asynchronen und zuverlässigen Austausch von Nachrichten und vereinfachen die Integration verschiedener Plattformen und Programmiersprachen. Diese Arbeit untersucht open-source MOMs hinsichtlich ihrer Integrationsfähigkeit von EIPs. Hierfür werden die EIPs zuerst in fünf Gruppen kategorisiert. So beschreibt eine Gruppe die grundlegenden EIPs, welche integraler Bestandteile einer jeden MOM sind. Weitere EIPs umfassen nicht den Scope einer MOM. Im Rahmen dieser Arbeit werden deshalb die MOMs auf Grundlage der Gruppe weiterführenden EIPs detailliert untersucht. Diese detaillierte Analyse umfasst die drei open-source MOMs Apache ActiveMQ, Apache Kafka und RabbitMQ. Apache ActiveMQ unterstützt die weiterführenden EIPs vollständig und bietet darüber hinaus auch die einfachste Form der Implementierung. RabbitMQ und Kafka unterstützen nur Teilmengen der weiterführenden EIPs. Die Untersuchung bringt hervor, dass die Integration von EIPs in MOMs ein mächtiges Werzeug, jedoch in MOMs nicht weit verbreitet ist.
3
Inhaltsverzeichnis
1 Einleitung 15 1.1 Motivation ...... 15 1.2 Message-oriented Middleware ...... 16 1.3 Enterprise Integration Pattern ...... 17 1.4 Ziele der Fachstudie ...... 17 1.5 Architektur des Anwendungsfall ...... 18 1.6 Gliederung der Fachstudie ...... 18
2 Recherche 21 2.1 Kriterien für die Recherche ...... 21 2.2 Vorgehensweise bei der Recherche ...... 21 2.3 Rechercheergebnis ...... 22 2.4 Zusammenfassung und Übersicht ...... 25
3 Referenzszenario 27 3.1 Referenzarchitektur ...... 27 3.2 Referenzkriterien ...... 29
4 Ergebnis und detaillierter Vergleich 31 4.1 Auswahl der MOMs ...... 31 4.2 Integration der EIPs ...... 32 4.3 Werkzeugunterstützung ...... 33 4.4 Implementierung der EIPs ...... 34 4.5 Gegenüberstellung der MOMs ...... 39
5 Diskussion 41
6 Fazit und Ausblick 43
Literaturverzeichnis 45
5
Abbildungsverzeichnis
1.1 Referenzarchitektur für die Analyse der MOMs ...... 18
3.1 Referenzarchitektur für die Analyse der MOMs ...... 27
4.1 Red Hat CodeReady Studio mit Fuse Tooling ...... 33 4.2 Normalizer Implementierung mit Fuse Tooling ...... 36
7
Tabellenverzeichnis
2.1 Zusammenfasssung der MOMs hinsichtlich Version, Lizenz und EIP Unterstützung 25
3.1 Zusammenfassung der Kriterien für die Bewertung der MOMs ...... 30
4.1 Auswahl der MOMs, die den Kriterien entsprechen ...... 31 4.2 Detaillierte Übersicht der EIP Integration ...... 39
9
Verzeichnis der Listings
4.1 ActiveMQ Normalizer: Konfiguration des Normalizers ...... 35 4.2 ActiveMQ Normalizer: Konfiguration der Java Bean ...... 35 4.3 ActiveMQ Normalizer: Funktion zur Normalisierung der Temperaturwerte .... 35 4.4 RabbitMQ Message Filter: Empfangen von gefilterten Nachrichten ...... 36 4.5 RabbitMQ Message Filter: Senden von gefilterten Nachrichten ...... 36 4.6 ActiveMQ Message Filter: Konfiguration des Message Filters ...... 37 4.7 ActiveMQ Content Enricher: Konfiguration des Enrichers ...... 37 4.8 ActiveMQ Content Enricher: Konfiguration der Java Bean ...... 37 4.9 ActiveMQ Content Enricher: Funktion um den Ort des Sensors hinzuzufügen .. 37 4.10 ActiveMQ Recipient List: Weiterleiten an eine statische Liste von Empfängern .. 38 4.11 ActiveMQ Content-Based Router: Routing je nach Sensortyp ...... 38
11
Akronyme
AMQP Advanced Message Queueing Protocol. 23
API Application Programming Interface. 23
DSL Domain-Specific Language. 32
EE4J Eclipse Enterprise for Java. 24
EIP Enterprise Integration Pattern. 15, 17
IDE Integrierte Entwicklungsumgebung. 33
IoC Inversion of Control. 32
IoT Internet of Things. 18
JSON JavaScript Object Notation. 28
MOM Message-oriented Middleware. 15, 16
MQTT Message Queuing Telemetry Transport. 23
XML Extensible Markup Language. 28
13
1 Einleitung
Die zunehmende Komplexität von Software und deren Schnittstellen oder stark wachsende Daten- mengen erfordern Muster (Pattern) um die Integration von Systemen und Daten zu vereinfachen. Ein möglicher Ansatz hierfür ist eine Message-oriented Middleware (MOM) als Integrationsplattform und die Nutzung von Enterprise Integration Patterns (EIPs) um die Integration zu vereinheitlichen. Diese Arbeit behandelt die integrierte Unterstützung von EIPs in MOMs. Das folgenden Kapitel führt in das Thema ein, erläutert die Grundlagen und zeigt die Ziele dieser Arbeit auf.
1.1 Motivation
Angetrieben durch den Fortschritt in der Technologie von Datenübertragung und -speicherung, hat in den vergangen Jahren die Datensammlung in den verschiedensten Bereichen enorm zugenommen. Niedrige Kosten für Datenspeicherung und schnelle Übertragungsraten erlauben die Übermittlung und Speicherung riesiger Datenmengen, die von verschiedensten Sensoren aufgezeichnet werden. Mittlerweile sind Industriemaschinen, deren korrekte Funktionsweise durch Sensoren überwacht wird, ebenso auf die Auswertung von Sensordaten angewiesen, wie Fahrassistenzsysteme in Au- tos. Weitere Anwendungsbeispiele sind die Verwendung von Sensoren in Handys und Wearables zur Steigerung der Funktionalität, sowie die Überwachung von Luftqualität, Temperatur usw. in Gebäuden mit Hilfe von Umweltsensorik. Häufig ist eine Auswertung der Sensordaten in kürzester Zeit von hoher Bedeutung, dadieauf- gezeichneten Daten sehr schnell an Wert verlieren. Ein Fehler in einer Industriemaschine, der bei weiterem Betrieb zu deren Defekt führen kann, sollte um größere Schäden zu vermeiden möglichst früh erkannt werden. Ein CO2-Sensor oder Rauchmelder muss einen Brand erkennen, bevor dieser gefährlich wird. Wird ein Gebäude zu stark beheizt, sollte die Klimatisierung zeitnah angepasst werden, um Energie zu sparen. Werden die entsprechenden Sensordaten erst Stunden später aus- gewertet, sind sie wertlos. Eine korrekte und schnelle Datenauswertung hat somit kommerzielle, ökologische und sogar sicherheitstechnische Aspekte. An entsprechende Softwaresysteme und -architekturen werden nicht nur hohe Anforderungen hin- sichtlich Geschwindigkeit und Latenz gestellt. Um aus der gesammelten Datenmenge sinnvolle Rückschlüsse ziehen zu können, müssen die Daten aggregiert und Informationen verschiedener Sensoren miteinander kombiniert werden. In einem Gebäude soll zum Beispiel bei zu kalter Tem- peratur nur dann die Heizung aktiviert werden, wenn das Fenster geschlossen ist. Auch solchen Anforderungen muss die Software gerecht werden.
15 1 Einleitung
Ein weiterer entscheidender Faktor stellt die Vielzahl und Komplexität der verschiedenen Software- systeme im Unternehmen und dessen Umfeld dar. Einerseits müssen sowohl verschiedene interne Softwaresysteme integriert und der Datenaustausch ermöglicht werden. Auf der anderen Seite müs- sen auch Integrationen zu verschiedenen externen Softwaresystemen von Kunden, Lieferanten oder Dienstleistern hergestellt werden. Um all den genannten Herausforderungen gerecht zu werden, benötigt man eine integrative und zuverlässige Kommunikation. Diese kann von MOM geboten werden. Im Hinblick auf die Verwirk- lichung eines solchen heterogenen und komplexen Datenaustausches zwischen Softwaresystemen, trifft man auf eine Vielzahl von benötigten Funktionen. Die EIP bieten Lösungsmuster für häufig auftretende Problemstellungen bei der Integration von komplexen Prozessen, Daten und Software in großen Unternehmen. Mithilfe von MOMs können diese Pattern implementiert werden. Da es sich dabei um Lösungen für wiederkehrende Problemstellungen handelt, ist es denkbar, dass MOMs bereits Implementierungen der EIPs zur Verfügung stellen. Eine Sammlung an generischen Pat- terns, die je nach Anwendungsfall konfiguriert bzw. implementiert werden können, stellen einen mächtigen Werkzeugkasten für die Integration von Softwaresystemen dar.
1.2 Message-oriented Middleware
Message-oriented Middleware (MOM) bezeichnet eine Software, die asynchrone Kommunikation mittels Nachrichten (Messages) zwischen Softwaresystemen ermöglicht [Gre04; Ley18]. Eine MOM wird benötigt um zuverlässig Nachrichten von einem System auf ein Anderes zu übertragen, auch wenn die Systeme durch unzuverlässige Netzwerke verbunden sind [Gre04; Ley18]. Falls Systeme oder Netzwerkverbindungen nicht verfügbar sind, wiederholt die MOM die Übermittlung der Nachricht, bis diese schließlich erfolgreich zugestellt wird [Gre04; Ley18]. Zu den zwei wichtigsten Messaging Konzepten zählen „send and forget“ und „store and forward“ [Gre04; Ley18]. Nachdem eine Anwendung eine Nachricht an die MOM übertragen hat, wird durch die MOM sichergestellt, dass die Nachricht schließlich beim Empfänger ankommt [Gre04; Ley18]. Die Anwendung selbst muss mögliche Übertragungsprobleme nicht handhaben, dieses Konzept nennt man „send and forget“ [Gre04; Ley18]. Das zweite wichtige Konzept „store and forward“ bezeichnet den Prozess, dass eine Nachricht beim Senden von der MOM zuerst gespeichert und dann weitergereicht wird [Gre04; Ley18]. Dies beginnt initial beim Sender und auf jedem Hopp bis die Nachricht schließlich den entgültigen Empfänger erreicht [Gre04; Ley18]. Hierdurch ist sichergestellt, dass die Nachricht jederzeit persistiert ist und nicht verloren geht [Gre04; Ley18]. Eine MOM kommt dann zum Einsatz, wenn eine asynchrone und zuverlässige Kommunikation oder eine Vereinfachung der Integration verschiedener Plattformen und Programmiersprachen gefordert ist [Gre04; Ley18]. Weitere Vorteile sind variables Timing und Throttling, wodurch der Empfänger die Geschwindigkeit beim Verarbeiten der Nachrichten selbst bestimmen kann [Gre04; Ley18]. Dies führt zu einem maximalen Durchsatz, aber nicht zu einer Überlastung [Gre04; Ley18]. Durch die lose Kopplung können Anwendungen Nachrichten senden und empfangen, unabhängig davon ob andere Teile des Gesamtsystems verfügbar sind oder nicht, dies führt insgesamt zu einer höheren Zuverlässigkeit und Verfügbarkeit [Gre04; Ley18].
16 1.3 Enterprise Integration Pattern
1.3 Enterprise Integration Pattern
Die Integration von Softwaresystemen stellen diverse Anforderungen. Beispielsweise müssen ver- schiedenste Technologien und Anwendungsarchitekturen verbunden oder sich ändernde domänen- spezifische Anforderungen umgesetzt werden [Sch10]. Oftmals wiederholen sich die Anforderungen und Problemstellungen. Aus der Architektur kennt man bereits seit Ende der siebziger Jahren soge- nannte Muster (Patterns) [Gre04; Sch10]. Seit den neunziger Jahren werden Patterns auch für die Softwareentwicklung verwendet [Sch10]. Begonnen hat es mit Pattern für Herausforderungen bei der Objekt-orientierten Programmierung [Sch10]. Im Laufe der Zeit entstanden immer mehr Pat- terns in verschiedenen Bereichen der Softwareentwicklung, unter anderem auch in der Architektur und Integration von Softwaresystemen [Gre04; Sch10]. Die Enterprise Integration Patterns (EIPs) wurden von G. Hohpe und B. Woolf zusammengetragen und umfassen 65 Patterns mit einem Fokus auf Integration von Softwaresystemen in Konzernen [Gre04]. EIPs tragen, wie Patterns im Allgemeinen, einen aussagekräftigen Namen, beschreiben eine Pro- blemstellung und einen Kontext [Gre04; Ley18]. Sie zeigen die Motivation, warum das Problem schwierig zu lösen ist und Alternativen, die das Problem nicht oder nicht so gut lösen [Gre04; Ley18]. Pattern beinhalten eine technologieneutrale Beschreibung und Vorgehensweise für die Pro- blemlösung, die unabhängig von einer konkreten Implementierung ist [Gre04; Ley18]. So können bewährte Lösungen von erfahrenen Experten weitergegeben werden und von Anderen verstanden und angewandt werden [Gre04; Sch10]. Die EIPs umfassen insgesammt 65 Patterns und werden im folgenden in fünf Gruppen unterteilt. Die erste Gruppe Integration Styles umfasst die EIPs File Transfer, Shared Database und Remote Procedure Invocation. Diese werden in dieser Fachstudie nicht behandelt, da sie dem Messaging Konzept widersprechenden. Grundsätzlich legen die EIPs einen Fokus auf die Integration mit MOMs [Gre04]. Deshalb umfassen sie auch die grundlegende Patterns Messaging, Message Broker, Message Bus, Message Channel, Message Endpoint und Message [Gre04]. Diese zweite Gruppe an Patterns beschreibt die konzeptionelle Grundlage für eine MOM und wird in dieser Fachstudie zu den grundlegenden EIPs zusammengefasst. Eine dritte Gruppe der EIPs zeigen Lösungen, wie fachliche Aspekte als Inhalt von Nachrichten dargestellt werden können. Hierzu zählen Command Message, Document Message, Event Message und Format Indicator. Andere Patterns beziehen sich auf Messaging-Clients, aber nicht auf die MOM. Diese client-seitigen EIPs sind eine weiter Gruppe und umfassen die Patterns Channel Adaptor, Envelop Wrapper, Idempotent Receiver, Invalid Message Channel, Message Sequence, Messaging Bridge, Messaging Gateway, Messaging Mapper und Selective Consumer. Alle weiteren 43 Patterns werden als fünfte Gruppe weiterführende EIPs zusammengefasst. Diese Patterns können in einer MOMs gelöst werden und gehen über die Basiskonzepte einer MOM hinaus. Die vollständige Liste, der weiterführenden EIPs findet sich im Abschnitt 4.5 Gegenüberstellung der MOMs.
1.4 Ziele der Fachstudie
Das erste Teilziel der vorliegende Arbeit ist einen Überblick über existierende Open-Source-MOMs zu geben. Hierfür soll eine Übersicht der MOMs, welche EIPs unterstützen könnten, erstellt werden. Eine erste Analyse soll die Einschätzung über die grundsätzliche Unterstützung von EIP liefern.
17 1 Einleitung
Anhand eines Anwendungsfalls wird nach erreichen des ersten Teilziels die Unterstützung von EIP durch die existierenden MOMs analysiert. Die Analyse der Funktionalität erfolgt anhand eines beispielhaften Use-Cases eines Smart Buildings, das zur Überwachung der Temperatur, Luftquali- tät usw. verschiedene Sensoren verwendet, deren Daten aggregiert und mit Hilfe der Ergebnisse verschiedene Aktoren triggern kann. Dieses Beispiel findet im Zuge des steigenden ökologischen Bewusstseins in der Bevölkerung vermehrt Anwendung, sowohl branchenübergreifend in der Indus- trie, als auch in Privathaushalten. Entsprechende Internet of Things (IoT)-Lösungen ermöglichen eine Steigerung der Nachhaltigkeit und des Komforts von Gebäuden. Der Anwendungsfall, welcher für die Analyse genutzt wird, stellt somit einen typischen und auch in Zukunft sehr relevanten Anwendungsbereich dar. Das abschließende Ziel stellt eine detaillierte Bewertung und ein Vergleich der MOMs in Hin- blick auf die integrierte Unterstützung von EIPs dar. Die Unterstützung von EIP im allgemeinen und ins speziellen MOMs soll diskutiert werden. Die Bewertung und Diskussion sollen als Ent- scheidungshilfe für die Wahl einer geeigneten MOM dienen, wenn entsprechende EIPs gefordert sind.
1.5 Architektur des Anwendungsfall
Für die Evaluation der Fähigkeiten der MOMs wird eine Softwarearchitektur zum Einsatz kommen, die verschiedene grundlegende EIPs beinhaltet. Der Anwendungsfall deckt die Einbindung diverser Sensoren ab und wird in Abbildung 1.1 dargestellt. Durch den Normalizer werden verschiedene Formate oder Repräsentationen von Events vereinheitlicht. Mit dem Message Filter können direkt ungültige oder unerwünschte Sensorevents gefiltert werden. Mittels Daten die auf einem separaten Speicher abgelegt sind, werden die Sensorevents angereichert. An Stelle der Datenbank könnten auch Webservices oder andere Systeme angebunden sein. Außerdem wird eine Zeitreihen Datenbank integriert um die Sensorevents zu persistieren. Parallel dazu werden die Events durch einen Content- Based Router auf verschiedenen Topics veröffentlicht.
Abbildung 1.1: Referenzarchitektur für die Analyse der MOMs
1.6 Gliederung der Fachstudie
Diese Fachstudie gliedert sich in die folgenden Kapitel:
18 1.6 Gliederung der Fachstudie
Kapitel 2 – Recherche stellt das Vorgehen bei der grundlegenden Recherche dar und präsentiert die aktuell verfügbaren Open-Source-MOMs.
Kapitel 3 – Referenzszenario beschreibt den Prozess und das Vorgehen für die detaillierte Analyse der MOMs und deren Fähigkeiten in Bezug auf Unterstützung von EIPs.
Kapitel 4 – Ergebnis und detaillierter Vergleich präsentiert die Ergebnisse der detaillierten Ana- lyse der EIPs Unterstützung in den MOMs.
Kapitel 5 – Diskussion diskutiert die Unterstützung von EIPs in verschiedenen MOMs, basierend auf den Ergebnisse aus Kapitel 4.
Kapitel 6 – Fazit und Ausblick fasst die Erkenntnisse der Arbeit zusammen und stellt mögliche Anknüpfungspunkte vor.
19
2 Recherche
Im folgenden Kapitel werden die Kriterien und die Vorgehensweise für die Recherche beschrie- ben. Anschließend folgt eine Auflistung mit Beschreibung sowie ein tabellarischer Vergleich der Rechercheergebnisse.
2.1 Kriterien für die Recherche
Das Ziel der Recherche ist eine Übersicht über aktuelle Open-Source-MOMs zu erstellen. Für die Recherche werden im Folgenden Kriterien definiert. Es handelt sich um Open-Source Software, damit der Einsatz in Unternehmen oder Forschung nicht beschränkt ist. Die MOM soll sich in einem aktiven Entwicklungszustand befinden, damit ein Einsatz in zukünftigen Projekten sinnvoll ist. Um den Entwicklungszustand zu bewerten, werden Aussagen auf der Projektwebseite sowie die Logeinträge der Versionsverwaltung analysiert. Wenn diese Analyse uneindeutig ausfallen sollte, wird die MOM in das Rechercheergebnis aufgenommen und auf diese Tatsache hingewiesen. Explizite Job und Task Queues sind ausgeschlossen, da diese nicht für den Nachrichtentransport konzipiert sind. Die EIPs definieren auch grundsätzliche Patterns, welche die Grundlage für eine MOM darstellen, somit implementiert jede MOM auch einen Teil der EIPs. Eine weitergehende Unterstützung von EIPs ist in der Recherche noch kein zwingendes Kriterium. Diese Fähigkeit wird nur angerissen und später in Kapitel 4 detailliert analysiert.
2.2 Vorgehensweise bei der Recherche
Für die Recherche kommen drei verschiedene Ausgangspunkte zum Einsatz, bei denen jeweils die Kriterien aus 2.1 auf die gefundenen Softwaresysteme angewandt werden. Ein Ausgangspunkt für die Recherche stellt die Webseite „Ultimate Message Broker Comparison“1 dar. Hier werden 28 Message Broker gelistet von denen sechs den Kriterien der Recherche entsprechen. Außerdem wurden als Ausgangspunkt die auf der Wikipedia Kategorie „Message-oriented middleware“2 verlinkten MOMs ausgewertet. Hiervon haben acht MOMs den Kriterien genügt und wurden entsprechend aufgenommen. Ein weiterer Ausgangspunkt war eine Google Suche mit dem Such- begriff "open source" AND ("message-oriented middleware" OR "message broker") 3, welche ungefähr 220.000 Ergebnisse lieferte. Hiervon wurden die ersten 50 Treffer eingehend anhand der zuvor
1https://ultimate-comparisons.github.io/ultimate-message-broker-comparison/ zuletzt überprüft am 22.08.2019 2https://en.wikipedia.org/wiki/Category:Message-oriented_middleware zuletzt überprüft am 20.07.2019 3https://www.google.com/search?q="open+source"+AND+("message-oriented+middleware"+OR+"message+broker")&hl= en zuletzt überprüft am 19.07.2019
21 2 Recherche genannten Kriterien ausgewertet und zu dem Ergebnis von 14 verschiedenen MOMs zusammenge- tragen. Duplikate in den Ergebnissen der drei Recherchen sorgen für ein Gesamtergebnis von 14 unterschiedlichen MOMs.
2.3 Rechercheergebnis
In der Recherche sind zahlreiche und größtenteils sehr unterschiedliche Systeme untersucht worden. Insgesamt halten 14 MOMs den in 2.1 definierten Kriterien stand. Im Folgenden wird diese Auswahl kurz vorgestellt. Zu jeder ausgewählten MOM werden die Besonderheiten beschrieben und ein Aussage über die weiterführende Integration von EIPs in den jeweiligen Systemen getroffen.
2.3.1 Apache ActiveMQ™
Nach eigener Aussage ist Apache ActiveMQ eine der beliebtesten und mächtigsten open-source MOMs [The19a]. Es unterstützt viele in der Industrie gängigen Protokolle und bietet darüber hinaus die Verfügbarkeit von Client-Implementierungen für verschiedene Programmiersprachen. ActiveMQ wird derzeit in zwei unterschiedlichen Ausprägungen vertrieben, ActiveMQ 5 und ActiveMQ Artemis.
ActiveMQ 5
ActiveMQ 5 ist die derzeitige Vollversion von ActiveMQ [The19a]. Sie kommt mit einer großen Bandbreite an zurverfügunggestellten Features. Besonders hervorzuheben, im Kontext dieser Arbeit, ist der Anspruch von ActiveMQ 5 die EIPs vollständig und einfach zu unterstützen. Dies wird insbesondere durch die Integration von Apache Camel umgesetzt.
ActiveMQ Artemis
Die Artemis Version von ActiveMQ wird als die neue Generation der MOM beschrieben. Sobald es einen ausreichend ähnlichen Funktionsumfang erreicht hat, wird Artemis zur Version ActiveMQ 6 und damit der Nachfolger von ActiveMQ 5.
2.3.2 Apache Kafka®
Apache Kafka ist eine verteilte Streaming Plattform. Der Kernarbeitsbereich einer solchen Plattform ist, ähnlich wie bei Messaging Systemen, Anwendungen die Möglichkeit zu bieten, gewisse Ströme (Streams) von Nachrichten zu veröffentlichen bzw. zu abonnieren und diese darüber hinaus in einer fehlertoleranten Art und Weise zu speichern. Diese Parallele qualifiziert Apache Kafka als eine MOM [The19g]. Hinsichtlich der EIPs wird in der Dokumentation keine Aussage getroffen. Jedoch ist Apache Kafka als ein Message Broker gelistet, der diese unterstützt [Hoh19]. Dort sind auch vereinzelt Beispiele zur Verwendung dargestellt.
22 2.3 Rechercheergebnis
2.3.3 Apache Qpid™
Apache Qpid beschäftigt sich mit Messaging Werkzeugen die mittels Advanced Message Queueing Protocol (AMQP) kommunizieren [The19b]. Dabei werden für unterschiedliche Plattformen unter- schiedliche Message Broker und Client Application Programming Interfaces (APIs) zur Verfügung gestellt. Die EIPs sind dabei nicht integriert.
2.3.4 Apache RocketMQ™
Apache RocketMQ wird als verteilte Messaging und Streaming Plattform beschrieben [The19c]. Trotz einiger interessanter Features, wie einer integrierten Service Discovery, wird die Integration von weiterführenden EIPs nicht zusätzlich unterstützt.
2.3.5 Emitter
Emitter ist eine skalierbare, einfache und effiziente Messaging Plattform mit geringeren Latenzen [Emi19]. Der Fokus von Emitter liegt auf Web- und mobilen Anwendungen sowie auf IoT Sze- narien [Emi19]. Emitter unterstützt nur Publish-Subscribe Channel und Message Filter von den weiterführenden EIPs.
2.3.6 HiveMQ Community Edition
HiveMQ wir nur in der Community Edition als open-source Message Broker vertrieben. Es hat einen starken Fokus auf Anwendungsfälle aus dem IoT-Umfeld und beschränkt sich auf das Message Queuing Telemetry Transport (MQTT) Protokoll [dcs19]. EIPs sind nicht integriert.
2.3.7 Moquette
Moquette ist ein leichtgewichtige Implementierung eines MQTT Brokers, der einfach installiert und in IoT Projekte eingebettet werden kann [Moq19]. Eine Unterstützung von weiterführenden EIPs ist nicht vorhanden.
2.3.8 Eclipse Mosquitto™
Eclipse Mosquitto ist ebenfalls ein MQTT Broker. Die Besonderheit hier ist dessen Leichtgewich- tigkeit [The19h]. Es ist extra dafür entworfen auf jeder Art von Geräten, unter niedrigen Ressour- cenverbrauch, zu funktionieren. Aufgrund dieser Leichtgewichtigkeit wird auf komplexere Feature wie die Integration der EIPs verzichtet.
23 2 Recherche
2.3.9 NATS
NATS ist ein einfaches, sicheres und hoch performantes open-source Messaging System mit einer Fokusierung auf Cloud native Anwendungen, IoT und Microservices Architekturen [Syn19]. Es ist ein Projekt der Cloud Native Computing Foundation und bietet Clients für viele Programmier- sprachen an [Syn19]. Bei NATS lässt sich kein Hinweis auf die Integrationsfähigkeit von EIPs finden.
2.3.10 NSQ
NSQ ist eine einfache und verteilte Messaging Plattform mit dem Anspruch horizontal zu skalieren, keinen Single-Point-of-Failure und wenige Abhängigkeiten zu haben [NSQ19]. NSQ bietet keine Unterstützung der weiterführenden EIPs.
2.3.11 OpenMQ
OpenMQ ist eine vollständige MOM [The19i]. Diese Projekt ist allerdings derzeitig pausiert (seit 2014), da es als Teil der Eclipse Enterprise for Java (EE4J) Initiative zur Eclipse Foundation transferiert wird. Es bietet keine Integration der weiterführenden EIPs.
2.3.12 RabbitMQ
RabbitMQ ist einer der meist genutzten Message Brokern [Piv19a]. Neben zahlreichen Funktionen und Werkzeugen für Entwickler, bietet es auch Integrierbarkeit für zumindest einige der EIPs. RabbitMQ wird unter anderem verwendet um die Anwendung der EIP zu demonstrieren [Hoh19].
2.3.13 Zaqar
Zaqar wird als ein mandatenfähiges Cloud Messaging System für Web- und Mobileentwickler be- schrieben [Ope19]. Zaqar bietet neben einer Websocket API auch eine RESTful API um die Integra- tion verschiedener Komponenten zu vereinfachen [Ope19]. Auch hier werden die weiterführenden EIPs nicht explizit integriert.
2.3.14 ZeroMQ
ZeroMQ wird zur verteilten asynchronen Kommunikation von Nachrichten verwendet. Im Gegensatz zu klassischen MOMs wird hierfür nicht zwangsweise ein zentraler Broker verwendet [iMa19]. Da es sich hierbei um eine eher kleinere Message Broker Bibliothek handelt, werden die EIPs nicht integriert.
24 2.4 Zusammenfassung und Übersicht
2.4 Zusammenfassung und Übersicht
Aus dem Ergebnis der Recherche geht hervor, dass die explizite Integration von EIP nur schwach verbreitet ist. In Tabelle 2.1 wird eine Zusammenfassung der zehn MOMs gezeigt. Aus ihr gehen die Versionen, Lizenzen und eine erste Aussage über die Integration der EIPs hervor. Lediglich Apache ActiveMQ implementiert, unter der Verwendung von Apache Camel, die EIPs in ihrer Gesamtheit [The19a]. Wie bei der kurzen Vorstellung von RabbitMQ bereits erwähnt, sind auch dort Ansätze einer solchen Unterstützung vorhanden. Diese beschränkt sich jedoch auf eine stark begrenzte Anzahl von EIPs. Ähnlich verhält es sich bei Apache Kafka. Ohne explizit auf EIPs einzugehen werden dort einzelne Patterns integriert. Die übrigen MOMs weisen keine weiterführende Integration der EIPs aus.
Name Version Lizenz EIP Apache ActiveMQ 5.15.9 Apache 2.0 Vollständig Apache ActiveMQ Artemis 2.9.0 Apache 2.0 Vollständig Apache Kafka 2.3.0 Apache 2.0 Teilweise Apache Qpid unterschiedlich4 Apache 2.0 Grundlegende Apache Rocket MQ 4.5.1 Apache 2.0 Grundlegende Emitter 2.678 AGPL 3.0 Grundlegende HiveMQ CE 2019.1 Apache 2.0 Grundlegende Moquette 0.12.1 Apache 2.0 Grundlegende Mosquitto 1.6.3 EPL 1.0 Grundlegende NATS 2.1.0 Apache 2.0 Grundlegende NSQ 1.2.0 MIT Grundlegende OpenMQ 5.1.1 CDDL v1.1 Grundlegende RabbitMQ 3.7.16 Mozilla Public License Teilweise Zaqar 2.0 Apache 2.0 Grundlegende ZeroMQ 4.3.2 GNU LGPLv3 + Grundlegende
Tabelle 2.1: Zusammenfasssung der MOMs hinsichtlich Version, Lizenz und EIP Unterstützung
4Java Broker: 7.1.4, C++-Broker: 1.39.0
25
3 Referenzszenario
Dieses Kapitel zeigt die Grundlagen für den Vergleich der unterschiedlichen MOMs. Es definiert wie in dieser Studie eine Aussage über die Integrationsfähigkeit hinsichtlich der EIPs zu treffen ist. Zum Einen geschieht dies durch die Einführung einer Referenzarchitektur für die Implementierung der Patterns. Zum Anderen werden Kriterien definiert die eine nachvollziehbare Entscheidung bei der Auswahl der MOMs und bei deren Vergleich ermöglichen.
3.1 Referenzarchitektur
Die EIPs umfassen insgesamt 65 von Hohpe und Woolf definierte Patterns. Diese EIPs wurden in Abschnitt 1.3 in die fünf Kategorien Integration Styles, client-seitige EIPs, fachliche EIPs, grundle- gende EIPs und weiterführende EIPs unterteilt. Um einen realitätsnahen Anwendungsfall abzubil- den, kommt im Rahmen dieser Arbeit eine Referenzarchitektur mit einer relevanten Teilmenge der client-seitigen, grundlegenden und weiterführenden EIPs zum Einsatz. Diese Referenzarchitektur wird verwendet um, im Verlauf der Studie, Implementierung exemplarisch darzustellen und zu Vergleichen. Sie soll zum Verständnis beitragen und darüber hinaus die praktische Relevanz bildlich aufzeigen. Im Folgenden wird die verwendete Architektur erläutert und vorgestellt.
Abbildung 3.1: Referenzarchitektur für die Analyse der MOMs
Das gewählte Szenario in Abbildung 3.1 bildet einen klassischen IoT Anwendungsfall ab. Ein Sensor sammelt Informationen über die Umgebung und generiert in einem gewissen Zeitintervall Nachrichten, die an unterschiedliche Zielsysteme geleitet werden sollen. Eine Nachricht soll zunächst in einem Normalizer (Pattern 3.1.1) vereinheitlicht werden. Ein exemplarischer Anwendungsfall wäre ein Sensor, der die Temperatur in Grad Fahrenheit übergibt, das System jedoch Werte in Grad Celsius erwartet. Diese Umrechnung des Temperaturwerts findet im Normalizer statt. Danach wird im Message Filter (Pattern 3.1.2) entschieden ob es sich um eine valide Nachricht handelt. Alle nicht validen Nachrichten werden verworfen, beispielsweise wenn ein Temperaturwert außerhalb eines
27 3 Referenzszenario definierten gültigen Bereiches liegt. Als nächstes erweitert der Content Enricher (Pattern 3.1.3) die in der Nachricht enthaltenen Informationen. In diesem Beispiel werden die Orte von Sensoren in einer externen Datenbank gespeichert und verwaltet. Im Content Enricher wird dann beispielsweise der Standort eines Sensors zur Nachricht hinzugefügt. Anschließend soll die Nachricht an eine statische Liste an Empfängern geleitet werden. Dies geschieht mithilfe einer Recipient List (Pattern 3.1.4). Ein Empfänger ist eine Datenbank, die die Nachrichten persistiert. Des weiteren wird die Nachricht an einen Content-based Router (Pattern 3.1.5) geleitet. Dieser leitet sie, abhängig vom Inhalt, an bestimmte Topics, die von anderen Systemen abonniert werden können.
3.1.1 Normalizer
Der Normalizer hat den Zweck alle Nachrichten von unterschiedlichen Sendern in ein einheitli- ches Format zu überführen. Wenn man das genannte Beispiel der Temperatur aufgreift, können die Eingangsnachrichten Werte in allen möglichen Einheiten beinhalten oder in unterschiedlichen Datenformaten wie Extensible Markup Language (XML) oder JavaScript Object Notation (JSON) eingehen. Der Normalizer benötigt somit intern einen Router der die jeweiligen Ausgangseinheiten bestimmt und sie den Umrechnungsfunktionen zuweist. Als Ergebnis werden dann alle Temperatur- werte in Celsius und einem einheitlichen Datenformat weitergeleitet.
3.1.2 Message Filter
Aufgabe des Message Filters ist es, im Allgemeinen, Nachrichten mit einer bestimmten Eigenschaft aus einem Fluss von Nachrichten zu filtern. Im Referenzszenario ist die Eigenschaft die Validität der Nachricht. Dabei sollen beispielsweise Werte die außerhalb eines bestimmten gültigen Bereichs als nicht valide gelten. Ein praktischer Fall wären Außentemperaturen von über 70°C, hier kann von einem ungültigen Messwert ausgegangen werden.
3.1.3 Content Enricher
Der Anwendungsfall eines Content Enricher ergibt sich, wenn das Zielsystem mehr Informationen benötigt als das Quellsystem bereitstellen kann. Da die Hardware auf Seite des Sensors meist möglichst einfach gehalten wird, könnten zusätzliche Informationen erst zu einem späteren Zeitpunkt hinzugefügt werden. Im angesprochenen Szenario fügt der Content Enricher den Nachrichten den Standort des Sensors hinzu.
3.1.4 Recipient List
Vergleichbar mit dem Versenden einer E-Mail, soll die Recipient List die Nachrichten an eine statisch definiert Liste an Empfängern weitergeben [Gre04]. Jeder Empfänger besitzt einen Channel über den er diese Nachrichten empfangen kann. In dieser Arbeit gibt es zwei Empfänger. Eine Datenbank um die Informationen der Nachrichten zu persistieren und einen Content-based Router.
28 3.2 Referenzkriterien
3.1.5 Content-based Router
Abhängig vom Inhalt einer Nachricht, soll sie auf unterschiedlichen Topics veröffentlicht werden. Das Pattern, welches hierfür verwendet wird, ist der Content-based Router. Er bestimmt anhand des Inhalts wohin die Nachricht weitergeleitet werden soll. Zielsysteme können dann die für sie relevanten Topics abonnieren.
3.2 Referenzkriterien
Um die Integrationsfähigkeit von EIPs einer MOM festzustellen, werden im Folgenden verschiede- ne Kriterien festgelegt. Diese dienen dem Zweck einen Vergleichsrahmen zu schaffen, der dazu befähigen soll die unterschiedlichen Grade der Unterstützung zu erfassen und in Relation setzen zu können. Des weiteren dienen die Kriterien zur Eingrenzung der in Kapitel 2 Recherche genannten Menge an MOMs. Sie bestimmen somit eindeutig welche Systeme in dieser Fachstudie, hinsichtlich der Integrationsfähigkeit von EIPs, detailliert untersucht werden.
3.2.1 Kriterium: Broker-seitige EIP Implementierung
Die meisten EIPs können client-seitig implementiert werden. Beispielsweise könnte ein Messa- ge Filter Client die Nachrichten eines Channels empfangen, diese filtern und an einen weiteren Channel senden. Diese client-seitige Implementierungen werden im Kontext dieser Arbeit nicht als Integrationsfähigkeit verstanden. In der Abgrenzung hierzu erfordert das erste Kriterium eine broker-seitige Implementierung und somit direkte Unterstützung durch die MOM. Der einfachste Fall hiervon wäre eine broker-seitige Konfiguration, beispielsweise mit XML-Dateien. Diese werden entweder während des laufenden Betriebs oder nach Neustart des Brokers geladen und resultieren direkt im gewünschten Verhalten der MOM, entsprechend der konfigurierten Patterns. Weiterhin wäre eine client-seitige Initialisierung vorstellbar. Diese unterscheidet sich von der client-seitigen Implementierung dadurch, dass der Client nur eine Deklarierung vornimmt, die wiederum vom Broker zum gewünschten Verhalten übersetzt wird. Dies ist die Linie, die für die Entscheidung über Integrationsfähigkeit in dieser Arbeit gezogen wird und somit auch ein obligatorisches Kriterium.
3.2.2 Kriterium: Anzahl der implementierten Patterns
Insgesamt umfassen die EIPs 65 einzelne Pattern. Allein durch den allgemeinen Anwendungsfall einer MOM, sind bereits einige Patterns bei allen MOMs integriert. Zum Beispiel sind die Pat- terns Message oder Message Channel integraler Bestandteil jeder MOM. Hierfür wurde bereits in Abschnitt 1.3 eine Gruppierung der EIPs eingeführt. Im Rahmen dieses Kriteriums wird deshalb nur die Gruppe weiterführende EIPs analysiert. Diese Gruppe umfasst 43 Patterns, welche in der Tabelle 4.2 aufgeführt sind. Es ist wahrscheinlich, dass einzelne MOMs nicht alle EIPs durch eine Implementierung unterstützen. Als Kriterium, ob eine MOM eine minimale relevante Unterstüt- zung der EIPs bietet, wird eine Untergrenze festgelegt. Diese obligatorische Grenze wird bei der Implementierung von mindestens fünf weiterführenden EIPs erreicht. Durch dieses Kriterium lässt es sich quantifizieren zu welchem Grad die Patterns in einzelnen MOMs integriert sind.
29 3 Referenzszenario
3.2.3 Kriterium: Nutzerfreundlichkeit der EIPs
Auch wenn die Integration von Softwaresystemen üblicherweise von Experten durchgeführt wird, ist die Nutzerfreundlichkeit ein wichtiger Aspekt. Dabei geht es vor allem darum, wie einfach es ist die EIPs zu verwenden. Es ist vorstellbar, dass gewisse Tools beim Erstellen der Architektur helfen können. Daneben wird der Aufwand der Integration, durch eine gute Dokumentation und die Art und Weise der Konfiguration oder Initialisierung, erleichtert und reduziert. Im Gegensatz zu den vorangegangen Kriterien, ist die Nutzerfreundlichkeit kein imperativer Bestandteil der Integrationsfähigkeit und nicht obligatorisch in dieser Arbeit. Dennoch lässt sich so zusätzlich bewerten wie weit vorangeschritten das Zusammenspiel zwischen den EIPs und der MOM ist.
3.2.4 Übersicht der Kriterien
Der Vergleichsrahmen für diese Arbeit ist zusammengefasst in Tabelle 3.1 dargestellt. Den Kriterien wird zugeordnet ob sie “obligatorisch“ sind oder nicht. Die Spalte “obligatorisch“ gibt an ob das Kriterium von der MOM zwingend erfüllt werden muss um in der Studie berücksichtigt werden zu können. In dieser Arbeit wird die Anzahl an implementierten Patterns als sehr wichtig erachtet. Grund dafür ist, dass dieses Kriterium eine sehr hohe Aussagekraft darüber hat in wie weit die EIPs Einzug in die Entwicklung der MOM gefunden haben. Zusätzlich wird vorausgesetzt, dass neben den grundlegenden EIPs fünf weiterführende EIPs implementiert werden. Das zweite nicht optionale Kriterium ist die broker-seitige Implementierung. Während die unterschiedliche Art und Weisen der Implementierung zur Bewertung verwendet werden, gilt die Möglichkeit der client-seitigen Realisierung als nicht zureichend. Einzig die Nutzerfreundlichkeit wird als optional angesehen. Sie kann die Arbeiten mit der MOM vereinfachen und dadurch positiv beeinflussen, ist aber nicht unabdingbar.
Kriterium Obligatorisch Broker-seitige EIP Implementierung Ja Anzahl der implementierten Patterns Ja Nutzerfreundlichkeit der EIPs Nein
Tabelle 3.1: Zusammenfassung der Kriterien für die Bewertung der MOMs
30 4 Ergebnis und detaillierter Vergleich
In diesem Kapitel wird die Durchführung und das Ergebnis der Studie vorgestellt. Dies geschieht anhand eines Vergleichs von ausgewählten MOMs. Zunächst wird die Menge der zu vergleichenden Systeme durch die in Kapitel 3.2 eingeführten obligatorischen Kriterien eingegrenzt. Diese bilden die Ausgangssituation für die folgende Analyse, wie die EIPs in den ausgewählten MOMs integriert sind. Dort wird zunächst auf die Art und Weise der Integration in den jeweiligen MOMs eingegangen. Im Anschluss folgt eine Untersuchung von etwaiger Werkzeugunterstützung. Nach der allgemeinen Betrachtung der Integration folgt, anhand der in Kapitel 3.1 erarbeiteten Referenzarchitektur, die praktische Umsetzung der EIPs. Das bedeutet insbesondere, dass sofern eine MOM die Möglichkeit zur Implementierung eines der Patterns in der Architektur bietet, versucht wird ein Beispiel hierfür zu erarbeiten. Den Abschluss dieses Kapitel bildet eine Gegenüberstellung der MOMs hinsichtlich der ermittelten Ergebnisse.
4.1 Auswahl der MOMs
Aus der Grundgesamtheit der MOMs wurden in Kapitel 2 die infrage kommenden Systeme erfasst. Der nächste Schritt is nun eine weitere Eingrenzung durch die festgelegten Kriterien aus Kapitel 3. Dies bedeutet, dass die MOM neben den grundlegenden EIPs auch weiterführende EIPs broker- seitig implementieren muss. Da die weiterführende Integration der EIP nur bei wenigen Systemen implementiert ist, fällt die Auswahl der zu untersuchenden MOMs knapp aus. Lediglich vier der Systeme erfüllen diese Kriterien. Namentlich sind das RabbitMQ, Apache Kafka und Apache ActiveMQ in den zwei Versionen 5 und Artemis. Diese Auswahl ist in Tabelle 4.1 dargestellt. Bei den zwei Versionen von ActiveMQ wird jeweils Apache Camel zur Implementierung der EIPs verwendet [The19e]. Aus diesem Grund und weil ActiveMQ Artemis noch nicht featurevollständig ist, wird es nicht gesondert analysiert [The19a]. Deshalb werden im Folgenden Apache ActiveMQ 5, RabbitMQ und Apache Kafka analysiert.
Name Version Lizenz EIP Apache ActiveMQ 5 5.15.9 Apache 2.0 Vollständig Apache ActiveMQ Artemis 2.9.0 Apache 2.0 Vollständig RabbitMQ 3.7.16 Mozilla Public License Teilweise Apache Kafka mit Apache Streams 2.3.0 Apache 2.0 Teilweise
Tabelle 4.1: Auswahl der MOMs, die den Kriterien entsprechen
31 4 Ergebnis und detaillierter Vergleich
4.2 Integration der EIPs
Im folgenden wird der Umfang der Integration der EIPs in den drei detailliert untersuchten MOMs betrachtet. In den nächsten Abschnitten wird die Umsetzung der EIPs direkt in den Brokern und für RabittMQ und Apache Kafka zusätzlich mögliche Frameworks für eine client-seitige Implementie- rung vorgestellt.
4.2.1 Apache ActiveMQ
Apache ActiveMQ unterstützt nach eigener Aussage alle EIPs [The19e]. Dies trifft nach einer eingehenden Analyse auf die grundlegenden und weiterführenden EIPs zu. Wobei die drei Integration Styles File Transfer, Shared Database und Remote Procedure Invocation, welche auch von Hohpe und Woolf zu den EIPs gezählt werden, nicht unterstützt werden. Ebenso sind die client-seitigen EIPs nicht in dieser MOMs umgesetzt. Die Integrationsfähigkeit der EIPs wird insbesondere durch die Integration von Apache Camel umgesetzt. Somit stehen prinzipiell alle Integrationsfähigkeiten von Apache Camel direkt broker-seitig in ActiveMQ zur Verfügung [The19e; The19f]. Die EIPs können in XML Dateien konfiguriert werden oder programmatisch mit Java definiert werden [The19e]. Ebenso ist eine Konfiguration mittels des EIP Control Bus zur Laufzeit möglich [The19d].
4.2.2 RabbitMQ
RabbitMQ integriert nicht alle EIPs, sondern nur eine Teilmenge. Dabei ist hervorzuheben, dass die EIPs auf der Internetpräsenz von RabbitMQ [Piv19a] explizit referenziert werden. Dort befinden sich auch Referenzen zu möglichen Implementierung verschiedener Patterns. Jedoch handelt es sich dabei um client-seitige Implementierungen, die im Kontext dieser Arbeit durch das in Kapitel 3.2.1 definierte Kriterium der broker-seitigen Implementierung nicht berücksichtigt werden. Nichts- destotrotz gibt es die Möglichkeit weiterführende EIPs zu verwenden. Eine direkte Konfiguration von EIPs über eine Konfigurationsdatei ist bei RabbitMQ nicht möglich. Die Patterns können über client-seitige Initialisierung verwendet werden. Hierfür bietet RabbitMQ Client-Bibliotheken für viele gängige Programmiersprachen an [Piv19a].
Spring Integration Framework
Hinsichtlich der Verwendung der EIPs wird unter anderem auf Spring Integration verwiesen. Mithilfe dieses Frameworks können die Patterns umgesetzt werden. Es ermöglicht die Kommunikation mit anderen Spring Anwendungen und Anwendungen die über RabbitMQ angebunden sind. Dabei kann auf Implementierungen mit Java Domain-Specific Language (DSL) zurückgegriffen werden, aber auch XML Konfigurationen werden unterstützt. Spring Integration übernimmt dabei integrale Funktionen um die Komponenten an sich simpler zu gestalten. Dieses Prinzip wird im Kontext von Spring unter dem Begriff Inversion of Control (IoC) zusammenfasst [Piv19b]. Dabei werden modulare wiederkehrende Elemente abstrahiert und durch das Framework verwendbar gemacht. Bei der Spring Integration Erweiterung sind das die EIPs. Das bedeutet, dass RabbitMQ in Kombination mit dem Framework dazu befähigt ist die EIPs auf ein einfache Art und Weise zu integrieren. Alleine bietet RabbitMQ jedoch ein geringe Integrationsfähigkeit hinsichtlich der Pattern.
32 4.3 Werkzeugunterstützung
4.2.3 Apache Kafka
In Kontrast zu den beiden vorangegangen MOMs wird in der Dokumentation nicht explizit auf die Patterns eingegangen. Die genauere Betrachtung zeigt aber, dass über die allgemeinen EIPs der MOMs auch weitere Patterns unterstützt werden. Ein Beispiel hierfür ist das Competing Consumer Pattern. Es wird über die sogenannten “Consumer Groups“ von Kafka realisiert. Diese werden implizit von der Client-Anwendung erstellt und im Broker verwaltet. Somit handelt es sich um eine client-seitige Initialisierung, welche im Kontext dieser Arbeit als valide Integration gilt. Das gilt ebenfalls für die anderen unterstützten EIPs. Jedoch fällt die Anzahl dieser Patterns bei Kafka sehr gering aus.
Apache Kafka Streams
Apache Kafka Streams ist seit Apacke Kafka 0.10 ein Teil des Apache Kafka open-source Projekts [Con19]. Apache Kafka Streams ist eine client-seitige Bibliothek für ein vereinfachtes Streams Processing [Kre16]. Dies ermöglicht die Umsetzung einiger EIPs, aber widerspricht dem Kriterium, dass die EIPs broker-seitig umgesetzt werden können. Deshalb wurde Apache Kafka Stream im Rahmen dieser Arbeit nicht näher analysiert.
4.3 Werkzeugunterstützung
Für Apache ActiveMQ existiert eine indirekte Werkzeugunterstützung durch Fuse Tooling. Fuse Tooling ist für eine einfache Integration von Anwendungen mithilfe von Apache Camel und unter- stützt somit indirekt auch Apache ActiveMQ. Fuse Tooling ist entweder als Teil des Eclipse Plugins Red Hat JBoss Tools oder in Red Hat CodeReady Studio, eine Integrierte Entwicklungsumgebung
Abbildung 4.1: Red Hat CodeReady Studio mit Fuse Tooling
33 4 Ergebnis und detaillierter Vergleich
(IDE) auf Basis von Eclipse, verfügbar [Red19a]. Die Kernfunktionalität von Fuse Tooling wird im folgenden kurz beschrieben. Ein visueller Routing Editor ermöglicht die Integrationselemen- te grafisch aufzubauen, anzuordnen und zu verbinden [Red19b]. Diese visuelle Darstellung wird direkt mit einer XML Repräsentation bidirektional synchronisiert [Red19b]. Eine grafische Daten- transformation ermöglicht die Umwandlung verschiedener Datenformate und die Modifikation der Datentransferobjekte [Red19b]. Außerdem besteht die Möglichkeit von lokalem Testen und Monito- ring [Red19b]. Ebenfalls steht ein integrierter Debugger zur Verfügung, der auch Breakpoints im Routing Editor nutzen kann [Red19b]. Abbildung 4.1 zeigt Red Hat CodeReady Studio mit dem Routing Editor von Fuse Tooling. Diese Werkzeugunterstützung vereinfacht die Übersicht und die Entwicklung von Integrationsszenarien erheblich.
4.4 Implementierung der EIPs
Im Folgenden werden exemplarische Implementierungen der EIPs gezeigt und erklärt. Dies geschieht anhand der in Kapitel 3.1 erarbeiteten Architektur. Dabei wird sich die überwiegende Mehrheit der Beispiele auf ActiveMQ Implementierungen beschränken, weil dort alle der in der Architektur enthaltenen Patterns vollständig zur Verfügung stehen. Ziel ist es, die Funktionsweise der Integration der EIPs in MOMs näher zu erläutern und praktisch darzustellen. XML Konfigurationen und Code- Ausschnitte zeigen wie der erarbeitete Anwendungsfall umgesetzt werden kann. Darüber hinaus wird auch vereinzelt auf das Zusammenspiel mit etwaigen Werkzeugen eingegangen.
4.4.1 Normalizer
Die Implementierungen der Patterns können bei ActivMQ per XML konfiguriert werden. Diese Konfiguration wird, wie in Listing 4.1 zu sehen, innerhalb des camelContext Tag durchgeführt. Da diese Art der Umsetzung Teil der gängigen ActiveMQ Konfiguration ist, handelt es sich dabei um eine broker-seitige Implementierung. Bei Brokerstart werden die gewünschten Patterns initialisiert. Im Folgenden ist eine Umsetzung des ersten EIP der Architektur dargestellt. Der Normalizer soll in diesem Beispiel, abhängig vom Ausgangsformat der Nachricht, die Temperaturwerte in ein allgemeingültiges gemeinsames Format normalisieren. In diesem Fall in die Einheit Grad Celsius. Dies geschieht dadurch, dass je nach Typ (xpath: /sensor/type) eine unterschiedliche Konvertierungsfunktion aufgerufen und im Anschluss in ein und dieselbe Queue „commonformat“ geschrieben wird. Sensor Nachrichten deren Typ bereits Celsius ist, werden direkt dorthin geroutet. Nicht unterstütze Typen werden in die „deadletter“ Queue geleitet.
34 4.4 Implementierung der EIPs
In diesem Fall sind die Konvertierungsfunktionen in Java implementiert. Um auf Funktionen einer Klasse zugreifen zu können, muss sie als bean konfiguriert sein. Für die Normalizer Klasse ist dies in Listing 4.2 zu erkennen. Zusätzlich muss sie sich im classpath von ActiveMQ befinden.
Exemplarisch wird hier nun im Listing 4.3 die Implementierung der kelvinToCelsius Funktion gezeigt. Hervorzuheben sind dabei die unterschiedlichen Arten um auf die Nachricht zuzugreifen. Zum Einen sieht man, dass über die XPath-Annotation direkt Werte als Parameter übergeben werden können. Zum Anderen lässt sich über exchange.getIn().getBody() auf das komplette Objekt zugreifen. In der vorliegenden Implementierung wird zunächst der Typ auf die Bezeichnung für Grad Celsius gesetzt und im Anschluss die Temperaturangabe mithilfe des übergebenen Wertes von Kelvin zu Celsius umgerechnet. public void kelvinToCelsius(Exchange exchange, @XPath("/sensor/value/text()") Double value) { SensorEvent event = fromXML(exchange.getIn().getBody()); event.setType("temp-celsius"); event.setValue(value - 273.15); exchange.getOut().setBody(toXML(event)); } Listing 4.3: ActiveMQ Normalizer: Funktion zur Normalisierung der Temperaturwerte
35 4 Ergebnis und detaillierter Vergleich
Abbildung 4.2 zeigt die mögliche Implementierung des Normalizers mit dem visuellen Routing Editor von Fuse Tooling. Dort sind alle angesprochenen Bestandteile des Patterns grafisch aufbereitet. Diese Darstellungsform ist äquivalent zur XML Konfiguration in Listing 4.1.
Abbildung 4.2: Normalizer Implementierung mit Fuse Tooling
4.4.2 Message Filter
Für die Umsetzung des Message Filter EIP werden Beispiele von ActiveMQ und RabbitMQ erläu- tert. Zunächst zeigen Listing 4.4 und 4.5 die RabbitMQ Implementierung in Java. Die Methode startFilteredRecieve wird verwendet um Nachrichten mit einem Schlüssel, hier gegeben durch die filter Variable, zu empfangen. Korrespondierend dazu sendet die Methode sendMessage Nach- richten mit einem Schlüssel. Dabei handelt es sich um eine client-seitige Initialisierung, da es keine Brokerkonfiguration ist, sondern nur vom Broker zur Laufzeit umgesetzt wird. Darüber hinaus kann in diesem Fall nur durch Headerinformationen gefiltert werden. Das heißt insbesondere, dass nicht auf die Werte des Inhalts zugegriffen wird. Der Anwendungsfall des Filters in dieser MOM ergibt sich deshalb mehr aus vorher bekannten Kategorien als aus der Validität von Nachrichten. Beispielsweise könnte man hiermit Nachrichten filtern die Temperaturwerte senden. Somit würden Sensornachrichten mit CO2 Werten nicht weitergeleitet werden. Aufgrund dieser Beschränkung wird in dieser Studie davon gesprochen, dass RabbitMQ das Message Filter Pattern nur teilweise unterstützt. public static void startFilteredReceive(String filter, Channel channel) throws IOException { Consumer consumer = new DefaultConsumer(channel);
String queueName = channel.queueDeclare().getQueue(); channel.queueBind(queueName, EXCHANGE_NAME, filter);
boolean autoAck = true; channel.basicConsume(queueName, autoAck, consumer); } Listing 4.4: RabbitMQ Message Filter: Empfangen von gefilterten Nachrichten public void sendMessage(String filter) throws IOException { channel.basicPublish(EXCHANGE_NAME, filter, null, msg.getBytes()); } Listing 4.5: RabbitMQ Message Filter: Senden von gefilterten Nachrichten
36 4.4 Implementierung der EIPs
Bei ActiveMQ hingegen lässt sich dieses EIP, wie in Listing 4.6 gezeigt, umsetzten. Dort ist zu erkennen, dass in diesem Fall auf den tatsächlichen Inhalt der Nachricht zugegriffen werden kann. Der Ausschnitt zeigt die Filterung nach Werten die größer -50 sind. Temperaturen unter dieser Schwelle werden als nicht valide angesehen und verworfen.
4.4.3 Content Enricher
Ähnlich einfach lässt sich das EIP Content Enricher umsetzen. Listing 4.7 zeigt wie dies aussehen kann. Im Anwendungsfall dieser Studie soll, hier anhand einer eindeutigen Kennzeichnung eines Sensors, dessen Ort zu dem Inhalt der Nachricht hinzugefügt werden. Diese Information kann sich beispielsweise in einer Datenbank befinden.
Die insertLocationInfo Methode befindet sich auch hier in einer Java Klasse, die wie in Listing 4.8 zur Konfiguration hinzugefügt wird.
Das Listing 4.9 zeigt die Implementierung der Anreicherungsfunktion. Über die Variable id wird auf den Ort des Sensors zugegriffen. Das erhaltene Ergebnis wird dem Sensorevent hinzugefügt. Im Anschluss gibt die Methode die geänderte Nachricht wieder zurück. public void insertLocationInfo(Exchange exchange, @XPath("/sensor/id") String id) { String location = LocationStorageAccess.getInstance().getLocation(id); SensorEvent event = fromXML(exchange.getIn().getBody()); event.setLocation(location); exchange.getOut().setBody(toXML(event)); } Listing 4.9: ActiveMQ Content Enricher: Funktion um den Ort des Sensors hinzuzufügen
37 4 Ergebnis und detaillierter Vergleich
4.4.4 Recipient List
Das Recipient List EIP soll die Nachrichten nun an zwei statisch definierte Endpunkte weiterleiten. Zum Einen an eine Datenbank, dessen Aufgabe es ist die erhaltene Sensorwerte persistent zu speichern. Zum Anderen an einen Content-Based Router, der die erhaltenen Nachrichten je nach Typ veröffentlicht. Dies geschieht durch eine Konfiguration wie sie in Listing 4.10 dargestellt ist.
4.4.5 Content-Based Router
Das letzte Pattern der Architektur ist der Content-Based Router. An dieser Stelle angekommen, sollen die Sensorwerte je nach Typ zum weiteren Gebrauch veröffentlicht werden. Exemplarisch zeigt dies Listing 4.11. Die definierten möglichen Typen sind Temperatur2 undCO Werte. Analog zum Normalizer werden sie als Fälle unterschieden. Der Unterschied liegt nur darin, dass bei diesem Pattern keine zusätzliche Funktion aufgerufen wird. Nicht definierte Typen werden an die “deadletter“ Queue geleitet.
Damit ist die Referenzarchitektur vollständig umgesetzt. Anwendungen könnten nun per Publish- Subscribe auf die unterschiedlichen Werte zugreifen. In diesem Stile lässt sich eine Architektur nur mit ActiveMQ umsetzen. Auch wenn Apache Kafka und RabbitMQ einen Teil der weiterführende EIPs unterstützen, wie im Beispiel des Message Filter gezeigt, sind Konfigurationen dieser Art dort nicht möglich.
38 4.5 Gegenüberstellung der MOMs
4.5 Gegenüberstellung der MOMs
In der Referenzarchitektur ist nur ein Teil der weiterführenden EIPs enthalten. Innerhalb dieser Studie wurden die ausgewählten MOMs auf ihre Unterstützung der Integrierbarkeit jedes einzelnen der 43 weiterführenden EIPs überprüft. Eine Zusammenfassung des Ergebnis dieser Untersuchung findet sich in Tabelle 4.2. Dort wird zwischen vollständiger (+), teilweiser (o) und keiner (-) Unterstützung unterschieden. ActiveMQ unterstützt in diesem Sinne 41 von 43 weiterführenden EIPs vollständig und zwei weitere teilweise. ActiveMQ bietet somit eine vollständige Unterstützung der EIPs an. Bei RabbitMQ beschränkt sich die Unterstützung auf zwölf weiterführende EIPs die vollständig und drei die teilweise implementiert werden. 28 der weiterführenden EIPs werden von RabbitMQ nicht unterstützt. Apache Kafka weißt eine noch geringere Integrationsfähigkeit auf. In Apache Kafka werden nur sechs weiterführende EIPs vollständig, zwei teilweise und 35 Patterns gar nicht unterstützt.
Tabelle 4.2: Detaillierte Übersicht der EIP Integration Pattern ActiveMQ 5 RabbitMQ Kafka Aggregator + - - Canonical Data Model + o o Channel Purger + + - Claim Check + - - Competing Consumer + + + Composed Message Processor + - - Content Enricher + - - Content Filter + - - Content-Based Router + - - Control Bus + + + Correlation Identifier + + - Datatype Channel + + + Dead Letter Channel + + - Detour + - - Durable Subscriber + - + Dynamic Router + - - Event-Driven Consumer + + - Guaranteed Delivery + + - Message Dispatcher + + - Message Expiration + + - Message Filter + o - Message History + - - Message Router + + - Message Store + o o Message Translator + - - Normalizer + - - Legende: + vollständig o teilweise - nicht Fortsetzung auf nächster Seite
39 4 Ergebnis und detaillierter Vergleich
Tabelle 4.2 – Fortsetzung der Übersicht Pattern ActiveMQ 5 RabbitMQ Kafka Pipes and Filters + - - Process Manager + - - Recipient List + + - Request-Reply + + - Resequencer + - - Return Address + + - Point-to-Point Channel + + - Polling Consumer + + + Publish-Subscribe Channel + + + Routing Slip + - - Scatter-Gather + - - Service Activator + - - Smart Proxy o - - Splitter + - - Test Message o - - Transactional Client + - - Wire Tap + - -
40 5 Diskussion
Im Rahmen dieser Fachstudie wurden open-source MOMs hinsichtlich ihrer Integrationsfähigkeit von EIPs untersucht. Hierfür wurden die MOMs in Kapitel 4 detailliert verglichen. In diesem Kapitel folgt darauf basierend nun die Beurteilung der Integrationsfähigkeit. Dabei werden ein weiteres mal die Kriterien aus 3.2 zu Grunde gelegt. Als Kriterium wurde festgelegt, dass die EIPs broker-seitig implementiert sein müssen. Dabei ging es darum auszuschließen, dass die Patterns als eigenständige Anwendungen implementiert werden. Die wünschenswerteste Variante einer solchen Implementierung ist über eine Konfiguration direkt im Broker. Dafür ist die Unterstützung in den MOMs sehr schwach ausgeprägt. Lediglich ActiveMQ ermöglicht eine solche Konfiguration. Die beiden weiteren MOMs die weiterführende EIPs integrieren, bieten diese Möglichkeit nicht. Bei RabbitMQ und Kafka werden die Patterns durch die Client-Anwendung initialisiert. Die Anzahl der implementierten EIPs soll als Kriterium eine Aussage über den Grad der Unter- stützung ermöglichen. Hier sticht vor allem ActiveMQ hervor, welches, bis auf zwei nur teilweise unterstützte EIPs, alle weiterführende EIPs unterstützt. Bei Apache ActiveMQ kann somit von einer vollständigen Integration der EIPs gesprochen werden. RabbitMQ unterstützt 20 von 43 der Patterns komplett oder zumindest teilweise. Im Bezug auf ActiveMQ ist dies zwar ein deutlicher Unterschied, jedoch auch kein zu vernachlässigender Wert. Die wenigsten EIPs von den drei ausge- wählten MOMs integriert Apache Kafka. Es kommt auf acht komplett oder teilweise unterstützte Patterns, was im Kontext dieser Arbeit als sehr geringe Integration gilt. Das dritte und letzte Kriterium ist die Nutzerfreundlichkeit. Für RabbitMQ und Apache Kafka sind dabei vor allem die Bibliotheken und deren Dokumentation auf den Internetpräsenzen ausschlagge- bend, da es keine weitere Möglichkeit gibt die Patterns zu verwenden. Auch in diesem Kriterium sticht nur ActiveMQ heraus. Zum einen ist die Konfiguration in XMLs sehr einfach und zum an- deren gibt es eine umfangreiche Werkzeugunterstützung für diese MOM. Mit dem Fuse Tooling können Integrationskonfigurationen auch grafisch erstellt werden und es existiert die Möglichkeit für Monitoring und Debugging. Insgesamt ist die Integrationsfähigkeit von EIPs in MOMs nur gering ausgeprägt. Zu einem gewis- sen Teil ergibt sich aus dem Anwendungsfall einer MOM die Unterstützung von grundlegenden EIPs. Über diese Basis hinaus werden nur von wenigen Systemen weiterführende EIPs integriert. RabbitMQ und Apache Kafka haben in Ansätzen das Potential gezeigt die EIPs in einem relevan- ten Maße zu unterstützen. Jedoch geschieht dies nur in einem begrenzten Umfang. Dadurch dass im Kontext dieser beiden MOMs Frameworks existieren, die die Verwendung von EIPs ermögli- chen, kann man darauf schließen, dass eine vollständige Unterstützung nicht beabsichtigt ist. Einzig Apache ActiveMQ integriert die EIPs komplett und in einer einfach verwendbaren Art und Weise.
41
6 Fazit und Ausblick
Diese Fachstudie hat gezeigt, dass die Integration von EIPs in open-source MOMs zwar vorhanden, jedoch nicht weit verbreitet ist. Besonders auffallend dabei ist, dass aus einem relativ breiten Feld an open-source MOMs nur ein einzige MOM eine vollständige Unterstützung der EIPs aufweisen. Die Unterstützung von EIPs ist häufiger in einem Enterprise Service Bus vorhanden, welcher zwar auf einer MOM basieren kann, aber einen deutlich größeren Funktionsumfang bietet. Außerdem wurde deutlich, dass eine Gruppierung der EIPs nötig ist, da manche Patterns implizit in einer MOMs enthalten sind und andere Patterns dagegen sogar dem Messaging als Integrationsstil widersprechen. Darüber hinaus hat sich im Laufe dieser Studie, speziell während der Arbeit mit Apache ActiveMQ und Apache Camel, herausgestellt, dass eine Verfügbarkeit der EIPs über Konfigurationen ein sehr mächtiges Werkzeug darstellen. Mächtig in dem Sinne, dass dadurch sehr einfach eine geplante Integrationsarchitektur umgesetzt werden kann. Dank dem Fuse Tooling ist diese Erstellung der Konfigurationen sogar mit einem grafischen Editor möglich. Die gewonnenen Erkenntnisse führen zu neuen mögliche Fragestellungen. Zum Beispiel wäre es interessant in einer zukünftigen Arbeit näher auf die zur Verfügung stehenden client-seitigen Frameworks einzugehen. In dieser Fachstudie wurde angesprochen, dass auch RabbitMQ und Kafka mithilfe von Spring Integration beziehungsweise Kafka Streams zur einer breiteren Abdeckung der EIPs verholfen werden kann. An dieser Stelle würde sich ein Vergleich anbieten. Eine weitere interessante Arbeit stellt eine Art Metakonfiguration für die EIPs dar. Unter der Voraussetzung, dass mittels Spring Integration oder anderen client-seitigen Implementierungen der EIPs alle relevanten EIPs abgebildet werden könnte. Mit dieser Metakonfiguration könnte somit eine MOM unabhängige Architektur aus den Patterns aufgebaut werden und dann je nach Anwendungsfall in die entsprechende Konfiguration transformiert werden. Abschließend lässt sich festhalten, dass die Integration von EIPs in MOMs einen sehr umfangreichen Werkzeugkasten bietet. Das Beispiel von Apache ActiveMQ in Verbindung mit Fuse Tooling zeigt dies deutlich. Der komplexe Vorgang und der Aufwand für eine Anwendungsintegration kann hiermit stark reduziert werden.
43
Literaturverzeichnis
[Con19] Confluent. Streams FAQ. 16. Aug. 2019. url: https://docs.confluent.io/current/ streams/faq.html (zitiert auf S. 33). [dcs19] dc-square GmbH. HiveMQ MQTT Broker. 31. Juli 2019. url: https://www.hivemq. com/hivemq/ (zitiert auf S. 23). [Emi19] Emitter Studios B.V. Emitter: Scalable Real-Time Communication Across Devices. 1. Aug. 2019. url: https://emitter.io/ (zitiert auf S. 23). [Gre04] B. W. Gregor Hohpe. Enterprise integration patterns: designing, building, and deploy- ing messaging solutions. Englisch. Hrsg. von G. Hohpe, B. Woolf. The Addison-Wesley signature series. Literaturangaben. - Hier auch später erschienene, unveränderte Nach- drucke. Boston, Mass. [u.a.]: Addison-Wesley, 2004. isbn: 0-321-20068-3 (zitiert auf S. 16, 17, 28). [Hoh19] G. Hohpe. Enterprise Integration Patterns. 31. Juli 2019. url: https://www.enterpris eintegrationpatterns.com/ (zitiert auf S. 22, 24). [iMa19] iMatix. ZeroMQ. 31. Juli 2019. url: http://zeromq.org/ (zitiert auf S. 24). [Kre16] J. Kreps. Introducing Kafka Streams: Stream Processing Made Simple. 10. März 2016. url: https : / / www . confluent . io / blog / introducing - kafka - streams - stream - processing-made-simple/ (zitiert auf S. 33). [Ley18] F. Leymann. „Loose Coupling and Message-based Integration“. Lecture slides. 2018 (zitiert auf S. 16, 17). [Moq19] Moquette Authors. Moquette Documentation. 1. Aug. 2019. url: https://moquette- io.github.io/moquette/documentation.html (zitiert auf S. 23). [NSQ19] NSQ Authors. NSQ Docs 1.2.0 - Features and Guarantees. 1. Aug. 2019. url: https: //nsq.io/overview/features_and_guarantees.html (zitiert auf S. 24). [Ope19] OpenDev. Zaqar. 31. Juli 2019. url: https://wiki.openstack.org/wiki/Zaqar (zitiert auf S. 24). [Piv19a] Pivotal Software Inc. RabbitMQ. 31. Juli 2019. url: https://www.rabbitmq.com/ (zitiert auf S. 24, 32). [Piv19b] Pivotal Software Inc. Spring Integration. 25. Aug. 2019. url: https://docs.spring. io/spring-integration/reference/html/ (zitiert auf S. 32). [Red19a] Red Hat Inc. JBoss Tools - Downloads. 2. Sep. 2019. url: https://tools.jboss.org/ downloads/index.html (zitiert auf S. 34). [Red19b] Red Hat Inc. JBoss Tools - Fuse Tooling. 2. Sep. 2019. url: https://tools.jboss.org/ features/fusetools.html (zitiert auf S. 34).
45 [Sch10] T. Scheibler, Hrsg. Ausführbare Integrationsmuster. Deutsch. Text (nur für elektronische Ressourcen). Online-Ressource. 2010. url: http://nbn-resolving.de/urn:nbn:de: bsz:93-opus-54989 (zitiert auf S. 17). [Syn19] Synadia. About NATS | The best messaging system for native cloud application develop- ment. 1. Aug. 2019. url: https://nats.io/about/ (zitiert auf S. 24). [The19a] The Apache Software Foundation. ActiveMQ 5. 29. Juli 2019. url: http://activemq. apache.org/components/classic/ (zitiert auf S. 22, 25, 31). [The19b] The Apache Software Foundation. Apache Qpid. 31. Juli 2019. url: https://qpid. apache.org/index.html (zitiert auf S. 23). [The19c] The Apache Software Foundation. Apache RocketMQ. 31. Juli 2019. url: https : //rocketmq.apache.org/ (zitiert auf S. 23). [The19d] The Apache Software Foundation. Broker Configuration URI - ActiveMQ. 8. Aug. 2019. url: http://activemq.apache.org/broker-configuration-uri (zitiert auf S. 32). [The19e] The Apache Software Foundation. Enterprise Integration Patterns - Active MQ. 30. Juli 2019. url: http://activemq.apache.org/enterprise-integration-patterns (zitiert auf S. 31, 32). [The19f] The Apache Software Foundation. Enterprise Integration Patterns - Apache Camel. 8. Aug. 2019. url: https://camel.apache.org/manual/latest/enterprise-integratio n-patterns.html (zitiert auf S. 32). [The19g] The Apache Software Foundation. Introduction to Apache Kafka. 29. Juli 2019. url: https://kafka.apache.org/intro (zitiert auf S. 22). [The19h] The Eclpise Foundation. Mosquitto. 31. Juli 2019. url: https://mosquitto.org/ (zitiert auf S. 23). [The19i] The Eclpise Foundation. OpenMQ. 31. Juli 2019. url: https://javaee.github.io/ openmq/ (zitiert auf S. 24).
Alle URLs wurden zuletzt am 19. 09. 2019 geprüft. Erklärung
Ich versichere, diese Arbeit selbstständig verfasst zu haben. Ich habe keine anderen als die angegebenen Quellen benutzt und al- le wörtlich oder sinngemäß aus anderen Werken übernommene Aussagen als solche gekennzeichnet. Weder diese Arbeit noch we- sentliche Teile daraus waren bisher Gegenstand eines anderen Prü- fungsverfahrens. Ich habe diese Arbeit bisher weder teilweise noch vollständig veröffentlicht. Das elektronische Exemplar stimmt mit allen eingereichten Exemplaren überein.
Ort, Datum, Unterschrift