Publish/subscribe message transmission model

1. Overview of publishing/subscription models

The publish-and-subscribe model is usually abbreviated as the pub/Sub Model. In this model, the message producer becomes the publisher, and the message consumer is called the subscribe ). In the point-to-point model, messages are sent to a queue, while the publish/subscribe model publishes messages to a topic. The most important features of the publishing/subscription model are as follows:

• Messages are exchanged through a virtual channel called a topic.
• Each message is sent to multiple consumers called subscribers. There are many types of subscribers, including persistence, non-persistence, and dynamic.
• The publisher generally does not know or realize which subscriber is receiving the topic message.
• The message is pushed to the consumer, which means the message is sent to the consumer without a request. Messages are exchanged through a virtual channel called a topic. The topic is the destination where the producer publishes messages and the subscriber consumes messages. Messages sent to a topic are automatically pushed to all qualified consumers.
• There is no coupling between producers and consumers. Subscribers and publishers can be dynamically added at runtime, which allows the complexity of the system to increase over time.
• Each client that subscribes to a topic receives a copy of the message that publishes the topic. A single message produced by a publisher can be copied and distributed to hundreds of thousands of subscribers.

When the publish subscription model is used, the JMS provider immediately sends messages published to a topic to each subscriber. Therefore, unlike the point-to-point model, subscriber does not scan the topic to find the messages that belong to them. Instead, a copy of the message is sent to each subscriber by the JMS provider.

Another major difference between the publishing/subscription model and the point-to-point model is that the message selector is used when a message is copied to each subscriber in the publishing/subscription model; the point-to-point model uses the message selector after a message is added to the queue.

Subscribers can be either persistent or non-persistent. Non-persistent subscribers receive messages only when the current subscriber is active and connected to the topic; A persistent subscriber receives all the messages sent to the topic, regardless of whether the subscriber is active or not.

Subscribers can also be dynamic or managed. Dynamic persistent subscribers can be created in real time, while managed subscribers are static, and the JMS provider knows the existence of this managed subscriber.

When to use the publish/subscribe message transmission model: If you want to broadcast events or messages to multiple message consumers, the publish/subscribe model is used. The most important one here is that this message can be consumed by multiple consumers. Publishing/subscription model

The principle is to push copies of messages to multiple subscribers.

Use of the publish/subscribe message model: Initialize JMS

In the tlender class example, the suoyoudejms initialization logic is all processed in the constructor. The tlender constructor code is almost identical to the qborrow constructor except for the two important differences.

first, note that the connection factory, connection, and session objects of the tlender class are similar to those of the qborrow class. Besides, they use topic-based interfaces rather than queue-based interfaces:

//Connect to the provider and obtain the connection with JMSContext CTX =NewInitialcontext (); topicconnectionfactory qfactory=(Topicconnectionfactory) CTX. Lookup (topiccf); tconnection=Qfactory. createtopicconnection ();//Create a JMS sessionTsession = tconnect. createtopicsession (False, Session. auto_acknowlege );//Query request and response queuesTopic =(Topic) CTX. Lookup (topicname );//Now, the creation is complete. Start the connection.Tconnection. Start ();
 

Although topic-based APIs are used, the process is the same as the queue-based API used by the point-to-point model:

1. Obtain an initial context provided by JMS.
2. Find the connection factory.
3. Create a JMS connection.
4. Create a JMS session.
5. Find the destination.
6. Start the connection.

Publish messages

Once the tlender class is initialized, the interest rate is input through the command line. In this case, the system calls the publishrate method from the main method, and the interest rate is published to the subject IQ. Different from the point-to-point example, once a message is published, the tlender class no longer waits for a response. This is based on the decoupling nature of the publishing/subscription model. The tlender class does not know or care about who is subscribing to interest rates and how they process data, or the number of subscriber receiving interest rate information. It may also happen that some subscribers are receiving interest rate data and the specific lender is responsible for analyzing the trend of mortgage rate fluctuations, while other subscribers (such as tborrower class) the interest rate is analyzed to determine whether to provide loans again.

At the beginning of the publishrate method, we created a bytesmessage to save the interest rate data. You can select either of the JMS message types in step 5, But we chose bytesmessage with the highest Portability:

 
Bytesmessage MSG =Tsession. createbytesmessage (); msg. writedouble (newrate );
 

After the message is created, we create the topicpublisher object, which specifies the topic of the message to be published. Then we use the publish method to publish the message:

 
Topicpublisher publisher =Tsession. createpublsher (topic); Publisher. Publish (MSG );
 

Like the send method of the point-to-point model, there are also several types of override publish methods available in the topicsender object. This method we are using only accepts the jmsmessage object as a unique parameter. Other rewriting methods allow you to specify the topic, transfer model, message priority, and message validity period. Since we have not set any other values, the priority of all messages is set to normal (4), and the transfer model is set to persistent messages (deliverymode. and the validity period is set to 0, indicating that the message will never expire. All these parameters can be rewritten using other publish methods.

It must be noted that although the request/response must be applicable to the publishing/subscription model, it is not common in the topic-based message transmission model today, this is mainly because the essential feature of the publishing/subscription model: the publishing/subscription model is usually used to broadcast events or information, and it does not expect to respond to the broadcast.

Persistent and non-persistent subscribers

If you want to run the tborrower class and then publish several kinds of interest rates, the tborrower class will get a new interest rate and determine whether the interest rate is appropriate. However, if you want to terminate the tborrower class, release some new interest rates, and then restart the tborrower class, you will not get the interest rates published to the topic during the tborrower class is not running. Why? The reason is that the tborrower class you created is a non-persistent subscriber:

 
Topicsubscriber subscribe = tsession. createsubscriber (topic );
 

Messages are received only when a non-persistent subscriber actively listens to a topic. Otherwise, they will miss these messages. In the publishing/subscription model, there is no such real concept as "topic" for saving all messages. Specifically, when the JMS provider receives a message, the provider creates a copy of the message for each subscriber. If the subscriber is not active, it will not receive a copy of the message. This concept is shown in Figure 5-3.

On the other hand, a persistent subscriber receives all messages sent to the topic (depending on the message Selector Used by the subscriber), regardless of whether the subscriber is active or not. This is usually called "store-and-forward" message transmission. The concept of persistent subscriber "Save and forward" is as follows: