Morphium messaging vs messaging systems

Morphium can also be messaging ... wow ... right?

Why do you still need such a solution? how does it compare to others, such as RabbitMQ, MQSeries etc.? Those are the top dogs ... Why another solution?

I would like to list some differences here

Conceptually

Morphium Messaging is designed as a "persistent messaging system". The idea is to be able to "distribute" data more easily within the MongoDB. Especially in connection with @Reference it is very easy to "transfer" complex objects via messaging.

Furthermore, the system should be easy to use, additional hardware should not be needed if possible. This was an important design criterion, especially for the cluster-aware cache synchronization.

Features

Morphium is to be understood as a persistent queue, which means that new consumers can be added to a cluster at any time and they also receive older, unprocessed messages.

Because Morphium persists the messages, you can use every MongoDB client to see what is happening purely in terms of messaging. there is a rudimentary implementation for Morphium messaging in python. This is used to e.g. display a messaging monitor, a status of what is happening right now.

Morphium is super easy to integrate into existing systems. The easiest of course, of course, if you already have Morphium in use. Because then it's just a three-line:

To e.g. To get RabbitMQ a "simple" producer-consumer setup, more lines and setup are necessary.

in the concept of Morphium, an "answer" was also provided. This means that every MessageListener can simply "reply" a message as a response. This message is then sent directly to the recipient. Something that is not easily achieved in other messaging systems.

An important feature is the synchronization of the caches in a cluster. This runs via annotations in the entity and then all you have to do is start the CacheSynchronizer, and everything runs automatically in the background.

  Morphium also provides a solution to "reject" an incoming message. Every listener can throw a MessageRejectedException. The message is then no longer processed in the current messaging instance and marked so that it can be processed by other recipients. This also happens in particular if an error / exception occurred during message processing.

JMS

Morphium also supports JMS, but there is a bit of a logical and conceptual "breach" ...

JMS sends messages e.g. in topics or queues ... in Morphium there is no or only a limited distinction. In this nomenclature, each message can be either a topic or a queue message.

If you send a message in Morphium Messaging that is marked as "non-exclusive" (default), then it is a broadcast, every participant can receive the message within the TTL (time to live). This is only decided based on whether you have registered a listener or not.

Every Morphium messaging listener can get topics, queues, channels, and direct messages. That is more or less determined by the broadcaster. The sender determines whether the message

• to be sent directly to a recipient (direct messaging)
• to all listeners (usually for a certain message name) - i.e. a broadcast (default)
• or to one of the listeners, but no matter which one (exclusive message, similar to the topics in the JMS)

Empty message-queue = healthy message queue

This is what you e.g. reads again and again about RabbitMQ. That is not the same with Morphium. The messages remain in the queue for a while and delete themselves when reaching the TTL. If I put a broadcast message in the queue with a lifespan of one day, then this message can still be processed within a day. And will it too, e.g. when new "consumers" register. (replay of messages).

This does not apply to exclusive messages, as you explicitly don't want to process them multiple times, i.e. the message is deleted after successful processing (only until V4.1.2 - after that, messages are only deleted when TTL is reached).

A Morphium message queue is always filled to a certain extent with this and that's a good thing.

Conclusion

Morphium messaging does not want to and cannot be a "replacement" for existing message systems and solutions. That was not the direct goal in development at all. There was a specific problem that could be solved most easily and efficiently.

Nevertheless, the areas of application of Morphium messaging are similar or overlap with other messaging systems. But that's in the nature of things. A migration from one system to another should definitely be possible in finite time. Morphium supports e.g. JMS, both as a client and as a server. This allows cache synchronization to be implemented using other, possibly already existing messaging solutions without having to forego the convenience of Morphium annotation-based cache definition. Or integrate Morphium into your own architecture as a messaging solution via JMS.

comparison table