Solace Community is getting a facelift!
On March 3rd we will be starting the process of migrating Solace Community to a new platform. As a result, Solace Community will go in to a temporary read-only state. You will still be able to come onto Solace Community and search through posts to find answers, but you won't be able to ask questions, post comments, or react in any way.
We hope to have the migration complete by Wednesday March 5th (or sooner), so please keep an eye out!
Send a message to the Queue instead the Topic
After hours of studying in Solace Documentation, Youtube Channel and etc, I believe I've ended up with some points to check with you:
Although we have some samples of sending a message to a queue, the best practice is to send a message to a topic. As I could see in the Spring Cloud Streams samples, this is the only way to send a message. Is it OK?
Since I have some legacy applications that use directly the Java JCSMP API (which allows me to send messages to a queue) and other new applications that use the Spring Cloud Stream with the Solace PubSub+ Binder, should I always send messages to topics to ensure only one standard in all applications of my architecture?
Best Answer
-
Hi @murillocg,
The short answer is "yes!" Our best practice is to always send to a topic, and to map this topic to a queue.
The reason is pretty simple: you may have a simple 1 to 1 pattern that you need to implement. But architectures are never static, and the chances are good that in the future someone else will need this data. If you use a topic, adding extra consumers is trivial. If you send to a queue, lots of pain awaits you.
Even if you know no other application will ever need your data, conforming to the best practice other need to adopt will make your application easier to understand.
1
Answers
-
Hi @murillocg,
The short answer is "yes!" Our best practice is to always send to a topic, and to map this topic to a queue.
The reason is pretty simple: you may have a simple 1 to 1 pattern that you need to implement. But architectures are never static, and the chances are good that in the future someone else will need this data. If you use a topic, adding extra consumers is trivial. If you send to a queue, lots of pain awaits you.
Even if you know no other application will ever need your data, conforming to the best practice other need to adopt will make your application easier to understand.
1
Categories
