Message Queuing Systems

Transkript

1 1 Message Queuing Systems Andreas Haller Institut für Telematik, Universität zu Lübeck Ratzeburger Allee 160, Lübeck, Germany Zusammenfassung Message Queuing Systems ist der Überbegriff für Message Oriented Middleware (MOM) sowie für die dabei verwendeten Protokolle, wie das Advanced Message Queuing Protocol (AMQP). Die Systeme kommunizieren synchron wie asynchron über so genannte Broker. Ziel ist, einen Nachrichtenaustausch zu etablieren, welcher einen hohen Nachrichtendurchsatz aufweist, und der vor allem zuverlässig ist. Message Queuing Systems sind die Grundlage für alle bekannten Instant Messaging Systeme am Markt, finden aber auch in jedem Betriebssystem bei der Taskabarbeitung Anwendung. In dieser Arbeit wird zunächst der Begriff Message Queuing Systems motiviert und die verwendeten Protokolle werden vorgestellt. Im weiteren Verlauf werden verschiedene Middlewarelösungen vorgestellt. Darauf folgt eine kurze Einführung über Message Queuing Systems und der angebotenen Softwarelösungen. Danach wird auf RabbitMQ näher eingegangen. Die Arbeit schließt mit einer Zusammenfassung bei der auch die zukünftige Entwicklung beleuchtet wird. Index Terms Message Queuing Systems (MQS), Message Oriented Middleware (MOM), Extensible Messaging and Presence Protocol (XMPP), Advanced Message Queuning Protocol (AMQP), Websphere MQ, Apache Active MQ, RabbitMQ, Message Queuing Services (MQS), Amazon Simple Queue Service (Amazon SQS), Microsoft Azure Services Platform I. EINLEITUNG Um das Thema Message Queuing Systems verstehen und einordnen zu können, muss man sich zunächst mit den Vorraussetzungen und der Entstehung dieser Systeme auseinandersetzen [1]. Message Queuing bezeichnet einen meist asynchronen Nachrichtenaustausch zwischen einem Sender und Empfänger. Ein Sender verschickt eine Nachricht, bei der sichergestellt ist, dass diese beim Empfänger ankommt und verarbeitet wird. Wann der Empfänger die Nachricht verarbeitet, kann der Sender nicht beeinflussen. Nur die tatsächliche Annahme und Verarbeitung ist sichergestellt. Message Queues oder Warteschlangen sind ein bereits etabliertes Verfahren der asynchronen Kommunikation. Vorallem innerhalb von Computersystemen oder innerhalb von Anwendungen wird dieses Prinzip schon seit Jahrzehnten eingesetzt. So sind das Betriebssystem Microsoft Windows, sowie Linux, ein Event- Driven System. Jede Eingabe oder Bewegung durch die Maus löst eine Nachricht oder Event aus. Über diese Nachrichten steuert das Betriebssystem seine eigenen Aufgaben, oder stellt Informationen an Anwendungen bereit. Die meisten Verfahren die hierbei verwendet werden, sind jedoch Closed Source und nicht ohne weiteres interoperabel [2], [3], [4], [5], [6]. Mit dem verstärkten Einsatz von verteilten Systemen wurde das Prinzip auch auf diese Problemdomäne übertragen. Nachrichten wurden jetzt über Rechnergrenzen hinweg verschickt. Die Anforderungen blieben gleich. Die Gefahr, dass Nachrichten über Rechnergrenzen hinweg verloren gehen, ist aber ungleich höher als innerhalb einer Anwendung oder eines Computersystems. Es entstand die Message Oriented Middleware (MOM) [7], [8]. Sie stellt nun die Basis für eine asynchrone Kommunikation zwischen Client und Server in einer verteilten Anwendung dar. Diese Form der Kommunikation steht im Gegensatz dazu, wenn Client und Server direkt und zeitgleich - also synchron - miteinander in Verbindung stehen und sich damit ebenso blockieren können. MOM wird daher auch als eine lose Kopplung zwischen den Teilnehmern bezeichnet [9]. Eine neuere Entwicklung sind die Message Queuing Services [10], welche die Leistungen der Message Oriented Middleware in die Cloud verschieben und somit Teil eines Software as a Service (SaaS) Netzwerkes sein können. Somit können die MOM-Funktionalitäten komfortabel über das Internet von nahezu jeder Plattform aus genutzt werden und ebenso komfortabel abgerechnet werden. Die weitere Arbeit ist wie folgt gegliedert: im nächsten Kapitel werden die gängigen Protokolle und deren Entstehung beschrieben. Kapitel 3 gibt einen Überblick über drei am Markt verfügbaren Message oriented Middleware Systeme und geht dabei im besonderen auf RabbitMQ ein. Kapitel 4 schließt mit der Beschreibung der Message Queuing Services. Das letzte Kapitel fasst die Erkenntnisse zusammen und gibt einen Ausblick über zukünftige Entwicklungen. II. PROTOKOLLE A. Extensible Messaging and Presence Protocol (XMPP) Das Extensible Messaging and Presence Protocol (XMPP; wurde zunächst unter dem Namen Jabber (www.jabber.org) bekannt. Es ist ein auf XML basierendes Protokoll, das von der Jabber open-source Gruppe 1999 zum Nachrichtenaustausch in Echtzeit ins Leben gerufen wurde [11]. Das Instant Messaging System Jabber war die erste Anwendung, die das Protokoll eingesetzt hat. In weiteren Iterationen des Protokolls wurde es von Google für Google Talk, von AOL für dessen Messenger und von Facebook für dessen Chat verwendet. Seit 2008 gehört Jabber zur Cisco Firmengruppe. Die Stärke von XMPP liegt in seiner Verbreitung. Da jedermann nicht nur Nutzer, auch einen eigenen XMPP Server betreiben können, gibt es keinen

2 2 zentralen Server und somit keinen Single Point of Failure. Die Sicherheit wird durch Isolation von einzelnen Netzen (isolierter Intranetserver) und durch eine hohe Verschlüsselung via Simple Authentication and Security Layer (SASL) und Transport Layer Security (TLS) gewährleistet. Auf das Protokoll aufbauend kann nahezu jede Funktionalität aufgesetzt werden. Die größte Schwäche von XMPP ist die Datenübertragung mittels XML. Hier gibt es deutlich bessere Ansätze wie das Advanced Message Queuing Protocol, das auf binären Datenversand setzt. Ein weiterer Nachteil ist die Client-Server-Kommunikation. Es findet keine direkte Kommunikation zwischen den einzelnen Nodes statt. Ein ursprüngliches Ziel von Jabber war es, die zu dieser Zeit auf dem Markt befindlichen Instant Messaging Systeme zusammenzuführen und sich somit mit nur einem Client, mit mehreren Systemen zu verbinden, welche nicht das XMPP Protkoll einsetzen. Dies hatte weniger mit dem Protokoll, sondern mehr mit der Serveranwendung zu tun, die solche Services bereitstellte. Das XMPP-Protokoll verwendet zur Kommunikation Streams. Der Grundlegende Aufbau dieser Streams ist, wie auch in Abbildung 1 zu sehen, in die drei Teile <presence\>,<message\>und <iq\>aufgeteilt. Die Verbindung wird über SASL und TLS verschlüsselt und per Simple Authentication gesichert [12]. B. Advanced Message Queuing Protocol Das Advanced Message Queuing Protocol, kurz AMQP, wurde im Juni 2006 von einer Gruppe von Unternehmen (JPMorgan Chase, Cisco Systems, Envoy Technologies, imatix Corporation, IONA Technologies, Red Hat, TWIST Process Innovations, 29WEST) ins Leben gerufen. Der Zusammenschluss hatte das Ziel, einen offenen Standard für ein interoperables, asynchrones Nachrichtenprotokoll zu etablieren. Bereits bei Gründung war die erste Spezifiaktion des Protokolls fertig. Aus diesem Zusammenschluss ging später das OASIS Technical Commitee hervor, das AMQP weiter standardisieren sollte und später Ende 2012 die Version 1.0 veröffentlichte. Eine Besonderheit dieses Protkolls liegt auch in der aktiven, kontinuierlichen Weiterentwicklung und darin, dass während dieser bereits Implementationen in den verschiedensten Programmiersprachen (Java, C++, Python) erschienen sind. Da dieses Protokoll aus dem Finanz und Börsensektor entstanden ist, bestanden auch hohe Anforderungen an Geschwindigkeit, Durchsatz, Skalierbarkeit und Verlässlichkeit. AMQP verfolgt keinen monolithischen Ansatz, sondern besteht aus zwei Teilen. Das Netzwerkprotokoll, welches den Inhalt spezifiziert, den Client- oder Serveranwendungen schicken müssen, um miteinander zu kommunizieren und dem Protokollmodell, welches die Standards an AMQP Anwendungen setzt, damit diese untereinander interagieren können. Der Nachrichtenaustausch wird in exchanges und message queues unterteilt: exchange ist der Verteiler, der anhand von Kriterien Abbildung 1. Vereinfachte Sicht auf Zwei Streams (Quelle: [13]) und Regeln die Nachrichten weiterleitet, sie aber nicht speichert message queues speichern die Nachrichten in einer Warteschlange; Dauer und Speicherort werden von der Implementation festgelegt Eine weitere Besonderheit ist die Verschiebung der Routinglogik in die Broker. Dies führt zwar dazu, dass bei der Implementation von AMQP, im Gegensatz zu anderen Protokollen, deutlich mehr programmiert werden muss, jedoch ist der Gewinn an Geschwindigkeit und der Vorteil, den Datenfluss modifizieren zu können ungleich größer. Das Netzwerkprotokoll sorgt nun dafür, dass die Interoperabilität gegeben ist. AMQP ist ein binäres Protokoll, da binäre Protokolle mehr Daten in einen Frame übertragen können und der Dataoutput beim Nachrichtenaustausch ein sehr wichtiger Faktor ist. Auch das binäre Protokoll sorgt für einen erhöhten Programmieraufwand, aber auch wieder für eine deutlich höhere Geschwindigkeit. Abbildung 2 zeigt den Aufbau eines AMQP Frames [14]. Es gibt neun verschiedene Frame-Bodies: open: neue Verbindung herstellen begin: neue Session erstellen attach: neuen Link erstellen transfer: Nachricht verschicken flow: Nachrichtenaustauschkontrollschema disposition: Zuverlässigkeitseinstellungen (at-most-once,

3 3 at-least-once, exactly-once) detach: Link trennen end: Session beenden close: Verbindung schliessen Abbildung 2. Aufbau des AMQP Frames (Quelle: [15]) III. MESSAGE ORIENTED MIDDLEWARE Message Oriented Middleware (MOM) bezeichnet die Implementierung der diversen Protokolle in Form von Middleware. Abbildung 3 zeigt die Architektur von MOM. A. Websphere MQ Websphere MQ von IBM, ist die wohl etablierteste kommerzielle MOM-Plattform. Sie ist mittlerweile über mehr als 10 Jahre gewachsen und für alle großen Plattformen (Windows, Linux, IBM z/os) verfügbar. Websphere MQ ist integraler Bestandteil der Service-Oriented Architecture Plattform (SOA) von IBM. Das MQ bezeichnet eine Aufteilung von den eigentlichen Messages, die wie bei AMQP binäre Daten sind, und den Message Queues welche die Nachrichten in den Programmen speichern. Die Queue Managers stellen dabei folgende Funktionalitäten bereit: Request & Reply Send & Forget Publish & Subscribe Die Websphere MQ Explorer sind grafische Interfaces, mit welchen die Queue Managers konfiguriert und gesteuert werden können. Bereits bestehende Anwendungen, welche nicht das closed Source Protokoll von IBM sprechen können, werden über Proxies angebunden. Dazu bietet IBM Schnittstellen zu folgenden APIs an: IBM Message QueueInterface (MQI) Java Message Service (JMS) WSDL SOAP Wie bereits erwähnt sind die Queue Managers verantwortlich für die Steuerung und den zeitlichen Abflauf der Kommunikation. Die Kommunikation ist über einzelne unidirektionale Channels gelöst. Jeder Manager benötigt also mindestens zwei Kanäle, um Daten zu senden und zu empfangen. Die Manager können unterbrochene Verbindungen automatisch wieder herstellen. Der Nachrichtenversand wird mitgeloggt, jedoch werden nur Nachrichten die als persistent gekennzeichnet sind, im Fall eines Ausfalls wieder hergestellt. Die Non- Persistent Nachrichten können dafür aber in einem Fast- Mode versendet werden, dessen Erfolg aber nicht garantiert werden kann. Die Abarbeitung der Nachrichten folgt dem FIFO-Prinzip. Abbildung 3. Architektur von MOM (Quelle: [9]) Die Protokolle werden zur synchronen Kommunikation genutzt, aber vor allem der asynchrone Ansatz findet Verwendung. Die Kommunikation wird in drei verschiedene Kommunikationsarten unterschieden: Publish & Subscribe Message Passing Message Queuing Alle Ansätze vereinen, dass die Ausführungsgeschwindigkeit der Programme gesteigert werden, sowie die Verfügbarkeit der Programme zunehmen kann. Die größte Stärke ist auch gleichzeitig die größte Schwäche der MOM. Wie in Abbildung 3 zu sehen, liegt die Middleware, wie der Name bereits vermuten lässt, zwischen den anderen Schichten und sorgt bei Absturz etc. für den Ausfall des Gesamtsystems und aller zu diesem Zeitpunkt verbundenen Systeme. Im folgenden werden nun drei ausgewählte MOM-Systeme vorgestellt. B. Apache ActiveMQ Apache ActiveMQ ist die Open Source Antwort auf Websphere MQ. Es gilt als die führende OpenSource Messaging Plattform. Da es auf Apache aufsetzt, ist es auch für ebenso viele Plattformen (u.a. Windows, Linux, Mac OSX) verfügbar. ActiveMQ ist ein Message Broker der die Java Standards JMS 1.1, J2EE 1.4, sowie JCA 1.5 unterstützt. Es wurde ursprünglich 2005 bei CodeHaus (www.codehaus.org) entwickelt und bereits 2006 von der Apache Software Foundation übernommen. Es ist heute das meist genutzte OpenSource Messaging-System der Welt [16], [17]. Ausser Java wird eine Reihe weiterer APIs unterstützt: OpenWire (Java, C, C++, C) Stomp (C, Ruby, Perl, Python, PHP, Flash) REST Ajax ActiveMQ unterstützt das AMQP-Protokoll und ist somit offen für eine Fülle von Clients.

4 4 C. RabbitMQ RabbitMQ (www.rabbitmq.com) ist eine Open Source Lösung, die das Advance Message Queuning Protocol (AM- QP) einsetzt. Der RabbitMQ Server ist in der Sprache Erlang geschrieben [18]. Das Unternehmen Rabbit Technologies Ltd. wurde im April 2010 von VMWare übernommen. Die Software wird aber weiterhin als Open-Source Lösung vermarktet. RabbitMQ besteht aus folgenden Teilen: RabbitMQ Server (nur Erlang) Gateways für diverse Protokolle (HTTP, STOMP, MQTT) offizielle AMQP Clients (Java,.NET, Erlang) unterstütze AMQP Clients (Spring, Groovy, Scala, Akka, Play!, Ruby, Python...) Das Unternehmen wirbt damit, dass es eine Lösung für nahezu jeden Client (siehe Abbildung 4) bereit hält, was vor allem auf die Verwendung des AMQP-Protokolls zurückzuführen ist. Bash completion has been installed to: /usr/local/etc/bash_completion.d To have launchd start rabbitmq at login: ln -sfv /usr/local/opt/rabbitmq/*.plist / Library/LaunchAgents Then to load rabbitmq now: launchctl load /Library/LaunchAgents/homebrew. mxcl.rabbitmq.plist Or, if you don t want/need launchctl, you can just run: rabbitmq-server Warning: /usr/local/sbin is not in your PATH You can amend this by altering your /.bashrc file Damit ist serverseitig alles installiert und konfiguriert, was zur Kommunikation benötigt wird. Der Server wird mittels launchctl load /Library/LaunchAgents/homebrew.mxcl. rabbitmq.plist gestartet. 2) Java-Client: Um eine erste mögliche Kommunikation mit RabbitMQ zu zeigen muss zunächst das Java-Package von der Website geladen und entpackt werden. Dann werden zwei Java-Dateien (Send /Receive) erstellt. Ziel ist es zu zeigen, wie man eine Verbindung zum Server aufbaut und eine Nachricht verschickt sowie empfängt. Weiterführende Beispiele, sowie auch dieses, werden auf der Herstellerseite unter dem Punkt Tutorials angeboten. Abbildung 4. RabbitMQ für viele Clients (Quelle: [19]) Im folgenden wird die Installation des Servers auf MacOSX 10.8 Mountain Lion beschrieben und ein einfaches Beispiel mit dem offiziellen Java-Client, um die Funktionalität zu illustrieren. 1) Download und Installation: Der RabbitMQ-Server liegt aktuell in der Version (Januar 2013) vor. Der Server lässt sich nicht nativ auf OSX installieren. Man muss zunächst sicherstellen, dass bereits die Addon-Software Homebrew [20] installiert ist. Die restlichen Abhängigkeiten werden dann bei der Installation von RabbitMQ automatisch nachinstalliert. Hat man alle Vorbereitungen getroffen, wird das Terminal geöffnet und folgendermaßen installiert: //aktuelle Homebrewupdates laden brew update // RabbitMQ Server installieren brew install rabbitmq Nach erfolgreicher Installation werden dem Nutzer die wichtigsten Informationen präsentiert, die man im weiteren Verlauf benötigt: Management Plugin enabled by default at localhost:15672 Zunächst wechseln wir in das Verzeichnis, in dem der Client entpackt wurde. Dort legen wir zwei neue Dateien (Send.java und Recv.java) an. Als Erstes befassen wir uns mit dem Sender. Für die Kommunikation müssen drei Imports hinzugefügt werden, damit die Verbindungen zum Server aufgebaut werden können. Jede Warteschlange muss bezeichnet werden, was unter QUEUE NAME gemacht wurde. Sollte die Bezeichnung für Warteschlange bereits vergeben sein, dann wird die bestehende Warteschlange verwendet (Idempotenz). Die Verbindung wird aufgebaut und auf der Verbindung wird ein Kanal zum Versand geöffnet. Auf dem Kanal wird die Warteschlange bekannt gegeben und danach die Nachricht veröffentlicht. Zur Kontrolle wird diese auch auf der Konsole ausgegeben und danach werden der Kanal und die Verbindung wieder geschlossen. Listing 1 zeigt den vollständigen Java- Code. Listing 1. send.java import com.rabbitmq.client.connectionfactory; import com.rabbitmq.client.connection; import com.rabbitmq.client.channel; public class Send { private final static String QUEUE_NAME = "Erste RabbitMQ Warteschlange"; public static void main(string[] argv) throws java.io.ioexception { //Verbindung aufbauen und Kanal erstellen ConnectionFactory factory = new ConnectionFactory(); factory.sethost("localhost");

5 5 Connection connection = factory.newconnection(); Channel channel = connection.createchannel(); channel.queuedeclare(queue_name, false, false, false, null); String message = "Hello World!"; channel.basicpublish("", QUEUE_NAME, null, message.getbytes()); System.out.println(" [x] Sent " + message + " " ); //Verbindungen schliessen channel.close(); connection.close(); Um Nachrichten zu empfangen, muss zusätzlich zum Versand, noch ein weiterer Import hinzugefügt werden, damit auch Nachrichten konsumiert, oder empfangen werden können. Auch hier wird wieder die Warteschlange deklariert. Sollte der Fall eingetreten sein, dass der Empfänger vor dem Sender gestartet wird, wird damit auch wieder die Warteschlange angelegt. Der Sender würde sich dann auf diese Verbinden und die Idempotenz ist weiterhin gegeben. Der Konsument fordert nun auf dem Kanal die Warteschlange an und gibt, solange es Nachrichten in der Warteschlange gibt, diese auf der Konsole aus. Listing 2 zeigt auch hier den vollständigen Java-Code. Listing 2. recv.java import com.rabbitmq.client.connectionfactory; import com.rabbitmq.client.connection; import com.rabbitmq.client.channel; import com.rabbitmq.client.queueingconsumer; public class Recv { private final static String QUEUE_NAME = "Erste RabbitMQ Warteschlange"; public static void main(string[] argv) throws java.io.ioexception, java.lang. InterruptedException { ConnectionFactory factory = new ConnectionFactory(); factory.sethost("localhost"); Connection connection = factory.newconnection(); Channel channel = connection.createchannel(); //Auf die gleiche Warteschlange verbinden channel.queuedeclare(queue_name, false, false, false, null); System.out.println(" [*] Waiting for messages. To exit press CTRL+C"); //Einen Konsumenten auf den Kanal hoeren lassen QueueingConsumer consumer = new QueueingConsumer (channel); channel.basicconsume(queue_name, true, consumer) ; //solange es Nachrichten gibt, gebe diese aus while (true) { QueueingConsumer.Delivery delivery = consumer.nextdelivery(); String message = new String(delivery.getBody ()); System.out.println(" [x] Received " + message + " "); 3) Kompilierung und Ausführung: Um das Beispiel auführen zu können, muss es zunächst kompiliert werden: javac -cp rabbitmq-client.jar Send.java Recv.java Um den Sender auszuführen: java -cp.:commons-io-1.2.jar:commons-cli-1.1.jar: rabbitmq-client.jar Send Die Nachrichten werden folgendermaßen empfangen: java -cp.:commons-io-1.2.jar:commons-cli-1.1.jar: rabbitmq-client.jar Recv IV. MESSAGE QUEUING SERVICES Message Queuing Services (MQS) sind die neueste Entwicklung im Bereich Message Oriented Middleware. Die Funktionalitäten der MOM-Systeme werden in eine Cloud verschoben, verbunden mit der Einbettung der Software in ein Software as a Service Modell. Nutzer können somit einfach Nachrichten aus der Warteschlange abrufen oder veröffentlichen, wenn sie mit dem Internet verbunden sind. Ziele der MQS sind: ungenutzte Kapzitäten freisetzen Kosten-Einsparungen (z.b. Wartungspersonal) Vereinfachung des Zugriffs auf die Warteschlange Performancesteigerung durch dedizierte Serverlandschaft Um eine Vielzahl von Nutzern zu erreichen, bieten die Lösungen eine Vielzahl an Protokollen, wie JMS, AMQP, REST-style APIs und Webservices an [10]. A. Amazon Simple Queue Service Amazon Simple Queue Service (Amazon SQS) bietet solch eine zuverlässige, hochskalierbare, gehostete Warteschlange zum Speichern von Nachrichten. Durch Amazon SQS können Entwickler auf einfache Weise Daten zwischen verteilten Komponenten ihrer Anwendungen, die verschiedene Aufgaben ausführen, verschieben. Dabei gehen keine Mitteilungen verloren und es muss nicht jede Komponente stets verfügbar sein. Amazon SQS vereinfacht das Erstellen eines automatisierten Workflows und arbeitet eng mit Amazon Elastic Compute Cloud (Amazon EC2) und den anderen AWS-Infrastruktur-Web-Services zusammen [21]. Amazon SQS funktioniert durch die Offenlegung der weboptimierten Mitteilungs-Infrastruktur von Amazon als Web- Service. Jeder Computer mit Verbindung ins Internet kann Mitteilungen hinzufügen oder lesen, ohne dass dafür Software installiert oder die Firewall speziell konfiguriert werden muss. Komponenten von Anwendungen, die Amazon SQS verwenden, können unabhängig ausgeführt werden und müssen sich nicht im selben Netzwerk befinden, mit denselben Technologien entwickelt worden sein oder zur selben Zeit ausgeführt werden.

6 6 B. Microsoft Azure Services Platform Microsoft hat im Februar 2012 auf der CeBIT, die Microsoft Azure Services Platform gestartet [22]. Microsoft zentralisiert damit die verschiedensten Dienste in die Cloud und versucht damit gegenüber dem Kunden als ein Full-Service-Anbieter aufzutreten. Die Platform vereint unter anderem: Webseitenhosting Virtuelle-Maschinen Cloud-Services Data-Services Messaging (Windows Azure Service Bus) Der Windows Azure Service Bus stellt hier ähnlich wie Amazon, Queuing Services bereit [23]. Microsoft hält hier eine REST konforme Schnittstelle, ebenso wie Konnektivitätsoptionen für die Windows Communication Foundation (WCF) bereit. V. ZUSAMMENFASSUNG Einstige alleinige Marktführer wie IBM bekommen nun schon seit Jahren den Druck der Mitbewerber zu spüren. Der Markt der Message Oriented Middleware ist einer der umkämftesten der Computerbranche. Dass sich auch hier der Markt immer mehr zu einem Käufermarkt entwickelt, sieht man vorallem an Firmen wie IBM, die ihrer Closed Source Plattform Websphere MQ immer mehr Proxies für diverse Open-Source Sprachen zur Verfügung stellen. Der Grund für die Vielfalt an Open-Source Lösungen ist sicher im Advanced Messaging Protocol zu sehen. Der Erfolg des Protokolls liegt in seiner Qualität. Weder im Bezug auf Geschwindigkeit noch im Bezug auf Customizing lässt es dem Programmierer Wünsche offen. Die Entwicklung des Protokolls hat für eine wahre Explosion an Produkten gesorgt. Unter anderem auch RabbitMQ, das in Bezug auf Kompabilität zu anderen Produkten seinesgleichen sucht. Ermöglicht wird auch das wieder durch das AMQP-Protokoll. Hinzu kommt bei RabbitMQ, dass die Dokumentationen im Internet und vor allem auf der Herstellerseite sehr gut sind. Die Forenunterstützung ist gut, was auch die hohe Anzahl an Clients und die Vielfalt an Programmiersprachen zeigen. Umso überraschender ist der Umstand, dass die neu angebotenen Cloud-Lösungen nun auch wieder propietäre Protokolle verwenden. So ist es nicht ungewöhnlich, dass die Internetforen voll von Diskussionen sind, was denn nun beser sei, Amazon SQS oder RabbitMQ. Vor allem da man RabbitMQ auch auf der Amazon EC2 Cloud betreiben kann. Die weitere Entwicklung wird sicher weiter Richtung Cloud- Services gehen. Zu günstig sind die Lösungen geworden, zu einfach deren Wartbarkeit, zu Ausfallsicher. Die Anbindung eines jeden Internetnutzers ist so gut geworden, dass auch hier keine Bandbreitenprobleme oder Geschwindigkeitsprobleme auftreten können. Dennoch werden sie Lösungen wie RabbitMQ nicht ablösen. Wahrscheinlicher ist es, dass die Welten weiter zusammenwachsen. LITERATUR [1] B. Turakhia. Investigating message queueing systems. [Online]. Available: [2] IBM. What is message queuing? [Online]. Available: topic=%2fcom.ibm.mq.csqzal.doc%2ffg10240.htm [3] Wikipedia. Message queue. [Online]. Available: wiki/message queue [4] MSDN. About messages and message queues. [Online]. Available: [5] Linux. Linux and posix message queues. [Online]. Available: [6] Event-driven architecture overview. [Online]. Available: omg.org/soa/uploaded%20docs/eda/bda2-2-06cc.pdf [7] E. Curry. Message-oriented middleware. [Online]. Available: http: //www.edwardcurry.org/publications/curry MfC MOM 04.pdf [8] Wikipedia. Message-oriented middleware. [Online]. Available: http: //en.wikipedia.org/wiki/message-oriented middleware [9] IT-Wissen. Mom (message oriented middleware). [Online]. Available: message-oriented-middleware-mom.html [10] Wikipedia. Message queuing service. [Online]. Available: http: //en.wikipedia.org/wiki/message queuing service [11] IETF. Extensible messaging and presence protocol (xmpp). [Online]. Available: [12] Wikipedia. Xmpp. [Online]. Available: XMPP [13] IETF. Rfc6120. [Online]. Available: [14] Wikipedia. Advanced message queing protocol. [Online]. Available: [15] OASIS, OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0, OASIS, [16] T. A. S. Foundation. Activemq. [Online]. Available: apache.org/ [17] Wikipedia. Apache activemq. [Online]. Available: org/wiki/apache ActiveMQ [18] Erlang programming language. [Online]. Available: org/ [19] G. T. Talk. Introduction to rabbitmq. [Online]. Available: alexis-google-rabbitmq-talk.pdf [20] M. Howell. Homebrew - the missing package manager for osx. [Online]. Available: [21] Amazon. Amazon simple queue service (amazon sqs). [Online]. Available: [22] Microsoft. Windows azure: die cloud plattform von microsoft. [Online]. Available: [23] MSDN. Windows azure service bus. [Online]. Available: http: //msdn.microsoft.com/de-de/library/ee aspx