Differences between (RPC and PubSub) RabbitMQ and Solace

Stromgald

Hi , i'm a newbie of Solace. I used for years RabbitMq and i would change for Solace. I'm reading documentation but i still didnt userstand the difference between Direct, RPC and pubsub.

In Rabbitmq i have someone that publish on a certain queue a message and subscriber (registered on rabbit) of that certain queue receive e message. Those message could be decorated with a Topic so only subscriber on certain queue on certain topic should receive message. (Exchange.Queue) EcommerceX.OrderDirectory.OrederSent#topic)

And then RPC message. I sent a request and a responder (subscriber binding on a certain RPC queue) give me response.

On solace instead seems that the concept of topic is different.

On rabbit i can see the subscriber (RPC) on managment interface. Can i do the same on solace?

I made an tutorial example (that works) but i dont find any panel where i can see those.

Another question , can i use REST Pattern on Reply/Response instead of Solace API client ?

Thank you

himanshu

Hi @Stromgald ,

I am no expert on rabbitMQ but there are several differences between Solace PubSub+ and rabbitMQ.

RabbitMQ uses AMQP 0.9 wireline protocol whereas PubSub+ supports multiple protocols which makes it easier to leverage PubSub+ for a wide range of usecases from backend high-throughput usecases to front-end usecases to IoT usecases. PubSub+ supports AMQP, MQTT, REST, JMS, and WebSockets natively without any need for proxies. This means you can have multiple IoT devices publishing data via MQTT to PubSub+ and a backend Java process using JMS to subscribe to this data for processing along with a frontend Javascript application using WebSockets to stream this data on web app.

If we talk about messaging patterns, PubSub+ supports three types of messaging patterns: pub/sub (of course!), point-to-point (not recommended but certainly possible), and request/reply.

It's also extremely easy to implement an event mesh by networking a bunch of brokers together using underlying TCP/IP connections and Solace's Dynamic Message Routing (DMR). Messages are easily routed to their destination broker without any pre-configuration of topics. Messages will only be routed as long as there is an active subscriber which makes it a very bandwidth efficient and secure implementation.

Solace also has a very reliable HA and DR replication. You can setup an HA cluster to avoid an outage due to a node failure. Or you can setup DR replication in case of a datacenter/region failure. Both are extremely efficient and result in zero message loss.

Regarding topics and queues. Solace leverages both concepts. You can publish to dynamic and hierarchical topics such as eq/us/nyse/aapl and consume directly by subscribing to a topic (for non-persistent messaging) or by creating a queue and mapping one or more topics to it (for persistent messaging). You can also dynamically filter the data by using wildcards: * and >.For example, you can subscribe to all US Equities (EQ) data by subscribing to: eq/us/>. Or you can subscribe to AAPL's data regardless of where it is traded by subscribing to: `/*/*/*/AAPL`.

Hope this helps!

TomF

Hi @Stromgald, everything my learned colleague @himanshu says above is right, but let me come at this from a different angle.

You mention Direct, PubSub, and RPC. You also talk about queues. Let's tie all this together in the Solace world.

Firstly, Pub/Sub (Publish/Subscribe). This is how the PubSub+ broker does everything (the clue's in the name :-) Want to send a message to multiple receivers? That's Publish/Subscribe: you publish to a topic, and subscribers subscribe to the topic. All the subscribers get a copy of the message*

Now for RPC - in Solace we call this Request/Reply, but the two are synonymous. In PubSub+, the requestor publishes to a topic. The replier subscribes to that topic, gets the message, and responds on a special, reply-to topic. There you go - RPC over Pub/Sub. Hang on... doesn't that mean multiple repliers could subscribe to the request? Yes! And multiple subscribers could listen to the response? Yes! It makes building analytics and audit applications a dream. For PubSub+, REST is just another protocol the broker speaks - so yes, you can send in a REST request, have a (for instance) Java service respond, and we'll send the response back in the http response body to the original http request.

Queues are interesting - they are generally thought of as point to point, and in PubSub+ you can use them in this way. But everything in PubSub+ is pub/sub - so the queue is actually a subscriber. When you send a message to a queue, the queue address is actually a special topic. What's magic in PubSub+ is you can tell queues to act as a subscriber to any topic. Doesn't that mean you can have the same message go to multiple queues all at once? Yes! Pub/Sub using queues. It's a very powerful idea. I explore it more in my blog post (shameless plug...)

There is indeed an interface for seeing who is bound to a queue or subscribing to a topic - it's called SEMP.