7.4.2 Pub/Sub messaging model

The Pub/Sub messaging model sends and receives messages using the Publish-Subscribe method.

Organization of this subsection
(1) Sending and receiving messages using the Pub/Sub messaging model
(2) Features of the Pub/Sub messaging model
(3) Using a persistence subscriber

(1) Sending and receiving messages using the Pub/Sub messaging model

With the Pub/Sub messaging model, the sending client (producer) that creates and sends the messages is called the publisher. Also, the client (consumer) that receives the messages is called the subscriber.

The messages sent from the publisher are registered in a destination called the topic. The messages registered in the topic are delivered to one or multiple subscribers that applied to that topic for a delivery.

The following figure shows the flow of messages in the Pub/Sub messaging model.

Figure 7-6 Flow of messages in the Pub/Sub messaging model

[Figure]

The messages are sent from the publisher and registered in the topic. In the figure, subscriber1 is registered in topic1, and subscriber2 and subscriber3 are registered in topic2. At this time, message1 and message2 registered in topic1 are delivered to subscriber1, and message3 registered in topic2 is delivered to subscriber2 and subscriber3.

(2) Features of the Pub/Sub messaging model

The features of the Pub/Sub messaging model are as follows:

Features from the sending of a message to the execution of processing
  • One or multiple publishers can register the messages into a topic.
  • One or multiple subscribers can fetch and process the messages from the topic.
  • The subscriber can receive and process all the messages registered in the topic to which a delivery application is made. However, the subscriber cannot receive messages not applicable to the standards set with Message Selector, or the messages with validity periods that have expired before the message was received.
  • The messages are registered in the topic in the order in which the publisher sent the messages. However, the order processed with the subscriber is determined based on the validity period and the priority order of each message, or the Message Selector contents specified in the subscriber.
  • The publishers and subscribers have a dependency on the process execution timing. A message registered in the topic is only delivered to the subscriber started before the message was registered.
  • If NoLocal is specified in the subscriber attribute, the receiving of messages sent using the same connection as the connection used by the subscriber, can be controlled. The default value of this attribute is false.
Features of the system
  • You can dynamically add or delete the publishers and subscribers. Due to this, you can extend or scale-down the system according to the usage.
  • Multiple producers can share the connections used for establishing a connection with Cosminexus JMS Provider. Note that multiple producers can send messages to the same topic regardless of whether the connection is shared.
  • Also, multiple subscribers can share the connections used for establishing a connection with Cosminexus JMS Provider. Note that regardless of whether the connection is shared, multiple subscribers can connect to the same topic.

(3) Using a persistence subscriber

Only the subscriber that was running when the message was registered can receive the message registered in the topic. A normal subscriber cannot receive messages that were registered during the period when the subscriber was stopped.

On the other hand, by making the subscriber persistent, even the messages registered during the period when the subscriber was stopped, can be received. A subscriber that is made persistent is called the persistence subscriber.

The messages in the topic where the persistence subscriber is registered are not deleted until one of the following statuses is reached:

When you use a persistence subscriber, register an identifier and name specific to that subscriber. The registered information is stored by CJMSP Broker. The messages registered when the persistence subscriber is stopped are delivered to the subscriber with the registered identifier and name when the subscriber is restarted.

The following figure shows the flow of sending and receiving messages when the persistence subscriber is used.

Figure 7-7 Flow of sending and receiving messages when the persistence subscriber is used

[Figure]

The following points describe the flow of sending and receiving messages when the persistence subscriber is used. Note that the numbers in the description correspond to the numbers in the figure.

  1. Register subscriber1 in the topic as the persistence subscriber.
    Assume the identifier (ClientID) as 1.
  2. Publisher1 registers message1 in the topic.
  3. Subscriber1 receives message1 from the topic.
  4. Stop subscriber1.
    In the stopped status, subscriber1 cannot receive the messages registered in the topic.
  5. Publisher2 registers message2 in the topic. Because subscriber1 is stopped, message2 cannot be received. However, subscriber1 is registered as the persistence subscriber, so this message is stored in the topic until the registered persistence subscriber receives the message.
  6. Register subscriber2 in the topic as the persistence subscriber. At this time, the identifier (ClientID) is assumed as 1, and the subscriber name is set to the same value as subscriber1.
    From the identifier and name, CJMSP Broker storing the persistence subscriber information determines that subscriber2 is the restarted registered persistence subscriber.
  7. Message2 stored in the topic is delivered to subscriber2.

To cancel the specified persistence subscriber, use one of the following methods:

For details on the cjmsicmd destroy dur command, see cjmsicmd destroy dur (Destroying the persistence subscribers) in the uCosminexus Application Server Command Reference Guide.

If you use the unsubscribe method, you can cancel the status of the topic stored for the subscriber. However, do not use this method at the following times:

Note that when the persistence subscriber is created by a session with acknowledgement mode CLIENT_ACKNOWLEDGE, the message remains in the destination if the unsubscribe method is executed when the message receipt has not been confirmed. To avoid this situation, when you want to execute the unsubscribe method, first execute the cjmsicmd purge dur command to delete all the messages associated with the persistence subscriber.

Note
You cannot register a persistence subscriber for a topic created as a temporary destination. If you make such an attempt, an exception is thrown.