Message Queuing Systems

1
Message Queuing Systems
Andreas Haller Institut für Telematik, Universität zu Lübeck
Ratzeburger Allee 160, 23538 Lübeck, Germany
Email: [email protected]
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. E INLEITUNG
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 EventDriven 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. P ROTOKOLLE
A. Extensible Messaging and Presence Protocol (XMPP)
Das Extensible Messaging and Presence Protocol (XMPP;
www.xmpp.org) 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
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
•
•
•
at-least-once, exactly-once)
detach: Link trennen
end: Session beenden
close: Verbindung schliessen
Abbildung 2.
Aufbau des AMQP Frames (Quelle: [15])
III. M ESSAGE O RIENTED M IDDLEWARE
Message Oriented Middleware (MOM) bezeichnet die Implementierung der diversen Protokolle in Form von Middleware. Abbildung 3 zeigt die Architektur von MOM.
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.
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 “NonPersistent“ Nachrichten können dafür aber in einem “FastMode“ versendet werden, dessen Erfolg aber nicht garantiert
werden kann. Die Abarbeitung der Nachrichten folgt dem
FIFO-Prinzip.
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
C. RabbitMQ
RabbitMQ (www.rabbitmq.com) ist eine Open Source
Lösung, die das Advance Message Queuning Protocol (AMQP) 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 3.0.1 (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 http://
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 JavaCode.
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
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
}
}
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. M ESSAGE Q UEUING S ERVICES
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:
•
•
import
import
import
import
com.rabbitmq.client.ConnectionFactory;
com.rabbitmq.client.Connection;
com.rabbitmq.client.Channel;
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 + "’");
}
•
•
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 WebService. 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
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. Z USAMMENFASSUNG
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 CloudServices 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.
L ITERATUR
[1] B. Turakhia. Investigating message queueing systems. [Online]. Available: http://bhavin.directi.com/investigating-message-queueing-systems/
[2] IBM.
What
is
message
queuing?
[Online].
Available:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?
topic=%2Fcom.ibm.mq.csqzal.doc%2Ffg10240 .htm
[3] Wikipedia. Message queue. [Online]. Available: http://en.wikipedia.org/
wiki/Message queue
[4] MSDN. About messages and message queues. [Online]. Available:
http://msdn.microsoft.com/en-us/library/
[5] Linux. Linux and posix message queues. [Online]. Available:
http://linux.die.net/man/7/mqoverview/
[6] Event-driven architecture overview. [Online]. Available: http://www.
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:
http://www.itwissen.info/definition/lexikon/
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: http://datatracker.ietf.org/wg/xmpp/charter/
[12] Wikipedia. Xmpp. [Online]. Available: http://en.wikipedia.org/wiki/
XMPP
[13] IETF. Rfc6120. [Online]. Available: http://tools.ietf.org/html/rfc6120
[14] Wikipedia. Advanced message queing protocol. [Online]. Available:
http://en.wikipedia.org/wiki/AMQP
[15] OASIS, OASIS Advanced Message Queuing Protocol (AMQP) Version
1.0, OASIS, 2012.
[16] T. A. S. Foundation. Activemq. [Online]. Available: http://activemq.
apache.org/
[17] Wikipedia. Apache activemq. [Online]. Available: http://en.wikipedia.
org/wiki/Apache ActiveMQ
[18] Erlang programming language. [Online]. Available: http://www.erlang.
org/
[19] G.
T.
Talk.
Introduction
to
rabbitmq.
[Online].
Available: http://www.rabbitmq.com/resources/google-tech-talk-final/
alexis-google-rabbitmq-talk.pdf
[20] M. Howell. Homebrew - the missing package manager for osx.
[Online]. Available: http://mxcl.github.com/homebrew/
[21] Amazon. Amazon simple queue service (amazon sqs). [Online].
Available: http://aws.amazon.com/de/sqs/
[22] Microsoft. Windows azure: die cloud plattform von microsoft. [Online].
Available: http://www.windowsazure.com/de-de/
[23] MSDN. Windows azure service bus. [Online]. Available: http:
//msdn.microsoft.com/de-de/library/ee732537.aspx