After reading this articleArticle
Service Broker implements the publish-subscribe framework
I practiced it myself and found some problems and experiences.
The main idea of this framework is that if the publisher wants to publish a message, he must first publish a request message to the publishing Queue (publisherqueue) to tell the publishing queue which topic messages I want to send
After a request message is sent to the publishing queue in the publishing direction, there will be a record in the queue. The most important thing is that the conversation field is of the guid type, it represents the handle of each session.
When sending a message again, it is equivalent to sending a Response Message to the producer. The message will be sent to the authorqueue queue. Of course it is not used here.
Then, when the subscriber wants to subscribe to a message, he first publishes a request to subscribe to the message to the publishing Queue (publisherqueue), telling the publishing queue that I want to subscribe to messages of that topic.
After a subscription request message is sent to the publishing queue in the subscription direction, the conversation generated in the queue is the handle sent to the subscription queue.
My idea is to store the request information and subscription information in two different tables: Publication and subscribtion, and then add a message sending table.
That is, the list of messages to be sent by the sender is stored in a table. The primary key of this table is the sending handle. We will first read the data in the queue cyclically, including sending and subscribing requests.
We associate two tables with subject to obtain all sending handles, and then read the messages to be sent to the subscription queue cyclically.
We can also write a service that reads the subscription queue in real time.ProgramOr console program to monitor every message!