can commands be issued into Solace PubSub+?

tomschreck

I'm new to Solace PubSub. I'm wondering if it's possible to issue commands into PubSub broker so it can get picked up somewhere else? Or, are only events issued through PubSub broker? Thank you for your time.

TomF

Hi @tomschreck,

TL;DR - yes, the Solace Event Broker can handle command, events, messages, REST interactions and a lot more.

Detailed answer:

I think it's worth talking at a more architectural level for this question. Let me start by answering some questions of my own:

• Can I exchange messages using pub/sub? Yes. You can exchange any message using the pub/sub pattern.
• Can I exchange commands using pub/sub? Yes. Any pub/sub system can route commands - commands can be a specialisation of messages. However, commands benefit from some features at the pub/sub layer (see below)
• Can I exchange events using pub/sub? Yes. Events are a specialisation of messages.

How does Solace PubSub+ treat messages, commands and events differently? It doesn't. PubSub+ doesn't care about the content (payload) of the message/command/event.

So how do we differentiate between them?

1. We use a topic taxonomy to tag events with topics that will exchange events. The same taxonomy can have a taxon in the tree that exhanges commands.
2. We interpret the payload differently. We do this by using _topic routing_ to route events to event consumers, and commands to command consumers.
3. We can configure certain aspects of the exchange pattern to make command processing easier.

Here is my recommended pattern for commands in PubSub+:

1. Send the command to a topic;
2. Tag the command as request/reply. A command expects a reply. Whether this is synchronous (has a timeout) or not is up to you. You'll probably want to use a correlation ID, especially if you're using an asynchronous pattern, and this helps with idempotency;
3. Map the command topic to a queue. Your command handler will consume from this queue.
4. Set the _max consumer count_ on the queue to 1. This prevents any other consumers from binding to the queue. Set the queue permissions so that only your command handler is permitted to bind. This gives you your ability to limit who can respond to the command.

uherbst

Hi @tomschreck ,

maybe I misunderstand your question.

You can put any payload in your messages that you want.

And if you put a payload as "open door and send ack back" in a message and that consumer reacts accordingly to that message, than yes: You can issue commands via messaging.

(That was a real life example from IoT environments).

Does this answer your question ?

Uli

tomschreck

Hi @uherbst . Thank you for response. So, the way I understand things are as follows

command -> command handler -> business process -> event -> event handler(s)

Commands are imperative like 'Create Notification'. Events express things that have happened for example: 'Notification Created'

Typically, for a command, you have a single command handler. For an event, you can have one or more event handlers.

So, from your response, I'm gathering I can issue commands from a system/service into Solace Event Broker for a command handler somewhere else to pick up and process? Is there a way to prevent multiple command handlers from consuming a given command?

Thank you.

TomF

Hi @tomschreck,

TL;DR - yes, the Solace Event Broker can handle command, events, messages, REST interactions and a lot more.

Detailed answer:

I think it's worth talking at a more architectural level for this question. Let me start by answering some questions of my own:

• Can I exchange messages using pub/sub? Yes. You can exchange any message using the pub/sub pattern.
• Can I exchange commands using pub/sub? Yes. Any pub/sub system can route commands - commands can be a specialisation of messages. However, commands benefit from some features at the pub/sub layer (see below)
• Can I exchange events using pub/sub? Yes. Events are a specialisation of messages.

How does Solace PubSub+ treat messages, commands and events differently? It doesn't. PubSub+ doesn't care about the content (payload) of the message/command/event.

So how do we differentiate between them?

1. We use a topic taxonomy to tag events with topics that will exchange events. The same taxonomy can have a taxon in the tree that exhanges commands.
2. We interpret the payload differently. We do this by using _topic routing_ to route events to event consumers, and commands to command consumers.
3. We can configure certain aspects of the exchange pattern to make command processing easier.

Here is my recommended pattern for commands in PubSub+:

1. Send the command to a topic;
2. Tag the command as request/reply. A command expects a reply. Whether this is synchronous (has a timeout) or not is up to you. You'll probably want to use a correlation ID, especially if you're using an asynchronous pattern, and this helps with idempotency;
3. Map the command topic to a queue. Your command handler will consume from this queue.
4. Set the _max consumer count_ on the queue to 1. This prevents any other consumers from binding to the queue. Set the queue permissions so that only your command handler is permitted to bind. This gives you your ability to limit who can respond to the command.

tomschreck

Hi @TomF. Thank you for the explanation. That helps a lot. Have a great weekend.

TomF

Thanks @tomschreck - it's always great to hear whether an answer has helped or not!