Topics and their subscriptions represent publish-subscribe (pub-sub) messaging pattern. If you’re coming from MSMQ, that’s a new concept. What’s the difference to plain old queue? Simplest scenario for a queue (and arguably most common one) is – single sender and single receiver:
Of course, we could have multiple senders, but that doesn’t create problems unless we want to maintain specific order of messages, so we won’t go into that. A bit more complex scenario is when there are multiple receivers:
If a queue has multiple receivers they’ll all compete for messages. If one receiver consumes a message others won’t see it anymore. That’s ok if we use queue for work jobs, and multiple receivers help us do some parallel processing to increase throughput.
But how do we handle a case where we want that multiple receivers all receive same message? For example, there could be a message notifying us that order is received. We have 3 independent subsystems that should all react to that event. First one would deal with credit card processing, the second one will prepare an invoice, and the third one will trigger someone to start packaging.
Topics allow you to have multiple subscribers (i.e. receivers). When you send one message, all of them will receive a copy of it:
We can think about this as if each subscriber has its own separate “queue” where it keeps copies of sent messages, and processes them at its own pace. But you can’t send messages directly to that special “queue”, you have to go through topic which distributes messages to everyone.
If you have 3 subscribers at the moment message is sent, each one of them will receive that same message. The important thing to notice is that subscription will get messages only from the moment it was created, it won’t get older messages which went through a topic earlier.
Subscription filtering
It’s not compulsory that all subscriptions receive all messages. We can set up a filter for each subscription which determines which messages it will receive. For instance, if our messages contain a field which describes payment method, and we have “Credit_card”, “Wire_transfer”, “PayPal” subscriptions, we can set up a filter on each subscription so that it receives only messages for that specific payment method and ignore all the others.
We can start QueueExplorer Professional and create a topic with 3 subscriptions, each one with a different filter. Here’s how to specify that filter:
Here’s how our 3 subscriptions look like:
Now we’ll prepare 3 test messages in some queue, each one with the same custom value named “PaymentMethod”, but with different values (Wire, PayPal, CreditCard):
After that is prepared we can drag and drop these 3 messages to our topic:
After drop is complete we’ll see that each subscription got one message:
And if we click on subscription we’ll see that “credit_card_processor” subscription received exactly the message we expected:
Since filtering allows more complex expressions, we could for example use invoice amount to put more valuable orders to a “high priority” subscription for faster processing. Since this filtering can be edited afterwards, we can reconfigure our system on the fly without changing applications!
Besides filtering, subscription rules allow us to modify a message as it’s transferred from a topic to subscription. We can create an “Action” which modifies or adds custom message properties.
We’ll learn more about queues in Part 3.
Links to all 5 parts of this series.