Welches ist die richtige MOM?

176px-XMPP_logo.svg Aus reiner Neugierde heraus habe ich mir mal genauer angeschaut, welches Austausch-Format eigentlich am besten für eine MOM (Messaging Oriented Middleware) geeignet wäre, um eine eigene Messanger-Implementierung zu bauen. Es hat mich erstaunt, dass die Auswahl an offenen Formaten hier gar nicht so groß ist, wie ursprünglich vermutet und es eigentlich nur drei große Player hier gibt.

XMPP

XMPP wird auch Jabber genannt. Hier handelt es sich um ein textbasiertes Format, welches XML verwendet. Es wurde initial 1999 entwickelt und ist sehr weit verbreitet. Unter anderem wird es von WhatsApp und Google verwendet. Es hat sich deshalb bei Messanger-Applikationen als „De-Facto-Standard“ etabliert. Für die Client– und Serverseite gibt es zahlreiche Open-Source-Implementierungen wie z.B. den in Java geschriebenen XMPP Server Openfire.

Vorteile

Die meiner Ansicht nach wesentlichen Vorteile von XMPP sind deren weite Verbreitung und damit riesige Community und Dokumentation. Darüber hinaus sind zahlreiche stabile Implementierungen frei verfügbar. Das Format ist theoretisch auch mit anderen Messangern kompatibel und unabhängig von einer bestimmten Programmiersprache.

Nachteile

Als wesentliche Nachteile von XMPP zählen für mich das XML-Format, welches sich nachteilig auf die Geschwindigkeit auwirken kann. Nicht nur das XML selbst einen relativ hohen Daten-Overhead hat, Binärdaten z.B. müssen immer im Base64 codierten Format eingebettet werden, um diese Inbound versenden zu können und sind damit im Schnitt um ca. 30% größer. Da es sich um ein Format und keine API handelt, gibt es logischerweise auch keine Standard-API hierfür. Allerdings gibt es zahlreiche gute Implementierungen für verschiedene Programmiersprachen, die verwendet werden können.

JMS

JMS (Java Messaging Service) ist eine Java-Spezifikation für eine Messaging Oriented Middleware. Es konzentriert sich primär auf eine Maschine-zu-Maschine-Kommunikation und ist in der JEE-Welt sehr weit verbreitet. Anders als z.B. bei XMPP oder AMQP handelt es sich hierbei jedoch nicht um ein reines Austauschformat sondern um die Spezifikation eines Frameworks für das Messaging inkl. Java-API.

Vorteile

Mit der größte Vorteil ist sicherlich, dass JMS in der Java-Welt relativ einfach eingebunden und verwendet werden kann. Es ist klar verständlich und sehr gut dokumentiert. Zahlreiche gute Implementierungen wie z.B. ActiveMQ und Abstrahierungen z.B. über das Springframework, sowie eine klar strukturierte Java-API erlauben eine stabile und saubere Implementierung in kurzer Zeit.

Nachteile

Aus meiner Sicht der größte Nachteil von JMS besteht darin, dass es primär auf die Java-Welt zugeschnitten ist. Zwar gibt es inoffizielle Abstraktionen für C++ & Co. trotzdem habe ich hier kein „rundes“ Gefühl.

AMQP

Das Protokoll AMQP wurde ursprünglich von JPMorgan entwickelt, ist verhältnismäßig jung und kann – vereinfacht gesagt – als der Versuch bezeichnet werden, die Vorteile von XMPP und JMS zusammen zu fassen. Es handelt sich hierbei um ein rein binäres Austauschformat. Ziel war ein Format, das auch für den Hochfrequenz-Aktienhandelt verwendet werden kann.

Vorteile

Der größte Vorteil von AMQP ist sicherlich dessen Geschwindigkeit, da es sich hier um ein Binärformat handelt. Ein weiterer Vorteil eines solchen Formats ist es, dass Binärdaten 1:1 inbound übertragen werden können und keine Base64-Kodierung vorab benötigen. Es scheint auf längere Sicht hin XMPP den Rang abzulaufen.

Nachteile

Es ist bei weitem noch nicht so weit verbreitet wie XMPP. Daraus folgt, dass es noch keine so gute Dokumentation, Community und Open-Source-Software hierfür gibt, wie z.B. für XMPP oder JMS. Allerdings ist das, was derzeitig vorhanden ist, mehr als ein guter Anfang. Da es sich um ein breiteres Einsatzspektrum als bei XMPP handelt, sind viele Dinge im Bereich Instant-Messaging noch nicht vorhanden und müssen selbst erstellt werden.

Der Rest

Der Titel ist nicht abwertend gemeint. Trotzdem sind alle anderen Protokolle meist Spezialisierungen oder spielen nur eine untergeordnete Rolle, weswegen ich diese nicht einzeln betrachten möchte. Hierzu zählen vor allem STOMP als weiteres reines textbasiertes Protokoll und das binäre Format MQTT, welches eine noch größere Geschwindigkeitsoptimierung wie AMQP erreichen soll. Allerdings massiv auf Kosten des Funktionsumfangs. Letzteres ist daher primär für einfache Push-Nachrichten gedacht und weniger für umfangreiche Gruppen-Chats und Transfers.

Darüber hinaus gibt es noch zahlreiche proprietäre Formate, die vor allem speziell für den Instant Messanger Bereich entwickelt wurden und daher häufig nicht das gesamte Spektrum einer MOM abbilden: http://de.wikipedia.org/wiki/Liste_von_Instant-Messaging-Protokollen

Fazit

Allen drei Lösungen gemeinsam ist, dass sie auch unter großer Last betrieben werden können und es hierfür erprobte Konzepte gibt, die je nach Konzept mehr oder weniger gut funktionieren.

Wer schnell einen Chat-Client mit größtmöglicher Kompatibilität, Dokumentation, Community und Tools erstellen möchte, ist mit XMPP sehr gut beraten. Wer hingegen Wert auf hohe Geschwindigkeiten beim Datenaustausch legt, sollte AMQP ins Auge fassen. Und wer sich bereits in einer JEE-Umgebung befindet, wo es primär um den Austausch zwischen Maschinen und der Einhaltung von klaren Programmierstandards geht, sollte auf JMS bauen.

 

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s