Morphium messaging vs messaging systems

Morphium kann auch Messaging... wow... oder?

Warum braucht man denn noch so eine Lösung? Was ist denn im Vergleich mit anderen, wie z.B. RabbitMQ, MQSeries etc.? Das sind doch die Platzhirschen... Wozu noch eine Lösung?

Ich möchte hier mal einige Unterschiede auflisten

Konzeptionell

Morphium Messaging ist konzipiert als "persistiertes Messaging System". Die Idee ist, insbesondere Daten innerhalb der MongoDB einfacher "verteilen" zu können, gerade in Verbindung mit @Reference kann man damit sehr einfach auch komplexe Objekte via Messaging "übertragen".

Des weiteren sollte das System einfach zu benutzen sein, zusätzliche Hardware sollte nach Möglichkeit nicht benötigt werden. Insbesondere für die Cluster-Aware-Cache Synchronization war das ein wichtiges Designkriterium.

Das läuft über Annotations im Entity und dann muss man nur noch den CacheSynchronizer starten, und alles läuft im Hintergrund automatisch.

Features

Morphium ist ja quasi als persistierte Queue zu verstehen, das bedeutet, dass jederzeit neue Consumer zu einem Cluster hinzugefügt werden können und diese erhalten auch ältere, nicht verarbeitete Nachrichten. Das ist schon ein gravierender Unterschied zu anderen Messaging Systemen, wie z.B. RabbitMQ, bei denen das im Normalfall nicht möglich ist oder nur durch Umwege.

Dadurch, dass Morphium die Nachrichten persistiert, kann man sich mit jedem MongoDB-Client ansehen, was rein messagetechnisch gerade passiert. So gibt es z.B. auch eine rudimentäre Implementierung für Morphium messaging in python. Diese wird benutzt um z.B. einen Messaging Monitor anzuzeigen, einen Status darüber, was gerade alles passiert.

Morphium ist super einfach in bestehende Systeme zu integrieren. Natürlich am einfachsten, wen man schon Morphium (oder zumindest MongoDB) im Einsatz hat. Denn dann ist's quasi nur ein Dreizeiler:

Um in z.B. RabbitMQ ein "einfaches" Producer-Consumer Setup hinzubekommen, sind schon mehr Zeilen und Setup nötig.

im Konzept von Morphium wurde auch ein "Antwortkonzept" vorgesehen. So kann jeder MessageListener eine Message als Antwort einfach "returnen". Diese Nachricht wird dann direkt an den Empfänger gesendet. Etwas, das in anderen Messagingsystemen so nicht ohne Weiteres möglich ist.

in Morphium ist auch ein "Verweigern der Annahme" der Nachricht implementiert. Jeder Listener kann eien MessageRejectedException werfen. Die nachricht wird dann im aktuellen Messaging nicht weiter verarbeitet und so markiert, dass sie von anderen Empfängern abgearbeitet werden kann. Das passiert insbesondere auch, wenn es bei dem Messageprocessing zu einem Fehler / Einer Exception kam.

JMS

Morphium unterstützt auch JMS, jedoch ergibt sich dabei ein wenig einen logischen und konzeptionellen "Bruch"...

JMS versendet Nachrichten z.B. in Topics oder queues... in Morphium gibt es diese Unterscheidung nicht bzw. nur bedingt. Jede Nachricht kann in dieser Nomenklatur entweder Nachricht eines Topics oder einer Queue sein.

Sendet man in Morphium Messaging eine Nachricht, die als "nicht exclusive" gekennzeichnet ist (default), dann ist das ein Broadcast. Jeder Teilnehmer kann die Nachricht innerhalb der TTL (time to live) empfangen. Das wird nur daran entschieden, ob man einen Listener für diese Nachricht oder allgemein registriert hat, oder nicht.

Jeder Morphium Messaging Listener kann somit sowohl Topics, queues, Channels, direkt messages bekommen. Das wird mehr oder minder vom Sender bestimmt. Der Sender bestimmt, ob die Nachricht

• direkt an einen Empfänger gesendet werden soll (direct messaging)
• an alle listener (für einen bestimmen Messagenamen normalerweise) - also ein Broadcast (default)
• oder an einen der listener, aber egal welchen (exclusive message, ähnlich dem Topics im JMS)

Empty message-queue = healthy message queue

Das ist das, was man z.B. bei RabbitMQ immer wieder liest. Das ist bei Morphium so nicht richtig. Die Messages bleiben eine Zeit lang in der Queue und löschen sich selbsttätig nach einer Weile. Wenn ich eine broadcast message in die Queue gepackt habe mit einer Lebensdauer von einem Tag, dann kann diese Nachricht innerhalb eines Tages noch verarbeitet werden. Und wird sie auch, z.B. wenn neue "Consumer" sich anmelden. (replay of messages).

Das gilt nicht für exclusive messages, diese möchte man ja nicht mehrfach abarbeiten, d.h. die Message wird nach erfolgreichem processing gelöscht (bis V4.1.2 - danach werden die Nachrichten nur noch als bearbeitet markiert und wenn outdated automatisch gelöscht).

Damit ist eine Morphium Message Queue immer zu einem gewissen Teil gefüllt und das ist auch gut so.

Fazit

Morphium messaging will und kann gar kein "Ersatz" für bestehende Messagesysteme und Lösungen sein. Das war überhaupt nicht das direkte Ziel bei der Entwicklung. Es gab ein konkretes Problem, welches damit am einfachsten und effizientesten gelöst werden konnte.

Dennoch ähneln bzw. überschneiden sich die Einsatzgebiete von Morphium Messging zu anderen Messagingsystemen. Das liegt aber in der Natur der Sache. Eine Migration von einem zum Anderen System sollte durchaus in Endlicher Zeit möglich sein. Morphium unterstützt z.B. JMS, sowohl als Client, wie auch als Server. Damit kann man die Cache Synchronisierung über andere, evtl. schon bestehende Messaging Lösungen realisieren ohne auf den Komfort von Morphiums Annotations based Cache defintion verzichten zu müssen. Oder Morphium via JMS als Messaginglösung in die eigene Architektur integrieren.

Vergleichstabelle